Windows Kernel Source Code

Don’t get excited! I have no access to Microsoft’s source code for the Windows kernel. I never have had. I have no secrets to spill. What I do have is a growing belief that some questions about Windows source code might better be put to rest.

Irrelevance

Though I have been looking at the Windows kernel for much longer than most, I can’t speak for everyone who studies Windows. Indeed, the way I came to it and thence the way I do it may be very particular. From my perspective as a reverse engineer of Windows to know it better for programming, I see little-to-no point in wondering about Microsoft’s source code and even less in writing about it. What counts for me is the binary code that actually runs on computers and which my code will interact with—if there’s ever enough time left over from reverse engineering so that I actually do get to write my own code!

That said, I imagine the source code is similarly unimportant for the very different work of reverse engineering for computer security. What Microsoft puts in its source code—or what Microsoft’s programmers thought they put in the source code—is at best peripheral to what the malware exploits and even to what vulnerabilities might be found in advance to close before they’re exploited.

By saying peripheral I don’t mean to dismiss. Understanding source code certainly does have its place. Indeed, it may provide essential insight to how the hand-crafted part of the engineering left the malware with something to exploit. But it’s just not central to any reverse engineering as a study of software’s behaviour.

Of course, to read binary code efficiently, you better have a good practical sense for how binary code is generated from source code. For instance, you will read instructions faster if you’ve subsumed into your subconscious mind your knowledge of which sequences are the typical output of compilers, much like you can read English better for knowing which sequences of letters are generally accepted as English words. And much as you will read well-written English better for anticipating that the words will make an idiomatic sentence, so too do you benefit from knowing what larger-scale sequences to expect from a compiler’s treatment of local variables, conditional blocks, loops and exception handling.

Or maybe you don’t need any such understanding! Perhaps you do well enough to trust that your disassembler, decompiler or other such tools handle it all for you. Perhaps you can succeed at reverse engineering even if these tools’ output is as much magic to you as code generation is to most programmers.

WRITING IN PROGRESS