Hi. I know it's been a while since the last post in this series. I apologize for the wait. I promise, the wait has been worth it.
It's almost exactly 6 months since the last PB6 hacking post went up. I'll be honest - I was having a lot of trouble getting further into it. I felt like I had exhausted most of my options and hit a wall. When that sort of thing happens, it makes my interest wane a bit. I had kind of drifted away from anything Pandora's Box for a little while.
One day about a month ago, I got messaged by someone who I will not name here at his request. He sent me a video that showed that he was able to replace the bootup videos as well as the Pandora's Box 6 logo on the main menu. When I asked him how he had gone about doing this, he replied that he had used binwalk to find the files he needed to change. For those unaware, binwalk is an application usually used with binary blobs to extract interesting stuff. So for instance, it can be used to try to find files stored within, say, the .bin file you use to upgrade your router. It's very useful for any sort of firmware exploration of embedded systems. He quickly stopped responding to me after a day or two and unfortunately, after a full weekend of poking around with binwalk, I wasn't really able to extract anything truely useful that I didn't already have. I also attempted to disassemble the applications on the box using snowman, but didn't really get too far with it. The output wasn't very helpful. It was frustrating, however it wasn't a waste of time as I hadn't ever used binwalk or snowman before so always good to have more tools in my arsenal now. In my opinion, if you learned something new, your time isn't really wasted.
What that experience really gave me was the realization that I still had a real desire to continue the work on the Pandora's Box 6, but I was still running into the same issues I was previously: any time I made a change to anything on the default SD card that holds the original operating system, it would refuse to start up. After a short spurt of energy, I was back to exactly where I had been with no further progress to show for it. Again, my interest faded away a bit.
A few days ago, I was contacted on Discord by Methraton who had read my previous PB6 hacking posts and wanted to know how far I got with it. He explained that he had started to disassemble the emulotar binary and was having more success with it than I was. (Using a far better disassmebler also helps a lot as I learned.) We compared our methods and I made a discovery. There's a script that is run on bootup on the Pandora's Box 6 called myinit. It is responsible for kickstarting the process of getting the PB6 running with the frontend. I had tried making edits to the script and it would cause the SD card to stop being bootable. Instead, Methraton was copying the files from the SD card to his PC, making his changes and then copying them back over to the SD card, while I was just directly editing and saving the file on the SD card. Apparently that difference is the real reason why I was failing while he was getting somewhere. It's somewhat frustrating to realize how close I was months ago and never thinking of trying it his way before.
Everyone that's been looking into hacking the Pandora's Box 6 has wondered where the box gets the files it needs to run. We knew they were likely extracted to /tmp (a RAM disk) and run from there. We were indeed able to confirm that is exactly what is happening. Also, we have found a way to extract the files the Pandora's Box needs. We are still no closer to knowing exactly where on the SD card they are stored but with our method, we don't actually need to know where they are yet. I know that I've been very very open about everything I've done with hacking on the PB6 to this point, however I'd like to keep our method secret for now. Anyone that's serious about hacking the box should be able to figure out the method pretty easily but we don't want to tip off 3A to our method with a new Pandora's Box right around the corner. If they don't know what the method is, they won't know what they need to change, right?
We were able to confirm a lot of the information I speculated in the previous blog post. Pretty much most of it at this point. We had a way of extracting all the files the PB6 uses from whatever magical vault they come from, so let's talk a bit about our findings.
(For simplicity's sake, I'm going to ignore the differences in language and resolution as it just makes the explanation more difficult. Realize that just like we speculated previously, almost all the files mentioned below have special versions for each language and resolution, but I'm going to just explain it with just the defaults.)
During booting up, the box grabs files from its special stash and puts them into tmp. It then copies /bin/mplayer to /tmp/vdt and uses it to play two videos on the screen. First, the "Pandora Box - Dream Never ENDS!" video. It turns out that the libbootX.so files are actually plain old video files despite their extensions. So /tmp/vdt plays libbootX.so on the screen, which is the "Dream never ends!" video. It follows that up by /tmp/vdt playing the liblogoX.so file, which is also a video of just the last frame of the previous video. It is 5 seconds long, contains no audio and there is no movement in the video. Seems odd but I think it is only there for timing reasons to make the transition to the frontend look smooth. At this point, app and libcfg.so are put into /tmp. libcfg.so is actually just a compressed archive in tarball format, again, despite the extension saying otherwise. Let's take a look at what's inside.
Within a config folder are the following:
- images - directory of unreadable png files for the menu logo, menu items with selected and unselected versions
- sound - directory containing the 4 sound effects used in the main menu and settings menu
- xmame - directory containing the xmame directory structure, all empty with the exception of the nvram folder and images folder
- images.so - unknown, not a tarball, looks possibly compressed or encrypted
- xmamerc - main xmame configuration file for default 1300 games, roms on USB stick
- xmamerca - main xmame configuration file for games added in roms_mame on USB stick, 100% same as xmamerc except for rompath
(There is also a "back" file that is only in particular versions of the libcfg.so archives. Not sure what it is or what it's purpose could be. The file contains nothing but the word "back." with period. We'll be ignoring this for now.)
Within xmame/nvram, we find the following two files: qix.nv, bubblem.nv. Both of these games require the NVRAM to be initialized the first time they are played. On standard MAME on PC, these files are written out to disk and you have to force the game to restart afterwards. On Pandora's Box, since there is nowhere for the files to be written to and no way to force the game to reset, there was no way to get games that required the NVRAM/EEPROM to be initialized to work. This was something we saw while working on the Community Collection as games like Joust and Defender would be unplayable on the Pandora's Box.
By editing the xmamerc and xmamerca, we were able to redirect the (mostly unused) MAME configuration directory to a directory on our USB stick. This directory has many more .nv files for games that require EEPROM/NVRAM initialization to start. I created a script to look for the xmamerc/xmamerca configuration files existing in /tmp and we automatically replace it with one from our USB stick so that when we start a game, it uses our options. We fiddled around with a few other options such as throttle and found that for some games, it really really helped to eliminate some screen tearing but makes other games run WAY too fast. We'll look to find a way to special case the throttling as soon as we can so that it only happens when you start a game that benefits from it.
This is how we got Joust, Joust 2, Defender, Stargate, Run and Gun and others to run on the Pandora's Box 6. There's still so much more to tell you about that I haven't gotten to but I didn't want this post to just be me vomiting info constantly... so you can likely expect more blog posts explaining our progress over the next few days. Honestly, it's going to be difficult to keep writing these posts fast enough with all the progress we've been making.
Thanks for reading, part 5 coming very, very soon.