popping around shell
Shellcode with some limitation
Problem
Solution
Analysis
Given a binary shell.out, the first thing we will do is to check the binary type and its security implementation.
basic analysis summary:
x64 least-bit ELF binary
dynamically linked, so it’ll depend on system library
stripped, means function and variable name from the source code is not carried
Full RELRO, means that the GOT entry table is not writable
No Stack Canary, means no additional checks if the stack is overflown
NX enabled, means the stack is not executable
No PIE, means base address is hard-coded and not randomized
The primary objective of this challenge is to navigate around limitations rather than pinpointing a vulnerability and taking advantage of it.
By examining the decompiled code in ghidra, we observe that the binary receives input data, saves it into a variable and tries to execute it as a function. If we can supply functional shellcode to the binary, it should spawn a shell for us.
we can potentially use asm(shellcraft.sh()), which ends up with 48 bytes of shellcode thus exceeding our input. It appears that we will need to create our own shellcode, which is likely the intended solution according to the author.
So let’s discuss what our goal is, to spawn a shell we want to call execve('/bin/sh') that is, a syscall that requires the following registers to be equal to a specific value accordingly:
$RAX = 0x3b
$RDI = a pointer to ‘/bin/sh’ string
$RSI = 0x0
$RDX = 0x0
to read more about this you can follow this link:
Thankfully, the author is nice enough to include the string within the binary, we can use ghidra to search for strings and we’ll find the address to it and because PIE is not enabled, we can simply point to it without worrying about address randomization.
Exploitation
to save up memory so we’ll use the 32-bit registers to make the syscall shorter. Below is the setup to register in assembly
Flag
flag{shell_is_just_\xff\d9}
Last updated