Hacking Toy RC Cars With The HackRF One

The origin story for many who’d call themselves a member of the hacker community usually starts with taking things apart as a child just to see how they worked. For [Radoslav], that trend doesn’t seem to have slowed down, and he’s continued taking toys apart. Although since it’s his daughters little radio controlled car, he stuck to a non-destructive teardown. The result? He’s able to control the car with his laptop through a HackRF One SDR transceiver as shown in the video below the break.

[Radoslav] is no stranger to reverse engineering embedded devices, IoT gadgets, and probably more. So he started with what information was publicly available about the radio control interface in use. Many electronic devices sold in the US must be certified by the FCC (Federal Communications Commission) and prominently display their ID number, and this toy was no exception. The FCC database gave [Radoslav] enough information to know that the communication protocol is modulated with GFSK, a type of Frequency Shift Keying.

He fired up his favorite radio signal analysis tool and and got to work on the protocol itself. Along the way he found that communication between the car and controller is bidirectional but also very easy to get around. The result is that he can drive the car around with his laptop- definitely a cool hack, but for this one, the journey was surely the goal, not the destination.

If hacking on RC cars really gets your wheels turning, you might like this little RC car that can drive on the ceiling. Or if you’re feeling a bit hungry, check out how you can use the HackRF to nab a table at your local restaurant.

Continue reading “Hacking Toy RC Cars With The HackRF One”

Analog Failures On RF Product Cause Production Surprise

A factory is a machine. It takes a fixed set of inputs – circuit boards, plastic enclosures, optimism – and produces a fixed set of outputs in the form of assembled products. Sometimes it is comprised of real machines (see any recent video of a Tesla assembly line) but more often it’s a mixture of mechanical machines and meaty humans working together. Regardless of the exact balance the factory machine is conceived of by a production engineer and goes through the same design, iteration, polish cycle that the rest of the product does (in this sense product development is somewhat fractal). Last year [Michael Ossmann] had a surprise production problem which is both a chilling tale of a nasty hardware bug and a great reminder of how fragile manufacturing can be. It’s a natural fit for this year’s theme of going to production.

Surprise VCC glitching causing CPU reset

The saga begins with [Michael] receiving an urgent message from the factory that an existing product which had been in production for years was failing at such a high rate that they had stopped the production line. There are few worse notes to get from a factory! The issue was apparently “failure to program” and Great Scott Gadgets immediately requested samples from their manufacturer to debug. What follows is a carefully described and very educational debug session from hell, involving reverse engineering ROMs, probing errant voltage rails, and large sample sizes. [Michael] doesn’t give us a sense for how long it took to isolate but given how minute the root cause was we’d bet that it was a long, long time.

The post stands alone as an exemplar for debugging nasty hardware glitches, but we’d like to call attention to the second root cause buried near the end of the post. What stopped the manufacturer wasn’t the hardware problem so much as a process issue which had been exposed. It turned out the bug had always been reproducible in about 3% of units but the factory had never mentioned it. Why? We’d suspect that [Michael]’s guess is correct. The operators who happened to perform the failing step had discovered a workaround years ago and transparently smoothed the failure over. Then there was a staff change and the new operator started flagging the failure instead of fixing it. Arguably this is what should have been happening the entire time, but in this one tiny corner of the process the manufacturing process had been slightly deviated from. For a little more color check out episode #440.2 of the Amp Hour to hear [Chris Gammell] talk about it with [Michael]. It’s a good reminder that a product is only as reliable as the process that builds it, and that process isn’t always as reliable as it seems.

Pokemon Go Cheat Fools GPS With Software Defined Radio

Using Xcode to spoof GPS locations in Pokemon Go (like we saw this morning) isn’t that much of a hack, and frankly, it’s not even a legit GPS spoof. After all, it’s not like we’re using an SDR to spoof the physical GPS signal to cheat Pokemon Go.

To [Stefan Kiese], this isn’t much more than an exercise. He’s not even playing Pokemon Go. To squeeze a usable GPS signal out of his HackRF One, a $300 Software Defined Radio, [Stefan] uses an external precision clock. This makes up for the insufficient calibration of the HackRF’s internal clock, although he points out that this might also be fixed entirely in software.

Continue reading “Pokemon Go Cheat Fools GPS With Software Defined Radio”

Shmoocon 2016: Z-Wave Protocol Hacked With SDR

The first talk at 2016 Shmoocon was a great one. Joseph Hall and Ben Ramsey presented their work hacking Z-Wave, a network that has been gaining a huge market share in both consumer and industrial connected devices. EZ-Wave uses commodity Software Defined Radio to exploit Z-Wave networks. This is not limited to sniffing, but also used for control with the potential for mayhem.

Continue reading “Shmoocon 2016: Z-Wave Protocol Hacked With SDR”