Try starting your Xbox 360 with Eject button...

I can't understand how JF can brick it while you reading flash... Can you guys post your logs here?

Good news for you! Solution #3 is coming!

Check this out: http://www.xbox-scene.com/xbox1data/sep/EFkAuuApZEOevdwBEQ.php

Transplanting to zephyr and rgh should help. My friend from Kursk did it once if I've understood him correct...

I also heard on russian forums that one guy has successfully unbriked his hitachi with maximus lizard, but I don't think that it's true. Anyway I don't have bricked hitachi to check this out... If you or your friends have maximus lizard - you can try this. Who knows, maybe it's real...

hitachi cannot be bricked when you read the flash content. It can only be bricked when you're write something to the flash afaik.

There is 3 possibilities:

1. Your story is a bull$#!t and you've bricked it while you tried to wrote something on the flash.

2. You can transplantate cpu+nand from your xenon to zephyr, glitch it and retrieve the cpukey to decrypt the kv from your nand to extract the dvdkey. Then put cpu+nand back on xenon.

3. You can wait if x360glitchip for corona (that doesn't require HANA-chip to launch the hack) will be updated for xenon support (it has ANA-chip, not the HANA-chip).

...

ORLY? Why you didn't post your method before RichY then huh? This will work on the retail dashboard without rgh. Your "0272+dvdkey+rgh+fwcr_bypass" method wouldn't...
Prove yourself and post your method here or stop to show off your fictional achievements lol.

RichY a.k.a. ARY published a way to re-generate 4096 bytes keyarea from 16 bytes dvdkey!

You can read it here: http://www.hackfaq.net/xbox360/keyarea_regen/

Use google translate to translate the page from russian.

Maybe Xenons will be glitchable in future with new x360Glitchip that does not need HANA to launch the hack?... AFAIK it is the only thing why Xenons was not glitchable after RGH was released.

In slim liteons there is no dvd key as is anymore (16 bytes). There is key area (4 kilobytes). JungleFlasher can't rebuild it because of some $#!tty reason (as always). But someone in TX can rebuild key area from dvd key for $$$. RichY can rebuild it too for $$$.

You can also try to flash 9504, then write your dvd key into drive via Write Key function, then dump 9504 back and extract key area. But key area will differs from original keyarea by 48 bytes. Maybe dashlaunch can handle this out.

Thanks! Very interesting info. Didn't saw it before.

thanks for the explanation of some of our questions.

but there is still one question without answer. can we generate keyarea for 0225/0401/1071 that will pass the realtime check a.k.a. fw hash check?

i mean we can generate keyarea by the dvdkey (32 hexademical chars) via writekey function in jungleflasher for 9504 and after that we can dump dummy and/or firmware from 9504 and extract keyarea from it. it will be 99% identical, except 32 bytes somewhere in 2A000-2AFEF and 2AFF0-2AFFF a.k.a. crapkey.

as I have understood we can forget about crapkey.

but we still need generate correct 32 bytes for keyarea with which it can pass the realtime check a.k.a. fw hash check.

so the question is: can we generate those bytes somehow?

---

also I think 0225/0401/1071 firmwares have some function to inject another key in it (for the needs of the factory) - just like writekey function for 9504 (btw writekey function fails on 0272 firmware as on 0225/0401/1071).

You can inject 0225 key into spare DG-16D4S with 9504 fw (stock or custom - whatever) then dump firmware and compare keyarea blocks. It's differ in 47-48 bytes (I've compare it with WinHEX). Position of 31-32 bytes depends from something. And other 16 bytes always in same place - from 0x2AFF0 to 0x2AFFF...

So the problem is to determine the allocation algorithm and the encryption algorithm.

From what then?

The problem is in KEYAREA a.k.a. KEYSECTOR. It's located in DUMMY and/or FIRMWARE from 0x2A000 to 0x2AFFF, length is 0xFFF (4096 bytes or 4 kilobytes).
If it wrong/invalid - you will get a "Play DVD" problem.

It can only be restored on 9504 drives via Write Key function in JungleFlasher.
On 0225, 0401, 1071 Write Key function is always fails.

In 9504 keysector depends only from key.
In 0225, 0401, 1071 keysector depends from key and serials...

It needs to be researched.
Hackers do not want to help us with this problem for some unknown reason (as usual).

+1

Can somebody reupload it? Thanks!

if you'll put xgd3 disc in kreon - XBC will say that disc is 8.07GB. but if you'll try to dump it - iso will be full of garbage (some random data). looks like old kreon and old XBC got fooled by xgd3 disc...

if you'll put xgd3 disc in normal pc dvd drive - any software will say that disc is 49MB (fake toc as before).

I already saw isos for ODDE - they are over 8GB. but who knows? maybe johnsmith was right... maybe it's because some tricks to prevent old style dumping...

...just thoughts...

It's falcon. And I've seen E79 and RRoD 0020 before many times. It's sooo nice. ROL make some crazy flashing sometime. For example diagonal red leds flashing, or all four leds flashing, but console is PLAYABLE. I've played with four blinking red lights about two hours and all was just great! And after I turn my TV off ROL shows me startup sequence lol!

I'm using Blackaddr's wiring, 10KOhm resistors and 2N3904 transistors. All soldering is A-grade!

so maybe you will upload sourcecode now?...

It looks like a problem with JTAG-wiring. Because after I have disassembled my Xbox 360 again it worked as it should.

I've resolder some wires. Now it's working good.

But sometimes I still have problems with RROD (0020) and E79. Rebooting solves these problems.