--- ### Challenge Description For the extreme-level challenge, submit your walkthrough (or link to it) as well as the solution. The judges will review submissions daily. Good luck! --- ### Summary In this challenge, the focus is on reverse engineering a binary with anti-disassembly and anti-debugging measures. The first task involves patching the binary to remove these obfuscations, enabling proper analysis. The second task modifies the binary's assembly code to decrypt an embedded flag rather than encrypting input. Once patched, the binary enters an infinite loop, providing an opportunity to attach a debugger and extract the decrypted flag from the stack. The EDB debugger is used to successfully obtain the flag. --- ### Patch the Anti-Assembly It seems there are some anti-disassembly techniques used in this binary. In order to understand the assembly of the code, it's imperative we patch the binary to remove the anti-disassembly. Here's an except of the code from Ida Pro (starts at address `0x40133D`): ![[images/Pasted image 20230904203257.png]] The challenge author added the bytecode for `call` to the start of each of the highlighted lines. In order to see the correct disassembly, we need to patch the binary. Lets start with the top function call. Click on `3B6F2Ah`, then: Edit --> Patch Program --> Change Bytes ![[images/Pasted image 20230904203705.png]] Notice how there are two `e8`'s? This is executing the `call` instruction twice. The first call is the anti-disassembly, the second call is a legit call. Change the first `e8` to a `90` (NOP). Follow these steps for the other two highlighted sections above. --- ### Patch the Encryption After doing some research on RC4, I discovered that encrypting a RC4 encrypted string is the equivalent of decrypting it, due to the nature of the xor function. We need to adjust the assembly code to utilize the encrypted flag array, so that the program decrypts the flag rather than encrypting our input, mirroring the approach in the Windows RE Extreme challenge. First, we need to find the location of the flag in the program. The function that calls the rc4 encryption is at address `0x400F82`. In IDA Pro, hit "g", then jump to that address: ![[images/Pasted image 20230904204603.png]] Looks like we have some more anti-assembly. Using the steps above, patch out the two highlighted calls: ![[images/Pasted image 20230904205019.png]] After analyzing the output, the binary seems to be putting the encrypted flag bytes at offsets of `[rbp-60h]`: ![[images/Pasted image 20230904205335.png]] This leads me to believe the flag is at `[rbp-60h]`. Patch the program so that the encrypted flag is used, instead of the user input: ![[images/Pasted image 20230904205548.png]] Change the bytes using IDA's Patch Bytes option. Click on `[rbp-30h]`, then hit Edit --> Patch Program --> Change Bytes: ![[images/Pasted image 20230904205800.png]] Change `DO` to `A0`. This changes the `rbp` offset to `-60h`. Verify your output at memory address `0x40125D` looks like this: ![[images/Pasted image 20230904210014.png]] Sadly, there are anti-debugging techniques embedded in the `rc4_pgra` function, at line 15-16: ![[images/Pasted image 20230904210416.png]] In order to bypass the `SIGTRAP` errors, we need to patch the binary in a special way. Once the binary completes the RC4 decryption, we want to force the binary to continue running, until we tell it to stop. This is helpful so we can avoid the `SIGTRAP` errors, but still attach a debugger to the running program, and read the flag from the stack. First, apply the following patches IMMEDIATELY following the completion of the RC4 decryption function: Click memory address `0x401378`, then Edit --> Patch Program --> Change Bytes: ![[images/Pasted image 20230904211138.png]] Your disassembly should look something like this: ![[images/Pasted image 20230904211411.png]] Notice the white arrow? The program will jump to `0x40137D` forever, until it's terminated. This gives us time to attach to a debugger, and view the flag. ### Debug the Patched Program First, run the patched program: ![[images/Pasted image 20230904211859.png]] Notice how the program is still running. Now is the perfect time to attach with a debugger. Install and run `edb` ```bash sudo apt install edb-debugger edb ``` Hit File --> Attach ![[images/Pasted image 20230904212137.png]] Select your patched binary. The cleartext flag is in the stack: ![[images/Pasted image 20230904212235.png]] Flag: `flag_{6a69dcc80f6340fba29688d82a341e8a}`