Talk:Hidden Protected Area

There is conflicting information on this page. In the introductory paragraph it says "The HPA was introduced with the R/T/X 40 series of ThinkPads." But on the bottom the X3x models are also linked as having this technology. What is right? --Rolf 12:30, 19 October 2006 (CEST)

Also I know an R50e machine, that has Rescue and Recovery on a Compaq Diagnostics partition. So it shouldn't be listed either on the bottom of the page. I'm just not too sure, if I understand those technologies correctly, so I hesitate to remove it.

Removing item "Accessing the HPA from Linux"

I've checked the fwdir code (http://colimit.googlepages.com/fwdir.zip). This code works on a Hidden Partition (is that the same as a R and R or yet another Predesktop variant?). This code can not work with real HPAs.

I suggest we remove this section in an week or so (or move it to the discussion section) unless further info regarding those Hidden Partition is provided.

Paul Bolle 01:08, 4 January 2007 (CET)

The fwdir page is quite clear that it does not access HPAs, but rather hidden partitions. I don't know if an HPA and a phoenix HP partition have the same internal layout (they could, and it would make sense; a partition does not have to contain a filesystem, it could contain an HPA image just as easily). Also, I have no idea if IBM ships the HPA as unpartitioned area, or as a hidden partition...

If you know the answer to the two implied questions above, you know what to do.

--hmh 03:22, 5 January 2007 (CET)

FirstWare Image Backup span file format

FWBACKUP creates an image set (a set of span files) of a Phoenix FirstWare HPA. FWRESTOR uses these span files to restore an HPA beckup image. (See the Predesktop Area white paper for usage information for FWBACKUP and FWRESTOR.) The format of a span file is straightforward.

Each span file consists of a plain (not compressed, not encrypted) copy of a number of (512 byte) sectors of the HPA. It is preceded by a 512 byte header.

The format of this 512 byte header is:

bytes   description
 0-  7  magic ("fwbackup")
 8-  9  1 (LSB first) # version number?
10- 11  span file number, one based (LSB first)
12- 13  number of span files in image set (LSB first)
14- 17  number of sectors in span file (LSB first)
18- 21  number of sectors in image set (LSB first)
22- 25  last sector of HPA on the original hard drive, zero based (LSB first)
26- 29  first sector of HPA on the original hard drive, zero based (LSB first)
30- 37  unused
38- 53  checksum
54-511  unused

Only bytes 10-11, 14-17 and 38-53 are unique for each span file. All other bytes of the header should be equal for all span files in an image set.

This magic entry for file(1) can be used to identify the files part of an Phoenix FirstWare HPA backup image file set:

# File magic for Phoenix FirstWare HPA backup image
0       string          fwbackup        FirstWare HPA backup image
# >8    leshort         # x             , version %d ???
>26     lelong          x               (first disk sector of HPA: %d,
>22     lelong          x               last disk sector of HPA: %d)
>14     lelong          x               %d of
>18     lelong          x                %d image sectors
>10     leshort         x               (span file %d
>12     leshort         x                of %d)

Paul Bolle 11:27, 7 January 2007 (CET)

Span File Header checksum

Each FirstWare Image Backup span file has a 16 byte checksum in its header. This checksum is a md5sum derivative. It is calculated over the backup image in that span file (i.e. everything following the header). It differs from a md5sum in two (minor and related) aspects. (I'll describe it here using the well known md5 implementation of Colin Plumb, which one can find easily with a Google Code Search.) Those differences are: -in MD5Transform you'll have to "swap" (0->3, 1->2, 2->1, 3->0) all 4 byte "in" values for all 64 invocations of MD5STEP; - in MD5Final you'll have to also "swap" both "bit lenghts" (again 4 bytes long) that are used just before the final call of MD5Transform.

These are trivial differences. Discovering these was absolutely non-trivial!

Mail me if you'd like some code (in c).

Paul Bolle 23:13, 24 July 2007 (UTC)

Migrating the HPA to a new hard drive (Windows)

The white paper referred to in the article describes a procedure for moving the HPA when upgrading the hard drive. The HPA partition can't be simply cloned because critical jump instructions used by the BIOS directly address sectors on the HDD, and thus depend on the drive geometry. (Therefore, migration to an identical replacement drive should be possible by cloning, but not to a larger drive).

The procedure involves running the system restore program residing on the HPA, interrupting it by using the (otherwise undocumented) F3 key, and copying FWBACKUP and FWRESTOR programs to a floppy disk. This may work on A series systems with internal floppy drives (with UltraBay 2000 or UltraBay Plus), but it doesn't seem to work for USB floppy drives, which are the only kind available for the R series (which has the UltraBay Enhanced internal drive, for which no FDD devices have been made available). The BIOS does recognize USB devices, and they are visible while running the system restore program, but any attempt to write to these devices fails (I've tried this with a USB floppy and a USB flash drive).

Does anyone have any suggestions for a work around? If not, I see no way to save the backup of the original system configuration when upgrading the hard drive on the R50p or similar machines. Slowthinker 21:15, 23 July 2007 (UTC)

---

I succesfully used the method Fabrice Bellet described. It's elaborate. Send me an email if you'd like further guidance.

Paul Bolle 22:50, 24 July 2007 (UTC)