Modder Recreates Game Boy Advance Games Using the Audio From Crash Sounds (arstechnica.com) 15
Kevin Purdy reports via Ars Technica: Sometimes, a great song can come from great pain. The Game Boy Advance (GBA), its software having crashed nearly two hours ago, will, for example, play a tune based on the game inside it. And if you listen closely enough -- using specialty hardware and code -- you can tell exactly what game it was singing about. And then theoretically play that same game. This was discovered recently by TheZZAZZGlitch, whose job is to "sadistically glitch and hack the crap out of Pokemon games. It's "hardly a ready-to-use solution," the modder notes, as it requires a lot of tuning specific to different source formats. So while there are certainly easier ways to get GBA data from a cartridge, none make you feel quite so much like an audio datamancer.
After crashing a GBA and recording it over four hours, the modder saw some telltale waveforms in a sound file at about the 1-hour, 50-minute mark. Later in the sound-out, you can hear the actual instrument sounds and audio samples the game contains, played in sequence. Otherwise, it's 8-bit data at 13,100 Hz, and at times, it sounds absolutely deranged. "2 days of bugfixing later," the modder had a Python script ready that could read the audio from a clean recording of the GBA's crash dump. Did it work? Not without more troubleshooting. One issue with audio-casting ROM data is that there are large sections of 0-byte data in the ROM, which are hard to parse as mute sounds. After running another script that realigned sections based on their location in the original ROM, the modder's ROM was 99.76 percent accurate but "still didn't boot tho." TheZZAZZGlitch later disclaimed that, yes, this is technically using known ROM data to surface unknown data, or "cheating," but there are assumptions and guesses one could make if you were truly doing this blind.
The next fix was to refine the sound recording. By recording three times and merging them with a "majority vote" algorithm, their accuracy notched up to 99.979 percent. That output ROM booted -- but with glitched text and a title screen crash. After seven different recordings are meshed and filtered for blank spaces, they achieve 100 percent parity. You can watch the video describing this feat here. Used source code is also available under the file name "gbacrashsound_dumper.zip."
After crashing a GBA and recording it over four hours, the modder saw some telltale waveforms in a sound file at about the 1-hour, 50-minute mark. Later in the sound-out, you can hear the actual instrument sounds and audio samples the game contains, played in sequence. Otherwise, it's 8-bit data at 13,100 Hz, and at times, it sounds absolutely deranged. "2 days of bugfixing later," the modder had a Python script ready that could read the audio from a clean recording of the GBA's crash dump. Did it work? Not without more troubleshooting. One issue with audio-casting ROM data is that there are large sections of 0-byte data in the ROM, which are hard to parse as mute sounds. After running another script that realigned sections based on their location in the original ROM, the modder's ROM was 99.76 percent accurate but "still didn't boot tho." TheZZAZZGlitch later disclaimed that, yes, this is technically using known ROM data to surface unknown data, or "cheating," but there are assumptions and guesses one could make if you were truly doing this blind.
The next fix was to refine the sound recording. By recording three times and merging them with a "majority vote" algorithm, their accuracy notched up to 99.979 percent. That output ROM booted -- but with glitched text and a title screen crash. After seven different recordings are meshed and filtered for blank spaces, they achieve 100 percent parity. You can watch the video describing this feat here. Used source code is also available under the file name "gbacrashsound_dumper.zip."
Blast Arena Advance (Score:3)
If you have the Blast Arena Advance GBA homebrew cartridge from 20 years ago, the highscore table cheat 'scramble' (which was used for resetting the cart to factory settings before it was posted) causes this audio output to happen as well.
Re: (Score:3)
This kind of attack offers hope for other systems where there is no way to read out certain data.
For example, I have some Cassette Vision games. The Cassette Vision was an early video game console that was unusual in that the base unit only contained the controllers and a video chip. No CPU, or RAM.
The CPU and RAM were contained in the cartridges. On the one hand, that made them more expensive, but on the other it allowed the manufacturer to simply repackage a lot of its existing "TV game" systems, which us
Re: (Score:2)
Several years ago something like this was used for dumping iPod firmware [ipodlinux.org] as part of the iPod Linux project. It was even covered on Slashdot [slashdot.org] at the time. Still a pretty neat hack for getting the firmware out of it.
Re: (Score:2)
Yeah, if only I could get one of the games to copy some program data to the screen RAM or something.
On a bit of a tangent, I built a little prototype that used a microphone to listen for beeps generated by Javascript. The idea being you could use a web page to program an embedded device, like say setting the alarms and timezone on a clock. I abandoned it because the mic side needed enough electronics that you might as well use some simpler system, but now you can get MEMS microphones with digital output I w
RAM scanning (Score:5, Interesting)
Heh... I thought only the Amiga had audio DMA that would freewheel and play the whole contents of memory, though I guess it's possible for a software mixing system to do the same thing. I have no experience with the GBA hardware. The Amiga was even more fun to play with, because if the copper list got corrupted and didn't reset the bitplane pointers, the entire contents of video RAM would scroll up the screen. Theoretically, under specific conditions, you could do a video capture of a crashed Amiga and grab game data that way. Even the raw floppy disk buffers (pre MFM decoding) will show up on the screen.
I did a lot of "RAM scanning" back in the 90's and can identify many data structures based on how they look on the screen and how they sound played through the speakers. Good times.
Re: (Score:2)
On the ATARI ST it was even simpler.
You used the xbios(2) command in GFA Basic to modify the start address of the displayed screen.
You could then use that to view the entirety of your RAM, including pictures from the game you just played, and realize with your own eyes that everything you see on screen is just memory.
Yes, I knew that from long before,by using POKE on ATARI 800XL, but sliding the window on memory that the screen is was a much more impactful effect on understanding.
Re: (Score:2)
30 years ago I wrote my own RAM scanner in AMOS Basic that did much the same thing. To look at fast RAM, it's necessary to do a memory copy into chip RAM first, and that allowed me to observe the floating bus behavior with respect to different alignment and CPU cache settings. It's fun to see how floating behavior changes on what kind of wait states and bus widths the glue logic dictates. I used these findings to submit some patches to WinUAE to help improve the memory bus and system timer emulation.
why? (Score:2)
Why does the GPA play the contents of the game as a audio? Is that a feature fof the GPA and just co-incidence on purpose. If on purpose, why?
Re: (Score:3)
It has DMA PCM playback. If you crash it while sound is playing, it just loops over the entire address space, and most Game Boy cartridges have their entire ROM contents directly mapped into the the address space, so it plays out the contents of the ROM as well as whatever it reads from RAM, etc.
Obscure cybersecurity applications? (Score:2)
Maybe a technique like this could be used for overcoming very specific "air gap" scenarios, like in some James Bond movie.
Re: (Score:1)
Re: (Score:1)