Rob, Sam, Jud + I got together on IRC tonight, and somehow were able to hammer something out.
We are having trouble writing to the flash chip on the PhatBox -- we can get out a few bytes at a time, and then the box hangs. This is okay, because I wrote a program that can make a 1-byte change to the bootloader, which is enough to bypass the drive signature check and allow you to use any drive you want.
It should go without saying that this at your own risk...
Bushings manual method for people with serial access (http://wiki.phathack.com/Patch_your_bootloader)
Scripts to do this for you (http://wiki.phathack.com/Script_to_run_firmware_patch)
-b
(edit by jud to link to scripts, change name of thread some and sticky this bad boy..)
sweet, I just finished reflashing mine over about 300 kernel panics.... and it works beautifully now w/ sig or without... I wouldnt reccomend that method to anybody though, it requires the serial port. We may want to make a flash writer for loading a new flash off hdd using boot_rom and serial port, or even just having the code to flash the rom loaded in place of linux... the actual flashing works fine its just that the kernel gets pissy. We could even take what you did here to get the loader to load a flasher instead of a kernel :)
I am going to test this out on one of my phatboxes using the serial port to watch it, then I'll write some scripts that can be used to run all this stuff and add to the wiki the info on it.
Be back shortly.
Okay it works! WAY TO GO GUYS!
I need somone to test the scripts that I built to do this. They seem to work on my box but it is already flash patched from the command line to make sure I had all the commands for my scripts correct.
Any testers?
ALSO -- To be specific about what this patch acomplishes, YOU CAN RUN ANY DRIVE YOU WANT IN YOUR PHATBOX OR KEG!!!! You cannot run modified code yet. This patch disables the drive signature check but NOT the .sig file checks of the boot loader of files in the phatsys partition or the fact that phatd checks them as well.
I am sure in due time we'll put together a method to do those too if there is demand for it.
As it stands right now though I think this may be the safe method to go with to keep phatnoise from playing whack-a-mole on us... You cant steal audible music like this I think. The hdparm will still return the real serial number of your drive so you cant play back music that was written to another drive.
This may break new audible content from being written to the new drive as well but I don't know how PMM does its encryption to the drive serial in windows. So just have it safe to say that Audible will likely not work at all on a modified drive.
If you do this patch you can still you an old valid DMS (if the sig is intact) and play audible content off it just fine...
http://wiki.phathack.com/Script_to_run_firmware_patch
Enjoy.. let me know if you have trouble with this or have suggestions on how to change it. :)
Also if anyone wants to host the file on their own site, I highly suggest that you do in case somehow mine gets removed.
Thanks!
Congratulations guys! Great work!! Awesome effort!
I predict NewEgg will soon be out of stock on large notebook harddrives.
I saw in the WIKI that drives larger than 127gb haven't been tested but has anyone actually tried something larger than 80gb? I can't see any reason it wouldn't work, but I figured I ask before placing my order.
BTW, $160 for a 100gb Toshiba sure beats $400.00+ for an 80gb.
I'll be headed to frys shortly to buy as big of a drive as I can there.. I'll post a trip report in a few hours. :)
Hmm, it didn't work for me.
Here is my bootload.log:
BOOT0-1: OK
BOOT0-2: Failed
It still seems to be checking the sig against the serial number. Does this require NO sig on the drive? I'm attempting to get my non-phatnoise but keyed (wrong key of course) drive to work. The original drive seems fine.
when you tried to use the utility did it log anything into /log ? perhaps the script i gave you is hosed somehow and it didnt really run the phatpatch flash utility?
hit me on IM or on the IRC channel I'll be around all day.
QuoteI saw in the WIKI that drives larger than 127gb haven't been tested but has anyone actually tried something larger than 80gb?
Not yet - let us know. I expect that a new kernel will be needed to support drives > 127GB. Somebody could probably test that now on the bench using a 3.5" drive.
I think PhatNoise published the diffs from the stock kernel that they use to build their kernel, so it should be possible to build a newer kernel with 48-bit LBA support. The only sticking point might be whether anybody bothered to add 48-bit LBA support to the IDE controller used in the PhatBox - is it integrated in the ARM, or a PC-style component?
its a XILINK XC9572XL, its some CPLD chip.. dunno if we can update it or not.
Great work everyone! :-)
Is this going to work with all versions of the Phatbox then (I've got the VW/Audi one). Anyone tried it yet/got any ideas?
Congrats on a good hack!
Quoteits a XILINK XC9572XL, its some CPLD chip.. dunno if we can update it or not.
Hmmm. I wonder if it is just being used as a glorified parallel port to talk to the drive? Do we have the PhatNoise-supplied kernel change file around here somewhere? It would be interesting to see if the kernel config references a "stock" Linux IDE driver or if they wrote their own...
The second Xilinx chip is only present on some of the PhatBox boards (check the pictures in the Wiki's Hardware FAQ). Mine doesn't have it, and the kernel is configured to access the IDE drive with the stock Linux IDE driver as a regular memory-mapped device.
It appears to have been replaced with a pair of 74245 ICs (and some other general-purpose logic chips) in the later board revisions, probably to reduce cost.
http://downloads.phathack.com/sbingner/images/c710-front.jpg
http://downloads.phathack.com/sbingner/images/cx910-front.jpg
Quote
Hmmm. I wonder if it is just being used as a glorified parallel port to talk to the drive? Do we have the PhatNoise-supplied kernel change file around here somewhere? It would be interesting to see if the kernel config references a "stock" Linux IDE driver or if they wrote their own...
http://downloads.phathack.com/sbingner/linux-2.4.18-phatbox-req.patch
Okay, its verified, I have a 100 gig seagate 5400 rpm 8 meg buffer drive from Frys (179.99 (20 bucks off normal price) in my DMS now.
I'll post the exact steps I used..
QuoteHmm, it didn't work for me.
Here is my bootload.log:
BOOT0-1: OK
BOOT0-2: Failed
As far as I understand my own hack, the only way the code can possibly generate the message "BOOT0-2: Failed" is if the patch didn't successfully execute i.e. your bootloader is unmodified.
It looks like judb's sweet script logs the output of the phatpatch utility -- would you mind posting the contents of your PHTSYS\log\phatpatch.log file? Also, feel free to try repeating the whole process-- it won't hurt anything, and in fact, it will generate output that can prove whether or not it sucessfully patched the firmware last time, as well as give us helpful info about your model of flash chip, etc.
-b
We got it fixed. there was a problem with the way the files got extracted.
big updates to http://wiki.phathack.com/Script_to_run_firmware_patch
Goes over how I got the new drive to work. its a bit more involved that I expected but its really not as hard as it may sound on the first glance over that wiki entry.
So not being a programmer and having some basic computer skills. How & where do I start with adding a non-OEM DMS to my Phatbox?
Is there a complete write up with step by step? I've already got a Fujitsu 60gb HD that I've been wanting to use.
QuoteSo not being a programmer and having some basic computer skills. How & where do I start with adding a non-OEM DMS to my Phatbox?
Is there a complete write up with step by step? I've already got a Fujitsu 60gb HD that I've been wanting to use.
See my post above. Follow the link to the wiki (http://wiki.phathack.com/Script_to_run_firmware_patch).. and read over the whole thing at least one time BEFORE starting. Print it out if you dont have two computers because you'll be rebooting your PC to do it.
Anyone should be able to do these things without having any programming or computer repair skills. Knowledge of a screwdriver is required. :)
Great job guys! Freedom at last...
Can I suggest that anyone who makes use of this patch make a donation to the running of this site as per this earlier thread...
http://forum.phathack.com/cgi-bin/yabb/YaBB.cgi?board=help;action=display;num=1119315190
It's the least we can do to say thanks!
Edit (Paul): I appreciate the gesture and will put to good use any donations that come in as a result if this post. However, let me make it very clear that Firefox said "DONATION." In no way are you asked, required, or expected to "Pay" any amount of money for any of the information on this board. Remember the user agreement to become a part of this forum which stated that "No information contained in or brought to light by this forum will be used for commercial purposes." Thanks - and sorry to hijack your post!
Sony Phatbox DMS OWN3D!
Just spun up an 80GB OEM 2.5" drive from Fry's in the Phatbox. Works GREAT!! Excellent work, boys! Also, I was able to salvage an original 60GB drive from Phatbox that had been rendered useless by a repartition/format under Windows. Below are a couple of comments on the process along with a dump of the generated logfiles in case you are interested.
Thanks again, guys! I bought this 80GB drive back a while ago and was in disbelieve that it wouldn't work and even more increduous when I found out it was because of the protection BS. Woohoo!
Matt
* Note that the first half of the instructions with respect to patching the firmware must be done with a known good and working standard DMS
* Didn't work the first try. Got "PLY1-FlashPhatbox" then time count. Never went to the second play list. Powercycled everything, then got "" playlist on "disc 1" for about 3 seconds, then jumped to Playlist2 with music.
* On second try, there were two files in the "log" directory:
-------------------------------------------------------------
patch.log:
--------------------------begin----------------------------
backing up drive signature
2048+0 records in
2048+0 records out
backup drive sig complete
starting patch
/dos/backup/patch.sh: 8: Syntax error: Bad fd number
backing up drive signature
2048+0 records in
2048+0 records out
backup drive sig complete
starting patch
/dos/backup/patch.sh: 8: Syntax error: Bad fd number
----------------------------end----------------------------
-------------------------------------------------------------
phatpatch.log:
--------------------------begin----------------------------
PhatPatch v0.2 -bushing
first 2 words of flash=c102 0025
writing auto-id command (AA, 55, 90)
Flash chip reports manufacturer id=0004, device id=22ba
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: 0000 1a00
Mismatch!
Verifying:
Patch 1 @ 0bb8: make drive signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00 Actual: 0000 1a00
Verified!
----------------------------end----------------------------
Interesting that the patch got a bad device number error the first time it ran. hmm.. any ideas bushing?
The rest of the logs look good though. Glad its working for you. I'll update the wiki with the info saying a KNOWN GOOD drive to make that crystal clear.
The logs above are from the *successful* update. The first failed update didn't generate any logs...
Matt
QuoteThe logs above are from the *successful* update. The first failed update didn't generate any logs...
Matt
Actually, from the logs you posted it looks like it worked the first time around.
The kernel might just have "oops"ed after successfully writing the flash the first time.
It should also be noted that in the very early version of the scripts it would replace your flacplay with the original version if you followed the instructions. now I have removed that function incase people have issues with the first attempt at flashing.
If you choose to copy the PHTSYS from the old dms to the new dms then make sure you remove the flacplay and flacplay.sig that you copied from my scripts so it doesnt keep patching your flash .. it can cause the box to freak out when you flash it sometimes so you dont want to have it do it over and over.
QuoteIt should also be noted that in the very early version of the scripts it would replace your flacplay with the original version if you followed the instructions. now I have removed that function incase people have issues with the first attempt at flashing.
If you choose to copy the PHTSYS from the old dms to the new dms then make sure you remove the flacplay and flacplay.sig that you copied from my scripts so it doesnt keep patching your flash .. it can cause the box to freak out when you flash it sometimes so you dont want to have it do it over and over.
Well, once it's modified it won't try to modify it again so it shouldnt cause any problems.... but it's still not a good idea
I had the same experience as Matt with the "8: Syntax error: Bad fd number" and "Mismatch!" messages (with a Success the second time round).
First time the Phatbox just sat there for several minutes flashing the disc light and no audio. I jumped to another playlist (audio played as normal) so then I shut it down. I guessed either it was unpatched (and OK) or patched but hadn't reported it. However the fact that it had "hung" suggested that the process probably hadn't worked.
So I then disconnected the Phatbox, powered it up again and selected the "flash" playlist for a second time - and it worked exactly as described... maybe the flash routine is slightly glitchy at the moment but it doesn't appear to do any damage when it doesn't work (if, in fact it isn't working the first time).
Btw mine is an Audi Phatbox, (80GB Samsung disc!)
I've got firmware version 3950.7 for my Audi Phatbox. Is this the lastest and where can we find the lastest firmware release? I thought my latest Audi firmware was version 7.02, and that 3950.07 was what I got from the radio head unit in the Function Menu.
just put the DMS into the cradle and in the PMM use the update feature to get the most recent firmware downloaded.
In this step:
From PHTSYS\backup copy p0.* to PHTDTA\profiles\default ... This will make the first playlist that the phatbox plays execute the patch.
Do I copy all 4 of these files to that folder?
p0.sig
p0
P0.idx
p0.pbx
I also noticed that in the file P0.idx in your replacement files that the letter "P" is capitalized. Did you mean to capitalize that letter?
I'm asking A LOT of question because I'm re-writing the HOW TO from a beginners stand point.
I just wanted to post a little text about the log file and what you should expect to see.
PhatPatch v0.2 -bushing
first 2 words of flash=c102 0025
This should always read like that - c102 0025 -- and indicates that it successfully found the flash chip.
writing auto-id command (AA, 55, 90)
Flash chip reports manufacturer id=0004, device id=22ba
These two codes indicate the manufacturer and model number of the flash chip -- they shouldn't affect anything, but I'm trying to track which chips they've put into these things, and it could help if some chips refuse to flash.
Go look here: http://wiki.phathack.com/Hardware_FAQ#Flash_ROM, and PM me if you have an ID code not listed there, and I'll add it.
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: 0000 1a00
Mismatch!
Here, it's checking to make sure that the location it's about to patch is what we expect it to be. If it's not, it won't write anything.
Regarless, it will press on:
Verifying:
Patch 1 @ 0bb8: make drive signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00 Actual: 0000 1a00
Verified!
Here, the "Verified" part indicates that the chip has successfully been patched. What this indicates is that the chip had already been patched before the program ran.
The reason you'll see this is, as I mentioned at the top of the thread, the PhatBox usually crashes right after flashing, for some unknown reason. When it does that, it won't usually leave a log file - so running it again will product the above log file.
QuoteIn this step:
From PHTSYS\backup copy p0.* to PHTDTA\profiles\default ... This will make the first playlist that the phatbox plays execute the patch.
Do I copy all 4 of these files to that folder?
p0.sig
p0
P0.idx
p0.pbx
I also noticed that in the file P0.idx in your replacement files that the letter "P" is capitalized. Did you mean to capitalize that letter?
I'm asking A LOT of question because I'm re-writing the HOW TO from a beginners stand point.
yes you are correct, copy all files pX.ZZZ ... the PMM created those files, not me, so as for the P vs p i dont think it matters. let me know what you have come up with and I'll check it out and update the wiki with it. thanks!
So do I navigate on my DMS, when its in the car. To "Playlist 1" and thats the script that runs the flash?
If so I did that and it first said "Corrupt Track" and went on to the "Playlist 2" on my DMS. I went back to playlist 1 again and this time it didn't play any songs but just scrolled thru a bunch of numbers like 1, 2, 3, 4, 5, etc. and then went on to playlist 2 again. I paused the DMS for a minute and then turned it off, waited for the lights to go out on the Phatbox. I brought it inside put it in the DMS cradle.
I didn't/don't see a file called: bootload.log
But I did see one called "log" on the PHTSYS partition, is that it?
I looked in that "log" folder on the PHTSYS partition where there were a couple files.
1) logs-go-here: where nothing was written in it.
2) patch: acking up drive signature
2048+0 records in
2048+0 records out
backup drive sig complete
starting patch
/dos/backup/patch.sh: 8: Syntax error: Bad fd number
backing up drive signature
2048+0 records in
2048+0 records out
backup drive sig complete
starting patch
/dos/backup/patch.sh: 8: Syntax error: Bad fd number
backing up drive signature
2048+0 records in
2048+0 records out
backup drive sig complete
starting patch
/dos/backup/patch.sh: 8: Syntax error: Bad fd number
backing up drive signature
2048+0 records in
2048+0 records out
backup drive sig complete
starting patch
/dos/backup/patch.sh: 8: Syntax error: Bad fd number
backing up drive signature
2048+0 records in
2048+0 records out
backup drive sig complete
starting patch
/dos/backup/patch.sh: 8: Syntax error: Bad fd number
backing up drive signature
2048+0 records in
2048+0 records out
backup drive sig complete
starting patch
/dos/backup/patch.sh: 8: Syntax error: Bad fd number
backing up drive signature
2048+0 records in
2048+0 records out
backup drive sig complete
starting patch
/dos/backup/patch.sh: 8: Syntax error: Bad fd number
3) phatpatch: PhatPatch v0.2 -bushing
first 2 words of flash=c102 0025
writing auto-id command (AA, 55, 90)
Flash chip reports manufacturer id=0004, device id=22bf
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: 0000 1a00
Mismatch!
Verifying:
Patch 1 @ 0bb8: make drive signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00 Actual: 0000 1a00
Verified!
Did my DMS flash the Phatbox correctly?
If you apply this patch can you update your firmaware at a later date if a newer version comes available?
It depends on if phatnoise decided to try and attack our method of DMS hacking or not. I would say at this point its 50/50 ...
That said, I don't expect many if any firmware updates out of phatnoise in the future as they are really not developing for this product line anymore.. they stated as much in as few of words on the now dead forums they used to host. Sorry.
MTS yes it looks as though it did. The verified line at the bottom of the second log shows it verified the patch is applied.
Also, we should have a new CD based method available tomorrow or the next day at the latest to simplify the work involved so that anyone can do this mod without really knowing much other than plugging the DMS in and using a phillips head screwdriver to swap the drives out.
Great work guys!
A few of questions if I may since I like to understand what's happening when I apply patches like these...
First, the patch itself simply changes a "jmp (condition), offset" instruction to now have a zero-offset, effectively removing the unwanted "jmp" effect, correct?
Second, we are able to accomplish this without first "erasing" the eeprom because we are simply "turning off" additional bits, whereas if we needed to "set" bits in the code we would first have to "erase" the flash block back to all 0xff and then re-program the entire block, correct? This implies that once "patched" there is no going back until a full "erase-block & reprogram" util is developed, right?
Third, is there not a firmware "cksum" somewhere that should also be updated to reflect the changes made to the code? Has this "patch" been tested through full "cold-start" (usually when a POST is run to verify the firmware)?
Congrats again on the *TERRIFIC* job done by everyone involved!
-Surgeon-
QuoteGreat work guys!
A few of questions if I may since I like to understand what's happening when I apply patches like these...
First, the patch itself simply changes a "jmp (condition), offset" instruction to now have a zero-offset, effectively removing the unwanted "jmp" effect, correct?
Second, we are able to accomplish this without first "erasing" the eeprom because we are simply "turning off" additional bits, whereas if we needed to "set" bits in the code we would first have to "erase" the flash block back to all 0xff and then re-program the entire block, correct? This implies that once "patched" there is no going back until a full "erase-block & reprogram" util is developed, right?
Third, is there not a firmware "cksum" somewhere that should also be updated to reflect the changes made to the code? Has this "patch" been tested through full "cold-start" (usually when a POST is run to verify the firmware)?
Congrats again on the *TERRIFIC* job done by everyone involved!
-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
yes the patch works via a cold start ...
There are functions that do check the firmware... as the wiki states this process will break Audible Audio files most likely..
I don't use any Audible so I can't verify this, its only suppisition. however every other feature works just great.
Quote
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-
QuoteAssuming 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.
QuoteAnd 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.
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.
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 ;)
QuoteI 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).
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.
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...
Quote
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
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.
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...
QuoteFlash 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
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.
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. :)