Hacker News Reader

Comment by jboy55 | Hacker News Reader

Would this be dependent on the audio file that was being played during the crash to start at address 0 of the ROM? It seems like it'd be highly unlikely you'd be able to get 100% of the ROM.

Now if this was a hack where the thought was, "What if we dumped the whole ROM to the audio buffer, could we recover the complete ROM through audio analysis?"

View on HN

The ROM on the GBA is mapped into memory at high memory addresses (0x08000000 and above). The audio "working" buffer is in low memory (I think somewhere near 0x02000000?). An interrupt fires when the audio chip reads to the end of the working buffer that looks something like this:

- run the function to fetch the next batch of audio to audio working RAM

- reset the audio read pointer to the beginning of audio working RAM

When interrupts are disabled (because the game has crashed), that "reset pointer" code never runs and the audio circuit keeps reading way past the end of its buffer, incrementing forever. Eventually it would increment into the 0x08000000 range in which case the sounds it's emitting map directly to the bits in the ROM.

GBA Memory Map:

  02000000-0203FFFF   EWRAM (256 KBytes)
  03000000-03007FFF   IWRAM (32 KBytes)
  06000000-06017FFF   VRAM - Video RAM (96 KBytes)
  08000000-09FFFFFF   Game Cartridge ROM (max 32MB)

The audio buffer will usually live in EWRAM, then you have to wait until about 100,000,000 audio samples have played before it proceeds from EWRAM to Game Cartridge ROM.

I think hardware starts from 0 after reaching 0xfff..ffff address. The article mentions that you need to wait before starting to record, I assume it is a pause needed for hardware to overflow address.

That video seems to imply that the audio hardware automatically wraps back to address 0 when it reaches the end of RAM. That may not be true, but it's implied by the animation in that video. And since they were apparently able to dump the entire ROM via audio, I suppose there's some way to get the entire memory contents.

the sounds aren’t read directly from the rom - the buffer is in a fixed place in ram, and sounds from the rom get copied into there

remember that it’s not like the music is just there as raw audio, the raw audio is just the sounds of the different instruments

That makes more sense, I thought they would just be pointers to ROM addresses for the samples.

No, they're read directly from the ROM.

Here's what's going on:

- reading from ROM is slow, relative to working RAM; the ROM is mapped to the same memory address space as the RAM, but reading a ROM address takes (I think 8?) clock ticks.

- so to do audio playback, the GBA "stripes" a chunk of data into RAM, sets a pointer to the beginning of that stripe, and then lets the audio chip pull data and update that pointer. When the pointer reaches the end of the stripe, an interrupt triggers that is supposed to pull in the next chunk of audio into the stripe (overwriting the current stripe contents) and reset the pointer.

... but if interrupts are disabled, then that doesn't happen, and the simpler logic in the audio chip just keeps incrementing the pointer forever and reading more data. It'll eventually get to the ROM addresses and pull directly from those (it's slow, but fast enough that it doesn't starve the chip; you just wouldn't run your audio this way in the game normally because you'd have 1/8th the amount of time to do everything else every frame of animation if the audio system were reading directly from ROM all the time. Also, reading from RAM lets you edit the samples to do audio effects).

Reply on news.ycombinator.com