In order to extract these programs from most of the DSPs, we had to decap the chips, scan them in with an electron microscope, and 'tweak' the processors to allow us to dump their protected program ROMs.
As you can imagine, this kind of work costs a substantial amount of money. Professional firms that do this can charge upwards of $100,000 per processor for this kind of work.
Thankfully, Lord Nightmare from the MAME/MESS project was in contact with a savant named Dr. Decapitator, with the necessary knowledge and hardware to make this possible. Even better, he was willing to do it just for the cost of the donor cartridges and supplies. This worked out to $250 per coprocessor.
From the perspective of a software guy, this sounds very impressive. Can some hardware guy chime in and tell us just how impressive it is to recognize a CPU from looking at a binary dump?
Also for every ISA there are some instructions that are very common, for example x86 has very-recognizable NOPs (0x90).
Having said that, seeing it is ARMv3 code specifically in one glance is pretty impressive.
You seem to have added some hyperbole. There was no mention of "in one glance".
Also, it's likely that he recognized that it was ARMvSomething (which is relatively easy) and then did some comparisons to narrow it down.
Remember how Super Mario RPG was really expensive when it came out? Thats why. Quite a few other games used this chip, but it seems to be all Japan only except for Kirby Super Star and Kirby's Dream Land 3, neither of which were particularly exceptional games.
I am sure that's enough to cover the cost of an ARM6.
Yes I know lots of games now do as well, but lots of the most popular ones don't.
I'm not sure if the single player play time has really gone up or down to get through the main story, but modern games seem to incorporate almost endless numbers of side quests, self generating quests, achievement junky-only quests (kill 10,000 of X) and also a lot of multiplayer functionality.
For what it's worth, this is almost identical to the process initially used to hack satellite TV smartcards, except it seems that these devices had a lot less physical tamper protection (and can't be reprogrammed with a new ROM over-the-air).
I think this kind of console hack is a dying art - as process shrinks and most consoles move closer and closer to commodity hardware and off-the-shelf software, LLE and chip decapping become less and less appealing and software exploits are the name of the game.
Absolutely awesome, though - this is the kind of story I come to HN to read.
I however think it is a prime example of great teamwork rather than open source.
Open source is a mean, not an end. We tend to forget that.
Open Source is both a means and an end. It can be a means to collaboration, but the ongoing sharing of knowledge is itself a virtue.
I prefer to read a book about why and how a software is made than to read the source code.
However, unlike source code, documentation cannot be machine tested for correctness.
Honestly, they're both important, and for different reasons. In this instance, Cydrak and I were able to pass revisions of the ARM core back and forth to fully debug it.
It's also true that code being open source doesn't mean the code is useful, but a book being published doesn't mean the material is presented well, either.
Maybe it's just my pro-open source bias, but it feels like you've got an axe to grind against open source. If so, would you mind sharing why (maybe you know something I don't)?
What I don't like is that people overstate the importance of open source and think it's the solution to everything.
Open source is great for some projects, useless and even counterproductive for others.
I'm sure you weren't implying me in particular, but to clarify, I certainly don't think open source is the solution to everything.
I just find it particularly important in the field of emulation. This is much like a science, with constant refinements to theories. Since we're running against the clock to preserve these systems before they die, I assign much more value to open source emulators than I do to other applications (for instance, I'm happy to use the closed source nVidia driver on Linux.)
From Dr Decapitator's page:
"The data was extracted by laser-cutting the top two ROM bits from the actual CPU logic (so it would read all opcodes as OP(00) or LD(11) opcodes depending on whether lines were pulled high or low, and neither OP nor LD can branch address), then microprobing, 8 bits at a time, the ROM outputs from before the cut. The program counter was also monitored to ensure that the data read started at 0×000 and didn’t jump anywhere."
You can read more about chip decapping here: http://guru.mameworld.info/decap/index.html And here: http://www.defcon.org/images/defcon-12/dc-12-presentations/G...
Yes, basically we bypassed the JP (jump) and RT (return) opcodes, so that the program counter always stepped by one. Externally clock the CPU to move to the next instruction, and keep logging the data lines prior to the OP/LD cuts.