Vulnerabilities are like good ideas - you’re rarely the first one dealing with it. Some vulnerabilities are almost classic, so I’ll proudly present: 7 old but surprisingly useful bugs that might also affect YOUR device.
In this series of articles, I will talk about the design, implementation and fall of an optical media authentication used on a popular, but past, gaming console. I will show that it’s possible to reverse engineer such stuff without access to expensive equipment or insider information.While I will not talk about practical implementation of attacks against the discussed scheme, I will show that this has been done, and I will analyze how this has been done. More after the break.
Step 1: $40k overpriced LA (could be replaced easily with a $150 FPGA board), some wires
Step 2: 20 lines of python code
Difference between those? Just some simple XOR and ADD.
The WhatsInside post from January was not an incidental post. It is actually snapshot of a much longer forensic investigation to find the ground truth behind some of the technology behind Tektronix’ scope accessories.
EDIT: This post was - seriously - posted before I’ve read “<Ch0p> the owner of datel electronics just made a $1000 donation to wiibrew”. However, I still believe my objections are valid. Anyway, Datel, thank you (a LOT) for supporting wiibrew.
Thank you, Datel, for all your precious hacker tools. You call them “videogame enhancement products”, which is probably as what most people see them, but I call them “hacker tools”, and that’s a compliment. You managed what few other people managed - you cloned optical media copy protections, produced innovative hard- and software, for a usually very fair amount of money. Your development guys are smart, sometimes maybe even too smart, and even while none of your tools are directly related to piracy, the big companies are less than amused by your products (which, again, is a compliment).
As a short summary, the new type triforce is probably a cost reduction of the old hardware. As part of this cost reduction, handling of the GDROM and security PIC, which was previously implemented in an SH-4 CPU, was “removed”. The network stuff was now handled separately on a MIPS cpu, but several strings that are proven to exist do not exist anymore in the flash rom, at least not as plaintext.
After bushing had shown the first homebrew exploit, a lot of stuff has happened in the Wii-world. The exploit was based on a hole in the disc hashing&verification, but the original finder (segher) decided that he doesn’t want the bug to be published. While this caused some controversy, the reason behind this was that the hole could be patched very easily in a future firmware version, as no original function relies on it. The next goal was to find a bug which could not be patched so easily, for example a savegame exploit. Patching such game exploits is considerable harder. Of course you could patch the game code when it is loaded (like some gamecube games are fixed in compatibility mode by the “gamecube compatibility IPL”), but we could just move on to another game. We wouldn’t lose that much power if a game bug is fixed, vs. a critical system bug. I can totally understand that people are annoyed by us not doing full disclosure. Nevertheless we try our best to balance our different interests. It’s not always easy, even inside a team. Still, the rule is: If you find a bug, it’s your choice what you do with it. If you don’t like that, find your own bug.
I’ve concentrated less on the high-level things, I’m generally more interested in the system design and security architecture. So I’ve digged into the bootloader.
What we knew before was that there is a fixed block of code called “boot1”, which is supposed to be the first code executed from flash. It’s ARM (“Starlet”) code, btw, the powerpc (Broadway) is booted much later. We didn’t knew how boot1 is encrypted (rumours ranged from an LFSR-based streamcipher to AES), nor if and how it was hashed. But what we had was a program called “BC” (title id: 1-100), extracted out of a system update. We are absolutely not sure why BC does even exist (it might be used to return from GC mode to Wii mode, but why would you want to do so?), but what BC is doing matches what boot1 could be doing: Reading a bunch of sectors from flash, decrypting them, and checking a signature against a previously decoded cert chain, then jumping there. Once we re-coded the algorithm, it was clear that this in fact decrypts boot2. Encrypting a new boot2 requires signing the new hash. Now it turned out that “BC” also contains “the bug” (well, a similar one), so chances were big that boot1 also does. But flashing a new boot2 is dangerous if you have no return - there is a backup mechanism to boot another copy of boot2, but we cannot count on that for several reasons (for example, if our new boot2 code hangs, the backup would not be tried, as boot1 thinks that everything is right).
It also became clear that once we are able to execute starlet code, it will be a lot of trial&error. So what I did was to revive my old FPGA-based NAND flash emulator, which I once built for the Xbox 360. I wired the Wii’s flash pins to the FPGA. Now the Wii flash has different properties (large block, larger size, different ECC algorithm used), but I could adapt it in a matter of hours. I had to fix the RESET handling (the Wii is waiting for R/#B to go low for a short moment of time), and some minor things, but then it worked! I could boot from my FPGA instead of the original Flashrom. So I could do code changes in a matter of seconds, instead of always reprogramming the flashrom (potentially external). Because my FPGA board has “only” 512MB of RAM, I couldn’t fit the whole flash contents into the RAM. As part of the NAND emulation happens on the embedded PowerPC core in the FPGA (a Virtex 2 Pro), I just added an ethernet MAC, and used lwip to fetch the flash pages from a TCP server. That made the development cycle even easier, as I could now just modify the virtual NAND content on my PC!