HDFURY 3

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.