Monthly Archives: October 2019

Root-Me: GB – Basic GameBoy crackme walkthrough

Hello,

In this article I will describe how I solved the GB – Basic GameBoy crackme challenge from Root-Me.

Before reading this article you should attempt to solve the challenge on your own. Start by reading/skimming through the GameBoy CPU manual then download an emulator such as mGba and play with the ROM. To disassemble the ROM I’ve used Ghidra and mgbdis.


After reading through the GameBoy CPU manual, I’ve opened the file in Ghidra and found these interesting strings:

If you emulate the ROM using mGba and press the Left key then the Enter key, the message “Left” will appear on the screen, for the moment I can assume that the strings are related to the message.

Ghidra doesn’t know about the GameBoy ROM structure and I don’t know either, so I’ve tried to disassemble the ROM with the help of a specialized GameBoy disassembler:

➜  mgbdis git:(master) ✗ ./mgbdis.py crack_rom.gb 
Loading "crack_rom.gb"...
ROM MD5 hash: 51ff0d38b93107c38a753d9b0ee1576c
Generating labels...
Generating disassembly..
Disassembly generated in "/home/denis/Downloads/mgbdis/disassembly"

By opening the output of the disassembler and searching for 0459 (the address of the Nope string) I’ve found code that references it at 0415.

I went back to Ghidra and disassembled the block at 0415 by pressing the D key.

This seems to be the block that checks some values from RAM and prints the flag if the values are correct.

The first comparison is done for the Left key. It loads the value from the RAM address 0xc0b0 into the A register.

The A register is then compared to 0x32 and there’s a conditional jump to the NopeBlock. JP NZ,NN ;jumps if Z is reset

                             LAB_ram_03c0                   
        ram:03c0 11 b0 c0        LD         DE,0xc0b0
        ram:03c3 1a              LD         A,(DE=>DAT_ram_c0b0)
        ram:03c4 4f              LD         C,A
        ram:03c5 fe 32           CP         0x32
        ram:03c7 c2 15 04        JP         NZ,NopeBlock
        ram:03ca 18 03           JR         LAB_ram_03cf
        ram:03cc c3 15 04        JP         NopeBlock

CP is a subtraction from A that doesn't update A, only the flags it would have set/reset if it really was subtracted. If A == N, then Z flag is set.

So if A = 0x32 then Z is set and the jump to NopeBlock only happens if Z is reset. Sounds easy to me. To pass the check the value at 0xc0b0 needs to be 0x32.

If we look at the memory view in the mGba emulator, the location at 0xc0b0 has the value 0x39. If we press the Left key the value is decremented.

To get the flag you must solve for the Up, Down and Right keys.

Thanks for reading! ❤

Ghidra Scripting: Annotating Linux system calls

I had some fun this weekend messing around with Ghidra. Having such a powerful tool for free is truly a game changer.

To start scripting in Ghidra, I downloaded the latest Eclipse for Java Developers Version: 2019-09 R (4.13.0), Ghidra and Open JDK, I believe any JDK version 11+ will work.

After downloading the JDK, extract the zip, put it somewhere and modify your PATH and JAVA_HOME environment variables to point to it:

export JAVA_HOME="/home/denis/jdk-13"
export PATH="/home/denis/jdk-13/bin:$PATH"

Next, you should start Ghidra in order to associate the JDK with it, now close it, then start Eclipse. In Eclipse, install the GhidraDev extension from the archive which is found in ghidra_9.1-BETA_DEV/Extensions/Eclipse.

After installing GhidraDev, you may now create a new Ghidra Scripts project.

This is cool because all your scripts are stored in ~/ghidra_scripts and linked to the project, if you change the JDK you may safely delete the project and recreate it without losing files.

If you click Run or Debug, Eclipse will be prompted to start a new Ghidra or Ghidra Headless instance, by clicking Debug, you can set breakpoints in the scripts you want to Debug. Run the scripts by opening Ghidra’s Script Manager and clicking Run. When the code reaches the breakpoints, the script’s execution will stop and you can debug it in Eclipse.

You can then resume the script, cancel it from Ghidra or modify the script without having to restart Ghidra. If you hit the stop button Ghidra will shut down, I’ve encountered some popups complaining that hot code replacement won’t work when I tried to save a script, I ignored it and it worked just fine.

By opening Ghidra Script Manager and right clicking on a script then clicking on Ghidra API Help will open a web browser with the scripting documentation.


To make my script I started with InstructionSearchScript.java as a base, iterated through all instructions, saved the value of EAX, searched for int 0x80 and added a plate comment with the system call’s name.

The final script:

https://github.com/dnutiu/GhidraScripts/blob/master/CommentLinuxSysCall.java

Please note the ugly systemCallNames.put(1, "sys_exit");, I haven’t used Java that much and I couldn’t find a good way to initialize maps in an inline statement. If you have a suggestion please write it in the comments.

To get the system calls names I used a reference table from Shell Storm and some JavaScript to parse the table.

table = document.getElementsByTagName("table")[0];
tableRows = table.children[0].children;

// for each tableRows starting from 1 skip header
for (index = 1; index < tableRows.length; index++) {
    rowData = tableRows[index].children;
    syscallValue = rowData[0].innerText;
    syscallName = rowData[1].innerText;
    console.log(`systemCallNames.put(${syscallValue}, "${syscallName}");`)
}

Running the script on a binary will annotate the system calls it finds by adding a plate comment.


In conclusion, creating my first Ghidra script wasn’t that hard and once I’ve figured out how to setup Eclipse and link it properly the development experience was a bliss. I hope more and more people will adopt Ghidra and contribute to it. Some Ghidra trainings and exercises can be found in ghidra_9.1-BETA_DEV/docs.

Thanks for reading and have a great day!

Root Me – Xor Madness – Walkthrough

Hello,

In this article I will describe how I solved the PE x86 – Xor Madness challenge from Root-Me

This challenge will ask you for a password and the password is also used to validate the flag. What makes this challenge interesting is that it only uses xorsubcall and ret.

Here’s how I approached the challenge:

  • Since the binary had a few function and some strings were in plain text, I tried to figure out the big picture and labeled all the function accordingly: winlosecheck and so on.
  • I’ve figured out that there are 6 stages, each stage tries to process a part of the password. The start function is also a stage and other stages are similar.
  • Next, I’ve spend a few hours debugging this challenge and documenting everything it does in order to see what it wants.

To solve this challenge you need to know how the XOR operation works, please check that you know this before moving forward.

The behaviour of the challenge is simple, it computes an addr, let’s call this address SOLADDR, and it makes it point to the value 1. [SOLADDR] = 1.

It takes a byte of the password you’ve gave and XORs it two times. The resulting value will be an address, we can call it PASSADDR. The trick is to look at how your password is XORed and make it equal to SOLADDR.

The function that will let you proceed to the next stage only does so when the location pointed to by PASSADDR has the value 1 assigned to it. This is stored into edx. edx = [PASSADDR].

The following function lets you proceed to the next stage if and only if EDX is 1:

weird_ret_addr_change proc near

arg2_next_stage_address= dword ptr  4

xor     eax, eax
xor     eax, [esp+arg2_next_stage_address]
sub     eax, [esp+0]    ; subtract return address from EAX
mul     dl              ; multiply eax with DL. Lower part of EDX
add     eax, [esp+0]    ; add back the return address
xor     ecx, ecx        ; reset ecx
xor     ecx, [esp+0]    ; set ecx to [esp]
xor     [esp+0], ecx    ; reset [esp]; [esp] = 0
xor     [esp+0], eax    ; set [esp] to eax
retn    4

We already know that EDX is set to [PASSADDR], which is EDX = *PASSADDR. Each stages performs this step.


In the main function, scanf scans for a maximum 63 characters (don’t trust anything you read, verify!) and stores the result in EDI, then it moved it into ESI and gets the first byte of the password_input into EBX.

call    ds:scanf        
xor     esp, esp
xor     esp, edi
xor     esi, esi
xor     esi, esp
xor     edi, edi
xor     edi, esi
sub     esp, 100h
xor     ebx, ebx
xor     bl, [esi] ; ebx contains the first byte of the password

EBX is then xored with a value, the first 3 bytes are just for show, we only care about the resulting last byte.

   xor     ebx, 59307554h  ; ebx contains first byte
.text:004010C0                                         ;
.text:004010C0                                         ; Example:
.text:004010C0                                         ;
                                                       ;  in     xor     res
.text:004010C0                                         ; 0x30 ^ 0x54 -> 0x64 test case
.text:004010C0                                         ; 0x6C ^ 0x54 -> 0x38 attempt1
.text:004010C0                                         ; 0x24 ^ 0x54 -> 0x70 attempt2 - success
.text:004010C0                                         ;
.text:004010C0                                         ; The First Xor

The next operations loads ESP into EBX, XORs them with the last resulting byte from the previous operation and saves it somewhere.

.text:004010D0                 xor     eax, esp        ; eax = 0x0019FD74 
.text:004010D2                 xor     eax, ebx        ; eax is now xored with the our byte 0x64 (res)
.text:004010D2                                         ;
.text:004010D2                                         ; 0x0019FD74 ^ 0x64 = 0x0019FD10
.text:004010D2                                         ; the resulting address is used when setting EDX
.text:004010D2                                         ; in this case it is invalid, the correct address is
.text:004010D2                                         ; === 0x0019FD04
.text:004010D4                 xor     edx, edx 
.text:004010D6                 xor     edx, eax        ; edx = 0x0019FD10 (Addr resulting our xored byte)
.text:004010D8                 xor     ecx, ecx        ; ecx = 0
.text:004010DA                 xor     ecx, [eax]      ; try to get value from [eax]
.text:004010DA                            
.text:004010DC                 xor     [eax], ecx      ; [EAX] = 0xFFFFFFFE
.text:004010DC                                         ; eax = 0

Note that EDX now contains the address that we control 19FD10, which we can call PASSADDR. We obtained 19FD10 after running the program and giving it 0 as the input.

The next piece of code computes the SOLADDR by XORing ESP with two hardcoded values and makes it point to the value of 1.

.text:004010E0                 xor     eax, esp        ; esp = 0x0019FD74
.text:004010E2                 xor     eax, 0F2h       ; 0x0019FD74 ^ 0xF2 = 0x0019FD86
.text:004010E7                 xor     eax, 82h        ; 0x0019FD86 ^ 0x82 = 0x0019FD04
.text:004010EC                 xor     ecx, ecx        ; ecx = 0
.text:004010EE                 xor     ecx, [eax]      ; ecx = *(0x0019FD04) 
.text:004010F0                 xor     [eax], ecx      ; [eax] = [eax] ; eax = 0
.text:004010F2                 xor     byte ptr [eax], 1 [eax] = 1

Now, the code assigns the value pointed by PASSADDR to EDX. EDX = [PASSADDR].

.text:004010F5                 xor     eax, eax        ; eax = 0
.text:004010F7                 xor     eax, edx        ; eax = 0x0019FD10; edx is set above; PASSADDR
.text:004010F9                 xor     edx, edx        ; edx = 0
.text:004010FB                 xor     edx, [eax]      ; edx = [0x0019FD10]; edx = [PASSADDR]

This is the only information you need to know to solve this challenge. You can now find the password by statically analyzing the next stages.

Thanks for reading!