Building Tor Network Tools and Encryption in C

There's a particular kind of educational video that doesn't try to sell you a shortcut. Dr. Jonas Birch's eight-hour composite series on cybersecurity in C is that kind of video — patient, methodical, and genuinely committed to showing you how things work at the level where they actually work. It's not a walkthrough of some GUI-based security tool. It's someone building the machinery underneath, in C, live, with all the compiler errors and wrong-direction type casts left in.

That choice alone is worth examining. Most security education either stays high-level ("here's how Tor works, conceptually") or drops you into a fully-formed codebase and tells you to read it. Birch does something less comfortable and more useful: he starts with a blank file and an RFC.

The Toralizer: Intercepting at the System Call Layer

The centerpiece of the series is a tool Birch calls "toalizer" — a command-line wrapper that routes any networked program's traffic through the Tor network without modifying that program. The mechanism is conceptually elegant: rather than patching Firefox or curl, you intercept the connect() system call at runtime and substitute your own function, which speaks the SOCKS4 protocol to a local Tor proxy.

"Toalize will intercept any calls to the connect function and execute our function instead," Birch explains. "The traffic will be redirected to a local proxy server which is a part of the Tor software. It will connect to the Tor network and then to the destination server, effectively masking your identity."

The SOCKS4 protocol itself is refreshingly simple — a two-step handshake where you send a small binary packet (version byte, command byte, destination port in network byte order, destination IP, null-terminated user ID) and receive a response whose single meaningful field tells you whether the proxy accepted the connection. Birch goes straight to the RFC to get the packet structure right, which is exactly what you should do and rarely what tutorials bother to show.

The interesting pedagogical move here is what he does with byte ordering. Network protocols specify big-endian byte order — the "most significant byte first" convention — and C on most modern hardware uses little-endian. Birch walks through htons() for port numbers and inet_addr() for IP addresses, explaining not just what they do but why the swap is necessary. That's the kind of explanation that makes concepts portable to the next protocol you encounter, not just this one.

When the tool works — when the logs on his web server show the request arriving from a Tor exit node rather than his own IP — Birch restarts the Tor service and runs the request again. The exit node changes. That's a live demonstration of the anonymization working as designed, and it's more convincing than any screenshot.

On RC4 and the Question of "Good Enough"

The encryption library segment is where the video gets genuinely interesting from a security perspective, because Birch doesn't pretend the algorithm he's implementing is beyond criticism.

RC4 has been formally deprecated from most security protocols. The weaknesses are real: the keystream it produces is statistically distinguishable from random output, and that distinguishability has been exploited in practice — most notably in WEP, the early Wi-Fi encryption standard, where RC4 was used with short keys and a flawed initialization scheme that allowed attackers to recover keys in seconds. TLS eventually moved away from RC4 as well.

Birch acknowledges this directly. "There's a lot of text here and some of it are warnings that this encryption standard isn't secure, but I have read through all of that and I'm not sure if I agree actually." His argument for proceeding with RC4 — with modifications — rests on two claims: that the known attacks require specific contextual conditions (RC4 used alongside TLS, or with the WEP-style initialization), and that discarding the first large chunk of keystream output neutralizes the statistical bias in the early bytes.

Whether those mitigations are sufficient depends heavily on your threat model, and Birch is right that context matters enormously in cryptographic security. RC4 used with a long, randomly generated key in isolation is a meaningfully different proposition than RC4 as deployed in WEP. Still, the broader cryptographic community's current position is that RC4 shouldn't be used in new systems regardless of mitigations. Birch's framing — "I think ARK 4 is still secure" — is a defensible engineering position for learning and experimentation, but readers deploying anything sensitive should default to established modern primitives.

What's not in dispute is the pedagogical value of building it. The RC4 key scheduling algorithm — iterating through a 256-byte state array, mixing in the key material byte by byte using modular arithmetic and swaps — is a clean illustration of how stream ciphers work. Birch's decision to break each pseudocode step into explicit temporary variables rather than collapsing them into single dense expressions is a genuine teaching choice, not sloppiness.

"The code will look kind of difficult," he admits during the key scheduling implementation, "but it really isn't. It's quite simple and it's quite easy to follow it step by step if you break it down into smaller steps."

That's true, and it's also true of most things in security that look opaque from the outside.

The XOR Foundation

Before the full encryption library, Birch covers XOR — the bitwise operation that sits underneath most stream ciphers. The demonstration is minimal by design: encrypt a single character using a single-character key, print the hexadecimal values, decrypt it by XORing again with the same key, confirm you get the original character back.

"This is a very basic form of encryption that is only for demonstrational purposes," he says, "it's quite easy to crack with today's technologies and computer power. However, it's a good example on how to use XOR."

The honesty matters. XOR-only encryption with a short, static key is trivially breakable — but understanding why it works mathematically is prerequisite to understanding why RC4 and every other stream cipher works. You XOR plaintext against a keystream to produce ciphertext; you XOR ciphertext against the same keystream to recover plaintext. The security of the whole system lives entirely in the unpredictability of the keystream. That's the concept. Everything else is implementation.

What the Format Actually Teaches

Eight hours of live coding — with compiler errors, wrong assumptions, backtracking, and the occasional "I've never seen that error message before" — teaches something that polished tutorials don't: debugging is the work. Birch doesn't cut away when the compiler complains about incompatible pointer types or signedness mismatches. He reads the error, reasons about it, and fixes it. Sometimes he fixes it wrong the first time and has to reason about it again.

The video also covers Linux file system security fundamentals, building a file encryptor, installing a custom C library, and writing what Birch describes as "unhackable" code through a safe string library — the kind of defensive coding that prevents the buffer overflows and memory corruption bugs that account for a persistent share of real-world vulnerabilities.

The full eight-hour arc lands somewhere specific: not "here are security tools you can use," but "here is how security tools are built, and here are the tradeoffs their builders navigate." The distinction matters. Tools you can use without understanding them make you dependent; understanding the layer underneath makes you capable of reasoning about any tool.

"Coding this is easier than you might think," Birch says at the outset about the Tor interceptor. He's right — and that's actually the more important lesson. The distance between a working mental model and a working implementation is smaller than most people assume. The question is whether you're willing to sit with the compiler errors long enough to close it.

---

Rachel "Rach" Kovacs covers cybersecurity and privacy for Buzzrag.