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 16th September 2008, 19:23   #141  |  Link
bmnot
Registered User
 
Join Date: Jun 2007
Posts: 215
Major update

Quote:
Originally Posted by Oopho2ei
Some suggestions:
- for branches you better show the absolute address and the not the relative address
- could you automatically load the snapshots?
- add a data view window (maybe double the number of columns for the register view and cut its height by half to make space for a small data view window below)
- reset the watchdog timer with ever trap call to 0x7FFFFFFF
- display the parameters of the trap call directly before it is executed (e.g. by commenting the values in the stack window)
- support of data breakpoints
- color the registers red which have been changed since the last step/run
- maybe assign some hotkeys
okay... some good ideas . These are implemented in version 0.2.0 of the Debugger: http://uploaded.to/?id=f0sxrm

Some notes:
- I found it somewhat ugly to hard-code the snapshot-names for auto-loading, so there's a menu option "Get post-trap snapshots from directory...". The Debugger will collect the files with the correct size in this directory and sort them alphabetically. It will load the next snapshot in the list whenever a trap was executed.
- There are read and write data breakpoints (displayed red and green). These can be set by selecting an area in the memory view and pressing the appropriate toolbar button.
- The traps including descriptions are parsed from a file that looks like this:

Code:
000010: void TRAP_Yield(UINT32 sleepTime); ?",
000020: UINT32 TRAP_EventGet(UINT8 *evBuf, UINT32 len); ?",
000110: UINT32 TRAP_Aes(UINT8 *dst, UINT8 *src, UINT32 len, UINT8 *key, UINT32 opOrKeyID);",
000120: UINT32 TRAP_PrivateKey(UINT8 *dst, UINT8 *src, UINT32 srcLen, UINT32 controlWord, UINT32 keyID); ?",
000130: UINT32 TRAP_Random(UINT8 *dst, UINT32 len);",
000140: UINT32 TRAP_Sha(UINT8 *dst, UINT8 *src, UINT32 len, UINT32 op); ?",
000210: UINT32 TRAP_AddWithCarry(UINT32 *dst, UINT32 *src, UINT32 len);",
000220: UINT8* TRAP_Memsearch(UINT8 *region, UINT32 regionLen, UINT8 *searchData, UINT32 searchDataLen); ?",
000230: void TRAP_XorBlock(UINT32 *dst, UINT32 *src, UINT32 len);",
000310: void TRAP_Memmove(UINT8 *dst, UINT8 *src, UINT32 len);",
000320: 5 parameters -> ?",
000330: void TRAP_Memset(UINT8 *dst, UINT8 fillvalue, UINT32 len);",
000410: UINT32 TRAP-SlotAttach(UINT32 slot, UINT32 codeLen, UINT32 reqPriority); ?", 
000420: UINT32 TRAP-SlotRead(UINT8 *dst, UINT32 slot);",
000430: UINT32 TRAP_SlotWrite(UINT8 *newContents);",
000510: UINT32 TRAP_MediaReadRequest(UINT32 offsetHigh, UINT32 offsetLow, UINT32 len); ?",
000520: UINT32 TRAP_DeviceDiscovery(UINT32 dev, UINT32 qID, UINT8 *buf, UINT32 *len);",
000530: 3 parameters -> ?",
000540: 5 parameters -> ?",
000550: 6 parameters -> ?",
000560: 4 parameters -> ?",
000570: 0 parameters ... nop/vendor specific?",
008010: UINT32 TRAP_DebugLog(UINT8 *txt, UINT32 len);"
- The menu command "Load alternative trap descriptions..." allows loading modified such trap descriptions from a file. This can be useful if new information on traps is discovered - the Debugger will show updated, appropriate comments.
- Unfortunately, I haven't found time to look at the traps any further yet. This will be next. Hardening the VM with the 50000(!) snapshots is also interesting. Fortunately, schluppo already started on both
I integrated and slightly beautified his trap implementations (yesterday's version; hope I didn't break anything).
@schluppo It should be pretty straightforward to integrate your newest trap implementations.

Quote:
Originally Posted by schluppo
The debugger is quite slow on inputting PC-traces. 4,000,000 PC values take 10min+.
Ok, this was clearly a flaw in the implementation - fixed that, too. Actually, this was only a minor detail:

Code:
          File f = ...
/*before*/ for (int i = 0; i < f.length(); i++) {  // hammering the file system
/*now   */ for (int i = 0, l = (int)f.length(); i < l; i++) {
BTW, I could post more often. However, I am somewhat concerned about staying anonymous (although the activities should be perfectly legal here) - so I currently don't.
bmnot is offline   Reply With Quote
Old 17th September 2008, 00:42   #142  |  Link
Oopho2ei
Guest
 
Posts: n/a
This is the output of aacskeys for this movie:
Code:
MKBv:                         4
Processing key:               F190A1E8178D80643494394F8031D9C8
Encrypted C-value:            95247837F8A71FFDDBE8B0D3C2EE0575
Corresponding uv:             000000A0

Decrypted C-value:            A174BE1DF3678FFCDBF8D43A7AF32B40
Media key:                    A174BE1DF3678FFCDBF8D43A7AF32BE0

Encrypted verification data:  810D5EE8B3011C4E8474E7702D12F55D
Decr verif data should be:    0123456789ABCDEF
Decrypted verification data:  0123456789ABCDEFD33493CD1DD12AC7

Drive FW info:                1.01

AGID:                         00

Volume ID (AACSBYPASS):       1D2FC67462FDF986357A8F808FA1298B
Volume Unique Key:            C5E868608ACD6700C2AC6A5E6AF533D9
Unit Key File Hash (DiscID):  6B63A40DD45F17A466B0C5CC35BF1500B4E0A9BA
Encrypted Unit Key 1:         6941CB89A6EEAB466AAB4B4F55DDA667

Decrypted Unit Key 1:         98E4D277F21AC464EFB0C0CA19FB50FD
I am posting this now because it's possible that some of these keys are used by the traps. It's unlikely that any of the important keys actually appear in memory though.
I have looked at the implementation of Trap_AES where the last parameter is a Key ID (in my particular case KeyID = 4). Like stated in the patent you have to first decrypt (aes-128-ecb) the encrypted aes key (pointed to by 4th parameter) using the player key and then use the resulting decrypted key to decrypt the data (second parameter) just like the last parameter were 0xFFF10001.
BUT the aes implementation doing the decryption of the key (first step) in my player has been transformed by some random mappings (different lookup tables basically) so the keys i could give you only work with the mapped aes version. Either i can figure out how to reverse the transformation or we have to use the mapped aes version for which i would provide a sample implementation in C. In the meantime you can play around with the keys above. Maybe it's one of them.

Quote:
Originally Posted by bmnot View Post
okay... some good ideas . These are implemented in version 0.2.0 of the Debugger: http://uploaded.to/?id=f0sxrm
Another great release. Thanks a lot!

Last edited by Oopho2ei; 17th September 2008 at 00:49.
  Reply With Quote
Old 17th September 2008, 10:07   #143  |  Link
tteich
Registered User
 
Join Date: Jul 2004
Posts: 40
Quote:
Originally Posted by KJI View Post
PortableBDVM.

A friend asked me to post this since his account wasn't yet allowed to post.
Something's wrong. The site appears to be offline.
tteich is offline   Reply With Quote
Old 17th September 2008, 15:34   #144  |  Link
schluppo
Guest
 
Posts: n/a
Here's a new edit of the debugger:
http://uploaded.to/?id=vj3a9w

I took bmnot's newest version and changed the following:
  1. Put return value of traps to R1 after trap_execution.
  2. If a snapshot is loaded, compare result of trap_execution with the snapshot. Output nice error message in console, if there are any differences in memory or registers.
  3. If you select a snaphot-directory containing at least 500 or so snapshots, "Run" will now run till trap 490, without loading snapshots (in order to run a bit faster - since the first 490 traps are treated correctly and since loading and comparing snapshots takes some time). From trap 490 on, snapshots will be loaded (and trap execution results will be compared to them).
  4. Treatment of traps. The following is an exhaustive list of TRAPs that I encountered yet:
    Code:
    • 0x110: TRAP_Aes(); Cases AES_Decrypt and AES_Encrypt are implemented correctly and generically. Case AES_Decrypt_Media did not occur yet but is an easy case, provided that we have the mediakey. The other cases use player keys which i don't have and are thus not handled in a generic way yet.
    • 0x140: TRAP_Sha(); The only case that occured yet (SHA_BLOCK) is handled correctly and generically. Other cases are simple and can quickly be added if needed.
    • 0x230: TRAP_XorBlock(); This is handled correctly and generically.
    • 0x520: TRAP_DeviceDiscovery(); This is handled correctly, but with constant results. For qId=0x3, the result seems to depend on a key that I don't have, so this trap is not treated generically yet.
    • 0x530: TRAP_???(); This trap is concerned with getting some data from the player. It is treated correctly, but not in a really generic way yet.
    • 0x540: TRAP_MediaReadFile(); This is handled correctly and generically.
Summarizing on the traps: As long as they do not use keys that I don't have, they are treated in a (hopefully) generic way.

Note, that this version of the debugger is still getting out of sync with PC-trace at about 3000 instructions after trap #494 (TRAP_SHA). But even if no PC-trace is used, the post_snapshot #495 contains more differences than are justified by the execution of trap #495 (TRAP_deviceDiscovery(1,1,...)). Since the traps are treated correctly according to the snapshots, I come to the conclusion that there is a bug in the debugger's basic VM. I don't have the knowledge to find and fix it though.

As long as this is not fixed, I can not get past trap #494 in a reasonable way, so it would be great if somebody could look into the execution after trap #494.

Edit: This version of the debugger is also in the repository now.

Last edited by schluppo; 17th September 2008 at 16:23.
  Reply With Quote
Old 17th September 2008, 16:58   #145  |  Link
Oopho2ei
Guest
 
Posts: n/a
Quote:
Originally Posted by schluppo View Post
Here's a new edit of the debugger:
Thank you!

Quote:
Originally Posted by schluppo View Post
As long as this is not fixed, I can not get past trap #494 in a reasonable way, so it would be great if somebody could look into the execution after trap #494.
I have asked someone who i think got past this point. This will hopefully get fixed soon.

This is a list of interesting details i was told anonymously:
- Trap_DeviceDiscovery, Trap_PrivateKey and Trap_AES use player specific keys
- the virtual machine is event driven but there is no "Trap_EventGet" (events are passed in a different way)
- Trap_010 is Trap_Finish
- the trap vector table in the 00000.svm is sorted alphabetically by trap names (all the traps are called from this table ... you know which one)
- Trap_520(1,3, 0x4514, 0x1EFF84) outputs the volume id at 0x4514+0x18 so question id '3' == 'what's is the volume id of the current media?'
- ...

A big thanks for sharing this information with us.

Last edited by Oopho2ei; 17th September 2008 at 17:05.
  Reply With Quote
Old 17th September 2008, 17:44   #146  |  Link
Oopho2ei
Guest
 
Posts: n/a
Quote:
Originally Posted by schluppo View Post
As long as this is not fixed, I can not get past trap #494 in a reasonable way, so it would be great if somebody could look into the execution after trap #494.
The person who got it running assumes your LB implementation is wrong and I was able to prove this .
Try the following: open the 00000.svm with a hex editor and overwrite the bytes at 0x1018 with the following sequence: "C8 00 10 04 88" This is cmd32 reading from 0x1004 (which is set to 0x88 by the last byte you replace). Now run the first command with the debugger. the result is stored in R0 and should be 0x88 but yours is 0xFFFFFF88. So somehow the byte is sign extended to integer.
  Reply With Quote
Old 17th September 2008, 18:46   #147  |  Link
Disabled
Registered User
 
Join Date: Aug 2004
Posts: 211
After a long time I'm reporting back. I stopped coding as the C99 and Java versions showed up, as I don't think there is a need for a third one.
Very good work of all of you contributing, including those anonymous ones!
On a side note, I fixed the "signed LB extension" bug in the svn. (Just remove the byte cast in L201.) I wasn't able to test it with the full run, as I don't have all the traces and files here, but it works on your test case and is now consistent with LW.
And I think it would be great to have more ppl hanging around the svn. At least bmnot should join it and I don't know who else is contributing or wants to contribute to the Java version or if there are more working on the C99 one they could of course use it too.
Disabled is offline   Reply With Quote
Old 17th September 2008, 19:01   #148  |  Link
schluppo
Guest
 
Posts: n/a
Confirmed, removing the byte cast in L201 fixes this, now the debugger goes to trap #499 at instruction counter 6584939 with correct PC.

New traps Trap_Random (0x130), Trap_PrivateKey(0x120) and Trap-SlotRead(0x420) occur:
Code:
trap 494 is trap_520(1,1,0x1EFA94,0x1EF890->0x190); <works ok>

trap 495 is trap_140(0x1ef894,0x1efa94,7c,3); writes 0x7c bytes to 1ef894. <works ok>

trap 496 is trap_130(0x2348, 0x10); returns 0; puts 16 bytes to 0x2348: 2cb40ca4 65236776 0454806a 0eca1b92

trap 497 is trap_140(0x1ef924,0x1ef924,0x20,3); writes 0x20 bytes to 1ef924. <works ok>

trap 498 is trap_120(0, 0x5514, 0x2348, 0x10, 0); returns 0; writes 40 bytes to 5514:

4aa6ef81 dc4cf6b7 0237eaff e7d14a93
cfdc52e2 74811e16 2f770cfb ee11ce92
2a4e9fc4 beab67bd

trap 499 is trap_520(1, 1, 0x1ef794, 0x1ef794); <works ok>

PC goes out of sync between trap 499 and trap 500 due to nondeterministic behaviour.
Snaphot contents is ok though for at least the next 500 traps:

trap 500 is trap_110(0x5b430,0x5b430,?,?); returns 0; this case is not handled yet...

trap 501 is trap_520(1, 2, 0x1efcc8, 0x1efcc4); <works ok>

trap 502 is trap_520(1, 1, 0x1efe08, 0x1efcc4); <works ok>

trap 503 is trap_420(0x1efb14,0); returns 0. reads 256? bytes to 0xx1efb14.

trap 504 is trap_420(0x1efb14,1); returns 0. reads 256? bytes to 0xx1efb14.

trap 505 is trap_420(0x1efb14,2); returns 0; reads 256? bytes to 0xx1efb14.

the following 495 traps all read slots (there are 511 accessible slots, first 498 of them are read here).
Only the first slot contains data, the rest filled with 256? times 0x00.
Trap-Calls which are already handled correctly are indicated with "<works ok>" above...

Edit: New traps Trap_Slot-Attach (0x410), Trap_Slot-Write (0x430) appear...

Last edited by schluppo; 17th September 2008 at 22:59.
  Reply With Quote
Old 18th September 2008, 10:23   #149  |  Link
Disabled
Registered User
 
Join Date: Aug 2004
Posts: 211
I took the adventure to download all the PC and Trap traces, about 1.5GB together. As I found that pretty inconvenient, I recompressed them using 7zip and found they fit in less than 10MB! They still extract to ~20GB and are exactly the same as what Oopho2ei offered, but are much less on the download side. So here they are.
Under Windows I recommend extracting them to a compressed folder, then they will use just about 2GB of space and it will probably speed everything up, as the HD is the limiting factor for me. Linux users might use SquashFS or something similar.
As an extra and because I don't like uploaded.to that much I also uploaded the BDSVM folder here. *edit* This is the same as in post #130, just another server.

Last edited by Disabled; 18th September 2008 at 18:17.
Disabled is offline   Reply With Quote
Old 18th September 2008, 17:34   #150  |  Link
Oopho2ei
Guest
 
Posts: n/a
Quote:
Originally Posted by Disabled View Post
As I found that pretty inconvenient, I recompressed them using 7zip and found they fit in less than 10MB! They still extract to ~20GB and are exactly the same as what Oopho2ei offered, but are much less on the download side.
Awesome! I will make a package of the current movie ("The Day After Tomorrow") and of a "new" movie i have just bought ("I robot"). This time the instruction trace and the program counter trace will match the snapshots!

package structure:
Code:
/
AACS/
post_trap_snapshots/
BDSVM/
traces/
aacskeys_output.txt
title.txt
version.txt
Edit: i am currently compressing both packages so they should be available online in a few hours.

Edit:
Package 1 ("The Day After Tomorrow"): http://uploaded.to/?id=yodttu
Package 2 ("I robot"): http://uploaded.to/?id=mej65b

Last edited by Oopho2ei; 19th September 2008 at 15:07.
  Reply With Quote
Old 19th September 2008, 15:12   #151  |  Link
Oopho2ei
Guest
 
Posts: n/a
Upload complete (see posting #130). You should now have 3 independent traces (including the old/deprecated one).

ToDo:
- compare the two traces of "The Day After Tomorrow" to identify "random" data returned by the traps (like timestamps)
- compare one trace of "The Day After Tomorrow" with a trace of "I Robot" and look at the the result of the traps to identify disc/movie dependent data.

Good luck/have fun. I will continue to study Trap_AES as planned.

Edit: Trap_AES: the key with opOrKeyID=4 is a constant stored in the key section of the player. It's transformed and i need to reverse the transformation so you can use it with your unmodified AES implementations.

Edit: Trap_010 seems to update the Watchdog Timer. After the first call of Trap_010 in "The Day After Tomorrow" the timer is set to 0FA0h (or decimal: 4000) so program execution will break quickly afterwards. Very likely some changes are made to the guest system so don't panic if you run into problems after this trap. I will look into this soon.

Edit: After Trap_010 execution continues at *r28 (thanks to [anonymous])

Edit: I have compared two snapshots before and after the first Trap_020 call in "The Day After Tomorrow" and found no difference.

Edit: I made a snapshot before and after the first execution break (by the watchdog timer reaching 0) and found no differences. The watchdog timer was again set to 0FA0h (=4000) so this regular interruption is maybe to allow other player functions to be run on the processor of the player. But probably more likely this is a regular check for player events.

Last edited by Oopho2ei; 20th September 2008 at 17:41.
  Reply With Quote
Old 20th September 2008, 17:41   #152  |  Link
Oopho2ei
Guest
 
Posts: n/a
There seems to be a problem with the current post-trap snapshots after the first Trap_010 call. Please do not try to execute beyond Trap_010 and instead focus on the other traps which have been executed up to that point. I will notify you when this issue has been solved.

Edit: I've made new packages for irobot and dat which both contain an extra directory "post_break_snapshots" and an additional trace file "timer_trace.bin". Like with the post_trap_snapshots you have to implement a "break counter" which is incremented every time the watchdog timer (see timer_trace.bin) reaches zero (or becomes negative).

How to use this:
As usual you decrement the timer at the end of every instruction according to the table in posting #25. When this is done you check the value of the timer. Only if it is less or equal zero the program execution is interrupted and you load the snapshot post_break_???_[cnt].bin, increment the break counter [cnt] and then continue execution. As long as the timer is positive program execution continues normally and you don't have to worry about this.

Note: I now use %06d instead of %03d for the filenames.

The new packages will be available in a few hours.

Last edited by Oopho2ei; 21st September 2008 at 11:22.
  Reply With Quote
Old 21st September 2008, 10:57   #153  |  Link
Oopho2ei
Guest
 
Posts: n/a
The new packages are available now:

Package (v1.02) for "The Day After Tomorrow": http://uploaded.to/?id=g93e2g
Package (v1.02) for "I Robot": http://uploaded.to/?id=svpn7q

Last edited by Oopho2ei; 21st September 2008 at 15:32.
  Reply With Quote
Old 21st September 2008, 13:27   #154  |  Link
Oopho2ei
Guest
 
Posts: n/a
A quick note about the trap names: Some traps are mentioned in the pdf (http://securityevaluators.com/pdf/spdc_aacs_2005.pdf) which are not listed in the patent. For example TRAP_Finished (#010) and TRAP_DiscoveryRAM (possible #530). So maybe we can complete our list soon.

I keep on updating the list in posting #97: http://forum.doom9.org/showpost.php?...1&postcount=97 Please use this as reference and do not make your own versions. If you see a mistake or maybe you want to add something please tell me.

Last edited by Oopho2ei; 21st September 2008 at 14:21.
  Reply With Quote
Old 22nd September 2008, 14:55   #155  |  Link
schluppo
Guest
 
Posts: n/a
Was busy the last few days, now I have time again...

Trap_Random (0x130) implemented, Trap_MediaReadFile (0x540) bug fixed. Trap_PrivateKey has different ordering of parameters than in the patent text:

Code:
UINT32 TRAP_PrivateKey(UINT32 controlWord, UINT8 *dst, UINT8 *src, UINT32 srcLen, UINT32 keyID);
vs
UINT32 TRAP_PrivateKey(UINT8 *dst, UINT8 *src, UINT32 srcLen, UINT32 controlWord, UINT32 keyID);
Next: slot traps.

I am still using the old snapshot-series, will get the new snapshots soon and start looking at the traps which appear there.

Will upload new edition of the debugger soon...

Edit: TRAP-SlotRead, TRAP-SlotWrite, TRAP-SlotAttach implemented (in a rather sloppy way - need to check how these are treated for in other BD-discs).

Last edited by schluppo; 22nd September 2008 at 17:09.
  Reply With Quote
Old 22nd September 2008, 17:31   #156  |  Link
Oopho2ei
Guest
 
Posts: n/a
Quote:
Originally Posted by schluppo View Post
Code:
UINT32 TRAP_PrivateKey(UINT32 controlWord, UINT8 *dst, UINT8 *src, UINT32 srcLen, UINT32 keyID);
Can you please also tell us your observations which make you believe Trap#120 really is "TRAP_PrivateKey" with that signature? I am not saying you are wrong or anything. It's just hard to tell if you are (almost) sure or just guessing.

Btw. Please use the version number when you refer to a particular snapshot package. Note that we we have now packages from two different blue ray discs.

Last edited by Oopho2ei; 22nd September 2008 at 17:37.
  Reply With Quote
Old 22nd September 2008, 18:13   #157  |  Link
schluppo
Guest
 
Posts: n/a
I was using the old version of "Day after Tomorrow" with the 5000 snapshots in 5 big packages. Apart from the AES-Traps which are using player keys (especially TRAP_AES(..,..,..,..,0)) and apart from TRAP_Random which should produce random numbers, the first 1600 of those snapshots are identical to the memory after execution of the coded treatment of those traps. Anyway, I'm extracting v1.02 of both movies now and will look at them soon in order to improve the treatment of traps.

Further, trap 0x120 could have any other name, I have no observation telling me for sure, that it's "Trap_PrivateKey". I was just using that name since it's in the trap-list at this position.

Also, a thing about trap 0x410: I'm not sure wether this really is TRAP-SlotAttach, since that should have three parameters, according to the patent. Until now, I found just one call of trap 0x410:

Code:
trap 1002 at ic 6732573 is trap_410(0x1f3,0xc)			// slot-attach(499,12)?
returns 0x80000001
Notice, that I think, that 0x800000001 is the 'error' return status number.

Later, the program tries to read from this slot 499 (just receiving 256 times 0x00 and returning 0x0 in R1) and afterwards tries to write to slot 499 (returning 0x0 in R1 indicating successfull execution of the write-process?).

Maybe BD+ is using a more simple variant of this trap without security code / hash.

Edit: I compared the behaviour of the traps in the old snapshot-pack (the one with the 5 big archives) and the new v1.02 (both packs are for the movie "Day After Tomorrow"). Here is a list of traps with different behaviour in the first 1600 trap-calls:
Code:
  • TRAP_DeviceDiscovery(1,3,4514,1eff84) - qID #3: ~5 bytes difference due to timestamp
  • TRAP_120(0, 0x5514, 0x2348, 0x10, 0) (TRAP_PrivateKey?) - all 40 bytes of the result are different
  • TRAP-SlotRead(0x1efb14,0) - 32 bytes different content in slot 0
The other trap-calls behave in exactly the same way as before (apart from TRAP_Random of course).

Edit2: For "I Robot", there's the following problematic traps:
Code:
  • TRAP_DeviceDiscovery(1,3): ~5 bytes difference due to timestamp and 16 bytes difference since the Volume-ID of this BD is different. I will implement this soon (we need a text file (or so) input anyway, containing all the keys needed to emulate the traps).
  • The AES-Trap behaves badly - as expected (we still need a way to emulate AES-decryption using player-keys).
  • TRAP_120(0, 0x54F0, 0x2348, 0x10, 0): all 40 bytes of the result are different.
  • At IC 2123976, trap_0x550(0x7F868,0xF,0,0x13FFE00,0x3DFCC8,0x7F850) writes 20 bytes to 0x7F850 and returns 0x0 in R1. Don't know what this trap could be. Another call of this: trap_0x550(0x81FBC,0xF,0,0,0x3DFC0C,0x3DFC10) writes 20 bytes to 0x3DFC10 and returns 0x0 in R1. One more call writing 20 bytes to the last parameter and returning 0x0 in R1: trap_0x550(0x3D5E8,0x16,5,0x27123800,0x3DFC00,0x3DFC04)
  • TRAP-SlotRead(xx,0): 68 bytes different content in slot 0.
Edit 3:
For trap 0x120 (TRAP_PrivateKey?), I found the following: It's second parameter is a pointer <pDst> where the result is going to be put. It's third parameter is a pointer <pSrc> to the input of this trap. It's fourth parameter <source_len> is the length of this input (this input is 0xFF-terminated). Further, this trap seems to behave non-deterministic.

I would guess, it is indeed TRAP_PrivateKey, just because the parameters are so close to what they should be. Imagine we have controlWord=0 and keyID=0 (indicating the case where this trap produces a signature of it's input, using a private key), then a call of this trap looks similar to the specification of the trap in the patent text:
Code:
trap_120(0, <pDst>, <pSrc>, <source_len>, 0)
vs.
Code:
TRAP_PrivateKey(UINT8 *dst, UINT8 *src, UINT32 srcLen, UINT32 controlWord, UINT32 keyID);
Furthermore, the patent mentions, that the keyID is "normally" 0 for TRAP_PrivateKey, and in every call of trap_120 that I have seen so far, the first and last parameter were 0.

However, the patent also says, that for keyID=0, the result of TRAP_PrivateKey will be a "2048-bit RSA-Signature". I guess that means 256 bytes of result, but trap_120 just produces 40 bytes of result.

Last edited by schluppo; 22nd September 2008 at 22:57.
  Reply With Quote
Old 22nd September 2008, 23:33   #158  |  Link
Oopho2ei
Guest
 
Posts: n/a
Quote:
Originally Posted by schluppo View Post
[*] The AES-Trap behaves badly - as expected (we still need a way to emulate AES-decryption using player-keys).
You can start to merge this into your code: http://uploaded.to/?id=w7qe3s
This sample program decrypts the given encrypted key using (a transformed version of) player key 4. The resulting decrypted key is transformed too so you need another obfuscated version of aes which i have not implemented yet. Together with this missing second half you will be able to use the player keys (to some extend) without really knowing them. These keys will probably be revoked quickly so it's not worth trying to remove all the different obfuscation layers just to find a "equivalent" key which can be used with a "normal" aes implementation.

Compile with:
Code:
gcc -o wbaes whitebox_aes_decrypt.c whitebox_aes_decrypt.h
Another thing: no trap is currently fully implemented because they all lack the initial parameter check. If a parameter combination is not allowed (eg. negative length, invalid address,...) the trap is supposed to refuse the execution (and maybe return 80000001h). But this isn't your fault because nobody has looked at this yet.

Last edited by Oopho2ei; 22nd September 2008 at 23:35.
  Reply With Quote
Old 23rd September 2008, 02:56   #159  |  Link
schluppo
Guest
 
Posts: n/a
Bug report for the basic debugger:

- Loading a big (>16mb) PC-trace file throws the following exception:

Code:
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
        at java.nio.HeapByteBuffer.<init>(Unknown Source)
        at java.nio.ByteBuffer.allocate(Unknown Source)
This prevents people from using a PC-trace beyond ~8,000,000 instructions. Even splitting the big file into smaller 16mb-files and trying to reload traces after every 8,000,000 instructions does not help and throws the same exception.

- The VM hangs up after Trap#2044 for I Robot, v1.02 / Trap#2029 for DAT, v1.02 (I manually compared PC to the respective PC-traces and it is for both titles in sync up to these traps). This happens due to PC getting value FE83AAFD+ and thus causing array out-of-bounds access. IC is at 38,756,448 / 39,061,664 by this time. I guess the program takes at this point a jump that confuses the debugger's VM to jump somewhere else than it should.

On another note, I added a log of the first 2000+ trap-calls for both titles. It should be self-explanatory and also contains all the differences between the 'implemented' traps and the snapshots: http://uploaded.to/?id=f8kiq8
  Reply With Quote
Old 23rd September 2008, 05:31   #160  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 12,811
The nasty "Java heap space" OutOfMemoryError happens all the time, when your Java app needs a certain amount of memory.
But it can be solved by giving the JVM more memory for the heap space. You can do it like this:

java.exe -Xms128m -Xmx768m ...
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.


LoRd_MuldeR 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 10:25.


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