Hacking Need updated info on how to JTAG xenon 6683

[DeadlyFoez]

I've got an infectus (If you don't already know me, I'm a pro with the infectus on the wii). I've got a xenon with kernel 6683 on it. I know that it is JTAG-able. I don't care to pay for a reset glitch modchip.

I've never seen a tutorial on how to jtag using the infectus, I've just always have done it with nandpro and my parallel port. I also know that a lot must have changed since what I learned last time I did a JTAG 1.5 years ago, so I kinda need to get caught up to speed. Everything that I have found for info is just really old info and all the places that I used go to have seemed to have closed or been bought out by shitty companies.

Would someone please just give me a little info or a few links to help get me caught up and point me in the right direction? Thank you.

 

[DinohScene]

You'll have to make a NAND dump from the 360, I have no idea if an Infectus can do this tho.
Then flash XeLL to the NAND to grab your CPU key to build a hacked image.

You only have to solder in some wires + a few diodes for accomplishing the jTAG hack.
You will need those wires installed for XeLL to boot.
Reset Glitch doesn't work on the Xenon and would never work.

I'd also recommend doing the 12v Fan mod and installing an extra 80 MM intake fan in the side.

 

[DinohScene]

jTAG wiring for the Xenon: http://forums.xbox-scene.com/index.php?showtopic=693742.

I've did a quick overlook and it's still the same.

You may optionally update to 7371 and then preform the jTAG hack.
Then update to 9199 (with a hacked NAND) and after that update to 14699 (with a hacked NAND)

To get Avatars to work just download the update from the MS website (provided you have updated to 14699) and run it from a USB drive.

If you're really paranoid on loosing the jTAG hack you can optionally bridge 2 points on the board to prevent eFuses from being blown.
Pics and tut: http://team-xecuter.com/forums/showthread.php?t=53292

 

[DeadlyFoez]

I've already bridged the point to prevent e-fuses being blown, I already added in the diodes and jumper. I was going to add in a couple extra fans, replace the gpu heatsink for the one with the heat pipe, and I also have a x-clamp fix kit that I was going to throw on it too.

With using the infectus, I can read and write to the full nand, or just individual block if I want, but I can't do things like how it is done with nand pro where you write to specific addresses. The infectus will read the full nand including the ecc, and you can't make a dump without grabbing the ecc.

Thank you for the info.

 

[DinohScene]

Looks like you've done everything except flashing the hacked NAND ;p

Then your option (cheap option) would be to make a LPT programmer with some diodes and a old printer cable.

tut: http://forums.xbox-s...howtopic=691873
(ignore the CAT 5 connector crap)

edit: You're welcome ;]

 

[DeadlyFoez]

Yeah, I was hoping I could just flash xell with the infectus since it will take so much less time, but I don't know what block (not the address) I need to flash xell to. This is the only bit of info I can't ever find when I search the net.

So once I get xell installed, I can just dump the keys and then use BestPig's toolbox to get a nand image that will bring me to the most updated kernel?

What about game loading? How can I load games off a USB drive? I also can't seem to find much for homebrew.

Thank you so very much. This is greatly appreciated.

 

[DinohScene]

You can inject XeLL into the NAND with coolshrimps jTAG tool (just go to advanced mode).
That hopefully should flash XeLL to the NAND.

If it works it should load up XeLL.
Then you'll have to combine fuseset 4 and 6 or 5 and 7 to get your CPU Key.

Then use that CPU key to build a hacked 9199 image using freeBOOT (or with the jTAG tool)
After that, build a hacked 14699 and flash that to the 360.
This can be done from within XeLL itself.

Game loading can be from the internal drive (as wel as external) in 2 ways.
GOD containers (handy for people that don't use Freestyle dash)
Xex files (uses WAY less space on the HDD but is only launchable from either XeXMenu or Freestyle dash)

Homebrew is somewhat limited.
We got a few emulators for XeLL....

But with the new RGLoader (Devkit NAND on retail consoles) + the new Reset Glitch, Homebrew should gain momentum.

I'd go for a big internal HDD since it's faster then USB ;]

edit:
Here's a link for a tutorial + Live CD of XeXmenu for setting up your jTAG with Freestyle dash.
http://pastebin.com/Pv0TqMpE

reason for edit: added some info.

 

[DeadlyFoez]

Out of couriosity, why do I have to go to 9919 first and then 14699?

 

[DinohScene]

I honestly don't know.

I've seen it all over the Internet that if you're on pre 9199 dashes you should upgrade to 9199 first and then go to the latest dash (in this case 14699)

So I'd personally upgrade to 9199 first and then 14699.
It might work upgrading straight to 14699 but I wouldn't know.

 

[DeadlyFoez]

So, just going on everything else I've been reading, I decided to give degraded a try and I made what was supposed to be a 1888.bin and I flashed it and my xbox would just stay at a black screen on startup.

Since I could not get any sure answer of how I can install xell with infectus I figured I try an old method of downgrading first. I've read a few more things of how I can use nandpro to inject xell into my nand dump so I am going to try those and see what happens.

 

[FAST6191]

I am not entirely sure why people would suggest moving through a few dashes as JTAG machines should now and always be on the dash they are at (the rebooter takes care of being at the dash as far as code is concerned). If I had to guess though I would guess one of two things
Pre 9199 also includes xbreboot and by making a 9199 freeboot you should have something nice/assured working to start off with (xbr build methods and how it all works led to some quirks).
14699. The biggest issue I see here is making sure you have a DVD firmware suitable for the task at hand as that would be past the DVD reflashing update (as an aside the CPU key plus nand will cause 360 flash tool and several other tools to spit out a DVD key thus eliminating the "hard" part of DVD firmware flashing).

fbbuild and co do a stunning job though and I reckon it is more or less at the point of building a working image (you not hosing the CPU key entry aside) or not at all.

Everything else seems to be sorted. Others wandering by http://www.infectus.biz/tutorials.php has roughly what goes in "Tutorial how to downgrade X360 dashboard with INFECTUS" although it is best if you can translate the logic across (absolutely no need to downgrade and much of what is there I would not do in light of all the new hacks and JTAG but being able to dump and flash NAND is what you want which that tutorial covers).

Do note however you can flash in software if you want after having just got xell onboard with the added bonus of it should take care of any bad block remapping (ECC I believe you were calling it- a valid term but not that one that is really used in these circles)- indeed all the cool kids did it that way if for no other reason than it was faster.

 

[DinohScene]

I have never used a Infectus on a 360 so I can't give a solid answer on that.

It's just the matter of injecting XeLL into the NAND on the PC.
Flashing it back wouldn't be a problem at all.

When you got XeLL on the 360 you can flash any hacked NAND to the 360 from a USB drive.
XeBuild or fbbuild can build a hacked image indeed.

 

[DinohScene]

Found something on injecting XeLL.
http://www.xboxhacker.org/index.php?topic=12627.0

 

[DeadlyFoez]

I know I can use nandpro with my dump that I make with the infectus and just flash xell into the dump, then flash my dump with the infectus. I just need to find a good page with all the correct commands (or addresses really) for me to write into the dump. That info I have not been able to find again.

I tried that coolshrimp jtag tool, but I can't get it to work with files that were dumps that I made with the infectus, only shit that it takes from usb or lpt, and I really want to avoid the lpt route.

Now mind you, I had successfully jtagged a few consoles in the past. I remember the type of crap I had to do before. I'm not a complete noob, but it's just been a while and so far it is seeming like my old ways that I did things before are mostly still current given the xbox that I have.

 

[DinohScene]

Have you tried the stuff from the xbox hacker link?

It's worth a shot imho.

 

[DeadlyFoez]

My 360 came with a torn apart hitachi drive, I was able to spoof it to my BenQ drive with LT1.1, so I'm all set on that end.

Do note however you can flash in software if you want after having just got xell onboard with the added bonus of it should take care of any bad block remapping (ECC I believe you were calling it- a valid term but not that one that is really used in these circles)- indeed all the cool kids did it that way if for no other reason than it was faster.

ECC and bad blocks are rather unrelated.... kinda. There are factory bad blocks that are permantly marked on the nand because of even just one bit in that block that can't be set but instead locked into place. Bad blocks can occur over time, and it is the ecc data that can be a trigger, but the system/hardware/console has to find its own way of dealing with it. With the wii, the handling code was done in the IOS.

ECC is just a checksum of the data in a block. But, like on the wii, there can be ECC mismatches, but everything still functions correctly. The reason being is because the console handles the ECC in it's own way. The wii and xbox 360 do it in a standart way, but the ps3 did their own way of obfuscating it.

But that is just kind of a quick explanation of how ECC failure != bad blocks, but it is still handled differently by each system.

When I dump my nand with the infectus, it includes the ECC data. I forget (and since I can't find a page utilizing the old nandpro methos) I can't confirm if a normal nandpro dump does also dump ECC data or just the FS data.

When I make a dump with my infectus, the dump comes out to 16.5MB.

It's kinda shitty that my RAID stripe failed on my about a year ago and I had to start from scratch again because I did already have everything I needed to do this method. I'm just reluctant to want to screw around with the lpt port because all my computers are on newer os's and only a few motherboards have an lpt port so I have to rip one out if its place just to do this.

 

[FAST6191]

Yeah that was a bit careless of me using terms in such a manner (especially as I had recently reread http://team-xecuter.com/forums/showthread.php?t=76014 and https://docs.google.com/View?id=dnfmv5h_23gw47ddgs ).

Two links that should get you on your way https://docs.google.com/View?id=dnfmv5h_30dw33vpf4 (it covers the fun parts of nandpro although it probably veers off a bit compared to what you need to do here) and http://www.xbox-scene.com/xbox360-tools/360FlashDumpTool.php (I usually find it cuts through NAND images better than fbbuild can).

 

[DinohScene]

The dump size of the Infectus is good. (my Falcon also is a 16.5 mb dump)

The ECC file doesn't get dumped with NANDPro iirc.
Thats why we had to generate our own ECC files (at least with the RGH)

Btw thanks on enlightening me on how bad blocks are managed by consoles.

 

[DeadlyFoez]

Well just to fill you in even more, or at least what I can tell you about how the wii works. On the NAND, the first block (boot1) is guaranteed to be good (at least from factory). With boot1 it has the code in it to handle bad blocks on at least a basic level so it can read boot2 (usually block 1 to 7), but is there are any bad block in that section then boot1 handles it.

Everytime you use an IOS to install a WAD file, the IOS that is being used to install the WAD firsts runs a check on the blocks to make sure they are good. If ECC fails, that does not mean that the IOS call it a bad block. Homebrew tends to cause ECC failures on the wii. But usually, if an IOS itself marks a block as bad then then current data will be moved out of it and future data will be written to the next available block.

When running bootmii and making a nand backup you may see Factory Bad Block, ECC failure Corrected, and ECC failure uncorrectable. Unusally a COrrected ECC failure is just because of homebrew or whatever. Uncorrectable ecc failure usuallly indicate a block that has gone bad over time and was not a factory bad block.

 

[DinohScene]

Hmm interesting.

So if boot1 gets corrupted due to it's block gone bad your only option is to desolder the NAND and solder in a complete new NAND chip then program it with an infectus?

What if you got a really old BootMii dump wich lets say 5 bad blocks in total.
And your Wii developed 10 new bad blocks over time.
Would you still be able to flash the old dump back on the flashchip without loosing vital data?

Afaik the 16 MB 360's automatically remap all bad blocks to a special area which is reserved for badblocks.

This is crucial for vital data like the Keyvault (somewhere on the first few blocks) and the first and second Config block.

265 MB and 512 MB "Big Block" 360's (mostly Jasper units) skip bad blocks all together.
Only in the first ~64 MB they get remapped to an area reserved for bad blocks.