Author Topic: Question about log files.  (Read 8292 times)

0 Members and 2 Guests are viewing this topic.

Offline kaet_22

  • Newbie
  • Posts: 2
Question about log files.
« on: July 20, 2007, 01:19:03 am »
My friend and I have just hacked my PB and I am able to see patch.log but unable to see patchverify.log

Patch.log is 100% successful after a few times trying to hack the unit.

But we still can not see the patchverify.log file at all.

I compared the bootload.log with others on the forum and people have said it is patched.

Should I try and proceed to switch to the new drive and continue the process or do I have to see this patchverify.log file in order to hack the system correctly ???

Any help would be Great!

Thanks in advance!

bootload.log looks like this:

BOOT0-0: OK
BOOT0-1: OK
BOOT0: Successful
BOOT9-X: Successful
BOOTB-X: Successful
BOOTF-X: Successful
BOOT*: Successful




patch.log / text file looks like this:

: No such file or directory
PhatPatch v0.8 - original code by bushing, additional patches by sbingner
Finding patch offsets:
Verified standard patch offsets
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!
Patch 8 @ 0330: don't try to read ramdisk.sig (boot without any .sig files): [bl sector_read_suzy -> bl PC+1]
Expected: 0000 eb00    Actual: 0000 eb00
Verified!
Patch 9 @ 02c0: don't try to read linux.sig (boot without any .sig files): [bl sector_read_suzy -> bl PC+1]
Expected: 0000 eb00    Actual: 0000 eb00
Verified!
PhatPatch v0.8 - original code by bushing, additional patches by sbingner
Finding patch offsets:
Verified standard patch offsets
first 2 words of flash=c102 0025
testing offsets 0x555 and 0x2aa
writing auto-id command (AA, 55, 90)
Flash chip reports manufacturer id=0001, device id=22bf
offsets 0x555 and 0x2aa 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: 0000 1a00
Detected patch 1 already applied
Patch 2 @ 0bec: make rc.sh signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0026 1a00    Actual: 0000 1a00
Detected patch 2 already applied
Patch 3 @ 0c20: make phatd signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0019 1a00    Actual: 0000 1a00
Detected patch 3 already applied
Patch 4 @ 0c54: make linux signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 000c 1a00    Actual: 0000 1a00
Detected patch 4 already applied
Patch 5 @ 0354: make ramdisk invalid signature return 0 instead of 0xFFFFFFFF: [movlne r0, 0xFFFFFFFF -> movlne r0, #0]
Expected: 0000 13e0    Actual: 0000 13a0
Detected patch 5 already applied
Patch 6 @ 0c80: make ramdisk signature check verify 0 instead of 1: [cmp r0, #1 -> cmp r0, #0]
Expected: 0001 e350    Actual: 0000 e350
Detected patch 6 already applied
Patch 7 @ 0358: make ramdisk valid signature return 0 instead of 1: [moveq r0, #1 -> moveq r0, #0]
Expected: 0001 03a0    Actual: 0000 03a0
Detected patch 7 already applied
Patch 8 @ 0330: don't try to read ramdisk.sig (boot without any .sig files): [bl sector_read_suzy -> bl PC+1]
Expected: 02db eb00    Actual: 0000 eb00
Detected patch 8 already applied
Patch 9 @ 02c0: don't try to read linux.sig (boot without any .sig files): [bl sector_read_suzy -> bl PC+1]
Expected: 02f7 eb00    Actual: 0000 eb00
Detected patch 9 already applied
« Last Edit: July 20, 2007, 01:21:31 am by kaet_22 »

Offline neo82

  • Newbie
  • Posts: 13
Re: Question about log files.
« Reply #1 on: July 20, 2007, 01:39:28 am »
if i remember correctly from my recent attempt, that log you have on the bottom there with all the verifieds looks like it is hacked.  I had a problem with log file generation on my unit as well, but those verifieds were key.  hope this helps (and is correct).  :)

Offline judb

  • Administrator
  • Veteran.
  • *****
  • Posts: 1329
  • ph4t l3wtz
Re: Question about log files.
« Reply #2 on: July 20, 2007, 05:02:17 am »
rename / delete the patch logs, and make a new bootload.log file if you want by removing it and copying properties.xml as bootload.log and try again.  it looks patched but if you have some doubts then try the logs again.

Offline kaet_22

  • Newbie
  • Posts: 2
Re: Question about log files.
« Reply #3 on: July 20, 2007, 06:54:13 pm »
Hey Guys,   Thanks for the help.  It turns out that the hack on the PB did take.  We were just a little unsure because of the missing patchverify.log and because we only heard music when it finished with the hack instead of the "hack complete" announcement.  Anyway, we formatted my new 120 gig drive and loaded music and everything seems to be working great! 

A couple of notes on Wiki Hack Procedure:
1.  The procedure does not say which file to run to restore your DMS to its orignal state.  The instructions at the end of DMShack batch file tell you this, but the "DOS" window closes before you can read it.  I would sugest putting a wait for Enter key command at the end so that it stays open until the user reads it.

2.The instructions are vague about where to find the firmware to load on the DMS. They only say that they "can be found on the Firmware page."  It took a little while to figure out that we could just load them form the PMM.
 
3. The instructions say that  after a successful boot of the DMS that you should copy the plugins and tts directories.  I found the tts directory but not the "plugins".  Does every DMS have the plugin directory?

Thanks again!

Offline judb

  • Administrator
  • Veteran.
  • *****
  • Posts: 1329
  • ph4t l3wtz
Re: Question about log files.
« Reply #4 on: July 21, 2007, 02:44:48 pm »
the instructions also say not to run the bat files from explorer, to use the command prompt so you dont have windows closing on you.  but thats a good point non the less.

Also anyone can register on the wiki and can make edits to the content of the wiki if they are so inclined.

The bat file method on windows is very close to being replaced by a windows application thanks to VortechS.  So shortly I'll just get around to hiding that info so people don't try and use it.