This article discusses how I used my recently purchased LG GGC-H20L Blu-ray ROM drive to successfully read and watch movies using Ubuntu Intrepid.

DISCLAIMER: This article describes decrypting BD titles using an Intel or AMD based PC with Ubuntu Linux. While you can use a PlayStation3′s BD drive to read and decrypt a title using known decryption keys using the PS3 version of Ubuntu, at this time of writing you cannot use Ubuntu installed on a PlayStation3 console to identify unknown decryption keys of a given BD title because the application used to derive those keys from the disc is not available for the PPC processor used by the PS3. You must use a consumer BD-ROM drive on an Intel or AMD based PC instead.

Hang on, you say – if there is no support for playback of Blu-ray movies on Linux, then why buy a Blu-ray drive if you can’t watch the movies? Well, I might not be able to watch them directly, but I can certainly rip the little buggers and watch a file version of it instead. But wait again, you say, if there’s no official Blu-ray support, and you can’t watch the discs directly, then how on earth do you rip them?? I’m glad you asked, and even if you didn’t ask, I’m about to tell you anyway.

First up, a little Blu-ray 101.

Blu-ray movies feature Digital Rights Management (DRM). Like DVD’s before it, most Blu-ray movies are encrypted. This is to stop those naughty pirate types from making illegal backups of the movie and giving or selling it to their mates. In the case of DVD’s, however, there was only one decryption key which was eventually discovered and from then on allowed all DVD’s to be easily decrypted using a simple library (called libdvdcss2). The movie industry as a whole were not impressed by this and insisted that the next format be more difficult (preferably impossible) to decrypt, so Blu-rays (and HD-DVD’s, but I’ll concentrate on Blu-ray for this article) each have a different decryption key now. But to complicate this further, this key is kept hidden from you by an authentication mechanism to ensure that there isn’t a repeat of the De-CSS scandal that brought the DVD encryption scheme undone.

Each and every player out there, hardware or software, has a unique player authentication key which is passed to the Blu-ray optical drive, essentially like giving your passport to Customs at the country border, to validate whether or not you are legally authorised to  playback a movie. If the drive has not got a blacklisted record of your authentication key, and the key is accepted as a generally valid key that has been paid for, THEN the drive will give up the movie’s decryption key and movie playback can commence.

Blacklist?? What blacklist? Well, like DVD players, it’s not difficult to pick up a Blu-ray player’s authentication key that is used to prompt the drive for the disc’s decryption key, after all, it has to be held in memory somewhere. Once an industry authority discovers that an authentication key has been compromised, it is added to a blacklist so that it will not work anymore. This is why hardware Blu-ray players need to be firmware-upgradable, and why software players need to be upgraded to the next version periodically with patches, etc, so that new, non-blacklisted authentication keys can be provided.

OK, that sounds all well and good, but if the Blu-ray drive itself is doing the blacklisting, how exactly does it know when a given authentication key is no longer valid? Simple – its blacklist will get updated with the next latest-release movie you buy.

Say what?

Every Blu-ray movie you buy has a little file on the disc under the “AACS” folder called “ContentRevocation.lst”. This file contains a complete list of blacklisted authentication keys for the drive to update itself with, and – get this – you can’t stop the drive loading it. Well, actually to be more accurate this file is simply a copy of the same list that is actually hidden in a non-tamperable, non-user-readable area elsewhere on the disc for the drive to read, but basically the instant you stick that movie disc in, the hidden version of this file is read and the drive automatically updates its blacklist right away with any new blacklist data, even before the disc icon appears on your desktop. Sneaky, huh?

So the next time your legal (or more specifically, pirated) copy of PowerDVD or whatever tries to playback a movie, all of a sudden you’ll see an error message instead saying that your player’s authentication key has been revoked – thus the movie is now unplayable. What’s worse is that you won’t be able to watch any of your older discs that worked previously either! It’s this exact reason that many people have called for the Blu-ray (and HD-DVD) formats to be boycotted.

But not all is lost. Remember, this is an encryption technology created by Man, and therefore can be broken by Man with a bit of help from the Open Source Community at large. With a little help from a few external resources including the Ubuntu Community Documentation and the Doom9 forums, I discovered a plethora of projects by various people, from dumping discs to breaking the encryption and authentication.

On the surface are general applications to dump the movie, decrypted, to a file. One of the best projects is DumpHD which is a Java app that provides a nice easy to use GUI that can rip a movie with a minimum of fuss (see detail about how to use it later in this article), however it requires that you already know what the decryption key for a given movie is which you can only obtain if you have authenticated with the drive. If you have the decryption key already, however, then authentication is not necessary and you can rip the movie right away without a problem, so this project is heavily supported by people posting up various decryption keys for all sorts of movie releases. The problem with this approach, however, is that different countries usually get different releases of the same movie, so for example a release of “Batman Begins” in Australia might have a completely different decryption key to the release of “Batman Begins” in America or Europe. This is not always the case of course, a good example being the Ewan McGregor movie “The Island” – the Australian release is actually the UK release, right down to the age-rating and film-office classification markings on the disc itself – only the box bears any Australian ratings markings!

Click for full size (228K)

So, how do you find out the decryption key of your locally purchased movie then? You don’t want to keep buying a commercial player, especially one that doesn’t run under Ubuntu, just to get a valid authentication key. There’s got to be a better way! Well, there is! How about we just bypass the authentication procedure altogether? How? Again, through another great contribution on the Doom9 forums.

The LG GGC-H20L drive is but one of many Blu-ray/HD-DVD drives which have had their firmware reverse-engineered. Firmware is largely just a computer program that operates the drive. Since the firmware is upgradable to fix bugs and add new features to the drive, it means the program can be altered by a third party. A Doom9 contributor has provided modified firmware for various popular drives, including the GGC-H20L that effectively allow the drive to ignore the authentication procedure no matter what player authentication key is provided, blacklisted or not, thus making the drive give up the decryption key for the Blu-ray movie currently inserted every time!

In the case of the LG GGC-H20L that I use, the firmware is provided as a Windows Executable file. There are three ways to run this, either via a native Windows installation on your PC, a virtualised Windows installation on your PC, or via the Wine compatibility layer. I successfully upgraded my drive using the Wine option as follows:

WARNING: The following information can damage or even brick your LG Blu-ray drive if not followed correctly, or if you have a power failure during firmware update. You proceed at your own risk and I will not be held responsible for any damage incurred by your drive, or for loss of hair being torn out, by following these instructions.

1. You need a normal Wine installation. If you’ve never installed it before, then type in:

   $ sudo apt-get install wine

   …and this will install the Ubuntu-repository version of Wine.

2. Since we’ll be modifying a physical device, only root can do that, so we will need to use sudo to execute the firmware upgrade, however Wine will not work as root until we change permissions of your Wine configuration in your Home directory, so type in the following to make root the owner of your Wine configuration:

   $ sudo chown -R root:root ~/.wine

3. Now execute the downloaded firmware file:

   $ sudo wine GGC-H20L_1.03_VolumeID_Patch.exe

4. The Upgrade GUI will appear. Click on the button to commence update and let it do its thing. After a minute or two, it will tell you that the drive firmware has been successfully updated. At this point, you will need to reboot your PC, but before you do, remember to change the owner of your Wine installation back to yourself. If your login was “jbloggs”, then you’d type in:

   $ sudo chown -R jbloggs:jbloggs ~/.wine

Upon returning from restart, every time you query the drive for the inserted disc’s decryption key, the drive will now happily give it to you without question. Nice.

So how do we query the drive for that decryption key anyway? A simple tool to do this is aacskeys (version 0.4.0c at this time of writing, but check further along the thread for newer releases) written by another Doom9 member, which queries the drive and tells you its Volume Unique Key and its Disc ID, which you can then copy and paste into DumpHD’s keys config file and happily begin dumping your movie.

$ ./aacskeys /media/cdrom
aacskeys 0.3.6 by arnezami, KenD00

Volume Unique Key:              5D9BCD44522B6940F8705400DA612ED9
Unit Key File Hash (Disc ID):   837487B4D6F614D5B4D5F566387B41C2D284F393
$ 

If your drive’s firmware was not patched, instead of seeing the Volume Unique Key and Disc ID, you would get this error message instead: “The given Host Certficate / Private Key has been revoked by your drive.”.

We now need to take the output data and copy it to DumpHD’s “keydb.cfg” file. Each key is placed on its own line in the following format:

DISC ID = Movie Title | D | YYYY-MM-DD | V | VOLUME UNIQUE KEY

Thus in the example above, we would enter:

837487B4D6F614D5B4D5F566387B41C2D284F393 = The Island | D | 2007-03-22 | V | 5D9BCD44522B6940F8705400DA612ED9

Now technically it appears that the date is largly irelevant, and most people just use 0000-00-00 instead of a real date (which is supposed to be the file date of the “Unit_Key_RO.inf” file in the “AACS” folder of the disc). I have tested this and I can’t see any difference in how DumpHD handles the disc.

Once you have finished editing the keydb.cfg file, save it.

NOTE: DumpHD (below) can now use AACSKeys directly, saving you having to edit to the keydb.cfg file manually, because DumpHD now does all the work for you. See this article for more information.

Since DumpHD is a Java application, you will need Java installed to run it. If you haven’t already got it installed, you can install it with the following command:

sudo apt-get install java-common

…or more realistically you should install it as part of the ubuntu-restricted-extras package which also installs a number of other useful packages:

sudo apt-get install ubuntu-restricted-extras

Once that is done, launch DumpHD by simply running the “dumphd.sh” script by either double-clicking on it and select “Run” when prompted, or in a terminal, change to where you extracted the DumpHD program and type in:

$ sh ./dumphd.sh

When loaded, you will be presented with the following interface:

Click for full size (63K)

At the top-right of the window, there is the Source Browse button. Click on it and a new window will appear. In that window, type in or select “/media/cdrom” and then click OK. After a few seconds, the disc should be identified and you will see the window change as follows:

Click for full size (85K)

Now all you need to do is click on the Destination Browse button, specify a place to store the decrypted movie and then click the Dump button to start the whole process! Once finished, you will have every video title found on the disc dumped in its originally encoded (video-wise) format, but without DRM. You can then use MPlayer to play these files directly. Generally the movie itself is the largest file, so in the case of my example, it’s the “00000.m2ts” file. I can play it simply with:

$ mplayer -fs 00000.m2ts

The -fs parameter plays the movie full-screen. I can toggle audio tracks using the hash (#) key (as for some reason, English is generally not the first audio track on the disc).

Remember that Blu-ray movies are very large. In my example, “The Island” is a good 21GB! It’s now up to you to decide whether or not you want to provide storage for your rips of this size, or whether or not you want to compress them down to save space. In my case, I was able to compress the movie down to about 4GB with negligible quality loss at a bitrate of 1200 using the x264 codec. I’ll probably increase this bitrate and allow the filesize to go to 8GB so I can maintain as near-perfect image quality to the original Blu-ray as possible. I personally choose to preserve the audio tracks as-is without down-converting them – they really don’t eat up that much space – a few hundred megabytes only.

Happy ripping!

Woah! After I’ve ripped the movie, it plays but it’s all corrupted! What’s going on?

The movie you have ripped is likely protected using BD+ protection. This is where some or much of the movie is deliberately corrupted to annoy you. I have written a guide on how to deal with this and correct the corruption here.

• Backup to an image file
• Clone to another hard-drive (eg: building multiple identical workstations) either directly or via an image file
• Data recovery (it’s safer and easier to examine an image file than risk further damage to the hard-drive itself)

Linux has a neat little command that can do this for us called simply “dd”. It is completely filesystem independent, so you can backup any hard-drive regardless of whether it was Linux formatted, Mac formatted or Windows formatted. It copies the drive bit by bit, sector by sector, not file by file.

WARNING: The following article describes commands that can destroy the information on your hard-drive with next-to-no-chance of being able to rescue what’s left. Make sure that you have full backups of your data prior to using these commands. You use these commands at your own risk!

First up, your drive/partition being backed up or written to should be unmounted before you begin. If you were trying to backup the partition containing your system’s root filesystem, you should boot up your system on a LiveCD so you can access your root partition unmounted.

You then need to determine which drive or partition you want to backup. Easiest way to do this is to fire up a terminal session and type in:

$ sudo fdisk -l

…which will list all your drives, their partitions and sizes. Note down the device name of the drive or partition you wish to backup, eg: /dev/sda for the whole of your first drive or /dev/sda1 for just the first partition of that drive, and you’re ready to begin backup.

At its simplest, backing up a drive takes two basic parameters – input device and output device or file as follows:

$ sudo dd if=/dev/sda1 of=/dev/sdb1

…will copy the content of the first partition on drive sda to the first partition of drive sdb (destroying whatever was in /dev/sdb1 previously).

$ sudo dd if=/dev/sda1 of=~/mybackup.img

…will copy the content of the first partition on drive sda to a file called mybackup.img in your Home directory.

If you wish to backup an entire drive rather than just a partition, drop the number on the drive name, ie: /dev/sda1 becomes /dev/sda instead.

To restore the image to a drive, simply reverse the parameters:

$ sudo dd if=~/mybackup.img of=/dev/sda1

How simple is that? The only issue with this method of backup, though, is that if you were to backup a 10GB partition containing only 5GB of actual data, the resulting image file will still be 10GB as dd does not simply copy active data from the drive, it copies everything.

So with that in mind, let’s compress the image, so any empty space on the drive doesn’t take up unnecessary space in the image file. We can do this by piping the data from dd into gzip before writing it to a file:

$ sudo dd if=/dev/sda1 | gzip -9 > ~/mybackup.img.gz

…and to restore, we simply pipe the decompressed data into dd again for writing to the drive:

$ gunzip -c ~/mybackup.img.gz | sudo dd of=/dev/sda1

But wait! There’s more!

This just scratches the surface of what you can do with dd. For example, you can also use dd to destroy a drive’s content before you dispose of, or sell the drive by using the following:

$ sudo dd if=/dev/random of=/dev/sda1

…which will write random data to the partition sda1 using the virtual random device, completely obliterating it.

Or, if you want a more uniform destruction, try:

$ sudo dd if=/dev/zero of=/dev/sda1

…which will – no surprises here – write zeros across the entire partition.

Or perhaps you have a drive that isn’t playing nice, for example Microsoft Windows can get stroppy when working with, or removing partitions created by a foreign OS. The easiest way to fix this is to simply destroy the Master Boor Record (MBR). You can achieve this by specifying a blocksize parameter. The MBR is inside the first 512 bytes of the drive, so all we have to do is blank those 512 bytes out using:

$ sudo dd if=/dev/zero of=/dev/sda bs=512 count=1

The bs parameter specifies the block size in bytes (in this case 512) and the count parameter specifies how many blocks of 512 bytes we’re doing (only one in this case, the first 512 bytes of the drive where the MBR resides).

Any PC will now view this hard-drive as a brand new, never partitioned drive.

Rescuing a dying hard-drive

The dd command is particularly useful for recovering data on a drive that’s about to become a paperweight. As long as it can power up and identify itself to the system, you can attempt data recovery by taking an image of the drive and then try to recover the files from that image.

Since dying hard-drives are typically sown with errors, we need to tell dd to ignore them and keep pulling as much data off as possible. Taking our first imaging example, we add a couple of parameters to the command as follows:

$ sudo dd if=/dev/sda of=~/mybackup.img conv=noerror,sync

This will make a full backup of all partitions on drive /dev/sda to a file called mybackup.img in your Home directory, and the conv parameter tells dd to ignore any errors found during the read by skipping over them. The sync parameter tells dd to replace the errors with null values – blanks – so that the resulting image file is the same data length as the drive.

Once the backup is complete, you can then mount the image to view its content. As long as the MBR (the first 512 bytes of the hard-drive) were not damaged, you will be able to now recover most, if not all your files, without worrying about further failure to the drive or odd behaviour due to the physical errors on the drive itself.

To mount the image file, you do the following. First we need a mountpoint – a place to reference the mounted image volume:

$ mkdir /dev/shm/myrecoveryimage

This creates a directory called “myrecoverytimage” in your system’s RAM drive. Before you point out that you have less physical RAM than the capacity of your hard-drive, don’t worry – this is just a mount-point. The image will still be physically read from wherever you put it on another drive.

Now we mount the image. Let’s say we backed up a standard Linux ext3-formatted drive:

$ sudo mount -t ext3 -o loop ~/.mybackup.img /dev/shm/myrecoveryimage

…or for a Windows NTFS formatted backup image:

$ sudo mount -t ntfs -o loop ~/.mybackup.img /dev/shm/myrecoveryimage

We have told the system to mount an image file of filesystem type Ext3 (or NTFS). We have to specify the loopback device because an image file is not a block device like a hard-drive is. We then specify the filename of the image we are wanting to mount, and finally where we are mounting it to.

You can now simply switch over to the mountpoint directory and see the content of the image file as though it were any normally mounted hard-drive.

$ cd /dev/shm/myrecoveryimage
$ ls -l

There are a plethora of filesystems that the mount command can manage including FAT, NTFS network filesystems etc. Refer to the man page for the mount command for more details.

When you have finished with the image, you can unmount it with:

$ sudo umount /dev/shm/myrecoveryimage

…and that will make the /dev/shm/myrecoverimage directory revert back to an ordinary empty directory again (which, being in the RAM disk, will be lost when you reboot).

Happy dd’ing!

Like

Unlike