View Single Post
Old 29th October 2008, 00:06   #296  |  Link
Oopho2ei
Guest
 
Posts: n/a
Thanks. I hope that other people try to write their own implementations and make their source code public. The debugger source code and the information from this thread and the repository should be enough to provide basic BD+ support. I am no professional programmer and it might also be better to integrate the core functionality of the debugger into DumpHD instead of having lots of smaller tools.

Quote:
Originally Posted by frogman View Post
- New (Blu-ray): Added support for new version of the BD+ copy protection
I've updated to the latest firmware version (sept. 2008) and couldn't find any major changes in my player. No new command or traps. Not even new AES keys or a different ECDSA certificate.
I believe this statement means the BD+ implementation in AnyDVD-HD is buggy/incomplete (like ours) and new versions of the content code are handled incorrectly because for example a particular trap was never used before (or never used with certain parameters) and was therefor insufficiently tested or not implemented (like TRAP_RunNative).

Quote:
Originally Posted by chavonbravo View Post
With this working, we're pretty much at the level of anydvd hd, as long as it's mkbv7 or below, right?
I currently can't answer that question because i only have 2 BD+ protected movies and only one of them (The Day After Tomorrow) has been tested so far. There is still some work to be done. Also using the debugger to get the conversion table and then repair every m2ts file with the small c program i wrote is too complicated for the average user. I am hoping other people will like KenD00 will integrate the code into their tools to make watching BD+ protected movies in linux possible for the average user.

Quote:
Originally Posted by Accident View Post
Is it not peculiar the offset from conversion table are only 32bit, can it not then scramble beyond 4GB boundary?
Sorry i didn't see you've edited your posting. You will find the answer when you look at the way the address is calculated line 151-156. As you can see it's adjusted with a positive value and then multiplied with 0xC0 (the buffer size). I haven't calculated the highest possible address but it's obviously much larger than 2^32. Also take a look at Schluppos example in posting #287.

Last edited by Oopho2ei; 29th October 2008 at 00:48.
  Reply With Quote