View Full Version : BD(+) Toolset 2.0
kreet
6th October 2009, 15:25
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! :D
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
JBM
6th October 2009, 15:37
Count me in. Hacking C is where I'll be of most use.
-JBM
neuron2
6th October 2009, 15:40
Hacking C What is "Hacking C"?
neuron2
6th October 2009, 16:10
But why would you prefer to "hack" it instead of writing it in a sound professional manner?
kreet
6th October 2009, 16:26
guys, i appreciate the discussion of semantics, but can we try and keep this thread 'clean'? no ot?
neuron2
6th October 2009, 17:00
It's development, so development methodologies are fair game.
cRTrn13
6th October 2009, 23:23
"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)
kreet
7th October 2009, 11:24
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.
KenD00
7th October 2009, 12:54
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 ;).
:rolleyes:
kreet
7th October 2009, 16:42
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?
JBM
7th October 2009, 16:59
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
cRTrn13
7th October 2009, 20:34
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.
kreet
7th October 2009, 20:51
i like the irc idea as well. nothing beats live-chat :D
any more interested people who want in or should we set a time?
JBM
7th October 2009, 21:02
No time like the present - kreet, want to suggest a channel?
pynux
8th October 2009, 02:56
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
Rupan
8th October 2009, 08:15
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.
GLUBSCH
8th October 2009, 12:21
Hey! Donīt destroy all our hopes to develop a true Doom9 community project! ;)
kreet
8th October 2009, 12:39
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.
KenD00
8th October 2009, 14:12
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 :p.
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 :D. aacskeys will go the C++ route, for the things i have in my mind this will simplify the design very much.
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.
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 ;)).
:rolleyes:
JBM
8th October 2009, 14:13
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
kreet
8th October 2009, 16:25
JBM: ill set up an assembla project.
KenD00: i actually like libtomcrypt its a nice clean crypto library which is 100% embeddable and is in pure c. it has everything we need (aes, sha, ecc).
we obviously cant get rid of java, we need to run the bdj apps. but the libraries themselves should be native for portability. also, we should embed our own jvm and jrt in our library, so we dont need to rely on the platform java at all. in other words we should do things exactly in the same way that real players do.
kreet
8th October 2009, 16:55
ok. i set up an assembla project. all those interested should pm me their nicks so i can add them to the team:
http://my-trac.assembla.com/libbluray
update: we really need someone to volunteer to manage/admin this project.
things that need doing from a project management perspective:
1) manage the wiki, add links etc to forum threads
2) manage releases (more of a future job at the moment)
3) manage the project layout, including build scripts
4) manage team member permissions for the repository and trac
please please will someone volunteer to do this? if i have to do this stuff, i wont have time for reversing and coding! this is your chance to contribute folks!
cRTrn13
8th October 2009, 19:40
I'm a coder - this is a good job for someone who wants to be involved but isn't a coder.
Re IRC meeting - Sunday's good for me.
kreet
8th October 2009, 20:52
sunday works for me too. im on constantly, at #libbluray on efnet. just ping me.
dirio49
9th October 2009, 02:04
i don't know how it works.
but this the old repository
https://trac.assembla.com/bdplus/browser
later
cRTrn13
9th October 2009, 08:49
sunday works for me too. im on constantly, at #libbluray on efnet. just ping me.
We should arrange a time where everyone (or most) are available... am pretty much available all day/night so someone else pls suggest a time!
JBM
9th October 2009, 10:14
How's this for a time:
Sunday 11th Oct, 19:00 GMT
That's
20:00 to anyone in the UK / Ireland
11:00 to anyone on the west coast of N. America
and not an antisocial time for anyone too far east either.
GLUBSCH
9th October 2009, 11:26
Let me throw this: Main goal of the project is to "...provide a full portable free open source bluray library, which can be plugged into popular media players to allow full bluray navigation and playback on linux." Are you aiming to replace the somewhat outdated libdvdcss library too? Nothing against copy protection and stuff, but an open source library to get around it use would be awesome. Iīm all ears for your opinion.
PatlaborForce
9th October 2009, 14:51
I'm pretty sure reimplementing libdvdcss would be outside the scope of a library to playback Blu-Ray discs. Secondly, what is wrong with libdvdcss that it needs to be reimplemented?
JBM
10th October 2009, 19:11
The scope of this project seems pretty huge, so perhaps it's best sub-dividing it into manageable chunks:
1) ANSI C code for removing AACS (based on aacskeys?)
2) extend this to cover simple BD+ titles (i.e. no java interaction) (based on the code in libbluray)
3) add suport for java interaction with the BD+ layer
4) Work on a full-blown BD-J implementation.
To begin with, we could have just a very simple command line tool which uses our library to dump the complete, decrypted and reconstructed contents of a disc, much the way dumpHD does. Once that's stabilised, we can move on to VLC / MPlayer plugins.
kreet makes a good point about libtom(crypto) - it's fully embeddable. Let's bear in mind that what we're doing is likely to be excluded from most major distros (just like libdvdcss is), so having embeddable libraries has its advantages. I presume something similar will apply when we get to work on BD-J.
Also, any graphic designers / artistic types out there want to make a logo for libbluray?
-JBM
kreet
10th October 2009, 19:58
all: suggested time for irc meet is 19:00 GMT on sunday 11 oct. this is when were doing it.
GLUBSCH: the goal of the project is clearly stated. bluray only. please keep all other discussion off this thread.
JBM: the roadmap is something that we should discuss at the irc meet, as are the other issues you raised. im far less concerned about getting a logo than i am about having people volunteer for the actual work, especially the 'project management', without which this project will almost certainly die.
cRTrn13
11th October 2009, 09:32
I'll be online then.
@JBM
I agree with kreet - we should discuss at the meeting. Just for everyone's info - I've already started work on item 1 on your list (and it works absolutely fine with mplayer). I suggest we use this as a starting point - but of course this can be discussed in the meeting.
kreet
11th October 2009, 23:18
we had a great kickoff meeting. hopefully things will start rolling on the assembla page. we are still open for volunteers.
TomZ
12th October 2009, 14:18
I would like to help you but i don't think i'll be very usefull... Maybe beta-tester, french translations if needed, but nothing more else... I have linux and MacOSX OSes for tests.
Let me know if you need this kind of abilities :-)
BR
'Z
kreet
12th October 2009, 14:20
TomZ: we wont be needing translations as we are building a library which will not have any user interface. regarding testing, please contact JBM who will be coordinating testing. at this point we are looking for developers and reverse engineers.
XYZ123
13th October 2009, 16:25
If you need some more coder(especially for aacs), I would like to help.
kreet
13th October 2009, 19:57
xyz123: great. please pm me your assembla username and ill add you. speak to cRTrn13 about what tasks need to be picked up, or look at the trac to see unassigned tickets.
TomZ
14th October 2009, 10:34
TomZ: we wont be needing translations as we are building a library which will not have any user interface. regarding testing, please contact JBM who will be coordinating testing. at this point we are looking for developers and reverse engineers.
That's why i've wrote "if needed" :p
I'll contact JBM for the testing part. I'll be pleased to be helpfull.
Accident
15th October 2009, 02:16
I'm still around, just busy is all. The current libbluray I wrote is fully ansi-c and portable, I have tried it on embedded mips system too, to get speed readings. But it does need more debugging and interfacing with other libraries with better defined API calls.
swolf2010
30th October 2009, 15:42
hey , how about this project now,
kreet
1st November 2009, 11:00
swolf2010: the project is alive and making progress. if you want to volunteer, join us on our irc.
titou10
14th November 2009, 15:04
Could do some Java programming under your directions guys (algorithms etc...).
Professional Java programmer here with a few years of C and C++ too (And some mainframe assembler and COCOL..lol)
Let me know where to start if you're interested
vBulletin® v3.8.4, Copyright ©2000-2009, Jelsoft Enterprises Ltd.