After 15 minutes spent trying to decipher this, I simply translated the code into Python and iterated infinitely. Turns out, this is how you perform big-endian addition without actually converting the number to little-endian. An odd way of doing it, but perhaps a compiler optimisation. It turns out they’re actually using AES_CTR, but instead of incrementing the entire counter IV, they’re only using the last 4 bytes. A little strange, but if your encrypted file is 232 16 bytes long, you have other problems to worry about.*
Not all that strange. The "counter block" is normally split into a nonce, which allows you to reuse the same key on multiple messages without generating a duplicate keystream, and a counter; an AES block is 16 bytes wide, so a 64 bit counter is more typical, but I've seen 32.
Doing that can even make sense, if you have bounded message sizes (<64 gigs) --- the larger the space you allocate for the nonce, the safer it is to generate nonces randomly, rather than using a system to remember all previous nonces to avoid collisions.
This stuff has been documented in private circles for over a decade now, and hasn't been made public because these games aren't available to play outside of owning a cabinet in Japan or acquiring the data via less-legit methods. While it's a fun exercise to explore, the real-world application is sadly limited to grey-market implementations that Konami frowns upon, which reinforces why the exposure has been limited.
> On the one hand information wants to be expensive, because it's so valuable. The right information in the right place just changes your life. On the other hand, information wants to be free, because the cost of getting it out is getting lower and lower all the time. So you have these two fighting against each other.
--Stewart Brand at the first Hackers Conference in 1984
Perhaps, but the details could put certain people in life-altering danger. The safety of these people has very rightly taken precedence over publishing information which could be quite literally incriminating (although they almost certainly wouldn't be prosecuted for it, just sued for all they're worth).
Konami has contacted some insiders and some arcades with stern legal warnings and they are taken very seriously. There's a joke in the community - "konmai will sue" - but it's not just a joke.
Well, the process itself regardless of the data is interesting. Likewise, surely for archival purposes once the games are decommissioned and people want to preserve them it will be useful to have, no?
I find your response just a bit weird; it's a nice break down of niche and likely easily lost technology once Konami et. al. are done with it. It's a nice read, well written, serves those looking to archive these games in the future, and also is a great high level overview of the reverse engineering process.
Is the issue that it has no immediate benefit to you?
This is the company that continues to ship new games with Windows XP Embedded (they are allowed to due to a technicality in the licensing agreement with Microsoft). No one expects them to up their security game all of a sudden - and I sure hope they don't :D
Of course, thank you to all of those who have done this type of work over the years! You know who you are.
Actually, they've actually been using Windows Embedded Standard 7 on a lot of their newer kits lately. This started with Dance Evolution Arcade (mainly because it needed Kinect drivers, since it was a essentially an arcade version of a Xbox 360 Kinect game called Dance Masters), but they've slowly been using 7 on newer cabinets for existing and newer franchises.
Konami changed their model for updates to their games around 2013; although most of their games use a roughly annual release model (with each new version featuring a new interface theme and branding, new content and features, etc.), they introduced a leasing system called "e-Amusement Participation" that, in most cases, supports in-place upgrades to new releases (rather than just patches to the existing version installed on the cabinet, and having to upgrade by replacing the hard drive and security dongle).
Unless the update actually requires the installation of new hardware (such as a new PC and I/O system, such as the latest beatmania IIDX release -- which, in case you're wondering, comes out on Thursday), it's pushed like a Windows 10 automatic upgrade as part of the bootstrap script. However, this doesn't update the OS, hence these older cabinets are still running the copy of XP Embedded from the last version they ran before the automatic update system was put in place.
https://www.youtube.com/watch?v=BPvjhkyl048 shows Nostalgia (another Konami game) booting up into Windows Embedded Standard 7 and installing its "Forte" update. The bootstrap script is nearly identical on every Konami game, and involves quite a few console windows.
MAME has long lacked support for certain Konami games. Is it because of this? Could MAME now support those Konami games, in jurisdictions with no anti-circumvention laws?
Konami didn't start using Windows for its games until IIDX 9th style, Pop'n 15, DDR X, and Drummania V...6 i think?. Before that, it was all custom hardware, based off of the PS1, PS2, or just an in-house creation. Older IIDX for instance uses a combination of a CD drive, a DVD drive, and an IDE drive for storing all its data, not to mention ROMs soldered onto the boards. The MAME team has actually just started to get the older games working, but require dumps which are hard to come by - thankfully the fans of these games have been collecting dumps for years and they are slowly being cataloged and added in.
DDR has been a thorn particularly because they used a custom chip for decoding encrypted MP3 streams in the System 573, something that MAME hasn't wanted to touch due to patents.
I highly doubt the newer games will go into MAME anytime soon - partly because they all run Windows XP embedded, and also because they are most likely considered "too new" for inclusion.
These systems still run custom hardware for things like IO, and those parts of the systems are emulate-able.
Getting emulation of said IO chips and whatever seems pretty inline with MAME's mission statement: "MAME's purpose is to preserve decades of software history."
Not all that strange. The "counter block" is normally split into a nonce, which allows you to reuse the same key on multiple messages without generating a duplicate keystream, and a counter; an AES block is 16 bytes wide, so a 64 bit counter is more typical, but I've seen 32.
Doing that can even make sense, if you have bounded message sizes (<64 gigs) --- the larger the space you allocate for the nonce, the safer it is to generate nonces randomly, rather than using a system to remember all previous nonces to avoid collisions.