FTDI Screws Up, Backs Down

October 24, 2014 by Brian Benchoff 252 Comments

A few days ago we learned chip maker FTDI was doing some rather shady things with a new driver released on Windows Update. The new driver worked perfectly for real FTDI chips, but for counterfeit chips – and there are a lot of them – the USB PID was set to 0, rendering them inoperable with any computer. Now, a few days later, we know exactly what happened, and FTDI is backing down; the driver has been removed from Windows Update, and an updated driver will be released next week. A PC won’t be able to communicate with a counterfeit chip with the new driver, but at least it won’t soft-brick the chip.

Microsoft has since released a statement and rolled back two versions of the FTDI driver to prevent counterfeit chips from being bricked. The affected versions of the FTDI driver are 2.11.0 and 2.12.0, released on August 26, 2014. The latest version of the driver that does not have this chip bricking functionality is 2.10.0.0, released on January 27th. If you’re affected by the latest driver, rolling back the driver through the Device Manager to 2.10.0.0 will prevent counterfeit chips from being bricked. You might want to find a copy of the 2.10.0 driver; this will likely be the last version of the FTDI driver to work with counterfeit chips.

Thanks to the efforts of [marcan] over on the EEVblog forums, we know exactly how the earlier FTDI driver worked to brick counterfeit devices:

[marcan] disassembled the FTDI driver and found the source of the brick and some clever coding. The coding exploits differences found in the silicon of counterfeit chips compared to the legit ones. In the small snippet of code decompiled by [marcan], the FTDI driver does nothing for legit chips, but writes 0 and value to make the EEPROM checksum match to counterfeit chips. It’s an extremely clever bit of code, but also clear evidence FTDI is intentionally bricking counterfeit devices.

A new FTDI driver, presumably one that will tell you a chip is fake without bricking it, will be released next week. While not an ideal outcome for everyone, at least the problem of drivers intentionally bricking devices is behind us.

DEFCON 22: Hack All The Things

August 9, 2014 by Mike Szczys 21 Comments

This morning I went to a fantastic talk called Hack All the Things. It was presented by GTVHacker. If you don’t recognize the name, this is the group that hacked the GoogleTV. They haven’t stopped hacking since that success, and this talk is all about 20+ devices that they’ve recently pwned and are making the info public (that link still had oath when I checked but should soon be public).

The attacks they presented come in three flavors: UART, eMMC, and command injection bugs. I’m going to add the break now, but I’ll give a rundown of most of the device exploits they showed off. I found all amusing, and often comical.

Continue reading “DEFCON 22: Hack All The Things” →

Hackaday Links: May 11, 2014

May 11, 2014 by Brian Benchoff 11 Comments

North Korean drones! Yes, your local hobby shop has the same aerial reconnaissance abilities as North Korea. Props to Pyongyang for getting v-tail mixing down.

There’s nothing quite as satisfying as the look of a well laid out resistor array, and the folks at Boldport have taken this to a new level. It’s an art piece, yes, but these would make fabulous drink coasters.

Here’s something even more artistic. [cpurola] found a bunch of cerdip EPROMs and bent the pins in a weird chainmaille-esque way. The end result is an EPROM bracelet, just in time for mother’s day. It’s a better use for these chips than tearing them apart and plundering them for the few cents worth of gold in each.

[John] still uses his original Xbox for xmbc, but he’d like to use the controllers with his computer. He never uses the third and fourth controller ports, so he stuck those in his computer. It’s as simple as soldering the controller port module to a connector and plugging it into an internal USB port. Ubuntu worked great, but Windows required XBCD.

[Kerry] has modified an FT232 USB/UART thingy as an Arduino programmer before. The CP2102 USB/UART is almost as popular on eBay, a little less expensive, and equally suited for ‘duino programming. It requires desoldering a resistor and soldering a jumper on a leadless package, but with a fine solder tip, it’s not too bad.

Software Half Duplex UART For AVRs

January 13, 2014 by Eric Evenchick 57 Comments

If you have worked with very low cost microcontroller in the past, such as the ATtiny series from AVR, you’ve probably been stuck without a UART peripheral. The usual answer to this problem is to implement the UART in software. It’s not fast, but it works.

Lets say you’re even more limited on resources, and only have a single pin for UART. [Ralph] created a software library and a small circuit that enables half duplex UART using only one pin. With the above circuit, and a 62 byte Arduino compatible library, you can add UART to the tiniest of ATtinys.

In this circuit, the Tx/Rx pin is on the AVR, and the Tx and Rx pins are another device. The circuit relies on the idle state of UART being a logic high signal. When the Tx pin is idle, the transistor stays on. This allows the Tx/Rx pin to pull Rx low when the AVR sends a 0. When the Tx pin sends a 0, the Tx/Rx pin gets pulled low through the diode.

It’s a clever hack, and could definitely help add communication to your next tiny project.

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” →

Giving The Nexus 4 A Serial Port

May 30, 2013 by Brian Benchoff 28 Comments

Having a serial port on any Linux box is always useful, but with the tiny computers we’re carrying around in our pockets now, that isn’t always an option. Some of the more advanced phones out there break out a UART on their USB OTG port, but the designers of the Nexus 4 decided to do things differently. They chose to put the Nexus 4’s serial port on the mic and headphone input, and [Ryan] and [Josh] figured out how to access this port.

Basically, the Nexus 4 has a tiny bit of circuitry attached to the microphone input. If the Nexus detects more than 2.8 Volts on the mic, it switches over to a hardware UART, allowing everything from an Arduino to an old dumb terminal to access the port.

The guys used a USB to serial FTDI board wired up to a 3.5 mm jack with a few resistors to enable the hardware UART on their phone. With a small enclosure, they had a reasonably inexpensive way to enable a hardware serial port on a mobile device with GPS, cellular, a camera, and a whole bunch of other sensors that any portable project would love.

EDIT: An anonymous little bird told us this: “You should add a note to the Nexus 4 serial cable post that TX and RX need to be 1.8V. If you use 3.3V USB cables, you will likely eventually fry something. FTDI makes 1.8V IO cables that work – you just need to make the trigger voltage for the mic line.” Take that for what you will.

Rooting Your AT&T U-verse Modem

December 13, 2012 by Mike Szczys 26 Comments

Unhappy with the performance of his U-verse modem [Jordan] decided to dig in and see if a bit of hacking could improve the situation. Motorola makes this exclusively for AT&T and there are no other modems on the market which can used instead. Luckily he was able to fix almost everything that was causing him grief. This can be done in one of two ways. The first is a hardware hack that gains access to a shell though the UART. The second is a method of rooting the device from its stock web interface.

We think the biggest improvement gained by hacking this router is true bridge mode. The hardware is more than capable of behaving this way but AT&T has disabled the feature with no option for an unmodified device to use it. By enabling it the modem does what a modem is supposed to do: translate between WAN and LAN. This allows routing to be handled by a router (novel idea huh?).