Xbox Security Daniel Butnaru 28th June 2006 Overview Intro Benefits Security System Attacks Conclusion 2Hardware | Introduction XBOX is a game console introduced by Microsoft in 2002. Consists of: Pentium III Celeron Mobile 733 MHz CPU 64 MB of RAM Geforce 3 MX with TV out 10 GB IDE HD DVD drive, Ethernet, USB 3Software | Introduction Software: simplified Windows 2000 kernel adapted versions of Win32, libc and DirectX statically linked 4Benefits From a hardware point of view the XBOX is a PC: It has LPC, PCI and AGP busses it has IDE drives it has a Northbridge and a Southbridge and it includes all the legacy PC features If it is a PC why not also used it like a (cheap) PC? 5Usage scenarios | Benefits So we could use it for: playing copied games running unofficial applications alternative operating systems ( ) Microsoft designed and implemented a security system to prevent this. 6Security System Idea: Lock out all software that is either not on the intended (original) medium or not by Microsoft. Bad : this makes the security system easier and reduces the number of attack points. Good : 3 times more attackers have a single security system to hack 7Idea | Security System order to allow only licensed and authentic code to run, a TCPA/Palladium-like chain of trust is required this chain reaches from system boot to the actual execution of the game. the first link is from the CPU to the code in ROM (256Kb), which includes the Windows kernel the second link is from the kernel to the game. one link less – the harddisk 8Architecture | System Security 9Startup Security | System Security on startup a x86-compatible CPUs start at the address 0xFFFFFFF0 which usually is flash memory. but flash memory can be replaced/overridden/reprogrammed ROM is much better but expensive so it must boot from flash 10The Hidden ROM | Security System Workaround use a tiny non-replaceable startup ROM put the bulk of the firmware (windows kernel) in the flash memory the “internal” ROM checks if the data on the flash memory is authentic and passes execution to it 11Architecture | System Security 12The Verification Algorithm Verify the kernel through: hash (SHA-1, MD5), but kernel updates become expensive digital signature (RSA), but is should fit on the small ROM (512 bytes) 132bl | Security System Introduce another link in the chain of trust hashes a small loader ("2bl", "second bootloader") in flash memory, which can never be changed It is then the job of this loader to verify the rest of flash, and as the second loader can be any size, there are no restrictions. 14Trust Chain | Security System 15 CPU boots secret ROM secret ROM verifies the 2bl in flash memory 2bl checks the kernel and boots itEncrypt the Flash Memory having the kernel and the 2bl in plain text in flash is not a good idea then encrypt it. But RAM initialization, data decryption and hashing in 512 bytes? 16Virtual Machine Interpreter Microsoft designed an interpreter for a virtual machine that can read and write memory, access the PCI config space, do "AND" and "OR" calculations, jump conditionally etc. The interpreter for the virtual machine is stored in the secret ROM, and its code ("xcodes") is stored in flash memory. 17Interpreter struct { char opcode; int op1; int op2; } *p; int acc; p = 0xFFF00080; while(1) { switch(p->opcode) { case 2: acc = *((int*)p->op1); break; 18 case 3: *((int*)p->op1) = p->op2; break; case 4: outl(p->op1, 0x0CF8); outl(p->op2, 0x0CFC); break; case 5: ... case 0xEE: goto end; } p++; }end:xcodes must not read the secret ROM (upper 512 Mb) sets bit #1 in the PCI config space, device 0:1:0, register offset 0x80 (0x80000880) may also not turn off the secret ROM, or else the CPU, while executing the xcode interpreter, would "fall down" from the secret ROM into the underlying flash ROM19 0x02 PEEK ACC := MEM[OP1] 0x03 POKE MEM[OP1] := OP2 0x04 POKEPCI PCICONF[OP1] := OP2Decryption of the 2pl RC4 is used as algorithm (fits in 150 bytes) 16 bytes key stored in secret ROM The Xcode interpreter is about 175 bytes CPU init about 145 bytes This leaves only about 40 bytes for checking decryption success only checked for one 32 bit constant (0x7854794A) TOTAL 512 bytes 20So far | Security System 21 secret ROM interprets the xcodes decrypt and check in RAM 2bl and kernel jump to the decrypted 2bl in RAMProblem | Security System a hacker could deliberately make the hash fail -panic after panicking the CPU shuts down and a device attached to the bus can dump the secret ROM 22Possible Solutions | Security System shut down the secret ROM but then the CPU can't be stopped the CPU will then fall into flash memory where malicious code lies or shut down the CPU but then the secret ROM can't be stopped 23 CPU Secret ROM device hyperBus sniffMS Solution | Security System jump to the very end of the address space (FFFFFFF1) and turn off the secret ROM in the very last instruction inside the address space. After the last instruction, the program counter (EIP) will overflow to 00000000 this causes an exception as there is no exception handler set up, it causes a double fault, which will effectively halt the machine. 24MS Solution | Security System mov eax, ds:95FE4h cmp eax, 7854794Ah jnz short bad_checkcode mov eax, ds:90000h jmp eax ; jump to decrypted second bootloader in RAM bad_checkcode: mov eax, 80000880h ; prepare MCPX ROM disable mov dx, 0CF8h out dx, eax jmp far ptr 8:0FFFFFFFAh ; jump to end of ROM, wraparound [...] FFFA: ; this is address FFFFFFFA add dl, 4 mov al, 2 out dx, al ; ------this is address 00000000 ------25Memory | Security SystemAttacks People got curios: the hard-disk was checked and found (almost) empty Andrew "bunnie" Huang, PhD student at the MIT, disassembled his Xbox, saw the flash memory, de-soldered it, extracted the contents, put it on his website and got a phone call from one of Microsoft's lawyers. he sniffed the busses, and eventually dumped the complete secret ROM, including the RC4 key from HyperTransport. 27Tools 28Overview the secret key is available but illegal to use a legal solution is needed 29 Get rid of the secret ROM altogether. The vizor trick rolling over of the instruction pointer from 0xFFFFFFFF to 0x00000000 is supposed to generate an exception. but it doesn't it continues running code at 0x00000000 so... 30Exploit POKE 0x00000000, 0x001000B8 ; store "mov eax, 0xFF001000; jmp eax" POKE 0x00000004, 0x90E0FFFF ; at 0x00000000 in memory END ; now we can place our code at 0x1000 in Flash 31The mist trick 32 the check for 0x80000880, the address of the configuration register to turn off the hidden ROM, is incorrect. the Southbridge decodes the 32 bit value into "bus", "device", "function" and "register" not all 32 bits are used. so 0x88000880 or 0xF0000880 behave exactly the same as 0x80000880 -but are not caught by the interpreterMS Reaction 33 With XBOX 1.1 they squeezed a TEA hash into the 512 bytes, replacing the old 32 bit test. changed the RC4 secret key. they left both the MIST backdoor and the Visor backdoor wide open. the TEA hash has been a bad choice.Conclusion 34 512 bytes is a very small amount of code (it fits on a single sheet of paper!), compared to the megabytes of code contained in software like Windows, Internet Explorer or Internet Information Server. Three bugs within these 512 bytes compromised the security completely a bunch of hackers found them within days after first looking at the code.Questions? 35References 36 http://events.ccc.de/congress/2005/fahrplan/attachments/591-paper_xbox.pdf http://www.xbox-hq.com/html/article2708.html&mode=thread&order=1&thold=0 http://www.xbox-linux.org/wiki/The_Hidden_Boot_Code_of_the_Xbox