DumpHD - a HD-DVD / Blu-Ray Decrypter

[KenD00]

Well, i thought that too but that doesn't seem to be the case. I can reproduce the error in Snow Leopard, the file contains all 4 architectures, no broken dependencies but it does not work. I recompiled the latest release under Snow but it didn't change anything.

My current development build does work however, so far i can tell the biggest difference is that it doesn't use OpenSSL anymore. I know i had some problems to get it work with OpenSSL, notably because the OpenSSL version shipped with MacOS missed the ECDSA functions. Using OpenSSL from MacPorts fixed that however.

You haven't mentioned but i assume you are using Snow Leopard, i have made the latest release with it's predecessor and i can't remember that i got this error because of another reason than a missing architecture in the file. If you have the ability you can try to get OpenSSL from MacPorts and recompile aacskeys with it, currently i don't have the time (and mood ) to do this myself.

[blu4fun1]

I downloaded aacskeys-0.4.0c a few minutes ago. The internal format of the libaacskeys.dylib in the lib/macosx directory is not correct. Here's the output of the file command:


libaacskeys.dylib: Mach-O universal binary with 4 architectures
libaacskeys.dylib (for architecture i386): Mach-O executable i386
libaacskeys.dylib (for architecture x86_64): Mach-O 64-bit executable x86_64
libaacskeys.dylib (for architecture ppc7400): Mach-O executable ppc
libaacskeys.dylib (for architecture ppc64): Mach-O 64-bit executable ppc64


The correct format is dynamically linked shared library.

[blu4fun1]

Here are some hints to correctly rebuild libaacskeys.dylib:

1. Carefully read README.txt and be sure you have openssl version 0.9.8 or later and premake version 3.7.

2. Verify your OPENSSL_INCLUDE = and OPENSSL_LIB = settings in premake.lua.

3. Uncomment (remove the --) from these three lines in premake.lua:
--if (macosx) then
-- table.insert(package.buildflags, "dylib")
--end

4. Enter this command: premake --file premake.lua --target gnu --os macosx

5. Remove -flat_namespace -dynamiclib, anywhere you find it in libaacskeys.make. It is caused by a problem with premake.

6. Enter this command: make clean

7. Determine the architectures you need libaacskeys.dylib to support. If you are only using it with DumpHD then you probably only need x86_64 however my Macs are older and I use a modified version of DumpHD that runs under the older Java 1.5 which is the latest Java that Apple has provided for those older Macs.

8. Enter a command like this for the architecture(s) you need: TARGET_ARCH="-arch ppc -arch ppc64 -arch i386 -arch x86_64" make libaacskeys

9. Verify that your result is a dynamically linked shared library using this command: file lib/macosx/libaacskeys.dylib

[KenD00]

Hi, thanks for taking the time to look into this, i totally have missed that file says executable.

I looked at your solution and was quite confused because i thought i'm doing just the same thing, and then i found the error, its a stupid typo!

So the fix is actually even more simple.

1. Look into premake.lua and find the line
   

   table.insert(package.linkoptions, "-dynamiclib, -framework CoreFoundation -framework IOKit")

   and change it to
   

   table.insert(package.linkoptions, "-dynamiclib -framework CoreFoundation -framework IOKit")

   The stupid colon behind dynamiclib was the problem!
   
2. To compile it under Snow open the file src/ioctl.cpp and change the line
   

   #include <IOKit/scsi-commands/SCSITaskLib.h>

   to
   

   #include <IOKit/scsi/SCSITaskLib.h>

3. Then regenerate the makefiles (you have to be in the root directory of the source tree for this)
   

   premake --target gnu

4. Clean the tree with
   

   make clean

5. Finally you can compile a new release version for your architectures, keep in mind that with Snow the powerpc architecture was removed, so an dual intel build would look like this
   

   make "CONFIG=Release" "TARGET_ARCH=-arch i386 -arch x86_64"

6. Enjoy your working library. In contrast to the broken version in the archive this library depends on the OpenSSL dylib, thankfully the version with Snow includes ECDSA and works fine. If you want to build a statically linked version or on an older MacOS release, consult the README.txt

[darkbasic]

Is there any way to decrypt mkbv11 to 14?
Are we still stuck with april 2009 films? :-(

[gravos]

Originally Posted by setarip_old

[Color=Blue]@KenD00
Perhaps if you personally try the following, you'll be able to determine whether you can, in fact, extract the volume ID from the created "discatt.dat" file - and whether doing so, in conjunction with DumpHD is all that is needed to decrypt the disc:

Yes, there is a VID in the file, the code to read it is in the linux download. But you need a VUK for DumpHD.

[cool54321]

Running Linux and dumphd-0.61 was only able to decrypt 2 BD discs out of 6. Is there a way to decrypt the newer discs on Linux?

These have MKBv: 16

lotr1.log: DiscID : 49E3C2EB3DF6697BF6613F84775EE419A817C06C
lotr2.log: DiscID : F4E162490E6971EC261CFC10653BD0CB52317F6C
lotr3.log: DiscID : A2FA3882887FD436F2E7399F3254771DFE2ED664

One disc had BD+ encryption but removing it also failed:

iceage3.log: DiscID : B6B6CF9AE847975220C62F82F41786DEA881B238

---8<---8<---
Loading /media/cdrom0/BDSVM/00000.svm ...
Volume ID set to: B6 B6 CF 9A E8 47 97 52 20 C6 2F 82 F4 17 86 DE A8 81 B2 38
[I] TRAP_LoadContentCode: Loading BDSVM/00001.svm (block 1)
[I] TRAP_MediaSHAFileHash: Hashing BDSVM/00000.svm
[I] TRAP_MediaSHAFileHash: Hashing AACS/MKB_RO.inf
[I] TRAP_MediaSHAFileHash: Hashing BDMV/STREAM/00389.m2ts
[I] TRAP_LoadContentCode: Loading BDSVM/00001.svm (block 2)
[W] TRAP_DeviceAccess not implemented!
[Event #00000000] EVENT_PlaybackFile( 00000000, 0000FFFF )
[Event #00000001] EVENT_0210( 00000000, 00000001 )
[W] TRAP_DeviceAccess not implemented!
[W] TRAP_DeviceAccess not implemented!
[Event #00000002] EVENT_PlaybackFile( 00000000, 00000001 )
[I] TRAP_LoadContentCode: Loading BDSVM/00002.svm (block 0)
[I] TRAP_GetConversionTable: Received new subtables: 1,59,118,java.lang.ArrayIndexOutOfBoundsException: 290
at bdvm.vm.conv_tab_main.setConversionTable(conv_tab_main.java:43)
at bdvm.vm.decoder.getConversionTable(decoder.java:55)
at bdvm.vm.bdsvm_player_interface.TRAP_handler(bdsvm_player_interface.ja
va:658)
at bdvm.vm.BDVM.step(BDVM.java:391)
at bdvm.debugger.Debugger.step(Debugger.java:801)
...
---8<---8<---

Why was the array out of bounds? Could that be easily fixed just by having a bigger array or has something else went wrong?

[GodofaGap]

I don't know specifically how to solve your problem but an ArrayIndexOutOfBoundsException is not thrown because the array is too small (this shouldn't really ever be happening in Java), but because the program is requesting an element at an index that does not exist (for example the array has 100 elements while the program requests element number 178)

[Rinse&Repeeat]

Are we (the user of your program)responsible for providing our own ProcessingDeviceKeysSimple.txt, HostKeyCertificate.txt contents?

I ask because I believe that the keys and hostCertificate provided was expired by the time I got to it.

I get the following error.

Could not find a Processing Key or Device Key resulting in the Media Key.

[pynux]

only key v1 to v10 is in the ProcessingDeviceKeysSimple.txt
if you want have decrypt v10 to v18 use lxbdplayer with lxbdaacs (and makemkv 1.5.5) to have the media key of bluray mkb >=v11

[Rinse&Repeeat]

The latest version of makeMKV is 1.6.8. I've used it, it's nice, I just don't to have to pay (again) to watch a movie I've already bought. I've payed my dues when I bought the disk(movie), I shouldn't have to pay again for software to watch it.

I found lxBDplayer, I'm not sure about the other file as most of the links I found for it were questionable, and the only one that looked remotely safe was in French, I don't speak French. Is their a link you can provide to the lxbdaacs?

Are you saying I need to replace files in dumpHD with the ones you suggested?

Edit, I found the thread for lxBDplayer, and the required lxBDaacs. I was hoping to use DumpHD, seeing as I don't have to pay for that. I suppose if the only I'll be able to get around the stupid silly "We don't support your OS" limitations of other programs, I'll have to use makeMKV. Paying for yet another program to do what I've already paid for (play a movie) rubs me the wrong way.

[pynux]

lxbdplayer was make by a student of french university
but the software have been translate in english

[pynux]

@Rinse&Repeeat
lxbdplayer is for playing bluray
lxbdaacs is plugin for lxbdplayer to have AACS

lxbdaacs dump the memory of makemkv to have the key of the bluray

but lxbdaacs work only with makemkv 1.5.5 (with the free beta serial)

you don't have to pay for use it

[myth88]

Any idea why I can't press any buttons opening the main window?
See this image:


System is Archlinux with XFCE, installed from AUR.

[Darksoul71]

I know this is not exactly an answer to your question but given the age of the last posting and the last update at the first posting I doubt that there is much active development here. In case you are watching for something to decrypt BDs under Linux, you might consider trying MakeMKV.

HTH,
D$

Edit: A more helpful answer might be which Java Runtime you are using and if this corresponds with the supported JRE of DumpHD. Java apps often behave strange when you use a different Java (older or newer version, OpenJRE versus Sun's JRE, and so on).

[myth88]

Hi,

thanks for the answer. I already tried different versions of java, didn't work...

So right now I really like makemkv!

[Darksoul71]

Re-Hi,

glad I could help ! I have been using MakeMKV for quite a while under Xubuntu 12.04 with an external LG BD and it worked like a charm.
Plus it has a nice option to directly watch BDs via local streaming server. Works also great from the shell via makemkvcon if you are more the text addicted type of user

[metaldave2003]

Hi, friends.

I am endeavoring to archive my HD DVD's. (It seemed like an appropriate project to work on at the moment.) For the most part, MakeMKV takes care of the job without any real customization. However, there are some titles that are still looking for their VUK.

@candela brought the DumpHD app to my attention when I was looking for keys for these relics of HD lore. I have pieced together the ProcessingDeviceKeysSimple.txt and HostKeyCertificate.txt as appropriate (based upon the sets listed here), and those seem to check out. The last piece I'm stuck on is the libaacs library.

I'm currently working this solution on a Mac, and I've found the libaacskeys.dylib within the aacskeys-0.4.0f archive. I've placed this in the same directory as the DumpHD JAR file, and I get the following:

Loading aacskeys library... FAILED
/Users/username/Desktop/Sandbox/dumphd-0.61/libaacskeys.dylib: dlopen(/Users/username/Desktop/Sandbox/dumphd-0.61/libaacskeys.dylib, 1): no suitable image found. Did find:
/Users/username/Desktop/Sandbox/dumphd-0.61/libaacskeys.dylib: can't map unslidable segment __TEXT to 0x100000000 with size 0x75000
/Users/username/Desktop/Sandbox/dumphd-0.61/libaacskeys.dylib: can't map unslidable segment __TEXT to 0x100000000 with size 0x75000
Direct key retrieval disabled, only keys from the database will be used

I've gotten a similar message when I locate the library in the /Library/Java/Extensions directory:

Loading aacskeys library... FAILED
/Library/Java/Extensions/libaacskeys.dylib: dlopen(/Library/Java/Extensions/libaacskeys.dylib, 1): no suitable image found. Did find:
/Library/Java/Extensions/libaacskeys.dylib: can't map unslidable segment __TEXT to 0x100000000 with size 0x75000
/Library/Java/Extensions/libaacskeys.dylib: can't map unslidable segment __TEXT to 0x100000000 with size 0x75000
Direct key retrieval disabled, only keys from the database will be used

I realize this application is ancient history, but I was wondering if someone might have a clue on how to address this issue. I realize running this on macOS Catalina has it's own share of security blocks (which seem to be bypassed if you're running in the local directory rather than anything at the /Library level). However, I think I've got everything configured and recognized correctly.

I will try this with my Windows 10 machine as well to see if the DLL works better than the DYLIB on the Mac.

Thanks in advance!

[maetel99]

Originally Posted by metaldave2003

I'm currently working this solution on a Mac, and I've found the libaacskeys.dylib within the aacskeys-0.4.0f archive. I've placed this in the same directory as the DumpHD JAR file, and I get the following:

It could be that the old libraries are built 32-bit and you are running macOS 10.15 which is 64-bit only. You can test this by opening a Terminal window and typing:

file <path to dylib>

Then look to see if the output shows "x86_64". If it only shows "i386" then it is a 32-bit only library. You'll have to rebuild it for 64-bit use.

[metaldave2003]

maetel99,

Thank you for the thought. I checked it, and it looks like we're good x86_64:

% file libaacskeys.dylib          
libaacskeys.dylib: Mach-O universal binary with 4 architectures: [i386:Mach-O executable i386] [x86_64:Mach-O 64-bit executable x86_64] [ppc_7400] [ppc64]
libaacskeys.dylib (for architecture i386):	Mach-O executable i386
libaacskeys.dylib (for architecture x86_64):	Mach-O 64-bit executable x86_64
libaacskeys.dylib (for architecture ppc7400):	Mach-O executable ppc_7400
libaacskeys.dylib (for architecture ppc64):	Mach-O executable ppc64

I was, truly, hoping you had it. Thanks again!