Taito X3 research


Taito X3 is current commercial arcade system.
You should legally own the machine, hard drive and matching hardware key.


Do NOT try to reset CMOS or remove the battery, it would erase encryption keys, needed for ATAsec calculation.

The protection system of X3 is quite a strange one. It incorporates both very strong design and very weak in one. You don't need any special tools to dump a game from X3.

There are 2 layers of data protection:

  • The HDD is protected with ATAsec password.
  • Game itself runs from virtual disk, that is mounted by Taito Loader (TDEGBoot.exe) from encrypted file container, using a key from the dongle.

Old good XBox method works well against X3 ATASec, than it is a matter of injecting custom executable file into Windows 7 Embedded. I use Q-Dir renamed and placed as "C:\Windows\System32\taskmgr.exe", it is nicely invoked by Ctrl+Shift+Esc hotkey. Then observe the loader mounting encrypted partition - and here are all the game files at your disposal.

The game itself (now I have only Lord of Vermilion VI) is happy to run from any Windows PC.

Of course it still needs network and connection to NesicaLive (as well as Nesica USB card reader) for playing, as this exact game is online multiplayer only. I just want to have it running in demo/tutorial mode only, as an exibition of "look, they play these in Japan". LOV IV is Unreal Engine 3 based, and the developers were generous to include local gameserver and all the debug PDBs with the game. Thanks SQEX!

What if I want to run different X3 game on the same hardware?

Let's say I have the original HDD and hardware security dongle for another game. Here comes the problem. Your X3 mainboard will not boot HDD from a different game, even it is from another X3.

ATAsec password to unlock the HDD is derived from:

  • Security Dongle
  • Mainboard CMOS (my assumption, as replacing cmos battery kills the keys)

Communications with the security dongle

Security dongle is a Renesas R8C MCU, which is connected to the FastIO PCI-e board. Taito FastIO board is based on iDMAC on Xilinx FPGA. Fun thing is that dongle communications are then exported by standard serial link from FastIO board into mainboard's COM2 port.

LOV IV MAIN dongle comms look like this:

> E0 00 02 FF 01 
< E0 00 03 01 01 05 
> E0 80 02 FE 80 
< E0 00 23 01 01 9E FD D1 16 80 5E CE 93 B2 68 F7 8F DA 8F 1B 9F 50 3A 6E 4D 74 08 AC CC 93 15 7A 89 1F E1 18 17 BC --- the atasec key 
> E0 80 12 FF E4 30 7C B9 C7 C8 57 60 53 F0 2C 1C 59 98 1B 02 B9 --- don't know what is that
< E0 00 03 01 01 05

> to dongle < to host from dongle

E0 00 and E0 80 are headers, third byte is length of the remaining data, that follows immediately. In this dialog bytes, containing ATAsec key are:

9E FD D1 16 80 5E CE 93 B2 68 F7 8F DA 8F 1B 9F 50 3A 6E 4D 74 08 AC CC 93 15 7A 89 1F E1 18 17

however the final key is calculated by BIOS with this key AND some data from the CMOS. Exact contents and algorithm is not yet known.
Final ATAsec key, which is send to the disk looks like:

58 33 3A 30 30 30 30 30 33 46 30 3A 55 63 51 53 59 53 50 58 50 65 62 65 68 69 92 85 90 8A 6B 98

Which says X3:000003F0: followed by 20 binary bytes. 3F0 is the game id. I suspect that the keys are unique for each dongle/disk pair shipped and X3 cmos key is unique for each game title. "Title" can include several game ids. Like this LOV has hardware game id 3F0, but id reported by Taito loader is 3F6 or "10-14" in the test menu (1014 is 3f6 in hex).

Now: How I know, that those bytes given by the dongle are the encrypted ATAsec password?

Well. By co-incindent I got an X3 dongle marked as "Developer Dongle". It works the same way as production one. Almost. When dongle's key is not matching something host has in the cmos - host would try to unlock the drive with ATAsec password, which would be made up by simply XORing dongle's key with FFs

> E0 00 02 FF 01 
< E0 00 03 01 01 05 
> E0 80 02 FE 80 
< E0 00 23 01 01 A7 CC C5 C8 B9 B9 B9 B9 B9 B9 B9 C5 CA BD BC CA C6 BE CF BD CD B9 C6 BC BB B9 CE CB CD BE C9 CA 49 
> E0 00 02 FF 01 
< E0 00 03 01 02 06

ATAsec password calculated from above dialog would be: X3:7FFFFFFF:5BC59A0B2F9CDF142A65 Allthru X3 would unlock the drive - it does not boot from it. Even if I take original drive, disable ATAsec and re-enable it with this password. It does boot the BIOS, unlocks the drive, then handing over boot process to the loader. But there it is stuck. Loader needs investigation (if someone wants to run their X3 as very expensive generic PC).

I also have a set of LOV III disk and dongle. As with the developer dongle, the key supplied to X3 is not matching to something in the CMOS and X3 uses FF to XOR the provided key, this results in arbitrary bytes instead of a usefull ATAsec password. Developer dongle's key is designed to be XORed with FFs and produces a valid "X3:blahblah" string, while other keys would produce arbitrary bytes.

What's next? I need more input data. I expect to get some more LOV IV disk/dongle pairs with the PCs in the next few weeks. And some USFIV (just disk/key) as well. If someone has functional X3 - let me know what key dongle sends to the host and what is the reply.

I have thought about researching R8C (MCU inside the dongle), but it does not seem to be worth, as dongle-host communications are plain serial port exchange (at 115200 8N1).

Future areas of interest: BIOS, cmos contents, bootloader.

Also TDEGBoot checks hard drive make, model and serial, actually it spawns a cryptically named process from C:\TDEG, which does all the fun security stuff, including talking to the dongle to get the key for mounting the encrypted virtual volume with game binaries & data.

I have made a backup disk with "dd" and it is unlocked by BIOS and boots Windows fine, then Taito Loader steps in and stops with "Error 2702" after checking drive serial number. At this point I can still make it work by replacing drive serial number on SATA bus with LeCroy Infusion, but that's not the way to go, should understand where drive maker/model/serial are stored for comparsion.

Mainboard contains TPM chip and Windows come with "Infineon Security Platform Software" installed, but it reports the TPM as not initialized.


Personally I usually understand how things work just by looking at something. Looking at LOV IV cabinet I don't have and idea how it detects playing cards on the playfield. It is very accurate in detecting several cards, with each card details, position and rotation angle. There is nothing special about the cards - no NFC or any other embedded tags. Even personally seated at one of the machines in Tokyo - I was unable to tell how it works. So I have started researching the software for any clues. Still none. It has some custom DLLs: ZCardReader.dll and some code refering to "FlatReader module". LOV III machine had a camera right under the screen, overlooking the playfield. This one does not. At least I was not able to spot it, even personally sitting at the machine.

Call me crazy, but I have made a bid (and won) a whole cabinet from Yahoo! Auctions. Now I expect delivery to cost me a fortune (the cabinet itself was won for a starting bid of $136), but may be it would make my hunger for knowledge to go away. For some time at least :)

Got some information to share? Ping me on Twitter or Telegram: @ArcadeMachinist

This article is my 3rd oldest. It is 1433 words long