Wednesday, September 25, 2013

This challenge was fairly simple you are given a
Windows PE. The first thing we did was attempt to run the executable, however
as soon as you run it the program will just crash. Next we decided to open the
executable in Ida Pro.

To reverse the key we simply opened the program in
the debugger and forced the program to follow the execution path we wanted
(making sure to step over the debugger trap of course). From there we were able
to find the key in memory and submit the flag.

Tuesday, September 24, 2013

This challenge was fairly simple you are given a
Windows PE. When you run the PE it opens a box titled flag and contains garbage
characters.

When opening the program in IDA pro we noticed this
line right away.

The executable checks if the
program is being debugged and if it is it will print the key. All we had to do
from there was run the program in Ida Pro with the Local Win32
debugger to see the message box that contains the key.

Credit to Spencer and Jessi
We were given a python script by the name of csawpad.py. The first function (genTables) generated an s box and s inverse box. S box was used in the encrypt function to generate the cipher text and s inverse was used in the decrypt function to go back to the decrypt. The comments in the script claimed that it was using a sha512 hash to generate random numbers. The problem with that is that the seed value was hard coded as "Well one day i'll be a big boy just like manhell" and therefore the tables generated were the same each time the script is ran.

The encrypt and decrypt functions run the supplied text though the s or s inverse table using a pad string as a key.

There is a simple sanity function the compares the s and s inverse tables to make sure that they are being generated correctly. It then checks the encrypt and decrypt functions by generating a 1000 value plain text and pad, running it through the encrypt function, then though the decrypt function, and then checking the results. It does that 1000 times.

At the end of the file, there was a block comment of 8 cipher texts that have been hex encoded:

The the problem was that we had no idea what padding was used to encode these texts. After messing around a but and trying to guess the pad value, we started to wonder why we were given such a large sample. A frequency analysis wouldn't help because this is a poly-alphabetic cipher. After some thinking, we came up with a plan to run the first value of each ciphertext though a long pad of a single value from the full ascii set. We then did this with the second value in each ciphertext, then third, and so on up to the 52nd value. If a pad value gave us a readable character for each of the ciphertexts, then we printed it out.

Output by column in ciphertext:

20 138 203 2237140 210139212234111104 11657 201 2411642281341134317 22 32 166 190155 183114 143 1802 97 20512764164 218 231114117 24810249 115591511622917512486169 242692 119 222 23930191235169 19535 7516 66167246241 25416612963 247104762399010 16 68 178 198 218 229
We attempted to use the first value of each column as the pad and ran the first cipher text through the decrypt function. We got a few readable words back but it wasn't perfect. We then swapped out values in the pad until we got all the words out correctly. We then ran the last cipher text though with our finished pad value and got the key out!

The first thing we did for this challenge was to look at the program headers:

From the headers we can see that the stack is given read, write, and execute permission therefore assuming the stack has enough space and we can overflow the buffer we should be able to place and execute shell code on the stack. Looking at the assembly in IDA pro we see a few interesting lines.

From the assembly we can also calculate what the stack will look like at run time:

We learned from reverse engineering the assembly the program is going to do the following:

Prompt for username and password

Compare the received username and password against “csaw2013” and “S1mplePWD”

Prompt for entry number

Verify that entry number is not zero

Verify the entry number + 1 is less than or equal to 1024

Prompt for dairy input (using entry number as the number of bytes to receive)

Create a dairy file

Save the input bytes into diary file

Delete the dairy file

Return

It appears that the program is reading 1024 bytes in to a 1024 byte buffer, however if we input a negative value for the entry number we will pass the less than 1024 byte check and force the program to read in enough bytes to overflow the buffer and change the return address.

From here we wrote a script to send the shellcode that opens a bind shell on the remote server. To connect to the server and cat the key.

Monday, September 23, 2013

So I did this challenge a bit different then anyone else.
so in the url you would get an ip.com/viewmessage.php?id=questionableid and ip.com/editnote.php?id=questionableid but if you put the same id from viewmessage.php into the id for editpost.php?id=questionableid you would go back a message. So by swapping the ids between the two webpages I was able to go back all the way to the first post which was the key.
I dont have pics but I assure you this was how I solved the challenge.
Peace and love Shiina

The first thing we did for this challenge was to
look at the program headers:

From the headers we can see that the stack is given
read, write, and execute permission therefore assuming the stack has enough
space and we can overflow the buffer we should be able to place and execute
shell code on the stack. By looking at the assembly in IDA pro we discovered
that the executable does not contain linking information. Rather than finding
the function that reads in user input we found the length to return address
through trial and error. The input length to return address is 417 bytes as
shown in the screenshot below.

Now that we have control of EIP we need to return to
our shell luckily upon further inspection of the stack addresses we noticed
that the stack is using memory addresses from the executable. This means the STACK ADDRESSES ARE STATIC. From here
we wrote a script to send the shellcode that opens a bind shell on the remote
server, connect to the server and cat the key.

2. What is the abbreviation of the research published in the Hackin9 issue
on nmap by Jon Oberheide, Nico Waisman, Matthieu Suiche, Chris Valasek,
Yarochkin Fyodor, the Grugq, Jonathan Brossard, and Mark Dowd?

key{dicks}

3. What is the common name for a single grouping of instructions used in a
Return Oriented Programming payload, typically ending in a return (ret)
instruction?

key{gadget}

4. What is the new web technology that provides a web browser full-duplex communication to a web server over a single connection?

There is a simple space shooter and a boss with a lot of health represented with the red bar at the top. Each time you shoot you do 2 damage (1 for each bullet) and he has a lot of health.

Using ArtMoney and NoCashGBA you can find the value of the bosses health to be 1000000. Search for an unknown value, shoot the boss, say the value decreased, reload the rom, say the value increased and repeat until you only have a few values.

Discover 2032178 = boss health

Start the rom, modify the value, Kill the boss, and get a screen that says KEY IS DUGZFG. The hint says are you sure you have the full key?

Keep modifying the bosses health after the screen loads and eventually you will get it to say KEY IS DUGZFGJCRC. This is a trap.

The key is really printed with text in memory and not to the screen.

Using IDA PRO with a NDS Loader
Load Strings and find where GameInit is loaded in sub_20019B8.
Notice WinState is loaded by sub_2001c40.
Right click the gameinit sub and find references to sub 2001dcc
Press space on the call to BL #0x20019B8 and get the memory address 0x2001DE8

So if you modify BL sub_2001920 to BL sub_2001c40 it will load the win state instead of the game. Cool let's make that change.

View the opcodes under options general and set the number of opcode bytes to 8.

Open HXD and search for that place in the program. 04 1c 20 1c ff f7 E6 FD 20 1C.

Open sub_2001c40 in ida and find references to it in sub_200220c
Press space BL sub_2001c40 and notice its opcodes are FF F7 9F Fb

Change "FF F7 E6 FD" to "FF F7 9F FB"

Save the file and run this in Desmume.
Click on the black screen to start the Win State. You won't see anything because of how kiwi made the rom using devkitpro.

Dump the memory for the ds in desmume using the memory utility

Strings the memory dump and search for key
You will find "key is ou6UbzM8fgEjZQcRrcXKVN"

For this challenge, they gave us an address to netcat to and an executable. We viewed the executable in IDA and noticed that it requests for a registration code, runs the given string through a function, and then compares the returned number to 0xEF2E3558. If they are equal, it reads in the key from a file and sends it to the user. So we figured that we might need to reverse that function to create input that it would accept.

IDA has kindly reconstructed the function in C for us:

From this we could see that the function takes in a string. It takes the returned variable (starting at 1337) and multiplies it by 32 and adds the value of the current character in the string. It then adds this value to the return variable, and repeats the process until the next character is NULL.

One major problem to this was that v4 is a signed integer and because of that it would reset into negative values if it would increase pass the maximum signed integer value. We also realized that the length of the input influenced the output of the function much more than the value of characters in the string. So we wrote a C program that would run this function and return the value.

We then figured that would attempt to find a possible solution by finding the length of the string by inputting a string of the same character. Then we would modify these values from right to left, so that the returned hex value would begin to form 0xEF2E3558.

We began by feeding the program 'A', then 'AA', then 'AAA', and so on until we reached 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAA'. At this point the returned hex value was fairly close the needed hex value, that is 0xa9ef0df6 since a distance of 0x50000000 would be possible to obtain by modifying the other values in the string to obtain the needed value.

We then began to go through each character in the string and increment it by one until we found a string that would only increment the most significant byte of the hex by only 1 or maybe 2. Once we found that, we modified it to give us something like 0xEXXXXXXX.

We then repeated a similar process to obtain 0xEFXXXXXX, and then 0xEF2XXXXX, and so on...

The final inputed string that gave us 0xEF2E3558 was: 'AAAAAAAAAAA$AAAAAAAAAAA[PV=Qv'.

The first thing we did for this challenge was to
look at the program headers:

From the headers we can see that the stack is given
read, write, and execute permission therefore assuming the stack has enough
space and we can overflow the buffer, we should be able to place and execute
shell code on the stack. Looking at the assembly in IDA pro we see a few
interesting lines.

From the assembly we can calculate what the stack
will look like at run time:

As we can see the assembly the program is going to
do the following:

1.Create
a random canary value and save it into VAR_C

2.Send
the address that tops to the top of BUF

3.Send
the canary value

4.Send
the following string “Welcome to CSAW CTF.Exploitation 2 will be a little harder this year.Insert your exploit here:”

5.Receive
4096 bytes and store them in BUF

6.If
the canary value has not been changed return else exit the program

So the program is
reading up to 4096 bytes into a 2048 byte buffer. We have a known address that
points to the top of the buffer and we have the canary value. So we need to
write an exploit program that will send the shellcode + canary value + buf
address to get the flag.