Secuinside CTF 2012 - iu

The challenge text was as follows:

Hints:
1. hex
2. [-3:]
3. inverse.

Challenge text:
-----
the message was decoded:
11111011 11101111 10001110 10000110 00011000 01100001
10000110 00011000 01011000 10100010 11100011 01011010
10111010 00001000 01101101 11001000 00010000 00010010
00010011 10101110 00111110 11111011 10111010 01011110
01100100
-----

As the hints mention, we converted the binary above to hex and got the following:

0000000: fbef 8e86 1861 8618 58a2 e35a ba08 6dc8  .....a..X..Z..m.
0000010: 1012 13ae 3efb ba5e 64                   ....>..^d

The second hint [-3:] means the last 3 elements of an array or last 3 chars in a string in python. The last 3 byes here was ba5e64 which stands for Base64. The challenge hint was also that "this message was decoded" so we need to Base64 encode to get the flag. On encoding, we get:

+++OhhhhhhhYouNaughtyBASE64++7peZA==

However, the above was not accepted as the key. Further hints were given to separately do Base64 of the first 22 bytes and the last 3 bytes and concatenate them to get the key. On doing the same we get the following which is still not the accepted key.

+++OhhhhhhhYouNaughtyBASE64++w== and ul5k

After some guessing, we get the correct key:

+++OhhhhhhhYouNaughtyBASE64+++==ul5k

Because of random padding, it turns out that both "+++OhhhhhhhYouNaughtyBASE64+++==" and "+++OhhhhhhhYouNaughtyBASE64++w==" decode to the same bytes.

Defcon CTF Quals 2012: Grab Bag 400

The Grab Bag 400 was a simple SQL Injection vulnerability in zip code based search which we exploited using UNION query.

The following query was executed to enumerate the accounts table:

http://140.197.217.85:8080/boa_bank/find_branch.jsp?zip=11%20UNION%20select%20CAST(id%20as%20text),CAST(id%20as%20text),CAST(id%20as%20text),CAST(account%20as%20text),balance,CAST(id%20as%20text)%20from%20Account

Since there was no name in the accounts table, we enumerated the information schema to find out the name and schema of other tables in the database and found that the user information is stored in the customer table which we enumerated using:

http://140.197.217.85:8080/boa_bank/find_branch.jsp?zip=11%20UNION%20SELECT%20table_name,%20table_schema,%20column_name,%20'1',%20'1',%20'1'%20FROM%20information_schema.columns%20WHERE%20table_name%20=%20'customer'

After enumerating the contents of Customer table, we were unable to find the name 'Jeff Moss' as was required to solve the level but since all the account's balance were 0.00, we ended by scoring using 0.00 as the key. However we later realized we had to look for Dark Tangent, Jeff Moss' alter-ego in the customer database :)

Defcon CTF Quals 2012 - urandom 300

This challenge was based on finding an efficient algorithm to a problem.  The following information was provided

Server: 140.197.217.155:5601
Password: d0d2ac189db36e15

First we connected to the given server and provided the password. The server responded with some text and some unprintable junk. So we wrote up a script to read what the server was sending. It turned out to be the following text


It was followed by 200000 bytes of data which consisted of 100000 unsigned integers which we were supposed to sort. We sorted the array in ruby and applied  an algorithm like selection sort where we shifted each of the numbers to their respective index as per the sorted list. In the worst case the number of swaps was 99999(in case it was a reverse sorted list) and in the best case it would be zero if none of the numbers need to be swapped.

We needed to run it in a decent connection with high upload speed to get the key. On submitting the correct list of swaps, the server responded with the following:


Ruby code: