Sometimes reverse engineering embedded systems can be a right old faff, with you needing to resort to all kinds of tricks such as power glitching in order to poke a tiny hole in the armour, giving you an way in. And, sometimes the door is just plain wide open. This detailed exploration of an off-the-shelf retro arcade machine, is definitely in that second camp, for an unknown reason. [Matthew Alt] of VoidStar Security, took a detailed look into how this unit works, which reads as a great introduction to how embedded Linux is constructed on these minimal systems.
The hardware is the usual bartop cabinet, with dual controls and an LCD display, with just enough inside a metal enclosure to drive the show. Inside this, the main PCB has the expected minimal ARM-based application processor with its supporting circuit. The processor is the Rockchip RK3128, sporting a quad-core ARM Neon and a Mali400 GPU, but the main selling point is the excellent Linux support. You’ll likely see this chip or its relatives powering cheap Android TV boxes, and it’s the core of this nice looking ‘mini PC’ platform from firefly. Maybe something to consider seeing as though Raspberry Pis are currently so hard to come by?
Anyway, we digress a little, [Matthew] breaks it down for us in a very methodical way, first by identifying the main ICs and downloading the appropriate datasheets. Next he moves on to connectors, locating an internal non-user-facing USB micro port, which is definitely going to be of interest. Finally, the rather obvious un-populated 3-pin header is clearly identified as a serial port. This was captured using a Saleae clone, to verify it indeed was a UART interface and measure the baud rate. After doing that, he hooked it into a Raspberry Pi UART and by attaching the standard screen utility to the serial device, lo-and-behold, a boot log and a root prompt! This thing really is barn-door wide-open.
Simply by plugging in a USB stick, the entire flash memory was copied over, partitions and all, giving a full backup in case subsequent hacking messed things up. Being based on U-Boot, it was a trivial matter of just keying in ‘Ctrl-C’ at boot time, and he was dropped straight into the U-Boot command line, and all configuration could be easily read out. By using U-Boot to low-level dump the SPI flash to an external USB device, via a RAM copy, he proved he could do the reverse and write the same image back to flash without breaking something, so it was now possible to reverse engineer the software, make changes and write it back. Automation of the process was done using Depthcharge on the Raspberry Pi, which was also good to read about. We will keep an eye on the blog for what he does with it next!
As we’ve covered earlier, embedded Linux really is everywhere, and once you’ve got hardware access and some software support, hacking in new tricks is not so hard either.
considering the maker of these cabs is probably made up of The Kind Of People That Read HackADay, the openness and lack of pitfall security features may be fully intentional! Reinforced by the presence of an extensive repair part catalogue in-site
Yeah, I’m thinking their idea was along the lines of “Why bother securing the system? It doesn’t have any Internet connection, so the only people who care will see having it unsecured as a bonus.”
“low-and-behold” — It’s lo-and-behold. “Low-and-behold” doesn’t even make any sense, like are you telling a person to low out loud? Lowing is what e.g. cows do, ie. mooing.
Lo: used to call attention to something or to show wonder or surprise — https://www.merriam-webster.com/dictionary/lo
Muscle-memory fail. Fixed, thanks.
I thought it was a pun, considering the working directory is moo. If it was intentional, it was quite witty.
Sorry, I didn’t spot that punning opportunity. Must try harder.
I had fun doing similar with a 1up Space Invaders Arcade machine, we were adding a Nano (cryptocurrency) faucet to the game where you were rewarded depending on the score. While it would have been easy to replace the whole system instead we used the embedded linux and just ‘manipulated’ it to work for us.
A short article: https://medium.com/@jacoxon/introducing-nano-arcade-fusing-nano-with-space-invaders-e551069bdc1e
There’s a group of us who have been anonymously developing ‘mods’ for these arcade cabinets for some time now ‘exploiting’ the systems in similar ways to what Matt has described here.
A lot of the challenge in doing has mostly been cross-compiling for the respective platforms two examples of modifications done can be seen here: https://www.team-encoder.com/MysteryPawRC1
And here:
https://www.team-encoder.com/node/7
Because of the nature of the systems and the way the individual SoCs operate as well as the Micro USB being wired into the SoC’s programming interface as well as the switch on the back of the PCB enabling a flash mode it’s entirely possible to create one click exploit/installation/modification software that doesn’t even require the end-user to open the cabinet more than removing the back of it and plugging in a micro usb cable to their PC in most cases, no UART, no uboot escapes just pushing and launching payloads straight on the processor through the internal flashing mechanism.
Ultimately some were speculating in the comments that they thought the company did it intentionally, they did not. They were originally a toy developer and really had no idea how to secure things. They’ve started to disable UART on some of their systems, and even change dtb configurations in cases where the USB was left enabled, this was one of their earlier designs and they outsource the integration so each one is different in terms of it’s attack surface or the viability of getting into it as easy as escaping UART.
Can anyone solve the mystery/problem of accessing the arcade1up nba jam pcb? I have a new one and no one anywhere on the planet knows how to access it or change the software on it.