Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/xbh360/public_html/Sources/Load.php(225) : runtime-created function on line 3
Exploitability and hijacking the chain of control.
XboxHacker BBS
 
*
Welcome, Guest. Please login or register.
Did you miss your activation email?
September 01, 2014, 01:30:59 PM


Login with username, password and session length


Pages: 1
  Print  
Author Topic: Exploitability and hijacking the chain of control.  (Read 1241 times)
adcurtin
Newbie
*
Posts: 5


View Profile
« on: January 11, 2010, 07:55:03 PM »

So I have a few basic questions about how the 360 works with loading the different bootloaders and how they're encrypted.

1. The 1BL is on the CPU die, and cannot be changed (right?). Is it encrypted, unencrypted, or we have no (easy) way of getting at the data at all, and have no idea?

2. the 2BL is on the nand, it is encrypted with RSA (right?). The 1BL loads the 2BL, does it do any sort of hash checking other than decrypting the RSA? (so if we had MS's RSA key, we could write our own 2BL and have complete exploitability on all consoles? [I know, won't happen, just helping me figured out how it's loaded]).

3. the 2BL checks the efuses to see if it can run, if it can, what does it do? (if it can't, it throws an error). When the 2BL checks the fuses, what is it comparing to?

4. the 4BL is loaded by the 2BL and is encrypted with the consoles CPU key, right?

5. the current exploit is in the 2BL / CB, how does it work (like a brief overview)?

Thanks.
Logged
littlestevie360
Master Hacker
****
Posts: 313

past the point of caring


View Profile
« Reply #1 on: January 11, 2010, 08:04:39 PM »

1. 1BL can be extracted from linux using dump32
2. 2BL is signed and encrypted, the signature is a sha1 hash that is then encrypted with the private key
3. 2BL(CB) checks the second row fuses to see if its been revoked, the check is hardcoded
4. 4BL is encrypted with the CPU key, but also signed with microsofts public key
5. the SMC JTAG is documented http://free60.git.sourceforge.net/git/gitweb.cgi?p=free60/tools;a=blob_plain;f=imgbuild/hack.txt;hb=HEAD but is not the exploit itself, its just a way of executing the exploit, the exploit itself resides within the 4532/4548 kernel (which was discovered 2 years ago)
Logged
MRA
Hacker
***
Posts: 81


View Profile
« Reply #2 on: January 11, 2010, 08:22:22 PM »

The 4BL is not encrypted with the CPU key.
Logged
littlestevie360
Master Hacker
****
Posts: 313

past the point of caring


View Profile
« Reply #3 on: January 11, 2010, 08:24:40 PM »

The 4BL is not encrypted with the CPU key.
it is in newer units, new CB's encrypt with CPU key from the CD section and on
Logged
MRA
Hacker
***
Posts: 81


View Profile
« Reply #4 on: January 11, 2010, 08:30:54 PM »

Oh, OK. Thanks for the info. Didnīt take a look at kernels since quite a time. Just knew that Xenons CD were definately not encrypted with the CPU key.
Logged
adcurtin
Newbie
*
Posts: 5


View Profile
« Reply #5 on: January 11, 2010, 08:38:12 PM »

ok, that pretty much answers all my questions. Thanks.
Logged
Martin_sw
Hacker
***
Posts: 57


View Profile
« Reply #6 on: January 11, 2010, 08:51:46 PM »

@littlestevie360

The 4BL is not signed, the 4BL SHA-1 hash is just hardcoded into the 2BL. The 4BL in turn contains the hardcoded SHA-1 hash for the 5BL.
Logged
Pages: 1
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC

Valid XHTML 1.0! Valid CSS! Dilber MC Theme by HarzeM