Buffer Overflow Prep Walkthrough

Faizan Ahmad Wani
6 min readJan 23, 2021

--

Room: https://tryhackme.com/room/bufferoverflowprep

  1. Setting up the environment: I deployed the machine and the IP assigned was 10.10.153.10. Boom so lets dive in via RDP.

2. The Immunity Debugger was to be ran as admin and simultaneously I opened up OSCP.exe in it just to attach the process.(All files were present on the desktop).

3. The binary will open in a “paused” state, so click the red play icon or choose Debug -> Run. In a terminal window, the oscp.exe binary should be running, and tells us that it is listening on port 1337. Simultaneously I tried to connect via nc just to make sure everything's up and fine.

4. To check out whether the function OVERFLOW1 was really exploitable, I used the Tib3rius script, and punched in the macine Ip, port and the function parameter chose the overflow characters to be A, you can choose yours which got repeated in additives of 100.

5. Meanwhile I configured Mona,which was preinstalled; inorder to set the working folder.

6. Fuzzing —Lets run our script with proper parameters.

It stopped at 2000 bytes, indicating a crash, so it was obvious the offset was somewhere in between 1900–2000

7. Now lets generate a cyclic pattern to help us identify the exact value of the offset.I used the metasploit’s inbuilt pattern create ruby program. Keeping the length greater than that which crashed the server.

/usr/share/metasploit-framework/tools/exploit/pattern_create.rb -l <length>

8. This value needs to go into payload now of the precious exploit.py script :)

9. Firing it- We see again an access violation in the immunity debugger-indicating a crash.

10. Using MONA we can find the offset value now !mona findmsp -distance 2300

11.So now we know the offset value and we can confirm this again by seeting in an offset value in the script and directy firing a retn address to be reflected.

12. We can see our EIP is now written with 43434343 — meaning the letter C

13. Now we need to find the BADCHARS- For which we create BADCHARS, on set inside the machine using MONA and another by just googling or using a python script.By default \x00 is considered as a BADCHAR so it is to be neglected for sure. This helps us to identify the characters which are really BAD for our program!

Generate a bytearray using mona, and exclude the null byte (\x00) by default.

!mona bytearray -b "\x00"

14. Now on Local Machine generate a string of bad chars that is identical to the bytearray. The following python script can be used to generate a string of bad chars from \x01 to \xff — I am using this script and named it as badchars.py

from __future__ import print_functionfor x in range(1, 256):
print("\\x" + "{:02x}".format(x), end='')
print()

15. We need to send these BADCHARS to our oscp.exe so yes, these should go directly in the payload param of our exploit.py

16. Lets execute it.

17. Lets view our ESP HEXDUMP now, to see what really happened to the CHARS we generated

18. We can see dome characters are not present which are bad — so to automate finding them I used mona compare function. The address is that of the ESP register

!mona compare -f C:\mona\oscp\bytearray.bin -a <address>

19. Now we have our BADCHARS and now we need to isolate them one by one and iterate the process of generating a custom shellcode unless we get our address unmodified .These were the apparent BADCHARS \x00 \x07 \x08 \x2e \x2f \xa0 \xa1. So i created a new bytearray and removed \x07 from the payload too

20. I fired the exploit.py once again, and as a hint by the immunity debugger the possible BADCHARS now were x2e \x2f \xa0 \xa1. That means a BADCHAR made its adjacent byte too a BADCHAR which want BAD by default

21. Lets further drill down and remove x2e

22. We need to simultaneously restart the immunity debugger since the program is crashed and again iterate through creating byte-array without the BADCHARS.

23. Firing it and again it was the same case x2e was a BADCHAR was x2f wasn't one.

Now we had only two apparent BADCHARS \xa0 \xa1

24. Lets create a MONA bytearray without \xa0 first

25. Also we need to remove \xa0 from our payload

26. After this! WE FIRE IT and run the comparison in MONA, we find the address unmodified now. BOOM so finally we got our BADCHARS. :P

In this case it was that Not all of BADCHARS displayed by MONA might be BAD! Sometimes BADCHARS cause the next byte to get corrupted as well, or even effect the rest of the string. Not writing in the answers down here I don't want spoilers present here:D (which I already have somehow)

--

--