Stack overflow for beginners - ARM

Preparing myself to the 'future research' I decided to read and learn more about ARM. Below you'll find few notes about it. Here we go...
Today we'll start here*:

(photo src)

(*As a 'practice') I decided that it will be nice to check how to exploit stack overflows bugs on ARM.

To do that I started building the lab (just like I did before). Unfortunately after many, many hours (of not reading the manual) I still wasn't able to install proper tools. :Z (Probably I did something wrong... anyway ;])

That's how I realised that there is already a known and "working VM" that I should try. So I got back to the Azeria Lab VM (thanks!). :) We now should be somewhere here downloading compiled files:

Let's move here to proceed:

(For obvious reasons we'll start from stack1 binary.) According to Azeria's web page - our goal is:

Let's check the source code to find the correct value:

But then: we'll continue with GDB (using GEF described before):

Pretty similar to the previous parts, isn't it? ;)

My next move was to set a breakpoint(s) on CMP instructions. Checking the first I wasn't able to get the proper value in any register. So I moved to the next cmp:

Next I used GEF (pattern create 100) to generate new string and restart our vulnerable program:

As the reader can see ($r2 and $r3 registers) we have some hints ;)

Restarting the program and checking again:

Great! We can move forward - directly to stack2 challenge. Here we go...

This time we'll talk about environments variables ;] Run stack2:

So far, so good. Checking the source of the challenge:

Our 'environment' is prepared so let's now open gdb and continue, starting the program:

This is pretty similar challenge to stack1 - this time we need to change the value of register using environment to exploit the  program. Let's try:

Looks like done again. :)

Let's check stack3:

Overwriting function pointers - sound cool, isn't it? ;D We'll see.

Let's find where is our win() function using gdb again:

To verify we can also use objdump (with -d stack3 | grep -e "<win"), like this:

In the meantime I decided to escape for a while from gdb and create 2nd file to restart stack3:

As you can see there is an overflow again (0x41414140). So far, so good. Knowing the length we can continue with 3rd input file:

Looks like it's done. Next one - stack4 challenge. Let's see how is it looks like:

Ok, let's try the same trick as we did for stack3:

Hm... let's try to add few more:

Looks good! :) Now we can move directly to stack5. We should be somewhere here:

Ok, let's try. I started gdb again and I used few input strings to check the program's behaviour:

Next step was to save the pattern to file and restart stack5 again:

Now the case was to find the correct pattern length in our input string to overflow the registers again:

Examining Memory ($sp register):

Ok, let's try again:

So far, so good. Checking memory again:

Looks better. :) Next:

So we can see that $pc register is overwritten by our B's. Next step - jump - let's find the address. Checking with new input file (f6):

First results:

(Yeah I know, I forgot to add breakpoint -> sigill ;] sorry my 2nd sleepless night... anyway. :))

As we can see ($sp) we landed. Let's restart it again - but first we'll use GEF (shellcode search arm /bin/sh) to locate the shellcode we'll use  in our new payload: 

Much better. ;] Checking 904:

We should be somewhere here...

... rewriting our payload again:

I think we need to correct our payload ;] Let's try:

Ok, looks good. :) I think now we'll do a little break.

Maybe you'll find it useful. 

Special thanks goes to to my Patreon: Daniel.

You are AWESOME! ;)

See you next time!


Cheers