Rumor: PartnerNet Bricking Kits?

Lets don't assume anything. Everyone's case seems to be different. I have read of the few kits on here are right after log-on.

 

My point on saying that people should not put their kits on PNet is that doing so without a proper license gives Microsoft authority to kill the unit. If you feel like investigating, go ahead.

But then stop connecting the kits and stay away from PNet. I only see them getting more strict with time, just like what happened with the retail consoles and hacked DVD drives.

Eventually, unauthorized access will be like a kit death sentence.

Anyway, you can have the CPU blow a fuse and keep running.

The user will only notice that his unit was bombed/disabled on next reboot.

 

Well my shit still works, so I guess just to be as safe as I can I'm a bridge the solder points just incase. It's only a test kit anyway, and it's not stolen or was supposed to be destroyed so hopefully I'm in the clear. I never play games on it, and only go online to dl new stuff then take it off and play it on the jtag console. So it should be fine if not oh well it was fun while it lasted.

Hawk

 

Mine froze as it was running and then went to RRoD after a couple seconds.

 

All they need to do to make it behave as you described is blow the fuse, send the southbridge an command to make the Ring of Light blink with the error code and then make the CPU sit on a idle loop.

The user reaction will be:

Freak out a little bit

Push the power button

Push the power button again

Cry as the 3 red lights blink yet again

Since Microsoft own all the code signing keys they can escalate any code they want to Hypervisor context, then taking full control of the machine at any time they feel fit. I don't need to say anything else.

Microsoft can even program how the machine will fail in any way they want it to.

How about an insane overclock on the CPU core ?
Just tinker with the CPU clock prescaller registers and you have your CPU damage inducing overclock.

Ways to permanently destruct an complex system like an XBOX360 are sure abundant.

 

I dont know the technicalities of this,
could we modify the kernle to not allow changes like so?

and what if we have a flash backup of the nand,
can we restore it?
if not, why?

everyone who's banned/not banned post information, so we can find out what you have in-common,
(Example)

banned: no
XDK Ver.: 9328.9
How long on XePN: 2 years
MFC: 2008
Mobo: Xenon
Retail titles: yes
If so was it halo?:
Friend list #: 16
ran a homebrewed application: yes
Kit origin (ie. main seller/other) ther


just a suggestion, if we all could see what we had in common then we might be able to help other prevent it.

 

Hmm... does it really work like that? I'm not sure if it works like that because then we could always do that since we can edit the kernel whenever we want on devs.

 

For devkits, you could edit the kernel and prevent it from happening if you really wanted, just nobody has.

 

Nope. The kernel is rsa signed with the rest of the boot loaders and hypervisor, using a private key obviously...

 

You can edit it in memory whenever you want.

 

They blow the fuse and revoke the bootloader then how you will start it again next time ? Like TheFallen93 mentioned, the bootloaders and hypervisor are signed, hashed and secure. You can tinker as much you want with the kernel, but the kernel runs on a virtual machine under the mercy of the hypervisor.

Supply it the right access key and you unlock complete access to the system.

As of now, only MS can do that. With full access you can read the CPU fuses, for example and write a copy on a file. For such level of access on a XDK only way is revert to an vulnerable kernel and apply the old KK hack from a devkit signed/modified demo package of the said game...

Well, if the disabled units are returning error code 0022 (hung during CB execution) the CPU still starts so if someone daring enough want to try, a good test would be make an zero-paired image on the XDK and see what happens. People say that XDK don't use the lockdown values (LDV) but honestly has anyone analyzed the devkit CB seriously ? I don't think I heard of anyone doing it.

Everyone with XDKs took their kits as granted, indestructible and MS just proven that it can nuke them if it deem necessary.

They used the hypervisor and 2048 bits RSA signing to keep control of what the machines do.

In the end, if MS need to revive an nuked XDK all they need to do is put a newer CB in it which is compatible with the new fuses layout. Since they own the keys, they can change anything they want, sign and deploy.

It's that simple.

 

Is it a bad time to say I kept to myself? I was lucky that I found out before anything happened to either of my kits. My friend told me and I unplugged the ethernet instantly. I heard that when you reboot it is when you get the rings, but obviously that hasn't been the case 100% of the time.

Oh and Sonic3d, don't take this the wrong way, but, how about trying to use the space bar after periods sometimes, eh?!

 

Doesn't really make sense. At which stage of execution or stage of running is this key supplied to grant full access? You're failing to show a way in which what you claim actually occurs. How is this key given to the hypervisor, how does the hv then handle this?

No, it's really not.

 

Take a look at JTAG-hacked machines, people have the system cracked WIDE-open without having any private key what-so-ever. Not only do you have the XEX private key for devkits, but the system is a bit more open for you than with Retail machines.

 

I'd say it is, and I agree with his theory.

It was cracked wide open because of a zero-paired image booting a vulnerable CB. Why do you think we can't exploit every 360 on the market? Once they incremented fuses, the exploitable bootloader was blacklisted. I don't think you are thinking about this correctly, but feel free to prove me wrong by doing it yourself.

 

I am not sure if you understood what I just said. I'll try to explain better:

JTAG hacked machines are PATCHED for having ALL checks/locks/security removed. And shouldn't be compared to XDKs which are still restricted/protected. The only thing different about XDKs to unhacked retail units is that we can sign XEXs and containers for them because we know the private key. Still we don't know the hypervisor private key for either DEV or Retail hardware.

Microsoft want to maintain control of what people does with the DEV consoles as much as they need to control what normal users do with their retail systems. They allow people coding with DEVs full memory access for the purpose of debugging and analysis of applications being developed. For that purpose there's no need to allow low level access to the hardware or devices within the system. Should you blink the RoL or make the unit "beep" (joke) you should do it through the API MS gave for the devs. If you don't do things right your game or app won't pass the checks and get certified. Of course people without licenses, agreements, NDAs are not bound to that terms but the hypervisor still restricts the system access for everyone.

On JTAGs the hypervisor security has been defeated/nulled but the normal system operation still depends on it's existence so it's kept running. JTAGs will run XEX files with broken signatures while XDKs won't as their hypervisor is working and blocking odd stuff. :shrug:

After typing so much, if people still fail to understand, I'll just grab the bag of popcorn and sit here just reading the posts as they pop ... :lol:

 

You forgot to explain how your "private key to grant hypervisor-level access" idea works.

 

I'd say it's pretty simple to understand, M$ can deliver a payload that is signed with their PRIVATE key (not dev XEX key), that escalates its permissions and allows it access to anything it wants, which would obviously allow it to brick the kit remotely.

 

Any dissasm or functions to support this ?

 

I think a good start would be take an bricked kit HDD and look the cache folder for weird packages downloaded automatically from PNET. And then if it's something too sensible it's possible that the system is told to *not* download it to the hard disk before execution. Anyway we could get it, see how it work, and still it would be impossible to prevent it's execution... :thumbsup:

I believe an different version of signin.xex is downloaded from XBOX Live when the user logs in. That's somewhere to start.

I have no devkits so I don't know how it works for them.