about this blog About This Blog:

Steinbring Inc.

The Real Story Of Window Washers

published on March 12th, 2007 . by joe
Link [ Via RGS ]

Remove A Cork From A Bottle Without Breaking The Bottle

published on March 12th, 2007 . by joe

Naked guy runs by news camera with ass on fire

published on February 27th, 2007 . by joe

I was tempted to make a Jerry Lee Lewis joke with this one but I don’t think it’s needed. :)

Link [ Via Bits & Pieces ]

Power Wheelin’

published on February 26th, 2007 . by joe

This is what happens when you have too much money in your pocket and too much beer in your system.

Link [ Via ETTF ]

WinDVD 8 AACS Device Key Found!

published on February 24th, 2007 . by joe

I fully expected that a software next-gen DVD player’s device key would be discovered, allowing any movie playable by the software to be decrypted.  The movie industry expected the same thing.  That’s why they engineered both HDDVD and BluRay to allow for the revocation of device keys.  So what’s next?  Do they revoke the newly discovered device key for WinDVD 8 and effectively kill all existing, legally purchased and legally used, copies of WinDVD 8 in an attempt to eliminate the value of this key or do they do nothing.

A few nights ago, something that Arnezami had written about slowing WinDVD 8 down though intensive memory dumps had started me thinking. So, I brought up my favorite Java IDE and begun writing code. Using a combination of VUK Finder (by Jokin), pmdump, psuspened (Sys Internals) and WinHex I was able to get enough data to find the VID, Media Key, and Processing Key by using the “bottom up” approach that Arnezami spoke about.

As soon as I had the processing key in a memory dump I knew that I was close to a Device Key. I then quickly implemented a version of AES-128G(k, d), where k = key and d = the data to be decrypted, however in this case I seeded d with the constant 0×7B103C5DCB08C4E51A27B01799053BD9 + 1, or 0×7B103C5DCB08C4E51A27B01799053BDA (per page 13 of the AACS Common Crypto doc), and ran the entire contents of my memory dump through decryption at 1 byte incremental offsets.

About 35,000 bytes into the file I extracted a 16 byte value that was able, using the constant as the d value, to create the processing key. If my interpretation of the AACS specification is correct, I have found a device key. Here is the device key, along with the memory offset where it can be re-discovered assuming that you dump memory in WinDVD 8 early enough in the runtime process. By the way, psuspened helps tremendously with slowing processes down so that pmdump can accurately dump memory!

[WinDVD 8]

Device Key: AA856A1BA814AB99FFDEBA6AEFBE1C04
Found at memory location: 0×000089EC

Device Key: AA856A1BA814AB99FFDEBA6AEFBE1C04
Found at memory location: 0×00008A20

An interesting thing to note is that the device key is found only a few bytes before the location where Arnezami found the processing key, and in contiguous memory! It is also interesting to note that WinDVD8 keeps the device key in 2 difference memory locations, very close by each other. My guess is that this would be the result of some sort of deep copy, maybe even the result of a function call.

Link [ Via Slashdot ]

« Previous Entries     Next Entries »