Nothing more than the fact that the pre-existing data is wiped out as far as the system is concerned. Yes, at a low level there are operating differences between actually erasing a block of the NAND chip and merely marking a block as deleted when a file is removed, but as far as what is visible outside the chip the net effect is the same. The data that was there previously is no longer visible. It is completely replaced by new data. Even if some of the old data is sitting on the chip due to features such as write balancing, it won't be accessible to the system. You won't see it unless you do a full dump of the chip. Incidentally, one nifty way to do hardware watermarking is to use the reserved area of a flash chip (where the backup blocks are stored for remapping back blocks) to drop in your watermark data. That section of the chip is not accessible by the system and the chip itself will never write to that section unless an additional block goes bad and it needs to remap on-the-fly. The average user won't have the skills or tools to dump the entire flash so you end up with a nifty way to track hardware. Back to the topic at hand, if you look at a retail update and how they apply, they are always patched against prior versions. So, if for some reason, you have a file in your flash that gets corrupted you cannot fix it by reflashing the system with one of the public updates. And there is no public way to boot a retail system off the backup kernel image. Now, look at any of the leaked dev recoveries and how they apply. They are designed to always install a full system. The discs don't care what was there before. They assume no dependencies and just install. This is why I say the "baby stepping" idea is an old wive's tale. If the dev recoveries worked like the retail updates, then yes, it would be important to get every patch in order. But since they work more like Windows recovery discs (to make a bad analogy) the "baby stepping" idea fails. I suspect most of the flash issues that people have seen are either due to old Xenon hardware that was already on its last legs or corrupted recovery media. Remember when you're doing a patch system like a retail, the underlying data isn't touched. If power fails during the update there's a good chance the system can be recovered by booting into the old data and rerunning the update. When you're going the full update route, it's no different than a BIOS flash on a PC. If the power cuts out, if the media is bad, if there is any sort of read/write glitch, if the system has a CPU error, etc. -- any of that -- there's a good chance of brickage. So, now that I've answered your question and since you seem to be implying that you understand how the recovery system works, please enlighten the board as to the technical reasons why you say "baby stepping" is required. I am curious to see where you think I am mistaken. -hl718
Baby stepping is not required. Its just a known practice. All the contents of the dev flash are stored within the recovery themselves. Every single file.
Well now I'm screwed... My hash matched up before the attempt to update. It gave me E79 on boot up with disk in, so I restarted. Now I get a whoooooole bunch of nothing, not even a blink. :banghead: Suggestions?... ...other than throwing it away
@bearkilla, @ShadowGuy, Can both of you generate NAND dumps from your "dead" boxes? I'd like to see what's there. -hl718
Please tell me you have a nand dump, if you do then you can just reflash the nand back via lpt or usb flasher. If not then you are probably screwed. Also the first person to tell me about this was a guy on aim, his aim name is xboxdevhacker. The name has been registered since 2000 so it's not just some newly created name, his buddies probably got him to send it to people but yet again failed attempt. Hawk
Oh I have a backup of my nand from a while back but that was using KK exploit. I wouldn't know how to go about doing it hardware-wise...
Well if you want any hope of restoration, now is the time to learn. Basically, you'll have to wire up an LPT port and use NANDPro, same as you would on a retail console. Then, assuming your previous dump is good, you'll use NANDPro to flash the backup image back to your NAND. Reboot and all is well. If you use NANDPro to do a read before writing the backup, you'll be able to get a dump of the current contents of the chip. I'm curious to see what exactly happened to your system to kill it. If you need wire pinouts, you can find them here in this forum. You do NOT need to wire up the JTAG exploit connectors (those have zero to do with reading the NAND) just wire up the SPI<->LPT connectors. If you have a dev with sidecar cables another user posted a schematic for using the existing cables rather than soldering to the board. -hl718
yeah but i have a friend out in cali whoh has a blue zephyr board in his unit... he ran a update and BAM shit stopped working. it was an official update as well. when you read his flash it all checks out too. i dunno its just strange.maybe blue boards are rare and microsoft wanted to pwn them heh.
If you didn't use redlines simple tool to backup your nand before running ANY recovery found off the net, you most likely were not thinking.
i will do a read of the dead one before flashing my backup, will be doing it this week some time apologies for the edit :S
----------REMINDER TO ALL---------- ALL BUYING/SELLING GOES IN THE MARKETPLACE FORUM. NOT HERE. IF YOU WANT TO BUY/SELL/TRADE DO IT IN THE MARKETPLACE. NOT HERE. THERE HAVE BEEN MULTIPLE POSTS IN THIS THREAD ON THIS ISSUE. Questions to PM. -hl718
so i tried this shit out last night... it does infact erase the flash. personally i have a usb olimex. this shit fucks the SMC. so programming via SPI isnt possible. i did this on a retail xenon modded with XBR _3.
