Category: Pwn
The task:
Following ARM’s success, I went ahead and designed my own RISC assembly language. I wrote a simulator, so you’ll be able to run your own programs and enjoy the (very) reduced instruction set! Of course, with such minimal implementation, reading the flag is impossible.
In this challenge, we were given a simulator with a reduced instruction set & 32bit processor. The source code of the simulator was also provided.
There is a ‘stub’(aka the admin code) which is always executed at the end. It prints the flag only if a certain condition is satisfied. The condition is quite trickey, and requires us to break some of the processor’s implementation rules if we want to read the flag.
Analysis
Available registers
Looking at ./inc/asm_processor_state.h, we can see a list of available “ARM-like” registers, stored in the .bss
segment:
The simulator contains the following registers:
ZERO
register: Always contains zero, this is used for calculation purposes when the number zero is needed.R0
…R6
registers: Common ARM registers. In this simulator, they are general purpose.SP
register: used as a stack pointer. Changes whenever we’re PUSHing and POPing from the stack.
The Instructions set
The opcodes for the instruction set are found at ./inc/asm_instructions.h
There are common instructions, such as ADD
, MUL
, SUB
, etc.
Every arithmetic operation has a corresponding immediate “version”, such as: ADDI
, MULI
, SUBI
, etc.
Immediate Operands: In addition to register operations, ARM instructions can use constant or immediate operands. These constants are called immediates, because their values are immediately available from the instruction and do not require a register or memory access.
Besides that, there are also custom instructions implemented, such as:
PRINTNL
(snippet) - printing a newlinePUSHCTX
(snippet) - push a “state snapshot”(==context) of the registers into the stackPOPCTX
(snippet) - pop a context from the stack onto the registers- More printing instructions such as
PRINTDD
(print decimal),PRINTC
(print a character) andPRINTDX
(print hex) are also available.
Validations / checks
To define the opcodes, the program implements a series of nasty, C, multi-line macros.
During execution, those macros are triggering validations, such as:
- The program validates that we cannot exceed that stack limit (snippet)
- During a write operation, it also validates that we cannot write to the
ZERO
register (snippet) - The program also has handlers for division by zero / weird edge cases. But this is less relevant for this writeup.
Time to pwn
After we covered the basics of the simulator, it’s time to dig into main()
.
During startup, the program:
- Generates an ‘admin shellcode’ that prints the flag(we will look at it soon) - snippet
- Gets a shellcode input from the user - snippet
- Appending the admin shellcode to the end of the user’s shellcode - snippet
- Parse the final shellcode(user code, followed by admin code) and start execution - snippet
The admin code
The admin code is generating a bytecode that perform the following check(snippet):
Which basically means:
// If the user sets R0 so (R0 * 42) == 1 (impossible!), she deserves to read the flag
ADDI R1, ZERO, 42
MUL R2, R0, R1
SUBI R2, R2, 1
RETNZ R2 // if R2 is not zero, return and don't print the flag
After taking a closer look at it, this is not (R0 * 42) == 1
, but rather (R0 * (42+ZERO)) == 1
.
Those instructions are executed after the user’s bytecode is executed. Meaning that our “entry point” here will be using the R0
register. If we can make (R0 * (42+ZERO)) == 1
to be true: the admin shellcode will print out the flag, 4 bytes at a time(since this is a 32bit processor).
The following snippet shows how the admin code prints the flag:
To solve this, we will need to replace the ZERO
register with the value -41
and R0
with the value 1
(more about it is described in ‘Solution’).
The problem is, as mentioned earlier, the simulator checks whenever we are trying to replace the contents of the ZERO
register during write operation and throws a E_W2ZERO
error code. We will have to overcome this obstacle.
Solution
When saving and restoring the registers ‘snapshot’/context(part of a POPCTX
and PUSHCTX
instruction), the simulator also includes the contents of the ZERO
register as part of the context structure:
This allows us to create a specially-crafted register context structure and overwrite the ZERO
register value. To do this, we need to:
- Perform a
SUBI R0, 41
to set theR0
register to-41
- Perform a
PUSHCTX
to push the registers context - Execute a
PUSH 0
instruction to corrupt the context structure alignment - Perform a
POPCTX
, which will overwrite the theZERO
register with-41
(previously, this was the value ofR0
but the whole structure shifted by 4 bytes in memory once we did an extraPUSH
in step 3)
The payload generation code for this is below(./solve-dir/build_pwn.c):
gdb output after this user payload was executed:
(gdb) p registers
$16 = {-41, 1, 0, 0, 0, 0, 0, 0, 0}
It worked! the ZERO
register is -41
, and R0
is 1.
Now, if we look at the admin code again:
ADDI R1, ZERO, 42
MUL R2, R0, R1
SUBI R2, R2, 1
RETNZ R2 // if R2 is not zero, return and don't print the flag
The result will be 0 and the program won’t return too early (==our flag will be printed out).
Let’s try to launch the shellcode on the target host:
The flag was printed! but it’s a little bit, well, messy.
This is happening because we corrupted the ZERO
register with the value -41
. The admin code uses this register to print out the flag when iterating through the characters of the flag with the ROR
instruction.
To overcome this, I added a small python script that will add +41
on every 32bit rotation.
The final exploit is below (solve.py):
output:
$ python3 solve.py
[+] Opening connection to 127.0.0.1 on port 9020: Done
3
flag{ahh_got_it}
Thanks for the challenge :D