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 > Programming and Hacking > Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 6th October 2009, 14:25   #1  |  Link
kreet
Registered User
 
Join Date: Jul 2009
Posts: 41
BD(+) Toolset 2.0

we all really want there to be a full modular open-source solution for playing back BD movies under linux.

a lot of excellent work was done by people here on the forums to reverse engineer and re-implement the AACS and BD+ systems.

as a result there are currently a number of foss tools available to decrypt and view movies, but:
1) there is no support for newer titles (no new processing keys)
2) there is no support for BD-J applications so linux users dont get the full experience
3) there is partial support for BD+ protected titles (newer titles which use the BDSVM-BDJ bridge are broken)

id like to suggest that we work together to build a set of ansi-c libraries which implement all tools necessary to view and playback all known titles, including full bdj application support.

while this toolset (library?) should definitely reuse code and knowledge from the various existing tools (libaacskeys, libbluray, ...) i think we need to work to make a cohesive set of libraries which are as portable as possible.

in order to push forward with this, were looking for volunteers to help with refactoring/writing the following:
1) an aacs library with full support for authentication, subset difference/key derivation and all known 'drive hacks'. the library should be as conform with the spec as much as possible. it should be possible to specify certificates and keys in configuration.
2) a bdj environment consisting of a jvm, jrt libraries, the bluray java libraries and the necessary java-native bridges.
3) a bdsvm implementation which allows for easy execution of content code. it should be possible to emulate different bdsvms run-time configuration.
4) a bluray library (libbluray) which serves as a 'host driver' all other libraries. it should be able to receive a path to a BD disc and perform all actions necessary to extract content. it should set up the bridge between the bdsvm and the bdj engine, etc.
5) a plugin for mplayer/vlc which wraps the bluray library and provides full BD support (including BDJ navigation) in the existing player.

obviously, it is possible that there will only be a single library (libbluray) with all other functionality inside it (except the media player plugins). but this is up for discussion.

all code should be ansi-c, so that it is as portable as possible and meets plugin-requirements for mplayer and vlc.

certificates, keys and other sensitive data might need to be obfuscated... but this can also be decided later.

at the moment, im focusing on reversing a couple of players to learn as much as possible about the bdsvm, the bdj environment etc and making good progress. anyone who wants to help out by starting to write/rewrite the libraries should please speak up!

so who wants to volunteer?!? what do you want to help with?

we need:
1) c developers with strong knowledge of design patterns
2) developers with knowledge of java and java internals
3) people with experience reversing java bytecode (including obfuscated bytecode)
4) people with experience reversing binary executables (windows, embedded), especially COM, packed binaries etc.
5) someone to set up and maintain a source repository (git/svn) and some kind of wiki (trac?)
6) testers with access to lots of movies and different drives (not too many testers at this point!)

you can contact me here or on irc://irc.efnet.net/#doom9

update: i created a project here: http://www.assembla.com/spaces/libbluray/ it would be great if someone would volunteer to maintain and admin this project space. so i can focus on reversing and development.

happy hacking
kreet

Last edited by kreet; 8th October 2009 at 15:59. Reason: adding link to project space
kreet is offline   Reply With Quote
Old 6th October 2009, 14:37   #2  |  Link
JBM
Registered User
 
Join Date: May 2009
Posts: 7
Count me in. Hacking C is where I'll be of most use.

-JBM
JBM is offline   Reply With Quote
Old 6th October 2009, 14:40   #3  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,901
Quote:
Originally Posted by JBM View Post
Hacking C
What is "Hacking C"?
Guest is offline   Reply With Quote
Old 6th October 2009, 15:10   #4  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,901
But why would you prefer to "hack" it instead of writing it in a sound professional manner?
Guest is offline   Reply With Quote
Old 6th October 2009, 15:26   #5  |  Link
kreet
Registered User
 
Join Date: Jul 2009
Posts: 41
guys, i appreciate the discussion of semantics, but can we try and keep this thread 'clean'? no ot?
kreet is offline   Reply With Quote
Old 6th October 2009, 16:00   #6  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,901
It's development, so development methodologies are fair game.
Guest is offline   Reply With Quote
Old 6th October 2009, 22:23   #7  |  Link
cRTrn13
Registered User
 
cRTrn13's Avatar
 
Join Date: Aug 2009
Posts: 31
"hacking" doesn't necessarily imply any specific dev methodology.

And back ot... I'm up for it too (have been working on a lib of my own for quite some time now - but would be good to combine efforts)
cRTrn13 is offline   Reply With Quote
Old 7th October 2009, 10:24   #8  |  Link
kreet
Registered User
 
Join Date: Jul 2009
Posts: 41
we still need more volunteers ppl.

anyone want to take on the svn/wiki stuff? as soon as we have a home for the project, we can start pushing forward.
kreet is offline   Reply With Quote
Old 7th October 2009, 11:54   #9  |  Link
KenD00
Registered User
 
Join Date: Jan 2007
Location: Internet
Posts: 378
Well, just for the record i'd like to note i'm still here too and i am actually working on aacskeys but progress is ... slow ... very slow. And it's not exactly the direction you prefer, namely it's going the C++ route because i want to revive an old idea, get feature proof for AACS 1.0 and very maybe getting rid of java .

KenD00 is offline   Reply With Quote
Old 7th October 2009, 15:42   #10  |  Link
kreet
Registered User
 
Join Date: Jul 2009
Posts: 41
KenD00: the reason i think we should go for c instead of c++ is because of portability. java is really a no go

maybe we can get you involved here?

id very much like to get a feature-complete spec-compliant aacs library as part of this new set of tools. what was your old idea?
kreet is offline   Reply With Quote
Old 7th October 2009, 15:59   #11  |  Link
JBM
Registered User
 
Join Date: May 2009
Posts: 7
I'm going to side with kreet on this issue - I'm a huge fan of C++ (it's what I use in my day job) but portability really is the name of the game here.

It would be great to have you on board KenD00 - someone with your experience in the area will be an enormous help!

-JBM
JBM is offline   Reply With Quote
Old 7th October 2009, 19:34   #12  |  Link
cRTrn13
Registered User
 
cRTrn13's Avatar
 
Join Date: Aug 2009
Posts: 31
I suggest we meet on irc somewhere/sometime to have a live chat to discuss all this. We're firing in all directions atm.

From the mplayer perspective, C++ is a no-go. Other projects don't like it either, so C it is I think. I have already done some work re-writing parts of aacskeys in C as a user-centered library with stream support (which is what the various projects such as mplayer, vlc, etc. need). I would like to offer it as a starting point.

As kreet says, svn/wiki somewhere would be good to get up and running as soon as possible.

Last edited by cRTrn13; 7th October 2009 at 19:37.
cRTrn13 is offline   Reply With Quote
Old 7th October 2009, 19:51   #13  |  Link
kreet
Registered User
 
Join Date: Jul 2009
Posts: 41
i like the irc idea as well. nothing beats live-chat

any more interested people who want in or should we set a time?
kreet is offline   Reply With Quote
Old 7th October 2009, 20:02   #14  |  Link
JBM
Registered User
 
Join Date: May 2009
Posts: 7
No time like the present - kreet, want to suggest a channel?
JBM is offline   Reply With Quote
Old 8th October 2009, 01:56   #15  |  Link
pynux
Registered User
 
Join Date: Aug 2009
Location: PARIS
Posts: 49
if you want something , i'm here

test bluraydisk on some linux system / mac os system
help for make a website (git/svn or other)

maybe make a parteneriat with a project with my school
pynux is offline   Reply With Quote
Old 8th October 2009, 07:15   #16  |  Link
Rupan
Registered User
 
Join Date: Nov 2008
Posts: 62
parameters ... in a unified config file

I propose that all of the configuration parameters be stored in one large configuration file. Things like drive authentication mechanism, default path names, host certificate, processing keys, etc should all have sane defaults.

Writing, testing, and maintaining this code might be time consuming and unneeded. Check this out:

http://www.hyperrealm.com/libconfig/

Its lgpl3 and supports some nice syntactic structure AND its maintained and tested by someone else. The only downside is that the static library is > 100k on i386.
Rupan is offline   Reply With Quote
Old 8th October 2009, 11:21   #17  |  Link
GLUBSCH
Registered User
 
Join Date: Sep 2009
Posts: 45
Hey! Donīt destroy all our hopes to develop a true Doom9 community project!
GLUBSCH is offline   Reply With Quote
Old 8th October 2009, 11:39   #18  |  Link
kreet
Registered User
 
Join Date: Jul 2009
Posts: 41
Rupan:
i agree that there should be a global config file, and that it should be sanely formatted. we can try and use an existing config library such as libconfig. were a little way away from this decision though.

id like to get some infrastructure up (svn + wiki) and then do an initial design of the toolset (irc meeting? + wiki). then we can start assigning some tasks to people and get moving.
kreet is offline   Reply With Quote
Old 8th October 2009, 13:12   #19  |  Link
KenD00
Registered User
 
Join Date: Jan 2007
Location: Internet
Posts: 378
Quote:
Originally Posted by kreet View Post
KenD00: the reason i think we should go for c instead of c++ is because of portability. java is really a no go
There was already a discussion about this here not a long time ago so i won't comment this further. And you won't get rid of java if you want to do BD-J except you write a compiler that converts the BD-J programs of the discs into native code .

In aacskeys i just replaced OpenSSL with CryptoPP and it solved all my problems on MacOSX, i don't need to carry around two AES implementations anymore and it simplified the ECDSA code so damn much and allowed me to implement some missing features so easily. It's just a pain to see how OpenSSL must emulate object orientated behavior to work... Oh damn, now i have written something about the C/C++ stuff . aacskeys will go the C++ route, for the things i have in my mind this will simplify the design very much.

Quote:
maybe we can get you involved here?
Currently i can't devote much time to coding but i will try to be helpful if i can.


Quote:
what was your old idea?
Until i'm not sure if it will ever hit the light i want to keep it for me. If it will become real sometime it will be an application only and not some sort of library that is targeted to be used by others (but maybe it will use available libraries ).

KenD00 is offline   Reply With Quote
Old 8th October 2009, 13:13   #20  |  Link
JBM
Registered User
 
Join Date: May 2009
Posts: 7
kreet: Assembla looks a good home for this effort, especially since it's free!

How about you register this project with them, and set up a meeting on IRC for this weekend?

-JBM
JBM 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 15:46.


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