What does 2008 hold for us in terms of AACS?

[lightshadow]

I was wondering, what 2008 will bring for us in terms of improved AACS.

When Slysoft have broken BD+ will AACS LA then role out Sequence Keys, or have their other options?

Is it likely that Slysoft breaks BD+? Does anyone know how far they are?

And is AACS DRM a never ending game, where AACS LA just releases new MKBv's everytime a Processing or Device key is found?

[gioowe]

Yes, it is very likely that they break BD+. Sequence Keys is something for 2009+ and the never-ending game will continue. :)

When will MKBv5 be out there?

[bcrabl]

Well the whole future of aacs depends on the finding of a reliable method to extract device keys from a specific standalone model. This in combination with firmware hacks of HD DVD-ROM PC drives to allow for the extraction of KCD (and basically all sectors from the disk), will leave the AACS LA with few options and even sequence keys will not be helpfull (since if you can extract the device keys from one standalone, the extraction of the device keys from the same model will be the same).

[FoxDisc]

Well the whole future of aacs depends on the finding of a reliable method to extract device keys from a specific standalone model. This in combination with firmware hacks of HD DVD-ROM PC drives to allow for the extraction of KCD (and basically all sectors from the disk), will leave the AACS LA with few options and even sequence keys will not be helpfull (since if you can extract the device keys from one standalone, the extraction of the device keys from the same model will be the same).

I think you meant to say "since if you can extract the device keys from one standalone, the extraction of the sequence keys from the same model will be the same)."

I can provide a likely scenario as to how the standalone picture might play out. Without commenting on whether some standalones have (or have not) been cracked yet, if a full set of DKs had been pulled from a standalone, they could be used (with KCD) to generate PKs for any released discs.

The AACSLA would immediately know that these keys came from a standalone. They would have only limited info about which model or manufacturer had been cracked. There were 512 original groups in MKBv1 discs and they would know which group it came from. We don't know which standalones were in which groups (I suspect all players from a single mnfr are in one group), but the AACSLA could narrow it to a single group of players.

Within that group are thousands of individual standalones, all with different sets of DKS. The problem facing the AACSLA would be to try to track down the one player that was cracked and revoke it, without pissing off their customers. This is a trickier problem than the software revocation where the LA just revoked the whole set of vulnerable software players and told everyone to upgrade. People don't want to have their hardware players revoked, even if there is some way to update the keys.

The LA would have to track down the single offending player and revoke that one. Unlike the software players (where my player is identical to yours), each individual standalone is uniquely trackable and revocable.

Even if the AACS put all ACME Model 1a players in one MKB group, I don't think they would do a mass revocation of all those players.

So they'll have to identify the offender. The problem with this is that even if they manage to identify the one compromised player, it's likely that the offender will just buy another one and use the same procedure to break it.

The AACS LA has two basic ways to identify the offender. One is to use the MKB system and make smaller S-D sets. They know which set the offender is in each time he releases a key. This is slow, but workable.

The other method is to implement SKs. That is what they were designed to do - identify bad boy compromised players. Implementing SKs has an advantage from the point of view of the LA. It breaks a lot of the current decryption tools. OTOH, it *might* break some players if their as-yet-not-field-tested SK decryption was not well implemented.:)

I suspect that some standalones have already been cracked and that standalone derived decryption keys have not yet been released because the payoff is still low. Most discs can be decrypted with public software-derived keys. The new year may lead to hardware derived key releases only if more software derived keys can't be found.

It will be interesting if the AACS LA continues to play. It's possible they may just keep on revoking software derived keys as they have been doing,

[Shinigami-Sama]

I'm betting we've already cracked a few stand alone devices, we got the 360 drive almost dead
slysoft seems to have gotten MKBv4 killed, and BD+ has a hackish workaround so far
2008 I believe we'll have killed another layer or two of BD+(partial VM injection) - as well as finding V4 and V5 Processing keys

if they throw in sequence keys I can see that putting us back 6 months but thats the worst I can see happening so far, only time will tell though

[lightshadow]

@FoxDisc: Very interesting post! Thank you :)


2008 I believe we'll have killed another layer or two of BD+(partial VM injection) - as well as finding V4 and V5 Processing keys

Is Partial VM a hyper visor?

[Shinigami-Sama]

@FoxDisc: Very interesting post! Thank you :)


Is Partial VM a hyper visor?

no no, I mean we'll have a limited set of instructions to inject into the BD+ VM, not a full set

[lightshadow]

no no, I mean we'll have a limited set of instructions to inject into the BD+ VM, not a full set

So the way to hack BD+ is to understand its instructions and have it to dump/redirect the output to a disc?

vs.

writting a Windows/Linux program that removes BD+?

[Shinigami-Sama]

So the way to hack BD+ is to understand its instructions and have it to dump/redirect the output to a disc?

vs.

writting a Windows/Linux program that removes BD+?

makes more sense from what I've read, BD+ only has a very small instruction set I think something like 100-300 instructions

[bob0r]

What does 2008 hold for us in terms of AACS?

A "key" to the world! :thanks:

[lightshadow]

makes more sense from what I've read, BD+ only has a very small instruction set I think something like 100-300 instructions
This (http://www.mediafanatics.net/BD-ROMSecurity.pdf) presentation says it is onæy 60 instructions and 100 lines of code.

On page 19 it says about the Bd+ features:

Transform code (can be included on any title)
Swap a part of AV data with separately prepared AV data
eg Such a part of AV data on the disc may be corrupted and will not
be useful without corrections with BD+ content code running in
the BD+ security VM
This same process can be used for forensic marking purpose,
which may be used to identify the source of content that has
been illegally distributed
Basic Countermeasure (when a hack has been confirmed)
When a hack is suspected, content provider can enter into a hack study
Once a hack is confirmed by the manufacturer of suspected Player, then
Content Provider can have developed and release BD+ Content Protection
code that detects and responds to the hack
Advanced Countermeasure (when basic countermeasure code does not work )
BD+ includes the ability to load native code (code that runs directly on the
player’s host process). It is allowed to deploy it only after it is proven that
basic countermeasure code cannot address the hack


How can all that fit in only 100 lines of code? Or is the 100 lines of code what the manufacturer can include on the disc?

[Shinigami-Sama]

This (http://www.mediafanatics.net/BD-ROMSecurity.pdf) presentation says it is onæy 60 instructions and 100 lines of code.


How can all that fit in only 100 lines of code? Or is the 100 lines of code what the manufacturer can include on the disc?

I'm betting thats just how much it is right now, it'd be stupid if they couldn't expand it

[lightshadow]

I'm betting thats just how much it is right now, it'd be stupid if they couldn't expand it
Yes, and wouldn't Slysoft have reverse engineered those quickly? So there must be more to BD+ than those 100 lines...

[Shinigami-Sama]

Yes, and wouldn't Slysoft have reverse engineered those quickly? So there must be more to BD+ than those 100 lines...

simplicity is the ultimate sophistication
you can do a lot with 100 lines

[lightshadow]

simplicity is the ultimate sophistication
you can do a lot with 100 lines
The way I now understand BD+ it works by the manufacturer can make his own scrambling algorithm (something like CSS for DVD's), and implement it on only that title.

That way breaking the BD+ will require a person with reverse engineering knowledge.

E.g.
* read 1 byte
* swap bit2 and bit 7
* xor
* write 1byte
* use TEA

so 100 lines of code should be enough for anyone... :p

But I could be wrong, at BD+ isn't like that.

[DeepBeepMeep]

I have read somewhere that the BD+ VM can access some private player BD+ keys. Which if this is true means it can detect which player is being used and prevent running on it (e.g: implement some form of revocation).

This is probably the reason why Slysoft is not rushing to release their BD+ support: when it is released, the player used by Slysoft may become blacklisted for upcoming titles.

In fact, I think BD+ will be also a cat and mouse game (that was the whole idea behind it) like AACS which will require periodic updates. These protection schemes are about preventing casual copies and controling a standard, it is why years after CSS has been cracked they keep on releasing new DVD protections...