Pandora’s Box 6 – Deep Dive, Part 2

Now that we have a general idea of what we’re looking at on the Pandora’s Box 6 file systems, it’s time to start poking around. As this is a Linux-based single board computer, some Linux knowledge is useful. I’ll do my best to explain things as I see them so that those of you who are less technically inclined can follow along and understand a bit about how the box functions.

Start Me Up

Since the Pandora’s Box 6 is built to basically be a simple appliance that turns on and does one thing, we should start our journey into it by taking a look at how it would go through starting up. Generally speaking, a bootloader would be the first thing that would run and would then load up a Linux kernel and mount a file system. Once that is done, control is normally handed off to the Linux kernel and it finishes the boot up process by mounting the other file systems needed, running various daemons (or services in the Windows world) on start up before finally handing control over to the user. Well, in our case, we have a bit of a problem here as there is no obvious Linux kernel anywhere on either the EXT3 or FAT16 file systems.

Educated guess time: I think the various boot1 through boot9 files in the FAT16 file systems are encrypted/compressed archives that likely contain either the Linux kernel itself and additional files needed or it is somehow loaded up from elsewhere. The one thing that we can easily throw out is that the Linux kernel being loaded is from the UDisk as you are very capable of booting up the Pandora’s Box 6 without it and getting a completely empty game list. (This may be something to remember in the future as it might mean that all ROMs are read from the file system and not just those in the three folders meant for users to add games to. Perhaps something we can exploit here?)

Let’s continue onward with the Linux bootup process. Linux has what it calls runlevels. Basically these runlevels are numbered from 0 to 6 and represent different states. Most Linux boxes will set runlevel to 5 which represents network up and running, graphical interface running, everything ready for users. Runlevel 6 is usually the reboot state and Runlevel 0 is when the system is halted and can be safely shutdown. There are scripts that can be run automatically when certain runlevels are hit, so let’s take a look and see if we’ve got something like that happening here.

A Simplified Look at Our EXT3 File System

Just before we start poking around, let’s take a quick tour of our EXT3 file system so you can get an idea of what you’re looking at.

This is a fairly typical file system for most embedded Linux systems here.

Starting from the top, here’s what we’ve got:

  • /bin – Binaries that are common for the system and available for most to use.
  • /dev – Files representing all the machine’s devices are stored here. (Linux treats all devices as if they were virtual files which allows for some interesting ways of doing things.)
  • /etc – Configuration files used by the system, some applications and daemons (services).
  • /home – This is where your own user files are stored, much like My Documents on Windows but more tightly controlled and secured.
  • /lib – Where you will normally find Linux kernel modules and libraries (much like Windows DLLs).
  • /lost+found – A directory where Linux will attempt to place any files it recovers upon checking the system at startup.
  • /proc – A virtual filesystem that contains information about the running system, no actual files exist here.
  • /sbin – Binaries that are needed for running the Linux system and maintaining it.
  • /sys – Similar to /proc, it is a virtual filesystem containing information about the running system.
  • /tmp – A temporary filesystem that is created in RAM and can be used by processes for temporarily storing data. Disappears when system reboots.
  • /usr – Contains binaries meant for users to run and use as well as libraries and additional files needed by those binaries.
  • We will ignore the linuxrc symlink (or shortcut) for the moment.

We’re going to take a quick look at the /etc directory to see what we can find there. Typically, it is where you would find scripts that would run when runlevel hits 5 as well as other information such as filesystems to mount on boot.

As spartan as you’ll almost ever find an /etc directory.

Poking Around Some More

So what do we have here?

  • /etc/init.d/ – A directory that normally holds scripts to run on startup.
  • /etc/fstab – A file used by Linux for mounting filesystems.
  • /etc/hostname – A filename that tells Linux what hostname the machine should use.
  • /etc/profile – A default profile for all users on the machine.

Okay, so taking a look at profile shows absolutely nothing of interest, just something for setting the default terminal prompt, which we cannot see anyways. The hostname file just tells the machine to set the hostname to “hhh”, nothing too exciting here.

Now fstab is very interesting for us as it is where you would normally find filesystems getting mounted. We would expect to find our udisk listed here among the filesystems and…

…we don’t.

Instead, what we see here are the various virtual filesystems that are needed soon after booting. /proc and /sys are created during boot up and /tmp and /dev are created soon after. Well, that would normally be the case except none of the file systems are marked “auto”, so they need to be mounted manually, likely from a script. The use of tmpfs means “this filesystem exists only in RAM”, essentially. Alrighty, so a swing and a miss. Let’s move on to the init.d directory, where we find a file called rcS that I have good feelings about. Let’s open it up, shall we?

And here’s where we start seeing something.

This small shell script is run on bootup. It tells the machine to set the hostname using the “hhh” value found in /etc/hostname. It then sets the default directories that Linux will use as its PATH variable, searching the directories listed for any executables the user will attempt to type into the console. Nothing unusual about either command here at all. But what do we have here? A command attempting to run /usr/myinit which definitely isn’t something you would find on a normal Linux box. Let’s check that out.

Finally, a little meat to chew on.

Okay, so the first two lines here set up the PATH for Linux to look for executables and the PATH to load libraries (like Windows DLLs) from. Both of these are 100% standard for Linux, so nothing odd there. But the next line… that’s… that’s something new to me. A quick Google search for QWS_DISPLAY shows that it is a variable used by QT for Embedded Linux, which is a graphical toolkit. So it is more than likely that our emulator frontend uses the QT toolkit for all its graphics.

Google is endlessly helpful when it comes to things like this.

After reading that and looking at the line in our /usr/myinit file, we can see now that it is setting a variable to tell a QT application to use the Linux framebuffer device for writing graphics to the screen using the /dev/fb0 device.

Remember when I mentioned how it was odd that /etc/fstab showed filesystems but none of them were flagged as “auto” and therefore wouldn’t be automatically mounted at boot time? Well, the reason for that appears to be that they would rather have this script do it instead. The use of “mount -a” tells Linux to mount all the filesystems listed in /etc/fstab right now, so it is at this point that those virutal file systems are mounted and active. “mdev -s” is responsible for creating all the virtual files for each of your devices in /dev. This is where, for example, the /dev/fb0 framebuffer device will be created.

Finally, we see a while loop that will loop infinitely running what looks like our frontend executable. This is exactly the kind of thing you do when you want a program to always be running because if it terminates at any point, this loop will start it back up again automatically. This is a great stopping point for now.

Summary

So, let’s take a look at what we now know about our Pandora’s Box 6 so far.

  • The udisk is formatted FAT16 and contains all of our default games and directories for adding more games.
  • The boot SD card is split into two partitions, a FAT partition that contains what looks like different archives depending on what settings you use and an EXT3 file system that houses the rest of the system.
  • The emulators used by the Pandora’s Box are MAME 0.106, Final Burn Alpha
    0.2.97.36 and an unknown PlayStation emulator (likely PCSX ReARMed, but haven’t found evidence yet).
  • The emulator frontend appears to load games up on-the-fly.
  • The emulator frontend appears to use the QT graphical toolkit for embedded Linux devices.
  • The boot sequence once we are past loading the Linux Kernel is /etc/init.d/rcS -> /usr/myinit -> /usr/emu/emulotar
  • We learned a bit about how the Linux filesystem looks and what the structure means.
  • We learned that sometimes, looking up stuff on Google can bring us some knowledge that we would have needed otherwise.
  • The Linux kernel isn’t on the UDisk as the PB6 can be booted up without it attached just fine.

In the next blog post, we will continue to pull on the thread to see what falls out as we examine the emulator frontend application itself and see what else we can find to help us.

Hope that you’ve learned something from this post. If you have questions, feel free to ask in the comments below.

Pandora’s Box 6 – Deep Dive, Part 1

This is going to be a series of posts taking a deeper look at how the Pandora’s Box 6 works and investigating what may help us break it open and get past some of the limitations we currently have with it. I don’t know how much time I have to devote to this task and I’m not sure how deep I’ll be able to get into it, but let’s poke around to see what we can find out.

Just so that you are aware, I am no hardcore hacker but I’ll be doing the best that I can while showing you what I’ve found and how, so this may be interesting to some regardless.

Superficial Looks

Before we attempt our deep dive, let’s attempt to get some information about what we’ve got the simplest way possible – just looking at the disk drives and seeing what we can find out. Let’s first take a look at the udisk – the external USB drive that comes with the Pandora’s Box 6 that you will need to copy the games onto and where you will add games of your own.

The UDisk

The udisk is a 16GB external USB drive that is formatted in FAT32 and looks like this:

Root directory of the Pandora’s Box 6 udisk. Pretty straightforward.

There’s not really all that much here for us. The movies and roms directories are where you will be copying the arcade ROMs and their accompanying videos when you receive the download links from 3A (as they will no longer give you preloaded games anymore). The romsp folder is for holding the default PS1 games that come with the unit (and pushed as if they were the original arcade versions). Inside, you’ll find a few games in .bin/.cue form, most of which are actually missing their soundtracks. You’ll find two identical copies of the PlayStation SCPH-1001 BIOS, both under the name bios.bin and scph1001.bin. A folder called mv contains movies that will play in the front end for these games specifically.

The list of PlayStation games included on the UDisk. Nothing too exciting.

Back in the root directory, we’ve got three more subdirectories which the Pandora’s Box 6 uses to check for games the user has added.

  • roms_fba – ROMs for the Final Burn Alpha emulator, version 0.2.97.36.
  • roms_mame – ROMs for the MAME emulator, version 0.106.
  • roms_playstation – ROMs for the currently unknown PlayStation emulator.

You’ll also find files that list what games the FBA and MAME emulators support… which isn’t entirely truthful as far as I can tell. The Final Burn Alpha game list shows all the various console emulators it normally supports as well as the standard arcade games, but so far, I’ve been unable to get any of the console games to load beyond just showing up in the Pandora’s Box 6 menu. There are also README files in both English and Chinese. That’s all that appears on the UDisk, so let’s create an image of the boot SD card and see what we’ve got there.

The Boot SD Card

I’m going to take the disk image I made of the SD card and I’m going to open it up in ISOBuster which is my tool of choice for poking around these backup image files.

First, we see that the SD card consists of two partitions, a partition containing a FAT16 partition and a partition containing a Linux EXT3 file system. This is pretty common for just about any sort of single board computer, like the Raspberry Pi, but unlike the Pi, it looks like the Fat16 partition does not contain the files you would normally expect to see that are required for booting up the board, such as a kernel. Instead, we see 9 files called boot and are numbered from 1 through 9.

Notice something odd here?

Each file appears to contain data that we can’t easily read, perhaps even some encrypted archives. Unfortunately, there are no magic bytes that match these so there’s no easy way to tell what this data is. I’ve got a slightly educated guess after seeing some of the similar partitions on other Pandora’s Box 4 clones. Looking at the file sizes of them, we see a pattern emerge. Boot1, boot4 and boot7 all are the same size. And if we look at the other files, we do see the same pattern (boot2, boot5, boot8 and finally boot3, boot6 and boot9). I am guessing here that these groupings are based upon the three different resolutions that the Pandora’s Box 6 can boot up in, which matches up to what I’ve seen on other clones. It also appears that the Pandora’s Box 6 supports three different languages – English, Traditional Chinese and Simplified Chinese. So here’s what I think these files are for:

  • boot1, boot4 and boot7 – likely files supporting booting in 1280×720 in English, Simplified Chinese and Traditional Chinese.
  • boot2, boot5 and boot8 – likely files supporting booting in 1024×768 in English, Simplified Chinese and Traditional Chinese.
  • boot3, boot6 and boot9 – likely files supporting booting in 640×480 in English, Simplified Chinese and Traditional Chinese.

When comparing files with the same size, they actually did have a lot of differences between them, so it’s not just 3 copies of the same file, which supports our language theory. If we take a look at the Pandora’s Box 5’s FAT partition, we see just two files present – boot1 and boot2, both of which have the same file size as the 1280×720 boot files. The Pandora’s Box 5 only supports 1280×720, however, and I’m not sure why there are two files here and not just one, but so far, I feel like we’re going down the right path here.

Taking a quick look at our EXT3 partition, we see what looks like a standard but stripped down version of the folder structure you would normally see on the main partition for any embedded Linux system.

Pretty standard set of files on the main Linux file system.

One thing that I would like to point out is the Linux partition’s name which appears to show the UUID partition label as well as where it was mounted to during development, which reveals that the main person responsible for creating these SD card images at 3A is likely named Zhang.

The Pandora’s Box 6 main partition UUID, apparently made by “zhang”.
The mysterious zhang appears again on the Pandora’s Box 5’s main partition name.

Just for funsies, let’s take a look at the same system partition on a Pandora’s Box 4s 1299 game clone and…

Uh… Mr. John Smith?

…and clearly, the bootleggers are taking the piss, so to speak.

In The Next Episode…

Now that we have taken a bird’s eye view of the Pandora’s Box 6 file systems, we’re going to start diving down into it to see what we can discover about how it works, the boot process and what fun scripts we might be able to find. Hope that you’re enjoying this so far and I’m looking to put out the next post within a week.