HDFURY

BD+




BD+ is a component of the Blu-ray Disc Digital Rights Management system. It was developed by Cryptography Research Inc. and is based on their Self-Protecting Digital Content concept. Its intent was to prevent unauthorized copies of Blu-ray discs and the playback of Blu-ray media using unauthorized devices.

While BD+ has not stemmed the flow of "cracked" high definition content, it has made it necessary for those who wish to copy Blu-ray movies to reinvest resources to break each new version of security code.

BD+ played a pivotal role in the format war of Blu-ray and HD DVD. Several studios cited Blu-ray Disc's adoption of the BD+ anti-copying system as the reason they supported Blu-ray Disc over HD DVD. The copy protection scheme was to take "10 years" to crack, according to Richard Doherty, an analyst with Envisioneering Group.

On 19 November 2007, Macrovision announced that it planned to acquire the SPDC technology (including patents and software code) from CRI for US$45 million in cash plus stock warrants.

On 7 July 2011, Irdeto acquired BD+ content protection technology for Blu-ray discs from Rovi.


Capabilities

BD+ is effectively a virtual machine embedded in authorized players. It allows content providers to include executable programs on Blu-ray Discs. Such programs can:

  • examine the host environment, to see if the player has been tampered with. Every licensed playback device manufacturer must provide the BD+ licensing authority with memory footprints that identify their devices.

  • verify that the player's keys have not been changed.

  • execute native code, possibly to patch an otherwise insecure system.

  • transform the audio and video output. Parts of the content will not be viewable without letting the BD+-program repair it.

If a playback device manufacturer finds that its devices have been hacked, it can potentially release BD+-code that detects and circumvents the vulnerability. These programs can then be included in all new disc releases.

The specifications of the BD+ virtual machine are only officially available to licensed device manufacturers. A list of licensed adopters is available from the BD+ website. Both SlySoft and members of the Doom9 forum have reverse engineered the virtual machine specification, however.

According to the reverse-engineered specification, the virtual machine consists of a 32-bit big endian DLX like processor with 4MB of RAM. It has 32 32-bit registers available for use. A TRAP instruction is used to allow the virtual machine host to perform more complex actions as system calls.

To prevent simple, static disassembly of the BD+ code, an instruction filter is available that can perform an XOR operation on an opcode before executing it. By varying the instruction filter at runtime, the compiler can force an adversary to trace through the code at runtime before they can fully disassemble it.

Virtual machine

This program which can be found inside the BDSVM directory of a BD+ protected disc is called content code. The content code is executed on a virtual big endian DLX-like processor interfacing 4MB of memory. The processor supports 59 different instructions and a register set consisting of 32 general purpose registers and three special purpose registers for the instruction filter, the clock cycle counter and the program counter. The BD+ Virtual Machine applies memory protection by masking memory access addresses to prevent them from falling outside of the designated memory areas. The execution of content code starts at address 0x1000 relative to the beginning of the payload of the first block of the file 00001.svm (located inside the BDSVM directory).

Traps

While the BD+ virtual machine is extremely simple, the interface between the virtual machine and the player is somewhat more complicated. BD+ provides the content code with 25 system calls or "traps". An overview is given in the table below. Note that the bits 00-07 of the trap id uniquely identify each trap within a group. The group id itself is specified by the bits 08-16 of the trap id. The group ids seen so far are 00 (event handling), 01 (cryptography operations), 02 (arithmetic operations), 03 (memory operations), 04 (slot memory access), 05 (device access) and 80 (debugging).

[spaces:0][spaces:0]

Group ID

Trap ID

Name

Parameters

00

000010

TRAP_Finished

0

000020

TRAP_FixUpTableSend

2

01

000110

TRAP_Aes

5

000120

TRAP_PrivateKey

5

000130

TRAP_Random

2

000140

TRAP_Sha1

4

02

000210

TRAP_AddWithCarry

3

000220

TRAP_MultiplyWithCarry

4

000230

TRAP_XorBlock

3

03

000310

TRAP_Memmove

3

000320

TRAP_MemSearch

5

000330

TRAP_Memset

3

04

000410

TRAP_SlotAttach

2

000420

TRAP_SlotRead

2

000430

TRAP_SlotWrite

1

05

000510

TRAP_ApplicationLayer

3

000520

TRAP_Discovery

4

000530

TRAP_DiscoveryRAM

3

000540

TRAP_LoadContentCode

5

000550

TRAP_MediaCheck

6

000560

TRAP_RunNative

4

000570

TRAP_???

0

80

008010

TRAP_DebugLog

2

008020

TRAP_???

 ?

008030

TRAP_???

 ?

Each of these system calls can be invoked by the TRAP instruction (opcode 0x39). By convention register 29 is used as the stack pointer holding the memory address of the parameters. After parameter validation the system call is executed and a return code is written to register 1. During its execution the content code performs a series of tests to verify it is being executed in a trusted environment. One of these tests involves asking the player for its certificate with TRAP_Discovery. The RSA signature of this certificate is later verified by the content code using the public key of the license administration which is (optionally in obfuscated form) also stored in the content code. Later the player is asked to sign a random message with ECDSA by calling TRAP_PrivateKey. The generated signature is subsequently verified using the player's public key stored in the previously verified certificate.

Events

The BD+ virtual machine is event-driven. Five callbacks (events) are defined by the interface which the player may invoke to notify the content code of a variety of events, including the playback of various parts of the movie, shutdown, media eject events, or player security operations. The event data is exchanged using a dedicated memory area (0x00-0x3F). TRAP_Finished is invoked whenever the content code has finished processing an event. The first event invoked is EVENT_Startup which starts the execution of the content code.

[spaces:0][spaces:0]

Group ID

Event ID

Name

Parameters

00

000000

EVENT_MediaInit

1

000010

EVENT_Shutdown

1

01

000110

EVENT_TitleInit

2

02

000210

EVENT_ApplicationLayer

2

000220

EVENT_ComputeSP

3

Conversion table

Before a BD+-capable disc is mastered, random sections of the .m2ts files are overwritten by random data, effectively corrupting parts of the content. The original data is stored encrypted and obfuscated within the BD+ content code. After the content code has verified the security of the execution environment, it sends a table with repair instructions (the "conversion table" or "fix-up table") to the player using the system call TRAP_FixUpTableSend. The conversion table consists of one subtable for each .m2ts file on the disc. A subtable consists of multiple, possibly empty, segments which contain the repair descriptors. Each repair descriptor then provides the raw data and the offset needed to repair a small section of a .m2ts file, replacing the corrupted part of the file with the original data.