Crackme 14: geyslan's crackme.02.32

Apr 18, 2018

Link: http://crackmes.cf/users/geyslan/crackme.02.32/ (binary)

$ ./crackme.02.32
Please tell me my password: 1234
No! No! No! No! Try again.

Hopper finds no strings, no symbols. strings tells us that there are probably some protections in place:

$ strings ./crackme.02.32
[...]
I'm sorry GDB! You are not allowed!
Tracing is not allowed... Bye!
Please tell me my password:
The password is correct!
Congratulations!!!
No! No! No! No! Try again.

The strings are mostly around 0x08048858.

GDB does not recognize the executable, which seems to be corrupted:

$ file ./crackme.02.32
crackme.02.32: ELF 32-bit LSB executable, Intel 80386, (SYSV), too many section (65535)

$ gdb ./crackme.02.32
[...]
"./crackme.02.32": not in executable format: File format not recognized

Hopper shows a reference in EntryPoint to 0x80486fd, which is recognized as data but that we can switch to code by pressing ‘c’. Immediately, we see references to “Please tell me my password: “, “The password is correct!\nCongratulations!!!\n”, and “No! No! No! No! Try again.\n”. The code at 0x08048768 performs the comparison:

08048768         test       eax, eax
0804876a         jne        EntryPoint+787

If we were to trivially patch this test by replacing test eax, eax with xor eax, eax, it would defeat it. Just like in crackme 13, we can replace 0x85 0xC0 with 0x31 0xC0 and save it as a new binary.

$ ./crackme.02.xortest
Please tell me my password: hello
The password is correct!
Congratulations!!!

That was a bit too easy, so let’s dig into the binary and see what it’s actually doing.

Let’s start with renaming 0x8048410 as printf since it’s called with string parameters:

0804871f         mov        dword [esp], aPleaseTellMeMy    ; "Please tell me my password: "
08048726         call       0x8048410
[...]
08048785         mov        dword [esp], aThePasswordIsC    ; "The password is correct!\\nCongratulations!!!\\n"
0804878c         call       0x8048410
[...]
080487ac         mov        dword [esp], aNoNoNoNoTryAga    ; "No! No! No! No! Try again.\\n"
080487b3         call       0x8048410

Let’s also try to fix the number of sections, with the hope that GDB will load the file. Wikipedia has a description of the ELF header, listing e_shentsize (the size of the section entry) at offset 0x2E. We can observe that the 2 bytes at that offset are 0xFF 0xFF, matching our 65535 sections from file. readelf confirms the corrupt header:

$ readelf -a crackme.02.header
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:                           0xffffffff
  Entry point address:               0x8048480
  Start of program headers:          52 (bytes into file)
  Start of section headers:          4294967295 (bytes into file)
  Flags:                             0x0
  Size of this header:               65535 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         8
  Size of section headers:           10240 (bytes)
  Number of section headers:         10496
  Section header string table index: 65535 <corrupt: out of range>
readelf: Warning: The e_shentsize field in the ELF header is larger than the size of an ELF section header
readelf: Error: Reading 0x6680000 bytes extends past end of file for section headers
readelf: Error: Section headers are not available!

“Size of this header” refers to e_ehsize at offset 0x28, it’s usually 52 for a 32-bit executable. We can replace the two bytes there with 0x34 0x00. Next, section headers. They should be 0x28 bytes so we can replace the 0xFF 0xFF at offset 0x2E with 0x28 0x00. Let’s also reset e_shoff to zero, as well as e_shnum and e_shstrndx. readelf now reports a clean header (even if we might be missing a couple of things) when we save a new binary:

$ readelf -a ./crackme.02.header
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:                           0xffffffff
  Entry point address:               0x8048480
  Start of program headers:          52 (bytes into file)
  Start of section headers:          0 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         8
  Size of section headers:           40 (bytes)
  Number of section headers:         0
  Section header string table index: 0

There are no sections in this file.

There are no sections to group in this file.

GDB loads it too:

$ gdb ./crackme.02.header
[...]
gdb$ r
Starting program: ./crackme.02.header
Tracing is not allowed... Bye!
[Inferior 1 (process 106) exited with code 01]

Interestingly, strace shows a call to ptrace(PTRACE_TRACEME) which returns -1 EPERM (Operation not permitted) before the program exist. We’ll need to patch this if we want to debug the program.

The tracing error message is referenced from 0x08048613:

08048613         test       eax, eax
08048615         jns        EntryPoint+431
08048617         mov        dword [esp], aTracingIsNotAl                        ; "Tracing is not allowed... Bye!"
0804861e         call       printf+16

We can patch it and XOR eax before the JNS as in earlier crackmes, saving a new binary.

After reading the password, esp+0x15 contains our input (ending with a new line). A static buffer is also loaded before calling a procedure:

08048754         mov        dword [esp+4], 0x8049bb8
0804875c         lea        eax, dword [esp+0x15]
08048760         mov        dword [esp], eax
08048763         call       EntryPoint+554

0x8049bb8 contains: [0xf7, 0xf8, 0xf1, 0xf4, 0xf1, 0xf8, 0xb3, 0xfc, 0xfc, 0x00]. This is not a readable string.

The loop that follows goes over our input and calls 0x08048631 on each character before comparing the values to the array above. The code is slightly obfuscated with a few bytes inserted throughout the code, likely to confuse tools and prevent disassembly:

08048631         push       ebp
08048632         mov        ebp, esp
08048634         sub        esp, 0x4
08048637         mov        eax, dword [ebp+8]
0804863a         mov        byte [ebp-4], al
0804863d         movsx      eax, byte [ebp-4]
08048641         mov        dword [dword_8049c08], eax
08048646         jmp        EntryPoint+458
08048648         db  0xc9 ; '.'                         ; garbage
08048649         db  0x35 ; '5'                         ; garbage
0804864a         push       edx
0804864b         mov        edx, dword [dword_8049c08]
08048651         jmp        EntryPoint+469
08048653         db  0x08 ; '.'                         ; garbage
08048654         db  0x5a ; 'Z'                         ; garbage
08048655         or         edx, 0x90                   ; OR 0x90 on each byte
0804865b         mov        dword [dword_8049c08], edx
08048661         pop        edx
08048662         mov        eax, dword [dword_8049c08]
08048667         leave

We can reverse the OR by doing an AND ~0x90 on the array found above:

>>> ''.join(map(lambda c: chr(c & ~0x90), [0xf7, 0xf8, 0xf1, 0xf4, 0xf1, 0xf8, 0xb3, 0xfc, 0xfc]))
'ghadah#ll'

Let’s try it out:

$ ./crackme.02.32
Please tell me my password: ghadah#ll
The password is correct!
Congratulations!!!