Geoff Chappell - Software Analyst
The first successful study that I know of the AARD code by anyone outside Microsoft, who wrote it, was by me on 17th April 1992. For all of anyone else’s talk of complexity or other difficulty, my records have my study of the AARD code in a pre-release build of HIMEM.SYS as done and dusted on the same day that I noticed the code’s existence.
E-mail with Andrew Schulman in late 1991 and early 1992 occasionally dealt with the HIMEM.SYS driver and its Extended Memory Services (XMS) interface in connection with my writing of DOS Internals, ISBN 1-201-60835-9, with Andrew as editor and his writing of Undocumented Windows, ISBN 1-201-60834-0.
It is perhaps as well to reveal here that what was eventually published as DOS Internals had been pitched in mid-1991 as DOS 5 Dissected. In my mind, it had only ever been intended as a selective examination of things that I had happened to find interesting (and hoped readers might also). In those days, my interests lay very much in memory management. That I would indulge this for the book was obvious from the start because DOS 5.0 had greatly enhanced both DOS’s own memory management and its involvement with external memory managers such as HIMEM.SYS.
The HIMEM.SYS that was to be included with the forthcoming Windows 3.1 was said to support a new version of the XMS interface, namely XMS 3.0. The big problem with this was that although the XMS 3.0 Specification turns out to be dated January 1991, I had not yet seen it and nobody anywhere had yet seen any implementation of it in any formally released software. Somehow—and I stress not from Andrew—I had got hold of a Windows 3.1 beta and set about studying its HIMEM.SYS, which was version 3.00. On 9th December 1991, I sent Andrew a list of XMS interface changes as I had come to understand them from inspecting this version 3.00 for changes from the version 2.77 that was distributed with DOS 5.0.
And there I left it for months! Work started full-time on the book in late December and although it became ever more clear that a book could not be written about DOS 5.0 without its also becoming a book on DOS’s growing support for Windows, there was not much I could sensibly do about a Windows 3.1 that was still months from being available for definitive study. Even once Windows 3.1 was formally released, which happened on 6th April 1992, it would inevitably be a while before I got a copy to study. As late as 15th April 1992, I was reminding Andrew that anything I say about Windows is still only about version 3.0.
On 16th April 1992 I sent Andrew my documentation of the XMS 2.0 implementation in HIMEM 2.77, as I proposed it for DOS Internals. Updating for the new HIMEM version from the now-released Windows 3.1 and its implementation of XMS 3.0 was important—and, of course, Andrew, said so straight away.
In e-mail that I saved for sending at 04:06 on 17th April 1992, I answered that for the purposes of documenting an XMS 3.0 implementation, “I have only looked through HIMEM 3.00 not 3.03, though I do have a copy of the latter.” As I recall it, I was less than eager to redo any study of anything from Windows 3.1 until I had got the properly released package. Already I had formed the idea that pre-release software is more trouble than it can be worth to me. Still, I looked.
In e-mail that I saved for sending at 19:57, I reported that I had “looked more closely” at HIMEM 3.03 and found that “This one contains a large amount of really stupid code (lots wasted, some encrypted with XOR)”. I attached a device driver that prepares an FCB-SFT block at a non-zero offset and I noted that “This condition triggers a message in HIMEM about contacting Windows 3.1 beta support.”
This “really stupid code” that I wrote about in this email is, of course, what Andrew later dubbed the AARD code. See that its need for the FCB-SFT block either to be missing or to be paragraph-aligned and canonically addressed is the whole of the code’s encrypted testing as built into HIMEM. The encryption is nearly trivial, but to get to it with the certainty of knowing that it’s what counts, you must also work out that the code’s other obfuscations actually are just obfuscation: I can’t have known to prepare an unaligned FCB-SFT block as the demonstration except by having understood all of the AARD code.
In the early morning of 17th April 1992, I seem not to have known of the AARD code’s existence in HIMEM version 3.03 and quite possibly hadn’t even prepared this HIMEM for study. In those days, and even still, preparation took non-negligible time. With no automated disassembler of any kind, my method then was to load the file into a debugger, work through it to distinguish code and data by sight, and then dump a clean listing. Only a few months earlier, my method had the extra encumbrance of printing the listing on continuous-feed paper to mark it up with pencil and straight-edge!
By the evening, it is clear that I not only knew the AARD code’s encrypted test but had also written a demonstration that made a true MS-DOS produce the error message for having failed the encrypted test.
The 16 hours (approximately) between the two e-mails therefore make an upper bound on the research effort, probably including preparation and certainly including the writing and testing of a demonstration (what we would now call a Proof of Concept). That working out the AARD code consumed all 16 hours is possible but improbable. Back then—for decades—I lived more or less nocturnally, having long before decided that since my work would repeatedly demand my attention late into the night, I may as well give in to it. Records show me as having sent or received e-mails at approximately 8pm and 10pm the night before and at 3am that morning, and then again at approximately 11:30pm that night. If I also worked on the AARD code from 4am to 8pm, when did I sleep!
Do not miss that it was only ever a fluke that the AARD code was looked at as early as April 1992 by one of the relatively few who at the time had both the curiosity and the disassembly skills to pick it apart as just a diversion.
For where to put the AARD code in the Windows 3.1 beta, Microsoft might have chosen anywhere but HIMEM.SYS. Even with it in HIMEM.SYS, I might not have been writing about HIMEM.SYS just then for a book on DOS or Andrew might not have pushed me to update for XMS 3.0 before there could be anything definitive to write—or I might have pushed back, saying I have neither time nor inclination to study pre-release software. Had any of these cases applied, I almost certainly would not have known of the AARD code until seeing it in WIN.COM from Windows 3.1 as formally released two months later.
For this formal release, had Microsoft removed the AARD code from WIN.COM, instead of leaving it to execute but with its outcome ignored, then I almost certainly would never have known of the AARD code from my own studies for my own interest—not in 1992 or 1993 or ever. I would only ever have known of it from someone asking me to look at it in the pre-release builds or from reading about it in a magazine, book, press release or court filings as someone else’s discovery and analysis.
But since Microsoft did leave the AARD code in WIN.COM, albeit as having no visible effect, I always was going to find it when I eventually got the released version to study.
Again from email to Andrew, I still did not have the formally released Windows 3.1 on 20th May 1992. Apparently it cost £88, which I just did not have for such a thing at the time! Still, I evidently did get a copy in the next week or two because on 2nd June 1992 I sent some “Changes to book now that I have seen a real Windows 3.1”. These were limited to HIMEM.SYS (now version 3.07) and EMM386.EXE. Remember that I was writing a book on DOS, not Windows. HIMEM and EMM386 had first call on my attention because they are useful for DOS even if you never will run Windows. Not for a few more days did I proceed to inspecting anything from Windows itself.
On 5th June 1992, I wrote to say I would “spend the next day or so” on WIN.COM, partly because “it now contains all sorts of task-switching support” but also because “it (like my beta HIMEM.SYS) contains a section of encrypted code and an error message recommending the user to contact beta support.”
How much time I spent on the task-switching support and how much on the AARD code, I don’t know. The one was substantial and new to me, against which the other was slight and familiar. Except that the AARD code in the released WIN.COM has a second test in its encrypted part, the AARD code itself is not architecturally different from what was linked in to the pre-release HIMEM.SYS. Though it cannot have presented any difficulty, the code from which WIN.COM calls the AARD code and acts on its results is more substantial than corresponding code in HIMEM.SYS and has obfuscations of its own. It will therefore have required some new study, but let’s please not overstate it.
On 7th June 1992, a bulletin board that I subscribed to happened in one of its conferences to talk about copy-protection schemes that “stop the competition from getting their hands on the program & disassembling the code.” I was interested to know how such a scheme stops the code from being read. You do not need to run code to study it. You do not need to step through it with a debugger. If you can get the same code that’s loaded into memory for execution, then you can disassemble it. I took this as an occasion to mention that WIN.COM has code that has been written to frustrate debugging but which presents no difficulty worth talking about for disassembly. Thus did my revisiting the AARD code in the released WIN.COM produce the First Public AARD Details on 8th June 1992.