{"id":22,"date":"2022-11-29T12:14:00","date_gmt":"2022-11-29T12:14:00","guid":{"rendered":"https:\/\/thebrokenpipe.com\/blog\/?p=22"},"modified":"2026-04-28T11:03:14","modified_gmt":"2026-04-28T11:03:14","slug":"reverse-engineering-pc-dos-1-00s-bios-and-boot-sector","status":"publish","type":"post","link":"https:\/\/thebrokenpipe.com\/blog\/reverse-engineering-pc-dos-1-00s-bios-and-boot-sector\/","title":{"rendered":"Reverse Engineering PC-DOS 1.00’s BIOS and Boot Sector"},"content":{"rendered":"\n

I wanted to get familiar with the IBM PC INT 1xH<\/code> BIOS interrupts and explore how they’re actually used in practice, all in preparation for a challenge project. Reverse engineering the BIOS of PC-DOS seemed like the perfect exercise – the DOS BIOS handles all input and output for the DOS kernel and applications, so it naturally relies heavily on the PC BIOS INT 1xH<\/code> interrupts. Plus, reverse engineering tends to give a much deeper understanding than just reading documentation online. Since I was already going to be digging into the BIOS, I figured I might as well reverse engineer the boot sector too.<\/p>\n\n\n\n

So, which version of the PC-DOS BIOS and boot sector should I go with? To keep things simple, it made sense to start with the earliest version – PC-DOS 1.00. Conveniently, there was already a fully annotated disassembly of its BIOS<\/a> and boot sector<\/a> by Michael Steil<\/a>. That said, this was primarily a learning exercise for me, so I avoided referring to his work while doing my own. As an added challenge, I wanted my disassemblies to produce binaries identical to the originals when assembled using the original assembler.<\/p>\n\n\n\n

Reversing the BIOS<\/h2>\n\n\n\n

The first step was extracting the DOS BIOS from the diskette image. I opened the PC-DOS 1.00 disk image in a hex editor and noticed there’s no BIOS Parameter Block (BPB) seen in later FAT filesystems. I could’ve added a BPB, but I took the simpler route and extracted the BIOS directly using the hex editor. It’s the first file after the root directory. This also saved me from having to deal with system and hidden file attributes. I saved the extracted file as IBMBIO.COM<\/code> and loaded it into IDA Pro.<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n\n\n\n\n

IDA identified the file as an MS-DOS .COM<\/code> binary and set the processor to MetaPC, which handles all x86 opcodes. Since it’s an 8086 binary, I switched the processor to Intel 8086 to make sure the disassembly was accurate.<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

Here’s where it got interesting – IDA only recognised about 30% of the file as code, while the rest was marked as data (brown for code outside of functions, blue for functions). That seemed off. Notice the org 100h<\/code> directive? That’s standard for all .COM<\/code> binaries, but why?<\/p>\n\n\n\n

In DOS, a Program Segment Prefix (PSP) is placed at the start of each code segment, so .COM<\/code> files are loaded at address 100H<\/code> within their segment. However, the PSP is set up by DOS and the Command Interpreter – both of which run after the BIOS. That meant the BIOS should have been loaded at segment 60H<\/code> offset 0<\/code>, not 100H<\/code>, as there’s no need for a PSP nor something to create its PSP. I rebased the program and re-ran the analysis.<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

Anything unusual? Definitely. At the start of the code, there are 10 long intra-segment jumps. Assuming execution begins at 0060:0000<\/code>, the first jump would go straight to 0060:0165<\/code>, leaving the other 9 jumps unused.<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

I suspected those other 9 jumps are for DOS to call via the far inter-segment CALL<\/code> instruction. But what exactly do they do? Luckily, there’s a fascinating document called “Customizing MS-DOS Version 1.23 and Later”<\/a> available on Bitsavers<\/a>. On the very first page, I found this listing:<\/p>\n\n\n\n