Anyone with a PC can prove this!
1. Using DEBUG[3] under MS-DOS or Windows™ (even Windows 10[3])
A. From any IBM® or Microsoft® DOS prompt, you would simply type, debug, to enter this program.
B. Under a Windows™ OS, such as Windows™
XP, you can either open a CMD window first, then enter debug, or if it's easier for you:
Click on the start button, then click on "Run...", type debug in the box and click on OK. This will pop up a
virtual DEBUG window.
|
||||||||
2. Under a Linux OS (or a BASH shell under Windows 10)
Most other PC operating systems, including Linux, do not have as easy to use a
debugger as MS-DEBUG, since it is an 'interactive' assembler and debugger (with a memory dump function) all in the same program. However,
it's still possible to prove the correct way to refer to the hex byte sequence "55 AA" by creating a small binary file in linux with NASM or
as (the GNU Assembler) or some other assembler, using assembly instructions equivalent to those above,
then dump its contents with the command hexdump -Cv <filename> to view the actual sequence of the
hex bytes stored in the file; and therefore, in memory (or on a hard disk). One could also use a GUI hex editor; such as Gnome's GHex, so 'hexdump'
isn't mandatory. Here are some steps for doing so in an Ubuntu:
1. Open a "Terminal" (also called 'Command Line') window; on
our Ubuntu 10.04 LTS install, under the "Applications" menu, choose "Accessories" and then Terminal. The following should also
work equally well at any linux prompt; even a command-line only install (provided it has an assembler).
2. Enter at the prompt: whereis nasm hexdump; and if both are already installed, you will see something similar to: nasm: /usr/bin/nasm /usr/share/man/man1/nasm.1.gz
hexdump: /usr/bin/hexdump /usr/share/man/man1/hexdump.1.gz
3. If one or both are missing, then you'll only see "nasm:" and/or
"hexdump:" and will need to install the missing program(s). Under Ubuntu (or the Windows 10 BASH shell), you would enter: sudo apt-get install nasm and/or: sudo apt-get install
nasm to install either of these programs.
4. Unlike MS-DEBUG, where all digits in a data declaration (db or dw) are always
hexadecimal, NASM interprets plain digits as being decimal. So in NASM, we must either prepend "0x"
or simply append an "h" to indicate a hexadecimal data byte (db; 8 bits), word
(dw; 16 bits) or double word (dd; 32 bits). But Note: Any hex number that begins with A through F must have a zero (0) prepended to it.
5. If you're running a Gnome Linux install, you can use gedit to create the following plain text file and save it as "test.asm"; otherwise use nano, vi or whatever other text editor you are familiar with
(nano is the easiest Terminal editor to use; you can cursor copy the following directly into it)[4]:
db 255 ; NASM converts 255 to the hex byte FF, proving
; plain digits are taken as decimal values.
db 0 ; A zero byte to keep the data on Word boundary.
dw 55aah ; How some books and articles refer to the MBR's
; Signature ID. But look at the byte order this
; creates in the hexdump of 'test' below. The
; assembler will reverse it into: AA 55.
dw 0x55aa ; Another incorrect way of representing the ID.
dw 1234h ; As noted above, this word will appear as: 34 12
; when you dump the binary output file 'test'.
dw 43605 ; Decimal 43605 = 0aa55 hex. But a PC stores this
; number as 55 AA as seen in the hex dump below.
dw 0aa55h ; This will prove the correct way to write the MBR
; Signature ID as a 'WORD' when followed by an 'h'.
; Note: A-F requires a leading zero(0).
dw 0xaa55 ; Another correct way to write this ID 'WORD'.
db 55h ; The clearest way to describe the Signature ID:
db 0aah ; Enter each byte separately, in this order.
|
Remember to save this as "test.asm".
Note: Anything written after a semi-colon (;) is ignored by the assembler; these are comments.
6. Now enter the command: nasm test.asm to assemble it; which creates only a small binary file of the name: test
7. Lastly, open the binary file, test, in a hex editor, or enter the
command: hexdump -Cv test and you should see the following:
00000000 ff 00 aa 55 aa 55 34 12 55 aa 55 aa 55 aa 55 aa |...U.U4.U.U.U.U.| 00000010 |
Which again proves that using "0x55AA" in any kind of PC assembly program will not produce the hex digits "55 AA" but rather the opposite!
Doing the work above on a Windows 10 PC in a special Ubuntu BASH shell:
(If you have any problems with the steps above, please contact us.)
Why is this error so prevalent?
Early Documentation used incorrect Hex Word for Signature
When the first IBM® Personal Computer™ became available in 1981, it had no hard disk and no concept of a boot record signature in its operating system. It wasn't until the introduction of IBM® Personal Computer™ DOS 2.00 in 1983 that this Signature "55 AA" appeared in boot sectors[5] on floppy diskettes. Note: The first IBM documentation for PC DOS 2 [Number 1502143, part of the "IBM Personal Computer, Computer Language Series, Disk Operating System," "First Edition (January 1984) Version 2.10"] does not contain this Signature anywhere within its pages. That manual does, however, refer to another one which does: It is the "Disk Operating System Technical Reference by Microsoft Corp." [IBM document Number 1502346, "First Edition (September 1983) Version 2.10"].[6] On page 8-9, this work states: "The last 2 bytes of the boot record (hex 55AA) are used as a signature to identify a valid boot record. Both this record and the partition boot records are required to contain the signature at offset hex 1FE."
Later IBM manuals appear to have taken the poorly worded description of the Signature bytes from
that Microsoft® manual and turned that phrase ("hex 55AA") into the erroneous hex word (55AAH)
in the "First Edition (April 1987)" of IBM's "Technical Reference
(Programming Family)" for the "Disk Operating System Version 3.30" in "Chapter 9. Fixed Disk Information"; located on following pages (quoting the sentences that include them for proper context):
"Signature: The last 2 bytes of the boot record (55AAH) are used
as a signature to identify a valid boot record. Both this record and the partition boot records are required to contain the signature at offset 1FEH."
(p. 9-9),
"Each extended volume contains an extended boot record in the first sector of the
disk location assigned to it. This boot record contains the 55AAH signature id byte." (p. 9-12)
and
"The last two bytes of the extended boot record (55AAH) are
used as a signature to identify a valid boot record. Both this record and the logical drive boot records are required to contain the signature at offset
1FEH." (p. 9-14).
Although it's only a guess, we suspect this erroneous hex Word (55AAH) for the Signature ID became part of the IBM documentation simply because an employee assigned the task (and/or a manager who may have provided the final "corrections") was unfamiliar with the little-endian nature of the Intel processor used in the PC to realize they were making a mistake. (Remember: Most, if not all, IBM computers up to that point had a big-endian architecture.) Sadly, this error continued to be perpetuated within IBM's documentation for so long, that many today believe this must be the correct way to refer to the Signature ID bytes on a PC. However, if someone takes a class in x86 assembly, using MASM[7], NASM[8], TASM[9] or any other x86 assembler, they will quickly learn the truth.
Journalists and computer book authors must often rely upon the documentation from a manufacturer, so we're sure this is the main reason so many writer's comments about the signature ID contain this error; yet another reason for their reluctance to correct it. Unfortunately, Microsoft® made things worse by apparently deciding to come up with an excuse to actually consider this error as acceptable usage in their documentation! We have written a great deal more about their very confusing notes[10] below.
Erroneous Examples
If you search the Net for the terms "Sammes", "Jenkinson" and "55aah", you should find a link to Google Books for page 170 of the second edition (page 142; 1st edition) of Forensic Computing, A Practitioner's Guide, by A. J. Sammes, Tony Sammes and Brian Jenkinson. Although the comments there and in Table 5.25 (page 143 of 1st ed.) relate to loading additional BIOS code, such as that for a video adapter card or some 'Expansion ROM', these 'Add-Ins' still use the same 2-byte Signature found in the MBR sector, except it's located in the first two bytes of its code rather than at the end; as you can see in this 64-byte dump of location 0C0000h and following from a PC's Memory:
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 0C0000 55 AA 5A E9 CB AA 30 30-30 30 30 30 30 30 30 30 U.Z...0000000000 0C0010 30 30 C4 17 E9 DD 16 BD-40 00 B0 0A 30 30 49 42 00......@...00IB 0C0020 4D 20 56 47 41 20 43 6F-6D 70 61 74 69 62 6C 65 M VGA Compatible 0C0030 20 42 49 4F 53 2E 20 03-5B 00 6B 00 79 00 8B C0 BIOS. .[.k.y... |
Twice on page 170 and again on 171 (in footnote 66), this book makes reference to these bytes
using the incorrect hex Word, 55AAh. [These same errors began in the book's first edition (pages
142-143).]
On page 174, at the end of the 3rd paragraph, we find the clear comment: "the
final two bytes of the partition table are always of value 55h and aah, as shown." Unfortunately, this second edition, added a footnote
(# 71) just before this, which reads: "Many systems will refuse to boot if these two bytes are not set to 55aah."
Adding more incorrect occurrences. The publisher of this book (Springer) is a prestigious company, and its authors are quite knowledgeable. Since the
authors discussed the topic of little-endianness at length in chapter 2 and elsewhere; including sections of chapter 5, why did they use an incorrect
hexadecimal number when describing the two-byte Signature of 55h and AAh on a PC? We have been unable to contact the authors, so don't know for
sure, but they probably did so simply because so many others have.
DO YOU HAVE ANY EXAMPLES TO SHARE?
Does using the wrong number even thousands of times make it right?
No!
AA55H is hexadecimal for 43,605 and 55AAH will
always equal 21,930; whether you simply write these numbers on a piece of paper, or store them on either a little-endian PC or a big-endian
computer, they are not the same number. A number is a number, period; whether it's binary, decimal or hex. And changing the type of
computer (from one endian-type to another) that a number is stored on, does not change one number into another, or our digital society would be in
chaos! It merely changes how the representation of a number's bytes must be ordered in a storage media of the different computer types. When we see the
characters "0x" followed by a string of digits, we must logically conclude they represent one, and only one, hexadecimal number; a number
which we could also convert into equivalent decimal, octal or binary representations of the same number whenever we need to! If someone wishes to use
different symbols to define some "little-endian hex representation on a PC" that's their choice. But pre-pending "0x"
or appending an "h" or "H" to one or more hexadecimal digits is already a well-defined standard.
A signature though, of two or more bytes in length, must never be separated from the concept of byte order. In other words, once we define some string of bytes as a signature, we should maintain the same order of its bytes whether it's being stored on a big-endian or little-endian computer; yet this also means the same signature would need to be represented by different hexadecimal numbers on these two different types of computers, since each one stores multi-byte numbers differently. However, because programmers and software engineers already know this, signatures in common file types are handled as character strings in PC code. Characters, as opposed to numbers, always remain in the same order in which they are displayed or given in the code, whether found on big- or little-endian storage media! For example, if you enter the following into either DEBUG or assemble it under NASM or some other assembler, the byte order will never change:
db 'This is a character string.'
db 'NTFS' ; These 4 chars. will always remain in this order.
db 'U',0xaa ; Another way to enter the MBR Signature ID,
; since 55h is the ASCII code for 'U'.
; Unfortunately, there is no standard
; ASCII character for 0xaa.
And remember, as we've seen above, an Option ROM or Boot Record (or any other kind of) signature is not required to be expressed as a number. Technically, it's just an indicator or identification, and could just as well be handled as two separate data bytes; in this case, a 55h followed by AAh (or: db 55h, AAh in x86 assembly code). The main reason these two bytes show up more often in the literature as a single Word (0xAA55 or 0AA55h), is simply because it's easier, and more logical, to compare two hex Words in a single line of code rather than using two separate lines of code for each byte. We'll examine some actual assembly code below to clarify this.
Therefore, we'd advise any authors who need
to describe a signature (apart from books on assembly language), to list each byte as it's found on some media or in memory, rather than attempting
to use a hexadecimal number comprised of more than a single byte.
Assembly programmers do not make this mistake
Students who pass a class in x86 assembly (or even you, if you studied the proofs above) know the truth, and so did the early programmers at Microsoft® who used this "Signature ID" in their code. For example, here's a bit of commented MASM source code which checks if a valid boot record signature ID exists; followed by two lines of code that define where and what it should be:
; The partition table is located at offset 1BEh in the sector. ; The signature is located at offset 1FEh (= 55h, AAh or word AA55h). TestBootSignature: cmp WORD PTR [BX + 510],0aa55h ; Check for 55 AA sequence #define BOOT_SIG_OFFSET 510 #define BOOT_SIG 0xaa55
The cmp instruction above, compares the WORD pointed to (PTR) at offsets 510 and 511 decimal to the hex word 0aa55h; which could have also been written as, cmp WORD PTR [BX + 510],BOOT_SIG, if BOOT_SIG had been previously defined as 0xAA55. Here's another snippet of code that checks for an Option ROM:
mov ax,0C000h ; look for 2nd graphics card installed mov ds,ax cmp word ptr DS:[0],0AA55h ; DS:0 -- check for option ROM
You can clearly see we need to write the hex Word as "0AA55h" to check for the byte sequence "55 AA" of either an MBR's signature, or the beginning of a video card's BIOS (as we saw in Fig. 2 above). And one last example:
;---- Check for ROM signature ---- cmp es:[di],0xAA55 ; Is the ROM signature present? jne NotOptionRom ; If not, jump out.
If any early DOS programmers had used the erroneous 55AAh in their code, the operating system would not have functioned correctly! People who merely write about such things, rather than those who assemble working code, are the ones more likely to make mistakes that may never be corrected.
Footnotes
1[Return to Text] [Table 1.] The original IBM® Personal Computer ("PC") or any IBM PC-compatible (whether its CPU is an Intel®, AMD® or some other manufacturer's processor), has what's known as a little-endian architecture; as opposed, for example, to the big-endian architecture of the Motorola® processors in a Macintosh or PowerPC system. (Note: Many Apple™ OSX computers today are being sold with Intel® processors having little-endian architecture.) This Little-endian architecture refers to the order of the bytes found in memory (or on a storage medium) for hexadecimal numbers composed of more than a single byte; where the least-significant byte will occur at a lower (or preceding) location than its most-significant byte (or any more significant bytes in-between). Thus, the Hex number, 38DA75C6h, as seen in a PC's memory would occur as: C6 75 DA 38 (each byte, but not the bits in a byte, when moving from a lower to higher location in memory, would be found in reverse order); whereas, a Big-endian system would have: 38 DA 75 C6. The creators of the first 16-bit Intel® processor used this little-endian order so the CPU could start working on arithmetic problems as soon as the first byte of a large number was accessed; basically the same as we do when adding the least-significant digits of two large numbers first, carrying any remainder over to the next column on the left, and finally adding together the most-significant digits, on the far left, last.
2[Return to Text] In all fairness, some authors may not become aware of this truth until after publishing a book. Thus a sizable cost would be involved in correcting this error; and the publisher might not agree to changing it even in a second edition. But they should at least be honest enough to include it in an errata note somewhere on the Internet. For those who never actually produce printed books; only create web pages or some other digital form of their works, hopefully they will be able to find enough time to correct this error if it appears in their work.
Some authors, however, may make excuses and "shift the blame" onto some large company, stating they won't make any changes unless that "well-known company" changes their documentation first! Obviously, such writers are not real classroom teachers nor actually do assembly programming!
3[Return to Text]
If you like what you see above, we have a complete Guide to DEBUG here.
Note: If you are using Windows™ 10 or a 64-bit version of the Win 7 (or later) OS, you will not find DEBUG at your Command prompt; it
was removed from all 64-bit versions (it was only in the first 32-bit version of Win 7). However, there have been a number of DOS emulators and even
free 'Virtual PC' programs which would allow you to install DOS or even an earlier version of Windows; such as XP, inside your current 64-bit OS, in order to
prove this! A much easier solution might be to install the free emulator pce; we would recommend searching
Hampa's download page for the file: "pce-0.2.2-xt-pcdos-3.30.zip" ("An IBM
PC/XT 5160 with PC-DOS 3.30") which includes DEBUG in PC-DOS 3.30. You may also wish to install "BASH On Ubuntu On Windows" under your Microsoft
Windows 10 OS: Yes, you can run some useful Linux commands/programs right on top of your Win 10 desktop! But PCE is definitely much easier to install.
4[Return to Text] We have Dennis German to thank for pointing out that our original NASM example had produced an output with the data on non-word boundaries; which would preclude the correct use of hexdump's optional -x or -d parameters. But, neither of those options is helpful in demonstrating the problem being confronted here, since the -x option regroups the bytes as words: Thus, an assembly entry of 0xAA55 is displayed as AA55.
5[Return to Text] We have much more information about various MBR and Volume boot sectors here.
The following shows how we described the Boot Record Signature on our pages about Partition Tables:
|
Table 1. This should remove any confusion over what constitutes a valid Boot Record signature; sometimes called its Magic number, and often expressed as the 16-bit hexadecimal Word, 0xAA55 (or: AA55h) for the little-endian[1] PC. |
|
|||||||||||||||
6[Return to Text] The Microsoft® PC DOS 2.10 work (Number 1502346) can be found here: 1502234 PC Technical Reference Apr83, and all the other IBM Technical Reference manuals can either be found at the BitSavers library there, at bitsavers.org or at minuszerodegrees.com.
7[Return to Text] Microsoft® Macro Assembler (MASM).
8[Return to
Text] The Netwide Assembler (NASM) was originally written by Simon Tatham
(with assistance from Julian Hall), but is now maintained by a team led by H. Peter Anvin. It's available as free software under GNU Lesser General Public
License. See 
http://www.nasm.us/ for more information.
9[Return to Text] Turbo™ Assembler (TASM) by Borland; no longer maintained. Here's a FAQ about TASM.
10[Return to Text] Please read our note on Microsoft's very confusing way of referring to hex numbers on their web sites and in some of their documentation by using a nonstandard definition for little-endian Hex numbers! Although we were happy to see at least one author at microsoft.com who'd dropped the incorrect 0x usage and simply listed the hex bytes in order with spaces between them (as we've done on our own boot record pages), many others continue to reference the same illogical note under their tables which use erroneous hex numbers.
So, we're presenting another analogy here to illustrate how wrong that concept is. The note is often worded as follows: "Numbers larger than one byte are stored in little endian format or reverse-byte ordering. Little endian format is a method of storing a number so that the least significant byte appears first in the hexadecimal number notation." (Searching microsoft.com or any of its related sites for the phrase "Troubleshooting Disks and File Systems" should turn up some links to pages with this note).
First, we agree with everything in the note up to the words in red; that's where they err. The little-endianness of a PC has absolutely nothing to do with "hexadecimal number notation" as this note claims! If you want to enter the hex number 0x3F (63) as a double-word (i.e., as 4 bytes; quad-words are 8 bytes), you could simply write "dd 0x3F" and an assembler would know it needed to reserve 4 bytes for this data (it would store this as: "3F 00 00 00"). But you would never enter 0x3F000000 since that would be a completely different number!
Yet some Microsoft employees think it's correct to write something like this: "The sample value for the Relative Sectors field in the previous table, 0x3F000000, is a little endian representation of 0x0000003F. The decimal equivalent of this little endian number is 63. The sample value for Total Sectors is 0x41D31200, which represents 0x0012D341. Therefore, in decimal, there are 1,233,729 sectors in the volume."
To show just how ridiculous this is, I propose a similar "definition" to theirs, but dealing with money: "All currency values larger than $9 are stored on my PC in reverse-order. This format is a method of storing the least significant digit first in decimal dollar notation! So, the sample value for our Relative Taxes in the previous table, a full $1,056,964,608.00, is a little endian representation of $63.00. The hexadecimal equivalent of this little endian amount is 0x3F dollars. The sample value for a Microsoft employee's income is $26,292,224.00, which represents $233,729.00. Therefore, in hexadecimal, he earned 0x39101 dollars." That's really not much different than what I quoted from Microsoft above; saying that two different dollar amounts represent the same thing, or that two different hex numbers are the same, is an equally insane way to approach this topic.
Wouldn't it confuse you if various banks and lenders started using my "dollar notation" (which you can't even tell is any different than normal dollars by looking at the symbol) for their assets, revenues or savings with only a little footnote redefining what everyone normally takes for granted? Didn't something similar to that happen here in the USA when criminals "cooked the books"?! That's why it's best to use a standard correctly.
Created: February 25, 2009 (2009.02.25)
Updated: June 27, 2009
(2009.06.27); January 15, 2011 (2011.01.15); December 7, 2014 (2014.12.07); February 21, 2016 (2016.02.21); September 28, 2018 (2018.09.28).
Last Update: April 14, 2023 (2023.04.14); added sources for IBM PC DOS 2.10 and the "IBM PC DOS Technical Reference Manual."
You can write to us here: contact page (opens in a new window).
MBR and Boot Records Index
The Starman's Realm Index Page