PhatPatch - Firmware Patcher!!!!!!!!!!!!

[Surgeon]

I've erased and reprogrammed my box, but otherwise you're essentially correct.   Erasing and reprogramming REQUIRES a serial port since you get constant segfaults and kernel panics when running it.   It should be trivial to write a loader to flash a file off the hard drive to the firmware before the kernel starts.... there appears to be a kernel bug that's making life hard on us but it could be something we're missing. like a flakey compiler

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...

And could the segfaults be happening because interrupt routines are accessing the firmware while it's being reprogrammed? Maybe a system-wide "disable interrupts" while flashing might fix it? I know from programming other flash-based systems that they usually require reading the new code entirely into ram first (to avoid block-device access); disabling interrupts; then sending directly to the flash; re-enabling interrupts; then re-booting...

-Surgeon-

[RobM]

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...

I don't know if there's any checksum being done here at all.  However, any signatures that are being done are with SHA1 I believe.

And could the segfaults be happening because interrupt routines are accessing the firmware while it's being reprogrammed? Maybe a system-wide "disable interrupts" while flashing might fix it? I know from programming other flash-based systems that they usually require reading the new code entirely into ram first (to avoid block-device access); disabling interrupts; then sending directly to the flash; re-enabling interrupts; then re-booting...

I'm 99% sure that the firmware is not being accessed at all once the kernel is booted; there's no reference to it in the kernel at all.

[judb]

I seem to recall that aadec or phatd checks the firmware according to one of bushing's decodes...  

BTW RobM when you get a minute I need you to hop on IRC to talk about the boot CD kernel.. we got a few issues to fix.

[RobM]

I've compiled a 2.6.11.12 kernel with tmpfs support.  That should give us a good working area; it defaults to half of physical RAM which should be enough.

The updated image is: http://never.net/phatbox/syslinux_11.img

You'd still need to put the flash.tar file in the root, which might not fit now with the bigger kernel

[RobM]

I seem to recall that aadec or phatd checks the firmware according to one of bushing's decodes...  

BTW RobM when you get a minute I need you to hop on IRC to talk about the boot CD kernel.. we got a few issues to fix.

It's probably aadec because I've never paid much attention to that, but aadec will still play the sample content on my DMS...

I can't get on IRC from work, but I'll be on when I'm home (about 6:30 EST).

[judb]

after I updated your new .img file with my modifed initrd.gz its got 89k free. YAY!

I recompiled phatpatch and some things to shrink down the size quite a lot.

[RobM]

I had modified the initrd.gz on that image to add tmpfs to the /etc/fstab, increment the version, and change the path that it kept the tar and key image files in, FYI.  I didn't update the initrd.gz in that directory...

[bushing]

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

[judb]

Bushing, you got a few minutes to look at problem I am having with the latest flash utility release?  its going waiting... over and over in a log file.

its v4 from sbingners drop directory.  thanks.

Code Select Expand

PhatPatch v0.4 - original code by bushing, additional patches by sbingner
first 2 words of flash=c102 0025
writing auto-id command (AA, 55, 90)
Flash chip reports manufacturer id=c102, device id=0025
Resetting flash.
Testing patch locations:
Patch 1 @ 0bb8: make drive signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0033 1a00    Actual: 0033 1a00
Match! Programming...
PhatPatch v0.4 - original code by bushing, additional patches by sbingner
first 2 words of flash=c102 0025
writing auto-id command (AA, 55, 90)
Flash chip reports manufacturer id=c102, device id=0025
Resetting flash.
Testing patch locations:
Patch 1 @ 0bb8: make drive signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0033 1a00    Actual: 0033 1a00
Match! Programming...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...

[sbingner]

Flash chip reports manufacturer id=c102, device id=0025

It didn't accept the unlock codes, did you recompile it?  Try the one I sent you compiled

[GoodVibeGroove]

To: Rob, Sam, Jud, & Bushing (and everyone else who contributed) THANK YOU!  I am up and running on a samsung 100g BEAUTIFULY!  I will paypal a donation to the site as soon as I have a bit of spare cash.

[judb]

This thread is closed...  please see http://forum.phathack.com/cgi-bin/yabb/YaBB.cgi?board=dmshack;action=display;num=1122424315
for newest version of the patch process.

If you want to thank people, send them a PM, you can send PM's to mulitple people using commas between names.. or start a seperate back slapping thread.