Keep Your SD Cards Data Safe With The SD Locker

November 12, 2013 by Adam Fabio 41 Comments

sdlocker_1

[Karl Lunt] has come up with a simple circuit for protecting data you have stored on SD cards. As is relatively well-known, the little lock switch on the side of most SD cards really doesn’t do anything more than the switch on floppies or the tabs on VHS or cassette decks. It’s up to the reader/writer to check the status of the tab and decide if it should write to the card or not. Not a very safe system. However, it’s not the only write protection system built into SD and SDHC cards. As part of the standard, cards have three protection methods: A TMP_WRITE_PROTECT bit, a PERM_WRITE_PROTECT bit, and a PWD register.

The PERM_WRITE_PROTECT bit permanently write protects the card. The bit can not be reset, so you should be really sure you want to keep the data on the card forever. The PWD register is a password register. The card will not allow any access (read or write) unless a password is provided. The TMP_WRITE_PROTECT bit is a temporary write protect. This is the bit that [Karl] is working with. When TMP_WRITE_PROTECT is set, the card can be read but not written. Note that there is no true protection here, as anyone can modify the bit. However, this should stop grandma from accidentally deleting your wedding pictures.

[Karl’s] device is very simple. A card is inserted into an Altoids tin enclosure. One button locks the card, another unlocks it. Three LEDs return status – power, card locked, and card unlocked. Under the hood, he’s using an Atmel ATmega328 to set and clear the TMP_WRITE_PROTECT bits. Power is provided by two AA batteries, and regulated with a Pololu 3.3v boost regulator. [Karl] has also included a serial port for control and debug information. We think this is a great hack, however one thing we’re not sure of is how or if these features are implemented in all cards. We’re relatively sure the name brand cards stick to the SD/SDHC spec sheet, but what about all the knockoff and no name brands from overseas?

Detect Disguises With A Raspberry Pi

November 9, 2013 by Adam Fabio 17 Comments

maskdetect

Computer vision based face detection systems are getting better every day. Authorities have been using face detection and criminal databases for several years now. But what if a person being detected is wearing a mask? High quality masks have been making their way out of Hollywood and into the mainstream. It isn’t too far-fetched to expect someone to try to avoid detection using such a mask. To combat this, [Neil] has created a system which detects face masks.

The idea is actually rather simple. The human face has a well-defined heat signature. A mask will not have the same signature. Even when worn for hours, a mask still won’t mimic the infrared signature of the human face. The best tool for this sort of job would be a high resolution thermal imaging camera. These cameras are still relatively expensive, so [Neil] used a Melexis MLX90620 ~~64×8~~ 16×4 array sensor. The Melexis sensor is interfaced to an Arduino nano which then connects to a Raspberry Pi via serial.

The Raspberry Pi uses a Pi camera to acquire an image. OpenCV’s face detection is then used to search for faces. If a face is detected, the data from the Melexis sensor is then brought into play. In [Neil’s] proof of concept system, a temperature variance over ambient is all that is needed to detect a real face vs a fake one. As can be seen in the video after the break, the system works rather well. Considering the current climate of government surveillance, we’re both excited and a bit apprehensive to see where this technology will see real world use.

Continue reading “Detect Disguises With A Raspberry Pi” →

Cracking GSM With RTL-SDR For Thirty Dollars

October 22, 2013 by Brian Benchoff 60 Comments

Theoretically, GSM has been broken since 2003, but the limitations of hardware at the time meant cell phone calls and texts were secure from the prying ears of digital eavesdroppers and all but the most secret government agencies. Since then, the costs of hardware have gone down, two terabytes of rainbow tables have been published, and all the techniques and knowledge required to listen in on cell phone calls have been available. The only thing missing was the hardware. Now, with a super low-cost USB TV tuner come software defined radio, [domi] has put together a tutorial for cracking GSM with thirty dollars in hardware.

Previous endeavours to listen in and decrypt GSM signals used fairly expensive software defined radios – USRP systems that cost a few thousand dollars a piece. Since the advent of RTL-SDR, the price of software defined radios has come down to about $30 on eBay, giving anyone with a Paypal account the ability to listen in on GSM calls and sniff text messages.

The process of cracking GSM first involves getting the TMSI – Temporary Mobile Subscriber Identifier – a unique ID for each phone in a certain cell. This is done by sending a silent SMS that will send back and acknowledgement an SMS has been received on the victim’s phone, but won’t give the victim any indication of receiving a message.

From there, the attacker listens to the GSM signals in the cell, receiving bursts attached to a TMSI, and cracking the encrypted stream using 1.6 TB of rainbow tables.

[domi] put up a four-part tutorial series (part 1 above; part 2, part 3, and part 4) that goes over the theory and the actual procedure of cracking text messages and voice calls with a simple USB TV tuner. There are a few limitations; the attacker must be in the same cell as the victim, and it looks like real-time voice decoding isn’t yet possible. Cracking GSM for $30, though, that’s good enough for us.

Running Custom Code On Cheap One-time Password Tokens

October 15, 2013 by Mathieu Stephan 41 Comments

One-time passwords (OTP) are often used in America but not so much in Europe. For our unfamiliar readers, OTP tokens like the one shown above generate passwords that are only valid for one login session or transaction, making them invulnerable to replay attacks. [Dmitry] disassembled one eToken (Aladin PASS) he had lying around and managed to reprogram it for his own needs.

Obviously, these kind of devices don’t come with their schematics and layout files so [Dmitry] had to do some reverse engineering. He discovered six holes in a 3×2 arrangement on the PCB so he figured that they must be used to reprogram the device. However, [Dmitry] also had to find which microcontroller was present on the board as its only marking were “HA4450” with a Microchip logo. By cross-referencing the number of pins, package and peripherals on Microchip parametric search tool he deduced it was a PIC16F913. From there, it was just a matter of time until he could display what he wanted on the LCD.

We love seeing tiny consumer hardware hacked like this. Most recently we’ve been enthralled by the Trandscend Wi-Fi SD card hacking which was also one of [Dmitry’s] hacks.

Reverse Engineering A D-Link Backdoor

October 14, 2013 by Mathieu Stephan 47 Comments

Here’s one true hack (Google cache link) for our dear Hackaday readers. On a Saturday night, as [Craig] didn’t have anything else to do, he decided to download the firmware of an old D-Link DIR-100 router (because who wouldn’t?). His goal was to see what interesting things he could find in it. He fired up binwalk to extract the SquashFS file system, then opened the router webserver on the multi-processor disassembler/debugger IDA. [Craig] discovered that the webserver is actually a modified version of thttpd, providing the administrative interface for the router. As you can see in the picture above, it seems Alphanetworks (a spin-off of D-Link) performed the modifications.

Luckily for [Craig], the guys at Alphanetworks were kind enough to prepend many of their custom function names with the string “alpha”. Looking at the disassembly of the http identification functions revealed that a backdoor is implemented on the firmware. If one malicious user has the string “xmlset_roodkcableoj28840ybtide” as his browser user agent, no authentication is required to gain access to the router. One of the comments on the reddit thread points out that reading that string backwords results in: “edit by (04882) joel backdoor”.

JTAGulator Finds Debug Interfaces

October 2, 2013 by Adam Fabio 24 Comments

jtagulator

[Joe Grand] has come up with a tool which we think will be useful to anyone trying to hack a physical device: The JTAGulator. We touched on the JTAGulator briefly during our DEF CON coverage, but it really deserves a more in-depth feature. The JTAGulator is a way to discover On Chip Debug (OCD) interfaces on unfamiliar hardware.

Open any cell phone, router, or just about any moderately complex device today, and you’ll find test points. Quite often at least a few of these test points are the common JTAG / IEEE 1149.1 interface.

JTAG interfaces have 5 basic pins: TDI (Test Data In), TDO (Test Data Out), TCK (Test Clock), and TMS (Test Mode Select), /TRST (Test Reset) (optional).

If you’re looking at a PCB with many test points, which ones are the JTAG pins? Also which test points are which signals? Sometimes the PCB manufacturer will give clues on the silk screen. Other times you’re on your own. [Joe] designed the JTAGulator to help find these pins.

Continue reading “JTAGulator Finds Debug Interfaces” →

An Open Source Hardware Modchip

September 17, 2013 by Eric Evenchick 12 Comments

Many Hackaday readers might remember the days of buying modchips from somewhat questionable sources. These little devices connect to a gaming system to circumvent security measures, allowing you to run homebrew games (and pirated games, but lets not focus on that). [Guillermo] built an open source hardware Gamecube modchip based on the XenoGC.

The XenoGC was a popular modchip back in the Gamecube days, and its source was released in a forum post. A Wiki page explains how to build a clone of the device based on an ATtiny2313. Most modchips were closed source, but this project lets you look at how they work. You can browse the XenoGC source on Google Code to learn more about the exploit itself. You’ll find the AVR code, which manipulates the DVD drive over a serial interface, in the XenoAT folder.

[Guillermo]’s hardware is available from OSHPark, so you can easily order boards. He’s also hosted the design files on Github. With one in hand, you can start building homebrew for the Gamecube, which can probably be picked up for around $25 nowadays.