Slashdot Mirror
Game Boy Zelda Comes With Source, Sort Of
Jamie found a fun story about a 90s Zelda Game Boy ROM that shipped with the source code- not so much on purpose, but more because the linker padded out the last meg of ROM with random memory contents, which happened to include game source code.
I guess the only way to really avoid the malloc() calls grabbing your source code would have been to compile, then reboot to link...so the extra data thats padded on the end of the ROM image would just be your emtpy RAM contents.
Obligatory blog plug: http://www.caseybanner.ca/
Air Fortress (Famicom version) also included a portion of the source code due to not clearing memory before linking.
Now the site is Wordpressed (like Slashdotting, only the other way around) and you can't get to it, but one of the last posts before it died pointed out that this was from a trainered version. That's where someone adds cheat code to a ROM. As it turns out, the original doesn't have any of the code in question. Dissassembling for the purpose of adding cheats is a completely sensible explanation of the code that was found.
The moral of the story? Start with a known clean dump (look for the "[!]" tag) before assuming that the introns were in the original game.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
This is a non-story. This only applies to a specific Pirate ROM Dump of Zelda DX. The clean dump does not contain any embedded source code.
"What do they mean by clear the memory? Because when I malloc() (and not calloc()) I seem to get whatever was there before.."
But you don't get anything from another process. When malloc() runs out of memory and asks for a new chunk from the operating system, a modern system will usually zero the block that it returns, whereas some older operating systems (e.g. MS-DOS, I think?) would just give a pointer to a chunk of free memory which could still contain any data that the previous user had left in it; that could be any program which had previously run on the machine.
When you free something and call malloc() again afterwards, you may well get a block with old data from your program. But in most cases you won't get a block with old data from a different program.
The same applies to disk files; with some operating systems in the past you could open a file, write a byte a megabyte into the file and then read a megabyte of old data preceding it in free blocks which had been allocated to you and not cleared. That was obviously a big potential security hole, so most modern operating systems will zero all the data in the file instead (more precisely, they'll probably allocate a sparse file which will return zeros from areas which haven't been written to).
The BBC model B didn't have CMOS ram. The operating system ROM did have a chunk of text in the memory-mapped IO area. It read:
The BASIC ROM didn't have room for any extra text; the only cruft in the whole 16K is the name "Roger" in the last five bytes. The optional disk filing system ROM doesn't have any extra text either (I just checked).
I don't know what you saw, but it wasn't a standard part of the BBC micro.