[Matthew’s] recent blog post does a good job explaining the basics of the Raspberry Pi’s file system. The Linux operating system installed on a Pi is generally installed on two different partitions on an SD card. The first partition is a small FAT partition. All of the files on this partition are used for the initial booting of the Pi. This partition also includes the kernel images. The second partition is the root file system and is generally formatted as ext4. This partition contains the rest of the operating system, user files, installed programs, etc.
With that in mind you can deduce that in order to backup your Pi, all you really need to do is backup all of these files. [Matt] has written some scripts to make this a piece of cake (or pie). The first script will simply copy all of the files into a gzipped archive. You can save this to an external SD card, USB drive, or network share.
The second script is perhaps more interesting. This script requires that you have one free USB port and a USB SD card reader. The script will automatically format the extra SD card to contain the two critical partitions. It will then copy the “boot” files to the new boot partition and the root file system files to the new SD card’s root partition. When all is said and done, you will end up with an SD card that is an exact copy of your current running file system.
This can be very handy if you have multiple Pi’s that you want to run the same software, such as in a Pi cluster. Another good example is if you have spent a lot of time tweaking your Pi installation and you want to make a copy for a friend. Of course there are many ways to skin this cat, but it’s always fun to see something custom-built by a creative hacker.
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…
For nearly every problem, it’s possible to engineer a solution, even if you’re dealing with an extraordinarily niche problem that might only apply to yourself. [Joel] wanted to be able to program the microSD card in his BeagleBone with a new bootloader or file system without removing the SD card from the target board. This is a peculiar requirement, and it’s highly doubtful a product or even a circuit exists for such a function. This meant [Joel] would need to roll his own board to accomplish the task.
The board is remarkably simple, housing a single microSD socket, two expansion headers for a microSD sniffer for a computer and an embedded board, an FTDI header, and a pair of 4-bit multiplexer/demultiplexers. The operation of the device is fairly straightforward: send a signal down the FTDI cable, and the board switches the onboard SD card from one device to another.
[Joel] has a video of his screen that shows him pulling off in-circuit SD card reading and writing. You can check that out below.
Continue reading “The In-Circuit SD Card Switch”
After a request from one of his friends, [Mastro Gippo] managed to put together a talking multimeter to be used by blind persons working in electronics. He wanted a feature-rich meter that had serial output, and recalling this Hackaday article from a few years back led him to find a DT-4000ZC on eBay, which has serial output on a 3.5mm jack. (Though, he actually recommends this knockoff version which comes with excellent documentation).
It turns out there aren’t many talking meter options available other than this expensive one and a couple of discontinued alternatives. [Mastro Gippo] needed to start from scratch with the voice synthesizer, which proved to be as easy as recording a bunch of numbers and packing them onto an SD card to be read by an Arduino running the SimpleSDAudio library.
He found a small, battery-powered external speaker used for rocking out with music on cell phones and hooked it up to the build, stuffing all the electronics into an aluminum case. Stick around after the jump for a quick video of the finished product!
Continue reading “Say Watt? A Talking Multimeter?”
In case you weren’t aware, that little ‘write protect’ switch on your SD cards probably doesn’t do anything. It’s only a switch, really, and if an SD card reader doesn’t bother to send that signal to your computer, it’s completely ineffective. Then there’s the question of your OS actually doing something with that write protect signal.
The better way to go about write protecting an SD card is using the TMP_WRITE_PROTECT bit on the SD card’s controller. [Nephiel] came up with an amazingly small device to set that bit, with the entire circuit fitting inside an old Playstation memory card.
[Nephiel] based his project on [Karl Lunt]’s SD Card Locker we saw late last year. [Karl]’s SD Locker uses an ATMega328 microcontroller, a pair of AA batteries, and an SD card socket to perform the bit toggling. This is still a very small device that fits inside an Altoids tin, but [Nephiel] thought he could make it smaller.
The new and improved version uses an ATTiny85 for SPI access to the SD card. A single button and LED serves as the user interface: with the LED off, the SD card is writable. Press the button, the card is locked, and the LED lights up.
We hope that some of our readers are currently at this year’s Chaos Communication Congress (schedule can be found here and live streams here), as many interesting talks are happening. One of them addressed hacking the memory controllers embedded in all memory cards that you may have. As memory storage density increases, it’s more likely that some sectors inside the embedded flash are defective. Therefore, all manufacturers add a small microcontroller to their cards (along with extra memory) to invisibly ‘replace’ the defective sectors to the operating system.
[Bunnie] and [xobs] went around buying many different microSD cards in order to find a hackable one. In their talk at 30C3 (slides here), they reported their findings on a particular microcontroller brand, Appotech, and its AX211/AX215. By reverse engineering the firmware code they found online, they discovered a simple “knock” sequence transmitted over manufacturer-reserved commands that dropped the controller into a firmware loading mode. From there, they were able to reverse engineer most of the 8051 microcontroller function-specific registers, allowing them to develop novel applications for it. Some of the initial work was done using a FPGA/i.MX6-based platform that the team developed named Novena, which we hope may be available for purchase some day. It was, among others, used to simulate the FLASH memory chip that the team had previously removed. A video of the talk is embedded below.
Continue reading “Hacking SD Card & Flash Memory Controllers”
Over the last few months, a few very capable hackers have had a hand in cracking open a Transcend WiFi-enable SD card that just happens to be running a small Linux system inside. The possibilities for a wireless Linux device you can lose in your pocket are immense, but so far no one has gotten any IO enabled on this neat piece of hardware. [CNLohr] just did us all a favor with his motherboard for these Transcend WiFi SD cards, allowing the small Linux systems to communicate with I2C devices.
This build is based upon [Dmitry]’s custom kernel for the Transcend WiFiSD card. [CNLohr] did some poking around with this system and found he could use an AVR to speak to the card in its custom 4-bit protocol.
The ‘motherboard’ consists of some sort of ATMega, an AVR programming header, a power supply, and a breakout for the I2C bus. [Lohr] wired up a LED array to the I2C bus and used it to display some configuration settings for the WiFi card before connecting to the card over WiFi and issuing commands directly to the Linux system on the card. The end result was, obviously, a bunch of blinking LEDs.
While this is by far the most complex and overwrought way to blink a LED we’ve ever seen, this is a great proof of concept that makes the Transcend cards extremely interesting for a variety of hardware projects. If you want your own Transcend motherboard, [CNLohr] put all the files up for anyone who wants to etch their own board.