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}

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}