QUOTE(hobosrock696 @ Jun 22 2011, 03:36 PM)
Well I said I would not post again however.... 2BL is not the kernel its just the vm the kernel and hypervisor combine in 5BL I believe and the check for the kernel version is in 2BL so could you not just fake it in 2BL before the vm is loaded and everything is in encrypted memory?
EDIT: I am assuming it is possible to load a valid 2BL and later pair it with a valid kernel of a different version. If you cannot do that then this definitely does not work...
EDIT2: Nono I see 2BL checks the 2BL version and 4BL ensures you do not load an older kernel.
Last question then, would it be possible to pass 4BL what seems like the correct kernel to verify and then switch it out for an older kernel when its being loaded? That is what I was getting at if it was not clear. Or does it load the kernel into memory and then verify making it impossible to modify?
The eFuses are checked as early as 2BL , line 2 in the fuseset is the 2BL fuseline , this is why we can't downgrade 2BL to run an exploit again , they burned a 2BL fuse when they updated it making that impossible.
Unless a new exploit is found in the hypervisor , or in one of the bootloaders CD for example , there will be no new exploits for the Xbox 360. If an exploit were found in 4BL allowing what you said then yes that would possibly be able to be exploited , but not on it's own , and probably not without the CPU key which would also require an exploit.
eFuses are a difficult concept to fully understand , but you should do some more reading , years of research can be found on Xboxhacker. Burning the 2nd fuseline is really what killed the hack , well aside from what they actually put in the code to prevent the old kernel from running , if the CB had not changed the exploit would still be running , the new one blacklists the 4532/4548 kernel patches so without downgrading CB there is no way to exploit the old bug , without an exploit there is also no way to get a CPU key so that also hurts although even with that you still can't do anything, because CB is RSA signed not CPU key signed, you modify CB you break the signature.
As it was said , it is pretty much an impenetrable fortress of security at this point, unless some fatal bug is found in the newer hypervisor , or even in a bootloader , there will be no new exploit. Don't think it always has to be in the hypervisor, it just has to be able to exploit the old bug unless a new one is found , running of the old kernels would allow for a new way to exploit. The hackers who developed the Jtag hack thought way outside the box , but they did so much research they knew what wouldn't work , in the end think of what they came up with , an exploit in the GPU , just some access to the PCIe bus was needed to write into memory the same memory writes that the shader accomplished.
Possible Efuse Faker?
Jun 20 2011, 09:06 PM
