0x41414141.com: 1 - 3

@jjarmoc pointed me at 0x41414141.com and I spent a few hours with the first 3 challenges.

1: Base64 encoding, decoded it.

2: A PE executable:

bfab4d3c076ac4059f3c1e680c7a6933.exe: MS-DOS executable PE for MS Windows (GUI) Intel 80386 32-bit

Started off with a strings of the binary which showed the following:

Email is return value of fn in form 0x12345678 zero padded to eight digits

Continued on with a objdump -D and pieced together what the ASM was doing. This lead me to the following C program:

#include <stdio.h>

int
main()
{
int val = 0xc0ffee;
int first = 0x401000;
int second = 0x8744ee;

printf("original: 0x%x\n", val);

val = val ^ first;

printf("first transform: 0x%x\n", val);

val = val ^ second;

printf("second transform: 0x%x\n", val);

return 0;
}

At first, I zero-padded the wrong side which lead me to a frustrating multi-hour "what am I missing" hunt.

3: I haven't played with a file format yet, so this challenge was very educational. They provided a PNG image named gzip.png--logo of GZIP.

I tracked down some documents on the PNG file format (1 and 2) and was delighted that it wasn't too difficult to follow. PNG files start with a header which is then followed by various variable length "chunks".

hexdump -Cing the image, I saw the string "email" inside a zTXT chunk--a compressed text string inside the image. zTXT uses zlib to compress the text string and this is where a day of frustrations began.

It turns out that there is a gzip file format, but also a zlib file format--At first, I thought they were the same and didn't know the other existed. At second, the zTXT chunk in this image almost makes sense using both formats.

3.c reads the PNG file, skips to the zTXT chunk and parses out the compressed text.

I took the easy way out and instead of learning and writing a zlib inflater, I used the zlib's API example zpipe.c to uncompress and print the txt.