Post by: Psyfer9983 on November 13, 2010, 03:43:00 AM
Second, don't know if this goes here. ANYWAYS,
I was looking around for a way to decrypt the KV.bin with out the cpu key. Didn't find anything of course. So I start to look at my nand dump from my JTAG with "010 Editor" (a hex tool), didn't really find anything useful. Then I use "360 Flash Dump Tool .97" on it and extracted the key vault only. Of course it was encrypted but it hit me, I HAVE MY CPU KEY. 360 Flash Dump Tool can decrypt the key vault if you have your cpu key. So now I have an encrypted kv.bin and a decrypted kv.bin file. If you use 360 Flash Dump Tool to view the decrypted key vault, it will give you a list on the left with the addresses and names of the keys inside it and on the right side will be the hex and ASCII of the address. Here is what I found, mind you that I will not show the hex or ASCII for private reasons.
KEY 0x14 - XEKEY_CONSOLE_SERIAL_NUMER
KEY 0x1A - XEKEY_DVD_KEY
You can even get your "real console id" that you can generate with 360 Flash Dump Tool.
At the bottom of the box it will tell you the offset address (hex of course) of the highlighted key.
BINGO!!!!
Now I had an idea to make a program to decrypt the kv.bin without the cpu key. Since we know the serial number of the console is on the back of the 360, and we know the hex address to look for it (the first 12 of 16 bits) is 0x00B0, it would be just be decrypting the 0x00B0 address. The last 4 bits of the address on my kv.bin were "...." (00 00 00 00 in hex), I would think it would be the same for all kv.bin files. We could also use the "real console id". Basically, use any information that we know with out a decrypted kv.bin file (like the sn of you console) to actually decrypt it, given the know addresses in hex.
If I knew how code a decryption program I would. Mind you that if someone else makes the decryptor you will have to use a 32 character pass word (CPU KEY). Basically decrypt the cpu key out of the kv.bin with known information.
We all know that you can dump a nand regardless of the dash version so this will work for anybody. I though that this would come in handy for making a decryption program for decrypting the key vault. This would defiantly be useful for getting the dvd key for people with lost keys. I will look into this a little more. I will also try to post all the key names (XEKEY) that are listed the key vault and maybe some pics.
Though I might share this, who knows, it might help someone.
Post by: Psyfer9983 on November 13, 2010, 05:28:00 AM
This post has been edited by Psyfer9983: Nov 13 2010, 01:31 PM
Post by: Psyfer9983 on November 13, 2010, 05:57:00 AM
PIC
This post has been edited by Psyfer9983: Nov 13 2010, 01:58 PM
Post by: syntaxerror329 on November 13, 2010, 12:37:00 PM
What i do like about your idea is that we would be brute forcing a very small amount of code so it would be very fast. You could probably test thousands of keys per second. Still i have read even if we did thousands a second it would not be fast enough to make this practical.
Not sure if my math is right but there is 3.402823669209385e+38 possible keys.
So that is the same as 340282366920938500000000000000000000000 possible combinations.
I think this is why your idea wont work.
Here is a idea for a simple test.
Make a computer program that simply counts from
00000000000000000000000000000000 to FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF and see how long it take to even count up till it even matches your key. This test program would not actually be brute forcing anything so it would be super fast. After a few months if you count up to your key then we can re-visit this idea further.
Post by: Psyfer9983 on November 13, 2010, 02:53:00 PM
Post by: MadBoxer on November 13, 2010, 04:34:00 PM
QUOTE(Psyfer9983 @ Nov 13 2010, 01:53 PM) 
I see your point, know any programs out that will work LOL. If so I would just run it across 2 offset only. The serial number and the "real console ID" offsets 0x00B0 and 0X09CA.
I have experience in computer forensics and this idea is crackable with brute force, but the problem is as syntaxerror329 mentions, would take a very long time to calc. Who wants to have their computer running for years to decrypt a key?? In the forensic industry, a key like this is considered un-crackable only because of the fact that by the time a computer decrypts it via brute force, the data would be so old that it is worthless. Even if you had 100 super computers running in parallel it would still take many years to dycrpt a key of this size. If the key was like 8 digits long, then it would be much easier, but the longer the key, the longer it takes. Microsoft is not stupid and they made sure their keys were long enough to eliminate cracking.
Post by: Psyfer9983 on November 13, 2010, 04:45:00 PM
Does anybody know any software that will take 2 files or 2 words (32 characters long), one encrypted and the other not, and generate a key from them which then can be used on another file or word. Exp...
encrypted file or word
+
decrypted file or word
=
KEY
Then try the key on a different file or word, mainly the offset address of the DVD KEY.
I'm just theorizing still, but it still should work. And it doesn't have to be a 32 character key, unless you want to try to generate a CPU key (would be nice).
Post by: MadBoxer on November 15, 2010, 09:22:00 AM
QUOTE(Psyfer9983 @ Nov 13 2010, 03:45 PM)
I have spent another half hour or so looking for some software with no luck, google is worthless with its results that have nothing to do with what you are looking for. So I am asking for some help.
Does anybody know any software that will take 2 files or 2 words (32 characters long), one encrypted and the other not, and generate a key from them which then can be used on another file or word. Exp...
encrypted file or word
+
decrypted file or word
=
KEY
Then try the key on a different file or word, mainly the offset address of the DVD KEY.
I'm just theorizing still, but it still should work. And it doesn't have to be a 32 character key, unless you want to try to generate a CPU key (would be nice).
It seems like you may not have understood my last message correctly. I'll will try to explain one more time. It doesn't matter if you try to decrypt one byte from the nand or the whole nand file, getting the cpu key with brute force would take pretty much the same time. The amount of information you are trying to decrypt doesn't make much of a difference, it is the size of the key used to decrypt that information that determines how hard is it to crack. There is no way to do your method without having a computer run for many years or possibly many decades strait! Unfortunately this is because the CPU keys are so long. If you don't believe me, let me try to back up my statement a bit. I have a close friend that works as a computer forensics specialist for law enforcement and he knows all about encryption. He verified that a key this long is just not feasible to crack using brute force. Trust me, anyone on Xbox scene that knows enough about encryption to make the program you are requesting wouldn't do it because they know it is not feasible to crack.