0

I ran into a confusion about memory address issue during my experiment to practice CTF pwn questions.

I tried to find the start pointer address of a local array variable to insert shellcode with Radare2. But the obtained pointer address was different when it was run from python to use pwntool.

This background context is a bit complex. I created a simpler reproducible code and here ere are my questions.

I compiled this following code.

#include <stdio.h>

void main() {
    char buffer[300];
    printf("%x",buffer);
}

with this compile option.

gcc source.c -o vuln -fno-pie -no-pie -fno-stack-protector -z execstack -m32

When I run this program simply from my bash or Radare2, it will generate the address like 0xffffcb24.

But when I use Python to run the built binary with this following python code, the address is different and it was 0xffffc9f4.

import subprocess

subprocess.run("./vuln")

These experiments was on my Ubuntu environment with disabling ASLR.

I don't have any rational explanation on this difference. Could someone help me to understand these difference?

(Note: The address run from a different shell file was also different. I reckon this is not a Python specific problem)

kyasbal
  • 1,132
  • 3
  • 12
  • 27
  • `%p` is the correct `printf` format directive for printing a pointer value. Technically, you should also cast the corresponding argument to type `void *`. Making those corrections might or might not cause different output to be produced. – John Bollinger Mar 22 '22 at 15:15
  • Also, the return type of `main()` is `int`. It is at best non-standard to use `void`. – John Bollinger Mar 22 '22 at 15:19
  • 2
    A different environment may launch the code in a different way, with a different "wrapper". – Weather Vane Mar 22 '22 at 15:20
  • 2
    adding to that: the environment variables and arguments are stored on the stack, if this is Linux – user253751 Mar 22 '22 at 15:22
  • My first guess as to an actual explanation for the reported differences would be that you are mistaken about ASLR being disabled, though I might revise that if printing the pointers correctly still showed their addresses being so close together. – John Bollinger Mar 22 '22 at 15:23
  • Thank you for your comments. Let me clarify a little bit. I compiled the binary just one time. And binary was executed from the different way. The output is always `0xffffcb24` when I run it from bash or Radare2. The output is always `0xffffc9f4` when I run it from Python. The output is also different when I run it from bash file. It is not clearly a problem in C code. But this is about memory placement problem implicitly done by operation system. – kyasbal Mar 22 '22 at 15:25
  • @user253751Thank you for your comment. Yeah, this could be good explanation. I will confirm it later. – kyasbal Mar 22 '22 at 15:28
  • @user253751 I confirmed your theory is right. I've modified the python code to this following code. ``` import subprocess subprocess.run("./vuln",env={}) ``` And these commands shows the same results. ``` $python ./exploit.py 0xffffdd34 $ env - ./vuln 0xffffdd34 ``` Both process should receive the empty environment variable. And in this case, these program could show the same result. I think your theory was proved. – kyasbal Mar 23 '22 at 13:04

0 Answers0