AUTOHACKER V2.1 IS OUT CHANGELOG:
============
v2.1 :
Fixed a bug where CB version 6723 was reported as not exploitable.
Added a self-check upon startup so that all the files are in place and correct version.
Added feature to automatically unpack XBR images in case the user threw them in the folder without decompressing first.
v2.00BETA:
Complete rewrite. v2.00 Initial Release
Updated first post with download links etc.
danthaman673, thanks for trying this out. I want to make a quick note on the "two same bad dumps" thingy. It is obvious that the chances of that happening is about the same as the chances of achieving 3 bulls-eye's by randomly throwing a bucket that contains three darts out of the window on the third floor of a building, while the target is on the ground. That's TOUGH
I also think that if two dumps are the same, but contain errors (the same errors), but are REPORTED by NandPro, the reads are good, it's the blocks that are bad...
Which brings us to our second topic.
Regarding the bad blocks:
The type of solution you are suggesting indicates that one doesn't understand the "problem".
The bad blocks are automatically relocated during write. That is what the controller and ECC is for.
A small FAQ on how NAND memory works (for anyone interested for discussion, because I see a lot of people confused about such stuff):
When NAND is erased, all bits are set to 1' (that means 0xff on all bytes if we ever dumped an erased NAND memory).
We can change as many bits as we want to '0'.
We can't set a bit back to '1' by simply writing. We have to erase a whole erase block instead and set again the rest of the bits to '0'
The number of erase cycles per block is not infinite. Wear is introduced each time we erase and write a block (which can also be done by the controller automatically, without asking us, if it has to set a bit back to '1').
If a bit reaches the limit of its erase/write cycles, it will not get back to 0xff.
This is a bad block. A bad block does not affect the performance of valid blocks because it is isolated from the bit line and common source line by a select transistor.
Now, some blocks are bad even in an untouched xbox360 (and any NAND memory, for that matter). The vendor just marks those blocks as bad to cut down costs (similar to dead pixels, only more bearable and not at all a deal-breaker). When a block has been marked as bad, the NAND will not simply fail to write, but the conrtoller will skip it, thus relocating it automatically.
Now, there are some special blocks that are vital to the xbox360 functionality. It's three blocks that contain our KeyVault and our ConfigBlock. These have an address in the NAND, that will not change. It is always in the same spot. These are the only three blocks that we need to patch XBR (we just take full backups for extra-safety).
Obviously, if, say, Hynix sends a NAND memory with one of these three blocks marked as bad, the xbox will fail to power up, and the memory will be sent back. In fact I doubt that the vendors even sends such NANDs, they just know, it will not work (many times there are some special block ranges that have been tested out and guaranteed too survive a big number of erase-write cycles, used for important stuff such as bootloaders, this may well be the case with XBOX360, too). Knowing that these blocks not bad (because if they were the xbox wouldn't have existed in the first place) and the fact that they can be written successfully, is the reason why we shouldn't care much about bad blocks. I have never seen any xbox fail due to bad blocks. Or else, even normal xboxes without JTAG would fail on their own during updates.
Might I say on the dump issue that the effect I was refering to is usally caused by LPT port logic levels being consistently inconsistent (If that makes sense) And that some controller nuances can put long strings of 1's for exsample as slightly shorter than they are (In exactly the same way every time). Also what if you get two dumps of all zero's?? Granted these things happen rarely to those who haven't done it successfully before (or if some one has been playing with ur bios settings), but it does happen :-)
Also isn't there somewhat of a difference between blocks marked as bad from manufacture and those that become so after a while from 'write leveling'? Also what if ECC becomes corrupted by voltage spike or what-not?? Obviously I see ur point about there only needing KV end Config from the zero paired, I would think config block prolly doesn't make it into the 'un-remappable @ mobo manfacture' category. I would like to be certain they don't also re-map KV if it suited them (God knows M$ will pinch every concieveable penny they think they can get away with
) As I wouldn't imagine them being worried about a retail mobo's nand being re-written by an outside controller.The onboard would know to re-map those blocks I always thought(unlike that of the PC's) - but I'm frequently wrong
.
Often it's the older boxes that have seen at least one update that show bad-blocks apon forensic inspection (It's not that much drama to remap with redline's tool anyway - In my experiance it sometimes prevents random RROD'ing that doesn't seem to be attributable to anything else it would seem) I guess what I'm saying (what I've always thought) is that if you have a box that has badblock(s) that have in the original been remapped and you write over the top without 1st remapping surely you run the risk of having a cruicial part of the new image landing on one or more of those bad blocks??? (Given the fact that PC's controller doesn't test-write each block or read ECC as it goes)
PS:Sorry if this post may lack readability but I don't have the time to proof/edit etc..
Author
Topic: Autohacker V2.1 (Read 877 times)