1

I started my adventure with reverse engineering but I have some problems which I can't solve from the very beginning. I'm following tutorials on YT and I meet some differences. So, when I work with this code from the tutorial:

#include <stdio.h>
#include <string.h>

int main(int argc, char** argv)
{
    char buffer[500];
    strcpy(buffer, argv[1]);

    return 0;
}

I should get disassembly result as the guy from the tutorial: expected result

But when I compile my program on a 32bit virtual machine withgcc -g -z execstack -fno-stack-protector and get result like this:enter image description here

When I compile the same same cod on 64bit virtual machine with gcc -g -z execstack -fno-stack-protector -m32 I get the same result. However if I compile it with gcc -g -z execstack -fno-stack-protector I get something like this:enter image description here

So it looks like the screenshot from the tutorial but it's 64bit version. So my question is, am I doing something wrong or I shoulg change something? I don't know if I should learn working with 64bit system or find a way to repair 32bit one. Anyone can help me?

Shirakumo
  • 182
  • 1
  • 1
  • 10
  • Try with `-no-pie` – Havenard Nov 12 '18 at 18:56
  • That call to `get_pc_thunk` tells it's position independent code [according to this answer](https://stackoverflow.com/questions/6679846/what-is-i686-get-pc-thunk-bx-why-do-we-need-this-call), so it might be the case why it is different. Disabling this feature at the compiler with `-no-pie` might make them look more alike. Also, the optimizer works in mysterious ways, disabling it with `-O0` may also help you recognize your code once it gets transformed in assembly. – Havenard Nov 12 '18 at 19:00
  • But as you know my previous question, may it be the case why my payload doesn't work? Or it's just an appearance and has nothing to do with a shellcode and memory? – Shirakumo Nov 12 '18 at 19:03
  • As long as `eip`/`rip` overwrite the `ret` address of the function by the address of the shellcode or any of the `\x90` before it, the shellcode should work. – Havenard Nov 12 '18 at 19:05
  • The `ret` address of the function, in any function implemented using `__cdecl` (default calling convention of the C language) is at the address `ebp-4` (32-bit) or `rbp-8` (64-bit). – Havenard Nov 12 '18 at 19:07
  • *to the callee, after it's done with the function prologue. – Havenard Nov 12 '18 at 19:11
  • I give up, I have no idea why it doesn't work on my 32bit system... – Shirakumo Nov 12 '18 at 20:01
  • I can tell that the first attempt you made it was working, the only problem is that the shellcode didn't have enough stack space after it to run thoroughly. I know that because of the address where it crashed, it crashed halfway through the shellcode execution. – Havenard Nov 12 '18 at 20:19
  • So I don't understand, what am I doing wrong? – Shirakumo Nov 12 '18 at 20:43

1 Answers1

0

You don't need two different virtual machines for x86 and x64, just make one for x64 and you can execute both x86 and x64 binaries.

You may want to find tutorials which provide the binaries, so you don't have to mess with compiler flags. The reason the assembly is different is because of different compiler versions and settings. You can try to disable optimizations but sometimes it's a waste of time, better to find a tutorial that provides the binaries.

Your exploit must be tailored to your binary, not the different binary from tutorial.

Most notably in your example, the size of the local stack frame is 0x200 in your second screenshot, but in the original screenshot it's 0x1F4.

You need to align your shellcode to match the layout of the enlarged stack frame.

Use the trial and error method of writing 'aaaaaaaaaaaaaaaaaaa' of various lengths and checking the memory to see where it landed

GuidedHacking
  • 3,628
  • 1
  • 9
  • 59