Leer eso:
*******************************
how is this significant? well,
1) the above encryption scheme should work okay if data bits are permuted identically on byte reads and writes (S-box integrity is still preserved)
2) the above scheme should work okay if some of the mid-range address bits are permuted
The only bits that I know for sure are not permuted are the lower 9 bits (because the code from 0xFFFF FE00 looks good till the end of ROM, and because the copyright signatures at around cf0-d30), and enough high bits to differentiate the major memory regions of the machine. It is quite possible that any number of bits between say, bits 10-20 are swapped around. Now begins speculation: decryption happens in 16k blocks. If you look at the data at 0xFFFFA000, it seems to start and end in the middle of a large region of encrypted code (a histogram of the regions of the ROM indicate what areas might be encrypted or not). That seems a bit odd. Also, the fact that the cipher is a CFB-mode cipher--ie, the key depends on the ciphertext stream--means that any mutation of the data going into the cipher is going to cause the rest of the cipher to yield garbage. Thus, if say, address bit 10 were swapped, then the largest sequential block one could recover from decrypting any region of the ROM without knowledge of the swap is 512 bytes--short enough to be infuriating to try and figure out what data is "the real deal" with dumb stastitical methods. It also seems like whoever wrote the decryption code did it in pure assembly. I doubt any compiler could produce code of that quality and density...perhaps someone was trying to get everything to fit into a 512-byte limit?
Things get even more interesting...I tried modifying code in the 0xFFFF FE00 range, and the XBOX seems to ignore it. I even put NOP's over the whole region, and the XBOX still boots-- even when NOP's are in each of the four copies of the ROM's high 512 boot bytes. Something...very...strange...is going on.
Roastbeef has also provided me with these insights on the PIC:
1) The PIC is powered all the time that the system is plugged into the wall. Maybe this is where they're keeping the real time clock.
2) There is an SMBUS connecting the Atmel, PIC and nVidia chipset together. (SMBUS is the Intel equiv. of Philips' I2C bus)
3) DVD ejection is handled in some way by the PIC. (I didn't actually capture data on this, but when I hit the front panel eject button I saw half the activity indicators on the TLA light up)
4) There's some type of SMBUS heartbeat every 2ms.
5) There is no SMBUS or PIC activity in the first second of boot, so none of the decryption stuff can be stored there. (Decryption is probably hit 20k or 30k CPU instructions after power good... that's much much less than the ~1.7sec I'm seeing before SMBUS activity
******************************
A que tiene pinta de que el tio se está currando un MOD chip??
