After our recent adventures with the Konami Picno, VTech Socrates, and Class200, it was time to tackle another interesting system with a missing piece of firmware.
This time, our target was the Go Retro! Portable from Retro-Bit.
Released in 2018, this Game Boy-style handheld comes packed with more than 260 built-in games. Unlike many other inexpensive multicarts, the Go Retro! Portable includes a surprisingly interesting selection of officially licensed classics from Capcom and Data East.
We're talking about games such as Mega Man 2, Mega Man 3, Ghosts 'n Goblins, 1942, 1943, Bionic Commando, Bad Dudes, BurgerTime, and many more.
Under the hood, the system is based on NES-derived VT-series hardware, combining a familiar gaming architecture with some rather unusual custom features.
The complete game collection is stored in a massive 32 MB flash ROM.
The system was already supported experimentally in MAME, but something had been bothering us for quite some time.
A mysterious little 8-pin chip was still hiding a piece of the puzzle!
And naturally, we wanted to find out what was inside.
The Missing Protection ROM
While the main 32 MB game ROM had already been dumped, the Go Retro! Portable contains another small chip used during the system's initialization.
This mysterious 8-pin device supplies a small amount of data that the console copies into RAM and subsequently uses as executable code.
Without this data, the original software cannot behave exactly as intended.
The MAME driver already contained a workaround, but it wasn't the real thing.
Instead, the emulation relied on a modified version of protection code borrowed from another system, adapted just enough to make the Go Retro! Portable's menu work.
The corresponding protection.bin was therefore marked BAD_DUMP in MAME.
It was a clever workaround, but from a preservation perspective, it left an important question unanswered.
What exactly does the original 8-pin chip contain?
Could we somehow convince the console to read that chip again and reveal its contents?
After our previous successes with Trojan-based ROM dumping, the answer seemed obvious.
Let's try another Trojan horse!
But first, there was some hardware work to do.
Goodbye BGA, Hello DIP42!
Instead of having a conventional flash chip soldered directly onto the motherboard, the system contains a small PSOP44 subboard carrying a 32 MB BGA flash chip.
Now, a BGA chip isn't exactly something you want to repeatedly remove, program, and solder back into place.
And since our experiments would certainly require multiple custom ROM versions, I needed a much more convenient solution.
Fortunately, the PSOP44 subboard gave me an idea.
Why not remove the entire subboard and connect an ordinary EPROM socket instead?
So that's exactly what I did!
First, I completely desoldered the PSOP44 subboard from the Go Retro! motherboard.
Luckily, the exposed PSOP44 solder pads were reasonably accessible, making this modification considerably easier than the tiny trace-scratching adventure we had recently experienced with the Class200.
Using individual wires, I connected the necessary address, data, and control signals to an external DIP42 socket.
This allowed me to use standard 27C322 EPROMs, each capable of holding 4 MB of data.
Of course, the original Go Retro! uses a much larger 32 MB ROM, so this raised an important question.
Would the console even start with just 4 MB?
There was only one way to find out!
The First Test – 4 MB Is Enough!
Before attempting any complicated Trojan code, I wanted to confirm that our hardware modification actually worked.
I took the original 32 MB ROM image, trimmed it down to its first 4 MB, and programmed it into a 27C322 EPROM.
Then I inserted the EPROM into our newly installed DIP42 socket and powered up the console.
And guess what?
It worked immediately!
The Go Retro! Portable started normally and displayed its original game-selection menu, complete with music!
This was fantastic news.
We had just confirmed two very important things.
First, our homemade EPROM adapter was working correctly.
And second, the initial 4 MB of the original ROM contained enough of the startup code and menu software to get the system running.
Naturally, a 4 MB EPROM couldn't replace the entire original 32 MB game collection, but that wasn't our goal anyway.
We only needed a working environment in which to launch our own code.
The door was open for another Trojan attack!
Our First Trojan – Not Quite There Yet!
With the hardware ready, we started examining the Go Retro! firmware and the existing MAME driver.
The interesting part was the way the console communicated with its mysterious 8-pin chip.
During startup, the original firmware sends a command to the chip and reads back a stream of data.
That data is copied into RAM, where the game software can access and execute parts of it.
We wanted to take advantage of this existing communication routine.
Rather than reverse-engineering the chip's electrical interface completely from scratch, we could reuse the console's own code to perform the read operation.
The plan was simple:
Start the console using our modified game ROM.
Execute a custom Trojan program.
Read the original 8-pin chip.
Display the recovered bytes on the screen.
Reconstruct the data into a binary ROM image.
Simple enough in theory!
Our first experimental ROM attempted to use the display as an optical data-transfer interface.
Instead of hexadecimal text, the initial idea involved rapidly changing screen colors to represent binary data.
Unfortunately, the first attempts didn't produce a usable dump.
We saw some visual activity, but not the reliable data transmission we were hoping for.
Clearly, something wasn't quite right.
And that's where the real reverse-engineering adventure began.
The Menu Appears... and Then Everything Goes Black!
Our next approach was more conservative.
Rather than trying to take over the console immediately during startup, we decided to let the original firmware initialize everything normally.
The original game menu would appear first.
Only after a short delay would our Trojan take control.
This approach had several advantages. The hardware would already be initialized, the screen would be working, and the original protection-chip communication would have completed successfully.
We inserted a small hook into the menu code, redirecting execution to our custom routine after approximately two seconds.
The result was encouraging!
The console booted normally.
The menu appeared.
The music played.
And after approximately two seconds...
The screen went completely black!
Well, that wasn't exactly what we wanted.
But it was still progress!
The timing strongly suggested that our code was being executed.
The problem now seemed to be related to our custom display routines rather than the console's ability to run the Trojan.
We had successfully reached the next stage.
Now we needed to make the screen cooperate.
Making the Screen Talk!
Instead of immediately attempting another full ROM dump, we switched to a series of smaller diagnostic tests.
First, we developed a ROM that simply switched the existing menu display on and off.
If the screen blinked at the expected intervals, we would know that our hook was executing and that we could manipulate the video hardware.
This worked!
Next, we experimented with different display colors.
The console eventually responded with the expected color changes, confirming that our custom code could control the visual output.
Our optical transmission idea was finally becoming practical.
The original concept used different colors to encode binary values, with a separate synchronization color helping the decoder identify the transitions.
Technically, this could have worked.
But there was one disadvantage.
Capturing hundreds of rapidly changing colors from the handheld's screen and reconstructing the exact data would have been rather cumbersome.
And after all the experience we had gained with our previous ROM-dumping adventures, we knew there was a much more convenient solution.
Why not simply display the ROM contents as hexadecimal text?
From Colored Screens to Pure HEX!
For the next major revision, we abandoned the color-based data transmission and developed a proper hexadecimal display routine.
This required some additional work.
The original game menu wasn't designed to display arbitrary memory contents as HEX values, so our Trojan needed its own small character set and text-output routines.
We created a custom hexadecimal font, allowing the handheld to display values from 00 to FF directly on its screen.
And this time, the results looked much more promising!
Our fifth major Trojan revision successfully displayed the protection-chip data as hexadecimal text.
The output was divided into numbered pages, each containing 16 bytes and an additional SUM16 checksum.
The system displayed the data page by page, giving us enough time to photograph the screen and record the contents.
But there was another important detail.
The original firmware didn't simply preserve the raw data exactly as it arrived from the 8-pin chip.
It also modified parts of the data in RAM during initialization.
For emulation and preservation purposes, we didn't want those modified bytes.
We wanted the original, untouched contents of the chip!
So our Trojan performed another read of the 8-pin device, using the original communication routine, and captured the newly received data before the firmware could apply its RAM modifications.
That distinction was essential.
We weren't just dumping a memory area that happened to contain some protection code.
We were recovering the actual raw data supplied by the physical chip!
The Final Trojan – 256 Bytes of Pure HEX!
Instead of relying on colored screens, we developed a proper hexadecimal display routine with a custom character set, allowing the console to show the actual contents of its mysterious 8-pin chip.
The Trojan reused the original chip communication routine to capture the raw data directly into RAM, without the modifications normally applied by the game's initialization code.
After several experiments and adjustments, we finally had a working solution!
The console booted into its familiar game menu, and after a short delay, our Trojan took over and started displaying the recovered data.
All 256 bytes were presented across 16 pages, each containing 16 hexadecimal values and a SUM16 checksum.
We photographed the screens, reconstructed the complete binary image, and independently verified every page against its displayed checksum.
All 16 pages passed!
And there it was: the complete original 256-byte protection data, recovered directly from the real Go Retro! Portable hardware!
Another mystery solved!
All of that work for just 256 bytes!
No comments:
Post a Comment