Talk:The Hidden Boot Code of the Xbox

From Xbox-Linux

(Comment: I work at another major console manufacturer, so maybe I can give some insight on that last question. Time. The console manufacturers are constantly competing with each other to deliver new hardware under very tight deadlines, and there is little or no time to do any proper security implementations or even reviews. Couple that with the added technical challenges imposed by pressure to reduce hardware cost, e.g. less RAM or ROM, and it is pretty much unavoidable that there are tons of security holes.).

The startup code is written in two ways in the opening paragraph, but the two addresses are not the same.

Bob: My take is this- badgers secretly infiltrated the system using harpoon guns and took control of the MCP (master control processor). All data was redirected to null.

This is gospel. Amen.

The article is a great resource for understanding X-Box security. Perhaps it can be a bit less cruel?

[edit]

x86 and exception generation

by DrYak : about the visor trick Yes, indeed, the x86 architecture only generates an exception when its reading *past* the boundary of a segment (like in "reading byte @ addresse 2000h, when segment is 2000h bytes long, i.e.: only [0-1FFFh] is valid).

  • So the last byte of the instructions is read at ffffffffh. (inside segment boudaries, no exception).
  • Then EIP is incremented, and rolls over to 0 (no carry or whatever...)
  • first byte of next instruction is read from 0 (which is _still_ a valid address inside segment boudaries, so still no exceptions)
  • RAM at addresse 0 is garbage and CPU hangs.

source:

  • Lot of experimenting on 80368 and 486 CPUs. (try reading a 32bits value at A000:FFFFh in real mode. *that* will generate an exception. Everything else wraps nicely around segment, and is very handy to access the VGA/MCGA/TweakMode video buffer whitch has exactly the same size as the segment boundary in real mode - i.e. 64k).
  • Book "Programming the 80386" by John H. Crawwford and Patrick P. Gelsinger (but I forgot which page, all this was a long time ago).
[edit]

code samples a real ?

My asm experience is a bit of D.E.C. PDP-11 (used in USSR schools), a bit of i80286, andbook read on Compaq C386/16 :-) So it was faaaar ago. When i got my AMD K6 - i lost interest to ASM, before it i had no 32bit PC, only my old AMD 286 :-) It was faar ago indeed and i remember very leetle, but...

But when i readed that code i was shocked... Is it real code or it was intentionally simplified ?

  • looks like real code to me, nothing to be shocked about --83.169.155.163 05:59, 13 Aug 2005 (PDT)

Of course there is no exception of wrapping code over -1/0 offsets ! But they could mark virtual memory page at 0 as missed to trigger exception - like it is done in almost all OSes today :-)

  • they can't. i'm assuming the CPU runs either in real mode or in SM at that moment, they apparently totally forgot that. since there's no protection at all in real mode, they can't mask page zero. even further, 0000:0000 is a valid execution address like any other. the real-mode IDT probably is initialized to zero, which would make any exception/interrupt jump to 0000:0000 anyway. --83.169.155.163 05:59, 13 Aug 2005 (PDT)

Or they could just press Reset instead - then computer would loop infinitly in quick resets.

  • flashing NES power light anyone? --Shawnz 19:29, 2 Jul 2007 (PDT)

Or just close HiddenROM and expect that CPU cache will disallow CPU to notice that - and then just, say, divide by zero (was it that very way, Windows 3.x went DOS mode on i286? )!

  • the return-to-real-mode trick on 286 was done with bios support. it was a cpu hardware reset, but there was a special value written at some location (0040:?) which caused the BIOS to shortcut back into the OS --83.169.155.163 05:59, 13 Aug 2005 (PDT)

And the most easy - copy the code to RAM, make this code delete itself, then close Hidden ROM, then cli/hlt. No, they just should settle stack above code and end in an "call $" - that will freeze PC and delete decrypted BIOS together with close-ROM seq!

  • I assume that the code you refer to is the code in the hidden ROM. This is the same code that configures the RAM, so isn't the copy uneccessary? Your suggestion simplifies to: initialise RAM, store some instructions there that close ROM and halt, jump to them. Oddly, they did all that except for the last bit: store the hlt at location 0 in RAM...

Putting such a code into south bridge is funny decision indeed. But aren't Pentium3+ able to get microcode update ? Perhaps Microsoft would better pay Intel to implement special microcode with 2-3 special instructions in it ?

  • this would have increased the xbox price, because they would either have to update each CPU or use a special version. neither is practicable. --83.169.155.163 05:59, 13 Aug 2005 (PDT)

I wonder how much RAM is required for decryption with open key, so there would be no secret key at all ?

BTW, if someone is neat on EGA/VGA internals - does those video cards have some predefined font - or is this font always loaded from BIOS ? Could they put a program in Video RAM loaded from some hardware BIOS?

  • the font is always loaded from a BIOS, on all gfx cards. on IBM compatibles, the video bios usually does it. --83.169.155.163 05:59, 13 Aug 2005 (PDT)

Jeez! couldn't them just hire author of ASProtect or some other protection tool ? I wonder if they became indeed smarter in X-Box 360.

  • i doubt ASProtect fits in 512 bytes

No, at last, about code snippets. They were short of RAM. And they knew it. And they used asm ans, i guess, knew it better than i do (didn't them have MASM and VC++ teams? or they just took some random Visual Basic programmers, given them MASM manuals and requested to learn it in 2 hours ??? ) So why ? 

 "and ecx, not 2" - i don't remember how the constant is stored here, is it 32 bit or auto-expanding 8 bit ? If 32 bit - they'd better do "and cl,..." ;)

80E102    and ecx, byte +0x2



 "mov eax, ecx  /  mov eax, ebx" - Why "mov"? Isn't there well-known common trick to use "xchg" and save 1 byte per command?

Or is 32bit mode so different from 16bit, that those tricks are not the case anymore ?

  • that should actually work

Arioch.

--83.169.155.163 05:59, 13 Aug 2005 (PDT) = equinox


> i doubt ASProtect fits in 512 bytes

...but he might tell with is the minimum minimorum for RAM requirements.

> he return-to-real-mode trick on 286 was done with bios support

True, but we do not need to return to somewhere. We just need a reset.This way, or using keyboard controller (0x64 port AFAIR) - if it is available on X-BOX. Infinite Reset loop seems to me in no way worse, and hacker would be confused a bit, watching how a CPU is workiong on something ;-)

> they would either have to update each CPU

...like any modern Pentium do. Motherboard BIOS updates contains fixes, and Linux or Windows update device drivers scan BIOS for the update tables, chooses appropiate for certain CPU build, and update it's microcode. That is security through obscurity,

Since no one ever disassembled intel internal microcode ;-) Made about ten specific commands, put this table into regular BIOS, and let decrypting of the rest of the BIOS and panic halt rely tightly on those commands, missing in usual destop's instruction matrix. That would make them pay Intel once for a number of XBOX-specific opcodes, but not for every CPU piece.

[edit]

Just a Typo

Probably It should be "17 [not 16] Mistakes Microsoft Made in the Xbox Security System".

Cheers! :-)

Retrieved from "http://www.xbox-linux.org/wiki/Talk:The_Hidden_Boot_Code_of_the_Xbox"