QUOTE(moh.sakhaii @ Apr 11 2011, 02:20 PM)

Thanks for the info

but I do not understand the shi**y security Microsoft has used here

they have given their precious system programs to others without any protection whatsoever

Well the Xex itself is not a normal Xex , you can't do much with it in XeXtool , as it doesn't have a valid PE basefile (so it says) , it also reads as a system file AKA dll. The Firmware file itslef , i would speculate gets encrypted at some point during the update when it adds your DVD key to it etc ... SO I don't think it is necessary for them to try to make it impossible for use to disassemble it , their job is to assume we can and make it work regardless , kinda like the HV.
Felix made this point in his C3 talk on the HV bug , without looking at the video the basic quote was about how even if your secrets are known your security should still work. Obviously having the private key would make that statement moot , but that key isn't anywhere on the system to retrieve it , only a hash to compare and check for validity of the xex signatures etc ... And after updating the 2BL even if you know your CPU key , and have a disassembled HV/Kernel you still can't hack it, so even though the 1bl key is known and we will go ahead and pretend you also have the CPU key , you still can't break the security because of the HV , and the updates made in the 2bl.
Sorry I didn't mean to take it that far off topic ... the point is still valid even when not discussing unsigned code , MS is going to assume their work can be disassembled , instead of assuming their encryption will stop anyone from seeing their code , they in turn make the code harder to exploit instead of making it harder to disassemble. Make Sense? Not saying they don't do both , Just saying they will have to assume at some point someone from the -scene- will reverse it , they need to make sure even when that happens they are still safe.