Reverse engineering PWN tasks or exploiting binary vulnerabilities (Part 3 / Stack2)
Friends, hello everyone! This is the third part of our “pyvn” 🙂 Today we will study the work of Stack2.exe (you can download it HERE).
Links to previous parts:
Exploitation of binary vulnerabilities or learning to “push” (Part 1 / Stack0)
Reverse engineering PWN tasks or exploiting binary vulnerabilities (Part 2 / Stack1)
Stack2
We'll start, as usual, with static analysis. Let's launch GHIDRA:
![Loading snake :) Loading snake :)](https://habrastorage.org/getpro/habr/upload_files/59f/88e/c16/59f88ec1644085600393422dee3c4ffc.jpg)
We throw the “binary” into the project and click on Code Browser:
![](https://habrastorage.org/getpro/habr/upload_files/520/eb8/711/520eb87110ead9d49de5ccbbe7ffaa99.jpg)
We analyze…
![](https://habrastorage.org/getpro/habr/upload_files/07b/47a/28e/07b47a28ed0c331825d2b9f044ea6740.jpg)
We get the decompiled code. Pay attention to the variable “local_14”. It is assigned the value of the environment variable “GREENIE”. Then comes the check. If the variable “local_14” is equivalent to 0x0 (NULL), then the program displays the message “Please set the environment variable GREENIE”:
![](https://habrastorage.org/getpro/habr/upload_files/998/b2e/ade/998b2eade7d5dc35924506fbeeaefc8e.jpg)
Let's look further… The variable “local_18” is assigned “0” (this is the variable we will overwrite). The notoriously unsafe strcpy() function copies the value of “local_14” to “local_58” (an array of 64 bytes). P.S. Sorry, the array declaration didn't make it onto the screenshot. Next comes the check. If the variable “local_14” is equivalent to “0xd0a0d0a”, then PWN! (we get a message that we are great, we have correctly modified the variable). If not, then “Try again”:
![](https://habrastorage.org/getpro/habr/upload_files/eae/60d/ac2/eae60dac23108ff36de1e52fc9d56a22.jpg)
Great! We figured out how the program works. Let's do a small test. Go to the environment variables and add the variable “GREENIE” with the value of 64 characters “A” (since the array is 64 bytes) and “BCDE” (we'll try to overwrite the variable “local_18” with these characters):
![](https://habrastorage.org/getpro/habr/upload_files/617/ab6/89d/617ab689df9d6877772008544b8aeaca.jpg)
![](https://habrastorage.org/getpro/habr/upload_files/50c/8c0/663/50c8c0663fdd79d091b0793b95d655e4.jpg)
Open x64dbg, set a breakpoint on the CMP instruction (we have already done this, we will not dwell on this). We see that the EAX register contains our BCDE “letters”:
![](https://habrastorage.org/getpro/habr/upload_files/69d/bb0/5ff/69dbb05ff27c611f44de61091d0f2fbd.jpg)
Then everything would seem simple, but we have to “overwrite” the variable “local_18” with the symbols “x0d”, “x0a”, …! Those who “fought” know that these are the control symbols CRLF:
\x0d
– is the Carriage Return (CR) character, ASCII code 13.\x0a
– is the Line Feed (LF) character, ASCII code 10.
![](https://habrastorage.org/getpro/habr/upload_files/7bf/51a/920/7bf51a9205affd5ba9d61cf6ecc9314c.jpg)
But how do we write control characters into the value of the environment variable “GREENIE”?
I'll say right away that control characters can be written in environment variables and now we'll write a small one exploit Python script:
![](https://habrastorage.org/getpro/habr/upload_files/1f7/cbd/22c/1f7cbd22cbc97f81c6d175ac13114063.jpg)
Let's look at the code. Var1 is assigned a 64-character string 'A', followed by a “packed” 0x0d0a0d0a in Little-Endian (
Let's execute the script:
![Profit! Profit!](https://habrastorage.org/getpro/habr/upload_files/940/8d4/aa3/9408d4aa37384b669e9fc7aca4d8e037.jpg)
We successfully managed to exploit the unsafe strcpy() function and get the coveted string! P.S. We even wrote an exploit 🙂
If you liked the article – thumbs up! Also subscribe to my TG!
See you in the next part! 🙂