Differences
This shows you the differences between two versions of the page.
|
cns:assignments:assignment-1 [2016/11/16 10:20] irina.presa [Assignment 1] |
cns:assignments:assignment-1 [2023/11/06 13:14] (current) adrian.sendroiu [Capture the Flag Format] |
||
|---|---|---|---|
| Line 2: | Line 2: | ||
| <note important> | <note important> | ||
| - | Deadline: **Sunday, November 20, 2016, 11pm (EET, Romania time)** | + | Deadline: **Monday, November 27, 2023, 11:59pm (EET, Romania time)** |
| The deadline is **hard**. No submissions will be accepted past the deadline. | The deadline is **hard**. No submissions will be accepted past the deadline. | ||
| </note> | </note> | ||
| + | ===== Capture the Flag Format ===== | ||
| - | ===== Assignment Archive ===== | + | Assignment 1 uses a CTF (//Capture the Flag//) format. |
| - | [[http://elf.cs.pub.ro/oss/res/assignments/cns-assignment-1.end-2014-2015-30-g4edeedb.zip|Assignment Archive]], **SHA1**: 0aae4be7de387e1e6125715786e28f208d8db324 | + | Challenges are on the [[https://cns-2023-assignment01.cyber-edu.co/|CyberEDU platform]] (To be able to access the platform, first you have to use the registration link that has been provided on MS Teams). For each challenge you will have to submit the flag to be able to get the points. |
| - | ===== GDB (1.5p) ===== | + | There are 7 challenges, each challenge is worth 200 points. 5 challenges are required for the maximum grade of 10 (1000 points), the other 2 are bonus. |
| - | The purpose of this task is to explore GDB, and automate a debugging session. You are encouraged to use the [[http://sourceware.org/gdb/current/onlinedocs/gdb/|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. | + | Apart from the flag submission, you will create a folder for each challenge. Each challenge folder consists of scripts and a README file documenting your solution to the challenge. Then pack all folders into a ''.zip'' archive and submit it on [[https://curs.upb.ro/2023/course/view.php?id=4549|curs.upb.ro]] using the [[https://curs.upb.ro/2023/mod/assign/view.php?id=61011|Assignment 1: CTF form]]. |
| - | <note> | + | Have fun and happy hacking! |
| - | The purpose of this first task is to establish some initial basic knowledge of GDB's capabilities. If you find some of the requirements ambiguous, feel free to formulate assumptions, and document them in comments. Since solutions usually have high degree of variance, the task will be graded manually. | + | |
| - | </note> | + | |
| - | + | ||
| - | 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: | + | |
| - | - when data to be hashed is being requested, a ''read()'' syscall will be issued, catch it | + | |
| - | - break execution right before ''compute_hash()'' is called (you should now be in ''main()'''s stack frame) | + | |
| - | - print the 5 instructions before the current instruction pointer | + | |
| - | - break on ''malloc'' calls | + | |
| - | * print the return value after ''malloc'' finishes | + | |
| - | - 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 | + | |
| - | - remove all breakpoints, catchpoints and watchpoints | + | |
| - | - add breakpoint after the normal hash is printed | + | |
| - | - __rerun__ | + | |
| - | - 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 | + | |
| - | - add watchpoints for hash mode changes | + | |
| - | - send the required signal | + | |
| - | - leave the watchpoint and the 2 breakpoints | + | |
| - | - __rerun__, but this time, trigger the mode change without sending the signal | + | |
| - | - delete watchpoints and breakpoints | + | |
| - | - 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 | + | |
| - | - __rerun__ | + | |
| - | + | ||
| - | ==== Tips ==== | + | |
| - | + | ||
| - | * [[http://darkdust.net/files/GDB%20Cheat%20Sheet.pdf|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. | + | |
| - | + | ||
| - | ==== Bonus ==== | + | |
| - | + | ||
| - | * Write everything in Python, using the GDB API. | + | |
| - | + | ||
| - | ==== What to submit ==== | + | |
| - | + | ||
| - | 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 <nowiki>--</nowiki>command=gdb-sha1.gdb'' | + | |
| - | * bonus: ''gdb -q -x gdb-sha1.py'' | + | |
| - | + | ||
| - | <note> | + | |
| - | This task will be checked and graded manually. | + | |
| - | </note> | + | |
| - | ===== call_me (2.0p) ===== | + | |
| - | + | ||
| - | Someone has tampered with the executable file. Please fix this and call the ''call_me'' function! | + | |
| - | + | ||
| - | ==== What to submit ==== | + | |
| - | + | ||
| - | 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. | + | |
| - | + | ||
| - | ===== call_main (2.0p) ==== | + | |
| - | + | ||
| - | Someone has tampered with the executable file (again). Please fix this. There should be a flag message printed in case you solve it correctly. | + | |
| - | + | ||
| - | ==== What to submit ==== | + | |
| - | + | ||
| - | 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 (1.5p) ===== | + | |
| - | + | ||
| - | Link me to print out the flag. | + | |
| - | + | ||
| - | ==== What to submit ==== | + | |
| - | + | ||
| - | Provide solution in a script/executable named ''link-me.solver''. This script has to generate all files required. | + | |
| - | + | ||
| - | ==== Hint/Working assumption ==== | + | |
| - | + | ||
| - | The current testing framework will do ''export LD_LIBRARY_PATH=.'' for you ;-). | + | |
| - | + | ||
| - | ===== png-bof (3.0p) ===== | + | |
| - | + | ||
| - | There is a buffer overflow in this program, can you trigger it? You'll have to understand a protocol, ''*trace'' is your friend. | + | |
| - | + | ||
| - | <note> | + | |
| - | A failed assertion is **not** a buffer overflow. You should be able to trigger a **''SIGSEGV''**. | + | |
| - | </note> | + | |
| - | + | ||
| - | + | ||
| - | ==== What to submit ==== | + | |
| - | + | ||
| - | 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''**. | + | |
| - | + | ||
| - | <note> | + | |
| - | By //correct// string, we mean a string that is able to bypass the asserts inside the ''png-parser'' executable. | + | |
| - | </note> | + | |
| - | + | ||
| - | ===== BONUS: packer (2.5p) ===== | + | |
| - | + | ||
| - | A packed binary is hidden/compressed in another "shell" binary. This is | + | |
| - | a common technique used by [[http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-papers/wp_revealing_packed_malware_sep_2008.pdf|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 {{:cns:assignments:packer.zip|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. | + | |
| - | + | ||
| - | <note> | + | |
| - | + | ||
| - | You can use **strace** and **GDB** to analyse how the original binary is | + | |
| - | unpacked and executed. | + | |
| - | + | ||
| - | You can use the GDB **dump memory** command to dump at runtime the content of any memory | + | |
| - | area to a file. | + | |
| - | + | ||
| - | Note that the ".data" segment gets populated with more data during the | + | |
| - | execution of a binary, so you'll have to retrieve it as early as possible. | + | |
| - | + | ||
| - | </note> | + | |
| - | + | ||
| - | ==== What to submit ==== | + | |
| - | + | ||
| - | 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. | + | |
| - | ===== Submission ===== | + | |
| - | + | ||
| - | The submission will made through [[https://vmchecker.cs.pub.ro/ui/#CNS|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. | + | |
| - | + | ||
| - | <note> | + | |
| - | We will check the [[#gdb_15p|GDB]] task by hand, it will not be included in the [[https://vmchecker.cs.pub.ro/ui/#CNS|vmchecker]] automated verification script. | + | |
| - | </note> | + | |
| - | ==== Archive format ==== | + | |
| - | + | ||
| - | 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'' | + | |
| - | + | ||
| - | <note> | + | |
| - | The Python version from the machine is: 2.6.6. The machine is a 32bit Ubuntu based machine. | + | |
| - | </note> | + | |
| - | + | ||
| - | ==== README ==== | + | |
| - | + | ||
| - | **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. | + | |
| - | + | ||
| - | === Example === | + | |
| - | + | ||
| - | <code> | + | |
| - | + | ||
| - | 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] | + | ===== Support ==== |
| - | I am not sure if the UNIVERSAL answer is 41 or 42, but I tried using | + | If you are really stuck or think that there is a bug in the assignment, please contact Adrian on Microsoft Teams or send an email to [[oss-support@cursuri.cs.pub.ro]]. You needn't subscribe or anything, just send an e-mail. It's a private discussion. |
| - | 42 and seems to work. Further investigation into why this is the case | + | |
| - | might be needed. Tests pass just fine. | + | |
| - | </code> | + | Keep in mind that we won't give solutions but rather hints. |
| - | ===== Hints ===== | + | ===== Other ===== |
| - | If you are really stuck or think that there is a bug in the assignment feel free to ask the [[oss-support@cursuri.cs.pub.ro|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. | + | Do not attack the infrastructure. If you find a problem with one of our tasks, please report to us. |
| + | You are not allowed to intercept the traffic of other teams or attack them. Any attempt to cheat on the contest will lead immediately to getting no points for the assignment and a contact of the faculty executive staff. | ||
