It's their property. They feel threatened by something, constructed a plan of attack based on probably a bunch of meetings and man hours working out the pros and cons of different procedures, and executed it.
Banned: No XDK Ver.: 9328 How long on XePN: 2 Months MFC: 2007 Mobo: Zephyr Retail titles: Yes If so was it halo?: Yes aswell Friend list #: 6 Ran a homebrewed application: Hell yes Kit origin (ie. main seller/other) : Not exactly sure.... So I think it depends on where your kit came from, like a blacklist of some sort that was mentioned, possible idk. My kit is fine, a friends kit is fine, also a fellow modder I talk to has a kit that is doing perfectly fine that when he got it was brand new in box.
Could Microsoft be bricking these based off geoip location? No doubt they have access to databases with that information.
There is no such thing as a special private key that grants your xex hv priviledges, the whole concept of the hypervisor is not to let ANYTHING not even a signed xex, gain hypervisor priviledged excecution, there is only one key for xexs on debug consoles, this is the one readily available in the xdk (in imagexex to be specific), this is also the very same microsoft make use of. The hypervisor ram space itself is even hashed so there is no modifying it without code running from the hypervisor itself. If you want to blow fuses on devkit, you can overwrite the kernel/hv on nand (with a version that would actually blow your fuses upon reboot) and then forcefully reboot or crash it (well actually you can't cause we do not have the keys to resign the kernel/hv but microsoft does), this can be done using signin.xex or any other piece of code microsoft may remotely run onto your kit. On retail you can use the specific calls to blow efuses which are HvxBlowFuses and KeBlowFuses. I thought HvxBlowFuses would still work on debug consoles but someone confirmed me otherwise. Finally I would like to add that non licensees are better off partnernet, there are things people should not be messing with, and leaking content out of it is one of the most irresponsible thing I have seen so far.
Banned: No XDK Ver.: 9328.9 How long on XePN: 7-8 MFC: 2006-5 Mobo: Xenon Retail titles: Yes Friend list #: 10-15 Ran a homebrewed application: 1 time Kit origin (ie. main seller/other) : Journalist You have the Nand : Yes
The hypothesis of special XEX/privilege escalation comes from the fact that hackers at XBOX Hacker forums analyzing the hypervisor have found mechanisms that allow MS to execute code on hypervisor context. While what mathieulh say is true for any hypervisor based design, Microsoft would want to have methods to bomb/nuke or test systems they suspect being compromissed. Such mechanism could use the 1BL private key as signing key and the public 1BL key as authority verification key. So only an real audit/analysis of a current version of the hypervisor code would end this discussion.
I looked at an old dev hypervisor (4548), there's only one public key to verify the signature of a xex while loading it, and it doesn't check for any other keys like what you are suggesting. Like mat said, this idea defeats the whole point of the hypervisor function. If someone feels like I should be looking at a newer hypervisor, feel free to provide me one .
Cable company's use to do the same thing, people would get tricked out card that gave you every channel, cable company would send a wave and break the box. They can do whatever they want with there property.
He's not talking about xex keys, hes talking about a key to allow an xex to execute at hypervisor level. Basically pass the key to a syscall then the xex is allowed to run at hypervisor level. There is no way to boot a modified kernel or hypervisor. And for those who dont know they are in the same cab file.
What happens when we get a hold of this key? The whole hypervisor concept falls apart is what happens. It just doesn't seem like something MS would do. That whole idea just cannot make any sense to me considering MS's security standards, nor have I ever heard any mention of this, which would be a pretty big deal.
If you could just "pass the key to a syscall" as you say, then you would just need to dump the code they send to the xbox to actually get that key (which means putting a private key in there to pass it to the said syscall would be a silly move). They could sign/encrypt a payload with another private key but that's assuming such a syscall does exist, beside the xexs themselves are signed so why the hell would they bother adding such a syscall in the first place ? The signature checks on debugs and retails are the same, only the keys are different. And yes with a regular signed xex, you can reflash any area of the nand, including the kernel/hv and there is no need to tell you that Microsoft can sign and encrypt any kernel/hv they like considering they have the key to do it. This process is actually used in XDK updates (not the signing of course, I am talking of flashing the signed hv/kernel to the nand here). Now I am far from being a 360 expert but I think those arguments are far off, if you find any evidence of such an existing syscall or any other way of getting hv priviledged code execution from a regular xex in the hypervisor feel free to enlight us as I'd be pleased to know about it, but until then this is all speculation (and unlikely one that is)
I fear the Dev market is going to be bad soon, as of now people are going to sell the bricked kits to noobs and thats going to suck.
Wow the sony scene usually scoffles as us when we act like this. and ichy's is fine, i really think they just traced all the missing kits form the main dealer.