AACS Keys - A program revealing all AACS Keys needed to decrypt (HD DVD and Blu-ray)

[Oopho2ei]

Eventually, I'm sure that open source projects like MPlayer will have the ability to playback complete HD disc structures, but it may not be for a year or two or more...
I have like 20 hd-dvds/blue rays and they all playback nicely with mplayer (for months!). The parameters are sometimes a bit weird for linux noobs but it works.
Example for Spy Game with eac3 sound:
mplayer -demuxer lavf -ac ffeac3 -fps 24000/1001 -aid 5 FEATURE_1.EVO

my config:
cat .mplayer/config
# Write your default config options here!

lavdopts=fast=1:threads=2
vo=xv

Version: 1:1.0.rc2svn20080531-0.1

No patch or whatever is needed. Also you only need to specify those parameters if you encounter problems (like no sound/av sync/...)

---------

What i originally wanted to ask: Does anyone have a valid certificate/privkey for aacskeys? I can sniff the host_cert and host_nonce without any problems but don't have any corresponding host_key for the signature :/

[Turtleggjp]

mplayer -demuxer lavf -ac ffeac3 -fps 24000/1001 -aid 5 FEATURE_1.EVO

This was my point. You are not playing the disc structure, you are simply playing the main movie file, which I will agree should work just fine. You just don't have the menu system and probably not chapters either. I can open the VIDEO_TS.IFO file of a DVD with Media Player Classic, and it will play with menus and chapters. As far as I know, playback like this with HD discs is not possible with mplayer or Media Player Classic.

[Oopho2ei]

Could we please have a parameter for aacskeys which allows to skip authentication in the next version? I have patched my firmware of my PX-920SA (compatible with GGW-H20L). :)

[fpga]

@setarip_old: I just built the computer and i wanted to put in a blu-ray drive at time of build. I figured there would be a way to make it happen, even if it takes a few weeks or months and some work on my part. if its absolutely impossible to do on linux then i can always dual boot with windows but, i'd prefer not to have to do that.
I don't know how well some of the Windows DVD programs (like AnyDVD) will work since they are likely operate at a pretty low level, but you might give Wine a try (allows running Windows programs from within Linux).

[KenD00]

Could we please have a parameter for aacskeys which allows to skip authentication in the next version?

Regarding what you have posted here (http://forum.doom9.org/showthread.php?p=1159131#post1159131) this isn't just skipping the authentication process but an own form of "authentication". Current aacskeys is some sort of intelligent and detects if the xbox drive is present and then uses the xbox hack rather the ACCS way, so this would be the preferred way. What firmware string does aacskeys report when using your custom firmware? Maybe i can find some time and integrate this new "hack" ;).

:rolleyes:

[Oopho2ei]

Regarding what you have posted here (http://forum.doom9.org/showthread.php?p=1159131#post1159131) this isn't just skipping the authentication process but an own form of "authentication".
I commented out the part between "agid = report_agid(h, bluray); + error handler" and "errnr = read_vid(h, agid, volume_id, mac, bluray);" as well as the following "calculate_volume_id_mac() + error handler". That works fine.

Current aacskeys is some sort of intelligent and detects if the xbox drive is present and then uses the xbox hack rather the ACCS way, so this would be the preferred way. What firmware string does aacskeys report when using your custom firmware?
I haven't changed the firmware string so it can't be distinguished from the original firmware looking at the return of inquiry. It only behaves differently when executing the cmdAD/80 handler.

Maybe i can find some time and integrate this new "hack" ;).
The easiest way to do it is just executing read_vid() right after "report_agid() + error handler" and see if it succeeds. Only if it doesn't perform the usual authentication.

[KenD00]

Today i'm proud to present a new version of aacskeys. Along the usual bugfixes it has these new features:

Changed CLI, options are now passed the usual -option style
Given parameters are checked and errors are reported
You have the option to choose how the Volume ID should be retrieved
The XBox hack is used automatically for the Toshiba SD-H802A drive
Can use the recently discovered way to get the Volume ID from patched drives

The archive contains precompiled executables and libraries for Windows and Linux (32 bit and 64 bit) and the source code. The linux versions are now statically linked against OpenSSL, this hopefully solves the problems people had where OpenSSL couldn't be found.

Known issues: If you try to decrypt a MKBv4 or later disc it can happen that aacskeys seems to hang (in verbose mode it doesn't continue after it prints out the current directory) and produces 100% CPU load. I currently don't know excactly why this happens, it looks like that it comes from crypto code that fails because there is no processing key for this MKB version present. I remember people saying they would release a new processing key but want to keep the "community" one step behind Slysoft.. well, AFAIK Slysoft is at MKBv7...

Grab aacskeys 0.3.0 here (the zip and tar.gz have the same content):
aacskeys 0.3.0 (zip, Rapidshare) (http://rapidshare.com/files/132033106/aacskeys-0.3.0.zip.html)
aacskeys 0.3.0 (zip, Sendspace) (http://www.sendspace.com/file/n5c5ut)
aacskeys 0.3.0 (tar.gz, Rapidshare) (http://rapidshare.com/files/132033650/aacskeys-0.3.0.tar.gz.html)
aacskeys 0.3.0 (tar.gz, Sendspace) (http://www.sendspace.com/file/xcyyye)

:rolleyes:

[derbeDeus]

Excelent work :)

I see that aacskeys still tries to load /AACS/VTKF000.AACS. That will fail for some discs that don't have the file and start their title file counting not with 000; eg. Pan's Labirinth (VTKF001.AACS is the first), Terminator 2[DE] (VTKF080.AACS).

Another thing, host_key_point can be calculated from host_key and G on EC using a function like aacs_calculate_bus_key (Figure 4-6, page 32 in AACS spec).
And it would be cool if (priv_key, host_cert) pair could be read from a file, just like device/processing keys. What do you say about this? :)

[KenD00]

I thought about that numbering thing, DumpHD does it already but i haven't heard any complaints about aacskeys not doing it (until now ;)), so i haven't implemented that. The whole file I/O stuff is still quite messy and unsafe, i wanted to move that code to C++ too, especially because i really wanted to read the Host Cert / Priv Key from file too, but i still haven't found the time yet.

Yeah, i wondered why he doesn't calculate the host nonce and uses a precalculated one, then i looked into the spec and thought "oh shit, too much math *g*". The crypto code is also messy and i honestly don't understand much of it right now. The OpenSSL doc is also not very complete so i don't know if and when i will touch that part.

:rolleyes:

[Oopho2ei]

It seems to work. Well done!
Now we need more people working on the players to get new key material. They are using advanced rootkit techniques to corrupt the system. It's quite a challenge. Those people who have experiences with Themida should probably have a look at windvd :)

[kkloster21]

@fpga: I'm wondering if i could use AnyDVD or some other program in Windows (or even in Wine) to get the VUKs of the discs that i own and then populate the KEYDB.cfg database with those keys and just watch them in linux on mplayer (i know i can watch blu-rays in linux if i have the VUK or some key). Would this be possible? Or i guess the real question is: is there a program like aacskeys for windows that will actually show the decrypted keys for blu-ray discs up to MKBv7 (or whatever the latest is)? does AnyDVD actually output the keys?

[gioowe]

AnyDVD doesn't output VUKs. And there's currently no other program that can handle MKBv4, MKBv6 or MKBv7 media. Not no mention BD+.

[Oopho2ei]

afaik AnyDVD contains a long list of those volume unique keys. Yes the vuk is enough for decryption. But you really should try to find them yourself because currently AnyDVD is like a single point of failure for the whole decryption network. If those open source decryption tools can't keep up and AnyDVD gets sued it would be a big blow for the linux blue ray playback support.
Anyway i am trying to get some new key material for aacskeys but this will take some time. So just wait or help.

[kkloster21]

@Oopho2ei: I'd love to help if i am able. I may not have the skill set but i can learn. What are some ways i could help or some things i could start learning to make myself useful? I have a little bit of experience with C.

[Oopho2ei]

Simply choose a player (hardware/software) and start to reverse engineer it. You need to know a lot but there are plenty of documents about this you can study. I don't think you really need to program anything unless you want to write a plugin or inject code in the address space of the process (hooks).

[kkloster21]

can you explain a little bit more what you mean by "choose a player (hardware/software) and start to reverse engineer it." ? Choose a hardware drive and a software player in windows? One or the other? Wouldn't reverse engineering any of that stuff involve looking at code or firmware of some kind? I do have an LG GGC-H20L combo drive that i can start trying things on. I just need to know what to do with it or where to find documentation on what to do. Would it be possible for you to post or PM a few links for some documents that i could study?

[Oopho2ei]

The GGC doesn't contain any device keys. The software player you use to playback your encrypted blue rays has them. Yes it involves looking at the disassembly *lol* among other things. If you are a developer of one of those software players you can use the source code of course. Anyway this is going off topic now. You need to educate yourself.

[zeroprobe]

can you explain a little bit more what you mean by "choose a player (hardware/software) and start to reverse engineer it." ? Choose a hardware drive and a software player in windows? One or the other? Wouldn't reverse engineering any of that stuff involve looking at code or firmware of some kind? I do have an LG GGC-H20L combo drive that i can start trying things on. I just need to know what to do with it or where to find documentation on what to do. Would it be possible for you to post or PM a few links for some documents that i could study?


Look up and master Assembly language then PM him :)

[pjo]

Yes, if your drive has been upgraded to MKBv3 or later this is the way to do it.

Unfortunately your disc seems to be MKBv4 or newer, there is no known Processing Key for these discs so you are currently out of luck (with aacskeys).

To check the MKB version of the disc, open the file AACS\MKB_RO.inf in a hex editor and look at offset 0x08, the next 4 bytes are the version number.

:rolleyes:

Thanks KenD00 !
I appreciate your work on aacskeys.

I am using aacskeys in backupBDAVfor V1 and V3 042.

My question is \AACS\MKB_RW.inf in case of BD-RE,
MKB version is at offset 0x08, the next 4 bytes same as MKB_RO.inf ?

The other question:
If I try to read BD-RE with MKBv7 or v4 and with P-MKB v7 or v4 using a drive whose P-MKB is v1, will the drive is modified to P-MKB v7 or v4 ?

pjo

[KenD00]

Beeing a lazy guy i opened a MKB_RW.inf i found on one of my Blu-Rays with my never released MKBView and it decoded it just fine, so yes, both MKBs have the same structure. And that MKB had also the same version than the MKB_RO.inf MKB on that disc. I also took a quick look at the specs and they don't define an extra MKB for the Recordable Book, there is only one common MKB type.

Your second question is a bit tricky but one thing i can say for sure: if an aacs authentication process is started (e.g. by aacskeys or a software player) the drive will be updated. However, the spec doesn't forbid to update the drive earlier, so i don't know if just putting the disc into the drive will already update it. This may be even different accross different drives.

pjo, i must thank you that you mentioned backupBDAV. This tool sounded unknown to me (good that i haven't checked my HDD, i already had an older version of it) so i googled for it and couldn't believe what i've found. On some sort of japanese website i found something that looked like MKBv4 and MKBv7 Processing Keys. So i gave aacskeys a try with 2 MKBv4 HD-DVDs and it decrypted them and said the VUK is valid?!?!? Next i ran DumpHD on my only MKBv7 Blu-Ray John Rambo and WinDVD played the rip fine!! I can't believe that, the keys are there for almost 5 days now, they are real and this hasn't made big news yet? Anyone knows something about that, theres no info on that site from whom these keys are.

:rolleyes:

[pjo]

Beeing a lazy guy i opened a MKB_RW.inf i found on one of my Blu-Rays with my never released MKBView and it decoded it just fine, so yes, both MKBs have the same structure. And that MKB had also the same version than the MKB_RO.inf MKB on that disc. I also took a quick look at the specs and they don't define an extra MKB for the Recordable Book, there is only one common MKB type.

Your second question is a bit tricky but one thing i can say for sure: if an aacs authentication process is started (e.g. by aacskeys or a software player) the drive will be updated. However, the spec doesn't forbid to update the drive earlier, so i don't know if just putting the disc into the drive will already update it. This may be even different accross different drives.

pjo, i must thank you that you mentioned backupBDAV. This tool sounded unknown to me (good that i haven't checked my HDD, i already had an older version of it) so i googled for it and couldn't believe what i've found. On some sort of japanese website i found something that looked like MKBv4 and MKBv7 Processing Keys. So i gave aacskeys a try with 2 MKBv4 HD-DVDs and it decrypted them and said the VUK is valid?!?!? Next i ran DumpHD on my only MKBv7 Blu-Ray John Rambo and WinDVD played the rip fine!! I can't believe that, the keys are there for almost 5 days now, they are real and this hasn't made big news yet? Anyone knows something about that, theres no info on that site from whom these keys are.

:rolleyes:

Thnaks for your reply.

I mounted MKBv7 BD-RE onto a Panasonic Blueray harddisk recorder which was MKBv1 for sure. now the recorder is V7 !

But I can run BackupBdav 042 which is available on this site.
http://forum.doom9.org/showthread.php?t=125592&highlight=BDAV
with v7 processing key.

It looks like v7 has been on the internet for a few weeks already. I found it in one of a blog(in Japanese language), but it was just a hint, not direct v7.:)

I could not find v4. Pls send personal message on this if it is ok for you.

[SvT]

KenD00 and pjo :)

Thanks for all the hints !

I have the movie Daylight on HD-DVD and it plays fine (SAP and PC) when I load AnyDVD-HD. It wasn't untill today that I noticed it was MKBv4.

"label DAYLIGHT
AACS!
HD type: 0
MKB version 4"

So I tried aacskeys h:

Could not find a Processing Key or Device Key resulting in the Media Key.
Possible key tried: 09F911029D74E35BD84156C5635688C0
Possible key tried: 455FE10422CA29C4933F95052B792AB2

Now I replace my file with the new "ProcessingDeviceKeysSimple.txt" I found thanks to you !

Volume Unique Key: D02FFAE3253D6D41861F3D11643DBE30
TKF Hash (DiscID): 9880EC369B4C8C26C9B7188204D3E5246B8EDCE4

Seems to work great ! So indeed this is BIG news !!! This means all free tools start to work again. Please correct me if I'm wrong.

I think we are looking at the same source because all you find is files and no further info.

Greets

[Oopho2ei]

Awesome! Why don't you post the keys here? Has anyone started working on the virtual machine used in BD+?

[pjo]

KenD00 and pjo :)

Thanks for all the hints !

I have the movie Daylight on HD-DVD and it plays fine (SAP and PC) when I load AnyDVD-HD. It wasn't untill today that I noticed it was MKBv4.

"label DAYLIGHT
AACS!
HD type: 0
MKB version 4"

So I tried aacskeys h:

Could not find a Processing Key or Device Key resulting in the Media Key.
Possible key tried: 09F911029D74E35BD84156C5635688C0
Possible key tried: 455FE10422CA29C4933F95052B792AB2

Now I replace my file with the new "ProcessingDeviceKeysSimple.txt" I found thanks to you !

Volume Unique Key: D02FFAE3253D6D41861F3D11643DBE30
TKF Hash (DiscID): 9880EC369B4C8C26C9B7188204D3E5246B8EDCE4

Seems to work great ! So indeed this is BIG news !!! This means all free tools start to work again. Please correct me if I'm wrong.

I think we are looking at the same source because all you find is files and no further info.

Greets

SvT, Congratulations ! You found it.

pjo

[pjo]

Awesome! Why don't you post the keys here? Has anyone started working on the virtual machine used in BD+?

I heard that several people were copying BD+ ok. But I cannot test it because I do not have BD+ disk.
pjo

[Oopho2ei]

I heard that several people were copying BD+ ok. But I cannot test it because I do not have BD+ disk.
pjo
Nice. Where can i find the source code of those programs?

[pjo]

Nice. Where can i find the source code of those programs?

I do not think the source for this is available.
It looks like it is SlySoft AnyDVD.

[Oopho2ei]

Could we please get some experimental device key support for aacskeys? A seperate plaintext file with a simple format like "KEYDB.cfg" would be sufficient. Also maybe you could include some features of MKBView in verbose mode.

[KenD00]

Aacskeys should already be able to process Device Keys, just put them in the ProcessingDeviceKeysSimple.txt file. And maybe check the source code to see if that crypto stuff makes sense, i currently don't understand it :D.

I wanted at least show the MKB version of the disc, but currently i can't code anything, my main computer broke 2 days ago, seems to be the mainboard. If thats the case, i need to change my whole water cooling for the new one, that will take some time (hopefully not as much as last time :().

:rolleyes:

[gioowe]

aacskeys already handles devices keys. It always did.

[Oopho2ei]

How does aacskeys determine the position of the device key in the tree? According to the spec (3.2.3) there is a path number associated with each device key which determines the path from the root to the position of the node. Without the position i wouldn't know which device key to choose and how to proceed from that node to the processing key. You see my point: that path number isn't stored in the ProcessingDeviceKeysSimple.txt file. I was aware of the fact that the source code already allows the use of device keys but there is just no way to store them other than hacking them into the source code. All keys should generally be stored in a separate file.

[gioowe]

It doesn't - it tries all positions (encrypted c-values).

[Oopho2ei]

It doesn't - it tries all positions (encrypted c-values).
You can try all the c-values if you have a list of processing keys which isn't the case here. One has to select the correct device key of a node which is the root of the subtree which contains the node i need the processing key of. A device key is not a processing key.. maybe that is what you are thinking. Using the device key and the specified hash function (AES-G3) you can calculate the left and right subsidiary device key to go further down in the tree and the processing key for the current node. You never directly use a device key to decrypt a c-value.

[gioowe]

You can try all the c-values if you have a list of processing keys which isn't the case here. One has to select the correct device key of a node which is the root of the subtree which contains the node i need the processing key of. A device key is not a processing key.. maybe that is what you are thinking. Using the device key and the specified hash function (AES-G3) you can calculate the left and right subsidiary device key to go further down in the tree and the processing key for the current node. You never directly use a device key to decrypt a c-value.

You simply use all keys you have, not knowing if it is a device or processing key. First you take the first encrypted c-value and assume your key is a processing key. Check it by decrypting the corresponding verification data. If it's different you go to the corresponding subtree lowest node, go one level up assume your key is now a device key, calc down the tree and verify again. If it still isn't you continue that by going and enumerating all levels up until you are at the top of the subtree. Then you continue with all other c-values and corresponding verification data. And after that you can't use your key and take another one. And do that same procedure again. That's the way aacskey is doing it.

[Oopho2ei]

There seems to be a bug in the linux/amd64 version of aacskeys-0.3. I have added the new keys to the ProcessingDeviceKeysSimple.txt and run from that directory the following commands:
./bin/linux32/aacskeys -v /media/cdrom
This is working and gives the correct result.
./bin/linux64/aacskeys -v /media/cdrom
This doesn't work and it is just looping giving no ouput but the "Current path:" line. There is only one ProcessingDeviceKeysSimple.txt in the directory i am calling these commands from. I have been using the linux/amd64 version with a mkb v1 generation disk without any problems but it fails when i try to get the keys from a mkb v4 generation disc.

mkb: http://uploaded.to/?id=yurqxj

gioowe: ok, i will try it. But it would be strange that the specification demands storing redundant data. Maybe that "brute force" search implemented in aacskeys as you described it cannot be realized easily in licensed players.

[gioowe]

Licensed players know their device keys position and corresponding subtrees (UV mask). We do not. All publicly available keys are processing keys. Only one device key is known (53BD...) to date and that one lead to PK of MKBv1 (09F9...)

53BD... was actually a subdevice key, the true device key is 86D2...

[KenD00]

@Oopho2ei
This endless loop in the x64 version happens when aacskeys cannot find a processing key. But since the x32 version works with the same ProcessingDeviceKeysSimple.txt the code is more broken than i thought. I will look into this as soon as i have a working machine again.

That "brute force" approach will take longer the more revocations happen, maybe because of that the devices know their uv.

:rolleyes:

[pjo]

Thanks for aacskeys v0.26(BDAV v0.50) new version works for dummy drive !

Using two MKBv7 and P-MKB v7 drives, no need to
run PowerDVD or no need to run USB Inspector.

I am wondering how dummy drive works. Please explain how it works if you would.

pjo

[KenD00]

That version you are talking about is not from me, i even haven't seen that one so i can't help you. Just beeing curious, whats that dummy drive thing doing?

:rolleyes:

[pjo]

That version you are talking about is not from me, i even haven't seen that one so i can't help you. Just beeing curious, whats that dummy drive thing doing?

:rolleyes:

That aacskeys is included in BackupBDAV 050 found in this forum.

I do not know the detail on how dummy drive works but I assume that by using an extra dummy drive (physical BD-R drive) some kind of key is found so that there is no need to run PowerDVD for hammering.

pjo

edit
You can put any disk in the dummy drive. Even blank disk is fine.
This suggests that some kind of key in the dummy drive hardware is read and used in this version of aacskeys.

[Oopho2ei]

I need the following patch to compile aacskeys on my my linux distribution (debian/lenny) with gcc (version 4.3.1):

diff -rupN aacskeys-0.3.0/src/aacs_ecdsa.cpp aacskeys-0.3.0_fixed/src/aacs_ecdsa.cpp
--- aacskeys-0.3.0/src/aacs_ecdsa.cpp 2008-07-24 07:06:58.000000000 +0200
+++ aacskeys-0.3.0_fixed/src/aacs_ecdsa.cpp 2008-08-17 16:09:28.000000000 +0200
@@ -2,6 +2,7 @@

#include <cstdio>
#include <string>
+#include <cstring>

#include <openssl/bn.h>
#include <openssl/evp.h>
diff -rupN aacskeys-0.3.0/src/aacskeys.cpp aacskeys-0.3.0_fixed/src/aacskeys.cpp
--- aacskeys-0.3.0/src/aacskeys.cpp 2008-07-24 08:31:29.000000000 +0200
+++ aacskeys-0.3.0_fixed/src/aacskeys.cpp 2008-08-17 16:10:36.000000000 +0200
@@ -35,6 +35,7 @@
// general
#include <cstdio>
#include <string>
+#include <cstring>
//#include <malloc.h>

/* *** KenD00 start: Added include for variable argument list processing *** */
diff -rupN aacskeys-0.3.0/src/ioctl.cpp aacskeys-0.3.0_fixed/src/ioctl.cpp
--- aacskeys-0.3.0/src/ioctl.cpp 2008-07-24 07:06:58.000000000 +0200
+++ aacskeys-0.3.0_fixed/src/ioctl.cpp 2008-08-17 16:11:42.000000000 +0200
@@ -2,6 +2,7 @@

#include <cstdio>
#include <sstream>
+#include <cstring>
#include <iomanip>


diff -rupN aacskeys-0.3.0/src/mmc.cpp aacskeys-0.3.0_fixed/src/mmc.cpp
--- aacskeys-0.3.0/src/mmc.cpp 2008-07-24 07:06:58.000000000 +0200
+++ aacskeys-0.3.0_fixed/src/mmc.cpp 2008-08-17 16:12:21.000000000 +0200
@@ -1,6 +1,7 @@
#include "mmc.h"

#include <string>
+#include <cstring>
#include <cstdio>

#define CDB_SIZE 16


Otherwise i get errors like: aacs_ecdsa.cpp
src/aacs_ecdsa.cpp: In function ‘int aacs_calculate_bus_key(unsigned char*, unsigned char*, unsigned char*, unsigned char*)’:
src/aacs_ecdsa.cpp:330: error: ‘memcpy’ was not declared in this scope

copy the file in the root directory of aacskeys and use patch -p1 < patchname.diff

Maybe you can fix this in the upcomping new release too :thanks:

[FoxDisc]

Licensed players know their device keys position and corresponding subtrees (UV mask). We do not.

Why don't we know the UV mask? Doesn't each PK have a corresponding UV number? Doesn't each C-Value correspond to a single UV number? Once you find a PK that decrypts a C-Value, you know the matching UV. Or am I missing something?

[Peer van Heuen]

Why don't we know the UV mask? Doesn't each PK have a corresponding UV number? Doesn't each C-Value correspond to a single UV number? Once you find a PK that decrypts a C-Value, you know the matching UV. Or am I missing something?

No, you're not.

[Oopho2ei]

Why don't we know the UV mask? Doesn't each PK have a corresponding UV number? Doesn't each C-Value correspond to a single UV number? Once you find a PK that decrypts a C-Value, you know the matching UV. Or am I missing something?
I think that is correct but we were actually talking about device keys and not processing keys. But because the processing key is derived from exactly one device key and that "path" is known you would get this position as well. If more people would help reverse engineering we wouldn't even have to bother about this and could instead use the stored values.

[FoxDisc]

we were actually talking about device keys and not processing keys. But because the processing key is derived from exactly one device key and that "path" is known you would get this position as well.

Agreed. The reason I asked, was that I had assumed that each time a PK (or DK ) was identified that its matching uv number would be associated with it and stored somewhere. Then the correct c-value could be identified using the same basic procedures described in the AACS docs. You'd just find a c-value with a matching u number for your PK and a v-number that is not below the PK's v-number. (Clearly, you can start with either the list of c-values or the list of known PKs.)

If more people would help reverse engineering we wouldn't even have to bother about this and could instead use the stored values.

I miss the excitement of the early days of discovery (not that I did anything other than watch and try to follow the technical details). With a smile, I have to blame Peer in part. He's really too good. I suspect the payoff for discovery is a lot less when Peer's in the lead.

[Peer van Heuen]

I miss the excitement of the early days of discovery (not that I did anything other than watch and try to follow the technical details). With a smile, I have to blame Peer in part. He's really too good. I suspect the payoff for discovery is a lot less when Peer's in the lead.

*blush* :)

[KenD00]

This new release is mainly a bugfix, i hope it fixes all the problems of the previous one. Beeing to lazy to write it a second time, i copy the changelog from the README:

- Fixed to run correctly under 64 bit
- Detects if the given mountpoint is a symlink and handles it correctly (Linux)
- Accepts mountpoints with a trailing "/" (Linux)
- Uses the Title Key file with the lowest number if VTKF000.AACS isn't present
(HD-DVD Advanced Content)
- Displays version of MKB
- New option --no-preinval to disable invalidation of all AGIDs before
requesting a new one
- Added missing includes to avoid compilation errors on some machines
(thanks Oopho2ei)
- Lots of small fixes to avoid buffer overruns and null pointers


As usual, the archive contains precompiled binaries / libraries for linux (32 bit and 64 bit), windows and the source code, the zip and tar.gz have the same content.

Get them here:
aacskeys 0.3.1 (RapidShare, zip) (http://rapidshare.com/files/141253835/aacskeys-0.3.1.zip.html)
aacskeys 0.3.1 (SendSpace, zip) (http://www.sendspace.com/file/bps0f4)
aacskeys 0.3.1 (RapidShare, tar.gz) (http://rapidshare.com/files/141255292/aacskeys-0.3.1.tar.gz.html)
aacskeys 0.3.1 (SendSpace, tar.gz) (http://www.sendspace.com/file/5acnol)

:rolleyes:

[Oopho2ei]

Thanks a lot for the corrections. :)

[KenD00]

This new release has one big new feature: Blu-Ray Recordable support (BDMV and BDAV type) :).
From the changelog:

0.3.5: 2008-09-20
- Experimental Blu-Ray Recordable support (BDMV and BDAV)
- New option --pa-lba (currently this must be used with Blu-Ray Recordables if the Binding Nonce is not given on the command line)
- The Host Private Key and Host Certificate is now loaded from the external file HostKeyCertificate.txt
- Diplays more information about the drive and inserted disc
- Fixed an endianess problem

The whole recordable stuff isn't tested because i don't have any AACS protected recordings, so please test this feature and report back if something isn't working. The processing of recordables isn't fully automatic as for the other disc types because aacskeys hasn't an UDF parser integrated. This will maybe change in a later release if i find a suitable parser or have written an own one.

As usual, the archive contains precompiled binaries / libraries for linux (32 bit and 64 bit), windows and the source code, the zip and tar.gz have the same content.

Get them here:
aacskeys 0.3.5 (RapidShare, zip) (http://rapidshare.com/files/146916519/aacskeys-0.3.5.zip.html)
aacskeys 0.3.5 (RapidShare, tar.gz) (http://rapidshare.com/files/146917858/aacskeys-0.3.5.tar.gz.html)
aacskeys 0.3.5 (SendSpace, zip) (http://www.sendspace.com/file/6frubx)
aacskeys 0.3.5 (SendSpace, tar.gz) (http://www.sendspace.com/file/gmkix8)


If none of the automatic modes to retrieve the Volume ID / Binding Nonce works for you, try the following utilities to sniff them from the bus (works only under Windows and requires a licensed software player):

For Volume ID: DumpVID Package 0.31
DumpVID Package 0.31 (RapidShare) (http://rapidshare.com/files/100373276/dumpvidpkg_0.31.zip.html)
DumpVID Package 0.31 (SendSpace) (http://www.sendspace.com/file/n6wely)

For Binding Nonce: DumpBN 0.31 (from BackupBDAV 0.50)
DumpBN 0.31 (RapidShare) (http://rapidshare.com/files/147507385/dumpbn-0.31.zip.html)
DumpBN 0.31 (SendSpace) (http://www.sendspace.com/file/9kznpr)

:rolleyes:

[Adub]

Dude, you are awesome!! Always know that your work is appreciated!! Quick question, what MKB version are we up to now?