The diode on place of the jumper also has a polarity, if you get E79, try inverting it.

Also you could be suffering of a severe case of ORIGINAL SMC (means no JTAG patches are being sent from SMC to GPU)

Only way to know for sure is trying. 

You would be caught and have them send it back to you banned and not repaired...

XBOX360 uses an *SIGNED* digital certificate which has the microsoft logo, information about the HDD size, model, maker and unique serial number.
Putting another HDDSS on the HDD will not make it work.  If you're wondering why HDDhackr works, it ONLY works with an specific series of Western Digital drives (Scorpio) and mods it so it's inquiry matches that what is on the HDDSS file. 

Hence why your thread was called "fail".

I suggest that you research the stuff before posting here. 
And to sum things up, only Microsoft can make your drive work on a legit XBOX360. I doubt they would want to help you, though. Perhaps they would ask you to buy an 120GB HDD which is just Plug'n Play (lol)....

You mean, by patching the said code ?

OP: Being rude is stupid. And all you will achieve from attempting to swap KVs on Jasper is Christmas lights.

Even junkyarding this, it makes for a good example of why the KV hashing should not be NOP-ed out from the kernel on Freeboot/XBR, I suppose.

All internal apps from MS (maintenance, test apps stuff and similar) require connection through the network port to function (I think of that as an anti leak protection because sometimes people forget discs and memory units on customer machines ) with an server they set up on the repair center. Remember the leaked ping17 disc which had a "stress test" build of either PGR or Forza ? (I don't remember which game was it but it was one of the MS own racing titles)  It only runs if it detects that said "server".

It seems like this is a MS APP and it won't be useful at all without their "server" lol.

Some picky falcons often 0020 or 0022 with the JTAG wiring installed. Adding a diode on place of the jumper has become an standard procedure on my installs.

Quoting my own post:
http://www.xboxhacker.org/index.php?topic=14956.msg108803#msg108803

I use that circuit because the output is open collector, giving me peace of mind.

The new DASH added technological means for them (Microsoft) to make new, stricter checks. But for obvious reasons (code security) the checks are deployed (uploaded and executed) when you log onto XBOX Live. Also it was made "public" by the firmware hackers that each drive firmware (newer drives like all Lite-ONs) contains unique "calibration" data which is very likely to be matched with data on the nand. Tinker with that and you're flagged as pirate. Can't get any simpler than that.

The reason for that is that they're obligated to set a certain threshold to give some room for hardware faults.

And even so they're so strict that sometimes they get legitimate customers mistakenly as pirates sometimes, but they do investigate the case again if you dispute it on their forum.

And it's great they do that. Playing a online game with people exploiting stuff is not fun at all.

lol after I read this thread OP's post I though: This post has powerful "landfill" potential. No offense intended.

Do you realize that KV on it's RAW form (as it's stored on the flash) is encrypted with the CPU key ? So it's stuck with the console it came with ?


So for swaping KVs around you need to decrypt and re-encrypt. Anyway why you just don't use the original keyvault from the console you're modifying ?
I see no useful reason for keyvault swapping. And since you can boot xell in it (you didn't try though, right ?) you can decrypt it's original KV and obtain it's DVD key.

lol sometimes you guys make simple things look so complex...

Means that dump has became corrupted at the mentioned block. ibuild detect that by checkling for mismatching sector contents data with the ECC.


What you did was make the program regenerate new ECC data for the dump.
Is it a fix ? For making the corrupted dump itself usable, no.
For a attempt on making files within the dump extractable, yes. Go for it.


All files dumped by ibuild will be in their decrypted form. XEX files will be still encrypted with the normal XEX encryption, though.
Security files will be plain text (fully decrypted).
If files are appearing in a way they look like encrypted, they are in fact corrupted and the CPU key is incorrect.


If you use flashtool to extract an SMC from XBR or XELL image, take the smc_dec.bin file, rename it to smc.bin and toss on the data folder of the 9199 build directory.
Again, all files being used with ibuild should be on their decrypted form.


No worries...

I used files from 6717 once to make freeboot for a bricked system (I had to extract files with 360 flash tool and extract the meta files by hand with winhex because the original dump as corrupted was refused by ibuild...) and it worked fine. Even SECDATA came as clean on xVal.

Older XBOX (Classic XBOX) = hacked BIOS

Classic XBOX emulator on XBOX360 reads game video mode flags, see it is not allowed to run on VGA and then stops.

The game clearly states IT IS NOT COMPATIBLE WITH VGA CABLE.
You will need a PAL TELEVISION to play it.

Peace.

No, it won't work with your ASUS LCD.

The behavior you're trying to change in ibuild images are intentional.

When the original image was read and separated on it's components, any user specific data which isn't related to the security files, is discarded/not saved.  It's likely done that way so ibuild don't need to contain code to convert the said data into new formats which might be changed in newer dashboards (newer than the one on the original/source dump).

It's impossible to use another CPU to retrieve the original CPU key because:

1- The CPU key is stored on the CPU itself and by removing it and replacing with another, you change the CPU key.
2- The "newly installed" CPU cannot decrypt the original console keyvalt, thus being unable to decode the DVD key.

The keyvault on the motherboard would still be that of the old CPU, causing it to not boot, this explains XBR/Freeboot not booting.

I wonder if he knows that the keyvault is "married" to the CPU so he MUST take it with the CPU from the falcon mobo to the new Jasper mobo he hacked.

Well ... That's it ...  Xell is booting so this might have future.

"In this case it won't be possible because the unit was acquired by trade with an customer because it was without DVD key and the customer kept the original case because it was customized. If needed, next time I can take a picture of the label and pair with the KV."

Yes. I want to see that too.
It's easy enough to hexedit the keyvault and make it look legitimate to the naked eye.

But then I want to have the file tested for authenticity digitally.  I am still in belief that he swapped the CPU to salvage the board.

I just believe he put an Falcon CPU on that Jasper mobo. If they're the same part (or similar enough) there's no reason for it to not work. As Tiros pointed out by great observation on the youtube video the system was updated at least 6 times (I am not sure if brand new falcons came out of factory with LDV 0 but I know that NXE jaspers come with LDV 1) and there's no way an brand new kronos GPU jasper has been updated 7 times already.