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

[KenD00]

A bit later than announced, but here it comes, a new aacskeys release. It has a great new feature, its running under Mac OS X now.

First a big thank you to yukiyuki for sending me his initial Mac OS X patch, without his work i probably would never have taken the time to port aacskeys to Mac OS X.

Due to the nature how Mac OS X handles low level I/O operations there are some remarks and open issues. aacskeys can use 2.5 paths to communicate with the drive. First it can use exclusive access to send commands to the drive, this has some drawbacks however so this needs to be enabled explicit by using the command line switch --exclusive-io. You can't get exclusive access easily because Finder will grab the drive when a disc gets inserted, to overcome this problem aacskeys unmounts the disc, this requires root rights currently. This has the side effect that as soon as aacskeys releases the drive Finder grabs it again and autorun gets started. This access path provides the same features as aacskeys has under windows and linux, the only benefit of using it is that only this path allows the usage of the XBox hack, there are no other advantages currently.

The non-exclusive path does not have these problems and is used by default. The 0.5 path results from a technical problem. I have tested aacskeys with two drives, a XBox drive and a LG-GGW-H20L. To get exclusive access and to query the drives firmware version and AACS features aacskeys needs to create a driver plugin (CFPlugIn) to communicate with the drive. For some unknown reason it cannot create one for the XBox drive, but everything else works so aacskeys emulates the commands and returns fake data. You can see if this path is used if the reported firmware version is F0BA and the AACS version is 0. I don't know if this happens only because my Mac is virtual, if anyone knows how to solve this problem im open for suggestions.

The archive contains quad universal binaries for Mac OS X, however only the two intel flavors were tested, i don't have access to a non-intel Mac. They should work but i would appreciate it if someone could test them on a non-intel Mac.

Along some smaller bugfixes there are two other new features. On linux full path resolval is implemented, aacskeys now accepts paths with ./, ../, multiple symlinks and relative paths as mountpath. And there is the new command line switch --dump-vid, when this is specified only the Volume ID / Binding Nonce gets retrieved. Useful if aacskeys can't decrypt the MKB but can retrieve the Volume ID / Binding Nonce to display it.


The archive contains precompiled binaries / libraries for Windows, 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.0 (zip) (http://rapidshare.com/files/187908491/aacskeys-0.4.0.zip)
aacskeys 0.4.0 (tar.gz) (http://rapidshare.com/files/187914704/aacskeys-0.4.0.tar.gz)

:rolleyes:

[usr139]

Hi
I am a new user of dumpHD tool.
After a bit of struggle I managed to do my first attempt to dump
a BD disc (die another day).
I get the following error


I have attached the txt file here.
Please help. What am I missing.
I created a file called HostCertificateKey.txt in the dir where I run the dumHD.jar command. In that file, I cut and pasted the Host key valu that I got by running aacskeys.exe command.
THanks for your help.

[Doom9]

looks to me like somebody didn't read the guides.. without a drive + firmware that supports aacs bypass you need to go down the dumpvid route to get the volume id.

[KenD00]

@usr139
There is no need (and its no appreciated) to send me your post you made one day ago as PM. And if you don't understand what Doom9 has written, why do you ask me but not him?

Besides obviously not having read the tutorials linked from the first page of the DumpHD thread you have damaged your aacskeys installation, nowhere was written you should create the HostKeyCertificate.txt file, it is already present in the release! To enable direct key retrieval in DumpHD all you need to do is to copy the files HostKeyCertificate.txt, ProcessingDeviceKeysSimple.txt and the library appropriate to your OS, in your case Windows so aacskeys.dll, into the DumpHD folder.

But as Doom9 already pointed out, the used Certificate has been revoked so aacskeys won't work without additional help. You are in the lucky situation that there is a patched firmware for your drive (can be found in this forum), flash your drive with that one and you are ready to go as long as your discs are < MKBv9.

:rolleyes:

[usr139]

Sorry for the PM.
Thanks for explaining.
I will try again based on your suggestions.
thanks.

[usr139]

Sorry for the PM.
Thanks for explaining.
I will try again based on your suggestions.
thanks.

KenD00 & Doom9:
Thanks for the tutorial(s).
I got it to work!!!

[odin24]

I'm trying to back a disc with MKBv12, is this possible yet... it's been a while since I've used aacskeys. My drive is patched.

aacskeys -v f:

EDIT: Nevermind... I read a bit back... nothing beyond MKBv9.

[evdberg]

I am looking for MKB files of v9 and higher. Can anybody provide these? Thanks in advance!

[kkloster21]

@evdberg:

what files are you looking for? I have plenty of discs that are MKBv9 or above.

[evdberg]

The MKB_RO.inf file.

[setarip_old]

@Odin24

Hi!I'm trying to back a disc with MKBv12, is this possible yet...(Presently FREEWARE) "MakeMKV" is claimed to be able to rip/decrypt (and convert to MKV) BluRay discs with MKBv12.

Perhaps you can try it and report back?

What is the title?

[kkloster21]

I have about 10 of them for you evdberg. check PM.

[Rupan]

Kend00, please review the attached patch. It adds the ability to place aacs key material in a global location. It will also search for the keys in $PWD, but this patch is really needed for widespread adoption.

It might be a good idea to wrap some Windows detection code in somehow, too, and define GLOBAL_KEY_LOC to e.g. C:\bluray\aacs.

**EDIT**

Another WTF! moment... it appears that the JNI implementation in aacskeys actually calls main() -- in the shared library. Hmmmm.

[KenD00]

Another WTF! moment... it appears that the JNI implementation in aacskeys actually calls main() -- in the shared library. Hmmmm.

Yes, the library actually calls main, it starts aacskeys as you would yourself by running the executable, it only enables some additional code that actually populates the object that the java code receives.

When i coded this aacskeys was still developed by arnezami, i needed a way to use his code without "disturbing" his work so that he doesn't need to take care of my needs. Because aacskeys was (and is) a noninteractive command line application with all its functionality basically put into the main method this was the best way. During the time i realized that using aacskeys as library requires a structural redesign to better fit the purpose but i still haven't found the time to do it (and i'm not sure how to do it exactly).

The dependency of the two text files is another problem, especially for the library. I still don't know how to properly realize that in a way that works well for all 3 supported OS. Thanks for your input, but i think hardcoding the paths into the binaries is a not so good solution. While this may work for the *nix variants this is not so nice for the windows version. I'm open for suggestions :).

:rolleyes:

[Rupan]

I think hardcoding is in fact the way to go. This can be done on Windows too, at build time. Set a define to a supported path based on the compiler environment in some global header. This also offers the advantage of a configuration file at some point in the future to fine-tune how libaacs works at runtime.

In addition, this does not remove the ability for the user to have the key file in the corrent directory. It simply adds an additional path to search rather than breaking the old behavior. These two reasons are enough to add in support. The patch I uploaded is a good start but does not implement Windows compatibility. This would, however, be trivial to add.

As far as a structural redesign for main(), on a high level it is simple:
*wrap main() in an ifdef and exclude it when the code should be linked as a shared library (detection can be trivially implemented in the build system)
*only parse command-line arguments in main(), and move the rest of the code into startup_aacs()

If there is simply too much data that must be transmitted from main to aacs_startup, define a structure to hold it all and pass that in.

My next bit of work is to reimplement trap_Sha in libbluray so that it (1) uses Gladman's SHA code and (2) handles interleaved calls. After I complete that I'll have another crack at this patch.

[blutach]

@drfix - please stop cross posting this request. Read rule 8.

Regards

[kyoshiro378]

Hi
I am a new user of dump vid and aackeys
anybody can me how to use this tool.

[KenD00]

This is a repack of aacskeys 0.4.0 which now contains the latest Processing Keys (MKBv9 and MKBv10), nothing else has been changed. If you have already aacskeys 0.4.0 and the MKBv9 and MKBv10 Processing Keys there is no need to download this release.

The archive contains precompiled binaries / libraries for Windows, 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.0a (zip) (http://rapidshare.com/files/220830187/aacskeys-0.4.0a.zip)
aacskeys 0.4.0a (tar.gz) (http://rapidshare.com/files/220832866/aacskeys-0.4.0a.tar.gz)

:rolleyes:

[Rupan]

Kend00:

This is an updated version of the aacskeys global configuration patch that handles both Windows and Linux. HostKeyCertificate.txt and ProcessingDeviceKeysSimple.txt are searched for in the following order:

If your platform is Windows, look in C:\bluray\aacs
If your platform is Linux, look in /etc/bluray/aacs
If the files are not located in a global location, read them from the current directory.

One things that consistently annoys me about the aacskeys software is the lack of a way to install the software system-wide. This patch does not break current behavior, it only supplements existing functionality. Now I can install libaacs in /usr/lib and aacskeys in /usr/bin and have it work regardless of the content of $PWD. Kend00, please accept and commit the attached patch.

BTW, congrats on the v9 and v10 processing keys! I just tested them on "The X-Files: Fight the Future" and they work perfectly.

[Rupan]

@Kend00:

I'm working on aacskeys this week as I find time. 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've also defined a structure that will hold all user-supplied runtime information, which will be passed to aacs_main(). It isn't ready to see the light yet, but it is coming along nicely. 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...

[KenD00]

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.


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.


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.


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).


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 :D.

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.

:rolleyes:

[dirio49]

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/forums/t346548-how-to-find-windows-quotapplication-dataquot-directory.html


hope it help.
but you could also ask the user where he want to install.

[Rupan]

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.

[wingman1659]

I get an error when running it. Using Vista x64

error: could not open file: (directory)\ProcessingDeviceKeysSimple.txt

[dirio49]

download and an zip the files in the same folder.
that file is in the zip.
later

[whatadeals]

works fine.

[drkrvn32]

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.....

[KenD00]

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.


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.

:rolleyes:

[KenD00]

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) (http://rapidshare.com/files/255993578/aacskeys-0.4.0b.zip)
aacskeys 0.4.0b (tar.gz) (http://rapidshare.com/files/256152839/aacskeys-0.4.0b.tar.gz)

:rolleyes:

[KenD00]

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) (http://rapidshare.com/files/273471735/aacskeys-0.4.0c.zip)
aacskeys 0.4.0c (tar.gz) (http://rapidshare.com/files/273476005/aacskeys-0.4.0c.tar.gz)

:rolleyes:

---- moderator note ----

The above links are dead, you can now find the download at cyberside (http://cyberside.net.ee/ripping/BD_DeviceKeys/).

[FirstBorg]

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.

[880]

That means that the disc is too new; it uses MKB version 11 or later.

[setarip_old]

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...

[KenD00]

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.

:rolleyes:

[FirstBorg]

Is it possible to find out what MKBv is used on a certain disc?

[880]

AACSKeys will tell you.

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.

[FirstBorg]

Ah yes, my Top Gun BD (German Version) has MKBv 12.

[bvc2068]

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.

[KenD00]

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.

:rolleyes:

[bvc2068]

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... :)

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.

[denret]

I've been trying to get this program to run, but can't get past error message: "Could not open file c:\\ProcessingDeviceKeysSimple.txt Error: Process MKB, error: -1
when I attempt to run from the command function.

My aacskeys folder is under my C: directory and the above mentioned txt file is directly under the aacskeys folder, not under a sub folder. Based on what I've seen in the forum archives, that is correct. Confused???

Can anyone enlighten me??

[880]

Change directory to the aacskeys folder first. Then run the exe.

[denret]

Thank you for your prompt response. However, I'm still confused as to where to put the text file. Here's the file config I've presently got:

Local Disk (C:)
aacskeys-o.4.0 (folder)
bin (folder)
win 32 (folder)
aacskeys.exe (app file)
ProcessingDeviceKeysSimple (text file)

My command line from the C prompt in DOS is as follows:

c:\aacskeys-0.4.0\bin\win32\aacskeys.exe e

Where the last e is the drive. When I run this command, I get the error message in my last message. What am I doing wrong here??

[880]

you didn't use the cd command
cd c:\aacskeys-0.4.0\bin\win32\
aacskeys.exe e

[denret]

Heres exactly what I typed after opening the command screen:

CD C:\ (to change to the C: prompt)

Now I'm at the C: prompt and I typed:


aacskeys-0.4.0\bin\win32\aacskeys.exe e

Is this wrong....

Thanks

[KenD00]

aacskeys looks for the Processing Key file and the Host Certificate file in the current working directory, thats the directory from where you issue the command. In your example this is C:\, apparently this is not the directory where these files reside, they are in aacskeys-0.4.0, so you have to change into that directory first.

Your steps should look like this:

C:\Users\KenD00> cd c:\aacskeys-0.4.0
C:\aacskeys-0.4.0> bin\win32\aacskeys e

:rolleyes:

[HOGGER]

I had the same issue http://forum.doom9.org/showthread.php?t=149727
Place the ProcessingDeviceKeysSimple.txt here C:\ ProcessingDeviceKeysSimple.txt right where the error is telling you it's missing and ALSO the same folder as aacskeys .exe and all will be well

[880]

I had the same issue http://forum.doom9.org/showthread.php?t=149727
Place the ProcessingDeviceKeysSimple.txt here C:\ ProcessingDeviceKeysSimple.txt right where the error is telling you it's missing and ALSO the same folder as aacskeys .exe and all will be well

That's unnecessary if you're smart enough to cd to the aacskeys folder before you try to run it. :rolleyes:

[denret]

Thanks KenD00 for the feedback.

Yes, by using your syntax, I can get the command file to work. However, now I'm getting an error message "c:\aacskeys-0.4.0\bin\win32\aacskeys.exe is not a valid Win32 application."

I've also noticed that when I click on the aacskeys.exe file from Windows, I also get the same error message. It seems to me that earlier when I did that, I got a flash of the Command file on the screen. Not sure whats up all of sudden. Maybe I should delete and reload aacskeys files?

[HOGGER]

That's unnecessary if you're smart enough to cd to the aacskeys folder before you try to run it. :rolleyes:

Either way will work, I had typed the command so much trying to get it to work
I eventually got lazy and cut and pasted the path in command prompt and than ran the exe
Guess that is where I made my mistake