Geoff Chappell - Software Analyst
The topic that was my diversion for August got ever more involving. I really could do without such diversion. I have well over a hundred other pages that have been in the limbo of “in preparation” for months now and which I must complete before next month, when I stop this research and writing and instead start in earnest to look for paid work as a consulting programmer. Yet I could not let go of Shim Database (SDB) Files. As I contemplated completing my write-up of the Kernel Shim Engine in its relatively new role of involving Windows itself in the hooking of calls to and from kernel-mode drivers, there was always at the back of my mind that although this particular aspect to the topic offers no particular difficulty in the research, something outside my write-up was leaving me deeply dissatisfied.
The problem was partly the practical one of keeping the write-up to the interesting, and even vital, material on the integrity of kernel-mode drivers without getting drawn into the sprawling topic of Application Compatibility. As much, though, was that I disliked what I could find on the Internet as other people’s research and, indeed, what some of those other people wrote to tell me about, perhaps as if I should not only know of it but appreciate it. Add that this subject has been around for 15 years or so, with obvious implications for computer security but an apparent lack of high-quality attention despite its being the subject of a few conference presentations, and it got me thinking again about the nature of reverse engineering and its current state as academic research.
Oh, and along the way, I did my first writing in twenty years or so for anywhere other than my own website. It is titled Where Is ShimDBC.exe? and is published separately as PoC||GTFO 13:9.
Discovery of Microsoft’s Shim Database Compiler—that’s the ShimDBC of the preceding title—opened the prospect of de-compiling real-world SDB files not to XML that some reverse engineer just makes up but to XML that re-compiles. As far as I can tell, nobody has yet attempted this. To do it in all the imaginable generality would be a huge amount of work, not so much for the de-compiler as an exercise in programming but for working out what to de-compile to. The DRVMAIN.SDB file, however, uses only a small subset of the defined SDB tags, such that de-compiling it specifically is just about manageable.
On the way to understanding what sort of XML might be Microsoft’s “source code” for SDB files—or even, to begin with, whether Microsoft actually does prepare SDB files from XML input—it helped to understand some undocumented APPHELP functionality that prepares a properly formatted XML file from information obtained as SDB tags.
Reverse engineering certainly has come along in leaps and bounds over the last five years or so, at least for work that meets the needs of the computer security industry. But reverse engineering of operating systems, just as a technique that programmers might do well to have in their arsenal so that their programs can be developed with more confidence and less trial-and-error, seems to be as much in the Dark Ages as ever. And I anyway can’t shake the feeling that although the computer security industry may be doing well at picking up the lowest-hanging fruit in the greatest quantity for the least cost, it is perhaps not developing the subject either for deep understanding or wide public utility.
Take the SDB file format. Since this governs an increasing variety of run-time changes that Windows itself makes to programs, and now drivers, you might think that security implications are plain. Microsoft certainly thought so, apparently right from the beginning. Microsoft’s TechNet article Windows XP Application Compatibility Technologies from 2001 notes of the SYSMAIN.SDB file that
While software vendors, IT managers, and developers can use the existing fixes, they are not permitted to create new ones. This limitation is by design and is intended to reduce the risk to system security posed by allowing non-Microsoft parties to inject potentially harmful code into the loading process.
If those words of Microsoft’s don’t count as announcing to the computer security industry that SDB files should be watched closely and understood well, then whatever would? How much of Microsoft’s “not permitted” is down to keeping the file format hidden behind an API? Isn’t even the suspicion of security by obscurity supposed to be a red flag? In this context I think it’s entirely fair to say that surprisingly little has ever been published about the SDB file format, and then to ask how come.
Some of the answer will be that those who have the skill and support are spread too thin. As much as reverse engineering has developed commercially, the practice of it is directed at very particular software, as for malware analysis, and very particular problems such as vulnerabilities. Much of it is commercially viable only because that which can’t at least be semi-automated is kept to a very narrow scope. For the very different work of hunting down details over the relatively large scale of an operating-system feature and then writing them up for general consumption, the number of reverse engineers who are ready, willing and able—including being well-funded and free to publish—is perhaps not much greater than it ever was. They can’t cover everything.
Yet where operating-system features do get covered in public, I wonder about the interests, priorities and incentives. The relatively little that seems yet to have been published about the SDB file format arguably falls into two broad categories. First, there are programs out and about on the Internet which dump an SDB file into more or less plain text, typically into XML, for easier review. (Perhaps also out there, but kept secret by hackers, are tools that then convert an edited dump to a valid SDB file to install on an “owned” computer.) Second are the extant projects that attempt to create some type of substitute Windows. These each support a selection of APPHELP functions but also attempt to reproduce Microsoft’s implementation in terms of SDB files. In all these cases, source code is provided, and it is clear that the authors know at least something, even quite a lot, of the file format. But none of this actually does document the file format.
ESSAY IN PROGRESS