Patching base kernel for new GPU?

[Andy1988]

Hi there,
I'm thinking a bit longer about how we could break the security system on the newer kernels.
I'm just talking about the 2nd revision of the box. I don't know the exact name. It's NOT the new Jasper.

I just watched (again... ) the Video from the 24C3 and an idea came up into my mind.
We can use a timing attack on the newer boards to calculate a new hash for the stored updates in the TSOP. We *could* then try to boot the base kernel but it will panic because of the different product id of the GPU.

But what about just patching the base kernel to work with the new GPU?
I know it sounds too easy. I'm almost sure that this also is signed with a cryptographical hash.


Another thing I came up with is messing around with .NET.
MS offers the XNA Framework with a .NET Runtime which has to be installed on the harddrive. I must be honest that I haven't yet found the time to look into it.
I somewhere saw a video from a Chaos Communication Congress about breaking out of virtual machines from inside. Perhaps the .NET Runtime has a flaw somewhere and we could exploit it by loading a modified .NET Assembly. Where would we be now? We would be in Userland right? So there is again these fscking hypervisor between us and the hardware...


Third thing would be the NXE dashboard. Did they change the hypervisor for it?
They must have done this because you can load games from the HDD and then the DVD needs to be checked for the security sectors. Is this done by the hypervisor or by the kernel?
Perhaps they did a mistake?


I almost gave it up to think about several attacks. I'm not the only one who did that before and if there is a hole in the wall somebody else already would have gotton to the other side through it.


edit:
Damn... It's late here in Germany. Forget about the first thoughts. If I could create a patch by myself and let it be applied by the loader I wouldn't need to patch the PID, just overwrite it with my own code and done... But it isn't.

[Shaun]

1. Is kindof possible but fails for an unknown reason.  the zephyr + falcon boards (read with timing attackable cb's) can be timing attacked to boot with the patch data removed, however this reults in e78 iirc.  Robinsod checked this and was under the impression they kernel prevents boot at final stage as 'some parameter' is passed to it during bootup which is then checked and results in the error.  whether it is just due to having 'NO' patch data present or at least requiring a minimum level of patch = not sure. this info may have been made common knowledge but i may have missed it.

2. Im not familiar with .net and xna but i do know that whatever code you write will be ran in 'Game mode' not 'Hypervisor' mode therefore you will not have the abilty to do anything funky like altering boot codes check signed contents im afraid.

3. related to 2 a little.  The game install process must run in Hypervisor mode as the created file is made executable from hd via the hypervisor by the install program, this is why its signed by the keyvault making it very difficult to mess with.  Also the SS data is not stored afaik, the game when ran from HD checks the inserted disc and only boots if the SS from the disc matches, I assume the hypervisor has this check built in and call that routine for any media signed to run from hd.

there is certainly more scope for playing with games which boot from hd but unfortunately, the 360 security setup is quite good !

[notherbastard]

do you mean signed to the KV as in by a hash or something, or is there any useful KV data stored in the game data ?