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. |
18th January 2007, 21:47 | #942 | Link |
Guest
Posts: n/a
|
BackupHDDVD on SourceForge http://forum.doom9.org/showthread.php?t=120896
|
19th January 2007, 04:05 | #943 | Link |
Registered User
Join Date: Dec 2006
Posts: 16
|
I have an HD-DVD that I cannot find the VK for. I'm starting to think it doesn't even have one or the disc might not be encrypted.
Here is the disc: Musicares person of the year tribute honoring James Taylor http://www.buy.com/retail/product.as...ype=video_vhs& I'm more interested in hunting down keys then I am actually backing this thing up. I'm just practicing finding keys and this is the only one that has stumped me. Could it be possible that it doesn't have a VK? Would anyone be willing to take a look at the dumped memory and give me a hint to it's location? Thanks |
19th January 2007, 04:44 | #944 | Link | |
Dwight Schrute's homeboy
Join Date: Jan 2007
Location: The Office
Posts: 136
|
Quote:
|
|
19th January 2007, 07:27 | #945 | Link |
Registered User
Join Date: Dec 2006
Posts: 27
|
C# port of HDDVDBackup
Please read the following before downloading.
HDDVDBackupG is C# port of HDDVDBackup with a GUI interface. I'm pretty sure title key decription works properly. It may not work on EVO files however. Since I don't have encrytped EVO files and a corresponding VTKF000.AACS to test with I couldn't do much more than guess at the crypto setup. If you feel it would be a waste of your time if the app fails to decrypt your files then don't bother. The C# source code will be released, but I'd like to get some feedback regarding EVO decription while I do some code clean up and maybe add a bit more error control. I'll also look at more informative output a progress bar and multithreading if I have time. http://users.adelphia.net/~m.crane/bin/HDDVDBackup.rar Below is the main decryption setup. If any crytpo people see any obvious errors please let me know. Code:
class AESFunc { static byte[] AESCBCConstantIV = { 0x0B, 0xA0, 0xF8, 0xDD, 0xFE, 0xA6, 0x1F, 0xB3, 0xD8, 0xDF, 0x9F, 0x56, 0x6A, 0x05, 0x0F, 0x78 }; public static byte[] AESG(byte[] x1, byte[] x2) { RijndaelManaged AES = new RijndaelManaged(); AES.Mode = CipherMode.ECB; AES.Padding = PaddingMode.None; AES.KeySize = 128; //AES.BlockSize = 128; ICryptoTransform decryptor = AES.CreateDecryptor(x1, x1); MemoryStream memoryStream = new MemoryStream(x2); CryptoStream cryptoStream = new CryptoStream(memoryStream, decryptor, CryptoStreamMode.Read); byte[] plainTextBytes = new byte[x2.Length]; // Start decrypting. int decryptedByteCount = cryptoStream.Read(plainTextBytes, 0, plainTextBytes.Length); return Utils.xor(plainTextBytes, x2); } public static byte[] decryptPack(byte[] pack, byte[] contentKey) { RijndaelManaged AES = new RijndaelManaged(); AES.Mode = CipherMode.CBC; AES.Padding = PaddingMode.None; AES.KeySize = 128; //AES.BlockSize = 128; ICryptoTransform decryptor = AES.CreateDecryptor(contentKey, AESCBCConstantIV); MemoryStream memoryStream = new MemoryStream(pack); CryptoStream cryptoStream = new CryptoStream(memoryStream, decryptor, CryptoStreamMode.Read); byte[] plainTextBytes = new byte[pack.Length]; // Start decrypting. int decryptedByteCount = cryptoStream.Read(pack, 0, plainTextBytes.Length); return pack; } } Last edited by NghtShd; 22nd January 2007 at 02:51. Reason: fixed code: int decryptedByteCount = cryptoStream.Read(pack, 0, plainTextBytes.Length); |
19th January 2007, 11:18 | #946 | Link | ||
Registered User
Join Date: Sep 2006
Posts: 390
|
CMAC check
Quote:
Quote:
|
||
19th January 2007, 13:52 | #947 | Link |
Registered User
Join Date: Mar 2004
Posts: 1,120
|
its prob best to use the c#.net version when thats fully working instead of just a .exe, this way you can have access to the keys.cfg file. we could create an installer for it to install it to $:\Programs Files\BackupHDDVDgui.
|
19th January 2007, 15:43 | #948 | Link | |
Registered User
Join Date: Jan 2007
Posts: 28
|
Quote:
I don't have my HDDVD drive hooked up at home to test, but I'll give it a shot tonight if no one beats me to the punch. |
|
19th January 2007, 15:49 | #949 | Link |
0xdeadbeef
Join Date: Jan 2007
Posts: 18
|
I want to clear a few things up about BackupHDDVD performance for the non-technical:
1. Software can be structured to be multi-threaded (not 'multi-core'), which would utilize multiple processors and/or cores. 2. An interpreted language algorithm (ie Java byte code running in a Virtual Machine, or C# in the CLR) is always going to be slower than a native machine code algorithm. Non-threaded native C/C++ code will probably still outperform multi-threaded Java, btw. 3. If you are really impatient, you can try compiling muslix64's source in the GNU Java compiler to get a native binary executable. You might see some performance gains, but you probably will learn something. 4. Most importantly: as others have stated, the encrypted AACS data streams still need to be handled properly! Guesswork hacks remain in muslix64's code that don't follow AACS spec... When these unknowns are addressed, then you'll see worthwhile optimized versions. In the meantime, you are likely archiving 'corrupt' backups that will need to be redumped in the future. I've partially written a platform independent C translation, and I'm sure others will rewrite the utility in a similar high-performance language (probably C++, with assembly sub-sections) that can be compiled to a specific processor-- C/C++ code will run significantly faster than the Java reference code currently floating around. C# may provide some marginal improvement, but it is still managed code and is not as portable as Java, C, or C++. Remember, this entire process is still in the testing/development stage. BackupHDDVD is not a production utility ready for prime time quite yet. GUI development is a nice coat of paint, but the core algorithm needs to be fixed first! Thanks for firing the first shot muslix! Last edited by kad77; 19th January 2007 at 16:17. Reason: clarity |
19th January 2007, 15:53 | #950 | Link |
Registered User
Join Date: Dec 2006
Posts: 154
|
Can you use XML-based key storage in future versions?
Example format: Code:
<?xml?> <keyset> <description>Movie name</description> <cmac>XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</cmac> <key type="volume">XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</key> <key type="title"> <title id="3">XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</title> <title id="10">XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</title> </key> </keyset> <keyset> <description>A different movie name</description> <cmac>XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</cmac> <key type="volume">XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</key> </keyset> |
19th January 2007, 15:55 | #951 | Link |
Registered User
Join Date: Aug 2003
Posts: 19
|
New version BackupHDDVD-GUI v0.0.5
changes: - Added more GUI functionality. - List of files with the possibility of choice. - Added AboutBox with the developers working on this programme (was nobody forgotten?). - Minor fixes - Check the correctness of the Volume Unique Key using CMAC algorithm (by Nutrition24) Last edited by Nomadic; 20th January 2007 at 09:06. Reason: VTKF*.AACS found bug... |
19th January 2007, 16:24 | #953 | Link |
0xdeadbeef
Join Date: Jan 2007
Posts: 18
|
Wrong-headed
Why? There are optimized SHA1 implementations available, and it is perfectly valid for uniquely identifying the TK. A lengthy disc list is available using this format... Where's the advantage in your suggestion?
|
19th January 2007, 16:57 | #955 | Link | ||
Guest
Posts: n/a
|
Quote:
As The_ByteMaster said: "This will help make the program a little more robust against fake or wrong keys". I actually think it's a very good idea to switch from SHA-1 to CMAC. Then people don't need to implement SHA-1 hash calculations in key extraction software anymore. Key extrationn will mste likely be an integrated part of BackupHDDVD in the future along with extraction of CMAC, Movie Title and prodution date from the disc). The online database isn't that big by now that it can't soon be changed. People who have submitted keys can soon find the CMAC value too to update the database. But because of this it's better to do the change from SHA-1 to CMAC now than wait 6 months or so. By using CMAC instead of SHA-1 it will be possible to verify. If the format of KEYDB.cg should be changed from uising SHA-1 to CMAC values, maybe it should be changed to have the titles in the first filed and then region/natiiom and date in the next filed and the CMAC and key files. It would improve readablity for human eayes to have the titles keys as the first thin I think. An earlier post about CMAC by The_ByteMaster: Quote:
Last edited by He-Man; 19th January 2007 at 17:21. |
||
19th January 2007, 17:05 | #956 | Link | ||||
Author of BDSup2Sub
Join Date: Jun 2003
Posts: 478
|
Quote:
Quote:
Quote:
Quote:
Anyway, my impression is, that most of the runtime is disc IO. If the AES implementation in the Java runtime should really slow things down by a measurable degree, maybe it would be worth to implement an optimized version instead of starting conversions to other languages just because people think Java is generally slow (which it isn't). |
||||
19th January 2007, 18:04 | #957 | Link |
Registered User
Join Date: Feb 2005
Posts: 40
|
There is some talk about speed, decrypting speed and so on...
Can someone with a drive (and a lot of patience) compare the time of copying the encrypted evo file to HDD with decrypting it with BackupHDDVD? That way we can see how much can be gained through program optimizations.. |
19th January 2007, 18:14 | #958 | Link |
Registered User
Join Date: Jan 2007
Posts: 117
|
without copying to hdd first, it tooks about 55min to decrypt it from drive to hdd.
~27gb movie p4 3,2ghz (HT) 1GB RAM sapphire x1950pro if you copy it first to HDD, it tooks much longer.. first i thought also it goes faster but it doesn't |
19th January 2007, 18:19 | #959 | Link |
Registered User
Join Date: Jan 2006
Posts: 6
|
i can't decrypt with BackupHDDVD-GUI v0.0.5 version i get the following error
BackupHDDVD starting. === Start analyse === Scaning video directory... Founded files... === Start decrypting === Could not find any ".AACS" file. Aborting... i tested it on all 3 discs i have with the original jar file its working |
19th January 2007, 18:50 | #960 | Link | |
Registered User
Join Date: Dec 2006
Posts: 27
|
Quote:
1) I use Visual Studio anyway, so it was there. 2) Going from Java to C# seemed more straight forward than going to C++ (my language of choice). 3) I wanted a to put a GUI on it*. VStudio made that pretty easy. 4) I felt like doing some C# code for a change and I thought someone else may also prefer to tinker with that instead--choice is good. 5) I thought I would also do a C++ version after the C# was done. Doing this has made me much more familiar with the code and was a lot more interesting than simply reading the code over and over. However, if others are working on C or C++ then I may not bother with that after all. * When I first started this I was unaware of any other GUI versions and prior to last night I hadn't seen HDDVDBackup-GUI (good job, BTW). I was a little surprised at the similarity at first (oh noes! I'll get flamed for ripping off their UI), but I guess a having couple of lines for file paths and a button or two is the obvious way to go. Anyway, I considered not going forward with this when I saw that someone was working on a GUI, but as I said above, choice is good and I've enjoyed having some reason to learn a little C#. So there are my reasons for a C# version. As melakai said, it's probably better to go ahead and get the source out, so I'll try to go ahead with that today, but I do want to add credits to muslix64 for the original code in all my source files and clean up a few things first. I think this was directed toward the Java version, but I was actually working on that a bit yesterday. Seems alike a good way to go and I like your layout. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|