Assignment Archive, SHA1: 0aae4be7de387e1e6125715786e28f208d8db324

The purpose of this task is to explore GDB, and automate a debugging session. You are encouraged to use the GDB User Manual, and what you learned during the previous lab sessions. We recommend that you start solving each subtask in a live debugging session, and then assemble the final script.

The given binary computes the SHA-1 hash of some input, but if you send him a signal at the right time, it will also compute a special hash. Write a GDB script/commands file that goes through the following steps:

1. when data to be hashed is being requested, a read() syscall will be issued, catch it
2. break execution right before compute_hash() is called (you should now be in main()'s stack frame)
3. print the 5 instructions before the current instruction pointer
4. break on malloc calls
   • print the return value after malloc finishes
5. break in alloc_hash() after malloc call (just once, when it is called from compute_hash())
   • print the stack, the registers and the last 3 frames
   • move to the previous frame, and print registers
   • move back, and print locals and arguments
6. remove all breakpoints, catchpoints and watchpoints
7. add breakpoint after the normal hash is printed
8. rerun
9. you will discover there is a special, or “reversed hash” mode, break execution on printf calls while in this mode
   • print current frame and the EIP register each time this breakpoint triggers
10. add watchpoints for hash mode changes
11. send the required signal
12. leave the watchpoint and the 2 breakpoints
13. rerun, but this time, trigger the mode change without sending the signal
14. delete watchpoints and breakpoints
15. break in main() after compute_hash()
    • print the heap section holding the hash in hex in 2 ways:
      • search for the hash in memory (you control the data being hashed)
      • use the malloc return value
16. rerun

• GDB Cheat Sheet
• Use source code line numbers and/or addresses when you cannot use the symbols.
• You can redirect all GDB and the binary's outputs to files.
• On Ubuntu/Debian x86_64: You will need libssl-dev:i386. Installing that might uninstall the 64-bit libssl. Be sure to reinstall it after you finish. We tested with libssl-dev:i386 1.0.1c-4ubuntu8.1 on Ubuntu Raring.

• Write everything in Python, using the GDB API.

The GDB script/commands file or the Python script (for bonus). Your submission will be run as follows, in the directory containing the hasher binary:

• normal: gdb -q --command=gdb-sha1.gdb
• bonus: gdb -q -x gdb-sha1.py

Someone has tampered with the executable file. Please fix this and call the call_me function!

Provide solution in a script/executable named call-me.solver. This script will have to properly update the call_me executable. You can assume that the call_me binary will exist in the same path as the call-me.solver script.

Someone has tampered with the executable file (again). Please fix this. There should be a flag message printed in case you solve it correctly.

Provide solution in a script/executable named call-main.solver. This script will have to properly update the call_main executable. You can assume that the call_main binary will exist in the same path as the call-main.solver script.

Link me to print out the flag.

Provide solution in a script/executable named link-me.solver. This script has to generate all files required.

The current testing framework will do export LD_LIBRARY_PATH=. for you .

There is a buffer overflow in this program, can you trigger it? You'll have to understand a protocol, *trace is your friend.

A Python script named png-bof.py that prints to stdout (in binary format, no newline) the correct string that has to be used as input by png-parser executable. A correct input will force the program to crash with a SIGSEGV.

A packed binary is hidden/compressed in another “shell” binary. This is a common technique used by malware developers to hide the malicious software. When running the packed binary (the “shell”), the original binary is unpacked/decompressed and it starts executing.

In the following archive you can find:

• a packed binary.
• the original binary from which the ”.data” segment was removed.
• readelf info with information about the original binary's sections and segments.

You have to rebuild the original binary without using any specialized unpacking tool.

The recovered(rebuilt) original binary (a file called binary_unpacked) and a readme/writeup where you describe how you've recovered the binary. Write the exact commands in the readme or include any scripts that you've used.

The submission will made through vmchecker interface. Choose the "Computer and Network Security" class and then "Assignment 1" and upload a .zip file that should consist of the files shown below.

The archive will contain at least the following files:

• README
• gdb-sha1.gdb
• call-me.solver
• call-main.solver
• link-me.solver
• png-bof.py

Shortly describe your approach for each task. If some details are not clear you can ask us or make some assumptions. Describe the assumptions in the README file.

foo-bar
--------

objdump can be used to disassemble the binary. I found an overflow 
when reading into the input buffer (see snippet below). We can
generate an attack string with the following format: [FORMAT].

[assembly snippet showing the ovf]

I am not sure if the UNIVERSAL answer is 41 or 42, but I tried using
42 and seems to work. Further investigation into why this is the case
might be needed. Tests pass just fine.

If you are really stuck or think that there is a bug in the assignment feel free to ask the OSS Team. Keep in mind that we wont give solutions but rather hints. We will answer in less than one day and update this page accordingly.