Dynamic Analysis
Due Date: 2026-05-11 23:59:59
Submission: via GitLab repo
Introduction
Dynamic analysis involves executing a sample in a controlled environment and observing its runtime behavior. You will use system call tracing, network capture, and sandbox tooling to characterize what a sample does when it runs.
Safety requirements:
- Revert to your clean VM snapshot before each sample
- Disable or isolate the VM’s network interface before executing anything
- Take a new snapshot immediately before running each sample so you can compare before/after state
Setup
Obtain the samples from ada.cs.pdx.edu:/stash/malware_re/dynamic/:
$ scp -r <MCECS>@ada.cs.pdx.edu:/stash/malware_re/dynamic/ ~/malware/samples/hw3/
Part 1: Dynamic Analysis
You should have two sample files. Using the debugger of your choice, run the programs and determine the solutions to defuse the bomb. If you don’t have an x86 linux machine on which to run the files, I would suggest you make use of ada or babbage to run this code.
The programs are non-malicious, and therefore do not pose a risk to your system.
I would suggest using tools designed for this process, such as:
You must do this exercise entirely dynamically! We won’t be mixing the tools until next time around.
Part 2: Written Analysis
Write a 1–2 page analysis report covering each sample, documenting:
- the results of the static analysis tooling,
- your approach to obtaining the solution,
- what the program does,
- steps you took to find the information you needed, and
- how you were able to generate the solution.
Screenshots are both appreciated and encouraged. An very thorough example style can be seen in this crackme reverse engineering writeup.
Submission
Commit and push hw2/hw2.md with all findings, screenshots from IDA and Cutter, and your written analysis. Include any scripts that you wrote to solve the challenges in the repo as well.