SLOP8445
Course information
What you need before week 1, how the teaching runs, what you may and may not run in the lab, and how the evidence is made readable.
Who this is for#
Upper-level undergraduate or introductory postgraduate, in systems or security. You do not need prior experience of symbolic program analysis; SSA, SMT, symbolic execution and lifting are all introduced in the course. You do need to arrive able to read code.
Assumed before week 1:
- C functions, pointers, arrays, control flow, and unsigned integer arithmetic;
- binary and hexadecimal notation, bitwise operators, and basic modular arithmetic;
- introductory architecture: registers, memory, the stack, calls, and conditional branches;
- comfort at a command line, and enough Python to read a short script. You will not be asked to write one.
Explicitly not assumed: compiler implementation experience, theorem proving, or any prior reverse engineering.
If you can read showcase.c and predict what demo_substitution(0x1337)
returns, you are ready. If you cannot, week 1’s studio is where to say so.
Teaching pattern#
Twelve two-hour studios, one per week, on Wednesdays. Four spine lectures, in weeks 1, 4, 7 and 10, each opening a block of three weeks.
Studios are where the work happens: you read the evidence, disagree about what it shows, and leave having written down one thing you could not conclude. Attendance is not marked. It is also not optional in any practical sense — reading someone else’s notes about a disassembly listing transfers almost nothing.
There is a two-week teaching break after week 6. A2 and the capstone are both set before it, deliberately, so that the break is usable.
The lab, and the rule about running things#
The course provides a Windows x64 image containing the twenty-one retained specimens, a disassembler, and the analysis tools used in the studios.
Every core exercise has a read-only route. Source, LLVM IR, generated C, exact disassembly, recovered control-flow graphs, solver queries and result files are all published on this site and are sufficient to complete the studios, A1 and A2 on any platform, offline, with a text editor. No paid decompiler and no commercial binary-analysis platform is required for anything that carries marks.
Execution and debugging need the lab image. The rules there are short:
- Run only what the evidence page marks runnable. One specimen is an explicitly incorrect rewrite, kept as negative evidence. It is for inspection.
- Run them in the lab image, not on your own machine. These are obfuscated Windows binaries. Endpoint protection will sometimes take an interest in them, and that is the correct behaviour.
- If a launch is blocked, it stays blocked. Do not disable or work around endpoint protection. A blocked launch is not permission to bypass anything; use the read-only route instead.
- Decline the original PDB when a debugger offers it for a rewritten specimen. The identifier survives patching; the instruction mappings inside a rewritten function do not.
- Navigate by export name or by loaded base plus RVA. No PDB or MAP file is supplied, on purpose, and address-space layout randomisation will move preferred addresses.
Nothing on this site is a distribution channel for executables, and the corpus is not licensed for redistribution outside the course.
Legal and ethical scope#
This is a course in program analysis, taught on a 483-line demonstration program written for the purpose. It is not a course in defeating software protection you do not own, and the skills in it do not come with permission to use them on anything.
Two practical lines:
- Analyse only software you own, software licensed to you for that purpose, or the course corpus.
- The corpus contains no malware, and nothing in the course requires a sample that might.
Assessment#
Three pieces — 25%, 30% and 45% — and no exam. The briefs, the spec lines and the marking criteria are on the assessment page.
One rule is worth stating here because it is the course’s own standard turned on your submission rather than boilerplate: name any tool you used and its version, and treat its output as a claim you now have to support. Every claim cites a file and a line or an address. Two of the results you will study are on this site because somebody applied that standard and somebody else had not.
Accessibility#
The course’s evidence is mostly text, which helps. Two known problems and what is done about them:
- Control-flow graphs. Several are several metres wide at natural size. Every one on this site is published as SVG — so it scales and its text is real text — with a described caption, and the numbers quoted beside it come from the result files rather than from the picture. Where a graph carries the argument, the argument is also in prose.
- Disassembler screenshots. These are raster images of somebody else’s tool and cannot be made into text. Each has alt text describing what is visible, each can be enlarged in place or opened at full resolution, and — this is the important part — no claim on this site rests on one. They illustrate; the result files establish.
Colour is never the only signal: every verdict on this site carries a word (PASS, WRONG, UNSAT, STATIC ONLY) and a shape as well as a colour.