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. |
16th September 2008, 19:23 | #141 | Link | ||
Registered User
Join Date: Jun 2007
Posts: 215
|
Major update
Quote:
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);" - 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:
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++) { |
||
17th September 2008, 00:42 | #142 | Link | |
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 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:
Last edited by Oopho2ei; 17th September 2008 at 00:49. |
|
17th September 2008, 15:34 | #144 | Link |
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:
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. |
17th September 2008, 16:58 | #145 | Link | |
Guest
Posts: n/a
|
Thank you!
Quote:
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. |
|
17th September 2008, 17:44 | #146 | Link | |
Guest
Posts: n/a
|
Quote:
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. |
|
17th September 2008, 18:46 | #147 | Link |
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. |
17th September 2008, 19:01 | #148 | Link |
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. Edit: New traps Trap_Slot-Attach (0x410), Trap_Slot-Write (0x430) appear... Last edited by schluppo; 17th September 2008 at 22:59. |
18th September 2008, 10:23 | #149 | Link |
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. |
18th September 2008, 17:34 | #150 | Link | |
Guest
Posts: n/a
|
Quote:
package structure: Code:
/ AACS/ post_trap_snapshots/ BDSVM/ traces/ aacskeys_output.txt title.txt version.txt 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. |
|
19th September 2008, 15:12 | #151 | Link |
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. |
20th September 2008, 17:41 | #152 | Link |
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. |
21st September 2008, 10:57 | #153 | Link |
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. |
21st September 2008, 13:27 | #154 | Link |
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. |
22nd September 2008, 14:55 | #155 | Link |
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); 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. |
22nd September 2008, 17:31 | #156 | Link | |
Guest
Posts: n/a
|
Quote:
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. |
|
22nd September 2008, 18:13 | #157 | Link |
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 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:
Edit2: For "I Robot", there's the following problematic traps: Code:
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) Code:
TRAP_PrivateKey(UINT8 *dst, UINT8 *src, UINT32 srcLen, UINT32 controlWord, UINT32 keyID); 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. |
22nd September 2008, 23:33 | #158 | Link | |
Guest
Posts: n/a
|
Quote:
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 Last edited by Oopho2ei; 22nd September 2008 at 23:35. |
|
23rd September 2008, 02:56 | #159 | Link |
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) - 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 |
23rd September 2008, 05:31 | #160 | Link |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
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 ...
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ |
|
|