PhatHack
The Hacking Hoedown => PhatBox Hacking => Topic started by: Firefox on October 21, 2005, 03:53:48 pm
-
Hi guys, i finally took the plunge and tried to patch my 710 Keg so i could use a new 80GB drive.
I'm using the v1.5 boot CD, all seemed to go fine until i put the original DMS into the car to do the patching.
The head unit just shows:
"Loading...Loading...Loading..." etc for a minute and then says "Eject"
Then it just sits there.
I looked at the keg lights and they seem to be cycling - one short flash, eleven long flashes, 1 short flash, four long flashes then both off. Then it repeats.
bootload.log is empty.
My seed original DMS is a 40GB and I have the AAC decoder and VIOT plugins on my keg.
I haven't done any repartioning at all, chkdsk looks fine but the most worrying thing now is I have just tried to revert to a pre-hack state by deleting all the files from PHTSYS and replacing them with a backup taken just before using the hack CD and it still won't work! Same error as above.
HELP!!! Any ideas what I can do now?
-
try corrupting the ramdisk.sig file by renaming it and copying another file's sig file as ramdisk.sig and see if the old DMS boots.
If it does, the hack didn't apply all the patches, just most of them. You'll have to run it again one more time.
The hack CD does not damage the DMS, nor does it have the potential of frying your box as far as I know. So it should be a sig file issue.
also, if that fails to work, rename the plugin folder and try booting that way.
-
Thanks for the suggestions judb. Sadly no joy with using the original 40GB DMS so far... :'(
I've also dug out my old 10GB original DMS and confirmed that the Keg still recognised that OK. Phew!
So now I've given up on using the 40GB DMS as a source and am trying to load the patch software onto the 10GB one instead. But it just doesn't seem to get picked up at all by the Keg.
bootload.log is showing:
BOOT0-0: OK
BOOT0-1: OK
BOOT0: Successful
BOOT9: Successful
BOOTB: Successful
BOOTF: Successful
BOOT*: Successful
which suggests nothing has been patched at all right?
I'm going to reload the firmware onto the 10GB, remove forceupdate/forcesettings and try to apply the patch software to it again.
At least i'm keeping fit going up and down 4 flights of stairs each time!!
-
Some progress to report. I'm getting logs now...
PatchWrite.log
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...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Continues with lots more waiting messages until i pulled the DMS from the Keg I guess.
PatchVerify.log
Starting Patch Process
PhatPatch v0.4 - original code by bushing, additional patches by sbingner
Verifying:
Patch 1 @ 0bb8: make drive signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00 Actual: 0033 1a00
Unverified!
Patch 2 @ 0bec: make rc.sh signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00 Actual: 0026 1a00
Unverified!
Patch 3 @ 0c20: make phatd signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00 Actual: 0019 1a00
Unverified!
Patch 4 @ 0c54: make linux signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00 Actual: 000c 1a00
Unverified!
Patch 5 @ 0354: make ramdisk invalid signature return 0 instead of 0xFFFFFFFF: [movlne r0, 0xFFFFFFFF -> movlne r0, #0]
Expected: 0000 13a0 Actual: 0000 13e0
Unverified!
Patch 6 @ 0c80: make ramdisk signature check verify 0 instead of 1: [cmp r0, #1 -> cmp r0, #0]
Expected: 0000 e350 Actual: 0001 e350
Unverified!
Patch 7 @ 0358: make ramdisk valid signature return 0 instead of 1: [moveq r0, #1 -> moveq r0, #0]
Expected: 0000 03a0 Actual: 0001 03a0
Unverified!
patch.log
: No such file or directory
2048+0 records in
2048+0 records out
hdparm - get/set hard disk parameters - version v3.9
Usage: hdparm [options] [device] ..
Options:
-a get/set fs readahead
-A set drive read-lookahead flag (0/1)
-c get/set IDE 32-bit IO setting
-C check IDE power mode status
-d get/set using_dma flag
-D enable/disable drive defect-mgmt
-E set cd-rom drive speed
-f flush buffer cache for device on exit
-g display drive geometry
-h display terse usage information
-i display drive identification
-I read drive identification directly from drive
-k get/set keep_settings_over_reset flag (0/1)
-K set drive keep_features_over_reset flag (0/1)
-L set drive doorlock (0/1) (removable harddisks only)
-m get/set multiple sector count
-n get/set ignore-write-errors flag (0/1)
-p set PIO mode on IDE interface chipset (0,1,2,3,4,...)
-P set drive prefetch count
-Q print out the drive id only (60bytes\n)
-q change next setting quietly
-r get/set readonly flag (DANGEROUS to set)
-R register an IDE interface (DANGEROUS)
-S set standby (spindown) timeout
-t perform device read timings
-T perform cache read timings
-u get/set unmaskirq flag (0/1)
-U un-register an IDE interface (DANGEROUS)
-v default; same as -acdgkmnru (-gr for SCSI, -adgr for XT)
-V display program version and exit immediately
-W set drive write-caching flag (0/1) (DANGEROUS)
-w flush os cache and wakeup drive
-X set IDE xfer mode (DANGEROUS)
-y put IDE drive in standby mode
-Y put IDE drive to sleep
-Z disable Seagate auto-powersaving mode
PhatPatch v0.4 - original code by bushing, additional patches by sbingner
Verifying:
Patch 1 @ 0bb8: make drive signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00 Actual: 0033 1a00
Unverified!
Patch 2 @ 0bec: make rc.sh signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00 Actual: 0026 1a00
Unverified!
Patch 3 @ 0c20: make phatd signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00 Actual: 0019 1a00
Unverified!
Patch 4 @ 0c54: make linux signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00 Actual: 000c 1a00
Unverified!
Patch 5 @ 0354: make ramdisk invalid signature return 0 instead of 0xFFFFFFFF: [movlne r0, 0xFFFFFFFF -> movlne r0, #0]
Expected: 0000 13a0 Actual: 0000 13e0
Unverified!
Patch 6 @ 0c80: make ramdisk signature check verify 0 instead of 1: [cmp r0, #1 -> cmp r0, #0]
Expected: 0000 e350 Actual: 0001 e350
Unverified!
Patch 7 @ 0358: make ramdisk valid signature return 0 instead of 1: [moveq r0, #1 -> moveq r0, #0]
Expected: 0000 03a0 Actual: 0001 03a0
Unverified!
I guess that is progress??!! Been at this 8 hours straight now - I'll look again in the morning........
-
oh no, i've just seen this earlier thread:
http://forum.phathack.com/cgi-bin/yabb/YaBB.cgi?board=dmshack;action=display;num=1126252507
Am i really stuffed?
-
Well I don't know what to tell you firefox.. Perhaps emailing or PMing Sam would be a good idea.
-
Thanks for trying judb - I think i'm going to give up on this for a few days while I calm down :-[
My Keg just plain refuses to patch.
I do have both original DMS working again so that is a relief. No lasting damage.
The 10GB gets stuck on patch step 1 as per logs above, with audio stuttering if you change to other playlists. chkdsk /f and defrags didn't help, so I have manually reverted it to a regular state and that still works fine now in the unpatched Keg.
I eventully managed to get the original 40GB DMS working again too - this time a firmware reload seemed to do the trick.
That 40GB DMS is really weird though, the patch process never once even started in the Keg using that one as a seed. I vaguely remember from the old PN forums that PN said something about the 40GB format being different in some way. Anyone else remember that?
A couple more questions to all:
- has anyone managed to patch using a 40GB original DMS as the seed?
- has anyone managed to patch a box when the AAC Plugin is already on the box?
judb - I've also got the same question that A543 had to you before in
http://forum.phathack.com/cgi-bin/yabb/YaBB.cgi?board=dmshack;action=display;num=1126252507;start=15#19
He was asking about your earlier post in
http://forum.phathack.com/cgi-bin/yabb/YaBB.cgi?board=dmshack;action=display;num=1122187002;start=48#48
when you had exactly the same problem as in my log above - you were stuck on patch step one with exactly the same chip being reported i.e.
first 2 words of flash=c102 0025
writing auto-id command (AA, 55, 90)
Flash chip reports manufacturer id=c102, device id=0025
etc... but you eventually got past it. Do you remember how?
One day I'll crack this beast!!!! ;D
-
Firefox, you mentioned that you have at least one plugin installed. I believe the box that had the problem in that other thread also had at least one.
Did you try installing the patch without having any plugins installed? Basically starting from scratch with a fresh DMS and a fresh firmware reinstall and then not installing any plugins, before running the patch?
-
Firefox, you mentioned that you have at least one plugin installed. I believe the box that had the problem in that other thread also had at least one.
Did you try installing the patch without having any plugins installed? Basically starting from scratch with a fresh DMS and a fresh firmware reinstall and then not installing any plugins, before running the patch?
No. I haven't wiped a DMS yet and tried that.
I have 2 questions before i try it:
a) How do you actually remove a plugin from the Keg? If I don't want to reformat the DMS is it a simple case of deleting the Plugins folder from the DMS and then re-applying firmware with forceupdate/forcesettings file in place?
b) Has anyone successfully reapplied plugins after patching their Keg/Phatbox - there seems to be a lot of people asking that question here but i don't see a definitive answer. I can live without the AAC plugin but not VIOT.
Thanks for the support guys.
-
Just rename the plugin folder and they don't work anymore..
you can zip up the folders in there and just extract them individually to test them out.
I'd guess its the aac plugin thats causing problems though
-
Just rename the plugin folder and they don't work anymore..
you can zip up the folders in there and just extract them individually to test them out.
I'd guess its the aac plugin thats causing problems though
Really? I thought the DMS was just used to transport a plugin to a Keg/PB like it is for firmware.
Once you have a plugin loaded onto a Keg/PB can't you theoretically use ANY DMS (even ones without the Plugins folder) and the VIOT/AAC plugins will still work?
I'll try it out later tonight.
I agree that the aac plugin is likely the problem.
Maybe I really do have to totally nuke the AAC plugin first by reflashing the firmware in the Keg - as suggested by A543 - otherwise the current AAC-modified firmware uses too many CPU cycles to allow the patch to work and hence it errors and loops? (Well, it's a theory... ;D )
-
Theory was no good - I have
- wiped the 10GB DMS,
- reloaded the Kenwood firmware to DMS via PMM
- loaded Kenwood firmware to Keg
- reapplied VIOT to DMS via PMM
- applied VIOT to Keg
- loaded patch to original DMS via boot CD
- Put patch DMS in car but got same result as before (hanging on step 1).
- Tried again after renaming the Plugins folder to Plugins.xxx but got same result as before (hanging on step 1).
Sadly it looks like I have an unpatchable box :-[ and I'm blaming the AAC Plugin!!
Has anyone who has ever had the AAC Plugin loaded to their Keg/Phatbox managed to patch it afterwards?
-
I had Exactly the same problem with mine see http://forum.phathack.com/cgi-bin/yabb/YaBB.cgi?board=dmshack;action=display;num=1126252507;start=15#19 which you have already referenced.
I solved it by buying a new box on ebay cheap. This flashed fine
I did have the AAC plugininstalled on the original box, as I upgraded the original software and it came with it.
Could this be the cause??
I tried it with the DMS completely wiped and new firmware (and old firmware)
just kept waiting....
I still have the old box, its a very pretty paperweight ;D
-
Firefox, would you feel like trying it again without any plugins installed? Having any plugin on the DMS, as the source of the problem, still hasn't been eliminated yet. I'm only reaching at straws here, so weigh the four flights of stairs accordingly. ;)
-
If it's using too much time, you can hit pause as soon as the hack starts.... wait a few seconds then unpause it. Sometimes the box doesn't even want to give you a serial console for a few moments after boot up unless you pause playback
The problem post-hack is usually that a plugin gives an error... the best way is to remove the entire plugins directory from the hacked dms and see if it works, then add the plugins back one at a time. There are ways to fix the plugins afterward, but I thought that was taken care of by the hack cd (which unfortunately I've actually never used)
-
...I did have the AAC plugininstalled on the original box, as I upgraded the original software and it came with it.
Could this be the cause??
...
@bazmk2 - I'm pretty certain the AAC plugin is the issue. I have yet to hear from anyone who has successfully patched after having the AAC plugin installed.
I'm not convinced that reflashing a Keg with new firmware truly removes the plugin. It's almost like installing it is a one-way ticket, you can never get rid of it!
@A543 - i'm a bit confused now because having renamed the plugins folder on my 10GB DMS to plugins.bak the VIOT still functions as normal on my Keg which supports my theory that a plugin is transported by the DMS but after that it is not required.
@sbingner - I've just tried your pause suggestion but unfortunately I get exactly the same "waiting..." problem when trying to patch the Keg.
Do you think it is possible that installing the AAC plugin has already "patched" my Keg in some official Phatnoise way that now prevents the Phathack calls from working e.g. my Keg does some additional checks now at boot time?
-
@A543 - i'm a bit confused now because having renamed the plugins folder on my 10GB DMS to plugins.bak the VIOT still functions as normal on my Keg which supports my theory that a plugin is transported by the DMS but after that it is not required.
Until the unit POWERS DOWN (I.E is disconnected from power) the plugins will remain enabled. Once it is powered down, it will have to be re-enabled by the DMS on bootup
@sbingner - I've just tried your pause suggestion but unfortunately I get exactly the same "waiting..." problem when trying to patch the Keg.
Do you think it is possible that installing the AAC plugin has already "patched" my Keg in some official Phatnoise way that now prevents the Phathack calls from working e.g. my Keg does some additional checks now at boot time?
I worked with dafamous12 and managed to get his audible working as well, had to put the original aadec in as "aadec-orig" and "aadec-orig.sig" then change the config to use that instead of aadec. As to the AAC codec, I believe I have that installed on my box at home... and no it couldnt have done anything to your firmware. NOTHING phatnoise does EVER touches the phatbox firmware, only the CPLD firmware. I can log onto IRC in about 3 or 4 hours and help you with this if you like, expect we can get it patched... (4:30 or 5:00 AKST since I'm in Alaska at the moment)
-
Until the unit POWERS DOWN (I.E is disconnected from power) the plugins will remain enabled. Once it is powered down, it will have to be re-enabled by the DMS on bootup
Hmmmm. I'm not convinced. To test this I've just pulled the lead from my Keg, waited 5 minutes then loaded an old firmware (Kenwood v12.05) with the plugins folder on the DMS renamed as plugins.xxx and after the firmware has loaded I STILL have VIOT active............ ???
...I can log onto IRC in about 3 or 4 hours and help you with this if you like, expect we can get it patched... (4:30 or 5:00 AKST since I'm in Alaska at the moment)
Appreciate the offer but i need to crash now due to early work start tomorrow. Will try to catch up with you soon though. Cheers!
P.S. You certainly get around - wan't it Japan a couple of weeks back??!!! :o
-
Mine doesn't work that way, but I suppose it could modify the CPLD firmware to always work with SSA enabled... that's where the difference is
-
From what I have seen. Viot once installed always works no matter what dms is used something is installed in rom on the phatbox. AAC will only work on the dms that it was installed on or if you use the patched addecc on a larger drive it will enable use on it.
-
From what I have seen. Viot once installed always works no matter what dms is used something is installed in rom on the phatbox.
and after the firmware has loaded I STILL have VIOT
Ok, based on these quotes it seems that some permanent change is made to the Keg when VIOT is installed. Is it possible that when the VIOT plugin folder is found on the DMS the software performs a dumb update of the ROM every time the box is started, which normally doesn't harm anything, but in this case is putting the ROM (and/or something else) into a "write" state that interferes with the patch process trying to access the chips it needs? Notice the logs show the chip not responding to the chip id query.
If this were the case the patch should work if the box is powered up fresh, no plugins folders, fresh firmware, etc.
Now if the box checks for a certain value in the VIOT ROM address to determine if VIOT is installed (instead of looking for the plugin folder) and then writes to alter the firmware, again every time the box powers up, and that interferes with the patch, there'd be no way to get the patch to work without modifying Phatnoise's software or reversing the VIOT ROM patch.
Also, I can't see why the AAC plugin would alter the box permanently in any way if the plugin follows the DMS and not the box.
-
VIOT will not always stay enabled... I have turned it on and off a number of times while doing research on how the plugin system works. When it authorizes the VIOT plugin it changes the operating mode of the CPLD, the CPLD will stay in that mode until reset at which time it will again default to the non-SSA mode until VIOT or SSA is enabled. You can verify this yourself via level 10 logfiles... I was going to paste the relevant info here but I cant connect to my home system from work. It DOES save some info in plugins.dat, and unless that is removed it won't do a full reauthorization of all plugins.
Sam
-
it changes the operating mode of the CPLD
This altered state is basically what I was getting at. Is it possible that this 'mode' is interfering with the patch?
Another thought I had, when one has the AAC plugin, does the AADEC file get changed? If so, maybe when someone reformats their DMS and uses PMM to set it up, PMM, knowing this person has the plugin, copies over (or changes) the AADEC file automatically, so even a fresh setup will still interfere with the patch. Using a PMM installation that hasn't had any plugins installed to set up a fresh DMS might get around this.
-
the aac plugin uses a different file for playing of aac files... it doesn't modify aadec
-rwxr--r-- 1 root root 136324 Jan 6 2005 aacplay
-rwxr--r-- 1 root root 240 Jan 6 2005 aacplay.sig
If I can talk to somebody whos having the problem I'm sure we can figure it out relatively quickly
Oh yea, my box had the AAC plugin on it when I flashed it originally
-
VIOT will not always stay enabled... I have turned it on and off a number of times while doing research on how the plugin system works. When it authorizes the VIOT plugin it changes the operating mode of the CPLD, the CPLD will stay in that mode until reset at which time it will again default to the non-SSA mode until VIOT or SSA is enabled.
You didn't say how the CPLD could be reset, i've been unplugged before for 5 mins and that didn't do it, but pleased to report I have now managed to get rid of VIOT from the Keg :)
I used a combination of...
(1) unplugging cable from Keg for 2 hours
(2) deleting plugins folder from PHTSYS completely (not just renaming to plugins.xxx or plugins.bak)
(3) using PMM to place updated firmware v13.01 onto DMS
(4) reflashing firmware in Keg using DMS
So this agrees with your assertion that VIOT is not permanent. I don't know which step actually removed it, but at least I'm convinced now it can be done!
So with that mini success I thought I would now be able to load the patch. Right?
Wrong... :(
I still get the waiting error i.e.
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...
etc
etc
Any more ideas? I should be around all night tonight if you are available to help.
-
I'll be able to once I leave work... I don't suppose you have a serial cable, or want to make one? That would simplify things ;)
Otherwise, we'll probably have to do alot of swapping of your DMS cartridge to make it check things... it's not accepting the unlock code for some reason. (you can tell by the fac that it says the manufacturer ID is the same as the first word of the flash, it's not.)
I should have seen that long ago, I guess I wasnt paying enough attention there....
BTW: the thread you mentioned where judb had the same problem, he had a bad version of the flash program... make sure you have the latest stuff posted for the flash stuff, and if you want you can get a working phatpatch from http://downloads.phathack.com/sbingner/phatpatch-0.4.gz
-
Oh yea, losing power to the box resets the CPLD
-
Just so you know, i'm in the UK so this is sent 9pm. Are you still in Alaska? If so I guess we are 9 hours apart? Should be fun getting a window to work for both of us........!!!
So far tonight I've been playing with a level 10 rc logging pair. I have quite a bit of stuff I could post if you think it's useful but your last comment makes me think we would need to crack the unlock first before anything else matters. Am i right?
Hmmmm. Serial cable. If it's "very easy" to make then I could have a go, but it wouldn't be tonight. Soldering isn't really my forte ;D
P.S. I have the v1.5 boot CD - so that must be OK already with a working v0.4 PhatPatch right?
PPS Your link above gives me an "invalid archive directory" when i try to unzip with WinZip - is it really a .gz or does it just need to be renamed as "phatpatch"?
-
it's really .gz but sometimes clients will decompress it inline...
You can try to get the unlock code to work by using http://downloads.phathack.com/sbingner/debugr.gz and http://downloads.phathack.com/sbingner/debugw.gz
i.e:
./debugw 0x555=0xAA
./debugw 0x2AA=0x55
./debugw 0x555=0x90
./debugr 0x0
(what the patcher does)
and
./debugw 0xAAA=0xAA
./debugw 0x554=0x55
./debugw 0xAAA=0x90
./debugr 0x0
and
./debugw 0x1554=0xAA
./debugw 0xAAA=0x55
./debugw 0x1554=0x90
./debugr 0x0
just try different addresses until the read returns something besides 0xc102 -- when you get one that works, let me know what you got... what should really work is the default addresses
-
As to the serial cable, see http://wiki.phathack.com/Access_Serial_Port
-
BTW, you can do all that without a serial cable... just make a script to run off your DMS and log all the output to a file
-
it's really .gz but sometimes clients will decompress it inline...
Yep. That's what was happenning. I just needed to rename the files.
You can try to get the unlock code to work by using http://downloads.phathack.com/sbingner/debugr.gz and http://downloads.phathack.com/sbingner/debugw.gz
i.e:
./debugw 0x555=0xAA
./debugw 0x2AA=0x55
./debugw 0x555=0x90
./debugr 0x0
(what the patcher does)
and
./debugw 0xAAA=0xAA
./debugw 0x554=0x55
./debugw 0xAAA=0x90
./debugr 0x0
and
./debugw 0x1554=0xAA
./debugw 0xAAA=0x55
./debugw 0x1554=0x90
./debugr 0x0
just try different addresses until the read returns something besides 0xc102 -- when you get one that works, let me know what you got... what should really work is the default addresses
Sorry. I don't 100% understand how I'm going to call those progs.
Do you mean I should copy both progs to backups folder in PHTSYS and then write a replacement patch.sh to actually call those commands in turn? ???
Even then I wouldn't know what was safe to use as the addresses. Where did you get those example values from?
I think I'll need to wait for some 1 to 1 guidance via IRC...
...I'm pushing my limits of knowledge and feeling pretty dumb here!
-
BTW, you can do all that without a serial cable... just make a script to run off your DMS and log all the output to a file
OK. We crossed messages.
So I got the script part right, I can do that, just don't know how to decide address values - for now i'll use your ones...
-
Any address is safe, it won't write unless the unlock code and write code was accepted --- and that's not the write command, that's chip ID command
-
try going to http://www.appindex.net/products/demo/chat/ and joining "The Zone" -- might be able to use that
-
okay. i'm in there now. results from modified patch.sh weren't great. In fact the logs are easily corrupted it appears.
First part of my modified patch.sh script...
echo Starting Address Checks > /dos/log/PatchAddress.log
echo CheckingAddressCombo1 >> /dos/log/PatchAddress.log
/dos/backup/debugw 0x555=0xAA >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugw 0x2AA=0x55 >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugw 0x555=0x90 >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugr 0x0 >> /dos/log/PatchAddress.log 2>&1
echo FinishAddressCombo1 >> /dos/log/PatchAddress.log
echo CheckingAddressCombo2 >> /dos/log/PatchAddress.log
/dos/backup/debugw 0xAAA=0xAA >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugw 0x554=0x55 >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugw 0xAAA=0x90 >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugr 0x0 >> /dos/log/PatchAddress.log 2>&1
echo FinishAddressCombo2 >> /dos/log/PatchAddress.log
echo CheckingAddressCombo3 >> /dos/log/PatchAddress.log
/dos/backup/debugw 0x1554=0xAA >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugw 0xAAA=0x55 >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugw 0x1554=0x90 >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugr 0x0 >> /dos/log/PatchAddress.log 2>&1
echo FinishAddressCombo3 >> /dos/log/PatchAddress.log
resulted in this log...
Starting Address Checks
CheckingAddressCombo1
/dos/backup/patch.sh:
dos/backup/debugw: No such file or directory
Offset: 0x2aa=55
Offset: 0x555=90
Offset: 0=c102
CheckingAddressCombo2
Offset: 0xaaa=aa
Offset: 0x554=55
/dos/backup/patch.sh: /dos/backup/de/debugw: No such file or directory
Offset: 0=c102
FinishAddressCombo2
CheckingAddressCombo3
Offset: 0x1554=aa
Offset: 0xaaa=55
Offset: 0x1554=90
Offset: 0=c102
-
just for completeness here are the results after running UNIX version of the patch.sh...
Starting Address Checks
CheckingAddressCombo1
Offset: 0x555=aa
Offset: 0x2aa=55
Offset: 0x555=90
Offset: 0=c102
FinishAddressCombo1
CheckingAddressCombo2
Offset: 0xaaa=aa
Offset: 0x554=55
Offset: 0xaaa=90
Offset: 0=c102
FinishAddressCombo2
CheckingAddressCombo3
Offset: 0x1554=aa
Offset: 0xaaa=55
Offset: 0x1554=90
Offset: 0=c102
FinishAddressCombo3
All failed to unlock the flash :(
Thanks for trying tonight Sam. If you get any other ideas please let me know...
-
okay. i'm in there now. results from modified patch.sh weren't great. In fact the logs are easily corrupted it appears.
It looks like you used an editor to create these scripts that actually backspaced over your typos rather than correcting them. Since you didn't actually execute all the commands in sequence (the "no such file" messages in the middle of the first two runs are a dead giveaway), we can't really say a lot about the results.
-
It looks like you used an editor to create these scripts that actually backspaced over your typos rather than correcting them. Since you didn't actually execute all the commands in sequence (the "no such file" messages in the middle of the first two runs are a dead giveaway), we can't really say a lot about the results.
Thanks Terry, yes we worked out that saving the file as UNIX format eliminated the problem with running the script "cleanly".
My later post shows "accurate" execution results, but we still haven't been able to unlock my flash...
:'(
-
Just been trawling the wiki for any other possible causes and was interested by the info about Startup Sequence FAQ (see http://wiki.phathack.com/Startup_Sequence_FAQ)
Boot procedure (on power)
The 8051 boots out of its internal 64k EEPROM [firmware.pac]
It boots up linux (see below) and the rest of the software to ask it what version of firmware.pac is stored on the drive if it is newer than that in the 8051, it will reflash itself . (This is why the instructions that come with the unit are insistent that you have the drive in the unit when you plug it in for the first time.)
Boot procedure (on ignition)
The 8051 will receive the turn*on sequence and apply power to the EP7312 (ARM)
The ARM will execute the bootloader code out of the 2mbit flash chip
This bootloader will query the drive for its ID and compare it to the signature written to the drive. It will also load the following files off the root directory of partition 1 and verify their corresponding signatures: linux, ramdisk, phatd, and rc.sh. It will hang with a blinking green light if anything is amiss.
If that check succeeds, the bootloader will load the linux and ramdisk files into memory, and jump to the linux kernel
I'm wondering if I have had a firmware.pac loaded that somehow prevents unlocking the bootloader flash.
Anyway to "downgrade" the 64k EEPROM in the 8051??
-
A few further unsuccessful attempts to read the Manufacturer ID using modified patch.sh...
#!/bin/sh
echo Starting Address Checks > /dos/log/PatchAddress.log
echo CheckingAddressCombo1 >> /dos/log/PatchAddress.log
/dos/backup/debugw 0x555=0xAA >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugw 0x2AA=0x55 >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugw 0x555=0x90 >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugr 0x0 >> /dos/log/PatchAddress.log 2>&1
echo FinishAddressCombo1 >> /dos/log/PatchAddress.log
echo CheckingAddressCombo2 >> /dos/log/PatchAddress.log
/dos/backup/debugw 0xAAA=0xAA >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugw 0x554=0x55 >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugw 0xAAA=0x90 >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugr 0x0 >> /dos/log/PatchAddress.log 2>&1
echo FinishAddressCombo2 >> /dos/log/PatchAddress.log
echo CheckingAddressCombo3 >> /dos/log/PatchAddress.log
/dos/backup/debugw 0x1554=0xAA >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugw 0xAAA=0x55 >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugw 0x1554=0x90 >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugr 0x0 >> /dos/log/PatchAddress.log 2>&1
echo FinishAddressCombo3 >> /dos/log/PatchAddress.log
echo CheckingAddressCombo4 >> /dos/log/PatchAddress.log
/dos/backup/debugw 0x555=0xAA >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugw 0xAAA=0x55 >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugw 0x555=0x90 >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugr 0x0 >> /dos/log/PatchAddress.log 2>&1
echo FinishAddressCombo4 >> /dos/log/PatchAddress.log
echo CheckingAddressCombo5 >> /dos/log/PatchAddress.log
/dos/backup/debugw 0x5555=0xAA >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugw 0x2AAA=0x55 >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugw 0x5555=0x90 >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugr 0x0 >> /dos/log/PatchAddress.log 2>&1
echo FinishAddressCombo5 >> /dos/log/PatchAddress.log
echo CheckingAddressCombo6 >> /dos/log/PatchAddress.log
/dos/backup/debugw 0x15554=0xAA >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugw 0xAAA8=0x55 >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugw 0x15554=0x90 >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugr 0x0 >> /dos/log/PatchAddress.log 2>&1
echo FinishAddressCombo6 >> /dos/log/PatchAddress.log
echo Finished Address Checks >> /dos/log/PatchAddress.log
results as follows...
Starting Address Checks
CheckingAddressCombo1
Offset: 0x555=aa
Offset: 0x2aa=55
Offset: 0x555=90
Offset: 0=c102
FinishAddressCombo1
CheckingAddressCombo2
Offset: 0xaaa=aa
Offset: 0x554=55
Offset: 0xaaa=90
Offset: 0=c102
FinishAddressCombo2
CheckingAddressCombo3
Offset: 0x1554=aa
Offset: 0xaaa=55
Offset: 0x1554=90
Offset: 0=c102
FinishAddressCombo3
CheckingAddressCombo4
Offset: 0x555=aa
Offset: 0xaaa=55
Offset: 0x555=90
Offset: 0=c102
FinishAddressCombo4
CheckingAddressCombo5
Offset: 0x5555=aa
Offset: 0x2aaa=55
Offset: 0x5555=90
Offset: 0=c102
FinishAddressCombo5
CheckingAddressCombo6
Offset: 0x15554=aa
Offset: 0xaaa8=55
Offset: 0x15554=90
Offset: 0=c102
FinishAddressCombo6
Finished Address Checks
Looks like i'm going to have to bite the bullet and remove the Keg from the car and dissassemble to see what flash chip I have - which is not easy because of how I have mounted it so neatly............ :-[
-
The 8051 couldn't do that, the communication to the flash chip goes directly from the processor and the communication between processor and 8051 is via serial port. The 8051 also has control of the power, but that's pretty obvious when it turns that off
I suppose it's possible they have a different flash chip in there, but every other chip they've used has accepted the same unlock codes...
-
I suppose it's possible they have a different flash chip in there, but every other chip they've used has accepted the same unlock codes...
Hi again all - thread still alive...
...I finally got my Keg out of the car and just performed open heart surgery on it.
The good news :) It is using a different flash. It's a Silicon Storage Technology SST39VF200A.
(http://home.btconnect.com/storri/SST39VF200A.jpg)
I've added it to the Hardware_FAQ http://wiki.phathack.com/Hardware_FAQ
The bad news :( according to the datasheet http://www.sst.com/downloads/datasheet/S71117.pdf it looks to me like it should respond to one of the combos i tried earlier...
/dos/backup/debugw 0x5555=0xAA >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugw 0x2AAA=0x55 >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugw 0x5555=0x90 >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugr 0x0 >> /dos/log/PatchAddress.log 2>&1
Could one of you pros check out the datasheet and see if my untrained verdict is correct?
Any other ideas?
-
try:
./debugw 0xAAAA=0xAA
./debugw 0x5554=0x55
./debugw 0xAAAA=0x90
./debugr 0x0
-
try:
./debugw 0xAAAA=0xAA
./debugw 0x5554=0x55
./debugw 0xAAAA=0x90
./debugr 0x0
Well I got a different result from usual and I think it's the manufacturer code!!!! ;D ;D ;D
Using a patch.sh of...
echo CheckingAddressComboSam1 >> /dos/log/PatchAddress.log
/dos/backup/debugw 0xAAAA=0xAA >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugw 0x5554=0x55 >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugw 0xAAAA=0x90 >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugr 0x0 >> /dos/log/PatchAddress.log 2>&1
echo FinishAddressComboSam1 >> /dos/log/PatchAddress.log
I got...
CheckingAddressComboSam1
Offset: 0xaaaa=aa
Offset: 0x5554=55
Offset: 0xaaaa=90
Offset: 0=bf
FinishAddressComboSam1
I think you've finally cracked it!!!!!!
Does that mean I will need a custom phatpatch created just for me?
Is that something you can send me?
Thanks for sticking with this....
Simon
ps where in the datasheet did you get that sequence from?
pps you would not believe how big a grin i have on my face now..........
-
Yea, that's it... you would need a custom compiled patcher, or you could just do it with debugw
I'll try to update phatpatch now, give me a few mins and I think I can give you one that'll work
BTW: I got it from where you were looking, what you didn't know is that phatnoise connected the thing up without connecting one of the pins so all the offset addresses have to be doubled
-
try http://www.phathack.com/downloads-direct/sbingner/phatpatch-0.5 -- it's totally untested but I think it should work
If not, I'll be able to fix it when I get home
-
thanks - i'll give it a try and report back.............
.............WOOOHOOO!!!!! My Keg is finally patched ;D ;D ;D ;D ;D
Great job Sam. The new v0.5 worked a treat
looks like you just need to update the version number in the printf code ;)
Here is the output...
PatchWrite.log
PhatPatch v0.4 - original code by bushing, additional patches by sbingner
first 2 words of flash=c102 0025
testing offsets 0x555 and 0x2aa
writing auto-id command (AA, 55, 90)
testing offsets 0x5555 and 0x2aaa
writing auto-id command (AA, 55, 90)
Flash chip reports manufacturer id=00bf, device id=2789
offsets 0x5555 and 0x2aaa verified
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...
Wrote 0000
Patch 2 @ 0bec: make rc.sh signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0026 1a00 Actual: 0026 1a00
Match! Programming...
Wrote 0000
Patch 3 @ 0c20: make phatd signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0019 1a00 Actual: 0019 1a00
Match! Programming...
Wrote 0000
Patch 4 @ 0c54: make linux signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 000c 1a00 Actual: 000c 1a00
Match! Programming...
Wrote 0000
Patch 5 @ 0354: make ramdisk invalid signature return 0 instead of 0xFFFFFFFF: [movlne r0, 0xFFFFFFFF -> movlne r0, #0]
Expected: 0000 13e0 Actual: 0000 13e0
Match! Programming...
Wrote 13a0
Patch 6 @ 0c80: make ramdisk signature check verify 0 instead of 1: [cmp r0, #1 -> cmp r0, #0]
Expected: 0001 e350 Actual: 0001 e350
Match! Programming...
Wrote 0000
Patch 7 @ 0358: make ramdisk valid signature return 0 instead of 1: [moveq r0, #1 -> moveq r0, #0]
Expected: 0001 03a0 Actual: 0001 03a0
Match! Programming...
Wrote 0000
PatchVerify.log
Starting Patch Process
PhatPatch v0.4 - original code by bushing, additional patches by sbingner
Verifying:
Patch 1 @ 0bb8: make drive signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00 Actual: 0033 1a00
Unverified!
Patch 2 @ 0bec: make rc.sh signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00 Actual: 0026 1a00
Unverified!
Patch 3 @ 0c20: make phatd signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00 Actual: 0019 1a00
Unverified!
Patch 4 @ 0c54: make linux signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00 Actual: 000c 1a00
Unverified!
Patch 5 @ 0354: make ramdisk invalid signature return 0 instead of 0xFFFFFFFF: [movlne r0, 0xFFFFFFFF -> movlne r0, #0]
Expected: 0000 13a0 Actual: 0000 13e0
Unverified!
Patch 6 @ 0c80: make ramdisk signature check verify 0 instead of 1: [cmp r0, #1 -> cmp r0, #0]
Expected: 0000 e350 Actual: 0001 e350
Unverified!
Patch 7 @ 0358: make ramdisk valid signature return 0 instead of 1: [moveq r0, #1 -> moveq r0, #0]
Expected: 0000 03a0 Actual: 0001 03a0
Unverified!
PhatPatch v0.4 - original code by bushing, additional patches by sbingner
Verifying:
Patch 1 @ 0bb8: make drive signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00 Actual: 0000 1a00
Verified!
Patch 2 @ 0bec: make rc.sh signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00 Actual: 0000 1a00
Verified!
Patch 3 @ 0c20: make phatd signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00 Actual: 0000 1a00
Verified!
Patch 4 @ 0c54: make linux signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00 Actual: 0000 1a00
Verified!
Patch 5 @ 0354: make ramdisk invalid signature return 0 instead of 0xFFFFFFFF: [movlne r0, 0xFFFFFFFF -> movlne r0, #0]
Expected: 0000 13a0 Actual: 0000 13a0
Verified!
Patch 6 @ 0c80: make ramdisk signature check verify 0 instead of 1: [cmp r0, #1 -> cmp r0, #0]
Expected: 0000 e350 Actual: 0000 e350
Verified!
Patch 7 @ 0358: make ramdisk valid signature return 0 instead of 1: [moveq r0, #1 -> moveq r0, #0]
Expected: 0000 03a0 Actual: 0000 03a0
Verified!
Thanks for all your help - now I can (hopefully) complete the disk swap!
The new version should hopefully help others with a similar flash chip in future too.
-
Cool, I updated the internal version etc. This will work for either unlock code, and it checks to make sure the unlock code works before it tries to patch now
binary: http://downloads.phathack.com/sbingner/phatpatch-0.5.gz
source: http://downloads.phathack.com/sbingner/phatpatch-0.5.c
It should be visible in about an hour, looks like I just missed the rsync window until then it can be seen from downloads-direct
-
I'm not quite there yet...
My new 80GB DMS does not boot (created using manual method). Bootload.log points to a problem with Ramdisk I think:
BOOT0-0: OK
BOOT0-1: OK
BOOT0-2: Successful
BOOT9-X: Successful
BOOTB-X: Successful
BOOTF: Successful
BOOT*-X: Failed
I tried corrupting ramdisk.sig to see if that helped. No joy, so I put it back again to original.
I tried with and then without plugins folder. No joy.
Original 10GB DMS still boots fine with or without the plugins folder.
Any ideas?
-
The problem isn't with your flashing, how did you create your second DMS? Make sure you have a primary partition (1) an extended partition (2) and a logical partition (would be called 5)
You might be able to find me on IRC...
-
The problem isn't with your flashing, how did you create your second DMS? Make sure you have a primary partition (1) an extended partition (2) and a logical partition (would be called 5)
You might be able to find me on IRC...
I created the new DMS using the "Genesis" manual method described here which uses the phathack boot cd to reformat the new drive...
http://forum.phathack.com/cgi-bin/yabb2/YaBB.pl?num=1123119033/1#1
That all went OK.
I checked the partitions and they are exactly as you describe.
chkdsk reports no errors.
I'll try to catch you on IRC over the next couple of days.
If anyone else has any bright ideas in the meantime, please share.
-
Tried a second firmware reload to the new DMS and hey presto - the new DMS is now recognised!!
;D ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D
Thanks everyone for helping with this marathon. Especially Sam.
It was painful but worth it - and I'm glad we ironed out another potential problem for the bootdisk in the process!
-
We'll need to get RobM or Bushing to recompile the code Sam published because his compiler makes huge executable files that I can't fit on the boot floppy image.
Once i have one thats under 30Kb I can update the disc and floppy with the new file and make a few other minor updates.
-
I worked with dafamous12 and managed to get his audible working as well, had to put the original aadec in as "aadec-orig" and "aadec-orig.sig" then change the config to use that instead of aadec....
Can I get some more details on this? I finally got my DMS "patched" this weekend and mp3's work just fine but I'd like to get my Audible books to work now. I don't need to copy them from the old DMS or anything, just add new ones from the PC via PMM.
I tried to copy the aadec and aadec.sig from the original drive, rename them -orig and put them on the new DMS, then I modified exec.ini and changed it to aadec-orgig (only place I saw reference aadec?)
After doing this, the keg wouldn't play ANYTHING and now just ejects after a min... :/
-
yeah don't mess with the exec file.. compare the file sizes of the aadec on the old drive and the aadec on the new drive.. are they the same?
-
forgot to mention, you need to sign the new exec.ini file -- you can use http://www.phathack.com/plsign.cgi to sign it
I also have a patched phatd somewhere but I never got around to posting a patcher for it ;)
-
yeah don't mess with the exec file.. compare the file sizes of the aadec on the old drive and the aadec on the new drive.. are they the same?
Hmm, actually ya, they seem to be the same file. Further investigation, I find there's the aadec files in the backup folder on the hacked DMS. the aadec-hacked file is the same as the aadec file in the root, but the aadec file in the backup folder is 108kb (vs 25 kb of the others).
The version.txt file has this in it as well (if it means anything).
phatpatch-v4
aadec-v4
-
forgot to mention, you need to sign the new exec.ini file -- you can use http://www.phathack.com/plsign.cgi to sign it
I also have a patched phatd somewhere but I never got around to posting a patcher for it ;)
Ok, now i'm confused :) Do i mess with the exec.ini or not? Do I put the aadec-orig files in, use the one from the backup, or leave them all alone?
Or do I ONLY have to put the new exec.sig file in?
I'm guessing since the aadec file from the old disk is the same as the one on the hacked dms and the same as the aadec-hacked in the backup file, this is the correct file and I should just put the new exec.sig file in place?
PS. just curious, why does it seem that the actual original aadec file is 85k larger than the hacked version?
-
The hacked version doesn't DO anything so it doesn't need to be very big... but it is neccesary
yes you need to modify the exec.ini file and resign it you need to change it to point to the REAL aadec (aadec-orig)
-
Still not working :'(
Closer though, signing the file allowed me to change the exec.ini and still play mp3's but still doesn't play audible, I either get "Corrupt Track" or it just hangs trying to play the file.
What I did was take the aadec file from the /backup dir, rename it to aadec-orig, signed it, put both files in the root dir, changed the exec.ini to point to aadec-orig, and resign the exec.ini. I even tried resigning the aadec-orig file on an off chance but that changed nothing.
Am I missing anything or anything else to try? I noticed the following in the exec.ini:
auth.pna=/dos/nmp3
auth1.pna=/dos/hdparm
auth2.pna=/dos/pkeysa.e
where .pna are audible files, but checking those files all had old date stamps so doesn't look like the hack touches those...
Help?
-Jamz
-
[Phatbox]
player.wma=/dos/phatwma
player.loop=/dos/playloopfile
auth.loop=/dos/swgrli
auth1.loop=/dos/nmp3
startprog=/dos/51d
player.flac=/dos/flacplay
player.pna=/dos/aadec-orig
auth.pna=/dos/nmp3
auth1.pna=/dos/hdparm
auth2.pna=/dos/pkeysa.e
player.ogg=/dos/oggplay-ha
auth.ogg=/dos/oggplay-la
player.m4a=/dos/needaac
auth.m4a=/dos/nmp3
Above is the exec.ini that worked for me - did you authorize the new DMS after updating it?
-
Hmmm, no I didn't :-[ Well, I did a few days ago but that was before moving the aadec-orig files and signing the exec.ini file.
I had tried to deauth/auth the dms before I discovered signing and I noticed I could not deauthorize it so not sure if it was doing anything. (after clicking deauthorize dms and going back into the options, it still had an option to deauth it?)
Anyways, i'll try that when I get home, hopefully that works.
And from the looks of it, your exec.ini looks exactly the same as mine.
-Jamz
-
Argh, I can't seem to authorize my DMS properly because I can't seem to Deauthorize it? When I click "Deauthorize DMS" it says Audible support has been removed, but the button doesn't change to "Authorize DMS". So not sure if I'm having trouble de-authorizing or authorizing?
Does anyone know which file(s) it actually touches? Is there a manual way of deauthorizing the DMS?
-Jamz
PS Thanks for all of your help so far, I must be the only one that can't get this to work :(
-
Wish I could help with that, but I don't actually use audible.... you could always try wiping out your PHTSYS partition and redoing it...
-
I may actually try that soon. I take it I'll have to put the original drive back in and copy the contents again eh?
Right now, I installed the original Music Manager on my windows vista VM and I was able to "deactivate" the DMS but can't eject it in the VM (says another process is using the drive etc etc) Bah. And now when I try to copy an Audible file, it asks for the user/password for audible but then says it fails and can't auth it...So, I REALLY have it deauth now i guess...
Next steps, gonna create an xp VM and try that with various versions of Music Manager/Media Manager.
Stay tuned for my Audible Adventures! :)
-Jamz
-
no, you dont need the original drive ever again... you can just format it and load the firmware with PMM... in fact you might be able to just do that and not replace aadec with the hacked version ;)
-
My audible wasn't working either with the patched DMS. I had to get the files called aadec and aadec.sig form the backup dir, rename them to aadec-orig and aadec-orig.sig, change the exec.ini, and sign it on this site. Once I did that, I transferred over Ender's Game to the DMS, and it worked perfectly in the car. Before that it would just act like the playlist was empty if I had Audible content on the DMS. It sounds like you have done similar steps, but I just wanted you to know there is hope!
-
Thanks for the encouragement :)
But, I'm STILL not having any luck... I expected maybe some trouble getting the new drive to work etc but that went REALLLY smooth, i'm running out of ideas now :/
Basically, I was able to deauth it using music manager, then had to call audible to reset my count so I could reauth it, ok, now I can recopy audible files again. I did this after deleting all the files in phatsys dir and reapplying the firmware/system files.
Next try was to copy the hack aadec files, aaced-orig files, and exec files over and recopy the audible files, still no luck...
Gonna try to boot cd and try to rebuild the disk from scratch now, not sure if formatting the partition is much different than deleteing the files and recopying them?
-Jamz
-
no need to use the boot cd -- unless you needed to format the PHTDTA partition, but you could just delete everything off it to be in the same place.
Did you try it BEFORE you replaced any aadec files?
-
Ya, I deleted all the files and reapplied them via PMM (firmware update), then authorized the DMS and tried it with no luck. Then tried again with replacing the files. Each time I get a "corrupt track" message and it goes to the next playlist. I ran the repair and the disk looks good, doing a deep scan now, so far PHATSYS checked out and it's still doing the data parition with no errors so far.
I know this is going to turn into something stupid eventually :)
-Jamz
-
maybe you have to download a new copy of the file that's signed for your dms?
-
Hello Sbingner,
sorry my English is not very good.
I have the same Problem how FireFox which I must do with the file phatpatch-0.5.gz and phatpatch-0.5.c
Can you help me ?
Thanks for the Answer.
Greeting TeutoneX