HackMii

Recently I was informed that Datel has released a new version of their Action Replay Cheat Cartridge that allows you to cheat in DS games on a DSi console. Knowing that Nintendo put quite some effort in blocking any third party cartridges from working on the DSi I was curious to figure out how they did it.

Before jumping in this article, I’ll give you a small warning that what is written here might be quite “techy” to some people, I advise reading lots of GBAtek (And maybe a bit of dsibrew) when you get lost.

[Read more →]

Wow, time does fly. More than a year ago, on October 23rd, 2008, Nintendo finally released an update that fixed the strncmp (fakesigning) exploit in all forks of IOS. This disabled any direct methods to install unofficial content on all updated Wii consoles. At the time, version beta9 of The Homebrew Channel had been in the making for a while, so we decided to take the opportunity to use one of our stockpiled IOS exploits to work around the update and release beta9. These exploits differ from fakesigning in that they directly exploit the IOS runtime, injecting code that lets us take control and disable signatures altogether. Therefore, this was our first released IOS code execution exploit. HBC beta9 was released and worked great on all Wiis, as always.

In order to hinder Nintendo’s attempts at fixing it, and to avoid misuse by warez kiddies, sven and I had a lot of fun obfuscating the exploit over a couple afternoons. We decided not to release information about it, hoping it would last long enough to be useful for future installers and BootMii. Later we kind of forgot about this, but on a few occassions people have asked us to document it, and we proposed a challenge: we would document the exploit as soon as someone “broke” our obfuscation and figured out how the exploit works. The intent was to promote reverse engineering and also see just how long it would take people to crack it. Apparently, either people weren’t very interested or we did a pretty good obfuscation job, because it took pretty long

Well, I’m happy to say that today I received an e-mail from an anonymous hacker who successfully reverse engineered our layers of obfuscation. He (or she!) discovered the inner workings of the STM Release Exploit, as I will be calling it, and did so after three weekends of reverse engineering. Hats off to you, and thank you for taking the challenge!
[Read more →]

I have been spending some time on reverse engineering the Nintendo CIC ROMs. The CIC is the “lockout” chip in NES/SNES/N64 cartridges, used to get an iron grip on the market prevent people from copying games. It was manufactured by Sharp and is likely one of their old “one-chip microcomputers”, used in calculators and TV remotes and the like. I couldn’t find a document describing the instruction set it uses (or its architecture!), so I made it all up (combining information from lots of sources: old datasheets, old patents, and the low-res die photographs).

The N64 chips are different, and I haven’t seen a ROM dump of those yet, so all of the following is NES/SNES only.

There is one chip inside the console, and one in every cartridge; the code inside the chip decides what to do based on a pin strap (the console one will be the “lock”, and the cartridge one will be the “key”). The two chips run off the same clock, and they run the same code, so they run in lockstep (sometimes they execute different codepaths, but the code is careful to take the same number of cycles on both paths in these cases). The chips communicate over two wires, one from key to lock, one from lock to key. Both chips calculate what bits they will send, and what the other guy should send; if what they receive is not the same as what they should have received, they panic, and the lock chip resets the console.
[Read more →]