How my shell mess with me

Last week I spent 2h instead of 20 minutes on stack overflow challenge because my payload has some strange values in the middle of jump address. I was impressed by this challenge, and how it managed to put some values between my bytes. Imagine my mood when I realized that it wasn't some special power of the program. It was my shell doing evil decoding behind the scene.

It all starts with a challenge. I'd got program with stack overflow vulnerability:

$ ./pwn1
Tell me your name: AAAA...AAAA
Hello, AAAA...AAAA
[1]    11870 segmentation fault (core dumped)  ./pwn1
$

And when I want to generate payload with value to overwrite return address it won't work. In gdb I notice that /my ret address wasn't what I intended it to be. It looks like this:

$ python3 -c "print('\x08\x03\xcd\x44')" | hex
0803c38d440a
$ 

Yep, bolded bytes are not mine 0803c38d440a. Should I blame python? Lets check:

$ echo "print('\x08\x03\xcd\x44')"
print(�D')
$ 

Ok, so Python has that bizarre string to process instead of what I expected:

$ echo '\x08\x03\xcd\x44'
\x08\x03\xcd\x44

So, shell (zsh) decode for me chars in command and pass it to python, which apparently does nothing new - just print that chars further. When I switch to /bin/dash everything was as I expected - no evil decoding. I don't make a decision if I should change zsh to another shell or just do not solve challenges in the shell - always write solutions in Python script. Maybe I leave things as they are and just check how much pain it will bring on me.

For the record, I solve this mystery one day after solving the challenge. So, how I eliminate those magic bytes from my ret address?

$ python3 -c 'print(138*"A"+"A\u0b44\u0004\u0008")' > pwn1_arg2

Yep, I found (by hand) encoded values which after decoding should give me my original bytes...

...SQUEAK!

Comments

Comments powered by Disqus