.PAC files?

[bushing]

I've been able to figure out that the .PAC files are written out to EEPROM by the "phat" executable, but I'll be damned if I can figure out what format they are in.

Anyone have any guesses?

Ben

[bushing]

Responding to my own post -- sheesh.

Okay.  Each .pac file has a 7-byte header:

Code: [Select]


struct pac_header {
   unsigned char firmware_name_h;
   unsigned char firmware_name_l;
   unsigned char firmware_version;
   unsigned char firmware_base_h;
   unsigned char firmware_base_l;
   unsigned char firmware_size_h;
   unsigned char firmware_size_l;
};


That yields the following headers for the .pac files:

Code: [Select]


firmware.pac:     name=0x3950 version=7 baseaddr=0x0ffd size=0x22b0
boot5.pac:                            name=0x0000 version=0 baseaddr=0x000 size=0x02e0
boot.pac:                             name=0x0000 version=0 baseaddr=0x000 size=0x02a8


Not much to look at, perhaps, but the sizes agree with the filesizes, at least.

I haven't been able to make any headway as far as interpreting the rest of the files.   I think i've been staring at hex too long ...

Also, it looks like the device is pushing out these pac files through /dev/ttyS1, which makes no sense at all to me  

Ben

[judb]

I didn't trace the second TX and RX ports of the Cirrus chip.. its possible the second serial port is connected to the 8052 controler to transfer the flash.... hmmm.

if thats the case, perhaps we could tap the serial port signal and dump the flash code during an upload that way?

My main worry is that the 8052 controller they use and the 7312 both support hardware encryption so the firmware in all likleyhood could be written to flash in an encrypted format.

[bushing]

 

I think you might be right.  There's a flag that gets set in phat to 3 if you're using an encrypted pac and 1 otherwise.

The only later reference to that value is in a routine that sends that number, out with the rest of the pac header, over the serial port as part of the programming routine.  So, that would suggest that the flag is getting looked at by whatever is receiving those bytes.

On a related note, if all of the flash in the system is in the .pac files, that's about 8k of storage for the bootloader to check signatures and boot linux. Is that realistic, or is there a fixed bootloader that is unflashable / we don't have a .pac for?

Ben

[judb]

Well, that really is a good question.  I don't know why they would have ever needed to update the boot loader so its likley that they dont reflash it.  That could be bad.

however if the bootloader is checking the sig files against another signature that would have to be stored somewhere in memory... like the flash code.. and we 8K of space as you calculate, that seems HIGHLY unlikley.

http://www.aleph1.co.uk/pipermail/yaffs/2003q3/000495.html talks about bootloaders and arm being about 8K but I doubt their bootloader code uses any encryption checking.  That would significantly increase the size of the bootloader.

Now, with all that said, i think I recall reading in the 8052 controler that it has an internal nvram or something which it might be using to store something like a sig file or more boot code.  who knows.  JTAG is the only way we would determine that I think.

[A543]

Just to remind you, there is ~ 128k of hidden code on each DMS. The code is identical on the two 10GB and one 20GB drives I've looked at.  Only the last ~256 bytes are different (which is also ~ the same size as the sig files).  Maybe the Phatbox boot code is analogous a PC's BIOS boot code, which is just enough to access the MBR on a drive.  And the hidden code on the DMS is equivalent to a PC drives MBR/BR, or more.  The last unique 256 bytes are the drives unique signature based on the serial number.

[judb]

you know what, that is a damned fine point.. I'd forgotten about that nugget!

8K would be enough to bootstrap to the correct sector instead of the MBR to begin loading the next part of the boot process.  Now the interesting thing is, does that portion of the drive get modified in ANY way using ANY of the firmware versions that are out there?  I mean is it possible that the firmware update process might modify that code section for any reason?

Edit: I hate the filter script.. I really dont like things changing what I said.

[RobM]

Just to remind you, there is ~ 128k of hidden code on each DMS.

Anyone have a dump of that code handy?  

[judb]

http://forum.phathack.com/cgi-bin/yabb/YaBB.cgi?board=dmshack;action=display;num=1110200457;start=14#14

should be able to extract it from there...(the two meg dump that is)