(adsbygoogle = window.adsbygoogle || []).push({}); The 18th syscall in the boot process of the Xbox 360 is known to retrieve the private key for data signing on the xbox kernel. My theory is that the since key is stored in one place in memory and then freed after it is used by the final syscalls in the boot process (XeKeysGetDigest, XeKeysQwNeRsaPrvCrypt, XeKeysDesCbc, XeKeysSaveSystemUpdate, XeKeysExecute), what if we were to create a second variable to hold the key but not free it. After the boot process is finished we could dereference the memory address that the second, un-freed key is held at, then from a dev-kit, dump the memory from that address. I know it's easier said than done but the hypervisor's code is all high-level so if we were somehow able to manipulate it, we may be able to snag the private key and **** Microsoft even more than we have already. Any thoughts? This is just a theory.

Source for some of my info on the boot process: You must login or register to view this content.

i seen this posted on TTG , yesterday :O

this was posted on ttg

I never said I was right, I said that it was a theory. But I definitely typed this out myself, so don't accuse me of copying and pasting. You must login or register to view this content. - I do believe that this is the post you are talking about, look at the times, I was the one who posted this first, dizzy is a kiniving thief.

Let me explain my theory in depth a bit more.

SysCall 13 (0x0C) is the first call in the boot process that frees memory, this is before the memory that contains the private key is allocated.
XexpLoadFile (SysCall 0x11, 18th call) is known to retrieve the private key %r4 holds the header, %r5 is the region, %r6 holds the value 4 which is used to offset the private key, and I'm not sure what %r7 holds.

Btw, %r = register (kinda like a variable, I guess you could call it a reference to memory that holds a variable, kinda).

SysCalls 19 and 20 (0x12 and 0x13) free memory for the XexpLoadFile calls following.

The 37th syscall - XeKeysSaveKeyVault saves and disposes of the memory that holds the private key.

If we were to patch the boot process to make a duplicate of the key and not dispose of it, we could dump the memory from an xex. I wrote a memory dumping xex, I'll post if I find it. But there ya go, there is my theory more in depth, do you believe that I posted this now?...

I appreciate you explaining this better. Next time just don't get so defensive when someone debates your theory. You will be more productive if you discuss instead of argue.

Alright, the flame stops right here right now. If anybody wants to continue to flame this thread will be closed and infractions may come. Have a discussion for once. And a message to the OP do not get out of hand with people. Just simply report and the issue will be take care of. Thanks

My apologies, I just want my due credit.

Mind = Blown