We investigate protection and restore arcades Namco System ES1

Introduction

This story began almost immediately after writing an article about the study of the arcade of a well-known Korean company : in the arcade machine Tank! Tank! Tank! from Namco the hard drive failed (which is not surprising, since the manufacturer installed the Seagate 7200.12 not differing in reliability), the disk was taken from the working arcade and copied through WinHex, after which the game stopped running. Assuming that the integrity of the disk was compromised by carelessly pressing a key in the data editing window on the disk in WinHex, another disk was taken from another working machine, copied in the same way, which also stopped running. It was then that it became clear that the copy protection was somehow built into the disk.

Namco System ES1

Arcade Tank! Tank! Tank !, released in 2009, works on the System ES1 platform, which is an ordinary computer of those years on the Intel Q35 chipset:

• Motherboard: Supermicro C2SBM-Q (Intel Q35 + ICH9DO)
• CPU: Intel Core2 Duo CPU E8400 @ 3.00GHz
• RAM: 2x512 MB DDR2 800 MHz 1.8V
• Video: NVIDIA GeForce 9600 GT with 512 MB of GDDR3 Memory
• HDD: Seagate Barracuda 7200.12 160 GB (ST3160318AS) or Hitachi Deskstar 7K1000.C 160 GB (HDS721016CLA382)
• Operating system: Arcade Linux (based on Debian 4.0)

All this is packaged to a massive case with a screwed-on 110V power supply.

_{Photo System ES1, which comes with the game Dead Heat. Installed horizontally, unlike the ES1 version in Tank! Tank! Tank !.}

On the ES1 platform, a total of 9 games were released, 4 of which are designed exclusively for the domestic market. The last game was released in 2014, so we can assume that there will be no new games on this platform. On the territory of Russia and Ukraine, I met only 4 ES1-games: Tank! Tank! Tank !, Dead Heat, Dead Heat Riders and Nirin.
')

Trusted boot and TPM

The peculiarity of this platform is that it uses the so-called trusted boot (Trusted Boot) with a static trust root (Static Root of Trust) using the Trusted Platform Module (TPM) version 1.2 cryptochip built into the motherboard. TPM is a great thing - something like a smart card that carries an RSA key, wired by the manufacturer at the production stage, with the ability to generate their keys, the private part of which will never leave TPM, load existing keys, with a small non-volatile storage arbitrary data (NVRAM) on board, random number generator and a whole bunch more. But the most interesting thing that provides TPM - Platform Configuration Registers (PCR), which can be expanded with SHA-1-sum of some arbitrary data. It is very important to note that these registers can neither be reset nor set to the desired value, but only supplemented with the new SHA-1-sum, from which the TPM itself will take the new SHA-1-sum from the concatenation of the old and the new values. Simply put, TPM executes the following command if you are sending to PCR NEW_HASH:

PCR[i] = SHA1(PCR[i] + NEW_HASH) 

The motherboard's BIOS / UEFI, if it supports the Trusted Computing Group (TCG) specifications, measures (that is, sends to the TPM hashes) everything that is involved in the boot since the computer was turned on: BIOS / UEFI Boot Block, BIOS / UEFI itself, UEFI, SMBIOS services, ACPI tables, Option ROM devices (for example, network cards), MBR or EFI boot loader, disk partitions, and a whole lot more.


_{(from Evil Maid Just Got Angrier )}

BIOS / UEFI cannot measure anything that is done after booting the MBR or the UEFI boot loader, so in the case of Linux, the boot kernel and the initrd remain unaccounted for in the PCR. To make measurements after the MBR, there are TPM-capable boot loaders and trusted downloads with a static trust root: TrustedGRUB, TrustedGRUB2, GRUB-IMA. The latter is used in System ES1. These bootloaders send hashes to TPM themselves (stage1 and stage2 in the case of GRUB), their settings and loadable modules (kernel, kernel command line and initrd, in the case of Linux).

The TPM can encrypt arbitrary data with an RSA key linked to PCR values, and it can only be decrypted if the PCR values ​​match. If we encrypt the data in this way, then if the BIOS / UEFI is modified, the boot loader, the GRUB modules, the kernel, the initrd, or just the kernel command line, the data is not decrypted due to a register mismatch.

Of the popular software TPM is used, as far as I know, only in Microsoft BitLocker. TPM can be used as a certificate store for all sorts of bank clients, VPN and SSH access, and it’s a shame that so few people use it, given its cost (≈ $ 10, cheaper than typical smart cards), capabilities and the fact that it is already installed in many notebook models, and in the latest processors from Intel, is generally implemented at the software level and is accessible to everyone.

ES1 Protection

Namco System ES1 has three levels of copy protection.
The first is the principle of trusted download : the files and resources of the game are encrypted using the key in the TPM and tied to the PCR values. The manufacturer, before sending the machine to the customer, starts the process of encrypting the data on the machine, and after that the game disc will be launched only on the arcade where it was originally launched. For encryption, AES-256 is used in CBC mode using the extremely simple and now deceased loop-AES kernel module to encrypt arbitrary data on block devices. There is also an encrypted LUKS partition on the disk in which a copy of the game data is stored along with updates, saves and other data.


The second degree of protection is HDD protection .

Why the game does not start after copying the disk? Perhaps, the manufacturer wrote its firmware for the disk controller, which erases data when accessing some sector, which occurs during the sector copying of the disk, but never occurs during normal use of the disk by the game and the OS? Knowing Namco, they could take such a step, because they have the means, the experts, and the time to create devices based on the PlayStation 2 ( System 246 ) and 3 ( System 357 ).
But no, everything is simple and ingenious in an evil way: in the MBR disk in the Disk Signature field there are zeros. As soon as you connect this disk to a computer running Windows, it detects zeros, it does not like it, because Windows uses Disk Signature as a unique disk identifier, generates a random one and quietly writes it to disk. The motherboard of the device, while loading the game, reads the MBR and sends it to the TPM hash. When it comes to decrypting the data, the TPM PCR does not match, the data cannot be decrypted and the game does not start. This was done intentionally - all Linux partition management utilities generate random Disk Signature, not zeros.

 $ cmp -l mbr_working mbr_broken | gawk '{printf "%08X %02X %02X\n", $1-1, strtonum(0$2), strtonum(0$3)}' 000001B8 00 4B 000001B9 00 4D 000001BA 00 17 000001BB 00 CC 

In addition to the TPM, which is used only to decrypt data using the OS, the games themselves use the USB dongle HASP HL ​​Max . More precisely, it is not used, but only its presence is checked, and this check costs literally one patch, or is completely disabled in the configuration file. It is foolish, wasteful, and generally incomprehensible why it is needed.

From noteworthy: BIOS and GRUB password, which can be obtained by brute force - 016ystn or arcade , depending on the game.

Attack options

So, we have:

• Disk image that no longer starts
• 2 operational machines
• 2 disabled machines

Our task is to restore inoperable machines, which drives failed. To do this, we need to get the encrypted game data in an unencrypted form from efficient devices, for which we need to somehow get the encryption key first.

• Exploit through usb device

The kernel version 2.6.25 used in the machine contains at least two vulnerable USB device drivers. In the first of these, the Voers PBX Auerswald driver, you can exploit a buffer overflow in the device name. Unfortunately, the buffer overflow is not on the stack, and we can overflow it by only 27 bytes, which is why, most likely, the vulnerability cannot be applied without interacting with the userspace, which does not suit us, because we do not have access to the terminal or any other ability to execute the code. But everything fell .
The second option is the Caiaq sound and MIDI device driver , which, unfortunately, also failed to work for me.

• Cold boot attack

The attack is to dump the memory and search for encryption keys in it. It can be done in two ways: by running a small dumper program from a USB flash drive (for example, msramdmp ) or HDD immediately after a reboot, or by freezing and removing the memory while preserving its contents on another computer using the same dumper. The first method will not work because the motherboard complies with the Trusted Computing Group specification, which instructs to perform memory cleaning at boot time, and the dumper will save the already cleared memory, in which, of course, there will be no keys anymore.

• DMA attack

Direct Memory Access attack is based on the execution of requests to the memory management unit via a bus, device or standard that allows such access. There are commercial cards specifically designed for DMA attacks, there are also boards with a USB 3.0 USB3380 controller ( SLOTSCREAMER ), which, by chance, can generate and send PCI packets to the bus, with some limitations, but for DMA requests enough. The easiest and most affordable way is the Firewire (IEEE 1394) standard, which, however, requires support from the OS. Fortunately, in our machine, the developers did not block the Firewire SBP2 driver, which allows direct memory access, which means that it is enough to insert the Firewire card into a free PCI or PCI-e slot, connect it to the card in your computer and save RAM using, for example, Inception . We will use it!

Data decryption

The memory data is still half the battle; you need to find the AES key in them and decrypt the game file. For the first task, smart people from Princeton University wrote the aeskeyfind utility, which goes through the entire image byte-by-byte, taking random in-memory data for an AES key, and trying to find temporary keys from it that are used in AES rounds ( called key schedule, key schedule). If we found something similar in memory - great, we have a candidate for the correct encryption key!

 $ aeskeyfind memdump_0x0-0x100000000_20160524-172534.bin f322ee68145f5f32dea7252b2de00ff30003bb2775b7164f7211ba56fbe2012a 7523dfd705d26ce4f34ee872ec88f7ede80ac8ea0f104d3aba4a5d38bfa5849f 103687fef032a17e830b6709c29bd805 

_{There were two 256-bit keys and one 128-bit}

To decrypt files encrypted with loop-AES, I wrote a simple Python script, since Existing utilities do not know how to work with the key that we found in the RAM (master key), but accept the “password” as input, from which the master key is obtained using the key generation function. We do not have a “password”, and it turned out to be easier to write our own than to modify someone else’s.

 $ echo f322ee68145f5f32dea7252b2de00ff30003bb2775b7164f7211ba56fbe2012a | xxd -r -p > key $ ./decrypt.py v352us.apps key v352us.app $ file v352us.app v352us.app: Squashfs filesystem, little endian, version 3.1, 655177264 bytes, 6062 inodes, blocksize: 131072 bytes, created: Sat Nov 28 06:26:17 2009 

_{The first key came up, great!}

We have everything to make the disk as it was before the device was first turned on at the factory, which means that we can restore any Namco System ES1 machine in the same way as the manufacturer would do!
From the first section, from the arcade directory, delete the encrypted * .apps file and the sealkey encryption sealkey , copy the file with the decrypted * .app data and create an empty RECOVERY file RECOVERY that the scripts will re-encrypt it on startup. You should have something like this:

 p1/arcade % ls -lah total 626M drwxr-xr-x 2 root root 4.0K Jun 27 19:02 . drwxr-xr-x 7 root root 4.0K Nov 28 2009 .. -rw-r--r-- 1 root root 396 Nov 28 2009 config -rw-r--r-- 1 root root 75 Nov 28 2009 partab -rw-r--r-- 1 root root 0 Jun 27 19:02 RECOVERY -rw-r--r-- 1 root root 625M Nov 28 2009 v352us.app 

Pay attention to the second section, this is the update section of the game. If it has a * .pkg file, then you need to delete the INITIALIZED file in order for the game to update itself, otherwise you will get an outdated version.

We connect the disk in System ES1, turn on the machine and watch how the game encrypts itself and copies files to the LUKS partition! Hooray!


Real story:

It was a very sad story, in about 2010, when Nirin got enough sleep, and the technician took off from another device to make a copy on Windows using Acronis. Make a copy, reports that everything is OK. But the disk from which they tried to make a copy, then, when connected back, shows a blue screen of death and a sign that you have problems with the disk. The stubborn guy did not stop at this and climbed into the third unit. History repeated. But nothing scares our man - he called his colleague in another city and asked him to send a CD with Nirin by mail. All 4 systems officers left for London (Namco European representative office), and all at the expense of the guy who thought that stubbornness would win! Almost 8,000 euros for everything cost (repair and round-trip logistics).

What to do if you are so stubborn, and you have no working devices left? No problem! It is enough to return zeros in the disk identifier field in the MBR, i.e. write 4 bytes of zeros at offset 0x1B8. In Linux, this is done with one command:

 # sudo dd if=/dev/zero of=/dev/sdX bs=1 count=4 seek=440 

And in Windows you can use, for example, WinHex.
After this, the game should start, and you can do all the above described manipulations in order to get the decrypted files and restore the rest of the devices.

06.25.2018 UPD : Apparently, Nirin was the first game on System ES1, and Namco did not know how to correctly implement protection using TPM. The game does not use encryption by means of TPM, but obtains the key by hashing the state of the values ​​of Trusted Boot PCR.
You can get the encryption key without a DMA attack by modifying the filesystem.squashfs file to save the state /sys/kernel/security/tpm0/binary_bios_measurements and /sys/class/tpm/tpm0/pcrs and reconstructing the original TPM PCR values.
Script to reconstruct PCR values: github.com/ValdikSS/binary_bios_measurements_parser

Conclusion

The architecture and quality of the scripts and utilities of Arcade Linux left a very positive impression on Namco programmers, and the trick with Disk Signature in the MBR is generally aerobatics. Of course, for greater protection, IOMMU should have been enabled, so that DMA attacks were (almost) impossible, and the encryption keys should be stored in the processor’s debug registers, and not in RAM, but I still consider the Namco System ES1 protection to be at least interesting, it was not boring to explore and crack.
Images and decrypted game files are available for download on the co-pig tracker.

I can help you if you need to restore arcade software, and if you are a developer of arcade games under Linux (but not pissing gambling / gambling machines!), I will be glad to make you reliable protection that only very smart people can crack.