The basic concept of this attack is the idea of modifying a signed XBE without invalidating the signature. You're probably saying "SHA-1 is secure bla bla bla" but hear me out before condemning it.
I was reading up on the XBE file format, and something came to mind. (for reference:
http://xbox-linux.so...t/docs/xbe.html )
First off: the SHA-1 signature cannot be based on the entire file... simply because the encrypted copy of the SHA-1 signature is in the XBE. (If you calculate the SHA-1 signature, then sign it and edit it into the XBE, the file just changed, so the SHA-1 signature of the file just changed so the signature is invalid.) Therefore the only way for the signature to be valid is if not the entire XBE is signed. The most secure thing MS could have done was calculate the SHA-1 signature based on EVERYTHING BUT the signature field. However this would be ugly because you'd have to sign everything before and after the signature, skipping only that 256 bytes.
There used to be a file on xbox-linux specifically about the signing process, unfortunately the link is gone and I can't find it. If someone could find that, it might be shown that this is what's going on. I'm not sure, however it has been figured out (xbedump is working proof of that). Therefore a portion of this is pure speculation that could be easily proven completely wrong by someone who knows, however I'm posting this because maybe I'm off by one and this could still lead to an attack.
I'm going to assume that what MS did, is they calculated the SHA-1 signature on everything but the header. IE, modifying the header does not invalidate the signature. This is the biggest assumption of the file; if this is correct then we're halfway to our exploit.
In the header there is a field for "Entry Point", which points to the offset to jump to at the beginning of execution (IE, where the actual code starts). What if this pointer pointed to a portion of the header, instead of the start of the main code? Here's the second assumption: MS does not check to make sure that the entry point > header size. If they do than we can't attack this way (however maybe something could work with the address pointer to the kernel image thunk address?)
Assuming that (1) we can modify the header without invalidating the signature, and (2) MS does not check the range of the Entry Point pointer, an exploit exists as follows:
alter a portion of the header, overriding fields that can harmlessly be edited without invalidating the file and don't break execution, to include a very brief assembly code similiar to the 007 or mechassault hacks that just modify the public key and load a seperate xbe. Then modify the entry point (XOR'd of course, read the XBE file specs) to point to this assembly code. Now the signature is still valid since we only modified the header, however we're running our own code.
As I said there's a couple assumptions being made, but before I start really hacking with this I want to know if anyone can tell me right off the bat if it's a waste of time or not. Thanks.
