Topic: Wrote Bad Data To The Eeprom, Now What? (Read 525 times)

thesmj · « **Reply #30 on:** March 02, 2010, 09:00:00 PM »

Great news! I flashed the image back to the xbox with the shorter (2.5') cable, and now it boots right up no problem. Thanks for all the help guys!

Now, I just have to un-cripple the HDD and it's a mission accomplished. (IMG:style_emoticons/default/biggrin.gif)

Martinchris23 · « **Reply #31 on:** March 03, 2010, 12:40:00 AM »

QUOTE(thesmj @ Mar 3 2010, 04:00 AM)

Great news! I flashed the image back to the xbox with the shorter (2.5') cable, and now it boots right up no problem. Thanks for all the help guys!

Now, I just have to un-cripple the HDD and it's a mission accomplished.

Glad you got it working! (15ft cable......

) lol, I suppose you thought it wasn't important to mention this

xBang360x · « **Reply #32 on:** March 03, 2010, 04:25:00 AM »

QUOTE(Martinchris23 @ Mar 3 2010, 02:40 AM)

Glad you got it working! (15ft cable...... (IMG:style_emoticons/default/rolleyes.gif) ) lol, I suppose you thought it wasn't important to mention this (IMG:style_emoticons/default/wink.gif)

Guess that is one of the first things to ask next time...

15 ft I dont even know why you would want it that long to begin with...

Glad you got it all working now..

Martinchris23 · « **Reply #33 on:** March 03, 2010, 07:22:00 AM »

QUOTE(xBang360x @ Mar 3 2010, 11:25 AM)

Guess that is one of the first things to ask next time...

15 ft I dont even know why you would want it that long to begin with...

Glad you got it all working now..

Sentence #2 almost answers sentence #1

Every guide on LPT flashing tells you to use as short a cable as possible, so you assume this has been followed. I will be sure to ask in future tho

thesmj · « **Reply #34 on:** March 03, 2010, 07:23:00 PM »

I used a 15 foot cable because I have read other people's success using long ethernet cables. Apparently they were lucky. It also allowed me to easy switch between the computer and the TV, because the cable was long enough.

In any case, I cant seem to get either findsecdata or 360 HDFR to get my HDD back up to snuff again. HDFR has me write the secdata_patch.bin file at an offset of 0x3b4, which while nandpro says it flashed ok, there is no difference in HDD usability. findsecdata had me flash two files to two different offsets, and this still made no difference.

I dont think I'm using these tools wrong based on all my reading. I've read that they're not perfect at always choosing the correct secdata to overwrite.

Martin, mind taking a look? (IMG:style_emoticons/default/unsure.gif)

This post has been edited by thesmj: Mar 4 2010, 03:23 AM

Martinchris23 · « **Reply #35 on:** March 04, 2010, 05:43:00 AM »

QUOTE(thesmj @ Mar 4 2010, 02:23 AM)

I used a 15 foot cable because I have read other people's success using long ethernet cables. Apparently they were lucky. It also allowed me to easy switch between the computer and the TV, because the cable was long enough.

In any case, I cant seem to get either findsecdata or 360 HDFR to get my HDD back up to snuff again. HDFR has me write the secdata_patch.bin file at an offset of 0x3b4, which while nandpro says it flashed ok, there is no difference in HDD usability. findsecdata had me flash two files to two different offsets, and this still made no difference.

I dont think I'm using these tools wrong based on all my reading. I've read that they're not perfect at always choosing the correct secdata to overwrite.

Martin, mind taking a look?

Yep, R/W using a 15ft Ethernet cable via LPT is not only risky but miraculous that it ever worked at all!

I've still got a copy of your NAND so I fired it up in 360HDFR. The issue is you have two entries for November 2009, either (or more likely both) have compromised data for preventing HDD installs.

You've written the one at offset 0x3b4 (dated 13/11/2009), so also write to offset 0x242 (dated 03/11/2009)

If THIS doesn't work, go through the following offsets in this order, trying after each write:

0x25a
0x3ba
0x3b8

You have a copy stored at 0x3b6 which you should keep intact!

Let me know how you get on.

thesmj · « **Reply #36 on:** March 04, 2010, 08:31:00 PM »

242 is still crippled. If I try writing the file to 25a, I get a E71 error during the boot sequence.

I'm going to re-write the full image back and try skipping over 25a to 3ba, and go on from there.

BTW, from the command line:

"nandpro lpt: -w16 secdata_patch.bin 0x3ba 1"

is the same as

"nandpro lpt: -w16 secdata_patch.bin 3ba 1"

Correct?

Martinchris23 · « **Reply #37 on:** March 05, 2010, 01:48:00 AM »

QUOTE(thesmj @ Mar 5 2010, 03:31 AM)

242 is still crippled. If I try writing the file to 25a, I get a E71 error during the boot sequence.

I'm going to re-write the full image back and try skipping over 25a to 3ba, and go on from there.

BTW, from the command line:

"nandpro lpt: -w16 secdata_patch.bin 0x3ba 1"

is the same as

"nandpro lpt: -w16 secdata_patch.bin 3ba 1"

Correct?

The file you're writing back from 360HDFR is zeroed out, meaning the 360 should move onto the next copy of secdata.bin. If you're getting E71 either it wasn't flashed correctly or the wrong area was specified.

And yes, 0x3ba or 3ba will suffice in nandpro.

thesmj · « **Reply #38 on:** March 05, 2010, 10:02:00 AM »

Could it have something to do with the bad blocks on the eeprom?

EDIT: What if I were to use findsecdata's dumps and take the secdata originally meant for that block and write it over one of the earlier secdatas?

This post has been edited by thesmj: Mar 5 2010, 06:08 PM

RRODXbox · « **Reply #39 on:** March 05, 2010, 10:33:00 AM »

QUOTE(Martinchris23 @ Feb 24 2010, 03:47 PM)

Yep, there's definitely an issue there. You're on 8955 so there's no way your LDV should be 0 for all three values. Not only that, but you should have pairing data too.

Unless you have a valid dump which shows you what values these should be at, I can't see any way forward. If it was exploitable still, you might have been able to downgrade but that's out of the question.

That happens if he hasnt got 1bl ticked.

thesmj · « **Reply #40 on:** March 08, 2010, 03:15:00 PM »

Bump. Anyone?

Martinchris23 · « **Reply #41 on:** March 09, 2010, 10:53:00 AM »

Sorry you're still on this

writing 0 data to the block at 0x25a shouldn't cause E71. Try this:

nandpro lpt: -r16 goodsec.bin 3b8 1

nandpro lpt: -w16 goodsec.bin 25a

Basically taking the oldest copy of secdata.bin and writing over the one at 0x25a.

or...

Failing this, try the FindSecData route:

ECC change: 0xDE Filetbl: 0x03BA Secdata: 0x03B9 Timestamp: 33766001 2004-04-13
ECC change: 0xDD Filetbl: 0x03B8 Secdata: 0x03B7 Timestamp: 33766001 2004-04-13
ECC change: 0xDC Filetbl: 0x03B6 Secdata: 0x03B5 Timestamp: 33766001 2004-04-13
ECC change: 0xDB Filetbl: 0x03B4 Secdata: 0x03B3 Timestamp: 3B683961 2009-11-07
ECC change: 0xDA Filetbl: 0x03B2 Secdata: 0x0241 Timestamp: 3B5D18EE 2009-10-27
ECC change: 0xD2 Filetbl: 0x0240 Secdata: 0x0259 Timestamp: 3B472D23 2009-10-05

So you want the secdata from 3B9 (secdata03B9.bin) and file table from 3BA (Patchedfiletable03BABy03BA.bin)

then write these to:

secdata:
3b7
3b5
3b3
241
259

patchedfiletable
3b8
3b6
3b4
3b2
240

Let us know how you get on.

thesmj · « **Reply #42 on:** March 09, 2010, 11:18:00 AM »

Thanks! I'll try this tonight.

btw, what is the 1 for at the end of the nandpro command? Why is it sometimes used when writing a single block, but not always?

Martinchris23 · « **Reply #43 on:** March 09, 2010, 11:42:00 AM »

unless you're only writing x number of blocks from the start of a file, you don't need to state it when issuing the write command.

thesmj · « **Reply #44 on:** March 09, 2010, 08:12:00 PM »

Tried both methods - still get E71 errors.

What I dont understand is that I can re-write the original nand.bin back to the xbox and it'll get it back to normal- so it must be writing ok. It's just that after I write to certain parts of the nand I get this error.

Author Topic: Wrote Bad Data To The Eeprom, Now What? (Read 525 times)