Researching protection and recovering Namco System ES1 arcades

11 min readJun 28, 2016

Read this article in Russian
I’m sorry for my bad English. I know how mistakes degrade readability and make the reader think I’m a 7-year-old schoolboy, but try to bear with it please.

This story began right after my old research of infamous Korean arcade machine 3 years ago: Tank! Tank! Tank! coin-op by Namco had HDD fault (which is not surprise as Namco uses Seagate 7200.12, not known for it’s reliability). Working arcade HDD was taken to make a copy from it using WinHex in Windows, after that the game won’t start. Assuming that the disk integrity was broken by a careless button press in an disk editing window of WinHex, another drive was taken from another working machine and copied the same way, which is also would no longer run. After that it became clear that the drive has a kind of copy protection in it.

Namco System ES1

Tank! Tank! Tank! Arcade has been released in 2009 and runs on a Namco System ES1 platform, which is basically a pretty usual Intel Q35-based PC for that time:

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 GDDR3
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)

Everything is bundled in a bulky case with 110V power supply on top.

Photo of System ES1 which came with Dead Heat game. Mounted horizontally unlike Tank! Tank! Tank! version.

There are 9 games for ES1, 4 of which are for Japanese internal market only. The last game has been released in 2014, it’s safe to assume we won’t see any new titles for this platform. I saw only 4 games in Russia and Ukraine: Tank! Tank! Tank!, Dead Heat, Dead Heat Riders and Nirin.

Trusted boot and TPM

The feature of this platform is that is has Trusted Boot with Static Root of Trust using Trusted Platform Module (TPM) version 1.2 which is soldered to the motherboard. TPM is a neat thing, something like a smart card, which has manufacturer supplied RSA key, ability to generate your own keys that way the private part would never leave the device, or import existing ones. It also has small non-volatile memory (NVRAM) to store user-supplied data, random generator (RNG) and some other stuff. The most interesting feature of TPM are Platform Configuration Registers (PCRs) which you can extend with a SHA-1 sum of arbitrary data. These registers can’t be reset or set to exact value, they can only be extended with new value, from which TPM would take SHA-1 hash sum concatenated with old value. In other words, if you supply NEW_HASH to the TPM, it does the following:

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

Motherboard BIOS/UEFI, if it follows Trusted Computing Group (TCG) specifications, measures (i.e. extends TPM PCRs) everything which is used in boot process right after powering on: BIOS/UEFI Boot Block, BIOS/UEFI itself, UEFI services, SMBIOS, ACPI tables, Option ROMs (in the network card as an example), MBR, EFI Bootloader, partition tables and a lot of other stuff.

BIOS/UEFI can’t measure anything after MBR or EFI bootloader is loaded, so, in the case of Linux, kernel and initrd are not extended to the PCR. To measure everything after MBR/EFI Bootloader, there are TPM-aware bootloaders which can extend everything they boot: TrustedGRUB, TrustedGRUB2, GRUB-IMA. The latest is used in System ES1. These boot loaders send themselves to TPM (GRUB stage1 and stage2), their settings and loaded modules (kernel, kernel command line and initrd, in case of Linux).

TPM can encrypt arbitrary data with it’s RSA key binding to PCR values, and one would be able to decrypt it only if all PCR values are exactly the same as they were. If we encrypt data that way, any modification of BIOS/UEFI, bootloader, GRUB modules, the kernel, initrd or even kernel command line would lead to decryption failure because of mismatching PCRs.

As far as I’m aware, Microsoft BitLocker is the only popular software which utilizes TPM. You can use TPM as a certificate storage for banking clients, VPN and SSH access, and it’s truly disappointing it’s used by a very limited number of people, as it’s cheap (≈$10, cheaper then usual smart card), it’s features and that fact that numerous laptop models already have it, even more, latest Intel CPUs have it as a firmware feature and now it’s available for everyone.

ES1 protection

Namco System ES1 has 3 stages of protection.
The first one—Trusted Boot principle. Game files and resources are encrypted with key in TPM and bound to PCR values. Manufacturer runs machine once before sending it to the client, this start encryption process after which the game would only work on this exact machine. AES-256 in CBC mode is used, on the behalf of obsolete and simple loop-AES kernel module. There’s also encrypted LUKS parition which stores game, updates and save data.

Second protection stage — HDD copy protection.

Why the game won’t run after you copy the drive? Could it be that the developer decided to write it’s own modified HDD firmware, which wipes some essential data when it detects access to some disk sector which is never accessed by the game or OS but read when you copy the drive sector by sector? If you’re aware of Namco, you may assume they could do that, as they, for example, have money, time and people to create custom Playstation 2 (System 246) and Playstation 3 (System 357) based machines.

Fortunately no, everything is simple yet evilly genius: drive’s Master Boot Record (MBR) has it’s Disk Signature field filled with zeros. Right as you connect this HDD to your Windows machine, the OS sees zeros and don’t like it, generates a random Disk Signature and silently writes it to the disk. Game motherboard reads MBR in boot process, sends it to the TPM. When it’s time to decrypt the data, PCR are not exactly the same and decryption is not possible. This was done intentionally—every Linux disk partitoning utility 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

Aside TPM, which is used by the OS only, the game itself uses HASP HL Max USB dongle. Or, better say, only checks it’s presence, which could be mitigated by literally one patch, or even by modifying configuration game file. Stupid, wasteful and I don’t understand, why they need it.

Some remarkable stuff: BIOS and GRUB password could be brute-forced, it’s either 016ystn or arcade, depending on game.

Attack methods

So long we have:

Drive image which would no longer boot
2 working machines
2 broken machines

Our goal is to fix broken arcades which drives are broke down. To achieve the goal, we need to fetch encrypted game data in a non-encrypted state from working machines, before that we need to get decryption key somehow.

USB device exploit

Kernel verion 2.6.25 has at least 2 vulnerable USB device drivers. The fist one, VoIP PBX Auerswald driver, has buffer overflow in the device name. Unfortunately, you can only overflow 27 bytes, and not on stack, so most likely it’s impossible to get code execution without userspace access. At least I’ve got kernel panic.
The second vulnerable driver is for Caiaq audio and MIDI device which unfortunately I also could not exploit.

Cold Boot Attack

Point of this attack is to dump RAM and search for encryption keys there. It can be performed using small dumper software started from a USB flash (like msramdmp) right after reboot, or by freezing memory with liquid nitrogen or halocarbon from the canned air, then removing the memory, installing it to another PC and running the same dumper software.
First method won’t work as our motherboard follows Trusted Computing Group specification which say to clear RAM on every boot or reboot, and we would dump nothing.

DMA Attack

Direct Memory Access Attack is an attack where you can perform memory read or write requests to the memory management unit over bus, device or standard which allows such access. There are commercial devices for DMA attacks, as well as devices on USB3380 chip (SLOTSCREAMER) which is by accident allow PCI bus requests. The most affordable way to perform DMA attack is a Firewire (IEEE 1394) standard which, on the other hand, requires drivers on the victim side. Fortunately for us, System ES1 has Firewire SPB2 drivers, that means that it’s sufficient to plug in Firewire card into arcade’s PCI or PCI-e slot, connect it with Firewire card inside your PC and run memory dump software like Inception. Awesome!

UPD: It seems that Arcade Linux could also be exploited using shellshock over DHCP.

Data decryption

Getting RAM contents is half of a deal, now we need to find AES key in it and decrypt game data. To solve first issue smart people from Princeton University wrote an application which reads memory contents byte by byte, assuming that current data is an AES key, and tries to search for temporary keys nearby, which are used in AES rounds (so called Key Schedule). If we found something which seems like AES key, hooray, we have a key candidate!

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

Found two 256 bit keys and one 128 bit key.

I wrote a small simple Python script to decrypt loop-AES encrypted data because existent software doesn’t support keys found in the RAM (so called master keys) and expect a “password” for input, which is converted to a master key with a key deviation function. We don’t have “password” and it’s easier for me to write my code than to modify someone’s

#!/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

Let’s run it!

$ 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 tried key works, great!

We have everything to make drive just as it was before first boot on the factory, it means we can recover any Namco System ES1 arcade as good as it would be done by the manufacturer itself!
Let’s delete encrypted *.apps and sealkey file from the arcade folder on the first disk partition, then create empty RECOVERY file in said folder to force OS scripts to re-encrypt game data. You should see something similar:

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

Should be noted that second HDD partition stores game updates. If there is a *.pkg file, you need to remove INITIALIZED file to make game update itself or you’ll get outdated game version.

Now connect our HDD to System ES1, power it on and watch how the game encrypts itself and copies files to the LUKS partition. Yay!

Here goes the real story:

There was a really sad story in year 2010, when Nirin hard drive died and the arcade technician took the disk from another machine to make a copy using Acronis in Windows. The copy is made, everything seems to be fine, but after connecting this HDD to the machine it no longer boots and says that you have a problem with the drive. Stubborn technician didn’t stop and took a drive from third arcade. The same story. Nothing can stop our person, he calls his pal in another city to send him Nirin drive by mail. All 4 machines were sent to London (Namco Europe) paid by technician who thought that stubbornness could win it all! Recovery cost almost €8000.

What to do if you’re as stubborn as the man in a story and you have no working machines anymore? Fear not! Just write 4 bytes of zeros where they should be in the MBR, at the offset 0x1B8. You can do it like this in Linux:

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

Or use WinHex in Windows.
Afterwards the game should boot just fine. Follow the DMA method described above to get decrypted game data and repair other machines.

25.06.2018 UPD: Nirin was probably the first game on System ES1, at that time Namco didn’t know how to implement protection properly. It doesn’t utilize TPM chip encryption and only uses SHA1-hash of Trusted Boot PCR state as an encryption key for files.
The game could be dumped by modifying filesystem.squashfs file to save TPM PCR state files /sys/kernel/security/tpm0/binary_bios_measurements and /sys/class/tpm/tpm0/pcrs and reconstructing original TPM PCR state, without DMA attack, which is a requirement for later games on this platform.

Here’s TPM PCR reconstructing software for those who interested: https://github.com/ValdikSS/binary_bios_measurements_parser

The end

I can say only very kind words of Namco programmers based on Arcade Linux architecture and quality of it’s scripts and utilities. The Disk Signature trick is top notch. Of course, they could enable IOMMU to prevent Direct Memory Access Attacks and store encryption keys in CPU debug registers instead of RAM, but I still think that Namco System ES1 protection was at least interesting to dig into.
All game images and decrypted files are available on a tracker-with-sows.

Feel free to contact me if you need help with arcade repairing, or if you’re an arcade games developer (but not shitty gambling machines!). I would be glad to help you to develop protection for your coin-ops, which could be cracked by only a very quick-minded persons.