Geoff Chappell - Software Analyst
Some of you who’ve written to me over the past year or so of my return to research and writing have asked if I might please tackle anything more widely relevant than all this kernel-mode stuff.
Yes, kernel-mode programming is all well and good—nobody lingers at this website except for being interested in how things work inside and even deep inside—but kernel-mode programming is unarguably highly specialised work, which Microsoft anyway makes ever more pointless for programmers to dabble in. (Even well-funded companies baulk at having to send to Microsoft a copy of a driver that they write to deploy only on their own computers.) Surely what real-world Windows programmers want is information that helps with user-mode issues. How about I turn my attention to illuminating some of its dark corners?
It’s a good point, and although this leopard is not about to change its spots, let me see if I have by now done enough kernel-mode preparation that I can at least try to start meeting you somewhere along the way to your practical user-mode concerns—and maybe write something about Windows that actually involves windows.
If you’ve been paying attention, you’ll know that one of my beliefs about reverse engineering is that although the security industry has somehow managed to develop it into some sort of commercial practice it is still too undisciplined for achieving more than the picking of low-hanging fruit. For all the money that’s nowadays thrown at reverse engineering in the name of computer security, when it comes to incidents that relate closely to the operating system (in contrast to more or less self-contained matters of application programming) reverse engineering in what has become its commercial practice shows little sign of ever graduating from hunter-gathering. Researchers scratch about for what information they can find as and when they need it for whatever analysis is currently their employer’s bread and butter. And then the industry at large kids itself—and consumers, insurers and politicians—that its reverse engineering for computer security aims high and reaches high.
Imagine a security researcher who comes across software that uses the windowing system in some way that will need to be navigated with care if they’re to get anywhere at all with understanding what the software aims to do (but gets wrong, or uses for mischief, or whatever). They will soon come across various objects that WIN32K.SYS builds in memory for use by USER32.DLL, by GDI32.DLL and by the software that’s actually being inspected. If the problem is an interesting one, there will be many objects of many different types being used in different ways for different purposes, possibly with subtle implications of how these objects are shared between processes. If each researcher is left to work out any significant amount of this from scratch, then each will soon be overwhelmed. I expect that if this doesn’t happen more than occasionally and trouble anyone but me, it’s because the security industry is oblivious of the problems it has become good at not tackling.
When a researcher is faced by some strange use of system functionality, it must be close to crazy to hope that they each find much as hunter-gatherers. Wouldn’t it go easier for everyone if a background understanding of the system functionality had been farmed or mined? Then, researchers could give their whole attention to their specific problem instead of first diverting to discover bits and pieces of background that would ideally be available to them as a found resource—and I could stop banging this drum!
So, to kick this off, as much as I feasibly can in time stolen from nights and weekends, here’s some background material on a smattering of structures that are prepared by WIN32K but are deliberately visible in user mode. Much of it is still rough. Very much more is in preparation.