Detecting DOSBox from Within the Box

Detecting DOSBox from within the Box

If you're the sort of person who reads blogs, I assume you need no introduction to DOSBox. It's an MS-DOS emulator, which necessitates it being a sort of x86 emulator. But unlike x86 emulators like 86Box or QEMU, the DOS parts are an inextricable part of it. There are BIOS interrupts and a POST, but not a BIOS in the sense of "a ROM chip mapped into memory." There isn't even really a DOS, in the traditional sense. But when you're running inside DOSBox, you wouldn't know it. Almost any DOS API you can expect is available, and effort was put into making sure features like Long File Names don't appear if your reported version is too old to have supported it. So how can you detect that which seeks not to be detected?

Most MS-DOS-likes aren't perfect replicas of MS-DOS, and you can usually use those quirks or extra functions to figure out what you're running on.[1] And one would imagine DOSBox is the same! "Quirks" are more likely bugs waiting to be resolved, but commands like MOUNT and VER seem to have the ability to poke through to the outside world, so maybe there's an extra function somewhere?

Easy Mode: The Correct Way

Okay, I know you're screaming it at your screen: the simplest way is to just get the string at FE00:0061 —which everybody knows is the common Award BIOS version string address[2]—and check if it starts with DOSBox. But that's so brittle, y'know? I could just modify a non-DOSBox BIOS to have that version string, or modify DOSBox to have the model string be something else. There's even a comment in DOSBox-X (source) that alludes to this being a desirable change in the future:

/* TODO: *DO* allow dynamic relocation however if the dosbox-x.conf indicates that the user
* is not interested in IBM BIOS compatibility. Also, it would be really cool if
* dosbox-x.conf could override these strings and the user could enter custom BIOS
* version and ID strings. Heh heh heh.. :) */

So of course I can't take this route! There are other easier ways, like checking the serial number of the Z: drive (or if it exists, for that matter). But these can all be faked pretty easily. No, we must find something that's an inherent part of the emulator. Something that proves this is DOSBox.

Inventing Instructions

Let's go back to how DOSBox can talk to the outside world with commands like MOUNT.COM. COM files are just machine code, meaning we can run it directly through a disassembler. So let's do that, with a copy of MOUNT.COM from DOSBox:

$ ndisasm MOUNT.COM
00000000 BC0004 mov sp,0x400
00000003 BB4000 mov bx,0x40
00000006 B44A mov ah,0x4a
00000008 CD21 int byte 0x21
0000000A FE db 0xfe
0000000B 3805 cmp [di],al
0000000D 00B8004C add [bx+si+0x4c00],bh
00000011 CD21 int byte 0x21
00000013 02 db 0x02

The first four lines make sense: INT 21h Function 4Ah shrinks the stack to 0x40 paragraphs (128 bytes). But the next couple lines are... basically garbage. db 0xfe just means "there's a byte here, 0xfe", and your typical x86 CPU would balk at this and throw an Invalid Instruction exception.

But when you're writing an x86 CPU, you can just invent your own instructions! Lo and behold, in the DOSBox sources:

/* Snippet from src/cpu/core_normal/prefix_none.h */
CASE_B(0xfe) /* GRP4 Eb */
{
GetRM;Bitu which=(rm>>3)&7;
switch (which) {
case 0x00: /* INC Eb */
RMEb(INCB);
break;
case 0x01: /* DEC Eb */
RMEb(DECB);
break;
case 0x07: /* CallBack */
{
Bitu cb=Fetchw();
FillFlags();SAVEIP;
return cb;
}
default:
E_Exit("Illegal GRP4 Call %d",(rm>>3) & 7);
break;
}
break;
}

This is the code for decoding the FE group of opcodes. 0x00 is INC and 0x01 is DEC, both real opcodes on x86. But that last one, 0x07, that is a DOSBox exclusive. The word after the opcode is used to say which callback should be called...back, and breaks out. So, to fix up the disassembly from earlier, it might look like this:

00000000 BC0004 mov sp,0x400
00000003 BB4000 mov bx,0x40
00000006 B44A mov ah,0x4a
00000008 CD21 int byte 0x21
0000000A FE380500 CallBack 0x0005
0000000E B8004C mov ax,0x4c00
00000011 CD21 int byte 0x21

Aside: Tripping and falling into the weeds of x86 Instruction Encoding

In the first draft of this, I wrote: "I'll try not to trip and fall into the weeds of x86 instruction coding". But the way the callback opcode works is directly because of how x86 opcodes work. And I don't feel like it's fair to expect anyone to know how x86 instructions are encoded. I want my ramblings to be at least somewhat accessible, even if I've already thrown assembly code at you in the first half.

If you already know or don't care how this works, feel free to skip this. If you're really curious, my primary source here is Volume 2 of the Intel 64 and IA-32 Architectures Software Developer's Manual. Machine code is split up into quite a few parts, with the opcode itself only being one-and-a-half. For the sake of conciseness, we'll ignore everything but the opcode, ModR/M, and Immediate bytes, since that's what we're using here.

Let's take a snippet of that earlier disassembly:

0000000A FE380500 CallBack 0x0005
0000000E B8004C mov ax,0x4c00

and turn it into hex: FE 38 05 00 00 B8 00 4C. Without a prefix of 0F, we know the opcode is just FE. But this is a group, "INC/DEC Grp 4," which uses the Opcode bits of the next byte, the ModR/M byte, to actually determine the opcode. That byte is split up like this:

Byte: 00 111 000 (0x38)
Mod: 00 (0x00)
Opcode: 111 (0x07)
R/M: 000 (0x00)

For our purposes, only the Opcode field matters. So this can be read as FE /7. According to the Opcode Extensions table, this doesn't actually exist. Only FE /0 and FE /1 exist in this group. But we know DOSBox supports a secret FE /7, so we'll have to rely on its source code to know what to do next. And it does this:

Bitu cb=Fetchw();
FillFlags();SAVEIP;
return cb;

Importantly, Fetchw() fetches the next word and returns it (effectively, telling the machine "call this callback"). Since x86 is little-endian, 05 00 becomes 00 05. Once the callback is complete, the next instruction is called. That'll be B8 00 4C. B8 is MOV AX,XXXX. This instruction takes a 16-bit immediate, which is the 00 4C value (4c00 in little-endian).

Anyway, here it is in the part of the code that generates virtual programs like MOUNT.COM:

/* Snippet from src/misc/programs.cpp */
static Bit8u exe_block[]={
0xbc,0x00,0x04, //MOV SP,0x400 decrease stack size
0xbb,0x40,0x00, //MOV BX,0x040 for memory resize
0xb4,0x4a, //MOV AH,0x4A Resize memory block
0xcd,0x21, //INT 0x21
//pos 12 is callback number
0xFE,0x38,0x00,0x00, //CALLBack number
0xb8,0x00,0x4c, //Mov ax,4c00
0xcd,0x21, //INT 0x21
};

Conveniently, since callbacks are returned the same way as the general status, FE 38 00 00 is effectively a four-byte NOP! On DOSBox, anyway. Other x86 CPUs won't have such fortune. Since the 80186, invalid instructions trigger a #UD (Undefined Opcode) exception, or Interrupt 06h. So we just need to write an exception handler.