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 > General > Decrypting

Reply
 
Thread Tools Search this Thread Display Modes
Old 20th January 2007, 17:59   #41  |  Link
jokin
Dwight Schrute's homeboy
 
Join Date: Jan 2007
Location: The Office
Posts: 136
Quote:
Originally Posted by noclip View Post
You can probably discard any potential key with any 0s at all. It's very unlikely they'd appear in a key.
Looking at the current list of VUKs it appears a majority have one 0 in them. Bot none have 00.
jokin is offline   Reply With Quote
Old 20th January 2007, 18:06   #42  |  Link
orbitlee
Registered User
 
Join Date: Apr 2006
Posts: 78
192 bytes are TS packet. Normal TS packet has 188 bytes, with 47 as leading sync byte. m2ts adds 4 bytes timestamp before the sync byte. Actually 47 is always there(TS spec), but D1 is not guaranteed, since it is only timestamp, it could be any value, but timestamp won't change too quickly between adjacent TS packet, and D1 is MSB byte.

For EVOB, there is similiar pattern. 00 00 01 BA, then system clock reference , per 2048 bytes(program stream packet). For more details, read ISO13818-1.

PS: muslix64, thanks for your excellent job :-)
orbitlee is offline   Reply With Quote
Old 20th January 2007, 18:06   #43  |  Link
tonyp12
Registered User
 
Join Date: Oct 2002
Location: Florida, USA
Posts: 90
Quote:
Originally Posted by jokin View Post
Looking at the current list of VUKs it appears a majority have one 0 in them. Bot none have 00.
I guess that what he mean is a byte.
And mostly always represented as two digits when displayed as hex

Hex is just a text string and it would be really hard to decode it to unicode (decimal)
if it was not even pairs unless you split each number with a ,
(A, 10, 4, F) = '0A10040F' and that would defeat the purpose as you could use dec is the first place.

decimal 0, hex 00 , Binary 00000000

Last edited by tonyp12; 20th January 2007 at 18:59.
tonyp12 is offline   Reply With Quote
Old 20th January 2007, 18:36   #44  |  Link
kad77
0xdeadbeef
 
Join Date: Jan 2007
Posts: 18
Quote:
Originally Posted by muslix64 View Post
This is blueray specific. It's different for EVOB. But it's the same concept. Guessing plaintext values...

Secure crypto is all about key protection. I cannot do this attack if the keys are protected in memory.
It is a dead certainty that any future revisions of software players (with new player keys) will have the disc AACS keys obfuscated to the extent where only top crackers (think scene release groups) will be able to wade their way through the spaghetti code.

Amateur slueths will be shut out of direct key retrieval soon (amateur programmers working on WinDVD let us in the door anyway).
kad77 is offline   Reply With Quote
Old 20th January 2007, 18:52   #45  |  Link
MrDVD
Registered User
 
Join Date: Dec 2001
Posts: 19
Anyone know for what this AES keys in the PowerDVD BD Edition are ?
The are located @ .\PowerDVD\NavFilter\key\
MrDVD is offline   Reply With Quote
Old 20th January 2007, 19:06   #46  |  Link
jokin
Dwight Schrute's homeboy
 
Join Date: Jan 2007
Location: The Office
Posts: 136
Seeing as how alot of people own PS3 and you can run linux on a PS3. It should be possible to decrypt my blu-ray discs from the PS3 correct (with a java decryption program)? This would work out great.
jokin is offline   Reply With Quote
Old 20th January 2007, 19:16   #47  |  Link
snurregrekk
Registered User
 
Join Date: Dec 2006
Location: Norway
Posts: 8
Quote:
Originally Posted by jokin View Post
Seeing as how alot of people own PS3 and you can run linux on a PS3. It should be possible to decrypt my blu-ray discs from the PS3 correct (with a java decryption program)? This would work out great.


you're talking of some type of method like this, right? http://www.hdtvblogger.com/?p=39 (has yet to be confirmed though...)

Last edited by snurregrekk; 20th January 2007 at 19:25.
snurregrekk is offline   Reply With Quote
Old 20th January 2007, 19:27   #48  |  Link
tonyp12
Registered User
 
Join Date: Oct 2002
Location: Florida, USA
Posts: 90
Quote:
Originally Posted by kad77 View Post
It is a dead certainty that any future revisions of software players (with new player keys) will have the disc AACS keys obfuscated
The people at windvd did sure make a blunder.

If it wanted to keep the keys in memory, just a simple
left roll circular before saving it and a right roll circular when
it's back in the cpu registry would have stopped us to find it.

Now that we know a alot of keys, we would have to use a debugger in the next version of player that stops when a register have the known key (it most be in the register at least one time)

So we could apply a patch that write this register to some known space in memory.
tonyp12 is offline   Reply With Quote
Old 20th January 2007, 19:28   #49  |  Link
MrDVD
Registered User
 
Join Date: Dec 2001
Posts: 19
I think the mainprob atm is UDF 2.5 for linux ? Is there an update out ?
MrDVD is offline   Reply With Quote
Old 20th January 2007, 19:30   #50  |  Link
Lord_KiRon
Registered User
 
Join Date: Aug 2002
Posts: 151
Quote:
Originally Posted by dito View Post
I think thier mistake is to allow software players... There are chips for HD format that has layers of hack protections inside thier CPU core (and handles the keys in the memory of the CPU, making hacks like the xbox hack very hard), using such chips would make HD-DVD and BluRay really safe...
I believe you are wrong here.
Almost any hardware player can be read out (including the RAM state) with chip relevant "debugger" tool (same as EPROM programmer but more advanced.
Of course this is not for amatures but still can be done.
Lord_KiRon is offline   Reply With Quote
Old 20th January 2007, 19:40   #51  |  Link
dito
Registered User
 
Join Date: Jun 2005
Posts: 12
Quote:
Originally Posted by Lord_KiRon View Post
I believe you are wrong here.
Almost any hardware player can be read out (including the RAM state) with chip relevant "debugger" tool (same as EPROM programmer but more advanced.
Of course this is not for amatures but still can be done.
No, I am not...
dito is offline   Reply With Quote
Old 20th January 2007, 19:47   #52  |  Link
tonyp12
Registered User
 
Join Date: Oct 2002
Location: Florida, USA
Posts: 90
Quote:
Originally Posted by dito View Post
No, I am not...
It could be done, but if they use a custom chip that needs a special debugger that only "people who need to know" can get hold of.
And only after and signing a non-disclosure forms when it's will be a little harder.
tonyp12 is offline   Reply With Quote
Old 20th January 2007, 19:47   #53  |  Link
mox69
Registered User
 
Join Date: Dec 2006
Posts: 3
Quote:
Originally Posted by tonyp12 View Post
The people at windvd did sure make a blunder.

If it wanted to keep the keys in memory, just a simple
left roll circular before saving it and a right roll circular when
it's back in the cpu registry would have stopped us to find it.

Now that we know a alot of keys, we would have to use a debugger in the next version of player that stops when a register have the known key (it most be in the register at least one time)

So we could apply a patch that write this register to some known space in memory.
Now that muselix has 1 set of *Correct* keys for a BD disc, it will be trivial to find the keys for any other disc in memory unless the Software DVD player guys get into some heavy obfuscation. Even then, the key has to be in memory at some point, even if its only for a few cpu cycles. You can always put that BD disc with the known keys in and search the memory continually for those keys. Even if they move they keys around in memory continually, one could reverse engineer the algorithm that does this. At this point it is a cat and mouse game.

As long as you can access 100% of the memory on your computer as you wish, no DRM scheme will ever be totally secure.

Hence the reason people are pushing the "TPM" chips soo much. They are the only thing that will make DRM much more resistant to local attacks.


Anyway keep up the good work guys.

I think this dispels any rumors as to muselix's intentions as well, you guys are too harsh.
mox69 is offline   Reply With Quote
Old 20th January 2007, 19:58   #54  |  Link
dito
Registered User
 
Join Date: Jun 2005
Posts: 12
Quote:
Originally Posted by tonyp12 View Post
It could be done, but if they use a custom chip that needs a special debugger that only "people who need to know" can get hold of.
And only after and signing a non-disclosure forms when it's will be a little harder.
I'm talking about doubble layer processors, where you have one security processor and one main processor... But ofcourse if you could get past the security processor then you could do some debugging... Maybe you could get past it with some HNO3...

Sorry for the OT, now back to topic...

Best regards!
dito is offline   Reply With Quote
Old 20th January 2007, 20:03   #55  |  Link
tonyp12
Registered User
 
Join Date: Oct 2002
Location: Florida, USA
Posts: 90
Quote:
As long as you can access 100% of the memory
The CPU's registry is not part of the memory.
Think of it as internal memory buffer.

So you would have to do registry dump and
probably a 1000 times before you do it at the exact right moment.

And it would only a part of the 128bit key in the registry.
probably a 32bit big-endian, if that what the AACS calc uses.

It could be split up to different registrys at the same time that would make it a little easier.
But that is depending how the compiler handles calculation.
Or if the code was writted in Assembly code for more direct control.

Last edited by tonyp12; 20th January 2007 at 20:15.
tonyp12 is offline   Reply With Quote
Old 20th January 2007, 20:26   #56  |  Link
mox69
Registered User
 
Join Date: Dec 2006
Posts: 3
Quote:
Originally Posted by tonyp12 View Post
The CPU's registry is not part of the memory.
Think of it as internal memory buffer.

So you would have to do registry dump and
probably a 1000 times before you do it at the exact right moment.

And it would only a part of the 128bit key in the registry.
probably a 32bit big-endian, if that what the AACS calc uses.

It could be split up to different registrys at the same time that would make it a little easier.
But that is depending how the compiler handles calculation.
Or if the code was writted in Assembly code for more direct control.
I'm a CS major, I know what registers are...

It's not hard to peek at reg / stack values while in a debugger. Nor is it hard to print out registry values just like you do with a memory dump..

Also in order to get a value into a register don't you have to move it from memory into a register? (mov XXXXXXXX,$EAX)

Obviously you can manipulate it once in there, but that data has to exist somewhere before it goes into mem.
mox69 is offline   Reply With Quote
Old 20th January 2007, 20:44   #57  |  Link
tonyp12
Registered User
 
Join Date: Oct 2002
Location: Florida, USA
Posts: 90
Quote:
Obviously you can manipulate it once in there, but that data has to exist somewhere before it goes into mem.
But next software player version of windvd would not be allowed
to keep any calculated keys in memory without doing some
manipulation to it first (roll circular left 1bit in this simplified example)

And during play back
line1: Load 32bit word from mem to registry a
line2: roll circular right 1bit on reg a
line3: now use reg a to do some calculation.
line4: clear reg a

A debugger could now stop between line 2 and 3 as registry a now matches some known part of the key.

It sure make it a lot easier to hunt down the code and and
figure out what manipulation they are doing.

Now any memory dump key finder would just have to do the same manipulation to get it work.

If we never had access to un-manipulation keys it probably could take years to reverse engineer powerdvd or windvd.
But thanks to people at windvd we do have that.

Last edited by tonyp12; 20th January 2007 at 21:41.
tonyp12 is offline   Reply With Quote
Old 20th January 2007, 21:54   #58  |  Link
mox69
Registered User
 
Join Date: Dec 2006
Posts: 3
Quote:
Originally Posted by tonyp12 View Post
But next software player version of windvd would not be allowed
to keep any calculated keys in memory without doing some
manipulation to it first (roll circular left 1bit in this simplified example)

And during play back
line1: Load 32bit word from mem to registry a
line2: roll circular right 1bit on reg a
line3: now use reg a to do some calculation.
line4: clear reg a

A debugger could now stop between line 2 and 3 as registry a now matches some known part of the key.

It sure make it a lot easier to hunt down the code and and
figure out what manipulation they are doing.

Now any memory dump key finder would just have to do the same manipulation to get it work.

If we never had access to un-manipulation keys it probably could take years to reverse engineer powerdvd or windvd.
But thanks to people at windvd we do have that.
I agree, I think we were saying the same things just different ways.
mox69 is offline   Reply With Quote
Old 20th January 2007, 22:00   #59  |  Link
muslix64
Registered User
 
Join Date: Dec 2006
Posts: 35
Here it is, alpha version of BackupBluRay V0.21!

This release is not for everyone! This is only for those who wants to experiment with early version of Blu-ray decryption.

Known limitations:

Don't support BD+
Don't support Volume unique key
Only support one CPS unit key per disc
I don't clear the HDMV_copy_control_descriptor in the stream
Don't have any FAQ or document so far...

You have to provide your own CPS unit key.

The playback seems to work with VideoLan

Because I don't have any Blu-ray equipment, I will need the help of the community to go further with Blu-ray decryption.

I have only test this with one video file...

Stay tuned!

Link:
http://www.sendspace.com/file/yvylle

Last edited by muslix64; 22nd January 2007 at 18:03.
muslix64 is offline   Reply With Quote
Old 20th January 2007, 22:13   #60  |  Link
generalnewbie
Registered User
 
Join Date: May 2003
Posts: 22
i tested the other file from the disc that brings up the copy rights and it played perfect fine.

Amazing work....

Just shows ya that both parties are sorta looking at one another going uh its your fault!
generalnewbie 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 06:31.


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