33C3: Hunz Deconstructs the Amazon Dash Button

The Amazon Dash button is now in its second hardware revision, and in a talk at the 33rd Chaos Communications Congress, [Hunz] not only tears it apart and illuminates the differences with the first version, but he also manages to reverse engineer it enough to get his own code running. This opens up a whole raft of possibilities that go beyond the simple “intercept the IP traffic” style hacks that we’ve seen.

dash_block_diagramJust getting into the Dash is a bit of work, so buy two: one to cut apart and locate the parts that you have to avoid next time. Once you get in, everything is tiny! There are a lot of 0201 SMD parts. Hidden underneath a plastic blob (acetone!) is an Atmel ATSAMG55, a 120 MHz ARM Cortex-M4 with FPU, and a beefy CPU all around. There is also a 2.4 GHz radio with a built-in IP stack that handles all the WiFi, with built-in TLS support. Other parts include a boost voltage converter, a BTLE chipset, an LED, a microphone, and some SPI flash.

The strangest part of the device is the sleep mode. The voltage regulator is turned on by user button press and held on using a GPIO pin on the CPU. Once the microcontroller lets go of the power supply, all power is off until the button is pressed again. It’s hard to use any less power when sleeping. Even so, the microcontroller monitors the battery voltage and presumably phones home when it gets low.
Continue reading “33C3: Hunz Deconstructs the Amazon Dash Button”

33C3: How Can You Trust Your Random Numbers?

One of the standout talks at the 33rd Chaos Communications Congress concerned pseudo-random-number generators (PRNGs). [Vladimir Klebanov] (right) and [Felix Dörre] (left) provided a framework for making sure that PRNGs are doing what they should. Along the way, they discovered a flaw in Libgcrypt/GNUPG, which they got fixed. Woot.

mpv-shot0012-zoomCryptographically secure random numbers actually matter, a lot. If you’re old enough to remember the Debian OpenSSL debacle of 2008, essentially every Internet service was backdoorable due to bad random numbers. So they matter. [Vladimir] makes the case that writing good random number generators is very, very hard. Consequently, it’s very important that their output be tested very, very well.

So how can we test them? [Vladimir] warns against our first instinct, running a statistical test suite like DIEHARD. He points out (correctly) that running any algorithm through a good enough hash function will pass statistical tests, but that doesn’t mean it’s good for cryptography.
Continue reading “33C3: How Can You Trust Your Random Numbers?”

Steve Collins: When Things Go Wrong In Space

[Steve Collins] is a regular around Hackaday. He’s brought homebrew LIDARs to our regular meetups, he’s given a talk on a lifetime’s worth of hacking, and he is the owner of the most immaculate Hackaday t-shirt we’ve ever seen.

For the 2016 Hackaday SuperConference,  [Steve] took a break from his day job of driving spacecraft around the Solar System. As you can imagine, NASA plans on things going wrong. How do you plan for that? [Steve] answers all your questions by telling you what happens when things go wrong in space.

Continue reading “Steve Collins: When Things Go Wrong In Space”

A Bold Experiment In A Decentralised Low Voltage Local DC Power Grid

January, for many of us in the Northern Hemisphere, can be a depressing month. It’s cold or wet depending where you live, the days are still a bit short, and the summer still seems an awfully long way away. You console yourself by booking a ticket to a hacker camp, but the seven months or so you’ll have to wait seems interminable.

If you want an interesting project to look forward to, take a look at [Benadski]’s idea for a decentralised low voltage local DC power grid for the upcoming SHA 2017 hacker camp in the Netherlands. The idea is to create a network that is both safe and open for hacking, allowing those with an interest in personal power generation to both have an available low-voltage power source and share their surplus power with other attendees.

The voltage is quoted as being 42V DC +/- 15%, which keeps it safely under the 50V limit set by the European Low Voltage Directive. Individuals can request a single 4A connection to the system, and villages can have a pair of 16A connections, which should supply enough for most needs. Users will need to provide their own inverters to connect their 5V or 12V appliances, fortunately a market served by numerous modules from your favourite Far Eastern sales portal.

This project will never be the solution to all power distribution needs, but to be fair that is probably not the intention. It does however provide a platform for experimentation, collaboration, and data gathering for those interested in the field, and since it is intended to make an appearance at future hacker camps there should be the opportunity for all that built up expertise to make it better over time.

We’ve touched on this subject before here at Hackaday, with our look at the availability of standard low voltage DC domestic connectors.

Wind turbine image: Glogger (CC BY-SA 3.0) via Wikimedia Commons.

Shmoocon 2017: The Ins And Outs Of Manufacturing And Selling Hardware

Every day, we see people building things. Sometimes, useful things. Very rarely, this thing becomes a product, but even then we don’t hear much about the ins and outs of manufacturing a bunch of these things or the economics of actually selling them. This past weekend at Shmoocon, [Conor Patrick] gave the crowd the inside scoop on selling a few hundred two factor authentication tokens. What started as a hobby is now a legitimate business, thanks to good engineering and abusing Amazon’s distribution program.

The product in question is the U2F Zero, an open source U2F token for two-factor authentication. It’s built around the Atmel/Microchip ATECC508A crypto chip and is, by all accounts, secure enough. It’s also cheap at about $0.70 a piece, and the entire build comes to about $3 USD. All of this is hardware, and should be extremely familiar to the regular Hackaday reader. This isn’t the focus of [Conor]’s talk though. The real challenge is how to manufacture and sell these U2F dongles, a topic we looked in on back in September.

The circuit for this U2F key is basically just a crypto chip and a USB microcontroller, each of which needs to be programmed separately and ideally securely. The private key isn’t something [Conor] wants to give to an assembly house, which means he’s programming all these devices himself.

For a run of 1100 units, [Conor] spent $350 on PCB, $3600 for components and assembly, $190 on shipping and tariffs from China, and an additional $500 for packaging on Amazon. That last bit pushed the final price of the U2F key up nearly 30%, and packaging is something you have to watch if you ever want to sell things of your own.

For distribution, [Conor] chose Fulfillment By Amazon. This is fantastically cheap if you’re selling a product that already exists, but of course, [Conor]’s U2F Zero wasn’t already on Amazon. A new product needs brand approval, and Amazon would not initially recognize the U2F Zero brand. The solution to this was for [Conor] to send a letter to himself allowing him to use the U2F Zero brand and forward that letter to the automated Amazon brand bot. Is that stupid? Yes. Did it work? Also yes.

Sales were quiet until [Conor] submitted a tip to Hacker News and sold about 70 U2F Zeros in a day. After that, sales remained relatively steady. The U2F Zero is now a legitimate product. Even though [Conor] isn’t going to get rich by selling a dozen or so U2F keys a day, it’s still an amazing learning experience and we’re glad to have sat in on his story of bootstrapping a product, if only for the great tip on getting around Amazon’s fulfillment policies.

Shmoocon 2017: Software Defined Radio for Terahertz Frequencies

Before Bluetooth, before the Internet of Things, and before network-connected everything, infrared was king. In the 90s, personal organizers, keyboards, Furbys, and critical infrastructure was built on infrared. Some of these devices are still around, hiding in plain sight. This means there’s a lot of opportunities for some very fun exploits. This was the focus of [Mike Ossmann] and [Dominic Spill]’s talk at this year’s Shmoocon, Exploring The Infrared World. What’s the hook? Using software-defined radio with terahertz frequencies.

[Dominic]’s infrared detector
Infrared communication hasn’t improved since the days of IrDA ports on laptops, and this means the hardware required to talk to these devices is exceptionally simple. The only thing you need is an IR phototransistor and a 4.7k resistor. This is enough to read signals, but overkill is the name of the game here leading to the development of the Gladiolus GreatFET neighbor. This add-on board for the GreatFET is effectively a software defined IR transceiver capable of playing with IrDA, 20 to 60 kHz IR remote control systems, and other less wholesome applications.

Demos are a necessity, but the world seems to have passed over IR in the last decade. That doesn’t mean there still aren’t interesting targets. A week before Shmoocon, [Mike Ossmann] put out the call on Twitter for a traffic light and the associated hardware. Yes, police cars and ambulances use infrared signaling to turn traffic lights green. You shouldn’t. You can, but you shouldn’t.

What was the takeaway from this talk? IR still exists, apparently. Yes, you can use it to send documents directly from your PalmPilot to a laser printer without any wires whatsoever. One of the more interesting applications for IR is an in-car wireless headphone unit that sends something almost, but not quite, like pulse coded audio over infrared. The demo that drew the most applause was an infrared device that changed traffic lights to green. The information to do that is freely available on the web, but you seriously don’t want to attempt that in the wild.

Shmoocon 2017: Dig Out Your Old Brick Phone

The 90s were a wonderful time for portable communications devices. Cell phones had mass, real buttons, and thick batteries – everything you want in next year’s flagship phone. Unfortunately, Zach Morris’ phone hasn’t been able to find a tower for the last decade, but that doesn’t mean these phones are dead. This weekend at Shmoocon, [Brandon Creighton] brought these phones back to life. The Motorola DynaTAC lives again.

[Brandon] has a history of building ad-hoc cell phone networks. A few years ago, he was part of Ninja Tel, the group that set up their own cell phone network at DEF CON. That was a GSM network, and brickphones are so much cooler, so for the last few months he’s set his sights on building out a 1G network. All the code is up on GitHub, and the hardware requirements for building a 1G tower are pretty light; you can roll your own 1G network for about $400.

The first step in building a 1G network, properly referred to as an AMPS network, is simply reading the documentation. The entire spec is only 136 pages, it’s simple enough for a single person to wrap their head around, and the concept of a ‘call’ really doesn’t exist. AMPS looks more like a trunking system, and the voice channels are just FM. All of this info was translated into GNU Radio blocks, and [Brandon] could place a call to an old Motorola flip phone.

As far as hardware is concerned, AMPS is pretty lightweight when compared to the capabilities of modern SDR hardware. The live demo setup used an Ettus Research USRP N210, but this is overkill. These phones operate around 824-849 MHz with minimal bandwidth, so a base station could easily be assembled from a single HackRF and an RTL-SDR dongle.

Yes, the phones are old, but there is one great bonus concerning AMPS. Nobody is really using these frequencies anymore in the US. That’s not to say building your own unlicensed 1G tower in the US is legally permissible, but if nobody reports you, you can probably get away with it.