Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
XBox (Games) Programming IT Technology

Behind the Xbox Boot Code 52

NiteStar writes "The Xbox-Linux team has up a new article about The Hidden Boot Code of the Xbox. The Xbox console contains a 'chain of trust' to allow only legit Microsoft signed code to run on the Xbox. The hidden 'MCP' boot ROM (just 512bytes) is the link between hardware and software in this chain of trust." From the wiki article: "The Xbox, having an external (reprogrammable) 1 MB Flash ROM chip (models since 2003 have only 256 KB), would normally start running code there as well, since this megabyte is also mapped into the uppermost area of the address space. But this would make it too easy for someone who wants to either replace the ROM image with a self-written one or patch it to break the chain of trust ("modchips"). The ROM image could be fully accessed, it would be easy to reverse-engineer the code; encryption and obfuscation would only slow down the hacking process a bit."
This discussion has been archived. No new comments can be posted.

Behind the Xbox Boot Code

Comments Filter:
  • best tech. description of the XBOX startup process I have ever seen.
  • A guess (Score:5, Insightful)

    by interiot ( 50685 ) on Monday August 08, 2005 @04:49PM (#13273243) Homepage
    Three bugs within these 512 bytes compromised the security completely - a bunch of hackers found them within days after first looking at the code. Why hasn't been Microsoft Corp. been able to do the same? Why?
    I can make a guess. I've worked near a similar security feature implemented in hardware, and they wouldn't let anyone ANYWHERE near any documentation that described how it actually worked. My impression was that no matter how much you know about security, the less the employees know about the implementation, the better, to minimize the possibility for internal leaks. I'm sure they got the minimum 4 people together to inspect the code, per our coding standards, but how experienced were those four?

    In Microsoft's case, their 512 bytes are incredibly high-profile. And based on the extensive nature of the hacks, they had to find a couple of VERY experienced security people to inspect their code, and who they trusted 100% to not disclose inside information. My bet is they didn't choose the right people to inspect their code, and after the inspection, any other employees who showed an interest in making sure the code was secure were treated more with suspicion than anything.

    • My bet is they didn't choose the right people

      FTFA: After they had learnt their lesson, they designed a pretty good system with the second version of the MCPX - but the implementation still contained at least three security holes

      so, my bet is they just aren't clever enough.

      • Re:A guess (Score:5, Insightful)

        by interiot ( 50685 ) on Monday August 08, 2005 @06:14PM (#13274006) Homepage
        FTFA: After they had learnt their lesson, they designed a pretty good system with the second version of the MCPX - but the implementation still contained at least three security holes

        so, my bet is they just aren't clever enough.

        *shrug* Not necessarily.

        The first shuttle accident was caused by... institutional problems. The engineering issues had already been discovered and discussed, but there were institutional issues that prevented the engineering discoveries to be fully investigated.

        The second shuttle accident was caused by... institutional problems again. Again, the engineering issues had already been discovered and explored as much as the engineers could. Certainly NASA tried to fix their issues the first time, but apparently institutional issues aren't as easy to fix as engineering problems are.

        My bet is that there WERE at least 4 people at Microsoft who were clever enough, they just weren't involved in the code inspections. Even if those four people knew that it was absolutely critical that they be involved in the inspections, they were specifically not permitted to look at the code, because four other people had already inspected the code, and involving more people (especially people who are "eager" to "help") would simply increase the chance of internal leaks. And that's not an engineering problem.

        (on a personal note, at the company I work at, there have been several cases of problems being solved that have well-known solutions, but management puts inexperienced people in charge of the project, and then surround them with many more inexperienced people, ensuring that they never come in contact with someone who can steer them in the right direction. If management doesn't have a process in place to put people with the right knowledge on the problems that really require their expertise (even in an advisory role), then the organization isn't going to perform as well as it otherwise could. (this relates more to the XBox problem... the Shuttle problem is obviously more complex))

        • OT: Shuttle Failures (Score:5, Informative)

          by cant_get_a_good_nick ( 172131 ) on Monday August 08, 2005 @06:51PM (#13274268)
          Richard Feynman was one of the people who investigated the first shuttle disaster, and as a pain in the ass cantankerous old coot, really didn't care about standard Washington procedures and really got to the core of the matter. He cronicles a lot of it in What Do You Care What Other People Think?, ISBN: 0393320928 (get it from wherever, no Amazon kickbacks here). A very interesting read, I ended up reading it right after the second shuttle disaster, and thought that a lot of the human problems that caused the first blow up could be fingered in the second.

          If you haven't read Feynman before, you'll probably like him. Funny guy, pretty damn smart, and managed with luck, brains, skill and stubbornness to get in the middle of some of the biggest science in the last century.
          • It really pisses me off when people complain about referral links.

            As long as you aren't spamming, and I'm interested enough in the book to click the link, why the HELL shouldn't you get a kickback if I purchase the book?

            It doesn't make the book any more expensive for me, and it gives less money to the MAN, so go for it! kthxbye
            • I see your point, and yet, I still don't like referral links or the related Slashdot/Roland debacle.

              Why? Because it makes me question the intentions of the poster. And that makes me question the integrity of his statements. Is he truly being informative--or just trying to make a book description fit the topic at hand (even if only remotely related) in order to make some money?

              I take advertising with a grain of salt. Having watched more than a few infomercials in my lifetime, I've come to regard the

        • Re:A guess (Score:5, Interesting)

          by Monkelectric ( 546685 ) <{slashdot} {at} {monkelectric.com}> on Monday August 08, 2005 @08:58PM (#13275144)
          Yep. Let me describe the situation at a place I work, posting anonymously because there are only 4 or 5 companies in this industry. We make devices used in the semi-conductor manufacturing industry ... so when theres a problem, it ruins very expensive batches of chips.

          Me: "The software that validates that units are configured correctly is 8000 lines of unauditable if statements. There is no definition of the policy it implements. This madness is going to cause an accident. We must rewrite the software and have lots of very boring meetings."
          Management: "Hmmm...interesting...continue patching the software as issues come up."
          Legal Department, "We're being sued because a configuration error ruined a batch of very expensive chemicals."
          Me: "We must rewrite the software."
          Legal: "We must rewrite the software."
          Management: "hmm...interesting...continue patching the software as issues come up."

  • by HotNeedleOfInquiry ( 598897 ) on Monday August 08, 2005 @05:10PM (#13273425)
    A brilliant, brilliant piece of stand-up hacking. Perhaps the best that has *ever* appeared in /. I stand in awe...
    • And I predict a plethera of clinched sphincters at Microsoft. A perversely amusing mental image.
      • El Guapo: Would you say I have a plethora of piñatas?
        -long, confused pause-
        Jefe: Yes, El Guapo. You have a plethora.
        El Guapo: Jefe, what is a plethora?
        Jefe: Why El Guapo?
        El Guapo: Well, I would just like to know if you know what a plethora is because you believe I have a plethora
        Jefe: Sorry El Guapo, I, Jefe, do not have your superior intellect or education. Could it be you are angry about something and are looking to take it out on me?
        El Guapo: Like what Jefe?
        Jefe: Maybe it's because you are turning 4
  • chink in their chain (of trust)
  • Summary (Score:5, Informative)

    by acaspis ( 799831 ) on Monday August 08, 2005 @06:32PM (#13274133)

    • Due to technical constraints, the Xbox designers had to implement a secure virtual machine in 175 bytes of x86 code, and failed (there are at least two execution paths leading out of the sandbox). But congratulations for trying.

    • They also used a non-cryptographically-secure hash function for authentication (or maybe they didn't have enough space left).

    Nice attempt at a TCPA-like architecture, though. And cheers to the xbox-linux guys for their amazing achievements and enlightening write-up.

    • They also used a non-cryptographically-secure hash function for authentication (or maybe they didn't have enough space left).

      Even worse:

      • In ther first implementation they didn't even bother to produce a hash over the complete ROM.
      • They made wrong assumptions about the i386 architecture and apparently never tested that case.
  • All they did was digitize themselves into the XBox and destroy the MCP with a Data Disc.
  • fta:
    Execution just happily continues at 0000_0000 - in RAM! Apparently the i386 CPU family throws no exception in this case, Microsoft's engineers only assumed it or misread the documentation and never tested it.

    The article says that they assumed or misread the documentation . This is so easy to test I find it hard to believe they wouldn't knew about this. I think they knew it and just accepted it. Too bad the article doesn't mention what code there is at address 0000, if there's an halt or illegal inst

  • A history (Score:2, Insightful)

    Despite some of the smart-aleck replies, this wiki article is a very good history of how the xbox was hacked. I remember when Bunnie was keeping us up-to-date on a day to day basis back in the heyday of xboxhacker.net. When he pulled the bios off the board and posted it on his website, he immediately got a phone call from Macroshaft which he recorded and put on his site. Funny stuff.

    But, the whole point of the article is to prove that you can never lock anything completely down, from cd's to xboxen--they
    • The only thing that bothered me about the wiki is the line: "There are two more approaches for attacks that we do not want to disclose yet, as Microsoft may still offer updated Xboxes in the future."

      How well does this represent our culture of openness? Is this consistent with how we want others to disclose security flaws? Obviously the authors have pegged themselves here as not pro-freedom, but simply anti-Microsoft.

      The text is well-written, but the tone of it all is: "Haha, see how much more clever we ar
      • How well does this represent our culture of openness? Is this consistent with how we want others to disclose security flaws? Obviously the authors have pegged themselves here as not pro-freedom, but simply anti-Microsoft.

        I'd say that the XBox is by design anti-freedom. The "security flaws" as you put it are for a security system put in place so that the owner cannot do with their property what they wish. An analogy would be like not pointing out to a dictatorship the various ways their fortress is flawed,

Math is like love -- a simple idea but it can get complicated. -- R. Drabek

Working...