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 7th October 2008, 21:11   #201  |  Link
Oopho2ei
Guest
 
Posts: n/a
Ok, the last repository update looks fine. Now i would suggest we introduce some structure to the code. I have this in mind. You can already find the "bdsvm_player_interface.java" (unfinished) in the repository together with another new class "bdsvm_globals.java" which is supposed to be used for constants or global variables (if needed).

When i wrote the bdsvm_player_interface.java i had the BDVM.java still open and the autosave function seemed to have overwritten your latest patch. I have corrected this in revision 54. Sorry!

Edit: The svg image can be displayed by your browser.

Last edited by Oopho2ei; 7th October 2008 at 21:43.
  Reply With Quote
Old 7th October 2008, 23:37   #202  |  Link
Oopho2ei
Guest
 
Posts: n/a
We were able to find all the curve parameters for the ECDSA algorithm used by TRAP_PrivateKey. They can be found in posting #188.

You can now use any ECDSA implementation which fits your programming language.

Edit: The public key given in posting #188 can be found in the output of TRAP_DeviceDiscovery.

Last edited by Oopho2ei; 7th October 2008 at 23:47.
  Reply With Quote
Old 7th October 2008, 23:55   #203  |  Link
RunningSkittle
Skittle
 
RunningSkittle's Avatar
 
Join Date: Mar 2008
Posts: 539
For the non technical readers following this, could you give an update to how things are progressing? :]
RunningSkittle is offline   Reply With Quote
Old 8th October 2008, 04:29   #204  |  Link
schluppo
Guest
 
Posts: n/a
Here's a nice RAM.bin, if you put it in the same dir as the newest version of the debugger, this will take care of TRAP_DiscoveryRAM

This trap gives same result for same parameters and also same result for same parameters on both movies, so it seems like it really checks 'constant' areas of the virtual RAM. Most of the 'footprints' are by the way very similar to each other, maybe they are just offset to each other. I will investigate this when I have more time (could allow for a nicer treatment of this trap).

TRAP_SHA is fixed too (intermediate results were a pain in the *** for me).

Now only TRAP_PrivateKey remains to be treated for the first 5000 trap-calls and both movies. Will do that next...

Unguided execution stays in sync till trap call ~#500 (gets out of sync one trap call after TRAP_PrivateKey).

Edit: Sorry about the SVN-trouble, I was using a bad client and didn't think anyone would be bothered by it. The situation is fixed now.

Last edited by schluppo; 8th October 2008 at 04:38.
  Reply With Quote
Old 8th October 2008, 13:56   #205  |  Link
Oopho2ei
Guest
 
Posts: n/a
Quote:
Originally Posted by RunningSkittle View Post
For the non technical readers following this, could you give an update to how things are progressing? :]
The whole project consists of three major tasks:
1. vm instruction processing (95% done)
2. trap implementations (80% done)
3. event/callback processing (10 % done)

With the memory snapshots and traces (for the movies "The Day After Tomorrow" and "I Robot") from a licensed player we are able to debug and test parts of our implementations on real world examples.

All the keys we currently use for debugging will probably be revoked soon (if they have not been revoked already) so you probably won't be able to watch the latest BD+ protected movies with mplayer without new keys in the future.
The result of this project will hopefully be a working open source BD+ implementation which can be used together with linux and other free operating systems. I am hoping that DRM companies will look for bugs in our code to exploit so we can constantly improve the source until it finally meets the requirements of the secret BD+ specification.

Quote:
Originally Posted by schluppo View Post
I will investigate this when I have more time (could allow for a nicer treatment of this trap).
Have you (and other) looked at my idea of a modular BD+ implementation in posting #201? I believe it will be easier to understand and maintain the code. If you keep on squeezing everything into BDVM.java it will probably become even harder to "reorganize" the code later. Maybe bmnot can assist you and i am willing to help too.

Last edited by Oopho2ei; 8th October 2008 at 14:19.
  Reply With Quote
Old 8th October 2008, 16:50   #206  |  Link
FoxDisc
Registered User
 
Join Date: Jan 2007
Posts: 274
Quote:
Originally Posted by Oopho2ei View Post
All the keys we currently use for debugging will probably be revoked soon (if they have not been revoked already) so you probably won't be able to watch the latest BD+ protected movies with mplayer without new keys in the future.
Thanks for the summary. Are the keys used by BD+ the same keys defined in the AACS spec, or do they use their own keys?
FoxDisc is offline   Reply With Quote
Old 8th October 2008, 17:49   #207  |  Link
Oopho2ei
Guest
 
Posts: n/a
Quote:
Originally Posted by FoxDisc View Post
Thanks for the summary. Are the keys used by BD+ the same keys defined in the AACS spec, or do they use their own keys?
As for the ECDSA algorithm used by TRAP_PrivateKey we know that it uses different curve parameters (q,n, etc are different) so there is no relationship. I don't know about the 7 aes keys used by TRAP_Aes because they are all transformed (obfuscated) and nobody has bothered to reverse the transformation yet so we still use the corresponding transformed aes implementation. It's like using the keys without really knowing them. See postings #158 and #163 for details. It's some kind of whitebox attack resistant aes implementation. The basic idea to introduce random bijections which are applied at the end of one round and reversed before the beginning of the next round so to introduces a lot of noise to hide the underlying calculations and the round keys (including the key itself). Afaik unless those implementations don't use extremely large lookup tables they are all insecure. So that's the status on the keys.
  Reply With Quote
Old 9th October 2008, 02:06   #208  |  Link
Oopho2ei
Guest
 
Posts: n/a
I think qID =1 and qID=2 for TRAP_DeviceDiscovery might be the question for the primary and the secondary player certificate. Each certificate contains among other things the corresponding public key. You can find both public keys in posting #188. The structure of each certificate could be similar to those in the AACS specification which you can find in this pdf on page 42 (4.1 Drive Certificate).

I have furthermore analyzed the event snapshots i made (see posting #195). The differences are shown in this file. The following is an example of what was changed during the time the vm instruction processing was suspended (because watchdog <= 0):
Code:
PC  = 000994C4 -> PC  = 00001000 
r28 = 000994D8 -> r28 = 000994C4 
00000000 : 64DE004B E25BE65D 8D18BD98 14710E79 -> 00000220 00000000 00000001 00000057
00000020 : 96D3A639 B57F047B 6462D48B 7BFF5510 -> 00000000 00000000 6462D48B 7BFF5510
This shows you that the PC has been set to 0x1000 (a copy of the PC is stored in r28) and that the first 16 bytes of vm memory were replaced by "00000220 00000000 00000001 00000056". I currently think that 0x0220 is the event ID and then other 3 dwords are the parameters. When you study the file you will see, that the last parameter is incremented with every new event (which occurred about every 30s). If it suddenly jumps to a different value than this is because of me switching to a different scene in the movie
Finally 8 bytes at address 00000020h are overwritten with zeros but i don't know why.

Assuming the value at 00000000h really is the event id then i have witnessed those events:
Code:
00000010 = occurred when i pressed the drive eject buttion, 1 parameter
00000110 = occurred at start of movie playback, 2 parameters
00000210 = occurred at start of movie playback, 2 parameters
00000220 = regular event (about every 30s), 3 parameters
I think i will find some answers when i follow the content code starting at 0x1000.
  Reply With Quote
Old 9th October 2008, 03:35   #209  |  Link
schluppo
Guest
 
Posts: n/a
The snapshot-packages contained some breaks too:

DAT v1.02:
Code:
...                                    // Initialization etc.
TRAP_Finished;

break 0x110(0,0xFFFF);
TRAP_0x20(0,0x1000);
TRAP_Finished;

break 0x210(0,1);
TRAP_0x510(2,1,0x1EFB6C);              // TRAP_DeviceAccess?
TRAP_0x510(0,1,0x1EFB6C);              // TRAP_DeviceAccess?
TRAP_Finished;

break 0x110(0,1);
...                                    // Lots of trap-testing here
TRAP_0x20(0xFCD9E,0xEFAF8);
TRAP_Finished;

break 0x010(0);
I Robot v1.02:
Code:
...                                    // Initialization etc.
TRAP_Finished;

break 0x110(0,0xFFFF);
TRAP_0x20(0,0x1000);
TRAP_Finished;

break 0x210(0,1);
TRAP_0x510(2,1,0x3DFB70);              // TRAP_DeviceAccess?
TRAP_0x510(0,1,0x3DFB70);              // TRAP_DeviceAccess?
TRAP_Finished;

break 0x110(0,1);
...                                    // Lots of trap-testing here
TRAP_0x20(0xFCBDA,0x2DFAFC);
TRAP_Finished;

break 0x010(0);
As you can see, the 'program' seems to be the same for both movies.

The player can tell the content code what to do by changing the first 20 bytes before it 'reactivates' the VM:
Code:
break 0x110(0,0xFFFF): ?
break 0x210(0,1): check whether disc is in drive and ready (?)
break 0x110(0,1): test bd+ system / player and get ready for playback
break 0x220(0,1,n): decrypt block <n>
break 0x010(0): shut down
Most interesting would be to see which traps are called after break 0x220(0,1,n) was invoked. The content code needs to get data, decrypt it and output it somehow. We don't know yet which traps are used for input and output (slots? 0x510? 0x20?).
  Reply With Quote
Old 9th October 2008, 13:08   #210  |  Link
Oopho2ei
Guest
 
Posts: n/a
Quote:
Originally Posted by schluppo View Post
Most interesting would be to see which traps are called after break 0x220(0,1,n) was invoked.
You can start implementing an event handler which writes the above data to the to the beginning of vm memory and sets registers pc and r28 appropriately. Then you only need to run your emulator and see what happens.
Quote:
Originally Posted by schluppo View Post
We don't know yet which traps are used for input and output (slots? 0x510? 0x20?).
Certainly not via slots. Probably through area 0x000000-0x000FFF and the results from the content code can maybe be passed to the player via Trap#0020.

Last edited by Oopho2ei; 9th October 2008 at 14:19.
  Reply With Quote
Old 9th October 2008, 22:48   #211  |  Link
schluppo
Guest
 
Posts: n/a
I looked a bit into the trap-call behaviour after different kind of breaks (all for DATv1.02).

When manually invoked after VM-initialization (i.e. after the first 5000 trap-calls), break 0x110(0,0xFFFF), break 0x210(0,1), break 0x110(0,1) and break 0x010(0) behave as expected.

Here's what I saw for break 0x220(0,1,n):

Depending on the value of <n>, several different traps are being checked (40-500 trap calls, some with bogus parameters, some with real parameters - they are being checked in exactly the same order as in break 0x110(0,1) - I found no new traps being called and there are no calls of known traps with new parameters).

I went through break 0x220(0,1,n) with 10 different values for n, and everytime, the last 5 trap calls in my log were identical:

Code:
IC: 75197 Trap #169: trap_0x410(0,14)= TRAP-SlotAttach
IC: 75203 Trap #170: trap_0x420(1ef964,0)= TRAP-SlotRead
IC: 75689 Trap #171: trap_0x520(1,1,22b48,1efa58)= TRAP_DeviceDiscovery
IC: 75789 Trap #172: trap_0x520(1,2,22b48,1efa58)= TRAP_DeviceDiscovery
IC: 78102 Trap #173: trap_0x10(ffffffff)= TRAP_Finished
By the way, everything before these 5 trap-calls is 'trap self-checking'.

So, the content code tries to read slot 0, but the current implementation of TRAP-SlotRead does not give the wanted result, hence the content code calls TRAP_DeviceDiscovery twice and then finishes (seems to be some kind of standard behavior in case that a trap gives a bad result).
  Reply With Quote
Old 9th October 2008, 23:48   #212  |  Link
Oopho2ei
Guest
 
Posts: n/a
Thanks for that information. So it looks like you need even longer snapshot packages now

In the meantime could you check where the trap id is accessed in the content code and against what values it is compared to. Or maybe there is a lookup table which leads to the event id specific code. You can also record program counter traces for different event ids and compare them to see up to which point they are identical. The reason for this is simply to get a list of all event IDs that exist/handled by the content code. There are supposed to be 5 other event IDs (so 9 in total).

Last edited by Oopho2ei; 10th October 2008 at 00:01.
  Reply With Quote
Old 10th October 2008, 02:33   #213  |  Link
schluppo
Guest
 
Posts: n/a
From now on, I will write 'events' instead of 'breaks', whenever apropriate.

The code directly (first thirty instructions) after the break checks for equality of memory[0] (which holds <event_id>) with values from here:

Code:
0x22070: 18210200 80270200 FFFFFFFF 10020000 
0x22080: 24250200 20020000 C4230200 10010000
0x22090: 60220200 00000000 18210200 10000000
0x220A0: 54260200 00000000 00000000 1000BD6F
0x220B0: 0C00DDE3 1000DD67 F8FFFEE3 00005DE0
(first from 0x2207C, then 0x22084 etc.)

If for instance <event_id> = 0x220, the according adress 0x223C4 is reached with IC = 47.

This indicates, that this version of BD+ has just the four events we saw so far (plus maybe event 0x0?).

Edit: Here's a small list of the traps which are called for the events in DATv1.02:

Code:
event 0x0: trap calls #1529-#2676 (the first 1528 trap calls are loading files and setting up the machine etc.).

event 0x10: execute just TRAP_Finished.

event 0x110(1): trap calls #2682-#5053.
event 0x110(2): trap calls #2682-#5053 (plus 4 additional TRAP_Random calls in the middle of testing TRAP_Random).
event 0x110(0xFFFF): execute TRAP_0x20 and then TRAP_Finished.

event 0x210: execute just TRAP_Finished (?)

Each of the following continues as stated in posting #211 after the testing is done:
event 0x210(1,1): trap calls #2682 - #2850 (= test TRAP_AddWithCarry).
event 0x210(1,2): trap calls #3760 - #3843 (= test TRAP_Random).
event 0x210(1,3): identical to event 0x210(1,1).
event 0x210(1,4): trap calls #3894 - #4001 (= test TRAP_AES).
event 0x210(1,5): trap calls #3473 - #3550 (= test TRAP_MemMove). Then custom test TRAP_MemMove.
event 0x210(1,6): trap calls #3551 - #3612 (= test TRAP_MemSearch). Then custom test TRAP_MemSearch.
event 0x210(1,7): trap calls #3142 - #3342 (= test TRAP_XorBlock).
event 0x210(1,8): identical to event 0x210(1,6).
event 0x210(1,9): identical to event 0x210(1,1).
event 0x210(1,a): trap calls #2851 - #3141 (= test TRAP_MultiplyWithRipple).
event 0x210(1,b): identical to event 0x210(1,5).
event 0x210(1,c): identical to event 0x210(1,2).
event 0x210(1,d): trap calls #4003 - #4442 (= test TRAP_DeviceDiscovery).
event 0x210(1,e): trap calls #4443 - #5049 (= test TRAP_DiscoveryRAM). Also trap calls #2070 - #2674 are the same.
event 0x210(1,f): trap calls #3614 - #3759 (= test TRAP_SHA).
event 0x210(1,10): identical to event 0x210(1,2).
event 0x210(1,11): identical to event 0x210(1,d).
event 0x210(1,12): identical to event 0x210(1,4).
event 0x210(1,13): identical to event 0x210(1,d).
event 0x210(1,14): trap calls #3344 - #3473 (= test TRAP_MemSet). Then custom test TRAP_MemSet.
event 0x210(1,15): identical to event 0x210(1,d).
event 0x210(1,16): identical to event 0x210(1,14).
...
event 0x210(1,0x56): custom test TRAP_MemMove.
event 0x210(1,0x85): trap calls #3844 - #3893 (= test TRAP_PrivateKey).
event 0x210(1,0xD3): identical to event 0x210(1,1).
event 0x210(1,0xE1): identical to event 0x210(1,f).
event 0x210(1,0x107): identical to event 0x210(1,d).
event 0x210(1,0x145): custom test TRAP_MemMove.
This should now cover all the trap-testing for Event 0x210. Note that it seems as if the current debugger gets past all of these tests (I logged all of this without snapshot- or PC/WD-guidance).

Last edited by schluppo; 10th October 2008 at 04:43.
  Reply With Quote
Old 10th October 2008, 12:38   #214  |  Link
Oopho2ei
Guest
 
Posts: n/a
So the table is actually:
Code:
event ID | handler
--------------------
00000210 | 00022524
00000220 | 000223C4
00000110 | 00022260
00000000 | 00022118
00000010 | 00022654
So we got a new unknown event ID: 0.

I am planning to upload the new code base for the debugger soon (when it can be compiled without error/warning). I will help you finding the mistakes i made. Remember what i told you about the parameter checking: if the return value is wrong i get the trap parameters and the expected return value so i can fix the documentation

Edit: a possible terribly broken snapshot of the new codebase is in the repository. At least it compiles without errors. A new file "flash.bin" (link removed) is needed which contains all slots and 256 byte extra data (so 128kb).

Edit: the debugger with the new code base runs fairly stable now . There are still some bugs which will be sorted out soon. You need a new flash.bin because the one above had the the wrong byte order. A visible change for the user is the new monospace font and the leading zeros.



I hope schluppo is not too mad at me about what i did to his code

Last edited by Oopho2ei; 12th October 2008 at 10:25.
  Reply With Quote
Old 12th October 2008, 02:12   #215  |  Link
schluppo
Guest
 
Posts: n/a
Looks quite fine.

One thing I noticed, is that you don't print out the value of trap-counter, instruction-counter or the trap-name, whenever a trap is executed. Also you always output 6 parameters even though a trap may have less parameters. I found the logging from previous versions more helpful when trying to quickly analyze which traps had actually been called during a run of the debugger.

Parameter Checking for TRAP_SlotRead is not correct - trap call #2037 is problematic:
Code:
IC: 37177656 Trap #2037: trap_0x420(1efd08,ffffffff)= TRAP-SlotRead
Parameter Checking for TRAP_AddWithCarry is not correct - trap call #2686 is throwing Array-Out-of-Bounds exception:
Code:
IC: 37506486 Trap #2686: trap_0x210(1ef928,3fffe0,8)= TRAP_AddWithCarry
Apart from that, I have no objections, nice work

Currently, I am idle. So, It would be great if you could provide a new snapshot-package, containing one or two calls of event 0x220.
  Reply With Quote
Old 12th October 2008, 10:42   #216  |  Link
Oopho2ei
Guest
 
Posts: n/a
Quote:
Originally Posted by schluppo View Post
One thing I noticed, is that you don't print out the value of trap-counter, instruction-counter or the trap-name, whenever a trap is executed. Also you always output 6 parameters even though a trap may have less parameters. I found the logging from previous versions more helpful when trying to quickly analyze which traps had actually been called during a run of the debugger.
I don't mind if you change it to something more useful. But please use System.out.format("bla = %08X, foo = %04d \n", bla, foo); or similar for console outputs.

Quote:
Originally Posted by schluppo View Post
Parameter Checking for TRAP_SlotRead is not correct - trap call #2037 is problematic:
Code:
IC: 37177656 Trap #2037: trap_0x420(1efd08,ffffffff)= TRAP-SlotRead
Yes and i have tried to fix it but without success. The slotid = 0xFFFFFFFF in TRAP_SlotRead means: read the currently attached slot. I have seen the check for slotid == 0xFFFFFFFF in the parameter checking code but didn't trace it into the following calls. My current guess is that something is wrong with the currently attached slot or there is no (valid?) slot attached.

Quote:
Originally Posted by schluppo View Post
Parameter Checking for TRAP_AddWithCarry is not correct - trap call #2686 is throwing Array-Out-of-Bounds exception:
Code:
IC: 37506486 Trap #2686: trap_0x210(1ef928,3fffe0,8)= TRAP_AddWithCarry
Oups. I must have missed that one.

Quote:
Originally Posted by schluppo View Post
Currently, I am idle. So, It would be great if you could provide a new snapshot-package, containing one or two calls of event 0x220.
I would suggest we fix the code of the debugger so it can run without snapshots and look at what the content code does for the events we create. For example TRAP_PrivateKey is still broken (i believe the problem is the conversion of the ASN.1 SEQUENCE (~46 bytes) in which the signature is represented by bouncycastle to the 40 byte raw hex data we have to place at 'dst'.
In a longer snapshot package you will probably only see the changes in the 0x00-0x30 memory area so i am not sure if this can help us. The above problem with TRAP_SlotRead shows me that there are still some things to study before we can turn to event handling/passing. Creating new longer snapshot packages is a full day of work for me.

Last edited by Oopho2ei; 12th October 2008 at 10:53.
  Reply With Quote
Old 13th October 2008, 01:42   #217  |  Link
schluppo
Guest
 
Posts: n/a
I don't mean to sound negative in any way, but I saw a few things I found that TRAP_AddWithCarry is broken now.

Code:
#002694 TRAP_AddWithCarry      (001EF928, 003FFFE0, 00000008);
Byte 1EF92C: snapshot: FF execute: FE
Byte 1EF92E: snapshot: FF execute: FE
Byte 1EF930: snapshot: FF execute: FE
Byte 1EF932: snapshot: FF execute: FE
Byte 1EF934: snapshot: FF execute: FE
Byte 1EF936: snapshot: FF execute: FE
Byte 1EF938: snapshot: FF execute: FE
Byte 1EF93A: snapshot: FF execute: FE
Byte 1EF93C: snapshot: FF execute: FE
Byte 1EF93E: snapshot: FF execute: FE
Byte 1EF940: snapshot: FF execute: FE
Byte 1EF942: snapshot: FF execute: FE
Byte 1EF944: snapshot: FF execute: FE
Byte 1EF946: snapshot: FF execute: FE
and so on. Looks like the carry value is not respected. Also the return value is still not correct:
Code:
#002732 TRAP_AddWithCarry      (001ED740, 001EFAB0, 00000001);
Register error at trap number 2732:
post_reg_snapshot:
00000000 00000001 00000000 00000000 0002282C 00000004 001ED740 00000000 001EB738
00000001 001EFA70 00000000 001EF9B0 001EF9F0 001EFA30 001EF748 001EF970 001EF9D0
001EF92C 00000200 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 000994B0 001EB6C4 001EFAD8 0005BF90
post_reg_execute:
00000000 00000000 00000000 00000000 0002282C 00000004 001ED740 00000000 001EB738
00000001 001EFA70 00000000 001EF9B0 001EF9F0 001EFA30 001EF748 001EF970 001EF9D0
001EF92C 00000200 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 000994B0 001EB6C4 001EFAD8 0005BF90
Byte 1ED741: snapshot: 67 execute: 68
Byte 1ED742: snapshot: 89 execute: 88
Memory Error at trap 2732
(you need to return the carry flag).

Furthermore, parameter checking (or implementation?) is not correct any more for TRAP_MultiplyWithRipple:
Code:
#002852 TRAP_MultiplyWithRipple(001EF7B0, 00000004, 00000008, 00000000);
java.lang.ArrayIndexOutOfBoundsException: 35
        at bdvm.bdsvm_player_traps.MultiplyWithRipple(bdsvm_player_traps.java:847)
        at bdvm.bdsvm_player_interface.TRAP_handler(bdsvm_player_interface.java:698)
Edit: Also, I thought that automatic loading of post-break-snapshots was convenient for testing the VM. Is there a reason to remove it already?

Last edited by schluppo; 13th October 2008 at 01:56.
  Reply With Quote
Old 13th October 2008, 02:38   #218  |  Link
Oopho2ei
Guest
 
Posts: n/a
Quote:
Originally Posted by schluppo View Post
I don't mean to sound negative in any way, but I saw a few things I found that TRAP_AddWithCarry is broken now.
Quote:
Originally Posted by schluppo View Post
Furthermore, parameter checking (or implementation?) is not correct any more for TRAP_MultiplyWithRipple:
Those are the normal regressions when you make deeper changes in the code. I will fix it.

Quote:
Originally Posted by schluppo View Post
Edit: Also, I thought that automatic loading of post-break-snapshots was convenient for testing the VM. Is there a reason to remove it already?
Yes it is convenient and the code is not gone either (you can still load all different revisions we made from the repository). I didn't like the way it was implemented.

The signature generation in TRAP_PrivateKey seems to be working now with the Bouncycastle library. I have spent like 10 hours trying to figure out why the signature verification in the content code always failed. The reason was simply that in the Bouncycastle implementation "ECDSA" means = SHA-1 + ECDSA. What a waste of time

To install the library i have downloaded the bcprov-jdk16-141.jar and placed the file in the directory "/usr/lib/j2sdk1.6-sun/jre/lib/ext". Furthermore i have added one line to the "java.security" located in the directory "/usr/lib/j2sdk1.6-sun/jre/lib/security" so it looks like this:
Code:
#
# List of providers and their preference orders (see above):
#                                                           
security.provider.1=sun.security.provider.Sun               
security.provider.2=sun.security.rsa.SunRsaSign             
security.provider.3=com.sun.net.ssl.internal.ssl.Provider   
security.provider.4=com.sun.crypto.provider.SunJCE          
security.provider.5=sun.security.jgss.SunProvider           
security.provider.6=com.sun.security.sasl.Provider          
security.provider.7=org.jcp.xml.dsig.internal.dom.XMLDSigRI 
security.provider.8=sun.security.smartcardio.SunPCSC        
security.provider.9=org.bouncycastle.jce.provider.BouncyCastleProvider
The last line is new ^

You can see if the signature verification succeeded by looking at the console output of the debugger when executing the BDSVM files from "The Day After Tomorrow":
Code:
#000496 TRAP_Random            (00002348, 00000010);                              
#000497 TRAP_Sha               (001EF924, 001EFB24, 00000020, 00000003);          
#000498 TRAP_PrivateKey        (00000000, 00005514, 00002348, 00000010, 00000000);
#000499 TRAP_DeviceDiscovery   (00000001, 00000001, 001EF794, 001EF78C);          
#000500 TRAP_Aes               (0005B430, 0005B430, 00000001, 0004B470, 00000000);
#000501 TRAP_DeviceDiscovery   (00000001, 00000002, 001EFCC8, 001EFCC4);
If the verification failed then the above TRAP_Aes call is replaced by another TRAP_DeviceDiscovery call.

Currently the debugger seems to run correctly up to the first TRAP_Finished without the help of snapshots. At least i get the impression by just looking at the console output.

To those java experts out there: Is there a way to add the Bouncycastle libraries without modifying the java installation on the user side? We only need the ECDSA implementation.

Last edited by Oopho2ei; 13th October 2008 at 02:43.
  Reply With Quote
Old 13th October 2008, 03:29   #219  |  Link
schluppo
Guest
 
Posts: n/a
Works fine for me. I'm glad that TRAP_PrivateKey is working now

I let the debugger run without guidance till the first call of TRAP_Finished and a quick compare of the snapshots 'post_trap_reg_002643.bin' and 'post_trap_mem_002643.bin' with the contents of memory and registers after unguided execution revealed lots of differences. Anyway, since the trap-execution is in correct order, I just hope/assume that these differences are stemming from normal (legitimate) changes in the random input data.

Feeding a memory-snapshot which is signalling event 0x220(0,1,n) to the debugger still does not get past the first TRAP_SlotRead. I assume that the data which is read from slot 0 should be of a specific pattern (which the debugger does not know yet).
Code:
#000252 TRAP-SlotAttach        (00000000, 00000014);
#000253 TRAP-SlotRead          (001EF964, 00000000);
#000254 TRAP_DeviceDiscovery   (00000001, 00000001, 00022B48, 001EFA58);
#000255 TRAP_DeviceDiscovery   (00000001, 00000002, 00022B48, 001EFA58);
#000256 TRAP_Finished          ();
Edit: Warning - I just let "I Robot v1.02" run without guidance and even though I do not have the big stream file (BDMV\STREAM\00001.m2ts) which is being hashed by the content code, and the hash-result hence must have been wrong, the debugger reached TRAP_Finish with just a very minor change in the sequence of executed trap calls: #2052 to #2084 were omitted (these trap calls were just checking the slot-trap's parameter checks). So it seems to be the case, that bad trap-results do not necessarily lead to immediate shut down of the VM. This makes it harder to see whether traps (especially the ones with nondeterministic result, since snapshots help for the other traps) really behave well.

Also invoking event 0x110(0,1) on the memory/registers after unguided execution of "DAT v1.02" gives a different order of trap calls than in the snapshot package, indicating, that there might have been a trap-call with bad result.

Last edited by schluppo; 13th October 2008 at 04:37.
  Reply With Quote
Old 13th October 2008, 15:20   #220  |  Link
Oopho2ei
Guest
 
Posts: n/a
I have rewritten the code for TRAP_AddWithCarry and TRAP_MultiplyWithRipple. The site where we host our repository ( assembla.com ) currently seems to have technical difficulties so here is the patch. I will commit the changes as soon as the problems are solved.

Edit: there was still a bug in TRAP_AddWithCarry which is fixed now. So above is a new patch (only one line has changed).

Edit: The problems at assembla.com seem to be solved now. The latest changes are in the repository

Edit: TRAP_SlotAttach is likely completely wrong. The patent states:
Quote:
Originally Posted by Patent
Using the address and the specified length, the procedure then computes a cryptographic hash (e.g., using SHA-1) of the code. If the hash result does not match the value of the authorization hash stored in the slot then slot zero is attached and an error is returned.
What you do is comparing the specified content code section with a database of all code sections you have seen so far (array "slotCode[][]"). Can you explain to me why?

Edit: TRAP_SlotRead( *, 0xFFFFFFFF ) is wrong. This call writes the three dwords "0x00000000, 0x00000000, 0x00000007" to dst and returns unless the currently attached slot number is zero in which case it returns STATUS_INVALID_PARAMETER. It looks like the entire slot handling has to be rewritten

Last edited by Oopho2ei; 13th October 2008 at 20:45.
  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 05:29.


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