Web security to native code: what carries over

Web testers thinking about native code usually arrive with one of two priors. Either they assume their hard-won bug-hunting instincts are universal and binary work is just a matter of learning some assembly, or they assume nothing carries and they'll be starting from scratch. The truth lives somewhere awkward in the middle, and knowing where it lives saves months.

Here's the inventory.

What carries over

Input-validation thinking. This is the headline transferable skill, and it transfers cleanly. Once you've learned to ask "where does user input enter the system, where does it get parsed, and where does the parser meet a sink?", you've learned the question that matters in binary work too. The sinks are different. The question is the same. A web tester who's spent two years staring at parameter handling will spot the equivalent suspicious code path in a C parser faster than a CS graduate who's never touched Burp.

Trust boundaries. Where does authenticated input become trusted? Where does data crossing a process boundary stop being checked? Where does a privileged daemon take instructions from an unprivileged user? These questions are almost identical in web work and in native binaries. The shape of the answer changes (a UNIX socket message instead of an HTTP POST, a setuid invocation instead of an authenticated session), and the muscle for noticing the boundary is the same.

The attacker's mindset. This one is so obvious people forget to mention it. The willingness to read documentation backwards, to assume nothing the developer said is true, to treat the system as adversarial geometry rather than a black box — that's the actual core skill of either field. It does not come from textbooks. You spent years building it on web targets. It travels.

Smell tests for parsers. Burp users who've fingerprinted bad XML parsers, weird CSV split logic, or hand-rolled JSON processing have already trained the instinct that says "this code path looks fragile". That instinct fires identically when you're reading a custom binary protocol parser in IDA. The visual cues are different. The pattern recognition is the same.

What doesn't carry

Assembly. No two ways about this one. You have to learn it from cold, and the first month feels like learning a language where the alphabet has thirty thousand letters. Reading x86_64 fluently is a separate skill from knowing what mov does, and there is no shortcut. The good news is that fluency arrives faster than people fear; the bad news is that it doesn't arrive at all without sitting down with disassembly daily.

The memory model. Stack frames, calling conventions, the heap, mmap regions, the GOT and PLT, virtual memory. These are the ground state for everything else, and web work touches none of them. You're not learning a new framework, you're learning a new physics. Plan for it.

Calling conventions. Specifically the difference between System V AMD64, Microsoft x64, ARM64 AAPCS, and the various fastcalls. Which registers hold arguments, which are caller-saved, where the return value lives. You'll memorise these the way you once memorised HTTP methods, except there's more of them and the consequences of getting them wrong are subtler.

Tooling fluency. GDB with pwndbg, IDA, Ghidra, Binary Ninja. None of them are difficult, all of them have to become as natural as Burp. The investment is real.

Conceptual analogues, with caveats

The honest map between worlds is approximate. Some pairings are cleaner than others.

XSS sinks ↔ format string sinks. The shape is similar: untrusted data flows into a function that interprets it. In XSS the function is a renderer; in printf the function is the format string parser, which can be coerced into reads or writes via %n and %s with attacker-controlled pointers. The difference is that XSS is essentially universal once you find a sink, whereas a format string bug needs the input to actually reach the format argument, which is rare in modern code.

SSRF ↔ trust-boundary parsing. Less direct, but the pattern of "make the server fetch something on your behalf" maps onto "make the privileged process parse something on your behalf". A binary that takes an attacker-controlled file path, opens it, and trusts whatever it finds is the native equivalent of an SSRF-vulnerable URL fetcher. Same trust failure, different transport.

Request smuggling ↔ binary input parsing ambiguity. Smuggling exploits two parsers disagreeing about where one request ends and the next begins. Binary protocols have the same problem at a finer grain. A length field that one parser treats as inclusive and another as exclusive is a smuggling primitive in everything but name. The exploitation feel is similar, even when the mechanics differ.

Mass assignment ↔ heap layout abuse. A stretch, but the underlying lesson is the same: the developer assumed certain fields wouldn't be reached, and you reach them anyway. Where mass assignment lets you set fields the developer didn't mean to expose, heap layout abuse lets you write to chunks the developer didn't think of as adjacent. Both bugs come from the same overconfidence about boundaries.

These analogies are useful as scaffolding, less useful as load-bearing intuition. Use them to feel less lost in the first weeks. Discard them once you've internalised the native-side primitives directly.

What to expect

The first month is uncomfortable in a specific way. You'll know enough to know you're missing something, without knowing what. The instinct that previously fired in Burp will fire on disassembly and tell you "something's wrong here" without giving you the vocabulary to say what. That's actually a good sign. The vocabulary catches up; the instinct is the part that takes years to build, and you already have it.

The web testers who succeed at this transition are the ones who treat their existing intuition as half the job done, and the assembly-and-memory layer as the other half they have to grind. The ones who get stuck are the ones who keep reaching for what they know.

Where this fits in

The Memory & Systems track is the part you have to acquire from cold. It walks through the address space, the stack, the heap, virtual memory, and the assembly fluency that everything else depends on. Treat it as the new physics. Your existing security instinct keeps doing its job once that layer is in place.