|
Helltick
|
 |
« Reply #140 on: August 23, 2009, 08:36:40 PM » |
|
well first, thx to utar for the push...i needed that. the result was success. so to make this picture perfect clear for people having problems like i was... even if nandpro gives you an error 250 while reading dont panic:  after 3 or 4 nand dumps and they dont perfectly match dont panic:  when programming hacked.bin or original nand.bin if nandpro gives you an error 202 dont panic:  i checked with infectus tool and it showed 2 bad pages. the detailed log showed the 2 bad blocks:   even with the above problems...everything worked. i dumped my nand 5 times and they were all different. i flashed the hacked.bin gave me an error 202 while writing but worked and received my cpu key:  i flashed the original nand.bin back gave me error 202 while writing but worked and played a game:  so...all in all...it worked great and i was freaked out over nothing. excellent work to the people who created this sh#t. cuz i'm one happy camper! do this at your own risk it worked for me thats all |
|
|
|
« Last Edit: August 24, 2009, 02:22:17 PM by Helltick »
|
Logged
|
|
|
|
|
l_oliveira
|
|
« Reply #141 on: August 23, 2009, 09:22:45 PM » |
|
What worked for me was:
1- Perform physical hack install (JTAG to SMC link and SPI to LPT connection)
2- Dump original flash (none of the consoles I tried had a bad block on the NAND)
3- Flash hacked.bin
4- Boot XeLL with something incompatible connected in the USB to make XeLL stop and not try to boot from network and CD then write down CPU fuse lines 3 and 5.
5- Put CPU fuses data on 360 Flash Tool and open dump.
6- Check KV data if it's valid (every time it was valid)
7- Backup all obtained data for later use.
From the point you obtained the CPU key and the original dump you can perform the following things:
Recover DVD key (360 Flash Tool)
Change GAME DISC region (360 Flash Tool)
Downgrade dashboard/kernel to any version you desire.
The latest version of Degraded tool will build a working 1888 flash image for your console if you provide it the 1888 file system dump and your original NAND dump, regardless of the pairing state of your console.
One important thing I should mention is that the data on the NAND will change slightly every time you power on the console.
So the backups will never match.
|
|
|
|
|
Logged
|
 It's a Rough World |
|
|
|
Andy1988
|
|
« Reply #142 on: August 23, 2009, 09:35:56 PM » |
|
@Helltick Seems you have a bad block there at 0x1fe The addresses with those FF and FE differences perfectly fit to this block: The NAND has a size of 16MB + 0,5MB in 0x400 blocks (block 0 to 0x3ff). That is a total block size of 0x4200 bytes. For the actual data and the ECC stuff. So your block resulting in an error starts at 0x837C00 (0x4200*0x1fe) and the last byte of this block is at 0x83BDFF (0x4200*0x1ff - 1). As I said... It totally matches. I just don't know why your values at 0x68145E and 0x68145F differ. Did you turn on your XBox between your two dumps? The datasheet of the Hynix NAND Chip says that there should be a list of all bad blocks inside of the "sparse area" of the 1st or 2nd block of the NAND. Whatever a sparse area is... If we had the source code... OK, enough, sorry. I'll stop ranting on this  Let's be friends again. edit: Ah OK. Each block has those 512 spare bytes. That's the 0,5 MB I added above which is used for the ECC data, too. |
|
|
|
« Last Edit: August 23, 2009, 10:03:13 PM by Andy1988 »
|
Logged
|
|
|
|
|
Arakon
|
|
« Reply #143 on: August 23, 2009, 11:28:37 PM » |
|
hrmm.. major differences after the first bytes for me. |
|
|
|
|
Logged
|
I do NOT give support by email, PM, ICQ or whatever. Anyone annoying me that way will have his balls removed. With a rusty butterknife. Slowly. And I'll enjoy doing it.
|
|
|
|
l_oliveira
|
|
« Reply #144 on: August 24, 2009, 12:36:03 AM » |
|
xell_ecc.bin worked properly here... Used this command to flash it: NandPro.exe lpt: -w16 xell_ecc.bin 40 9 |
|
|
|
|
Logged
|
It's a Rough World |
|
|
|
|
|
Ell3X
|
|
« Reply #146 on: August 24, 2009, 03:21:11 AM » |
|
i dumped my nand 5 times and they were all different.
that`s the reason why i just look for "bad pages". i always check my nand dumps with infectus tool 1.1 (nand checker) extract -> choose your dump -> look for bad pages http://rapidshare.com/files/270820429/NAND_Checker_V1.1.rar.htmlUSE IT @ YOUR OWN RISK !!! |
|
|
|
|
Logged
|
|
|
|
|
utar
|
|
« Reply #147 on: August 24, 2009, 04:30:14 AM » |
|
that`s the reason why i just look for "bad pages".
i always check my nand dumps with infectus tool 1.1 (nand checker)
extract -> choose your dump -> look for bad pages
For clarity are bad pages anything to worry about? Checked my dump and had 6 bad pages. Utar |
|
|
|
|
Logged
|
|
|
|
|
tmbinc
|
|
« Reply #148 on: August 24, 2009, 04:58:52 AM » |
|
If bad pages are bad blocks, then no, no need to worry.
|
|
|
|
|
Logged
|
Please don't copy/quote full text outside this board. Instead, summarize and link to this post. Thanks! This lets me keep information updated and doesn't pull things out of context.
|
|
|
|
utar
|
|
« Reply #149 on: August 24, 2009, 05:03:27 AM » |
|
Ok!
Perhaps my question should have been are these a sign of a problem dumping the nand (e.g. a wiring issue) or are these bad pages a problem with the nand itself (hence the dump worked)?
The bad pages in my case were in the same place as one of the 250 errors I got from nandpro. Given that the reflash worked, and I note that helltick had the same issue and managed to reflash the ms firmware as well I guess these aren't a critical error.
[Edit: tmbinc thanks for clarifying.]
Utar
|
|
|
|
|
Logged
|
|
|
|
|
zouzzz
|
|
« Reply #150 on: August 24, 2009, 05:09:44 AM » |
|
Re-upload please in megaupload, rapidshare sucks. |
|
|
|
|
Logged
|
|
|
|
|
Straßenkampf
|
|
« Reply #151 on: August 24, 2009, 05:16:40 AM » |
|
|
|
|
|
|
Logged
|
|
|
|
|
|
|
gupek
|
|
« Reply #153 on: August 24, 2009, 05:34:05 AM » |
|
sorry 4 double post... For reference:
(Secondary) error code 0022 means:
The box switched on, so your SMC code works, but the CPU stopped booting at some point, but without signaling an errorcode (like 010x broken memory etc.) to the SMC. This is likely a corrupted image, or an image which doesn't work on your hardware. For example, trying to use the hack on an updated box would cause this error, but just flashing half of an image, or a broken image, will do the same.
For the tech-savvy, you can measure your POST OUT bus at this point (see the 8 connections required for downgrading). As the value will be static, just use a multimeter, and measure D7..D0 and convert binary to hex. If you post that code here, we can decode it for you.
can anyone help to find POST OUT on motherboard ? |
|
|
|
« Last Edit: August 24, 2009, 05:36:56 AM by gupek »
|
Logged
|
|
|
|
|
zouzzz
|
|
« Reply #154 on: August 24, 2009, 05:42:14 AM » |
|
|
|
|
|
|
Logged
|
|
|
|
|
Shaun
|
|
« Reply #155 on: August 24, 2009, 05:42:57 AM » |
|
yes look on the downgrader schematics, it all on there !
|
|
|
|
|
Logged
|
|
|
|
|
gupek
|
|
« Reply #156 on: August 24, 2009, 06:00:51 AM » |
|
it will be much easier when searching forum will work 4 me, rigth now i have error "Please try again. If you come back to this error screen, report the error to an administrator." trying to find manualy... and post 4 others  |
|
|
|
« Last Edit: August 24, 2009, 06:36:57 AM by gupek »
|
Logged
|
|
|
|
|
Ell3X
|
|
« Reply #157 on: August 24, 2009, 06:36:26 AM » |
|
can anyone help to find POST OUT on motherboard ?
here they are  |
|
|
|
|
Logged
|
|
|
|
|
tmbinc
|
|
« Reply #158 on: August 24, 2009, 06:42:15 AM » |
|
Really, in most cases, 0022 is one of these two causes:
a.) A bad flash. Re-program, readback, and compare with the image you flashed.
b.) Check your original CB version by checking the four bytes at 0x8400 in your backup dump. They should be "43 44 xx yy". The last two bytes are the CB build number. Convert to decimal, and you should get a number from 1888 to 1940 (for xenon).
If it's less or equal 1920, any CB in the hacked image will do.
If it's 1921, you need a hacked image with CB=1921.
If it's 1922 and up, you're out of luck, this console was already updated.
|
|
|
|
|
Logged
|
Please don't copy/quote full text outside this board. Instead, summarize and link to this post. Thanks! This lets me keep information updated and doesn't pull things out of context.
|
|
|
|
gupek
|
|
« Reply #159 on: August 24, 2009, 07:12:25 AM » |
|
right now i have finish write hacked binary to nand second time and it works fine, dvd key extracted(decrypted) and match(correct)... so in my example the problem was a bad flash, why? becasue when i flashed first time i was disconecting and conecting keyboard, mouse, monitor from motherboard of PC...!!! i have found also it is making the mistake in reading from nand... a lot of difference and bad pages in flash!!! so do not disconnect anything from pc while r/w nand - this was my stupid mistake in my correct dump at offset x8400 is 43 42 07 6f what means CB 1903 dash is 7371...  right now... time to find usb stick... thx guys!!! |
|
|
|
« Last Edit: August 24, 2009, 07:14:57 AM by gupek »
|
Logged
|
|
|
|
|
