Finally handling BD+ (?)

[ala42]

Originally Posted by Disabled

I was thinking about using this lib for AES decryption or does anyone have better ideas?

Better take the AES implementation used in AACS keys

Originally Posted by Oopho2ei

Has anyone setup an sourceforge account for this project yet? Otherwise i would create one.

That is not worth the trouble, as it will be shut down quite soon.

[Disabled]

Originally Posted by ala42

Better take the AES implementation used in AACS keys

Does it have AES encryption? Or is it never used?

That is not worth the trouble, as it will be shut down quite soon.

Any other suggestions? Or just stick to the code - upload sheme?

[ala42]

Originally Posted by Disabled

Does it have AES encryption? Or is it never used?

Sorry, I do not know the crypto stuff details.

[Disabled]

Originally Posted by ala42

Sorry, I do not know the crypto stuff details.

Originally Posted by Oopho2ei

      case 0xFFF10000: // TODO: AES_ECB_ENCRYPT
      case 0xFFF10001: // TODO: AES_ECB_DECRYPT

So I thought it is at least in the standard...
And aacs_aes.h contains the following funtions:

calculate_subdev_proc_key
decrypt_c_value
decrypt_verification_data
calculate_volume_unique_key
decrypt_title_key
calculate_title_key_file_mac
calculate_title_key_file_hash
calculate_volume_id_mac

So... I might rip the decrypt_title_key if its doing "AES_ECB_DECRYPT_MEDIA_KEY" Oopho2ei refers to and evaluate later how I do the encryption. To be honest, even if TRAP_Aes are the first two traps issued, I'll first do the others, as I'm lazy and those look easier to do.

Originally Posted by ala42

That is not worth the trouble, as it will be shut down quite soon.

I have setup and account now. If you want to join our team please send me a private message for details. I will choose who gets access to the repository.

Originally Posted by Disabled

So... I might rip the decrypt_title_key if its doing "AES_ECB_DECRYPT_MEDIA_KEY" Oopho2ei refers to and evaluate later how I do the encryption. To be honest, even if TRAP_Aes are the first two traps issued, I'll first do the others, as I'm lazy and those look easier to do.

Leave Trap_AES for now. I haven't even described it yet.

[LoRd_MuldeR]

Originally Posted by Disabled

Any other suggestions? Or just stick to the code - upload sheme?

Create a new SVN repository at https://opensvn.csie.org/

[KenD00]

Originally Posted by Disabled

So... I might rip the decrypt_title_key if its doing "AES_ECB_DECRYPT_MEDIA_KEY"

aacskeys uses OpenSSL for AES, the methods in aacs_aes perform special tasks and are not general purpose AES functions. If you need AES only take a look at the good implementation from Brian Gladman.

[NeonMan]

Originally Posted by ala42

...That is not worth the trouble, as it will be shut down quite soon.

Sourceforge is known to shut down questionable projects, I think playfair received a DMCA and sourceforge removed all the project. I suggest launchpad but the best option is a personal server like zotty did with the defunct? decryptHD.
I know this is a quite delayed opinion but I couldn't find the time to write it and I think a CVS/SVN will help the development of this BD+ implementation and will also allow a faster error tracking.

[Disabled]

I'll just quote Oopho2ei:

Originally Posted by Oopho2ei

I have setup and account now. If you want to join our team please send me a private message for details. I will choose who gets access to the repository.

And about the AES implementation:

Leave Trap_AES for now. I haven't even described it yet.

Thus: Everyone who wants to help, just write him a message about the details. And we'll concentrate on the easy traps for a start until TRAP_AES and others are documented.

The next feature I implemented was an .svm parser. Now you can load a segment of an svm file, the BDSVM_CC header is verified, the length is calculated and then the data is copied to mem and the first 0x1000 bytes are zeroed.
And I again rewrote the dasm part, as It was a horror to debug both earlier versions. I hope thats the last time I'll do that.

Next stop: implementing traps
*edit* perhaps I'll restructure the code first...
*edit2* oh and perhaps I'll also rewrite the debug trace functions first...
restructuring the code is also a good thing, so more ppl can work on the code without the need of backporting or merging code.

Originally Posted by Disabled

Thus: Everyone who wants to help, just write him a message about the details. And we'll concentrate on the easy traps for a start until TRAP_AES and others are documented.

I don't hide the details. If i knew i would post them (except player specific stuff or course). Of course you can ask me and depending on your question(s) i will take a look.

Originally Posted by Disabled

The next feature I implemented was an .svm parser. Now you can load a segment of an svm file, the BDSVM_CC header is verified, the length is calculated and then the data is copied to mem and the first 0x1000 bytes are zeroed.
And I again rewrote the dasm part, as It was a horror to debug both earlier versions. I hope thats the last time I'll do that.

You are doing well. It's good to have you in the team.

For those who want to play around a bit with the emulator here is an extended program counter trace: http://uploaded.to/?id=gx84gh (~4 million entries)
If you need other (extended) traces please leave a note here or send me a private message.

Thanks to all who made suggestions where to host our software development project. We currently have a working repository but this is still very helpful if we get trouble and have to move to another location.

[KJI]

PortableBDVM.

A friend asked me to post this since his account wasn't yet allowed to post.

Originally Posted by KJI

PortableBDVM.

A friend asked me to post this since his account wasn't yet allowed to post.

The code looks very clean and well structured. I like it but i suggest to convert the image (section from 00000.svm) from big to little endian before execution. This should be more efficient compared to converting the data/code on every access.

Btw. if you want to test a trap implementation use the pc trace from posting #110 and ask me for some memory snapshots. You can also send me a modified memory snapshot so you can run your own program with your own data on a fully implemented player. I would need the initial register values and where to start and stop execution. But please comment your program and all the other changes you made so i can verify that no player specific data is retrieved. You would get the result as a memory/register file snapshot.

[loric]

Originally Posted by Oopho2ei

The code looks very clean and well structured. I like it but i suggest to convert the image (section from 00000.svm) from big to little endian before execution. This should be more efficient compared to converting the data/code on every access.

I beg to differ. In case of self-modifying code (and in the future bd+ may become that), what you suggest would break things. My suggestion is to behave as close as possible as the real BD+VM which, AFAIR, doesn't do any endianess conversion at load time.

BTW, great job.

Originally Posted by loric

I beg to differ. In case of self-modifying code (and in the future bd+ may become that), what you suggest would break things. My suggestion is to behave as close as possible as the real BD+VM which, AFAIR, doesn't do any endianess conversion at load time.

Please elaborate on this seĺf modifying code problem you see. If all memory accesses of instructions and traps are adapted according to our memory format (e.g. big endian or little endian) it's impossible for the program running on the vm to tell any difference. We could even store our instructions in some weird looking sql database tables. As long as everything is correctly implemented our memory organisation is fully transparent to the program which is running on our emulator. But what does change is the performance of our emulator.

Edit: The following archive contains a series of 16 snapshots taken after each of the first 16 trap executions. Example: post_trap_mem_000.bin + post_trap_reg_000.bin is a snapshot after the execution of the first trap which is Trap_AES (TRAP #110). Each snapshot is supposed to be loaded by your emulators with every new trap call you encounter when executing the given program (see the program counter trace in posting #110). In other words instead of executing the trap you only load the corresponding snapshot. After the 11th trap call you will find yourself right in the middle of the decryption process of the second section from the second file (00001.svm). Also there seem to be pictures in the *.svm files somewhere. So it's getting more interesting soon.

post trap snapshots: obsolete. see posting #130

(for those who don't know: we are executing the first section of http://uploaded.to/?id=jqstc8 which is one of the files stored in the BDSVM directory of every BD+ protected blue ray disc)

[sakman]

Looks like a date is also part of the header:
42 44 53 56 4D 5F 43 43 01 00 00 00 01 07 D7 0B 06 00 00 00 00 07 EC E4

07D7h=2007
0Bh=11 (November)
06h=6

[bmnot]

ok... sorry for the delay.

It's interesting how things evolved (nice work!).

As announced in my last post, I implemented a Java BDVM together with a graphical debugger.
It executes the BD+ program correctly until the 0x520 trap (memory dumps and registers match) - just as the other two VMs do, which I used as an orientation/prototype. The code is pretty similar (in my notion, it is slightly cleaner and more compact than my C implementation due to Java's convenient ByteBuffer classes which take care of endianness; Apart from that, the graphical Debugger is actually less code than the VM (294 SLOC vs. 245 SLOC) ; the implementation is big endian throughout; I just started looking at the traps).
I don't know whether this will be useful. I mainly implemented this for fun and educational purposes (for me and maybe others).

I agree that the implementation by KJI's friend is very clean (this probably doesn't matter, but I think 'vm->watchdog-=2;' in 'void ExecuteInstruction(BDVM *vm)' is not correct - see post #25).

Below is a screenshot of the debugger (ok, no screenshot... no idea where to upload it to.. it's included in the zip). BTW, the disassembling is dynamic (updated after every step).

Source (2 Java files - 1 VM and 1 Debugger) is available from here: http://uploaded.to/?id=s46hrd

[derbeDeus]

Originally Posted by sakman

Looks like a date is also part of the header:
42 44 53 56 4D 5F 43 43 01 00 00 00 01 07 D7 0B 06 00 00 00 00 07 EC E4

07D7h=2007
0Bh=11 (November)
06h=6

The BDSVM block format is:

BDSVM_header
-----8<------
magic      8 bytes - is string 'BDSVM_CC'
?version   1 byte  - always 1?
?unk9      4 bytes - usualy 1 (sometimes 0x2000 in AVP2, Jumper)
year       2 bytes
month      1 byte
day        6 bits
chunkSize 26 bits  - always 0? (don't remember why I named it)
datalen    4 bytes - size of code chunk following the header
----->8------
ContentCodeBlock of datalen bytes
CC_signature 40 bytes

that's padded with 0's to 2MB boundary

Originally Posted by bmnot

As announced in my last post, I implemented a Java BDVM together with a graphical debugger.

Looks awesome! Could you write a small howto to get it all working? My first attempts failed and i would like to try it

javac Debugger.java BDVM.java
Debugger.java:110: error: The method actionPerformed(ActionEvent) of type Debugger must override a superclass method
        public void actionPerformed(ActionEvent e) {

(javac invokes gcj-4.3 here.)

Could you also please load a snapshot for traps which are currently not implemented? See postings #114 for details.

[sakman]

Originally Posted by derbeDeus

The BDSVM block format is:

BDSVM_header
-----8<------
magic      8 bytes - is string 'BDSVM_CC'
?version   1 byte  - always 1?
?unk9      4 bytes - usualy 1 (sometimes 0x2000 in AVP2, Jumper)
year       2 bytes
month      1 byte
day        6 bits
chunkSize 26 bits  - always 0? (don't remember why I named it)
datalen    4 bytes - size of code chunk following the header
----->8------
ContentCodeBlock of datalen bytes
CC_signature 40 bytes

that's padded with 0's to 2MB boundary

Thanks derbeDeus. Matches what I saw looking at several .svm files from different discs. I did notice that the 4 bytes of "?unk9" changed to 2000h with that bunch of March/April 2008 discs (Hitman, Jumper, Alvin, etc.). Interesting that those discs also broke the initial BD+ support in AnyDVDHD.

[bmnot]

Okay, I made things a little simpler:
The binaries, a readme and an ant build script are included in this updated version: http://uploaded.to/?id=khplo8
Java 1.5 or newer is required in order to compile and run the Debugger (not sure whether gcj will work).
Ant is helpful for compiling.

Regarding the traces...
Executing with the help of the dumps was successful
I'm not sure whether this is already clear: r1 seems to contain the return values from the trap calls.
Apart from r1, the registers were always identical to the dumps (if I haven't missed something).
Note that loading the mem dumps and register dumps is not automated in the debugger. Currently this has to be done manually.

The Traps were: (<dump no>) <trap id> <instruction counter>
(0) 110
(1) 110
(2) 520
(3) 520
(4) 520
(5) 110
(6) 110
(7) 110
(8) 540 4527
(9) 110 13536
(10) 230 13547
(11) 110 22408
(12) 230 22419
(13) 110 31289
(14) 230 31300
(15) 110 40161
((16) 230 40172)