Rating: 0

# Pwn - EmojiiiVM

See [part1](
) for VM structure and [part2](
) for programming hints.

The goal here is to pwn the good old EmojiVM. During reversing, the major
problem that stood out was that only `PUSH` and `POP` had explicit overflow and
underflow checks - all the other commands can confidently reach below the stack.
The other problems: lack of trailing `\0` checks in a few places and the ability
to jump outside of the loaded program pale in comparison.

So we can breach the bottom of the stack by doing an `ADD` and then dig deeper
using `POP`, since the latter merely does an equality comparison. What do we
have before the stack anyway?

.got:000000000020DDF8 strlen_ptr dq offset strlen
.data:000000000020E008 dso_handle dq offset dso_handle
.bss:000000000020E040 stderr dq ?
.bss:000000000020E180 emoji_code_table db 40h dup(?)
.bss:000000000020E1C0 emoji_data_table db 40h dup(?)
.bss:000000000020E200 gptrs dq 0Ah dup(?)
.bss:000000000020E260 stack dq 400h dup(?)

Sweet - `gptrs`, which we can thus control, `libc` pointer and self pointer in
case we have a bone to pick with ASLR, and, last but not least, GOT.

By the way, in part 2 the bytecode we submitted could not read from stdin. This
is not the case here: we can exchange information with it and assist it when
e.g. its math capabilities are strained.

First attempt: overwrite `strlen` GOT entry with `system` and trigger
`strlen("/bin/sh")` call by using code `0x14` which does the following:

v5 = gptrs[a1];
v3 = strlen(*(const char **)(v5 + 8));
return write(1, *(const void **)(v5 + 8), v3);

So, `ADD`, `POP` until `stderr`, `PRINT_QWORD` (for sanity checking), `POP`
until `strlen_ptr`, `PRINT_QWORD` again, `ADD` delta between `system` and
`strlen`, `PRINT_GPTR`, done.

What do you mean, `Segmentation fault`? Turns out it pays off to run `checksec`
every now and then:

$ checksec emojivm
[*] 'emojivm'
Arch: amd64-64-little
Stack: Canary found
NX: NX enabled
PIE: PIE enabled

[Full RELRO](
), goddamnit! So we have to exploit the heap though `gptrs` corruption, aren't
we? Time to study https://github.com/shellphish/how2heap! But first, let's see
what kind of corruptions we can trigger.

Each gptr consists of 2 allocations: 16 bytes for length + pointer metadata, and
as many bytes as we want for the data. If we allocate 10 gptrs containing 15
bytes of data (EmojiVM will add one byte for the trailing zero, making it 16),
all 20 allocated buffers will line up one after the other quite predictably.

* Double free. Add `0x40` to any data pointer to make it equal to the next one,
and then deallocate the two corresponding gptrs.
* Use after free. Subtract `0x20` from a metadata pointer to make it equal to
the previous data pointer, then free the corresponding gptr. Since after
subtraction it will point to all zeroes, freeing the associated data will be
a no-op. Writing to the previous gptr will overwrite the free chunk.

Actually, that's enough for [tcache poisoning](
). Here is the plan:

* `ALLOC` x10.
* `ST` the string `sh` into `gptrs[0]` (we have to conserve space, only 1000
bytes this time).
* `ADD []`: breach the stack bottom.
* `POP` until `gptrs[9]`.
* `SUB [0]`: negate the pointer value.
* `ADD [32]`.
* `SUB [0]`: we'll end up with `gptrs[9] - 0x20`. The whole dance was necessary
because we could subtract the pointer value from something, but not something
from pointer value due to the way the memory is laid out.
* `FREE GPTR [9]`.
* `POP` until `stderr`.
* `PRINT_QWORD`: the remote part will read this and compute `__free_hook`
address for us. Actually it's not a problem to compute this address on the
EmojiVM side, but then there is no way to load it into gptr.
* `INPUT [8]`: load `__free_hook` address into the free chunk, poisoning tcache.
* `ALLOC`: this will allocate gptr in the last slot, which we previously freed.
Due to the way tcache poisoning works, the first allocation will return a
normal healthy chunk, and it will be happily used for gptr metadata. The
second allocation though will return a poisoned chunk, that is, `__free_hook`
address. So now we can write into `__free_hook` via newly allocated gptr.
* `INPUT [9]`: load `system` address into `__free_hook`.
* `FREE [0]`: remember that `sh` string we wrote at the beginning? This will be
now freed, but first it will be passed to `__free_hook`, that is, `system`,
with a predictable result.

The shell obtained this way allows us to look around on the server and find a