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 23rd November 2008, 20:51   #441  |  Link
loo3aem3ON
Registered User
 
Join Date: Sep 2008
Posts: 189
I've restructured our documentation so please have a look at the table of contents. We need more people working on this if possible. Fixing grammar/bad English expressions and typos will help too. Has anyone written a description of the conversion table yet? Would you suggest to move the detailed trap descriptions to the appendix?
loo3aem3ON is offline   Reply With Quote
Old 24th November 2008, 14:34   #442  |  Link
loo3aem3ON
Registered User
 
Join Date: Sep 2008
Posts: 189
I saw you committed a few updates including a patch to add diffarchive support. I would like to comment on this.
Quote:
Originally Posted by Accident
// Locate the correct diff. This is tedious. Why couldn't they have
// made the diffarchive with a index-list of offsets.
A diffarchive snapshot is a stream of patches in which you are not supposed to seek. The diffarchive file is opened only once during your program initialization (startup). Then you are supposed to allocate another 4MB of memory and fill it with zeros. Now you have two 4MB memories. One is updated by the virtual machine and the other (lets call it reference memory) is updated by the patches from the diffarchive stream.
Once this is done you can start the virtual machine and let it run until the first trap. In the meantime (different thread maybe?) you can apply the first chunk of patches to the (zeroed) 4MB reference memory which gives you the memory state after the first trap execution.
Now when the first trap has been executed you compare both 4MB memories and if they should differ you overwrite the virtual machine memory with the reference memory.
After this is done you apply the second chunk of patches to update the reference memory to the state after the second trap execution... and so on.

I believe you made it far to complicated. Have a look at the snapshots.java file and see how simple this actually is if you can afford the extra 4MB of memory.

(the register snapshots are threated the same way)

Quote:
Originally Posted by Accident
// Seriosuly who writes files in LE, you can't use any of ntohs() etc calls
If you would like to have big endian/little endian swapped in future diffarchive snapshot packages you can try to convince me to change it.

Last edited by loo3aem3ON; 24th November 2008 at 14:40.
loo3aem3ON is offline   Reply With Quote
Old 25th November 2008, 00:09   #443  |  Link
Accident
Registered User
 
Join Date: Aug 2002
Posts: 111
Quote:
Originally Posted by loo3aem3ON View Post
A diffarchive snapshot is a stream of patches in which you are not supposed to seek. The diffarchive file is opened only once during your program initialization (startup). Then you are supposed to allocate
I meant to delete this rant, I wasn't thinking clearly or drunk, one of those two. Of course the differences has to play from the start to get a specific snapshot.



Quote:
If you would like to have big endian/little endian swapped in future diffarchive snapshot packages you can try to convince me to change it.
This one I feel I have some legs to stand on. Since both the OS (since all network is BE), and BD+ itself is BE, we already have functions and support to handle it. But since normal use will not use snapshots, it doesn't matter too much if you can't use them on BE architectures.

But either way, disregard my rantings, they weren't supposed to be checked in, I did so a little bit quickly to have it committed before the end of the weekend.


Also, I read your documentation, nicely done.

Edit:

I re-did the cleaning of fake repair descriptors to be done at segment-decrypt time, so they are not in the way for all the functions using conv_tab. I will work on Win32 build today, and all issues that brings. Otherwise, libbluray-0.0.6 should be working with the known titles.

libbluray-0.0.6.tar.gz
If you intend to try it against Jumper, don't forget you need the two shablocks, or the original encrypted 00005.m2ts file.

Last edited by Accident; 25th November 2008 at 09:37.
Accident is offline   Reply With Quote
Old 25th November 2008, 12:42   #444  |  Link
haggi
coffee addict
 
Join Date: Apr 2007
Posts: 9
My math guy doesn't reply ... So I'll post it here. Prove me wrong if you like

The signature for some data is calculated as follows:
Code:
m = c^d mod n
which is the same as
Code:
m = c^d - k*n
with k big enough to satisfy m < n where k is some big int

we know m (the signature), n = p*q (where p and q are the primes we want to get in the end) and c (which is obviously needed the check a signature)

but we want to know d
Code:
m + k*n = c^d
d = log_c (m + k*n)
the most efficiently calculated log is the log_2 (the int part is the index of the most significant non-zero bit, counting from the LSB side)
Code:
d = (log_2 (m + k*n))/(log_2(c))
where log_2(c) has to be calculated only once

some k has to be found to satisfy
Code:
| d' - ((log_2 (m + k*n))/(log_2(c))) | <= 2 * square_root( N )
The last operation (the division by log_2(c)) is to be aborted if the some byte returned is different from the known byte in d'. Which is efficiently possible because a division is calculated from the MSB to the LSB and we know the 640(?) most significant bits. For most k it should be sufficient to only use the int part of both the log_2.

I'm looking into some math libs to see if we could make the whole calculation streamable to save even more computation time if k is wrong, which it will be most of the time

I will add some pseudo code in the evening... Got to go to work now.
haggi is offline   Reply With Quote
Old 25th November 2008, 14:48   #445  |  Link
loo3aem3ON
Registered User
 
Join Date: Sep 2008
Posts: 189
Quote:
Originally Posted by Accident View Post
This one I feel I have some legs to stand on. Since both the OS (since all network is BE), and BD+ itself is BE, we already have functions and support to handle it. But since normal use will not use snapshots, it doesn't matter too much if you can't use them on BE architectures.
I'm thinking about it.

Quote:
Originally Posted by Accident View Post
But either way, disregard my rantings, they weren't supposed to be checked in, I did so a little bit quickly to have it committed before the end of the weekend.
I sensed frustration so i tried to help. Someone should write a proper documentation about how to use the diffarchive files.

Quote:
Originally Posted by Accident View Post
Also, I read your documentation, nicely done.
It's far from finished. I'm trying to attract some volunteers to help me.

Quote:
Originally Posted by Accident View Post
Otherwise, libbluray-0.0.6 should be working with the known titles.
Did you fix TRAP_Sha to match the snapshots (for all operations)? If yes, i would like to copy your implementation because the intermediates are still wrong here (debugger).

@all: Please run some tests with the movies you have and report back with the titles of those Movies which don't work. Thank you.

Quote:
Originally Posted by haggi View Post
Code:
m = c^d - k*n
with k big enough to satisfy m < n where k is some big int
Let m=2 and c=8. Now try to estimate the number of bits 'k' has if you choose the given public modulus N for 'n' and the approximation d' of the private exponent for 'd'.

Quote:
Originally Posted by haggi View Post
My math guy doesn't reply ...
He probably crashed due to a memory overflow.

Quote:
Originally Posted by haggi View Post
For most k it should be sufficient to only use the int part of both the log_2.
It's a calculation over a finite field and i don't think you can just use the floor of the logarithm result. Anyway I didn't think about it in detail because k is too large to store anyway.

My suggestion for you is to experiment on a mini rsa example with small numbers and a public exponent of e = 3. Use maple/mathematica/matlab or whatever you have access to.

Last edited by loo3aem3ON; 25th November 2008 at 14:52.
loo3aem3ON is offline   Reply With Quote
Old 25th November 2008, 18:52   #446  |  Link
ala42
Registered User
 
ala42's Avatar
 
Join Date: Aug 2008
Posts: 19
Quote:
Originally Posted by haggi View Post
[CODE]m + k*n = c^d
First you should estimate the number of digits of c^d and then buy memory, much memory
ala42 is offline   Reply With Quote
Old 26th November 2008, 01:17   #447  |  Link
Accident
Registered User
 
Join Date: Aug 2002
Posts: 111
Quote:
Originally Posted by loo3aem3ON View Post

Did you fix TRAP_Sha to match the snapshots (for all operations)? If yes, i would like to copy your implementation because the intermediates are still wrong here (debugger).
It is not perfect, but it is better than it was before. I don't know how it compares to Debugger though. Generally byte 349 still differs.
(+addr is libbluray, -addr is snapshots)

Code:
[dlx] Sha(003DFD8C, 00002E58, 00002000, 00000002 SHA_FINAL
'post_trap_snapshots/post_trap_mem_000973.bin'
+003DFEE0 00 00 00 00 00 00 00 00 00 00 00 00 15 0D EC C7  |................|
-003DFEE0 00 00 00 00 00 00 00 00 00 80 00 00 15 0D EC C7  |................|

[dlx] Sha(003DEB1C, 003DED1C, 00000001, 00000001 SHA_INIT
'post_trap_snapshots/post_trap_mem_003145.bin'
+003DEB30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
-003DEB30 61 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |a...............|

[dlx] Sha(003DEB1C, 003DED1D, 00000002, 00000002 SHA_FINAL
[bdtest] comparing with 'post_trap_snapshots/post_trap_mem_003146.bin'
+003DEB30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
-003DEB30 61 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |a...............|
+003DEC70 00 00 00 00 00 00 00 00 00 00 00 00 E1 E1 E1 E1  |................|
-003DEC70 01 00 00 00 00 00 00 00 08 00 00 00 E1 E1 E1 E1  |................|
If one really wanted to, it could be made perfect.

Edit:

I think I have SHA_UPDATE just fine. But SHA_FINAL is harder. It is like they accidentally run one extra turn after final.

Code:
+003DEB30 64 63 62 61 68 67 66 65 6C 6B 6A 69 70 6F 6E 00  |dcbahgfelkjipon.|
-003DEB30 64 63 62 61 68 67 66 65 6C 6B 6A 69 6F 6E 6D 00  |dcbahgfelkjionm.|
Edit 2:

Both SHA_UPDATE and SHA_FINAL will process all of Jumper without mismatch. A couple of things are worth noting;
There is sha_ctxt_len set from last update, and then there is the "len" passed to SHA_FINAL. The logic in SHA_FINAL for the reference player leaves "dst" with length from "sha_ctxt_len" only. So "len" is not added on. The bytes left in "dst" are also in "sha_ctxt_len" (without len) in length.

However, this is only true if that length is 44 bytes or less. If longer, it is cleared.

Secondly, OpenSSL's SHA_CTXT after SHA_FINAL, when sha_ctxt_len + len is (a multiple of) "56", is cleared. Which means I do not clear "dst", but leave it untouched.

This makes for some ugly code, and really it isn't required, but it kept me entertained at work. Completely breaks if you change endian.

Code:
 uint32_t sha_reference(uint8_t *dst, SHA_CTX *sha, uint32_t len,
                       uint32_t total_len)
{
    uint32_t xlen, i;

    memcpy(&dst[ 0  ], &sha->h0, sizeof(sha->h0) );
    memcpy(&dst[ 4  ], &sha->h1, sizeof(sha->h1) );
    memcpy(&dst[ 8  ], &sha->h2, sizeof(sha->h2) );
    memcpy(&dst[ 12 ], &sha->h3, sizeof(sha->h3) );
    memcpy(&dst[ 16 ], &sha->h4, sizeof(sha->h4) );

    // Move all 4 bytes first:
    debugf("reference: copying all even 4s from %u\n", len);
    i = 0;
    xlen = len;
    while(xlen >= 4) {
        xlen -= 4;
        // Refence is big-endian.
        memcpy(&dst[ 20+i ], &sha->data[i/4], sizeof(sha->data[0]));
        i += 4;
    }

    debugf("reference: dealing with half-words: %u\n", len-i);

    // Deal with the remainder.
    switch(len - i) {
    case 0:
        break;
    case 3:
        dst[20 + i ]    = (sha->data[i/4] & 0xFF00) >> 8;
        dst[20 + i + 1] = (sha->data[i/4] & 0xFF0000) >> 16;
        dst[20 + i + 2] = (sha->data[i/4] & 0xFF000000) >> 24;
        break;
    case 2:
        dst[20 + i ]    = (sha->data[i/4] & 0xFF0000) >> 16;
        dst[20 + i + 1] = (sha->data[i/4] & 0xFF000000) >> 24;
        break;
    case 1:
        dst[20 + i] = (sha->data[i/4] & 0xFF000000) >> 24;
        break;
    }

    // Update len field, if needed
    if (total_len) {
        debugf("reference: updating total size %u\n", total_len);

        dst[340] = (uint8_t) ( total_len & 0xFF );
        dst[348] = (uint8_t) (( total_len * 8 ) & 0xFF );
        dst[349] = (uint8_t) ((( total_len * 8 ) & 0xFF00 ) >> 8 );
    }

    return 0;
}


..skip skip...

    case SHA_UPDATE:
        sha_ctxt_len += len;
        SHA1_Update(&osha, src, len);
        sha_reference(dst, &osha, osha.num, sha_ctxt_len);
        break;

    case SHA_FINAL:
        trap_Sha(dst, src, len, SHA_UPDATE); // Call above UPDATE to add in "len" bytes.
        SHA1_Final(digest, &osha);
        i = sha_ctxt_len - len;  // Compute size before UPDATE added "len".

        if (!(sha_ctxt_len%56)) {
            memset(&dst[20+i], 0, 352-20-i); // Clear after "i".
            sha_reference(dst, &osha, 0, sha_ctxt_len - len);
        } else if (i > 44) {
            memset(&dst[0], 0, 352);           // Clear all
            sha_reference(dst, &osha, 0, sha_ctxt_len - len);
            i = 0;
        } else {
            memset(&dst[0], 0, 352);           // Clear all, rebuild all.
            sha_reference(dst, &osha, i, sha_ctxt_len - len);
        }
        // Copy over the digest
        memcpy(dst, digest, sizeof(digest));
        sha_ctxt_len = 0;
        break;
It can most likely be further cleaned up if checked against mod 56.

Last edited by Accident; 27th November 2008 at 04:53.
Accident is offline   Reply With Quote
Old 26th November 2008, 20:58   #448  |  Link
loo3aem3ON
Registered User
 
Join Date: Sep 2008
Posts: 189
Quote:
Originally Posted by Accident View Post
It is not perfect, but it is better than it was before.
Thanks.

Quote:
Originally Posted by haggi View Post
Prove me wrong if you like
We will forgive you if you can't tell us the factorization of N or the private exponent.
I've studied a few papers and it is still unknown if factoring is more difficult than the rsa problem. There is some evidence that at least for small public exponents like e=3 it might be easier to solve m^(1/3) mod N than factoring N (or equivalently calculating the private exponent d). But currently nobody knows how to do that without the trapdoor 'd'.

A different approach to forge the certificates returned by TRAP_DeviceDiscovery would be to intervene with the subsequent SHA-1 hash calculation or the encryption of the signature part of the certificate. The interesting data paths (data dependencies) for a given content code program can be found among all automatically recorded data dependencies from the certificate.
loo3aem3ON is offline   Reply With Quote
Old 26th November 2008, 21:24   #449  |  Link
xkodi
Registered User
 
Join Date: Aug 2002
Posts: 221
what about this paper:

http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf

it describes timing attack on RSA:

Quote:
Our attack exposes the factorization of the RSA modulus. Let N = pq with q < p. We build approximations to q that get progressively closer as the attack proceeds. We call these approximations guesses. We refine our guess by learning bits of q one at a time, from most significant to least. Thus, our attack can be viewed as a binary search for q. After recovering the half-most significant bits of q, we can use Coppersmith’s algorithm [3] to retrieve the complete factorization.

Last edited by xkodi; 26th November 2008 at 21:32.
xkodi is offline   Reply With Quote
Old 26th November 2008, 21:52   #450  |  Link
loo3aem3ON
Registered User
 
Join Date: Sep 2008
Posts: 189
Quote:
Originally Posted by xkodi View Post
it describes timing attack on RSA:
I don't have access to any device that contains the private exponent. If i had one i wouldn't be sitting here writing postings
Those certificates are probably created on a pc without a network connection to rule out any side channel attacks.
loo3aem3ON is offline   Reply With Quote
Old 27th November 2008, 09:06   #451  |  Link
Schwa226
Registered User
 
Join Date: Sep 2004
Posts: 3
About RSA attack I can give you following information:

A 512 Bit RSA done with GGNFS:

Code:
with GGNFS on 2 A64 X2 4800+ in less then 2 month...
latsieve 11.10. to 14.11.
matbuild/matprune 14.11. to 16.11.
matsolve 16.11. to 30.11.
sqrt 30.11. to 01.12.
Boost GGNFS for Dualcore:

GGNFS adjusted for Intel Core2Duo :Rapidshare

Needed libgmp-3.dll DLL

May it helps...
Schwa226 is offline   Reply With Quote
Old 27th November 2008, 20:29   #452  |  Link
tteich
Registered User
 
Join Date: Jul 2004
Posts: 40
Quote:
Originally Posted by Schwa226 View Post
About RSA attack I can give you following information:

A 512 Bit RSA done with GGNFS:

Code:
with GGNFS on 2 A64 X2 4800+ in less then 2 month...
latsieve 11.10. to 14.11.
matbuild/matprune 14.11. to 16.11.
matsolve 16.11. to 30.11.
sqrt 30.11. to 01.12.
Boost GGNFS for Dualcore:

GGNFS adjusted for Intel Core2Duo :Rapidshare

Needed libgmp-3.dll DLL

May it helps...
While 512bit brute-force attacks can be done these days, this approach is really useless at a modulus size of 2048bits.
tteich is offline   Reply With Quote
Old 27th November 2008, 22:46   #453  |  Link
js06078
Registered User
 
Join Date: Aug 2008
Posts: 7
How about starting work on the newest batch of BD+ titles?

Here's a list of titles that confirmedly employ the newest version of BD+ (which AnyDVD-HD cannot handle yet):
Code:
Futurama: Bender's Game (USA)
Firefly, The Complete Series (USA)
Planet of the Apes (1968) (USA)
Planet of the Apes (all of the series) (USA)
Space Chimps (USA)
Meet Dave (USA)
X-Files 2 (USA)
X-Files 1 (USA)
Home Alone (USA)
The Day The Earth Stood Still: Special Edition (USA)

Horton Hears A Who (Hong Kong)

Predator 2 (1990) (UK)
Shine a Light (UK)
js06078 is offline   Reply With Quote
Old 27th November 2008, 22:49   #454  |  Link
loo3aem3ON
Registered User
 
Join Date: Sep 2008
Posts: 189
Quote:
Originally Posted by tteich View Post
While 512bit brute-force attacks can be done these days
The general number field sieve has a subexponential runtime (brute force is exponential). It's the latest and asymptotically fastest algorithm publicly known algorithm for integer factorization. Like all the other previous version (like the quadratic sieve) it is based on fermat factorization. That is finding a pair (x, y) with x>1,y>1 and x!=y which satisfies x^2 = y^2 (mod N). If such a pair is found the factorization of N can be obtained easily (in most cases). Now the gnfs employs very sophisticated techniques to find such pairs which are hard to understand (for me at least). A brute force search is hopeless even for a 160-bit rsa modulus.

Quote:
Originally Posted by tteich View Post
this approach is really useless at a modulus size of 2048bits.
Our N (public modulus N = p*q) is 1280 bit long:
Code:
N =
8B169F529C28B5D45DB5D1607B831BED31381D38AEF561A43E744326DD00765E
E7A47F353D4A8C507752B08A6671259AAF140E86EEB1D05D344EF801A5AFB150
3A82BE089DCF25618852199D26CC79AE99466A231999AAC6C26E7DDA662304A7
72D1B304C9CD0C724434D640E29BE64FBBE1E7993A30939D6FB925AE0C350896
14F89FBAE9B931FC01D4D10732EB62CA8878E1894BD82F3007806D75CE172B57
Like i said 1024 bit numbers (product of two prims of about the same length) can be factored currently with expensive hardware but not 1280-bit. Maybe with classified algorithms.

Quote:
Originally Posted by js06078 View Post
How about starting work on the newest batch of BD+ titles?
People have stopped reporting results so it's probably better to work on the documentation to improve the public understanding of BD+.

Quote:
Originally Posted by js06078 View Post
Here's a list of titles that confirmedly employ the newest version of BD+
Thanks for the list. Btw. there is only one version of BD+ but each disc can have a unique content code. Every time a content code doesn't run properly on SlySofts emulator they just call it a new version of BD+ but it's not.

Last edited by loo3aem3ON; 27th November 2008 at 23:03.
loo3aem3ON is offline   Reply With Quote
Old 28th November 2008, 01:12   #455  |  Link
Accident
Registered User
 
Join Date: Aug 2002
Posts: 111
Anyone able to upload the SVMs of those non-working disks? Top two looks to be most important
Accident is offline   Reply With Quote
Old 29th November 2008, 06:05   #456  |  Link
SixKiller
Registered User
 
Join Date: Oct 2006
Posts: 19
I`ve got X Files 2 EU laying right here. So what do you need exactly ? I'll upload it.
SixKiller is offline   Reply With Quote
Old 29th November 2008, 16:44   #457  |  Link
loo3aem3ON
Registered User
 
Join Date: Sep 2008
Posts: 189
Quote:
Originally Posted by SixKiller View Post
I`ve got X Files 2 EU laying right here. So what do you need exactly ? I'll upload it.
We need the contents of the BDSVM directory (without the BACKUP subdirectory). If any more data is required we will ask you for it.

Thank you for your support.
loo3aem3ON is offline   Reply With Quote
Old 29th November 2008, 21:43   #458  |  Link
kkloster21
Registered User
 
Join Date: Jun 2008
Posts: 117
i have Firefly the series on blu-ray. how can i send you the BDSVM directories (for each disc)?
kkloster21 is offline   Reply With Quote
Old 29th November 2008, 22:57   #459  |  Link
SixKiller
Registered User
 
Join Date: Oct 2006
Posts: 19
Ok so i uploaded this to rapidshare. http://rapidshare.de/files/41026609/..._java.rar.html

Hope you can use this .

Greets
SixKiller is offline   Reply With Quote
Old 30th November 2008, 00:49   #460  |  Link
loo3aem3ON
Registered User
 
Join Date: Sep 2008
Posts: 189
Quote:
Originally Posted by SixKiller View Post
Hope you can use this.
Thank you. I am getting a conversion table which means the key set is accepted. The segment keys are wrong though this is usually due to bugs or more likely in this case the wrong SHA-1 hashes of the files i don't have:
Code:
[I] TRAP_MediaSHAFileHash: Hashing AACS/MKB_RO.inf
[I] TRAP_MediaSHAFileHash: Hashing BDMV/STREAM/00008.m2ts
Please try to run the content code in the debugger: DVM Debugger v0.1.3.
I am confident that you will get the correct conversion table. You can test it's integrity using ConvTableView which is available from the Dump HD thread.

And it's not java opcode (like your filename suggests you think it is) but DLX like opcode. The content code runs on a DLX like processor. This processor is simulated by our emulator which is implemented in java. Accident has implemented the same emulator in C which runs several times faster.

Last edited by loo3aem3ON; 30th November 2008 at 00:51.
loo3aem3ON 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 22:50.


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