MBR and Boot Records Index
The Starman's
Realm Index PageProof
that Power Quest®'s Partition Magic
can alter HDD 1st Track Reserved Sectors
Copyright©2005 by Daniel B. Sedory
We've been collecting data on this for many years, and finally decided it was time to show others our conclusions; especially since (to the best of our knowledge), no one else has published on this.
The series of Power Quest® (now Symantec®) Partition Magic programs from at least version 4.01 through the latest version 8.0 running under either DOS (from a diskette) or Windows™, will write certain bytes to at least one sector within the first HDD track (also known as the 'Reserved' area) whenever they are run!
The actual reason(s) for Partition Magic to behave this way is still unknown to us. One plausible explanation might be that PQ only wanted the software to know if it had ever been run against any HDD before. Tests prove that simply running their program (without using it to make any changes to a drive) is all that's required for it to write to an acceptable sector on your HDD. Whether or not the bytes have any other meaning, we can easily assume that Partition Magic has been used on a drive by simply looking for "28 96 C4 17" within the first 63 sectors! [Note: We can see no significance in these particular four bytes, nor why they were chosen by the PQ programmer(s); unless it was only because this combination was unlikely to appear in any code normally found there.]
Normally
the answer would be: No! (However, one reader wrote to us saying that
PM always messed up his system after using it! After examining what was
happening on his system, we verified this one exception*)!
Our tests have shown that Partition Magic will not write to any
sectors in the Reserved area unless at least one of them
is completely filled (all 512 bytes) with the same byte value! This could
be 00h (or 22h as we used); and we would assume, any other byte value. Thus,
the PQ programmer(s) appear to have included a precautionary measure
against overwriting any important data that might be stored in the first track
of your HDD; such as, DDO software and Boot Managers.
Since Partition Magic has this 'safety feature' let's call it (unlike what we've read, but have not confirmed, about some versions of Intuit®'s TurboTax™ with SafeCast that indiscriminately overwrote any data in Absolute Sector 32), and since we also ran Partition Magic when it could not write to any of the sectors in the Reserved area, we must assume that these bytes are not important to the functionality of the program.
____________________
*There is one exception:
If you use a free boot manager called SBM (Smart Boot Manager;
which appears to no longer be supported by any of its creators!), that particular
program sets aside two sectors as a table for listing all the bootable OSs on
your system. Unfortunately, one of those sectors contains nothing but zero
bytes for most users. Thus, Partition Magic assumes the sector
isn't being used and writes its signature bytes (28 96 C4 17) to that
sector. When you reboot the system, SBM tries to interpret those bytes
as a new bootable OS and has a fit over the incorrectly written
data it finds there! All we can suggest to SBM users at this time is to write
to Symantec (the new owners of PQ's Partition Magic) and complain about them
writing what appear to be useless bytes inside their boot manager's data table!
If we could find anyone to support SBM, we would of course suggest that they
should have placed at least one signature byte of their own inside that sector!
In each case, we started with a drive that had every sector filled in with a 22h byte (we often use Non-zero bytes to fill our drives, so any zero-byte writes can also be detected!). For all three versions we tested (4.01, 7.0 and 8.0), the preferred sector to write to was Absolute Sector 10 (CHS 0,0,11). However, if we changed any of the bytes in that sector; such as inserting the signature Word AA55h (the bytes "55 AA") into its last two bytes, Partition Magic would then search the next sector (CHS 0,0,12) and so on, until it finally found an acceptable sector to write to (one having all the same bytes). If Partition Magic couldn't find any sectors to write to between CHS 0,0,11 through 0,0,63 inclusive, it would then go back to Absolute Sector 1 (CHS 0,0,2) and continue searching until it had tried Absolute Sector 9 (CHS 0,0,10), before giving up completely!
First Pass: Sectors
10 (0,0,11) through 62 (0,0,63).
Second Pass: Sectors 1 (0,0, 2) through 9 (0,0, 9).
When Partition Magic 4.01 was simply run (no changes made) against our test drive, it created the following pattern of bytes at offset 190h in the sector it wrote to (normally CHS 0,0,11):
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F |
The "hh" bytes shown in these tables are whatever byte value the whole sector had been filled with. Just as we said about the "28 96 C4 17" bytes, we have no idea what these "FF" bytes mean, and can only guess that the "04" at offset 19Ch and the "01" at offset 198h might possibly be the major and minor parts of its version number. Unfortunately, the other versions we tested did not produce any byte values like this one, so there's not much we can say about them. Partition Magic versions 7.0 and 8.0 had only zero bytes (00h) in most of these locations, just as version 4.01 did after we used it to create a new partition on the drive, so you will most often see a Partition Magic sector-entry like this:
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F |
If you have any additional information that could be helpful in understanding the use of these Partition-Magic-bytes, please contact us.
Last Update: July 4, 2005 (04.07.05)
You can write to me using this: online
reply form. (It opens
in a new window.)
MBR and Boot Records Index
The Starman's
Realm Index Page
