Getting IBX keys and a way to defeat MS WM-DRM 11.0.6000.7000

[sectroyer]

Hi.
Wanted to start a talk how we can extract (an how it is already done) IBX keys. According to technical details of freeme:

Since the
IndivBox.key file is shuffled in a random way for each client, these
keys would be extremely difficult to extract from the file itself.
Fortunately, we don't have to: these keys are part of the object state
that is maintained by this library, and since the offset within this
object of these secret keys is known, we can let the library itself
extract the secret keys! The code for this simply loads up the "black
box" library, has it initialize an instance of the object, and then
reads the keys right out of that object.

As I belive now it should not be that easy to extract keys from this object and probably this is not what FairUse4WM/mirakagi does. But I believe it gets IBX public key (It can be found for instance in license database file) and then tries to find it in IndivBox.key. As we may suspect somewhere "near" this key should be private key. This would explain why it outputs something like this:

AES: 4e 68 d7 2b c6 01 cf 5a 1e f3 3f ee 1f 73 a3 45
Decoding secondary keys
Please wait for 19587 attempts.
It is finished.

As I suspect these "19587 attempts" are just tries to check whether some set of bytes is the private key or not. But does anyone know how we can perform this check? I think about taking one license from the license file and trying to decode content key. It should be "short" and (not sure of this) begin with 7.
Regards.

[Ajax_Undone]

Is it a random access AES key generator...

It might search for the the key that unlocks the file to gain access to the data contained in the IBX... (ie Brute force attack)...

[sectroyer]

Originally Posted by Ajax_Undone

Is it a random access AES key generator...

It might search for the the key that unlocks the file to gain access to the data contained in the IBX... (ie Brute force attack)...

No it isn't I have found viodentias post that explains what is really going on

The AES key displayed in new key extraction
For the v11 individualization, v2ksndv.bla (or v2ks###.bla) is now an XML file. There are two tags of particular interest, the first 40 bytes of "c:PKCert" is the public key for ECC encryption and the "Keys" which stores all the secondary keys.

Each time you re-individualize, the DLL sends "escrowed" key information to Microsoft's servers which decrypts it and re-encrypts it inside this secondary key table. These are all the keys for previous individualizations.

The <Keys> tag is encrypted with AES in Counter mode using the displayed key. To decrypt, create a 16-byte BIG-ENDIAN counter (that is, 16 bytes of 0, next would be 15-bytes of 0's and one 1 byte, and so forth). Encrypt that with the AES key. XOR the output with the next 16-bytes from the tag.

Once decrypted, the Keys tag holds a XML document which in turn has both the old ECC keys (which v1.3 happily extracts for you), and some RSA keys - the RSA keys are apparently new for v11, and I don't know what they're for.

By the way, if one looks at the individualization process in Wireshark, it's conceivable that future individualizations can be handled with the assistence of Microsoft's own servers.

Now I just have to understand it and implement

[Ajax_Undone]

LOL well good luck he confused me...

[sectroyer]

I think I understand what he meant. I will just need to implement and test it Unfortunately he didn't explain how to get this AES key But it's a piece of code less to reverse engineer

[Ajax_Undone]

You might try getting a Copy of the Microsoft digital rights management SDK 10.1.2... After all thats how Viodentia did his program... I know that you have to register with MS and buy a licence to use it I think... or find it on a Bittorrent Site...

ANyhow good luck unlocking the secrets of the empire...

[sectroyer]

I want to crack wm-drm without using any ms code and without linking with any ms drm libraries

[people are pork]

There is much confusion, of which I will try and resolve. This information is my own fabrication. It may not represent actual reality. Nor do I speak for any employers, past or present.

The IBX or Individual Black-boX is a method of practical implementation of access control. The goal is to entangle decryption capability with policy enforcement in a manner that resists separation.

Concretely: The IBX only decrypts video for a blesssed player application.

An IBX is just a DLL (renamed to .key), that contains two assymmetric keypairs (1 - Elliptic Curve Cryptosystem, see freeme doc. 2 - RSA, not documented) and one symmetric key (explained later). It also contains the code to parse licenses, checks that the system clock hasn't been moved backwards, verifications that it is running on the same hardware, and signature validation for the players. When things work perfectly, the application gives the IBX the XML licenses + encrypted file data, and gets back fresh clean multimedia data.

In theory, this is doomed - all the keys are in the hands of the attacking parties. In practice, the inevitable is delayed by layers of obfuscation and renewability. As long as each version lasts long enough for the next to be prepared, then the system is reasonably secure.

For WM11, IBX files are obfuscated by a tool called "warbird", which is more of an ineffectual surrender chicken. The process likely goes like this, for a large number of IBX components.
1. Generate random key data
2. create source from templates + key data
3. Compile into object files
4. apply "warbird" obfuscations
5. link (shuffling the order of object files)
6. sign

Warbird uses the linkage information in the object files to make certain alterations.
It encrypts certain whole routines, some randomly picked, others based on configuration.
Other routines are seperated into basic blocks (a flow of asssembly statements without a branch), each block is encrypted individually, and the branches are removed (stored in a seperate table).

The encryption is a home grown, weak cipher that uses two 24 bit keys (one for even bytes, the other for odd bytes). The keys are either stored in the IBX, or are calculated in code based on hashing other parts of the IBX to ensure integrity.

To further protect the valuable asymmetric keys, the keys are stored in a mutated form. They are transformed by XORring with a random value, as well as being rotated.

One problem in this scenario is that each IBX has a key, but it is impossible to handle upgrades. If you have IBX v0, and software upgrades you to IBX v1, you want to play all your old files! We handle this in both directions with an associated file (XML, ending in .bla). This file contains your current asymmetric keys, encrypted to a secret private key that only the individualization servers have. When you go to upgrade, this "escrowed" data is encrypted with the new IBX's symmetric key, and stored in the XML file.

Recap:
.key - Obfuscated: ECC key pair, RSA key pair, AES key
.bla - Encrypted to Microsoft key: ECC keypair, RSA keypair, AES key. Encrypted to AES key: ECC/RSA keypairs for PREVIOUS IBX files.

c0redump's method used in fairuse4wm and mirakagi worked by extracting the private ECC key data and AES key from the IBX due to the weak obfuscation. Since the key data is mutated, instead of executing IBX code to undo the mutation, the attack just tried every possible mutation on the ECC key data.

The new IBX tries to prevent these issues by increasing the number of mutations to make the attack infeasible, using more instructions and better checking to make emulation difficult, and improving slightly improving some microobfuscation. Some of the code that came from cloakware can't be rewritten at this time, so some weaknesses remain.

However, this new version complexifies the simple scanning attacks that worked on the prior versions.

[people are pork]

To answer an unasked question - what can you do?

it is feasible for a moderately skilled attacker to get the keys from any single IBX. Preventing this is impractical. Obfuscation only aims to prevent tools from working over the long term.

The easiest attack to mount, then, is to figure out what registry keys are involved in preventing an IBX downloaded on machine A from being moved to machine B. When you can do this, you can distribute IBX files with the associated keypairs.

This strategy will also cause more grief for the obfuscation team, as the exact methods used will no longer become public.

[people are pork]

Originally Posted by Ajax_Undone

You might try getting a Copy of the Microsoft digital rights management SDK 10.1.2... After all thats how Viodentia did his program... I know that you have to register with MS and buy a licence to use it I think... or find it on a Bittorrent Site

I am unaware of this file being on a bittorrent site. Since each version includes information that will link it to the leaking party, it is unlikely to be leaked.

fairuse4wm did not use this sdk. It used the freely available windows media sdk, however, it used an undocumented API, probably by guessing the parameters. This undocumented API was used to open and walk the hashed datastore (HDS file).
This API will probably be removed from future versions of the public SDK.

Originally Posted by sectroyer

As I suspect these "19587 attempts" are just tries to check whether some set of bytes is the private key or not. But does anyone know how we can perform this check? I think about taking one license from the license file and trying to decode content key. It should be "short" and (not sure of this) begin with 7.

It is actually much simpler. The public key is, well, public. The parameters are public now in the freeme doc. The secret key is just an integer.
In ECC, the public key is (IIRC) (Secret Key)*(Generator Point).
So the code does an scalar multiply then does a compare.
There are some optimizations involving projective transforms and other cases, but you will not find the bytes of the key in the IBX (see above post). This isn't AACS stuff.

[Ajax_Undone]

My point exactly


Tu kool Now we know where to look... Thanks bro...

[Ajax_Undone]

OMG are you Viodentia...

[Ajax_Undone]

either way I am not writing the decipher and still have no idea what the hell even he has said so its all yours sectroyer...

[sectroyer]

The point is that I believe he knows what he is saying Of course I don't say that I get everything clear but I am starting to see trough the clouds

[abudara]

drmdbg for IndivBox.key v11.0.6000.7000
http://sky.advenbbs.net/bbs/DRMdbg2005.htm

[sectroyer]

Originally Posted by abudara

drmdbg for IndivBox.key v11.0.6000.7000
http://sky.advenbbs.net/bbs/DRMdbg2005.htm

Be careful since some versions on this site doesn't work and some do. In other words we can say that it is cracked

[Aratar]

hmm.. I don't really get that drmdbg to work tho

[sectroyer]

Originally Posted by Aratar

hmm.. I don't really get that drmdbg to work tho

I spent two hours trying to install sp2 and validating product key. Then 15 minutes to install (without WGA) WMP 11 and individualize to 11.0.6000.7000 so you can trust when I say that it is cracked Just learn japanese or spent some time with google language_tool

[ssj4android]

Why don't you post some instructions for those of us who know no Japanese? It doesn't seem to be working on Vista English for me. Just closes wmp11 shortly after it tries to open.

[sectroyer]

Originally Posted by ssj4android

Why don't you post some instructions for those of us who know no Japanese? It doesn't seem to be working on Vista English for me. Just closes wmp11 shortly after it tries to open.

The problem is that I don't know japanese You should consider uninstalling Vista I don't know if it will ever work with Vista