This code is not guaranteed to be complete and/or working and would require other code/libraries to function properly. I reversed a lot of the sata code from the 20xxx kernel + hv, here is some that may be of use to someone idk: http://pastebin.com/RiFxR3fi

Except that this instruction:
is from 4584, and the reason he needed multiple xbox consoles, is because he has a habit of putting Colgate toothpaste and peanut butter on them.

If it's from sevensins, it's guaranteed bull$#!t.

It would be cheaper to buy the f***ing game. Yea I went there.

XGD3 only required an update for the security, aka stuff that is 100% useless to hackers. You can play XDG3 just fine on any drive as long as you patch the security functions in the kernel.

No it is a corona. Trinity was being developed in 2009, Corona has been in development since winter 2010-2011.

1bl is responsable for reading 2bl from flash into soc ram, verifying, decrypting and jumping to 2bl. The bootloaders in flash (CB, CD, CE, CF, CG) all come consecutively after the flash header, smc code, and kv. A descriptor can be found at offset 0 in flash to describe this section of flash by version, offset, size, and flags.

All of 2bl except for the 16 byte nonce data and rsa signature are signed by said rsa signature. 1bl calls XeCryptRotSumSha on 2bl to form the SHA1 hash, then uses XeCryptBnQwSigVerify with the rsa signature, calculated SHA1 hash, and the salt XBOX_ROM_B to verify the rsa signature.

0xC0000001 is just the error code returned from the last function that exeucted and is a general error. It does not mean in anyway his hardware is failing, even though that could be the case.

You are gunna have to change the max syscall number in the syscall handler. It should compare the syscall number, %r0, to 0x76, and if its greater than or equal it will fail and return. Change it to 0x78 and you should be good. Also peek/poke are the same thing, just with src and dst switched, might wanna make 1 syscall instead of 2.

Mean while in $Systemupdate\su20076000_00000000\xboxupd.bin...

The hv image is 0x40000 in size. Even though on older hv images the second 2 segments contained mostly runtime data, loading a newer hv image like that will only yield half the image, they moved executable code around and added a few new jump tables to make reversing it harder.

If I'm not mistaken on retail CB has a SHA1 of CD, which has a SHA1 of the kernel patch, so you can't just swap in a new kernel patch. On devs CD is rsa signed and has a SHA1 of the kernel, so you can swap CD to other versions.

Wanna go back to se7enskids?

You said you can boot into the dashboard but not into xell. Are you using hdmi? because I have consoles that display nothing on the screen when using hdmi and xellous. Try using SD, it may be booting into xellous and you just don't see anything on the screen. Also check to see if the rol plays the boot animation when you run it.

Must only apply to retails as all my devkits the 3rd fuse line is 0x0000000000000000.

Yea the Imports windows doesn't get used when you use the idc script, but they appear in the functions window. Just click on the function name column header and it will sort the list for you.

Don't go to the entry point. Use the -i option to dump the idc loading script. Then after IDA says "you have just loaded a binary file", goto File-> IDC File and select the dumped idc file. It will do all the analyzing stuff for you.

You can create a generic image and boot up until it fails loading the kv, at which point you can shadow boot a recovery and it will generate you a "temp" offline kv and you can use your console as normal. I've done it numerous times while working on a misc project.
It has my name on it when you run it, I even had one of the idiots who messaged me about confirm that along with all the file names...

This is seriously getting out of hand. The cpu key on a devkit is 100% useless. There is not one legit reason you would EVER need it EVER. I can take any final hardware devkit, erase all of flash, and without knowing a god dam thing about the console, or having any sort of flash backup, recover the kit to a fully functional state (and get on partner net, which is COMPLETLY besides the point I am trying to make here). If people spent less time trying to steal and leak $#!t, and learned how the hardware they have works, then we wouldn't have problems with people leaking $#!t in the first place. Yes that app was leaked, can you guess who made it? Not that it matters any more, but its rediculous that it is now being traded back and forth to people for recoveries and money.

0x80040000 is the loading address for the kernel. But you must split the kernel and hv before you can load it at that address.

Having all executable code encrypted. If it wasen't for the 1bl key being released, then we still would not be able to decrypt and disassemble a lot of the code on the console.