Home Assignment 2a › hacker track › assignment2-177 Digital test Mon, 20 Apr Submit
Aryan
5 hours of reverse-engineering, ghidra, manual stack tracing… then someone mentioned the 'strings' command. It was just sitting there in the binary, in plaintext, saying hi. 5 hours. For nothing. I'm fine.
Aryan

See the assignment's PDF available on BrightSpace for task descriptions and submission requirements.

Level 5

5
(1) Explain what were the vulnerabilities of the target program of this level.
(2) Explain how you exploited the aforementioned vulnerabilities to get access to the next level.
Your explanations must be clear and not miss any detail. Take care that with your explanations a reader would be able to exploit the target program.
Answer

1) The vulnerability is that the restricted file 'password.h' is compiled into the final binary. The compiled binary does not read the file, it includes it, by examining the binary file we can try and find the password.

2) We started with exploring the file. We tried running it with no parameter, with a parameter 'AAAAAAA', and with 10.000 A's as a parameter to see if we find anything interesting. We ran 'strings level5', to see if we can find any strings, hoping the password would be stored in plain text. Unfortunately there was no text. GDB was not working at all, we couldn't make breakpoints, it would always make the breakpoint, and eventually when running/starting (run AAAA, start, starti) it would say the memory wasn't acceible, and breakpoint were not possible. Because the program couldn't pause, we couldn't make breakpoint, and we couldn't figure out why. We thought maybe because there are no 'debugging symbols'

We decided to try to reverse engineer the binary, since it's the only thing we have. We could analyse the binary itself, in GDB as well. We found out the password was obfuscated with an algorithm and we wanted to reverse engineer it. This was possible but tedious.

We would need to de-obfuscate the password. But looking at the assembly for the main function, we saw that the password word be right there, in the register RSI or RDI. We tried many things, but GDB didn't work and not using GBD would mean that ASLR would be on.

After hours we found that the following works, we're not sure why, we feel like it randomly worked as we tried all of this. For some reason this sequence seemed to work. Note that on my PC, it did seem to work using the methods we initially tried, we suspect it has something to do with the way GDB is configured on the pc: mainly the line 'process 744896 is executing new program: /levels/level5/level5' seems to be what caused it to finally work.

gdb ./level5
(gdb) run < /home/students177/AAttack.txt
Starting program: /levels/level5/level5 < /home/students177/AAttack.txt
warning: Probes-based dynamic linker interface failed.
Reverting to original interface.
process 744881 is executing new program: /levels/level5/level5
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Inferior 1 (process 744881) exited with code 01]

breaking at the strcmp, before freeing the memory. Than read the string in the RDI register, revealed the password.

Hardcoded Secret in Binary
A restricted header is compiled directly into the binary as a string constant. The secret is not read at runtime — it's baked in. GDB can be used to catch the value at the right breakpoint, revealing the password without needing the source file.