View Single Post
Old 2nd March 2007, 11:22   #58  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
Ok. Let me clarify some stuff. It looks like I haven't been very clear about the Host Private Key.

First off the Volume ID is retrieved (not calculated). The Private Host Key is only used as a "passport" to let the drive give you the information it normally wouldn't give away (like the Volume ID).

Device/Processing/Media Keys have nothing to do with this process. Its a completely separate part of AACS. And I admin the gray box is a bit obscure and confusing. Sorry about that.



What's in the gray box? Basicly this:



and this:



The above is the communication between Software Player (=Host) and drive.

What is very clear is that first the AACS-auth communication is done (the picture with the Hpriv in it) and after that the Volume ID is retrieved (the last picture). However when the volume ID is retrieved the Hpriv is long gone (its not in memory anymore).

What I have done is halt the player the very moment the Hsig (or Hv) gets into memory. Since the Hsig is the result and the Hv is part of the input of the ECDSA signing function (for which the player needs the Host Private Key!) this was my best bet at finding the Private Key. But its already gone. It looks like i'm a few ms too late... (btw I always see both the Hv and the Hsig in mem which is a problem, indicating I might be looking at a copy of the Hv and Hsig)

This is the problem I am facing: how to stop the player at just the right time. I've tried to stop it just before and just after the signing function but no luck yet. It keeps slipping through my fingers .

I've also thought about this: in order for the player to sign it first has to SHA1-hash the "message" it wants to sign: this "message" is: Dn || Hv (the || simply means they are concatenated or "glued" together: Dn = 20 bytes, Hv = 40 bytes, resulting "message" = 60 bytes, and of course the SHA1-hash of this "message" is 20 bytes). Technically the hashing is part of the ECDSA signing process/function so its ideal as a marker. But this hash is not in any of my memory dumps (and btw its always different so its not very easy to check). But if I could find it in memory its quite likely the Private Key will also be in memory. But in order for this to work I need to be able to guess where this SHA1-hash is going to be written in memory so I can scan that area on-the-fly. This is what I'm currently working on.

Hope that helps to clarify it a bit.

Regards,

arnezami

PS. Of course me being able to find the private key also hinges on the fact that my private-key-identifyer is working correctly...
PPS. I'm also believe i'm having a practical problem: my GetMemoryAddressFromPattern function (link) doesn't seem capable of looking at the entire memory: it doesn't appear to be able to find patterns that are in the further portions of memory (those areas I can see using a WinHex dump). I'm not sure what "further" exactly is here. If somebody can give suggestions to solve this please do. The function uses lpMaximumApplicationAddress which seems to be correct.

Last edited by arnezami; 2nd March 2007 at 12:27.
arnezami is offline   Reply With Quote