Lab 2: Build a Malware Blueprint
Design a modular malware architecture on paper, without writing a functioning payload.
The brief
Design a modular, non-functional malware architecture: its loaders, payloads, supporting modules and the infrastructure they depend on.
Once a lifecycle exists, it requires an architecture: the components a real system would be built from, and how those components fit together. This lab asks for that blueprint, a design only and never a running program, laying out loaders, payloads and the supporting modules and infrastructure they depend on.
The design work here more closely mirrors ordinary software architecture than it does a single exploit. The same pressures toward modularity, separation of concerns and maintainability apply, which is precisely the point the lecture makes about why malware increasingly resembles the software engineering discipline it borrows from.
What you submit
- An architecture diagram naming each component and its role
- A short justification of the modularity choices made
Due: 10 August 2027 ·Weight: 2% of the course grade
How it is marked
Assessed on whether the design shows a working understanding of loaders, payloads, modules and infrastructure as separable components.
Key dates
- Submission due: 10 August 2027
The spec
The brief poses the problem and leaves room for a response. The spec is the fixed part: what a marker checks. Some lines can be checked mechanically; the rest call for judgement.
- submitted by the deadline, in the format named below
- the architecture separates loaders, payloads, modules and infrastructure rather than describing one undifferentiated blob
- the architecture diagram names each component and the role it plays
- the modularity choices made are justified, not just asserted
- reasons about separation of concerns and maintainability the way ordinary software architecture would, not just a single exploit