Assuming that the firmware is just verified via a simple 16 or 32 bit cksum value is there any "uninitialized" code area near the end of the rom containing a bunch of 0xff values? If so, then wouldn't it be possible to alter 1 (or 2) of these bytes enough to get the original cksum to again be valid? If not then maybe another byte or two in the now "unused" signature-invalid code sequence could be altered for the same purpose. I know I've used these tricks on other embeded systems I've hacked in the past...
The design of this system always manages to surprise me ... anyway.
You'd think there would be some checksumming of the bootloader, but the only place that does anything of the sort is aadec, which is used to play Audible content.
The bad news there is that they're not using a checksum; they're doing a hash of the contents of flash using, of all things, TEA
http://en.wikipedia.org/wiki/Tiny_Encryption_Algorithm in a hashing mode. And finding hash collisions is hard.
On the other hand, they're only doing this over the first 256 bytes of the bootloader, which seems like a pretty half-hearted attempt to me? (There's notihng particularly interesting in that part of the bootloader, just a couple of utility routines and a jump to the rest of the loader.) They're not even doing a check on that hash, per se, but rather it's being used as an input to an algorithm that comes up with a key to use to decrypt an encrypted player key from pkeysa.e, which is then used to decrypt Audible content.
The fact that this is such a weak attempt, combined with the use of a strange algorithm, leads me to believe that it's only being done out of contractual obligation to Audible. Maybe the only purpose of that check is to make sure that aadec is running on something that remotely resembles a PhatBox, and not some other ARM-based player. In any case, we have no need to modify that part of flash.
On the other hand, Audible content will still probably break if copied from one drive to another, because another input to that algorithm is the drive id. Without wanting to provoke the wrath of 100 DMCA-wielding lawyers, I can think of at least 3 ways to trick that ... but on second thought, that shoudn't even be necessary.
That same reliance on the drive id would prevent you from copying Audible content from one real DMS to another, and that's probably the point. I bet that you could use the PhatNoise Media Manager software to delete it off the "real" DMS and then copy it back onto the "fake" DMS, and it would update the keys appropriately with the fake DMS's drive id (model id and serial number), and it would work just fine.
Ben
