Okay, when we last left off, we found what looked to be our emulator frontend, /usr/emu/emulotar. It appeared to be the program that the Pandora’s Box 6 wanted to keep running at all costs and it looked like some scripting set up the use of the Linux framebuffer for the QT graphical toolkit for embedded Linux. Let’s try to verify our assumptions by taking a look at emulotar with a hexeditor.
Personally, I am using HxD, a freeware hexeditor for Windows that should work fine for most cases, including this one.
Do We Know What We Think We Know?
Let’s start off by verifying a few of our previous assumptions. We’re going to rip open /usr/emu/emulotar and take a look at what we might find inside. When looking at a file with HxD, we will see the hexidecimal representation of the file on the left and a translation to ASCII on the right. This helps us visually look for strings of text within the file easily. So, let’s open ‘er up.
The very first thing we see when opening up the file is “.ELF”. This is a tell-tale sign that we’re looking at an .ELF file, which is an executable built for ARM processors. This is exactly what we’re expecting to see as the Pandora’s Box is built on the ARM architecture.
I know what you’re probably thinking right now.
“Jay, that’s… not very interesting.”
And you’d be right. However, there actually IS a lot in this file that IS actually interesting. Starting at offset 0x00005C40, we have what appears to be a block of strings. These appear to be commands that the emulator frontend is running which will give us some insight into what’s going on.
Instead of just giving you screenshots, I’m going to list what I find here and explain what they mean/do and take a guess at how things are working. Here are my little notes on what I think I’m looking at and I’ll take a final guess as to what is going on afterwards. This is a little information-dense, so feel free to skip this.
- /dev/spidev1.0 – I believe this is a device file for the SPI bus and it’s likely that controls are accessed by reading GPIO pins through the SPI bus. I would have expected a /dev/spidev0.0 rather than a 1.0, but who knows…
- /dev/mem – The normal device file that all the RAM is mapped to, normal in Linux land.
- /dev/fb0 – The framebuffer device. Also to be expected in Linux.
- echo volume – A command that would write “volume” to the screen. Odd.
- %d – Usually used as a token for another variable. Impossible to tell what this is here for alone. The 00’s show that this isn’t just a part of the next line as they would be spaces (20) instead but they aren’t.
- 1 > /tmp/mfile & – This appears to be a fragment of a command. The intent appears to be to write the contents or output of a file into /tmp/mfile. The “&” here tells Linux to do this in the background. It appears that the file being copied to /tmp/mfile is a video file, likely the Pandora’s Box 6 intro video that you see on bootup.
- /bin/vp -slave -input file=/tmp/mfile -quiet -volume – This appears to be our video player application. A quick look at vp using our hexeditor shows that it appears to be a version of mplayer, the popular Linux video player. So it looks like vp is mplayer in disguise and is told to play the file found at /tmp/mfile.
- /bin/vp -slave -input file=/tmp/mfile -quiet -zoom -x 384 -y 226 -volume – Exactly the same as above except we can see that it appears to be playing at a small resolution. This is likely the command used when the Pandora’s Box 6 is used through a JAMMA connection to a low resolution arcade machine.
- /tmp/libboot.so & – This tells Linux to run the file as an executable in the background. This is slightly odd as usually any file that ends in .so is a shared object, similar to Windows DLLs… but in Linux, you can name anything whatever you want so it’s not a hard and fast rule. This appears to be common on the pirate versions of the Pandora’s Box at least.
- rb – Unsure. Too small to speculate. See wb below.
- /dev/mmcblk0 – This is the device file for the first SD card that Linux finds. This would be where the Pandora’s Box would find the SD card it uses to boot from.
- app1, app2, app3, app4, app5, app6, app7, app8 – I believe that – much like the previous boot1, boot2 files we found previously – this is potentially the emulator application set up for different languages/resolutions.
- wb – When seeing wb and rb somewhat close together, it is possible that this is a flag for opening files as writable (wb) or read-only (rb). Until we can dig into everything ourselves, this is just a guess.
- /tmp/app – Later on, it appears that this is the path to the main emulator executable used by the Pandora’s Box 6. I believe it is a combination of MAME, FBA and PCSX Reloaded in a single executable but this is currently unknown.
- We now have what looks like 4 different sets of mplayer executables copied to /tmp/vdt as well as 4 different sets of .so files:
- cp /bin/mplayer /tmp/vdt – Copies /bin/mplayer to /tmp/vdt. Also has the following files listed: /tmp/libboot.so, libbootc.so, /tmp/liblogo.so, liblogoc.so. libbootf.so, liblogof.so, libboote.so, liblogoe.so. Very likely that the files that end in c are Chinese, those ending in e are English. Very possible that these are the logos shown on the screen during boot up before the video is played and when a game is launched.
- But we also have cp /bin/mplayer1 /tmp/vdt with the following files: libbootc1.so, liblogoc1.so, libbootf1.so, liblogof1.so, libboote1.so, liblogoe1.so
- Same cp and files mentioned for numbers 2 and 3 as well. Very likely meant for different resolutions. On closer inspection, the mplayer3 version does not appear to have any files ending in f as the others do. Perhaps this is the one for the JAMMA version?
- Much like the repeating blocks of files and commands for 4 different versions of mplayer, we have something similar with libcfg.so files, but also the Pandora’s Box 6 allows players to change the background of the menus by copying a file on the Udisk. If the number scheme holds up, it appears that we’ve figured out what the numbers mean. No number = 1280×720, 1 = 1024×768, 2 = 640×480, 3 = 384×224.
- tar -xf /tmp/libcfg.so -C /tmp – This extracts the files from within /tmp/libcfg.so directly into /tmp. Most likely what happens here is that the version of libcfg.so taken from above is copied to /tmp/libcfg.so before being decompressed. So I think this is going to be a set of configuration files for MAME that is setup for the different resolutions.
- rm /tmp/libcfg.so – Delete the /tmp/libcfg.so file after decompression.
- cp /tmp/config/xmame/nvram/* /tmp/ – Almost 100% certain that these are premade NVRAM files for different games with preselected settings. Likely something like this also with save states for the PlayStation games allowing them to skip all the intros and loading at the start. So this means that they have an archive of NVRAM files dumped into /tmp. This is where we would need to put in a fixed joust.nv so that Joust would be playable.
- We appear to have a list of filetypes that this emulator frontend supports showing – bin, cue, img, mdf, pbp, toc and cbn for the PlayStation emulator and zip for MAME/FBA.
- /tmp/imagesc.so – Unknown, perhaps Chinese only due to this being the only version of the file mentioned? Haven’t found references to this elsewhere yet.
- /tmp/mfile, mkfifo /tmp/mfile – It looks like the /tmp/mfile that is used for playing a video through mplayer is a named pipe. Basically, the video file is piped through /tmp/mfile for mplayer to play it. It’s okay to not know what that means, just think /tmp/mfile = start up video and you’re good.
- mkdir /tmp/udisk, mount -a, mdev -s, /dev/sda1, mount -t vfat /dev/sda /tmp/udisk – It looks like we have the emulator frontend setting up the mounting of the udisk, which we expected to find in /etc/fstab but didn’t. What is very interesting about this here is that it doesn’t look like the udisk is mounted as read only, so it’s very possible that maybe we can output some logs or something out to the udisk for analysing.
- killall -9 vp – Forcably kill the video player when everything’s mounted and ready?
- rm /tmp/libboot.so – Delete /tmp/libboot.so when done with it.
- 4 calls of mplayer0 playing /tmp/liblogo.so in all four resolutions the PB6 supports… except that the horizontal resolution is 2 pixels wider for… whatever reason. So 1280×722 instead of 1280×720, for instance. Odd that they only use mplayer0 for this and not mplayer1/2/3 as we see elsewhere.
- /tmp/udisk/roms_fba, /tmp/udisk/roms_mame, /tmp/udisk/roms_playstation – These are the three different folders that users can drop their ROMs into to get added to the PB6 and their mount points.
- killall -9 mplayer0 – Kill the video player when we’re done loading up user roms?
- rm /tmp/liblogo.so – Delete the logo when we’re done?
- /tmp – Seems to be where most of the work is being done here, the temporary RAM disk.
- chmod 777 app – Set the permissions to allow read/write and execute on app. I believe this app program is our actual emulator.
- /app -qws 54 54 20, /app -qws 54 52 20, /app -qws 52 54 20, /app -qws 52 52 20, /app -qws 54 54 30, /app -qws 54 52 30 – Pretty sure that this runs our emulator at different resolutions. Likely that qws has to do with the QT toolkit.
- rm app – Delete the emulator when we’re done? Why?
- /app tankfrce, /app btime, /app 54, /app 52 – I believe this is how the emulator to run for each ROM is selected as it mirrors something I remember seeing in a pirate Pandora’s Box. As far as I remember, while tankfrce (Tank Force) and btime (Burger Time) are legit MAME roms, I believe the emulator looks specifically for these games being called to know to switch to either the FBA or MAME emulators. It’s… an odd way of doing things, that’s for sure.
- Just a few more device file names, and some error text after that, nothing special.
- /dev/dsp – Likely the device file for audio output.
That’s about all the interesting text we’ve got here, so let’s take a look at everything we’ve got so far and take a guess at how this whole thing is functioning.
It’s getting late though and I’m tired. So I’ll write up a full guess into how the Pandora’s Box 6 boots up and runs, how it does things and when. I’ll also mention a few potential attack vectors for breaking into the box.