Skip to main content

ARM buffer overflow: chapter 1 ( ° ͜ʖ °) (day 58)



In this first post about buffer overflow in ARM, we are going to take a look at how to cause an overflow in the ARM binary and build an exploit in this specific architecture. To demonstrate the POC itself we are going to used source code from protostar and modified it a little bit to make it more interesting.

But before we are going to the juicy stuff let me tell you some little bit of background of the ARM architecture.

Background:

ARM is basically just another processor architecture like intel x86 and MIPS but unlike these two architectures, ARM machine becoming more and more common this day if you notice your phone is actually is using ARM architecture including router and not to mention IoT.

why ARM is chosen to be used in IoT (embedded technology) and mobile phone?

simple! ARM is a resource constraint and doesn't require a lot of CPU power to execute a task. ARM is a RISC (Reduced instruction set Computing) processor this means it has fewer instructions and more general-purpose register this is actually equivalent to More power but less resource to compute

Before you start :

I suggest you take a look at azeria-labs website to get the concept of the ARM assembly to follow this tutorial and if you are already familiar with memory corruption, you only need a couple of days to finish all of the materials.

Setting up the environment:

To do exploitation in ARM assembly of course we need to have an ARM machine. There are two ways you can accomplish this: first, you can buy a raspberry pi and install raspbian inside or the second approach is to use qemu emulator, follow this tutorial to set up your machine. If you successfully set up the qemu it will show like this.


Let's begin:


The vulnerable code will be like this. Basically is similar to the protostar challenge, you need to change the variable value to 1337


Compile the following source code with the following specification:

 

 Once it is done, let's loaded into our gdb:

~# gdb stack0
~# disassemble main


You don't need to care about the first three instructions since that is just a function prologue. This is just telling how the compiler set up the stack for the program to run so nothing interesting will come from there 

in the fourth instruction you can see that:

mov r3, #99

 

(put a breakpoint and examine the register before and after the assignment)


this is equivalent to the variable assignment in the modified variable so the value of 99 is going to be the first stored in r3 and then after it stored in r3 it will move again to the location of r11-8. remember str instruction is moved from left to right

 

(proceed to the next instruction and we can see that the r3 value is stored in the r11-8)



after the assignment of the modified variable, the next three instruction will used to set up the stack for the gets function 


Don't worry this is just basically just to set how long is the buffer that needs to take for the function input and then store the location of the size to the r0 register, in ARM storing value to r0 consider as the first parameter of the function.


Let's say we put some A char so we can easily spot the char input in the stack region.

 

Now, this is where the interesting part is coming together, remember that our value of the assigned "modified" variable is stored in the r11-8 and now it is loaded again to r3 and surprise surprise the value of "1337" that will be compared will be put to the r2 register.


 Let's take a look at how the stack is arranged 


Cool so our input is stored at 0xbeffef74 and the "modified" variable is stored at the 0xbeffefb4, since the program get the input using gets function that is commonly known as unsafe method we can just overflow the stack of the who holde the modified variable to become "1337".

simple math: 0xbeffefb4 - 0xbeffef74 => 64 offset for use to overwrite the variable

so create a python script like this:


(run it again in gdb as the input)



examine the stack region and wallaaaa we are able to replace the value of the variable.


(continue the execution again)


We also can use this payload outside the gdb :)


Cool :) we just get our first buffer overflow in ARM.

That's all folks! hope you enjoy this post see you in the next series
Labels:

Comments

Post a Comment

Popular posts from this blog

Having fun analyzing nginx log to find malicious attacker in the net (ง'̀-'́)ง (day 37)

  What makes you sleepless at night? is it because of a ghost or scary stories? is it because you have an important meeting tomorrow? or is it because you have an exam? For me, what keeps me up all night is that I keep thinking about what happens to a website that I just created, is it safe from an attacker (certainly not) or did I missing some security adjustments that lead to vulnerability? well I'm not the best secure programmer in the world, I'm still learning and there is a big possibility that I can make a mistake but for me, a mistake can be a valuable investment to myself or yourself to be better so from this idea, I want to know more about what attackers casually do when attacking a website. Here in this post, I'm going to show you how I analyzed attack to the website that I have permission to design and also some interesting findings that I could get from the analysis Background: All of this analysis comes from the traffic that is targeted to th...
Post a Comment
Read More »

Utilize Pwntools for crafting ROP chain :') (day 69)

who doesn't like pwntools? it is a very versatile tool and can be customized according to our need using the python script but did you need to know that pwntools itself can help us to automatically craft a rop chain for us? so in this post, I will show you how to make rop chain less painful and make pwntools do all the heavy lifting. To demonstrate this I will use the binary challenge callme 64 bit from ropemporium link: https://ropemporium.com/challenge/callme.html Crashing the app: Like any other exploitation process, we need to crash the program by generating a long string pattern to determine the offset. based on the information from the above figure we can see that we required to provide 40 bytes of offset Fun stuff: now this where the fun stuff began write the following python script: as in the guideline of the challenged said we need to chain the function call by first to call the callme_one function, callme_two function and then callme_three funct...
Post a Comment
Read More »

Bypassing stack canaries protection :') (day 51)

In my previous blogs, I show you guys how to bypass some common protection usually used in Linux binary such as NX and ASLR but this time we are going to take it to the next level we are going to talk about protection employ in the modern Linux OS which is "The Canaries" and how to bypass it. note: this post was not originally mined it was inspired by the following resources https://ctf-wiki.github.io/ctf-wiki/pwn/linux/mitigation/canary/ (Credit goes to the author) we are going to start this post about what is stack canaries and types of different implementation of it then move to the implementation about how to bypass this protection. We are going to focus on "leak canaries" technique What is stack canary: In layman terms, canaries are just another protection mechanism to prevent stack overflow implemented by appending 4/8 bytes value (depend on the architecture) into the stack when a function is entered. When the function is at the end of its exec...
Post a Comment
Read More »