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. |
30th November 2008, 02:58 | #461 | Link | |
Registered User
Join Date: Jun 2008
Posts: 46
|
I'm not sure if this needs to go into the dumphd thread or this but I've been trying out the bdvmdbg today and ran into some trouble:
I got the conversion table for Prison Break Season 3 Disc 1.. and got no special errors during the process Code:
$ Volume ID set to: 90 BB 43 94 DC C6 50 05 54 FE 96 16 96 07 DE 66 Loading E:\/BDSVM/00000.svm ... [I] TRAP_LoadContentCode: Loading BDSVM/00001.svm (block 6) [I] TRAP_DebugLog: 2008-11-01 01:43:11.21 playback starts [I] TRAP_MediaSHAFileHash: Hashing BDSVM/00000.svm [I] TRAP_MediaSHAFileHash: Hashing AACS/MKB_RO.inf [I] TRAP_MediaSHAFileHash: Hashing BDMV/STREAM/00004.m2ts [I] TRAP_LoadContentCode: Loading BDSVM/00001.svm (block 7) [Event #00000000] 0110 ( 00000000, 0000FFFF ) [Event #00000001] 0210 ( 00000000, 00000001 ) [W] TRAP_DeviceAccess not implemented! [Event #00000002] 0110 ( 00000000, 00000001 ) [I] TRAP_LoadContentCode: Loading BDSVM/00002.svm (block 0) Conversion table set Anyway, DumpHD reports some potential problems Code:
0x0000000000 Decryption enabled Processing: BDMV\STREAM\00001.m2ts Error! BD+ SubTable not found, dumping may fail 0x0000000000 Decryption enabled Processing: BDMV\STREAM\00002.m2ts Error! BD+ SubTable not found, dumping may fail 0x0000000000 Decryption enabled Processing: BDMV\STREAM\00004.m2ts Error! BD+ SubTable not found, dumping may fail 0x0000000000 Decryption enabled I loaded the convtable into ConvTableView and it can successfully load the table. Quote:
|
|
30th November 2008, 03:23 | #462 | Link |
Registered User
Join Date: Jun 2008
Posts: 46
|
Umm... I think there's a problem with Die Another Day (US).. on the right hand side of the debugger I see some stuff marked in red, though the console output doesn't contain any errors / warnings. The convtable is a lot smaller than my previous ones (592KB instead of almost 1 MB) - convtableview loads the table just fine but there's a lot of emptyness there. I'll post again when the decryption process is through.
|
30th November 2008, 03:44 | #463 | Link | |||||||
Registered User
Join Date: Sep 2008
Posts: 189
|
Quote:
Quote:
Quote:
Those error messages say that the conversion table doesn't contain entries for all the files you have on disc. It most likely means that either the conversion table is corrupt (which you would have noticed with ConvTableView) or you are using the wrong conversion table. Is it possible that you are using the conversion table from a different movie? Are you running dumpHD from command line like this example below? Code:
/dumphd-0.5/dumphd.sh --infile:BDMV/STREAM/00001.m2ts --convtable:conv_tab.bin /media/cdrom/ > /tmp/00001.m2ts Quote:
Quote:
Quote:
Quote:
I have recently introduced code which removes bogus repair descriptors. It might be possible that a bug causes the removal of valid descriptors. Last edited by loo3aem3ON; 30th November 2008 at 03:51. |
|||||||
30th November 2008, 04:20 | #464 | Link | ||
Registered User
Join Date: Jun 2008
Posts: 46
|
Quote:
Quote:
In the meantime I'm done with Die Another Day and at first glance the decrypted output seems to be fine. DumpHD reported no issues and in jumping around the movie I have yet to discover a corrupted part. I will compare the decrypted output with the files on the disc when I have AnyDVD HD active. Are you interested in knowing which discs decrypt okay? I have a sizeable collection (by my count 19 from the list of Fox/MGM discs posted here though I'm not convinced every one is really a BD+ disc.. plus two titles are actually series so they have 4/6 discs respectively) and if it helps I can run them all through and compare with AnyDVD HD. Last edited by yippiekayee; 15th December 2008 at 20:01. |
||
30th November 2008, 15:33 | #465 | Link | |
Registered User
Join Date: Jun 2008
Posts: 46
|
Quote:
The same also holds for Live and Let Die.. only that on that disc the difference are 36KB files. By the way, is it enough to compare the Streams directory or are there other files protected by BD+? Last edited by yippiekayee; 30th November 2008 at 17:03. |
|
30th November 2008, 16:31 | #466 | Link | ||
Registered User
Join Date: Sep 2008
Posts: 189
|
Quote:
I believe there is a problem with the callback parameters (event management) and i need the hashes to fool the content code. Below is the structure of the hash_db.bin in EBNF. Accident will probably want to add support for it. We could include the volume id. *edit* removed. See posting #480 *edit* After this issue is fixed we can take a look at the other problems. Quote:
Last edited by loo3aem3ON; 1st December 2008 at 19:30. |
||
30th November 2008, 17:09 | #467 | Link | |
Registered User
Join Date: Jun 2008
Posts: 46
|
Quote:
|
|
30th November 2008, 17:33 | #468 | Link | |
Registered User
Join Date: Dec 2006
Posts: 5
|
Quote:
Coppersmith's algorithm -- a low-exponent attack on RSA -- after the upper half of the bits had been determined by the timing attack. Since you claim the upper half bits have been obtained the method described in the article should be directly applicable. However, I do not think knowing the upper half bits is necessary in order to apply Coppersmith's algorithm. I'm also unclear about how knowledge of the upper half bits can be exploited in order to speed-up the algorithm. Coppersmith's algorithm is implemented as zncoppersmith in PARI/GP, coppersmith in Sage and elsewhere. http://groups.google.com/group/sage-...0c9b2a9e8d22ee |
|
30th November 2008, 18:33 | #469 | Link | |
Registered User
Join Date: Sep 2008
Posts: 189
|
Quote:
Download this snapshot please: http://uploaded.to/?id=7yht2d Run it once with Prison Break and send me the hash_db.bin and the contents of the BDSVM directory (without the BACKUP subdirectory). That's all i need currently. Before running verify that the hash_db.bin has zero length. Thank you. |
|
30th November 2008, 21:00 | #471 | Link |
Registered User
Join Date: Jun 2008
Posts: 46
|
I'm afraid the new version didn't do the trick either. Same errors from dumphd and while the first episode is again properly decrypted, subsequent episodes aren't.
And I did compare the last three of my Bond discs - which played just fine but there are again small files where the md5sums differ. I also watched ripped Hitman today and watched the main movie.. it was glitch free but I haven't yet compared md5sums with AnyDVD. Last edited by yippiekayee; 15th December 2008 at 20:02. |
30th November 2008, 21:06 | #472 | Link | |
Registered User
Join Date: Dec 2006
Posts: 5
|
Quote:
potentially useful low-exponent RSA attack. |
|
30th November 2008, 21:21 | #473 | Link | |
Registered User
Join Date: Dec 2006
Posts: 5
|
Quote:
http://www.informatik.tu-darmstadt.d...tions/03/bp.ps |
|
30th November 2008, 22:59 | #476 | Link |
Registered User
Join Date: Jun 2008
Posts: 46
|
I just ripped the second disc of Prison Break Season 3. Got the same error about BD+ subtable not being found, but this time only for the episodes... subsequent m2ts files didn't yield the error and the first episode (first m2ts file) was okay again - so I think this is something systemic.. has the BD+ code ever been tested against episodic discs?
This brings me to a question: how can we verify the debugger against titles with MKB versions for which we don't have a processing key yet? Firefly is in the mail but afaik it's MKBv9.. AnyDVD HD can handle that but not the BD+. So, since DumpHD won't be able to decrypt those discs without the processing key is there a way to apply the BD+ removal without doing AACS encryption so that we could first remove BD+, then run AnyDVD HD on it to remove AACS and the verify if the output is correct. |
30th November 2008, 23:26 | #477 | Link | ||
Registered User
Join Date: Sep 2008
Posts: 189
|
Quote:
Quote:
Maybe you have heard of "confusion" and "diffusion" which are properties of every serious encryption algorithm. In our case the "diffusion" property of AES would cripple the entire 128-bit block if you only change a single bit before decryption. I see no way to modify the encrypted stream so that the decryption result is already repaired (without knowing the key of course). Last edited by loo3aem3ON; 30th November 2008 at 23:35. |
||
1st December 2008, 01:23 | #479 | Link | |
Registered User
Join Date: Sep 2008
Posts: 189
|
Quote:
Try this development snapshot please: http://uploaded.to/?id=ij27kc I still don't understand the second parameter of callback/event 0x0110 but i know this event occurs before the playback of every m2ts file. So i decided to issue event 0x0110 with the second parameter with all possible values between 0 and 50 to get all the pieces from the conversion table. It seems to work. The resulting conversion table for "Prison break" is 4MB big. |
|
1st December 2008, 19:15 | #480 | Link |
Registered User
Join Date: Sep 2008
Posts: 189
|
I've redesigned the hash database. It now supports multiple hashes created from a single large block. It's implemented as a chained list which is fast enough for those few entries we have. The structure is:
Code:
key = SHA-1 hash of offset, bytesToHash and Filename; 20 bytes nextPointer = points at the beginning of the next entry; relative address; 4 bytes bytesHashed = number of bytes used to calculate the hash; 4 bytes database ::= {entry} entry ::= key , nextPointer , bytesHashed , {hash} |
Thread Tools | Search this Thread |
Display Modes | |
|
|