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 18th January 2007, 21:37   #941  |  Link
Coderjoe
huh?
 
Join Date: Mar 2006
Posts: 5
noclip: developer on what project?

btw, I am getting more and more tempted to get a drive and a movie or two and start poking around...
Coderjoe is offline   Reply With Quote
Old 18th January 2007, 21:47   #942  |  Link
He-Man
Guest
 
Posts: n/a
Quote:
Originally Posted by Coderjoe View Post
noclip: developer on what project?
BackupHDDVD on SourceForge http://forum.doom9.org/showthread.php?t=120896
  Reply With Quote
Old 19th January 2007, 04:05   #943  |  Link
DanITman
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
DanITman is offline   Reply With Quote
Old 19th January 2007, 04:44   #944  |  Link
jokin
Dwight Schrute's homeboy
 
Join Date: Jan 2007
Location: The Office
Posts: 136
Quote:
Originally Posted by DanITman View Post
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
Try just dragging an EVO to the desktop and playing it.
jokin is offline   Reply With Quote
Old 19th January 2007, 07:27   #945  |  Link
NghtShd
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);
NghtShd is offline   Reply With Quote
Old 19th January 2007, 11:18   #946  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
CMAC check

Quote:
Originally Posted by Nutrition24 View Post
I adapted BackupHDDVD-GUI to check the correctness of the Volume Unique Key using CMAC algorithm, but since I don't have a title key file myself, I'd also like to receive some sort of valid title key file to test the changes against.

(If anyone else want to try out ahead: it's at http://www.sendspace.com/file/slqvdw)
This is a great feature. Has this been tested yet by anyone? Maybe change a key slightly and see if it is detected?

Quote:
Originally Posted by Nomadic View Post
New version BackupHDDVD-GUI
changes:
- Decrypting file in separate thread (as yet one!)
- Progress bar while decrypting
- Minor fixes
Looking at your source Nutrition24's cmac check still has to be added to your program. Am I right? Or is it already in the exe?
arnezami is offline   Reply With Quote
Old 19th January 2007, 13:52   #947  |  Link
hajj_3
Registered User
 
Join Date: Mar 2004
Posts: 746
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.
hajj_3 is offline   Reply With Quote
Old 19th January 2007, 15:43   #948  |  Link
melakai
Registered User
 
Join Date: Jan 2007
Posts: 28
Quote:
Originally Posted by NghtShd View Post
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.
Don't worry about trying to stuff all these features in right away. It might be better to get the source out so others can help rapidly develop that don't do Java.

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.
melakai is offline   Reply With Quote
Old 19th January 2007, 15:49   #949  |  Link
kad77
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
kad77 is offline   Reply With Quote
Old 19th January 2007, 15:53   #950  |  Link
noclip
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>
noclip is offline   Reply With Quote
Old 19th January 2007, 15:55   #951  |  Link
Nomadic
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...
Nomadic is offline   Reply With Quote
Old 19th January 2007, 16:05   #952  |  Link
noclip
Registered User
 
Join Date: Dec 2006
Posts: 154
Oh, and since everyone is adding CMAC-baesd volume key checking algorithm, I'd like to suggest using the CMAC to identify disks instead of a SHA1 hash of the TK file.
noclip is offline   Reply With Quote
Old 19th January 2007, 16:24   #953  |  Link
kad77
0xdeadbeef
 
Join Date: Jan 2007
Posts: 18
Wrong-headed

Quote:
Originally Posted by noclip View Post
Oh, and since everyone is adding CMAC-baesd volume key checking algorithm, I'd like to suggest using the CMAC to identify disks instead of a SHA1 hash of the TK file.
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?
kad77 is offline   Reply With Quote
Old 19th January 2007, 16:48   #954  |  Link
noclip
Registered User
 
Join Date: Dec 2006
Posts: 154
Quote:
Originally Posted by kad77 View Post
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?
You don't have to do any hashing, just read the CMAC from the disk. Gets rid of an unnecessary step.
noclip is offline   Reply With Quote
Old 19th January 2007, 16:57   #955  |  Link
He-Man
Guest
 
Posts: n/a
Quote:
Originally Posted by kad77 View Post
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?
Quote:
Originally Posted by noclip View Post
You don't have to do any hashing, just read the CMAC from the disk. Gets rid of an unnecessary step.
Besides this another and IMHO more important advantage of using CMAC over SHA-1 is that you can always verify if submitted Volume Unique Keys are indeed correct. When someone submits keys to an online database, they could automatically be checked for correctness at the same time so people don't post invalid keys, either on purpose or by mistake.
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:
Originally Posted by The_ByteMaster View Post
My bad! But yes, the idea was just to have a quick check whether the Volume Unique Key in the KEYDB.cfg is indeed correct. This will help make the program a little more robust against fake or wrong keys.

The format of VTKF.AACS file can be found in paragraph 3.4 of AACS_Spec_HD_DVD_and_DVD_Prerecorded_0_912, more specifically in Table 3-5. The TKF MAC field (16 bytes) is bytes 2464-2479.

The CMAC calculation is the one described in NIST SP800-38B, also described RFC 4493 with a C source.
I googled and found Java source (OMAC.java), placed in the public domain by author Paulo Barreto, here: http://www.larc.usp.br/~pbarreto/

Last edited by He-Man; 19th January 2007 at 17:21.
  Reply With Quote
Old 19th January 2007, 17:05   #956  |  Link
0xdeadbeef
Author of BDSup2Sub
 
Join Date: Jun 2003
Posts: 478
Quote:
Originally Posted by kad77 View Post
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.
When processing a stream, you'd need to divide the stream into packets which can be processed in parallel. Multithreading alone won't help. Also I'm not even sure if a multithreaded application running in a virtual machine will necessarily be distributed to multiple CPUs.

Quote:
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.
The Java runtime uses a just in time (JTI) compiler, so in a processing loop, the code executed is "native" anyway. Indeed the JIT compiler might create better code than a static compiler under some circumstances.

Quote:
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.
This won't help. Indeed the EXE might even be slower.

Quote:
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++.
Well, a highly optimized C version might indeed be faster though I wouldn't expect a large improvement. I don't see any reason why a C#-version should be. Using ASM won't help much either, only if the purpose is to use SIMD instructions which of course could speed up things quite a bit.
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).
0xdeadbeef is offline   Reply With Quote
Old 19th January 2007, 18:04   #957  |  Link
romgohan
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..
romgohan is offline   Reply With Quote
Old 19th January 2007, 18:14   #958  |  Link
2bigkings
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
2bigkings is offline   Reply With Quote
Old 19th January 2007, 18:19   #959  |  Link
heman
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
heman is offline   Reply With Quote
Old 19th January 2007, 18:50   #960  |  Link
NghtShd
Registered User
 
Join Date: Dec 2006
Posts: 27
Quote:
Originally Posted by 0xdeadbeef View Post
Well, a highly optimized C version might indeed be faster though I wouldn't expect a large improvement. I don't see any reason why a C#-version should be. Using ASM won't help much either, only if the purpose is to use SIMD instructions which of course could speed up things quite a bit.
I don't see any reason there shouldn't be translations into any language people might want to develop in. I used C# for a several reasons (and, BTW, prior to now I've never done more than a couple dozen lines of C# code):

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.

Quote:
Originally Posted by noclip View Post
Can you use XML-based key storage in future versions?
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.
NghtShd 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:35.


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