Xbox Security. Daniel Butnaru. 28 th June 2006

Transcription

1 Xbox Security Daniel Butnaru 28 th June 2006

2 Overview Intro Benefits Security System Attacks Conclusion 2

3 Hardware Introduction XBOX is a game console introduced by Microsoft in 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 3

4 Software Introduction Software: simplified Windows 2000 kernel adapted versions of Win32, libc and DirectX statically linked 4

5 Benefits 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? 5

6 Usage 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. 6

7 Security 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 7

8 Idea 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 8

9 Architecture System Security 9

10 Startup 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 10

11 The 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 11

12 Architecture System Security 12

13 The 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) 13

14 2bl 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. 14

15 Trust Chain Security System CPU boots secret ROM secret ROM verifies the 2bl in flash memory 2bl checks the kernel and boots it 15

16 Encrypt 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? 16

17 Virtual 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. 17

18 Interpreter struct { char opcode; int op1; int op2; } *p; int acc; case 3: *((int*)p->op1) = p->op2; break; case 4: outl(p->op1, 0x0CF8); outl(p->op2, 0x0CFC); break; p = 0xFFF00080; case 5:... while(1) { switch(p->opcode) { case 2: acc = *((int*)p->op1); break; case 0xEE: goto end; } p++; } end: 18

19 xcodes 0x02 PEEK ACC := MEM[OP1] 0x03 POKE MEM[OP1] := OP2 0x04 POKEPCI PCICONF[OP1] := OP2 must not read the secret ROM (upper 512 Mb) sets bit #1 in the PCI config space, device 0:1:0, register offset 0x80 (0x ) 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 ROM 19

20 Decryption 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 (0x A) TOTAL 512 bytes 20

21 So far Security System secret ROM interprets the xcodes decrypt and check in RAM 2bl and kernel jump to the decrypted 2bl in RAM 21

22 Problem 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 22

23 Possible 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 device CPU sniff hyperbus Secret ROM 23

24 MS 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 this causes an exception as there is no exception handler set up, it causes a double fault, which will effectively halt the machine. 24

25 MS Solution Security System mov eax, ds:95fe4h cmp eax, Ah jnz short bad_checkcode mov eax, ds:90000h jmp eax ; jump to decrypted second bootloader in RAM bad_checkcode: mov eax, h ; 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

26 Memory Security System

27 Attacks 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. 27

28 Tools 28

29 Overview the secret key is available but illegal to use a legal solution is needed Get rid of the secret ROM altogether. 29

30 The vizor trick rolling over of the instruction pointer from 0xFFFFFFFF to 0x is supposed to generate an exception. but it doesn't it continues running code at 0x so... 30

31 Exploit POKE 0x , 0x001000B8 ; store "mov eax, 0xFF001000; jmp eax" POKE 0x , 0x90E0FFFF ; at 0x in memory END ; now we can place our code at 0x1000 in Flash 31

32 The mist trick the check for 0x , 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 0x or 0xF behave exactly the same as 0x but are not caught by the interpreter 32

33 MS Reaction 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. 33

34 Conclusion 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. 34

35 Questions? 35

36 References