Working under the pressure of being watched on a live feed, [DeadlyFoez] pits himself against the so-called unhackable Wii Mini and shows unprecedented results all while recording hours of footage of his process for others to follow along. We dug through that content to find the gems of the process, the links below include timestamps to those moments.
The Wii Mini is a cost-reduced version of Nintendo’s best-selling console, sold near the end of its life with a few features removed such as GameCube backwards compatibility and SD card support. Along with that, in an effort to thwart the jailbreaking that had plagued its big sister Nintendo made it so the NAND memory (where the system is stored) is encrypted and keyed to each device’s Hollywood GPU chip. This defeats methods which modified the storage in order to gain access to the hardware.
That did not stop [DeadlyFoez] from trying anyway, planning out the steps he needed to achieve a hacked Mini unit with the help of a regular Wii donor, already hacked. After dumping both systems’ NANDs and exploring the Wii Mini hardware further, he found a few pleasant surprises. There are test points on the board which allow GameCube controllers to be used with it. There are also SD card connections physically present on the board, but the support was removed from the Mini’s system software.
The most interesting parts come later on however: by simultaneously swapping NAND and GPU chips between original Wii and Wii Mini, [DeadlyFoez] manages to put together two distinct systems. The first is an original Wii board with the Mini’s chips claimed to be “the first Wii Mini running homebrew software”. The second, filling the opposite side of the equation, with both hardware and software to add SD card and GameCube controller ports to a Wii Mini.
This process of BGA rework in order to mod Nintendo hardware into unorthodox versions of themselves has actually been done before a few years ago, when someone made an unofficial US region non-XL new 3DS by piecing together parts from two separate consoles. Continue reading “Defeating The Wii Mini As The Internet Watches Over Your Shoulder”
You may still have some luck getting those selfies off of your SD card, even if it will no longer mount on your computer. [HDD Recovery Services] shows us a process to directly access the NAND memory of a faulty micro SD card to recover those precious files you thought about backing up but never got around to.
On a Micro SD card you may have noticed there are two slightly longer pins than the rest. These are VSS and VCC pins. As long as they are not a dead short between the two the SD card controller isn’t completely trashed and we can go ahead and get into that little sucker. With a bit of know how — along with sandpaper, enameled wire, and a NAND reader — an image of your lost data can be recovered with a bit of patience and some good soldering skills.
Working your way down from a relatively high grit sand paper, slowly sand away the plastic on the underside of the SD card until you can clearly see the copper traces hidden away inside. Then solder your enameled wire onto the small solder pads to hook it up to a NAND reader and you should be able to read the data that was previously unreachable via conventional means. Of course you’re still going to need to make sense out of the NAND dump. That’s a topic for a different article.
If you ever find yourself in need of an SD card recovery tool you could always roll your own DIY NAND reader. We will likely give this process a try just to play round with the concept. Hopefully we’ll never need to do SD card recovery!
Continue reading “Recover Your Broken SD Card Selfies By Your Selfie”
[James Tate] is starting up a project to make a “Super Reverse-Engineering Tool”. First on his list? A simple NAND flash reader, for exactly the same reason that Willie Sutton robbed banks: because that’s where the binaries are.
As it stands, [James]’s first version of this tool is probably not what you want to use if you’re dumping a lot of NAND flash modules. His Arduino code reads the NAND using the notoriously slow
digital_write() commands and then dumps it over the serial port at 115,200 baud. We’re not sure which is the binding constraint, but neither of these methods are built for speed.
Instead, the code is built for hackability. It’s pretty modular, and if you’ve got a NAND flash that needs other low-level bit twiddling to give up its data, you should be able to get something up and working quickly, start it running, and then go have a coffee for a few days. When you come back, the data will be dumped and you will have only invested a few minutes of human time in the project.
With TSOP breakout boards selling for cheap, all that prevents you from reading out the sweet memory contents of a random device is a few bucks and some patience. If you haven’t ever done so, pull something out of your junk bin and give it a shot! If you’re feeling DIY, or need to read a flash in place, check out this crazy solder-on hack. Or if you can spring for an FTDI FT2233H breakout board, you can read a NAND flash fast using essentially the same techniques as those presented here.
An SD card is surely not an enterprise grade storage solution, but single board computers also aren’t just toys anymore. You find them in applications far beyond the educational purpose they have emerged from, and the line between non-critical and critical applications keeps getting blurred.
Laundry notification hacks and arcade machines fail without causing harm. But how about electronic access control, or an automatic pet feeder? Would you rely on the data integrity of a plain micro SD card stuffed into a single board computer to keep your pet fed when you’re on vacation and you back in afterward? After all, SD card corruption is a well-discussed topic in the Raspberry Pi community. What can we do to keep our favorite single board computers from failing at random, and is there a better solution to the problem of storage than a stack of SD cards?
Continue reading “Single Board Revolution: Preventing Flash Memory Corruption”
Put your hand under you chin as here comes a 6 months long jaw-dropping reverse engineering work: getting the data back from a (not so) broken SD card. As you can guess from the picture above, [Joshua]’s first step was to desolder the card’s Flash chip as the tear-down revealed that only the integrated SD-to-NAND Flash controller was damaged. The flash was then soldered on a breadboard so it could be connected to a Digilent Nexys-2 FPGA board. [Joshua] managed to find a similar Flash datasheet, checked that his wire-made bus was reliable and generated two 12GiB dump files on his computer.
In order to extract meaningful data from the dumps he first had to understand how SD-to-NAND controllers work. In his great write-up he provides us with a background of the Flash technology, so our readers can better understand the challenges we face with today’s chips. As flash memories integrate more storage space while keeping the same size, they become less reliable and have nifty problems that should be taken care of. Controllers therefore have to perform data whitening (so neighboring blocks of data don’t have similar content), spread data writes uniformly around the flash (so physical blocks have the same life expectancy) and finally support error correcting codes (so damaged bits can still be recovered). We’ll let our users imagine how complex reverse engineering the implementation of such techniques is when you don’t know anything about the controller. [Joshua] therefore had to do a lot of research, perform a lot of statistical analysis on the data he extracted and when nothing else was possible, use bruteforce…
No, that’s not a Playstation Vita up there, it’s a “Yinlips YDPG18A” portable game system. [Ian] found that his Yinlips was lacking in the flash memory department, so he fired up his soldering iron. The Yinlips is based on an Allwinner Sunxi series processor, and uses a standard TSOP48 footprint flash. There is some standardization in flash pin out and packages, so [Ian] picked up the largest pin compatible chips he could find – a pair of 256 gigabit (32 gigabyte) chips from Micron. Desoldering the existing flash proved to be a bit of an adventure as the flash was glued down. [Ian] also didn’t have his hot air gun handy, making things even more interesting. Careful work with a razor blade broke the glue bond.
It turns out that the soldering was the easy part. All flash chips have geometry, die count, page size, block count, sector size, etc. The geometry is similar to the geometry in a hard drive. In fact, just like in modern hard drives, a system will read some basic information before accessing the full storage array. In the case of NAND flash, the processor can access the first page of memory, and query the flash for its part number. Once the part number is known, the geometry can be determined via a lookup table. [Ian] checked the NAND table on github, so he knew going in that his flash chips were not supported. Due to the complexities of booting Allwinner processors into Linux or Android, the table and the NAND driver that uses it exist in several places. The bootloader’s axf file, U-Boot, and several flash application binaries sent from the PC based LiveSuit flash app all required modification. Most of these files were packed into a single flash image. [Ian] used imgrepacker to unpack the image, then opened the hex files. The fact that he knew what the original flash parameter tables looked like was key. He searched for an existing Micron flash table entry, and replaced the parameters with those of his new chips.
With all the files modified, [Ian] re-packed his flash image and sent it over. The Yinlips rewarded his hard work by continually resetting in a bootloop. [Ian] wasn’t going to give up though. He wired into the boot console, and discovered that a CRC check failure on one of his modified files was causing the reset. He then disassembled binary issuing the reset. Changing the return value of the CRC to always pass fixed the issue. [Ian’s] now has a collagen infused Yinlips with 58GB of internal storage. Pretty good for a device that only started with 2GB.
[HC] took a gander around the Googles and saw a number of people trying to read NAND flash chips with an Arduino. It’s an interesting problem; at 16 Megahertz, [HC] is looking at about 60 nanoseconds per instruction cycle, and flash chips normally operate around 20 ns. He got the build working, and was able to read the memory contents and ID of a flash chip.
Right now, it’s just a proof-of-concept to demonstrate that reading flash memory is possible. [HC] used an Arduino Mega to pull the manufacture ID off a flash chip. Because there isn’t exactly a whole lot of storage on an Arduino to hold Megabytes of data, so [HC] is looking for a way to pull data off his flash chip. He’s considering sending it over Ethernet or storing it on an SD card.
This isn’t the first time we’ve seen a roundabout way to use those cheap, ubiquitous NAND flash chips. Considering we’ve got a few dozen of them housed in unused thumb drives, [HC]’s work shows a lot of potential. He posted a topic on his forum to see if there’s any interest in further developments, something we’d like to see.