Wednesday, September 25, 2013

CSAW 2013 Reversing 200

Reversing 200 CSAW 2013

Credit to Ryan

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

CSAW 2013 Reversing 100

Reversing 100 CSAW 2013

Credit to Ryan

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.



CSAW 2013 Reversing 100

Reversing 100 CSAW 2013

Credit to Ryan

This challenge was fairly simple you are given a .NET executable that prompts you for a password:


To see the password check function we used .NET reflector to view the source code. The source code is as follows:


All we needed to do to get the program to print the key is to find the result of num2 ^  num3 which is 13371337255. From here we put in 13371337255 and had the program print the key.




CSAW 2013 Crypto 100

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:
Recovered texts, hex encoded '794d630169441dbdb788337d40fe245daa63c30e6c80151d4b055c18499a8ac3e5f3b3a8752e95cb36a90f477eb8d7aa7809427dde0f00dc11ab1f78cdf64da55cb75924a2b837d7a239639d89fe2b7bc1415f3542dba748dd40', '14a60bb3afbca7da0e8e337de5a3a47ae763a20e8e18695f39450353a2c6a26a6d8635694cbdc34b7d1a543af546b94b6671e67d0c5a8b64db12fe32e275', '250d83a7ed103faaca9d786f23a82e8e4473a5938eabd9bd03c3393b812643ea5df835b14c8e5a4b36cdcfd210a82e2c3c71d27d3c47091bdb391f2952b261fde94a4b23238137a4897d1631b4e18d63', '68a90beb191f13b621747ab46321a491e71c536b71800b8f5f08996bb433838fe56587f171a759cf1c160b4733a3465f5509ad7d1a89d4b41f631f3c600347a8762141095dad3714027dfc7c894d69fd896b810313259b1a0e941ecb43d6ae1857a465b4ddcdf102b7297763acb0281144b0598c326e871c3a1ad047ad4fea2093a1b734d589b8998175b3', '0fc304048469137d0e2f3a71885a5a78e749145510cf2d56157939548bfd5dd7e59dcebc75b678cfeac4cf408fce5dda32c9bfcbfd578bdcb801df32ebf64da365df4b285d5068975137990134bd69991695989b322b0849', '254c0bb31453badaca9d060ce5faa45fa66378a6716915473579d3743e315dbedf4d8cf78b93c3267d579247e32c8c7cd3e71e7dda6138a2ab015166fa03f2ce6ab74b89ce561eb16a65990189e169f1c457d9af622ba119a66acedb108fae18825bf3efc0428b9dae250791cb0ea018966e257d601a87f9914d646026eeab5c45cbaedd27e4c47643ab4e25193aa64f79', '41cd1c01c62883b2ca71e671dce57e5f96b1610e29507b6c03c38211653284576d4d8cdc967764147d1a0578102cb05f32a73065f11009041fa3cc5f60b24d8c7098598627df37322f814525966acabc99be5303c2322b43ecf358ac8b8541bd82214d1cc042cac3869c54e2964fa376229c2563ba3fd03e2d4d4d441721c60b6d817e034965be28b7d463cf2b97baebfe2729ed2aa41ffe', '68c50bd5197bfdbdfa887883783d2455a673a685436915bd72d1af74dffdd2b89df335daee93c36d5f57e147e9a35913d3b3bf33'

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  223
71
40  210
139
212
234
111
104  116
57  201  241
164
228
134
113
43
17  22  32  166  190
155  183
114  143  180
2  97  205
127
64
164  218  231
114
117  248
102
49  115
59
15
116
229
175
124
86
169  242
69
2  119  222  239
30
191
235
169  195
35  75
16  66
167
246
241  254
166
129
63  247
104
76
239
90
10  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!

Pad:
223, 71, 40, 139, 212, 234, 111, 104, 57, 164, 228, 134, 113, 43, 190, 155, 143, 97, 127, 64, 231, 114, 248, 102, 115, 59, 15, 116, 229, 175, 124, 86, 169, 69, 239, 30, 191, 235, 195, 75, 16, 167, 246, 254, 166, 129, 247, 104, 76, 239, 90, 229

Output:
MY key for you is {And yes the nsa can read this to}

CSAW 2013 Exploit 300

Exploit 300 CSAW 2013

Credit to Ryan

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:
  1.  Prompt for username and password
  2. Compare the received username and password against “csaw2013” and “S1mplePWD”
  3.  Prompt for entry number
  4. Verify that entry number is not zero
  5. Verify the entry number + 1 is less than or equal to 1024
  6.  Prompt for dairy input (using entry number as the number of bytes to receive)
  7. Create a dairy file
  8. Save the input bytes into diary file
  9. Delete the dairy file
  10.  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.

Flag = signness_oh_what_a_world_we_live_in



Monday, September 23, 2013

Web 200

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

CSAW 2013 Exploit 400



Credit to Ryan

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.
Flag = key{And_all_I_got_was_this_stupid_key}

CSAW 2013 Trivia

1. Drink all the booze, ____ all the things!

key{hack}

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?

key{websocket}

5.What is the x86 processor operating mode for running 64-bit code?
key{long mode}

CSAW 2013 Rev 500 (No Pics)

Credit to MK/MG

Nintendo DS Reversing 500

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"

crackme - Reversing 300 Points CSAW QUALS 2013

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 key is:  day 145: they still do not realize this software sucks

deeeeeeaaaaaadbeeeeeeeeeef - Misc 200 Points CSAW QUALS 2013

So for this challenge we're giving a neat image with a CRC error in the IHDR chunk.  Here's what the image showed:





  Here's some of the data found through png check:
3264 x 1681 image, 32-bit RGB+alpha, non-interlaced
Now that's a strange height.
We then increased the height of the image by increasing the value in a hex editor until it showed a key:



Here's the complete image:


key is {TheISISPasswordIs}

Black & White - Misc 100 Points CSAW QUALS 2013

So for this challenge, they give us a white image:



We then viewed it in Stegsolve and could see that some of the bits were slightly off:


key is {forensics_is_fun}

CSAW 2013 Exploit 200



Credit to Ryan

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.

Flag = 53666e040caa855a9b27194c82a26366

key{53666e040caa855a9b27194c82a26366}