June 27, 2016 at 21:05We investigate the defense and restore the arcades of Namco System ES1
Introduction
This story began almost immediately after writing an article about the study of the arcade of the notorious Korean company : in the arcade machine Tank! Tank! Tank! the hard drive from Namco failed (which is not surprising, since the manufacturer installed Seagate 7200.12, which are not reliable in the machine), the drive was taken from the working arcade and copied it through WinHex, after which the game stopped running. Assuming that the integrity of the disk was violated by a careless keystroke in the data editing window on the disk in WinHex, another disk was taken from another working machine, copied in a similar way, which also stopped starting. It was then that it became clear that copy protection was somehow built into the disk.
Namco System ES1
Arcade Tank! Tank! Tank !, released in 2009, runs 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 megabytes 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 equipped with a massive case with a screwed-in 110V power supply.
Photo of System ES1 that ships with Dead Heat. Installed horizontally, unlike the ES1 option in Tank! Tank! Tank !.
On the ES1 platform, a total of 9 games were released, 4 of which are designed exclusively for the domestic Japanese market. The last game was released in 2014, so it can be assumed 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 root of trust (Static Root of Trust) using the Trusted Platform Module (TPM) crypto chip version 1.2 built into the motherboard. TPM is a wonderful thing - something like a smart card that carries an RSA key wired by the manufacturer at the production stage, with the ability to generate its own keys, the private part of which will never leave TPM, load existing keys, with a small non-volatile storage arbitrary data (NVRAM) on board, a random number generator and a bunch more. But the most interesting thing that TPM provides is Platform Configuration Registers (PCR), which can be extended with the 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 can only be supplemented with a new SHA-1 sum from which TPM itself will take a new SHA-1 sum from the concatenation of the old and new values. Simply put, TPM runs the following command if you send NEW_HASH to PCR:PCR[i] = SHA1(PCR[i] + NEW_HASH)
(from Evil Maid Just Got Angrier )
The BIOS / UEFI cannot measure anything that happens after the MBR or UEFI bootloader is loaded, therefore, in the case of Linux, the bootable kernel and initrd remain unaccounted for in the PCR. To take measurements after MBR, there are loaders that support TPM and perform trusted boot with a static root of trust: TrustedGRUB, TrustedGRUB2, GRUB-IMA. The latter is used in System ES1. These loaders send to TPM their own hashes (stage1 and stage2 in the case of GRUB), their settings and loadable modules (kernel, kernel command line and initrd, in the case of Linux).
TPM can encrypt arbitrary data with an RSA key that is bound to PCR values, and they can only be decrypted if the PCR values match. If we encrypt the data in this way, then, in case of modification of the BIOS / UEFI, bootloader, GRUB modules, kernel, initrd or just the kernel command line, the data will not be decrypted due to case mismatch.
From 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 kinds of bank clients, VPN and SSH access, and it’s very disappointing that so few people use it, units, given its cost (≈ $ 10, cheaper than typical smart cards), features and the fact that it is already installed in many laptop models, and in the latest processors from Intel is generally implemented at the software level and is available to everyone.
ES1 Protection
Namco System ES1 has three degrees of copy protection.The first is the principle of trusted download : the files and resources of the game are encrypted using a key in TPM and are tied to PCR values. The manufacturer, before sending the machine to the buyer, starts the process of encrypting data on the machine, and after that the game disc will only be launched 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, the kernel module for encrypting arbitrary data on block devices. There is also an encrypted LUKS partition on the disk, which stores a copy of the game data, along with updates, saves and other data.
The second degree of protection is HDD protection .
Why doesn’t the game start after copying the disc? Perhaps the manufacturer wrote his firmware for the disk controller, which erases data when accessing some sector, which occurs during sector-by-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, specialists and time to create devices based on PlayStation 2 ( System 246 ) and 3 ( System 357 ).
But no, everything is simple and evil genius: in the MBR of the disk, zeros are indicated in the Disk Signature field. 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 identifier for the disk, generates a random one and writes it to the disk quietly. The motherboard of the device, while loading the game, reads the MBR and sends its hash to the TPM. When it comes to decrypting data, TPM PCRs do not match, data cannot be decrypted and the game does not start. This was obviously done intentionally - all partition management utilities on Linux 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 CCIn addition to TPM, which is used only to decrypt data using OS tools, 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 is bypassed with just one patch, or is generally disabled in the configuration file. It is foolish, wasteful and generally unclear why it is needed.
From the remarkable: the password for BIOS and GRUB, which can be obtained by brute force - 016ystn or arcade , depending on the game.
Attack options
So we have:- A disk image that no longer starts
- 2 working machines
- 2 inoperative machines
Our task is to restore inoperable machines whose drives are out of order. To do this, we need to get the encrypted game data in unencrypted form from working devices, for which we need to somehow get the encryption key first.
Exploit via USB device
The second option is the Caiaq sound and MIDI device driver , which, unfortunately, I also could not use.
Cold boot attack
DMA attack
Data decryption
Getting 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 bytes through the entire image, taking random data in RAM as an AES key, and tries to find near it temporary keys obtained from the main one and used in AES rounds (so called key schedule). If we found something similar in memory - great, we got a candidate for the right encryption key!$ aeskeyfind memdump_0x0-0x100000000_20160524-172534.bin
f322ee68145f5f32dea7252b2de00ff30003bb2775b7164f7211ba56fbe2012a
7523dfd705d26ce4f34ee872ec88f7ede80ac8ea0f104d3aba4a5d38bfa5849f
103687fef032a17e830b6709c29bd805To decrypt files encrypted with loop-AES, I wrote a simple Python script, because existing utilities do not know how to work with the key that we found in the main memory (master key), but accept the “password” as an 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.
Hidden text
#!/usr/bin/env python3
import sys
import struct
from Crypto.Cipher import AES
if len(sys.argv) < 3:
print("Namco encrypted game file (.apps, LOOP-AES) decryptor.")
print(sys.argv[0], "USAGE: ENCRYPTED_FILE KEY_FILE OUTPUT_FILE")
print("KEY_FILE should be in binary format.")
print("Use echo KEY_HERE | xxd -r -p")
sys.exit(1)
aesfile = open(sys.argv[1], 'rb')
key = open(sys.argv[2], 'rb').read()
output = open(sys.argv[3], 'wb')
iv = 0
while True:
enc_data = aesfile.read(512)
if not enc_data:
break
cipher = AES.new(key=key, mode=AES.MODE_CBC, IV=struct.pack('LL', iv, 0))
output.write(cipher.decrypt(enc_data))
iv += 1$ 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 2009We have everything to make the disk the way 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 a manufacturer would!
From the first section, from the arcade directory, delete the encrypted * .apps file and the encryption key
sealkey, copy the file with decrypted * .app data and create an empty fileRECOVERYso that the scripts re-encrypt it at startup. You should get 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.appPay attention to the second section, this is the section with game updates. If there is a * .pkg file on it, then you need to delete the file
INITIALIZEDso that the game updates itself, otherwise you will get an outdated version. We connect the disk to System ES1, turn on the machine and watch the game encrypt itself and copy files to the LUKS partition! Hurrah!
Real story:
There was a very sad story, about 2010, when Nirin got enough sleep, and a technician removed from another device to make a copy on Windows with the help of Akronis. He does 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 there and climbed into the third apparatus. The story repeated itself. But our man is not afraid of anything - he called his colleague in another city and asked him to mail a disk from Nirin. All 4 sistemniks left for London (Namco European Office), and all at the expense of the guy who thought stubbornness would win! Almost 8,000 euros for everything cost (repair and round-trip logistics).What to do if you are just as 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. On Linux, this is done with one command:
# sudo dd if=/dev/zero of=/dev/sdX bs=1 count=4 seek=440After that, the game should start, and you can do all the above manipulations 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 TPM encryption, but receives the key by hashing the state of the Trusted Boot PCR values.
Get encryption key can not DMA-attack, by modifying the file
filesystem.squashfsto save the state /sys/kernel/security/tpm0/binary_bios_measurementsand /sys/class/tpm/tpm0/pcrsand reconstruction of the original TPM PCR values. Script for reconstructing PCR values: github.com/ValdikSS/binary_bios_measurements_parser
Conclusion
The architecture and quality of Arcade Linux scripts and utilities left a very positive impression on Namco programmers, and the Disk Signature MBR trick is generally aerobatics. Of course, for greater protection, IOMMU should be turned on so that DMA attacks were (almost) impossible, and encryption keys should be stored in processor debug registers, and not in RAM, but I still think the protection of Namco System ES1 is at least interesting, it was not boring to research and crack.Images and decrypted game files are available for download on the pig-tracker.
I can help as I can if you need to restore arcade software, and if you are a developer of arcade games for Linux (but not pissed gambling / gambling machines!), I will be glad to give you reliable protection that only very smart people can crack.
Hidden text