Problem Hacking VW Phatnoise

[CS8ALM]

Hi

I've read the forums and digested as much as I can in regard to hacking the VW phatbox so that I can upgrade my DMS. I've tried, both with the CD (1.5) and manually - and even tried using a later version of the phathack file (0.6).

Looking at the PhatPatch log I can see following. Note that the longer the DMS is in the phatbox the bigger the file becomes (29Mb after 5 mins!)...

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

------------------------------------------------------------------------------------------

From this, and the fact that I never hear the confirmation sound I believe that the phatbox is not actually getting hacked? Also patch.log shows the following..

----------------------------------------------------------------------------

PhatPatch v0.6 - original code by bushing, additional patches by sbingner
Verifying:
Patch 1 @ 0d90: make drive signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00    Actual: 000c 0a00
Unverified!
Patch 2 @ 0dc4: make rc.sh signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00    Actual: fee2 ebff
Unverified!
Patch 3 @ 0df8: make phatd signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00    Actual: 0001 e3a0
Unverified!
Patch 4 @ 0e2c: make linux signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00    Actual: 8410 e8bd
Unverified!
Patch 5 @ 051c: make ramdisk invalid signature return 0 instead of 0xFFFFFFFF: [movlne r0, 0xFFFFFFFF -> movlne r0, #0]
Expected: 0000 13a0    Actual: c000 e3a0
Unverified!
Patch 6 @ 0e58: make ramdisk signature check verify 0 instead of 1: [cmp r0, #1 -> cmp r0, #0]
Expected: 0000 e350    Actual: 0040 e59f
Unverified!
Patch 7 @ 0520: make ramdisk valid signature return 0 instead of 1: [moveq r0, #1 -> moveq r0, #0]
Expected: 0000 03a0    Actual: e482 e1a0
Unverified!
Patch 8 @ 04f4: don't try to read ramdisk.sig (boot without any .sig files): [bl sector_read_suzy -> bl PC+1]
Expected: 0000 eb00    Actual: 0008 0000
Unverified!
Patch 9 @ 0460: don't try to read linux.sig (boot without any .sig files): [bl sector_read_suzy -> bl PC+1]
Expected: 0000 eb00    Actual: 5000 e1a0
Unverified!
done

----------------------------------------------------------------------------------------------

Any ideas?

[sbingner]

That's very strange, the first time it shows sensible output.... but in the second half, you should never be able to get some of the things it says is actual value...   ie:

Patch 1 @ 0bb8: make drive signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0033 1a00    Actual: 0033 1a00
Match! Programming...

Verifying:
Patch 1 @ 0d90: make drive signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00    Actual: 000c 0a00
Unverified!

You can't change anything from a 0 to a 1 without erasing the flash.   The patch does not do this, so "0033" can never change to "000c" because '3' = 0011 binary and 'c' = 1100 binary

In general, nothing makes sense... can you post all your logs somewhere?

[sbingner]

Oh, I don't really want 25MB of logs.... if you could do a fresh run it would be most useful

[judb]

i suggest that you delete the existing logs and run a chkdsk on the drive before you start again.  sometimes failed patch runs can cause filesystem errors that you have to chkdsk to fix.  just fyi.

[CS8ALM]

Thanks - You were correct that chkdsk brought up problems so I -

 - Used the repair util to reformat and initialise my DMS
 - Place firmware 7.0 onto the drive (rather than 7.02 as a long shot to see if it worked with an earlier version)
 - Flashed the Phatbox to 7.0 and check it all worked.

Then I ran the HDD Hack utility 1.5 and got the same behavior - in that the patch process begins but never completes (as the log shows waiting..., waiting... etc). The logs also contain similar information.

I have zipped up my logs and placed them at http://mysite.orange.co.uk/xenicus/phatlog.zip

Could the box use a different bootloader firmware than the one the patch is designed for?

Xenicus

[sbingner]

No, it verified that the original code is correct.

For some reason when it writes to flash it's not completing the actual write, but rather getting stuck.  That's something I've never seen before... I'll have to think about it a little.  The waiting is the box repeatedly checking the patch location for the data to be updated.   I'll add a timeout value to it.

PhatPatch v0.4

You could try a newer phatpatch - see http://downloads.phathack.com/sbingner/phatpatch-0.5.gz  just replace your 'phatpatch' file on the dms

I don't think it'll help you though, since the only changes I made shouldn't be related...

[judb]

If you have a plugin directory in phtsys rename it to plugin-bak and try again, perhaps there is an issue with a plugin that is causing your problem?  just taking a stab in the dark.

[CS8ALM]

sbingner / judb - it's finally worked!

I used the version of phathack you pointed me to but (significantly?) I had no 'Plugins' folder [in actual fact I did have one on my original DMS but after making a backup deleted it]. It seems that by either using v5 of phathack and/or creating a empty Plugins folder the box took the hack :-)

It never played the 'you're phatbox has been unlocked' mp3 but I immediatley knew something was different as the 'welcome to phatnoise' mp3 did not stutter (which it did when the logs kept showing 'waiting....').

I took the DMS out and confirmed that the logs showed the hack had been applied and tried a new DMS and it works fine.

One last Q - can I still apply future firmware updates (like update 7.02) as this doesn't touch the bootloader?

Cheers for all your help. Will look into contirbuting to your 160mb project....

Xenicus

[judb]

yes you can, however phatnoise hasn't really been releasing many updates for a while now.  I think the phatbox is semi abandoned at this point code wise.

[sbingner]

That's interesting... it seemed to accept your unlock sequence but perhaps I was misreading the logfile.  The difference with 0.5 was that it detects some chip that need a different unlock sequence and uses the other code.   The plugins directory shouldnt have mattered, so I expect it was using 0.5 that helped you.  (An empty plugins directory is functionally the same as no plugins directory)

[sbingner]

Sure enough, I was blind.   Your chip was NOT accepthing the unlock code previously.

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

The chip ID and device ID should not be the same as the first 2 words of the flash, that means the auto-id command was not accepted by your chip.

[CS8ALM]

aha - that'll explains it then. Cheers again.

Shame Phatnoise have stopped producing updates I guess that is where the PhatOS project comes into play... except I don't know anything about it as yet... seems I've more reading up to do!

Xenicus

[sbingner]

I haven't done much with the PhatOS stuff... got the beginnings of a phatd replacement and 51d replacement but nothing that's usable yet.   I just haven't had the time