Geoff Chappell - Software Analyst
The first public description that I know of the AARD code, by anyone, is in the following exchange of messages on a conferencing system called CIX that was hosted in the United Kingdom and was open to public subscription (for a fee, very much like Compuserve). Note that by description I mean an explanation of what the code does. The error message it presents would surely have been seen, and maybe even talked about in public, by possibly many DR-DOS beta testers before I ever knew of it, but I don’t know of any earlier public explanation than in this exchange. For an earlier explanation in private, again by me, see my record of AARD research as inferred from email with Andrew Schulman.
The only editing is that the AARD details are emphasised in bold for easy location by readers who aren’t interested in the context. I present the exchange with no further comment, except to direct attention to the date: the AARD details were presented in public as early as 8th June 1992.
>>>windows/development 4237 geoffc(1212)7jun92 15:32 c4202* > but to stop the competition from getting their >hands on the programs & disassembling the code. Are you saying that you have a copy protection scheme that prevents a PC from actually reading the distribution disks? There is a persistent belief that disassembly means running the code under a debugger to see what it does. The relevance of this to a Windows conference is the discovery that my copy of WIN.COM (and presumably every one else's) contains some 2KB of code and space designed to trap attempts to run Windows under a non-DOS. The code is real gobbledy-gook with lots of redundant instructions to make it seem confusing and a crucial part is encrypted. Most significantly, it installs handlers for the debugger interrupts (and NMI just in case you're using a sophisticated debugger) that are guaranteed to cause the unexpected should anyone attempt to step through the code. As far as I know, this is Microsoft's first stoop to the practice. Does it indicate defensiveness on their part or mere curiosity? My WIN.CNF (that SETUP copies to the SYSTEM subdirectory) is 16,112 bytes long - stamped 10/03/92 at 3:10. Would anyone with a different file please let me know. -- Geoff --
>>>windows/development 4241 djewell(223)8jun92 11:36 c4237* Geoff :- this sounds very interesting ! When you say > designed to trap attempts to run Windows under a non-DOS do you mean: > designed to trap attempts to run Windows under a non-MS DOS Dave (intruiged.....)
>>>windows/development 4243 geoffc(3013)8jun92 17:04 c4241* I don't know what I mean, but I reckon that every now and then I turn up something of reasonable interest. The story goes like this: The copy of WIN.COM that I have inspected is very interesting on a number of counts. Towards the end of the WIN.CNF component is some disguised code that checks to see that a standard MS-DOS is running 1. In the internal variable table (address obtained by int 21h function 52h), far pointers to the Handle-based SFTs, the standard input device, the standard clock device, the BUFFERS descriptor, the CDSs and the first device driver after NUL must all be non-zero. This would be the case for MS-DOS, but it is my vague understanding that it has not always been true for the OS/2 compatibility box. 2a. If a redirector is running (int 2Fh with AX = 1100h returns al = FFh), then the upper case mapping routine (sought, curiously enough, only for country = US) must lie in the DOS kernel data segment (value returned in ds by int 2Fh with AX = 1203h) OR 2b. Without a redirector, the offset address of the FCB-based SFTs must be zero. Again, both these are normally true for MS-DOS. The checks in 2a and 2b are encrypted (just a bitwise XOR) - the relevant section is bounded by "AARD" on both sides (and we all know which MS employee this suggests). For the whole test, interrupt vectors 01h, 02h, 03h are directed to a stub containing either int 21h or int 2Fh (depending on when) followed by an IRET, so single-stepping through this code or setting a break point or whatever will have curious effects (calling DOS functions when registers can't be known). The code is littered with red herrings - long and convoluted operations whose results are discarded - the whole style seems deliberately perverse. In the WIN.COM copy I've inspected, the code is executed but not acted upon (the message "non-fatal error #2761, contact Windows 3.1 beta support" or similar, with a press ENTER to exit, "c" to continue) unless a particular variable is non-zero. Static allocation has this variable as zero and it is not referenced anywhere else in the file. Two things. First, this copy of Windows is on a machine to which I have access but I do not know its provenance. It is hard to see where they could have got a beta version from, though. If the thing were for beta release only, it would have been stripped from the file rather than let it depend on a variable at run-time, surely? My guess (perhaps a little suspicious) is that Windows Setup patches the file in some circumstances. Second, I don't believe the whole thing to be a red herring, because I have seen a beta copy of HIMEM.SYS in which the code was active (and to prove it, I have a device driver that sets a temporary FCB-SFT with non-zero offset address to trigger the effect). The whole thing is very odd! May I refer you to the digest topic for a word or two on what must be the worst example of MS programming I have ever seen? -- Geoff --
>>>windows/development 4247 thines(218)9jun92 15:09 c4243* What you describe is in the current release copy of Win 3.1 that I've got here, including the "Please contact Windows 3.1 beta support" message! (The error number in my copy is #2726) Verrry interesting :-) | Tim |
>>>windows/development 4248 geoffc(305)9jun92 15:36 c4247 Thank you for the confirmation. I would really like to know how to proceed with this morsel, for I too find it interesting and am sure that one or two industry watchers would also. Most of the DOS bugs I know are going into my book but it's a little difficult to stretch this to Windows. -- Geoff --