I managed through most of this on my own. I have two exploits written for this challenge: One which is mine and the other which I copied from a youtube walkthrough https://www.youtube.com/watch?v=i_5VQF18suQ
PwnShop Challenge in ‘Intro to Binary Exploitation’ Track
I have developed an exploit for this challenge that should call ‘system’ from libc with ‘/bin/sh’ as an argument. The problem is that the program crashes within the system function. I found the offsets for “system” and “/bin/sh” with the following:
system:
/bin/sh:
I am able to trace the program with GDB, and verify that system is being called with the ‘/bin/sh’ argument. This is the top of the stack before poping argument into rdi:
After pop rdi:
Stepping into ‘system’:
SIGSEGV:
I have no idea where to go from here as far as diagnosing the problem. I’d be more than happy to share my code. This is the core dump from my code:
90 commands loaded and 5 functions added for GDB 12.1 in 0.00ms using Python engine 3.10
[New LWP 7306]
[*] Failed to find objfile or not a valid file format: [Errno 2] No such file or directory: ‘system-supplied DSO at 0x7ffff7fc9000’
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007ffff7e12013 in ?? ()
I get what looks to be the exact same error when running the code from the afformentioned youtube video. I have that code as well.
Core dump shows:
90 commands loaded and 5 functions added for GDB 12.1 in 0.00ms using Python engine 3.10
[New LWP 47205]
[*] Failed to find objfile or not a valid file format: [Errno 2] No such file or directory: ‘system-supplied DSO at 0x155555520000’
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000155555369013 in ?? ()
I used the following template for each exploit:
pwn template ./pwnshop > exploit.py
I run the python exploits with:
python exploit.py LOCAL NOASLR GDB DEBUG
EDIT*
“<do_system+339> movaps XMMWORD PTR [rsp+0x50], xmm0”.
The binary crashing at this assembly instruction indicates an issue with stack alignment. I’m still doing research on this to understand it more.
The work around is to align the stack with another ROP gadget. If anyone sees this and has the same issue, look for a “ret” instruction offset via ROPgadget.py, then add that to your ROP chain. I placed it between the “/bin/sh” argument and libc_system. Worked like a charm.