Geoff Chappell - Software Analyst
Well into October I still had no idea where the month was going. One place it headed to—but didn’t arrive—in my writing of new pages on kernel-mode structures is the KSYSTEM_TIME. This 12-byte structure is on the one hand a simple dressing of a 64-bit time but is on the other the oldest survivor in Windows of early techniques for concurrent access without formal locking or waiting. In my opinion it’s much neglected, and in the worst way, with commentators glossing over the extra high part of the 64-bit time as if they and their readers understand it so well that it’s barely worth a mention. After a week, off and on, at trying to write something definitive, I say it’s not at all easy to explain! But much about timing in Windows is not. And I anyway have a long record of finding complexity in things that others happily pass over. For now, I add KSYSTEM_TIME to my much too large collection of aborted write-ups.
For diversion from my frustration at having not seen how to finish this one write-up, I picked up my occasional relocation of old pages on kernel structures. The aim is that these eventually are all arranged according to which of Microsoft’s headers they’re defined in—well, as much as this is revealed in the public symbol files, which is very much more than anyone but me seems to care about or perhaps even to have noticed.
Though it’s possible, and even likely, that the many unpublished headers whose existence (along with some content) Microsoft has been disclosing in public symbol files for the last decade are themselves generated from other headers whose existence is not recorded in the symbol files, what Microsoft has revealed about its organisation of source code has no small impact on the study of Windows. I mean this on two counts.
One is prompted by the occasional nonsense from someone, often a Microsoft programmer, claiming expert insight into whether correlation of supposedly reverse-engineered information with Microsoft’s source tree proves, or at least suggests, that the work was helped by access to source code, leaked or not. Though Microsoft certainly does have programmers who know precisely what sort of material goes into symbol files, most plainly don’t—if only because it’s just not what they work on—but this doesn’t stop some of them from speaking as if their work for Microsoft as programmers means they are uniquely well-informed about what’s possible for reverse engineers. That they then are widely believed is no help to anyone. If I were in computer forensics or software litigation, I’d worry for what such ready acceptance of such claims to expert insight does for standards of proof.
The second count is that reverse engineers can’t very well complain when the integrity of their work is impugned. Most don’t, of course, because they don’t care. Especially for computer security, what reverse engineering of Windows gets done is often under such pressure that the researchers grasp for whatever they can get, wherever it comes from, no questions asked—and a whole industry of people who in other circumstances might like to think they know better or would aim higher goes along with the expedience. Even the most prominent reverse engineers of Windows leave notably little record of where their information comes from. If they get accused of lifting it from the back of a truck, it’s because that’s very much how it looks.
My number one mission in what time remains to me is to get the reverse engineering of Windows onto firm ground. But I do feel very much to be the lone voice.
Relocating my pages about kernel-mode structures inevitably got me looking again at the many pages I have written, on and off, over many years, about Event Tracing for Windows (ETW). If you were looking for an example of undocumented Windows internals that Microsoft uses for its own products but might usefully be taken up into third-party products to develop a competitive market—in this case, of diagnostics tools or for security monitoring—then ETW is the poster child. A casual reader might think ETW is well documented, and some of it is, even copiously, but there is so much more to it and has been for decades. On this too I have long thought myself the lone voice, though I have of course suspected that some of the “so much more” is researched privately or is learnt from Microsoft, including under NDA. That an industry of Windows programmers has not got the power of ETW to wide attention is an enduring shame. I do what I can, but there’s only one of me.
Less in the foreground of my studies, and for much less time, is the rich functionality that has developed through the last decade for Processor Power Management (PPM). I’ve inexcusably let this pass by without writing about it. The security industry seems not to have had much interest, perhaps because what goes on is just a bit too far from easy exploitation. I try not to think like a security researcher but instead to look for opportunities for novel programming. There’s maybe not much of that here, either, and yet I can’t escape thinking that something in this topic might better have public interest—and so I make a little time for it.
Inevitably, writing about any per-processor feature gets me diverted to another of my occasional hobby horses: processors. Back in 2016 I noticed there was increased kernel-mode support for what Hyper-V does with processors. Others have since got interested for all their different reasons. Revisiting was irresistable.
Also inevitably, I didn’t finish anything like as much as I wanted! When I’ll get back to any of this, let alone with energy and time to finish what I’ve started here, I don’t know.