Un-ban your xbox360 with keyvault

[bhaskar]

MY Xbox 360 NTSC/J Asia
MY Xbox 360 has ban banned Live already
i need buy Infectus chip ?
how to fix Replace Keyvault Unbans my xbox 360 unbanned back Xbox live
help me

[robinsod]

You need the KV from another XBox (non banned) and your CPU keys. Then insert the new KV into your flash image and re-encrypt using CPU keys. My NAND tool can do all this for you BUT You need the KV from another XBox (non banned) and your CPU keys.

[bhaskar]

i dont have KV from another XBox (non banned)
what KV ?
i have one XBOX 360 banned already 
i dont have another Xbox 360
u have File CPU keys (non banned) can give me send email attach can or cannot ?

[Arakon]

uhm.. they CPU key is unique to your xbox360. noone can send you that. without another, unbanned 360, the CPU keys and keyvault of both of them, there is no way to unban your 360. simply put: buy another 360 for Live.

[Geremia]

The thread title is promising a console unban with "the magic of keyvault", but people has not understood what is the KV.

KV, in a easy talking, is like the identity card of the console, where a set of unique info is stored. It's the most secured archive of the console, you need your CPU key (stored inside the CPU) to decrypt it, so you need linux and KK exploit to obtain CPU key (you need also a working and ixtremed dvd drive), but you need a 4532 kernel to run kk exploit, so you need to downgrade first to 1888 then upgrade to 4532.

This is far from being easy and quick.
If you get banned, you should better go and buy a new console.

The topic is misunderstood 99% of the time. If you take a look at "copy>babelfish>paste" forums out here, you can get a lot of fun, you can even see people that goes to the nearest store to take note of the console serial numbers on the shelves 

KV is not writed in a sticker on the back of the console, is not 1 key that can be found even at the butcher shop like at old seca1 and irdeto1 times.

[torne]

I agree with you, that any check can be cracked, and cheating will be possible.

But my point is just that MS have made a design mistake when designing the DRM. They implemented one DRM to protect them against Linux, homebrew, piracy, and Live cheating. They should have made a DRM for each enemy.

They have. All those things are controlled by different software mechanisms. But, for any security implemented in software to be worthwhile you need a secure boot path to load that software, otherwise it can be tampered with, and the hypervisor bug allows us to subvert the secure boot path and load anything we want. The only way to prevent this is to implement more mechanisms in hardware (or unmodifiable firmware, like 1BL) which is expensive and difficult, and enlarges the size of the trusted base. The more trusted mechanisms exist, the more likely that one of them will contain a flaw that is exploitable.

Why? Because they knew that hackers would hack it to be able to boot Linux from dashboard.

I wish I could take credit for this, but it was one of the 17 mistakes MS did, presented at 23C3 by Michael. The presentation can be see at http://www.free60.org/wiki/Videos. It is the first video.

I happen to think that's nonsense - it's mind-bogglingly difficult and definitely impractical to separate security mechanisms to that kind of degree. How do you design a mechanism that allows unrestricted homebrew software without allowing someone to use the same mechanism to load a copy of a retail game?

[Surrido]

I also agree 100% with tmbinc and the others making the statement that we should not mess with xbox live.

the good thing is, only a handfull of people will actually try doing that. it is for fact a lot of work to do all the soldering flashing, downgrading and what have you, just to unban your xbox.

as i have stated in a posting before. some degree of piracy actually helps distributing a system (network effect)  and this is why MS probably never really attempted to make it harder to run backups. BUT messing with xbox live is something totally different. it is part of their major future strategy towards bulding their home entertainment network which will most likely in the future be much more than just chatting and playing network games. xbox live is what differentiates them from many competitors and it turns out to be very successful for them.

they are swinging the ban hammer from time to time and they have all the right to do so. what we dont want is that they start swinging the court hammer or that they try to kick us out of the hacking game by locking our little security hole totally!

besides that, its not worth going to jail just because a 15 year old might like the idea that he can unban his console that he should never have messed with.

[hm2075]

absolutely agree with the above post. I think talk about unbanning consoles should be banned. The great work on this forum should not be used for piracy but for development of homebrew.

Those who want to play live should go out and buy a second box. Make a decision -- homebrew or live.

[The M.A.R.T.]

I also agree 100% with tmbinc and the others making the statement that we should not mess with xbox live.

the good thing is, only a handfull of people will actually try doing that. it is for fact a lot of work to do all the soldering flashing, downgrading and what have you, just to unban your xbox.

as i have stated in a posting before. some degree of piracy actually helps distributing a system (network effect)  and this is why MS probably never really attempted to make it harder to run backups. BUT messing with xbox live is something totally different. it is part of their major future strategy towards bulding their home entertainment network which will most likely in the future be much more than just chatting and playing network games. xbox live is what differentiates them from many competitors and it turns out to be very successful for them.

they are swinging the ban hammer from time to time and they have all the right to do so. what we dont want is that they start swinging the court hammer or that they try to kick us out of the hacking game by locking our little security hole totally!

besides that, its not worth going to jail just because a 15 year old might like the idea that he can unban his console that he should never have messed with.

Well I think MS is certainly using the 'backup' theory to get some consoles pushed. But at certain times they'll hit with the ban hammer, so owners that got hit once or twice, sell their banned one 2nd hand, will buy a new one and MS hopes they'll be so addicted to XBL and their games, they will start to use legit/originals after that.

Probably there will always be left a possibility to use backups, for another 6 months and MS will ban the next new wave of new 360 owners that haven't learned the hard way yet. That way they attract new customers first that run backups (illegal games) and try to convert them to game buying users after they have XBL and the 360 in their daily 'routine'.

[amadeus]

Why? Because they knew that hackers would hack it to be able to boot Linux from dashboard.

I wish I could take credit for this, but it was one of the 17 mistakes MS did, presented at 23C3 by Michael. The presentation can be see at http://www.free60.org/wiki/Videos. It is the first video.

I happen to think that's nonsense - it's mind-bogglingly difficult and definitely impractical to separate security mechanisms to that kind of degree. How do you design a mechanism that allows unrestricted homebrew software without allowing someone to use the same mechanism to load a copy of a retail game?

I don't know if that one have a desirable solution, but Michael's point is that MS made a design mistake by making one DRM to protect the XBox against Linux and homebrew.

[tmbinc]

amadeus: Actually, your "one DRM for every enemy" is in my eyes the exact error microsoft has done, and that was also the main thing we tried to tell microsoft on bluehat. They've used the same system to fight against linux hackers to also fight against piracy, cheating and online-consistency problems. Every hacker is intersted in his own goals, but in this case, all hacker could work together, and hack "the security". And all hackers together are much more likely to hack something than only a few ones alone.

If they had seperate security systems for anti-Linux/homebrew, anti-piracy, DRM etc., probably only few hackers would have cared for DRM at all. The linux-hackers would have worked on one side, without any support from the other groups. Thus, it would have been more likely that some parts wouldn't be hacked, or at least not all at the same time.

There *are* methods to allow homebrew, and still disallow piracy. Look at the PS3. Or let's cripple the GPU, and uncripple it with a challenge/response which would be embedded in the games. Homebrew could use the GPU at half-speed (which is still more than decent). Who would work one year on trying to free half of the GPU? Probably much fewer people. Or look at the gamecube, where the DVD-Rom is doing *all* the security checks (ok, ultimately it failed because of backdoors.. but that's another topic. The gamecube was effectively (not counting the ACLoader) warez-free for almost 2 years of homebrew).

Microsoft wanted the ultimate flexibility by implementing all security in one piece of software. A "one hack frees it all" is probably what they had to pay for this. They could still have put more stuff in hardware, like key management. Why didn't they implemented a hardware unit to manage the keyvault, making decrypted keys never leave the hardware? Who would have hacked THAT? (linux hackers don't care for the keyvault...)

[torne]

I don't know if that one have a desirable solution, but Michael's point is that MS made a design mistake by making one DRM to protect the XBox against Linux and homebrew.

That's the same thing as what I said, though. To separate the two schemes, you need the anti-piracy mechanism to not block homebrew in any way, otherwise the two schemes aren't separate and people who want to run homebrew will end up enabling piracy as a side effect. Thus, to make it work you need to design a scheme that prevents piracy while fully enabling homebrew.

There *are* methods to allow homebrew, and still disallow piracy. Look at the PS3. Or let's cripple the GPU, and uncripple it with a challenge/response which would be embedded in the games. Homebrew could use the GPU at half-speed (which is still more than decent). Who would work one year on trying to free half of the GPU? Probably much fewer people.

I was discounting the PS3's 'solution', because I don't think it's a solution at all - if I had any interest in using a PS3 for Linux/homebrew I would absolutely be after a way to access the entire capabilities of the hardware. Unless you let everyone play on the same field you've not solved it, and then you lose in all the other ways (commercial, etc)

Or look at the gamecube, where the DVD-Rom is doing *all* the security checks (ok, ultimately it failed because of backdoors.. but that's another topic. The gamecube was effectively (not counting the ACLoader) warez-free for almost 2 years of homebrew).

The gamecube had no security at all to prevent you from running arbitrary code, though. Having no mechanism is easy to design There's just no built-in mechanism to load binaries that doesn't require authentic discs. (except the backdoor, obviously).

They could still have put more stuff in hardware, like key management. Why didn't they implemented a hardware unit to manage the keyvault, making decrypted keys never leave the hardware? Who would have hacked THAT? (linux hackers don't care for the keyvault...)

If you have hardware key management but it's possible to run an untrusted OS on the CPU, then the untrusted OS can ask the hardware key device to do things for it, no? You don't need to steal the keys if you have unrestricted use of them. e.g. boot Linux, then load a virtualized copy of the dash. Doctor all interactions between the dash and the hardware key management device. Live thinks you're authentic.

To make that kind of scheme work in the face of a hack that allows running an untrusted OS with privileges to access the hardware directly you need the actual security mechanisms themselves to be implemented in hardware - i.e. move the functionality of the hypervisor into read-only firmware or silicon - and then it can't be updated, meaning if there's a bug in it, you lose anyway as there's no way to patch existing systems.

(btw, I'm a security analyst and kernel programmer for an embedded OS, so these design issues have crossed my mind before *grin*)

[amadeus]

amadeus: Actually, your "one DRM for every enemy" is in my eyes the exact error microsoft has done, and that was also the main thing we tried to tell microsoft on bluehat. They've used the same system to fight against linux hackers to also fight against piracy, cheating and online-consistency problems. Every hacker is intersted in his own goals, but in this case, all hacker could work together, and hack "the security". And all hackers together are much more likely to hack something than only a few ones alone.

Did they give any explanation on why they didn't wanted to make independent DRM's?

If it's a prestige question, then they have at least made up their mind, and will rather screw the game companies than admitting the demand for Linux.

If they had seperate security systems for anti-Linux/homebrew, anti-piracy, DRM etc., probably only few hackers would have cared for DRM at all. The linux-hackers would have worked on one side, without any support from the other groups. Thus, it would have been more likely that some parts wouldn't be hacked, or at least not all at the same time.

This was Mist's point exactly =)

There *are* methods to allow homebrew, and still disallow piracy. Look at the PS3. Or let's cripple the GPU, and uncripple it with a challenge/response which would be embedded in the games. Homebrew could use the GPU at half-speed (which is still more than decent). Who would work one year on trying to free half of the GPU? Probably much fewer people. Or look at the gamecube, where the DVD-Rom is doing *all* the security checks (ok, ultimately it failed because of backdoors.. but that's another topic. The gamecube was effectively (not counting the ACLoader) warez-free for almost 2 years of homebrew).

Doesn't homebrew fall under the same category as playing a backup of an original? I don't think the PS3 allows booting homebrew.

Perhaps the solution would be to not allow homebrew, but offer an exchange service of scratched discs that no longer works.

I assume that the reason for making a backup is to prevent the original from being scratched?

I am not up to date on the Wii hacking, but it seams that Nintendo have taken the route to not put its money on making a strong DRM for the hackers, but make very difficult for the users to implement the hack/mod chip.

Perhaps that is the best solution for all parties? Hackers get to do what they want, and MS/Nintendo makes in less attractive for the average user.

[amadeus]

I was discounting the PS3's 'solution', because I don't think it's a solution at all - if I had any interest in using a PS3 for Linux/homebrew I would absolutely be after a way to access the entire capabilities of the hardware. Unless you let everyone play on the same field you've not solved it, and then you lose in all the other ways (commercial, etc)

Of course having full hardware access would be the best, but I think Sony solved the piracy problem with the PS2/PS3.

But full hardware access will never happen out-of-the-box, for one "good" reason. MS can't collect royalties from game companies.

I doubt many Linux hackers would derive much satisfaction from hacking the PS3, because it allows Linux out-of-the-box.

But time will tell, if the PS3 DRM will get hacked to allow full hardware access 

[tmbinc]

Sure, you all got your points. And yes, solving the "homebrew yes, piracy no"-question is not easy. But neither is the situation today. It's simply that more work is required on this topic.

torne, i totally understand your points. But there is still a difference between using a crypto engine and knowing all secret keys. The 360 hypervisor for example lets you sign data with the console private key. But it doesn't let you extract that key. With the hypervisor exploit, we can extract that key, and transplant it into another key, allowing, for example, "unbanning a box" (wow, we are back on topic ;). If the key would be held in hardware, this wouldn't be possible (unless the hardware is buggy, of course). If the bootloader's RC4 stuff (or better, the HMAC stuff) would be done in hardware (involving the secret key), we wouldn't have a "rom decrypter", but we would need hardware access each time we need to decrypt something. While this doesn't *solve* security problems, it make things harder - sometimes hard enough to tighten the "experienced security" of a product enough to make it secure for a year, or longer. The key difference is probably that software can be reversed, but hardware usually cannot, even if you have the possibilities to decap chips and photograph them.

For example on gamecube, we still don't know the streamcipher algorithm and/or key for the bootrom encryption. Ok, it doesn't help in that case, because a 2MB table is enough to describe the decryption in a blackbox, but imagine a block cipher... no possibility to encrypt the data, even though a symmetrical algorithm could be used, because the algorithm is implemented in hardware. Or take a look at gamecube's memory card lockout, where the DSP does the challenge/response to the memory card hardware asic. (ok, this failed because an ancient gamecube software version did implement the algorithm in software instead of using the DSP.) Or look at paytv - NDS still has the most secure cards, mostly because they have their strange ASIC. I doubt they have terrible secure algorithms in there (ok, they probably *have*, thanks to s. working there. But the point is, it doesn't really matter.), still, it's not hacked.

Yes, at some point, you need to expose stuff. You cannot keep the game encryption secure for ages. But let's take the Cell isolated mode as an example, and let's assume for a moment it could be deactivated with a strapping pin. You could boot into a PS3-like system, with a hypervisor knowing to load (and decrypt) games, signed ones only, of course - or you could flip a switch, and boot into a completely free environment, without any access to the encryption keys. Agreed, this fails when somebody finally decrypts a game, allowing it to boot in the "free environment". But you wouldn't have all the hackers working on this, only a few, because those only interested in homebrew would spent their time on other devices.

torne, your "Unless you let everyone play on the same field you've not solved it" comment is interesting. Let's take the 360 as example, but i guess it also applies to the PS3. You don't have full hardware access as a commercial developer there, too. In both cases, the hypervisor is still there. For example this restricts you to not have self-modifying code in games on 360, and (please correct me if i'm wrong) the isolated SPU isn't available for games on ps3 either. We are that far that systems are restricted even for real developers. It's just that hackers don't eat that. They want full access (after all, that's why they are hackers), sometimes more than you would have as a commercial developer. Today the 360 HV exploit gives you more freedom that you would have as a game developer.

And for the gamecube: The thing is, it didn't *need* to have a mechanism to prevent running arbitrary code. They had their goal of preventing "piracy", and that worked well for them (backdoors aside). Today, the goals are more complicated (no cheating, online, DRM), so the simple gamecube way doesn't work anymore. Agreed.

[robinsod]

I think that says it all....