WinDVD 8 Device Key Found! - Page 2

lightshadow · 27th February 2007, 01:12

I have just come to think of DRM Tools

drm_tools contains the following small utilities:

accudate modified date utility with subsecond accuracy
columnadd adds columns of integers, decimals and/or times
datasniffer a tool for dumping binary data
execinput runs an input file as a series of commands
extract a tool for extracting row/column data from files
mbin input tool for buffering large binary data streams.
mbout output tool for buffering large binary data streams.
mdump a tool for dumping binary data.
msgqueue command line manipulation of message queues

jokin · 27th February 2007, 03:02

My memory dumps have been 300 MB or so.

HyperHacker · 27th February 2007, 06:24

Quote:

Originally Posted by lightshadow

If there someone in this thread with a lot of memory, we can make pattern match script/program that takes the memory dump and compares patterns of 16bytes.

I could probably write it in Matlab, but that would not be efficient=(

In psudo I guess it would be something like

load memory dump into an array
initialize 2 arrays that will contain offsets of pattern matches.
take the 16byte starting at offset 0, and compare them with the 16bytes starting at offset 1.
if pattern match, save offsets and compare with 16bytes starting at offset 0 with 16bytes starting at offset 2.
when end of data is reached, take the 16bytes starting at offset 1, and start pattern match all over again.

if it is made general enough it could perhaps be used for finding other types of keys? Private host keys perhaps?

Good idea/bad idea?

How big is the memdump?

I could do this in C and I have 1GB of RAM, but what exactly would this accomplish? It just sounds like you're trying to make a list of memory locations that contain the same 16 bytes as other memory locations. I see no real use for this, and blocks of uninitialized memory would inflate the list to ridiculous proportions.

arnezami · 27th February 2007, 07:26

We have 4 problems when working with memdumps:

1) The size of the memdumps
2) The low speed of checking if any x bytes is a key
3) The very short period the key is in mem
4) The inaccuracy of knowing when the key might be in mem (no easy sign)

So I have been thinking of something a little different (but i'm not sure yet if it would be very useful): make many memdumps (and keep making them) then scan one memdump for all unique 16 (or 20) bytes and write each of them in a hash table (or some binary tree tructured file) or simply a sorted file of 16/20 byte values. The idea is you can do this with all these memdumps and gather a set of already tried keys. This way only the unique sets of bytes have to be used for checking whether they are in fact keys or not. And you only have to check additions to the set (of unique 16/20 bytes) caused by new memdumps.

Why? Because when trying to find a key you need a memdump at the exact right time (this is the tricky part when with memdumps only and doing no altering of the code). In practice this means you need many memdumps at around the same time and you somehow have see whether a new memdump contains anything "better" then your last ones. But you can only do that if you know what you're tried so far. Simply trying (for example) each 20 byte value in each 150-300MB memdump at a speed of a few thousands per second (this is the speed of ecdsa...** see the problem?) is time consuming.

Of course we can try to pinpoint/anticipate where a private key/device key might be but we could be mistaken (and requires a more "hands-on" approach). Therefore the above might not be such a bad idea.

The biggest problems with this idea: (a) simply processing one memdump for new possible keys may be timeconsuming (many mem lookups, although some basic randomness checking will speed things up big time) and (b) maybe there will be too many unique values each startup of the Player so the hash table/tree will get too big (you do have to use the same movie and player each time of course).

Technically we could even share this stuff but only between people who own the same disc/movie and software player (and since memdumps contain lots of pc/drive identifying stuff it can't really be done publicly).

Alternatively maybe some kind of diff between an old dump and a new dump could work but when looking at dumps I'm not so sure they are organized exactly the same each time: looks quite dynamic... So diffs won't work so well.

I'm also thinking about releasing a proggy that can check a memdump for a private key so everybody can start trying to find it. What do you think?

Regards,

arnezami

PS. Personally I'm starting to think using a debugger and or altering binaries will be much more useful. But since I'm not experienced with those somebody else will have to try that. I've read somewhere about altering some kind of zeromemory-function (which was called by P DVD many times) so it wouldn't clear its mem. Something like that...

** I'm using pre-computation, "light" private key checking, fast entropy/randomness detection. So it won't go much faster...

lightshadow · 27th February 2007, 08:47

Quote:

Originally Posted by HyperHacker

I could do this in C and I have 1GB of RAM, but what exactly would this accomplish? It just sounds like you're trying to make a list of memory locations that contain the same 16 bytes as other memory locations. I see no real use for this, and blocks of uninitialized memory would inflate the list to ridiculous proportions.

Okay, I forgot to write the rest. When the locations have been collected, then it should write out the 16bytes of each location.

But I see the problem with uninitialized memory...

Pata · 27th February 2007, 14:38

Quote:

Originally Posted by arnezami

We have 4 problems when working with memdumps:
I'm also thinking about releasing a proggy that can check a memdump for a private key so everybody can start trying to find it. What do you think?

Boyer Moore is fast
http://en.wikipedia.org/wiki/Boyer-M...arch_algorithm

Like GSAR.

Or maybe others..
http://www-igm.univ-mlv.fr/~lecroq/string/index.html

natronicus · 27th February 2007, 17:31

Quote:

Originally Posted by arnezami

PS. Personally I'm starting to think using a debugger and or altering binaries will be much more useful.

This is the best approach. If you can learn where to set the right breakpoints, you can step through and keep an eye on memory after every event, until you can reliably come to the same position.

Since you already know where the keys are stored in memory, it should be fairly trivial to identify when it first occurs, then back up and figure out exactly what is happening leading up to it.

BlazingMind · 27th February 2007, 21:12

I've been following these decryption threads with great interest lately, and I would like to start off by congratulating you all for the progress you have made :-) Good work!!!

About debuggers though...
There arent really that many people that have access to SoftIce / IDAPro etc. and are capable of using them effectively. Even fewer I suppose, that also has access to HD DVD / BR hardware, software and a movie or two.

So... I've been thinking about how the "average" AACS cracker would be able to get some useful data out that later could be interpreted by someone with the right skills with reverse engineering.

This is why I would like to suggest that you take a look Cheat Engine and TSearch.

Both programs should be able to act as a debugger that should enable you to get to the routines that handle the keys.

Let's say you found a sub device key in memory... If you loaded CE and selected "add address manually" and then selected "find out what writes to this address", you should end up with a list of addresses to the actual code that handles the keys.

Even if the keys change, these addresses should be static for each build of the software, so it should be far easier to extract more keys by following these routines... (in theory)

If you were able to identify the routines that handles the keys, they can again be followed to see where other keys are stored. (find the AES-G algo and I believe you have what you need to get all keys by following the data output from it).

...Just a thought...

xyz987 · 27th February 2007, 22:00

Quote:

Originally Posted by BlazingMind

This is why I would like to suggest that you take a look Cheat Engine and TSearch.

Both programs should be able to act as a debugger that should enable you to get to the routines that handle the keys.

Let's say you found a sub device key in memory... If you loaded CE and selected "add address manually" and then selected "find out what writes to this address", you should end up with a list of addresses to the actual code that handles the keys.

Even if the keys change, these addresses should be static for each build of the software, so it should be far easier to extract more keys by following these routines... (in theory)

If you were able to identify the routines that handles the keys, they can again be followed to see where other keys are stored. (find the AES-G algo and I believe you have what you need to get all keys by following the data output from it).

This seems to be a far good approach.

lightshadow · 27th February 2007, 22:13

Quote:

Originally Posted by BlazingMind

This is why I would like to suggest that you take a look Cheat Engine and TSearch.

I know the ScummVM folks are very happy with IDA - The Interactive Disassembler.

I have no idea how easy/complicated it is to use.

arctor · 27th February 2007, 22:57

Another option is too have a look in AnyDVD for the private key. If they are using the PowerDVD 6.5 private key we may be able to grab this from AnyDVD.

Strikes me that it may not be as well protected as WinDVD and PowerDVD. Plus there is almost a sense of irony of hacking AnyDVD

BlazingMind · 28th February 2007, 00:15

Quote:

Originally Posted by arctor

Strikes me that it may not be as well protected as WinDVD and PowerDVD. Plus there is almost a sense of irony of hacking AnyDVD

Usually software created by hackers is far better protected than commercial stuff. The reason is that the hacker knows all the common pitfalls, and how to avoid them, while commercial programmers (that write programs in high-level languages etc.) don't know how to protect their stuff properly. Besides, they are often on a "clock", and don't have time to go through all the details...

BlazingMind · 28th February 2007, 00:20

Quote:

Originally Posted by lightshadow

I have no idea how easy/complicated it is to use.

IDAPro is the only disassembler you'll ever need, but you need to know a great deal of assembler to be able to make sense out of it. Assembler is not something you learn in 24 hours.

Driverstudio / SoftICE would probably be the tool of choice here though... You probably need to debug the code while it's running, and that is even harder than reading it in IDAPro :-P

Anyways...
The CE and TSearch are freeware programs, and not that hard to use. It is better suited for those with little or no assembler skill.

Edit: confusing sentance :P

HyperHacker · 28th February 2007, 02:41

If someone wants to buy me an HD-DVD drive, I know how to use a debugger...

This is certainly the approach to be taking. Load up your debugger and set a write breakpoint on the memory location that will hold the key, before it's actually there. If you can set it up to break only when a certain value is written, all the better. When you find this write you will be right in the routine that writes the key into memory. From here it'd be easy to make it just give you the key.

Since patching into existing apps is difficult, I'd go a simple route: Simply write the key to some unused memory location, along with some sort of "flag" byte. Another program can be written that will watch this memory region, and when the flag byte appears, read the key. This avoids the need to hack in a bunch of code to write the key to a file or what have you, and is more reliable than simply telling the other app where the key is being written already, since this could be overwritten later.

Once you can do this you can write a program that will launch the player, apply this hack in memory, wait for the user to load a movie, and read the key out. All they'd have to do is run the program (it could even launch the player for them

).

BlazingMind · 28th February 2007, 09:39

Quote:

Originally Posted by HyperHacker

If someone wants to buy me an HD-DVD drive, I know how to use a debugger...

You and me both ;-)

There is however a pitfall which can make this approach a tad too heavy for the average user.

If self modifying code is used, the address of the routine may change. I doubt it is however, because SMC is a horrible thing to implement in such a routine as it takes huge performance penalties due to the code changing before execution.

Has anyone tested if the keys tend to stay at similar addresses, or will they appear at random?

From what I've seen so far, the addresses are placed so low that I doubt they are dynamically allocated. If this is the case, they should be consistent within the same build of the software... Anyone feel like checking?

Arne / ATARI, care to post the build numbers of your players? If this can't be found, check the version information on the exe file. Even the last modified date and filesize of your exe files may help identify the build.

Also check if the address changes after a reboot please.

BlazingMind · 28th February 2007, 10:17

Quote:

Originally Posted by HyperHacker

I see no real use for this, and blocks of uninitialized memory would inflate the list to ridiculous proportions.

Actually... it may not be such a bad approach after all.

Unused memory areas tend to be zeroed out (unless a buffer is reused without being unallocated). To do this, you should check for patterns. Of the 16 bytes, no byte should statistically appear more than twice, and the first 8 bytes should not match the last 8.

This should be enough to get rid of the mismatches.

If a buffer is reused, it will contain "random" data, that statistically will not match with 16 bytes at an offset of 034h.

I say it is worth a try...

(Grr.. I could do so much more if I had the actual hardware and software :P)

ATARI Vampire · 28th February 2007, 20:11

Quote:

Originally Posted by BlazingMind

Has anyone tested if the keys tend to stay at similar addresses, or will they appear at random?

WinDVD 8: Keys remain at the same memory locations (Device, Processing, Media, VUK and VID)

PowerDVD 6.5: Pending further analysis... keys migrate constantly between different memory locations. Currently working on documenting the pattern (still assuming it is not pseudo random).

BlazingMind · 1st March 2007, 01:10

Quote:

Originally Posted by ATARI Vampire

PowerDVD 6.5: Pending further analysis... keys migrate constantly between different memory locations. Currently working on documenting the pattern (still assuming it is not pseudo random).

Don't bother, they are random in the sense that windows decides where to put it based on how much free mem you have etc. Try using CE to trace the keys back to a routine that handles the keys. This should be a static address.

dirio49 · 1st March 2007, 02:07

Quote:

Originally Posted by BlazingMind

IDAPro is the only disassembler you'll ever need, but you need to know a great deal of assembler to be able to make sense out of it. Assembler is not something you learn in 24 hours.

Driverstudio / SoftICE would probably be the tool of choice here though... You probably need to debug the code while it's running, and that is even harder than reading it in IDAPro :-P

Anyways...
The CE and TSearch are freeware programs, and not that hard to use. It is better suited for those with little or no assembler skill.

Edit: confusing sentance :P

I am not a professional but I also like OllyDbg

I think easier than CE.

ffguy · 1st March 2007, 03:41

I am not a crypto expert by any means, just an interested programmer.
Given enough of the keys, one could theoretically figure out the master key used to generate them all by guess-and-check, correct? It wouldn't be fast, but it could be theoretically done.
I ask because I have several computers with nothing to do. By splitting the potential solution space into many many parts, people like me with too much time on their hands could start chipping away at the problem. Divide the solution space and start handing out slots, if not to find the key than to verify where it is not.

27th February 2007, 01:12	#21 \| Link
lightshadow Registered User Join Date: Feb 2007 Posts: 123	I have just come to think of DRM Tools drm_tools contains the following small utilities: accudate modified date utility with subsecond accuracy columnadd adds columns of integers, decimals and/or times datasniffer a tool for dumping binary data execinput runs an input file as a series of commands extract a tool for extracting row/column data from files mbin input tool for buffering large binary data streams. mbout output tool for buffering large binary data streams. mdump a tool for dumping binary data. msgqueue command line manipulation of message queues

27th February 2007, 07:26	#24 \| Link
arnezami Registered User Join Date: Sep 2006 Posts: 390	We have 4 problems when working with memdumps: 1) The size of the memdumps 2) The low speed of checking if any x bytes is a key 3) The very short period the key is in mem 4) The inaccuracy of knowing when the key might be in mem (no easy sign) So I have been thinking of something a little different (but i'm not sure yet if it would be very useful): make many memdumps (and keep making them) then scan one memdump for all unique 16 (or 20) bytes and write each of them in a hash table (or some binary tree tructured file) or simply a sorted file of 16/20 byte values. The idea is you can do this with all these memdumps and gather a set of already tried keys. This way only the unique sets of bytes have to be used for checking whether they are in fact keys or not. And you only have to check additions to the set (of unique 16/20 bytes) caused by new memdumps. Why? Because when trying to find a key you need a memdump at the exact right time (this is the tricky part when with memdumps only and doing no altering of the code). In practice this means you need many memdumps at around the same time and you somehow have see whether a new memdump contains anything "better" then your last ones. But you can only do that if you know what you're tried so far. Simply trying (for example) each 20 byte value in each 150-300MB memdump at a speed of a few thousands per second (this is the speed of ecdsa... see the problem?) is time consuming. Of course we can try to pinpoint/anticipate where a private key/device key might be but we could be mistaken (and requires a more "hands-on" approach). Therefore the above might not be such a bad idea. The biggest problems with this idea: (a) simply processing one memdump for new possible keys may be timeconsuming (many mem lookups, although some basic randomness checking will speed things up big time) and (b) maybe there will be too many unique values each startup of the Player so the hash table/tree will get too big (you do have to use the same movie and player each time of course). Technically we could even share this stuff but only between people who own the same disc/movie and software player (and since memdumps contain lots of pc/drive identifying stuff it can't really be done publicly). Alternatively maybe some kind of diff between an old dump and a new dump could work but when looking at dumps I'm not so sure they are organized exactly the same each time: looks quite dynamic... So diffs won't work so well. I'm also thinking about releasing a proggy that can check a memdump for a private key so everybody can start trying to find it. What do you think? Regards, arnezami PS. Personally I'm starting to think using a debugger and or altering binaries will be much more useful. But since I'm not experienced with those somebody else will have to try that. I've read somewhere about altering some kind of zeromemory-function (which was called by P DVD many times) so it wouldn't clear its mem. Something like that... I'm using pre-computation, "light" private key checking, fast entropy/randomness detection. So it won't go much faster... Last edited by arnezami; 27th February 2007 at 08:19.

27th February 2007, 21:12	#28 \| Link
BlazingMind Registered User Join Date: Feb 2007 Posts: 19	Debuggers.... I've been following these decryption threads with great interest lately, and I would like to start off by congratulating you all for the progress you have made :-) Good work!!! About debuggers though... There arent really that many people that have access to SoftIce / IDAPro etc. and are capable of using them effectively. Even fewer I suppose, that also has access to HD DVD / BR hardware, software and a movie or two. So... I've been thinking about how the "average" AACS cracker would be able to get some useful data out that later could be interpreted by someone with the right skills with reverse engineering. This is why I would like to suggest that you take a look Cheat Engine and TSearch. Both programs should be able to act as a debugger that should enable you to get to the routines that handle the keys. Let's say you found a sub device key in memory... If you loaded CE and selected "add address manually" and then selected "find out what writes to this address", you should end up with a list of addresses to the actual code that handles the keys. Even if the keys change, these addresses should be static for each build of the software, so it should be far easier to extract more keys by following these routines... (in theory) If you were able to identify the routines that handles the keys, they can again be followed to see where other keys are stored. (find the AES-G algo and I believe you have what you need to get all keys by following the data output from it). ...Just a thought...

28th February 2007, 02:41	#34 \| Link
HyperHacker Resident DRM Hater Join Date: Oct 2006 Location: International waters Posts: 242	If someone wants to buy me an HD-DVD drive, I know how to use a debugger... This is certainly the approach to be taking. Load up your debugger and set a write breakpoint on the memory location that will hold the key, before it's actually there. If you can set it up to break only when a certain value is written, all the better. When you find this write you will be right in the routine that writes the key into memory. From here it'd be easy to make it just give you the key. Since patching into existing apps is difficult, I'd go a simple route: Simply write the key to some unused memory location, along with some sort of "flag" byte. Another program can be written that will watch this memory region, and when the flag byte appears, read the key. This avoids the need to hack in a bunch of code to write the key to a file or what have you, and is more reliable than simply telling the other app where the key is being written already, since this could be overwritten later. Once you can do this you can write a program that will launch the player, apply this hack in memory, wait for the user to load a movie, and read the key out. All they'd have to do is run the program (it could even launch the player for them ). __________________ Because Moogles pwn. Last edited by HyperHacker; 28th February 2007 at 02:42. Reason: spelling

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

27th February 2007, 03:02	#22 \| Link
jokin Dwight Schrute's homeboy Join Date: Jan 2007 Location: The Office Posts: 136	My memory dumps have been 300 MB or so.

27th February 2007, 22:57	#31 \| Link
arctor Registered User Join Date: Jan 2007 Posts: 7	Another option is too have a look in AnyDVD for the private key. If they are using the PowerDVD 6.5 private key we may be able to grab this from AnyDVD. Strikes me that it may not be as well protected as WinDVD and PowerDVD. Plus there is almost a sense of irony of hacking AnyDVD

1st March 2007, 03:41	#40 \| Link
ffguy Registered User Join Date: Feb 2007 Posts: 2	I am not a crypto expert by any means, just an interested programmer. Given enough of the keys, one could theoretically figure out the master key used to generate them all by guess-and-check, correct? It wouldn't be fast, but it could be theoretically done. I ask because I have several computers with nothing to do. By splitting the potential solution space into many many parts, people like me with too much time on their hands could start chipping away at the problem. Divide the solution space and start handing out slots, if not to find the key than to verify where it is not.