Register yourself if you have not yet.
Access the challenge at http://ringzer0team.com/challenges/11
Download the subject, the checksum:
- f6816b590d2021a16ba8005aa235e6a3 (md5)
- b8c18db3e4678e09683e3b20e9004d1183c2420b (sha1)
The challenge clearly instruct as to utilize GDB. In this case, I have customize my GDB using init script which can be downloaded from my github.
After downloading the binary, ran ‘file’ then ‘readelf’ to get some initial information about the file.
# file 88eb31060c4abd0931878bf7d2dd8c1a 88eb31060c4abd0931878bf7d2dd8c1a: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=a5f44b829c4727ed369f823f19d575087673f34e, not stripped # readelf -h 88eb31060c4abd0931878bf7d2dd8c1a ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: Intel 80386 Version: 0x1 Entry point address: 0x8048380 Start of program headers: 52 (bytes into file) Start of section headers: 4508 (bytes into file) Flags: 0x0 Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 9 Size of section headers: 40 (bytes) Number of section headers: 30 Section header string table index: 27
We know the entrypoint which is 0x8048380 and certain that the file is ELF32.
Load the binary to GDB, we use Intel syntax instead of AT&T syntax and break to entrypoint. We then run the binary so we can reach our breakpoint.
# gdb 88eb31060c4abd0931878bf7d2dd8c1a gdb$ set disassembly-flavor intel gdb$ break *0x8048380 gdb$ run
If you are using my .gdbinit script you can see the all the registers. If not, see the disassembly of $eip and let’s analyze the code.
gdb$ disassemble $eip
See the code and learn that there are interesting parts.
... 0x080484ae <+66>: mov DWORD PTR [eax],0x47414c46 0x080484b4 <+72>: mov DWORD PTR [eax+0x4],0x3930342d 0x080484bb <+79>: mov WORD PTR [eax+0x8],0x32 ... 0x080484e9 <+125>: mov DWORD PTR [eax],0x75393438 0x080484ef <+131>: mov DWORD PTR [eax+0x4],0x6a326f69 0x080484f6 <+138>: mov WORD PTR [eax+0x8],0x66 ... 0x08048530 <+196>: mov DWORD PTR [eax],0x6a736c6b 0x08048536 <+202>: mov DWORD PTR [eax+0x4],0x6c6b34
All of them are pushing the code into some region of memory pointed by eax. It’s ASCII, if you know. Let’s search it in our ASCII table.
0x47414c46 ==> GALF 0x3930342d ==> 904- 0x32 ==> 2 ... 0x75393438 ==> u948 0x6a326f69 ==> j2oi 0x66 ==> f ... 0x6a736c6b ==> jslk 0x6c6b34 ==> lk4
Well, it doesn’t make sense, unless you remember they are pushed in reverse order for each word. So, the flag would be
Submit the flag!crackmes, problem, reverse engineering