Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > General > Decrypting

Reply
 
Thread Tools Search this Thread Display Modes
Old 17th April 2009, 18:03   #421  |  Link
KenD00
Registered User
 
Join Date: Jan 2007
Location: Internet
Posts: 378
Quote:
Originally Posted by Rupan View Post
If your platform is Linux, look in /etc/bluray/aacs
Ok, you convinced me that this is necessary, but regarding the unix directory structure i would propose another location, either /etc/aacskeys or, because these files aren't configuration files but more some kind of data files, /usr(/local)/share/aacskeys.

Quote:
If your platform is Windows, look in C:\bluray\aacs
This is not the windows way and i really hate applications which install themselves on c: . Either take the files from the application directory (which is a little tricky when using the library, how can it figure out the directory it is executed from?) or use the Application Data directory under Documents and Settings. I currently don't know how to query these locations but i will look into this later.

Quote:
Originally Posted by Rupan View Post
My current focus is on moving the command-line parsing routine out of main, into a new main() then renaming main() to aacs_main().
I always wanted to convert the code more to c++ but never found the time for this. The main logic is still all in main(), its a first step to move this to another location and make main() "dumb" and let it only initialize the program.

Quote:
I've also defined a structure that will hold all user-supplied runtime information, which will be passed to aacs_main().
This is a c approach and i don't encourage this, i prefer c++, the code isn't c conform already and i already started with that (see ioctl files).

Quote:
Do you have any suggestions as to how to deal with nonfatal errors and status messages? If it is to function as a library these must go away. Maybe I can redirect them to a log file...
Well, i would/want to split the code into multiple smaller function units that can be called externally, like getting the VID, decrypting the MKB and so on and use error codes or exceptions that the caller needs to evaluate. However, this way the caller needs to know what to do, maybe it's still possible to use one method that does it all and use a big list of error codes so that you can still figure out in detail what failed.

A library doesn't need to output status messages itself, if you want that information (e.g. MKB version, etc) provide methods for this and the caller has to query that information and display it. The current "library" just executes the program, this is the main problem and should be changed. But i'm still not sure how to do this without writing double code just to do the same things one time in the main program and the second time in the library. Oh well, i could put #ifdef's around every printf .

I'm currently not working on aacskeys because i'm spending my time on the BDVM/BD-J connection so a new aacskeys release will take some time.

KenD00 is offline   Reply With Quote
Old 17th April 2009, 20:58   #422  |  Link
dirio49
JuSt a PoWer uSEr
 
Join Date: Mar 2005
Location: None of your Business
Posts: 288
i agree with KenD00. writing stuff on C:\ is horrible
Appdata is better.
usually you can just type %appdata% on the run command that will take you to the appdata folder.
or you can read registry HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

This might help
http://www.velocityreviews.com/forum...directory.html


hope it help.
but you could also ask the user where he want to install.
__________________
Birthdays are good. Statistics show that the people who have the most live the longest.
dirio49 is offline   Reply With Quote
Old 18th April 2009, 04:24   #423  |  Link
Rupan
Registered User
 
Join Date: Nov 2008
Posts: 62
library (try 1)

Here is the sum of my current work thus far. I am posting it because I don't think I will have time to work on aacskeys in the near future and I don't want work duplicated. The changes currently suffer from the following drawbacks:

1) I'm not a Windows programmer, and hope I will never be. As a result, the Windows compatibility code is probably horribly wrong and may not even compile. I don't have any way to test it, and am relying on MSDN's online documentation.

2) Braindead Windows doesn't have getopt(). Go figure. Some drop-in replacement will have to be found. A quick google search reveals a couple of implementations, but their licenses are incompatible with aacskeys. I hear GNU has a portable getopt, but I haven't invested the time to find it.

3) The code isn't necessarily all that clean or correct. I put it together as a test, so please don't bash me on coding practices. Its pre-pre-pre alpha quality, and only meant as a starting point for the real implementation.

4) get_appdata_dir() does introduce a memory leak. It is easy to fix, but I've run out of time for at least this week.

5) Currently aacs_main() copies values from the passed structure into internal variables. This isn't the correct way to do it; the correct way would be to write bit test macros and replace all occurrences throughout the code. Again, I'm short on time.

6) probably lot of others....

The code changes compile and run on my machine, which runs 64-bit Linux. They appear to work perfectly, but the only thing I'm willing to commit to right now is that they work fine on my own personal desktop.

The license for this patch is GPL2 or any later version, at your discretion.

EDIT:
I forgot that C++ enforces typecasting so strictly. Line 1245 of aacskeys.cpp must be changed to this:
char *path = (char *)malloc(_MAX_PATH);
from this:
char *path = malloc(_MAX_PATH);

EDIT2:
I suggest that aacs_main() be split out into component functions. the real main(), the one that is for compilation as a standalone application, should parse the config options and call all of these component functions. All error printouts should be moved into main(). Compilation of main() can be conditional, depending on whether it is built as a library or application. Application developers should read the documentation and handle invalid return values gracefully in their software.
Attached Files
File Type: txt library_try_1.diff.txt (13.3 KB, 509 views)

Last edited by Rupan; 18th April 2009 at 04:39. Reason: correction to attached patch & suggestion for
Rupan is offline   Reply With Quote
Old 23rd April 2009, 21:57   #424  |  Link
wingman1659
Registered User
 
Join Date: Feb 2009
Posts: 1
I get an error when running it. Using Vista x64

error: could not open file: (directory)\ProcessingDeviceKeysSimple.txt
wingman1659 is offline   Reply With Quote
Old 24th April 2009, 17:05   #425  |  Link
dirio49
JuSt a PoWer uSEr
 
Join Date: Mar 2005
Location: None of your Business
Posts: 288
download and an zip the files in the same folder.
that file is in the zip.
later
__________________
Birthdays are good. Statistics show that the people who have the most live the longest.
dirio49 is offline   Reply With Quote
Old 11th June 2009, 11:12   #426  |  Link
whatadeals
Registered User
 
Join Date: Dec 2008
Posts: 1
works fine.
whatadeals is offline   Reply With Quote
Old 11th July 2009, 20:18   #427  |  Link
drkrvn32
Registered User
 
Join Date: Jan 2009
Posts: 11
In reply to building on OSX Leopard:

the binary file with .40 works in CLI mode. The library does not work with DUmpHD, it crashes the JVM.
Now, saying this I have the following installed:

openSSL .98k via MacPorts[only way I have gotten this to install correctly]

When I try and compile libaacskeys I run into the same error that everyone else does with EACS?? extensions to openSSL. I'm cluless where to begin to fix it.

I can use the commandline up to MKV10. 12, as we know is still in the works.

Correct me if I'm wrong, but isnt the MKBV info inside the same file as the version header? Obviously its stored on disc somewhere near the AACS files.How difficult is it to use the discs auth against itself? Thats how we managed to break CSS, and usually that's how crypto stuff is cracked.

I'm hardly an expert in drive auth,but the ceasar cypher was broken by the number of occurances [uses per letter]of the english alphabet.Also,once you bust a hash, anything that uses that hash is now cracked. [xb-360 forums]

I hear someone says that only Volume/disc/title keys are in this file, but the MVKB has to be close to these or the set-top boxes couldn't decode the disc.
Maybe we need to start looking at firmwares and set-top firmwares.....
drkrvn32 is offline   Reply With Quote
Old 12th July 2009, 18:50   #428  |  Link
KenD00
Registered User
 
Join Date: Jan 2007
Location: Internet
Posts: 378
Quote:
Originally Posted by drkrvn32 View Post
openSSL .98k via MacPorts[only way I have gotten this to install correctly]

When I try and compile libaacskeys I run into the same error that everyone else does with EACS?? extensions to openSSL. I'm cluless where to begin to fix it.
The macports version of openssl contains everything that the original tarball does, at least the version i have installed (don't remember which), including ECDSA. That was the reason i used this version, because the OSX included one wasn't complete. Post the error message the compiler spits out, maybe i can help.

Quote:
Correct me if I'm wrong, but isnt the MKBV info inside the same file as the version header? Obviously its stored on disc somewhere near the AACS files.How difficult is it to use the discs auth against itself? Thats how we managed to break CSS, and usually that's how crypto stuff is cracked.

I'm hardly an expert in drive auth,but the ceasar cypher was broken by the number of occurances [uses per letter]of the english alphabet.Also,once you bust a hash, anything that uses that hash is now cracked. [xb-360 forums]

I hear someone says that only Volume/disc/title keys are in this file, but the MVKB has to be close to these or the set-top boxes couldn't decode the disc.
Maybe we need to start looking at firmwares and set-top firmwares.....
Honestly, i don't understand what you are saying here. Of course, the MKB file on the disc contains the version number, thats what aacskeys reads and displays. However, this information is only informative for us, it doesn't add anything to the decryption process. Inside the MKB there are the encrypted Media Keys, one of these has to be decrypted with a Processing Key. Every new version of the MKB encrypts the Media Keys with new keys so that we can't decrypt them with our known Processing Keys. So there is no other way then finding new Processing Keys to decrypt new MKBv's.

Second problem is the revokation of certificates, there the version number is important because the drive reads this out to decide if it has to update its revokation lists or not. But this does the drive itself, there is nothing we can do about it.

KenD00 is offline   Reply With Quote
Old 15th July 2009, 18:03   #429  |  Link
KenD00
Registered User
 
Join Date: Jan 2007
Location: Internet
Posts: 378
aacskeys 0.4.0b

This is again a (slightly more than only a) repack of aacskeys 0.4.0, this release adds a precompiled executable and library version for windows 64 bit. While compiling the the new windows target i have also updated the 32 bit windows build to link against OpenSSL 0.9.8k (all other builds are still linked against OpenSSL 0.9.8i).

@Rupan: sorry, i haven't found the time yet to work further on aacskeys

The archive contains precompiled binaries / libraries for Windows (32 bit and 64 bit), Linux (32 bit and 64 bit), Mac OS X (quad universal) and the source code, the zip and tar.gz have the same content.

Download links:
aacskeys 0.4.0b (zip)
aacskeys 0.4.0b (tar.gz)

KenD00 is offline   Reply With Quote
Old 30th August 2009, 17:20   #430  |  Link
KenD00
Registered User
 
Join Date: Jan 2007
Location: Internet
Posts: 378
aacskeys 0.4.0c

And again another repack because i still haven't found the time to work on this but forum member pynux has made a great discovery which hasn't made big news yet as it should.

He has found the Host Certificate/Private Key used by MakeMKV in one of its binaries. I don't know the exact details on how he did it but it doesn't look like Mike Chen has protected it in any way so i've taken the freedom to use it for aacskeys as well. It works for at least MKBv12, i don't know how recent the version was that pynux used so maybe it even works for current MKBv14 titles.

So what do we get from this new Certificate? While we have known Processing Keys for up to MKBv10 we had a Certificate only for MKBv1. With this new Certificate users who don't have a patched drive can finally use aacskeys again without going the painful dumpvid route and everything works automatically again as it should.

The archive contains precompiled binaries / libraries for Windows (32 bit and 64 bit), Linux (32 bit and 64 bit), Mac OS X (quad universal, NOTE: There are reports that the dylib does not work on MacOSX >= 10.5.7, i can't do anything about it right now because i have only MacOSX 10.5.4 running here) and the source code, the zip and tar.gz have the same content.

Download links:
aacskeys 0.4.0c (zip)
aacskeys 0.4.0c (tar.gz)



---- moderator note ----

The above links are dead, you can now find the download at cyberside.

Last edited by foxyshadis; 28th May 2015 at 01:15.
KenD00 is offline   Reply With Quote
Old 4th September 2009, 22:39   #431  |  Link
FirstBorg
Registered User
 
Join Date: Jan 2002
Posts: 110
Hi!
I tried the new version, 0.4.0c to get the key for the top gun bd, and I get the Error:
Could not find a Processing Key or Device Key resulting in the Media Key.
FirstBorg is offline   Reply With Quote
Old 5th September 2009, 00:13   #432  |  Link
880
Registered User
 
Join Date: Jan 2009
Posts: 125
That means that the disc is too new; it uses MKB version 11 or later.
880 is offline   Reply With Quote
Old 5th September 2009, 01:05   #433  |  Link
setarip_old
Registered User
 
setarip_old's Avatar
 
Join Date: Aug 2005
Posts: 16,267
Hi!

The keys for the U.S. version of "Top Gun" are already in the "KeyDB.cfg" file for the BluRay version of "DumpHD".

Also, as noted above by "KenD00", aacskeys 0.4.0c definitely works with MKB 12 and likely MKB 13 and MKB 14, as well...
setarip_old is offline   Reply With Quote
Old 5th September 2009, 03:50   #434  |  Link
KenD00
Registered User
 
Join Date: Jan 2007
Location: Internet
Posts: 378
Ok, once i again i should get some things straight here.

Basically there are two types of information we need to decrypt a disc, its Media Key and its Volume ID to calculate the Volume Unique Key. To get these two entities we need two different cryptographic elements.

First a non revoked Host Certificate and its Private Key to get the Volume ID. The recently found one (thanks Mike Chen and pynux) works for (i'm pretty sure) up to MKBv14, so with this one we can get the Volume ID of discs from MKBv1 up to MKBv14. If some day this one gets revoked (which will happen, i'm pretty sure about this) we can't get the Volume ID from ANY of these discs (this is a form of active revokation) until a new Certificate is found (or we use other ways to get it )!

Second we need a Processing Key to decrypt the Media Key. Currently we have Processing Keys for MKBv1 up to MKBv10. If they "revoke" a Processing Key it simply cannot decrypt new MKB versions but it still can decrypt the old ones (so this is a form of passive revokation). But if we can't get the Volume ID of a disc all our Processing Keys are worthless (see above).

To sum things up the current situation is Volume ID for MKBv14, Media Key for MKBv10, the common denominator is MKBv10, so this is the maximum MKB version we can handle now.

KenD00 is offline   Reply With Quote
Old 6th September 2009, 00:19   #435  |  Link
FirstBorg
Registered User
 
Join Date: Jan 2002
Posts: 110
Is it possible to find out what MKBv is used on a certain disc?
FirstBorg is offline   Reply With Quote
Old 6th September 2009, 02:20   #436  |  Link
880
Registered User
 
Join Date: Jan 2009
Posts: 125
AACSKeys will tell you.
Code:
Current path:                   C:\Documents and Settings\Administrator\
                                Desktop\aacskeys-0.4.0c

MKBv:                           12
Could not find a Processing Key or Device Key resulting in the Media Key.
880 is offline   Reply With Quote
Old 6th September 2009, 13:15   #437  |  Link
FirstBorg
Registered User
 
Join Date: Jan 2002
Posts: 110
Ah yes, my Top Gun BD (German Version) has MKBv 12.
FirstBorg is offline   Reply With Quote
Old 9th September 2009, 00:06   #438  |  Link
bvc2068
Registered User
 
Join Date: Mar 2009
Posts: 7
Quote:
Originally Posted by KenD00 View Post
aacskeys 0.4.0c (tar.gz)[/URL]
I noticed that hddump with aacskeys 0.4.0c would not try to use AACSAUTH even if the "-a" option was specified, as it fell through a "goto exit;" when finding that none of the keys in the db were fitting, before even trying to do the "conventional" AACSAUTH method.

A one-line patch (sorry, not at hand at the computer I'm writing from) to not take that "goto exit" code path fixed it for me, I wonder whether I was the only one to stumble upon this.
bvc2068 is offline   Reply With Quote
Old 9th September 2009, 05:52   #439  |  Link
KenD00
Registered User
 
Join Date: Jan 2007
Location: Internet
Posts: 378
Quote:
Originally Posted by bvc2068 View Post
A one-line patch (sorry, not at hand at the computer I'm writing from) to not take that "goto exit" code path fixed it for me
No, you haven't fixed anything, instead you have broken something that was working fine. There is no need to do AACSAUTH or any other process to get the Volume ID from the drive because you couldn't decrypt the Media Key with any of the Processing Keys. Your "patch" just let it continue to calculate the VUK with whatever crap was left behind in the array for the Media Key after testing the Processing Keys (or you could have gotten a VERIFYDATA error, depending on which goto you are talking about, you haven't given quite detailed information)!

You could have figured this out by yourself by actually trying the VUK or CPS Unit Keys, DumpHD would have told you that it couldn't find a key for any of the M2TS files!

If you really want to get the VID even if you can't decrypt the Media Key use the --dump-vid switch, then you will get the VID of the disc if one of the retrieval methods worked, nothing more.

KenD00 is offline   Reply With Quote
Old 10th September 2009, 00:05   #440  |  Link
bvc2068
Registered User
 
Join Date: Mar 2009
Posts: 7
Quote:
Originally Posted by KenD00 View Post
There is no need to do AACSAUTH or any other process to get the Volume ID from the drive because you couldn't decrypt the Media Key with any of the Processing Keys.
Ah, ok, so I was just misled by the error messages. They aren't too obvious, after all...

Quote:
If you really want to get the VID even if you can't decrypt the Media Key use the --dump-vid switch, then you will get the VID of the disc if one of the retrieval methods worked, nothing more.
Yes, that works as described.
bvc2068 is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 11:16.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.