After countless posts of repeating myself, I've decided that it's best to write this guide instead.
First off, let's understand the main difference between the old SMC exploit (JTAG) and the new Reset Glitch.
JTAG consoles emulate the e-fuses, therefore data stored within (with the exception of the lines 3,4,5,6 - the CPU key) are not addressed. This is why JTAGs are a lot easier to manage in terms of updating. It doesn't matter what state the remainder of fuse lines are in as it doesn't care.
So, back to RGH (as this is an RGH tutorial).
Every time you run an OFFICIAL MS update on your console, the Lock Down Value (LDV) will increment by one. This value is written to the base address of the NAND as well as into secdata.bin as well as a couple of others. I think the console can go up to an LDV of 80 and after that, it doesn't increment any more.
It's worth noting at this state that the bootloader (CB) and LDV are the FIRST thing the console checks when it boots. If the LDV doesn't match what the CPU e-fuses say (or more importantly, is LOWER than the CPU e-fuse LDV), you'll get 3 red lights and 0022 Secondary Error Code. This isn't your average run-of-the-mill RRoD, so don't assume it is.
Whatever you see in XeLL is LAW. The value for CPU key for instance is a permanent string and CANNOT be changed (and won't ever change, unless you replace the CPU).
The e-fuse lines are a different matter, and this is where you will trip up if you don't understand the basics.
Example - you've just finished with an RGH console (or indeed rebuilding a retail NAND for unflagging) and after flashing, the console sits and looks at you for about 20 secs and FINALLY gives you 3 red lights 0022.
Crap.
Don't panic. The chances are you've done something out of sequence or the NAND dump you used for the source image is older than what was previously on the console.
Solution:
1. Boot XeLL. If it's an RGH console doing this, then XeLL should still work as it doesn't need to know about any details from your console (with exception of the smc and CB values, but that's by-the-by).
2. Count the number of ffff's you see on lines 7 and 8 (directly below the CPU key). This is the current LDV number for the console. As long as you don't run any more official MS updates, this number won't change. Alternatively on phat consoles, remove R6T3 and this number will NEVER change, regardless of what you try to apply.
3. Download Multi_Builder (latest version). You'll see me harp on about this tool just about everywhere. I do because it's probably the most functional image build tool out there.
4. Go into Data/my360 and put your cpukey.txt (a txt file with your CPU key) and nanddump.bin into this folder . ANY previously valid dump for this console will do. LDV and dashboard level are irrelevent. You can even use a previous RGH image should you want to.
5. Open options.ini (options_r.ini if you're building a new retail NAND). Find "cfldv =" and add your number from XeLL after this, so if you counted 8 fff's, then "cfldv = 8". Save and close the ini file.
6. Run Multi_builder. Choose your board type, then choose whether you're building a retail or RGH NAND. Note at the very end you should see something like this:
---------------------------------------------------------------
nandflash.bin glitch image built, info:
---------------------------------------------------------------
console : falcon
NAND size: 16MiB
CPU Key : 71929DA455E71BD95654E071D1018C33
1BL Key : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
CF LDV : 8
---------------------------------------------------------------
ggBuild Finished. Have a nice day.
---------------------------------------------------------------
The CF LDV should match what you entered into options.ini.
Flash this new nandflash.bin to your console and it should now be ok.
NOTES:
1. It's possible to sort this out without being able to boot XeLL. If you only have the CPU key for example and no longer have the ability to run XeLL, take the LAST KNOWN DUMP for the console and open in 360 Flash Dump Tool. Note the highest LDV number. Now follow the steps above and increment the LDV number by one each time, so build and flash to the console - rinse and repeat until it boots.
2. It's also possible to do the increment in 360 Flash Dump Tool, however this is not advisable since other files like secdata.bin etc have the LDV in there too. Whilst this won't affect an RGH console, those booting a retail dash will have issues the next time they update (E81 more than likely). Therefore, simplicity rules and using the same method for both RGH and Retail NANDs wins.
Hope this helps some of you scratching your heads over this.
PS I've done this entirely from memory and it's 1am here, so please excuse any errors!
LinkBack URL
About LinkBacks
ups...
Update dashboard-a JTAG konzole sa RAWFLASH
RTFM
ali uspesno reseno.
Emigrant
E=M x C2
