Joder, es sorprendente lo rapido que avanza el tema del hackeo de la BIOS. Visor quien descubrió el backdoor ya ha creado un documento donde pone en comun algunos puntos... os pego lo que ha escrito en el foro de xboxhacker (es algo extenso pero merece la pena leerlo) :
here the post that i've been promising you guys. i've decided to omit quite a bit of specific details so as to make your adventure more exciting & also to separate the boyz from the boys.... let me know if i missed out anything or any typo etc. enjoy....
------------------------------------------------------------
the aXventure - released on may 28, 2002
> introduction
this is an account of my xbox hacking adventure over the last 2 weeks. it contains detail of each step of the process in finding a way to boot self-written low level firmware code to run on the xbox. this document is highly technical in nature and assumes that the reader is technically well versed in the x86 platform. finally this document will be completely useless to you unless you have the following: -
. xbox that have been opened up for exploration
. replace the flash in the xbox either by desoldering and reprogramming, or connecting a new flash in parallel
. logic analyzer or similar data capture equipment
huge amount of information exists at the forum pages of xboxhacker.net & various other websites that serves as good starting point. i will not reproduce most of that information here. please note that i do not guarantee the information presented here to be 100% accurate as most of the information are derived from observation & speculation, therefore you are advised that you are using these information at your own risk.
> overview of xbox booting
xbox boots up from some hidden bootstrap code in the mcpx (512 bytes). this bootstrap is the main stumbling block that prevents self-written code from running. extracting the code from the flash revealed some bogus bootstrap code that however gave plenty of hints on how the bootstrap works. the bootstrap seems to work as follow :-
. hardware initialization using 'x-code'
. load & decrypt bootstrap2
. execute decrypted bootstrap2
> the 'x-code'
the first part of this document will explore the 'x-code' - a simple interpreted low-level language or instruction sets. the 'x-code' has proven to be extremely powerful & useful in the subsequent stages of the hacking adventure. i am not going into the details of how 'x-code' works, the bogus bootstrap provides a very close match of what is actually going on. there have many attempts to decipher the 'x-code'. some important information shows that the proper 'x-code' starts at offset 0x92 of the flash, and among other things, it seems to be programming the PCI devices.
an analysis of the dump of the 'x-code' from offset 0x92 onwards revealed some interesting bits. for opcode 0x04 & 0x05, the first operand is always 0x8XXXXXX. this seems a nice fit for the PCI configuration operations. bit 31 must always be enable for PCI configuration. it is possible then that the bogus bootstrap simply shuffled the opcode around. working with this information, the original 'x-code' interpreter can be reconstructed as follow :-
. opcode 0x04 & 0x05 is for PCI configuration read & write. the second operand, which is always zero will indicate a read operation. therefore, opcode 0x11 in the bogus code is actually the proper opcode 0x04, and opcode 0x04 is actually opcode 0x05.
. the first 'x-code' instruction configure a PCI device to i/o port base address 0x8000 & the third 'x-code' instruction seems to be doing an 'out(0x80XX,0xXX)'. with this information, it is deduced that opcode 0x11 is the i/o port output operation.
working along this line of analysis, the final list of opcode remapping from the bogus bootstrap to the actual bootstrap is as follow: [BOGUS->ACTUAL] 0x03->0x07, 0x01->0x02, 0x09->0x03, 0x12->0x06, 0x11->0x04, 0x04->0x05, 0x10->0x08, 0x02->0x09, 0x06->0x10, 0x05->0x11, 0x07->0x12, 0xEE->0xEE.
> verifying the 'x-code'
in order to verify that correctness of the reconstructed opcode list above, we need to find a method of testing the 'x-code' and get back the result. new 'x-code' can be constructed by modifying the flash contents but how do we get back the results? since the flash basically sits on a ISA-like bus (or X-bus - check out Intel documentation), if we can find the RD & WR signal then 'x-code' can be used to write back data onto the X-bus. a few snoops of some of the test point on the back of the motherboard near the flash reveals some interesting information. the OE_ & WE_ signals from the flash is not connected to the mcpx but interestingly provisions are being made from them to be connected via 2 jumper points (2 sets of resistor pads). connects up the jumpers & hooking up with RD & WR signal together with address & data buses of the flash to a logic analyzer will enable us to look at all the read & write transactions on the X-bus. if you have no means to capture & look at these signals, this document will probably be of no use to you.
if you have everything wired up correctly, modifying the 'x-code' to perform a write to the flash mapped region, i.e. <0x03> <0xFFFFFF00>,<0xAAAAAAAA>, will show up some nice write cycles on your logic analyzer. we now have a way to pass data for execution by the 'x-code' interpreter & also a primitive way to read back the results. next, we will look at how we can make use of these powerful 'x-code' instructions to explore the xbox!
> finding bootstrap2
with the logic analyzer you should be able to observe quite of read transactions to the flash - the 32-byte line-fill read cycles for each instruction being executed & also the read cycles of the 'x-code' being fetched. this will go on for a while until the last opcode 0xEE & then suddenly the 32-byte line-fill read cycles disappear. from the bogus code, we can see that some caching mechanism is being manipulated. what follows seems to the loading & decryption of the bootstrap2. the address in the bogus code is incorrect. the logic analyzer reading seems to indicate the region to be from 0xFFFF9E00 to 0xFFFFFE00. we have now found the location of the encrypted bootstrap2. from the bogus code, it seems that the decrypted code should be somewhere in the main memory. now, if only we can access the main memory after the decryption is done, then we will have bootstrap2 in the open! but since we have no way of running our own code after the decryption routine, that would seems impossible. well, not quite!
we know that we have found a way to read out from the memory using 'x-code'. the problem is that 'x-code' gets executed before the decryption process. the flow is as follow :-
RESET -> X-CODE -> DECRYPTION -> ...
hmm... if only we can get 'x-code' to run again. here's the trick - if 'x-code' takes place after 'reset', we can always 'reset' the system after bootstrap2 decryption, then 'x-code' will run again :-
RESET -> X-CODE -> DECRYPTION -> RESET -> X-CODE -> ...
if the second reset is a warm reset, the residual code from the decryption of bootstrap2 should still be in main memory, we can now read out the decrypted code! how exciting!
however, first we have to prove that the residual code will not be corrupted by the warm reset. we will need to make out some new 'x-code' to test it out. let's extend the 'x-code' so as not to disturb the other hardware initialization steps. place the new 'x-code' at the location where opcode 0xEE is. some simple test can be done in this way :-
<0x02> <0x00001000> <0x00000000> read from memory
<0x07> <0x00000003> <0xFFFFFF00> write to flash (view on LA)
<0x03> <0x00001000> <0xAAAAAAAA> write test pattern
<0x09> <0x00000000> <0xFFFFFFF7> infinite loop
running the new 'x-code' produces even more interesting observation. it seems that the xbox auto-reset itself repeatedly if the proper flash is not running. this turn out to be interesting, as it automatically generates the second warm reset for us. anyway, even it is does not auto-reset, simply pressing the on/off button will do fine. the main memory seems to survice even that quite nicely. looking at the result on the logic analyzer, we found that the data in the main memory (SDRAM) seems to have survived the warm reset.
now, let's put back the opcode 0xEE in place of the opcode 0x09 above, so that the original decryption routines can continue. one very important information that we need to know is that opcode 0xEE also manipulates the cache setting. operand 0x0806 will set the CPU into write-back mode which means the bootstrap2 is actually decrypted into the internal CPU cache, and we will not be able to find it in the main memory. however, the designer of xbox has somehow allows us to manipulate the cache setting with opcode 0xEE. with that we can change that to 0x0804 which is to set it to write-through mode.
what follows is the tedious process of hunting for the exact location where bootstrap2 is located. it took me quite a while to find it but i will leave that to you to try. the method is actually similar to the 'x-code' snippets above. just write some test pattern at various locations & read them back at the second reset. if the test pattern got changed, you have found the location. after you have found the decrypted bootstrap2, you can read out the whole 0x6000 bytes if you decide to. as for me, i just want to find the entrypoint, just enough of that data will do.
> patching the entrypoint
ok, by now, we have part of bootstrap2 & enough information of where the entrypoint is. it will be sufficient to just patch a few bytes of that entrypoint so that the code will jump to our own plain code that can be placed anywhere in the flash. however, patching bootstrap2 will mean that we need to know how the crypto works. well, yes & no. we do need some basic idea of how the crypto works, but not the whole algorithm and the crypto key. i am no expert on crypto, so i will avoid making too much comment here. from the bogus code, it seems that an 'xor' operation took place in the decryption process. assuming that C[i] xor K[i] = D[i], since we can set C[i], i.e. the encrypted bootstrap2 in the flash, & observed the result D[i], from the location of main memory that we found above, by setting C[i] to 0, 0 xor K[i] = D[i] means K[i] = D[i]. if the location to be patched is 'i', we have to patch the encrypted bootstrap2 at offset 'i' to zero, and use the 'x-code' sequence above to read out K[i]. having found that we are ready to generate C[i] from K[i] that we found and D[i] is the x86 opcode that we want to patch into bootstrap2. That's it, we have finally succeeded in running our own code!!!
> what's next
well, being able to run self-written code is just the beginning. there are still tremendous amounts of information that we have yet to figure out. for example, your code will not execute beyond a certain time because the reset watchdog will time out in about 200ms and the system will automatically reset. however, within the short 200ms, which is extremely long in the CPU world, you would have succeeded in grabbing a lot of valuable information. i would appreciate it if you could share those information, if you have benefited from the information that i have provided here.
for those of you wishing for more detailed information of the exact location of bootstrap2, the actual x-code snippets, mcpx hidden code, etc, i do not wish to provide those here. i believe if you are really serious & capable of hacking the xbox, these information will be more than sufficient.
what's next... continue to follow the scene for more exciting news... i hope i have unlocked the door for serious x-hackers to move forward.
- visor - reachable @ xboxhacker.net
![[jaja]](/images/smilies/nuevos2/otrasonrisa.gif "otra sonrisa")
