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. |
|
|
Thread Tools | Search this Thread | Display Modes |
17th April 2009, 18:03 | #421 | Link | ||||
Registered User
Join Date: Jan 2007
Location: Internet
Posts: 378
|
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:
Quote:
Quote:
Quote:
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. |
||||
17th April 2009, 20:58 | #422 | Link |
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. |
18th April 2009, 04:24 | #423 | Link |
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. Last edited by Rupan; 18th April 2009 at 04:39. Reason: correction to attached patch & suggestion for |
11th June 2009, 11:12 | #426 | Link |
Registered User
Join Date: Dec 2008
Posts: 1
|
works fine.
__________________
Brand Name Watches armani watches guess watches Michael Kors watches Dolce and Gabbana watches |
11th July 2009, 20:18 | #427 | Link |
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..... |
12th July 2009, 18:50 | #428 | Link | ||
Registered User
Join Date: Jan 2007
Location: Internet
Posts: 378
|
Quote:
Quote:
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. |
||
15th July 2009, 18:03 | #429 | Link |
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) |
30th August 2009, 17:20 | #430 | Link |
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. |
5th September 2009, 01:05 | #433 | Link |
Registered User
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... |
5th September 2009, 03:50 | #434 | Link |
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. |
9th September 2009, 00:06 | #438 | Link |
Registered User
Join Date: Mar 2009
Posts: 7
|
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. |
9th September 2009, 05:52 | #439 | Link | |
Registered User
Join Date: Jan 2007
Location: Internet
Posts: 378
|
Quote:
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. |
|
10th September 2009, 00:05 | #440 | Link | ||
Registered User
Join Date: Mar 2009
Posts: 7
|
Quote:
Quote:
|
||
Thread Tools | Search this Thread |
Display Modes | |
|
|