nand2tetris Part III — Coming Soon
November 10, 2026
You built a computer from a NAND gate. In Part I you wired up logic gates, an ALU, memory, and a CPU. In Part II you wrote an assembler, a virtual machine, a compiler for the Jack language, and a small operating system. At the end you had a working machine that runs programs you wrote yourself, top to bottom, with no magic left in the stack.
And then the course ends — right at the point where the questions get interesting.
How does a debugger actually stop your program on a line and let you poke at its memory? How does a buffer overflow turn a sloppy loop into an attacker's foothold — and how do the defenses that stop it really work? How can one computer pretend to be another, running a whole second machine inside itself? These aren't in the book. Part III is a new, independent sequel that answers them — built entirely on the Hack computer and Jack OS you already have.
No new platform to learn. You bring your Part I/II machine; we extend it, break it, and defend it.
One idea, at three altitudes
Part III isn't a grab-bag of topics. Everything in it is one pattern seen from different heights: a privileged layer that watches and controls a less-privileged one. We call it supervision, and once you see it, you see it everywhere.
- A debugger supervises your program: it traps on a breakpoint, inspects memory and registers, then hands control back.
- A kernel supervises user processes: it traps on a system call, does the privileged work, then returns to the caller.
- A hypervisor supervises a whole guest machine: it traps on a privileged instruction, emulates it, then resumes the guest.
Same move — trap, inspect, resume — at three altitudes. A breakpoint and a system call and a virtual-machine exit are the same mechanism pointed at different things. By the end, you'll have built all three, and the payoff is seeing that a debugger, a kernel, and a hypervisor are the same idea wearing different clothes.
That's why the modules are ordered the way they are: each one hands the next its machinery.
What you'll build
Five modules, each a working tool, each building strictly on the one before.
III-A — Hardware for supervision
We add three small primitives to the Hack machine: a user/kernel mode bit, a timer interrupt, and base/bound memory protection. Each is tiny; together they're the toolbox everything else draws from. Dull on its own, decisive for everything after — so we get it out of the way first, and the later modules become applications of it rather than detours into hardware.
III-B — Debuggers
You build a real source-level debugger for Jack, with break, continue, step, print, backtrace, and watch. Breakpoints work the way gdb's do — by patching a trap instruction over the target and restoring the original. Backtrace walks the VM frame chain your Part II calling convention already lays down. And symbol/line tables mean extending your Jack compiler to emit debug info, so you feel firsthand that a debugger depends on the compiler's cooperation.
III-C — Memory safety and exploitation
The module people come for. You'll craft three escalating attacks and then defend against them:
- Heap overflow in pure Jack — overflow one object into the next and hijack a later method call.
- Return-address overwrite at the VM level — redirect control to existing code. This is the seed of ret2libc and ROP, not shellcode.
- The finale — flip the simulator into von Neumann mode so data becomes executable, and watch classic shellcode injection finally work. The contrast is the whole lesson in why NX/DEP exists.
Then you implement the defenses as real passes — stack canaries, bounds checking, a shadow stack, a poisoned-allocator (an ASan analog), and base randomization (an ASLR analog) — and re-run each exploit to watch it get caught.
III-D — Processes and the kernel
The bridge from tool to operating system. Context switching, a scheduler driven by III-A's timer, system calls via trap, and user-vs-kernel enforced by III-A's mode bit. Here "supervisor" grows up into "kernel."
III-E — Virtualization (capstone)
You write a Hack CPU that runs inside Hack — first as a plain interpreter, for the "a computer can simulate any computer" moment. Then you upgrade it to trap-and-emulate, reusing III-B's trap mechanism and III-D's context switching, so the guest runs on the real CPU and only privileged instructions trap to your hypervisor. You finish by meeting the real vocabulary — Popek–Goldberg, ring compression, why x86 needed VT-x — right after hitting the exact problems those names solve.
Why Hack, of all machines?
Here's the surprise: the Hack computer is a Harvard machine — instructions live in ROM, data in RAM, and no instruction can write to ROM. So the textbook "inject shellcode into a buffer and jump to it" attack is impossible by construction on stock Hack. You simply cannot execute data.
That's not a limitation we're apologizing for. It's the best teaching moment in the whole course. Real CPUs spent decades bolting on the NX/DEP/W^X protections that Hack has for free — and in III-C you get to discover that by hitting the wall yourself, then flipping a switch to tear the wall down and see exactly what you lose. A protection you had to remove to get hacked teaches more than one you were told to add.
One honest note: because Hack is a 16-bit Harvard machine with a VM calling convention, the fine mechanics won't transfer one-to-one to real-world x86-64 exploitation. The goal is conceptual — the shape of each vulnerability class, the attacker's mindset, the defender's tradeoffs. That's the right scope for learning, and it's exactly the foundation that makes a real target comprehensible later.
Who it's for, and what you'll need
Part III is for anyone who finished The Elements of Computing Systems (Parts I and II) and wants to keep going — self-learners, students, and working engineers who want systems and security concepts grounded in a machine they fully understand. If you can read and write Jack and you remember how the VM calling convention works, you're ready.
What you'll need: your own Part I/II project (or the book's supplied one), and a willingness to extend the tools rather than just run them. Each module ships with specs, starter code, and test scripts; the simulator extensions stay behind flags so your original machine keeps working untouched.
Honest scope note: this is a full semester's worth of material, not a weekend. III-A and III-D are real modules, not warmups, and the virtualization capstone is genuinely ambitious. We'd rather tell you that now than have you expect a quick add-on.
What you'll walk away with
A debugger, a kernel, and a hypervisor you built yourself — and the lasting realization that they were the same idea the whole time.
Modules will roll out one at a time, starting with III-A. Stay tuned — and if there's a direction you most want to see first, that feedback shapes the order.
