FCC Reaches Agreement With Router Manufacturers

August 2, 2016 by Brian Benchoff 43 Comments

Last year, the Federal Communications Commission proposed a rule governing the certification of RF equipment, specifically wireless routers. This proposed rule required router manufacturers to implement security on the radio module inside these routers. Although this rule is fairly limited in scope – the regulation only covers the 5GHz U-NII bands, and only applies to the radio subsystem of a router, the law of unintended consequences reared its ugly head. The simplest way to lock down a radio module is to lock down the entire router, and this is exactly what a few large router manufacturers did. Under this rule, open source, third-party firmwares such as OpenWRT are impossible.

Now, router manufacturer TP-Link has reached an agreement with the FCC to allow third-party firmware. Under the agreement, TP-Link will pay a $200,000 fine for shipping routers that could be configured to run above the permitted power limits.

This agreement is in stark contrast to TP-Link’s earlier policy of shipping routers with signed, locked firmware, in keeping with the FCC’s rule.

This is a huge success for the entire open source movement. Instead of doing the easy thing – locking down a router’s firmware and sending it out the door – TP-Link has chosen to take a hit to their pocketbook. That’s great news for any of the dozens of projects experimenting with mesh networking, amateur radio, or any other wireless networking protocol, and imparts a massive amount of goodwill onto TP-Link.

Thanks [Maave] for the tip.

Microchip Publishes USB Mass Storage Loader

March 11, 2016 by Mike Szczys 36 Comments

Microchip just published their USB-MSD Programmer firmware. This open source project allows a board to enumerate as a USB Mass Storage device. Programming is as simple as copying a .hex file to the “drive”.

This code is what’s running on the $10 Xpress board that they released last month which includes a PIC18F25K50 to serve as a PICkit On Board (PKOB) programmer for the actual target micro; a PIC16F18855. In its stock version, the XPRESS-Loader firmware programs any PIC16F188xx chips that have a row size of 32 words. But it should be possible to tweak this package to program any chips that use the 8-bit LVP-ICSP protocol.

Now, this may seem like small potatoes at first look: it requires two microcontrollers on your board and is capable of programming just a small subset of the vast PIC inventory. But in our minds it’s the USB-MSD that is killer since it doesn’t require any software or drivers on the computer side of things. That’s a big invitation for all kinds of hacks. But there should be even more on the way from the Xpress team before too long.

It turns out the microcontroller [Voja Antonic] chose to use on the Hackaday | Belgrade badge is the 25k50. Since hearing about the Xpress board we’ve been talking to some of the PIC engineers and they are exploring a loader that will program onto the same chip. This means device upgrades without special hardware or drivers – perfect for badge hacking at a conference. This can be done with a precompiled hex, one created on MPLAB X, MPLAB Xpress, or others. We’ll keep you updated if we hear more on that part of the project.

32C3: Towards Trustworthy X86 Laptops

December 28, 2015 by Brian Benchoff 38 Comments

Security assumes there is something we can trust; a computer encrypting something is assumed to be trustworthy, and the computer doing the decrypting is assumed to be trustworthy. This is the only logical mindset for anyone concerned about security – you don’t have to worry about all the routers handling your data on the Internet, eavesdroppers, or really anything else. Security breaks down when you can’t trust the computer doing the encryption. Such is the case today. We can’t trust our computers.

In a talk at this year’s Chaos Computer Congress, [Joanna Rutkowska] covered the last few decades of security on computers – Tor, OpenVPN, SSH, and the like. These are, by definition, meaningless if you cannot trust the operating system. Over the last few years, [Joanna] has been working on a solution to this in the Qubes OS pro ject, but everything is built on silicon, and if you can’t trust the hardware, you can’t trust anything.

And so we come to an oft-forgotten aspect of computer security: the BIOS, UEFI, Intel’s Management Engine, VT-d, Boot Guard, and the mess of overly complex firmware found in a modern x86 system. This is what starts the chain of trust for the entire computer, and if a computer’s firmware is compromised it is safe to assume the entire computer is compromised. Firmware is also devilishly hard to secure: attacks against write protecting a tiny Flash chip have been demonstrated. A Trusted Platform Module could compare the contents of a firmware, and unlock it if it is found to be secure. This has also been shown to be vulnerable to attack. Another method of securing a computer’s firmware is the Core Root of Trust for Measurement, which compares firmware to an immutable ROM-like memory. The specification for the CRTM doesn’t say where this memory is, though, and until recently it has been implemented in a tiny Flash chip soldered to the motherboard. We’re right back to where we started, then, with an attacker simply changing out the CRTM chip along with the chip containing the firmware.

But Intel has an answer to everything, and to the house of cards for firmware security, Intel introduced their Management Engine. This is a small microcontroller running on every Intel CPU all the time that has access to RAM, WiFi, and everything else in a computer. It is security through obscurity, though. Although the ME can elevate privileges of components in the computer, nobody knows how it works. No one has the source code for the operating system running on the Intel ME, and the ME is an ideal target for a rootkit.

Is there hope for a truly secure laptop? According to [Joanna], there is hope in simply not trusting the BIOS and other firmware. Trust therefore comes from a ‘trusted stick’ – a small memory stick that contains a Flash chip that verifies the firmware of a computer independently of the hardware in a computer.

This, with open source firmwares like coreboot are the beginnings of a computer that can be trusted. While the technology for a device like this could exist, it will be a while until something like this will be found in the wild. There’s still a lot of work to do, but at least one thing is certain: secure hardware doesn’t exist, but it can be built. Whether secure hardware comes to pass is another thing entirely.

You can watch [Joanna]’s talk on the 32C3 streaming site.

Embed With Elliot: Debounce Your Noisy Buttons, Part I

December 9, 2015 by Elliot Williams 98 Comments

“Psst…hey buddy! Wanna see the sweetest little debouncing routine this side of Spokane? C’mon over here. Step right over those bit-shift operators, they don’t bite. Now look at this beauty right here: I call her The Ultimate Debouncer(tm)!”

Everybody who works with microcontrollers eventually runs into the issue of switch bounce or “chatter”, and nearly everyone has their own favorite solution. Some fix it in hardware, others fix it in software. Some hackers understand chatter, and others just cut-and-paste the classic routines. Some folks even try to ignore it, and they might even get lucky, but everyone’s luck runs out sometimes.

In the next two “Embed with Elliot” installments, I’ll look a little bit at bouncing, look into doing hardware debouncing both the simple way and the right way, and build up a basic software routine that demonstrates some of the principles and which works just fine, though it’s not optimized. We’ll be laying the groundwork.

In the next installment, I’ll let you in on my personal favorite debounce routine. It’s a minor tweak on a standard, but with some special sauce that’s worth spreading around. I’ll call it the Ultimate Debouncer(tm), but will it stand up to the scrutiny of the Hackaday commenteers? (How’s that for a cliffhanger?!?)

For now, though, let’s look into switch bounce and the standard ways to fix it in hardware and software.

Continue reading “Embed With Elliot: Debounce Your Noisy Buttons, Part I” →

Hacking A KVM: Teach A Keyboard Switch To Spy

August 8, 2015 by Mike Szczys 11 Comments

When it comes to large systems, there are a lot more computers than there are people maintaining them. That’s not a big deal since you can simply use a KVM to connect one Keyboard/Video/Mouse terminal up to all of them, switching between each box simply and seamlessly. The side effect is that now the KVM has just as much access to all of those systems as the human who caresses the keyboard. [Yaniv Balmas] and [Lior Oppenheim] spent some time reverse engineering the firmware for one of these devices and demonstrated how shady firmware can pwn these systems, even when some of the systems themselves are air-gapped from the Internet. This was their first DEF CON talk and they did a great job of explaining what it took to hack these devices.

Continue reading “Hacking A KVM: Teach A Keyboard Switch To Spy” →

Dumping Old PROMs With New Hardware

July 11, 2015 by Brian Benchoff 34 Comments

[ijsf] recently came across a very old synthesizer from a defunct West German company. This was one of the first wavetable synths available, and it’s exceptionally rare. Being so rare, there isn’t much documentation on the machine. In an attempt at reverse engineering, [ijsf] decided to dump the EPROMs and take a peek at what made this synth work. There wasn’t an EPROM programmer around to dump the data, but [ijsf] did have a few ARM boards around. It turns out building a 27-series PROM dumper is pretty easy, giving [ijsf] an easy way to dig into the code on this machine.

The old EPROMs in this machine have 5v logic, so [ijsf] needed to find a board that had a ton of IOs and 5v tolerant inputs. He found the LPC2148, which has a nice USB system that can be programmed to dump the contents of a PROM over serial. Interfacing the PROM is as simple as connecting the power and ground, the address lines, data, and the signal lines. After that, it’s just a matter of stepping through every address according to the timing requirements of the PROM. All the data was dumped over a serial interface, and in just a few seconds, [ijsf] had 32768 bytes of ancient data that made this old synth tick.

Hard Drive Rootkit Is Frighteningly Persistent

June 8, 2015 by Rick Osgood 82 Comments

There are a lot of malware programs in the wild today, but luckily we have methods of detecting and removing them. Antivirus is an old standby, and if that fails you can always just reformat the hard drive and wipe it clean. That is unless the malware installs itself in your hard drive firmware. [MalwareTech] has written his own frightening proof of concept malware that does exactly this.

The core firmware rootkit needs to be very small in order to fit in the limited memory space on the hard drive’s memory chips. It’s only a few KB in size, but that doesn’t stop it from packing a punch. The rootkit can intercept any IO to and from the disk or the disk’s firmware. It uses this to its advantage by modifying data being sent back to the host computer. When the computer requests data from a sector on the disk, that data is first loaded into the disk’s cache. The firmware can modify the data sitting in the cache before notifying the host computer that the data is ready. This allows the firmware to trick the host system into executing arbitrary code.

[MalwareTech] uses this ability to load his own custom Windows XP bootkit called TinyXPB. All of this software is small enough to fit on the hard drive’s firmware. This means that traditional antivirus cannot detect its presence. If the owner of the system does get suspicious and completely reformats the hard drive, the malware will remain unharmed. The owner cannot even re-flash the firmware using traditional methods since the rootkit can detect this and save itself. The only way to properly re-flash the firmware would be to use an SPI programmer, which would be too technical for most users.

There are many more features and details to this project. If you are interested in malware, the PDF presentation is certainly worth a read. It goes much more in-depth into how the malware actually works and includes more details about how [MalwareTech] was able to actually reverse engineer the original firmware. If you’re worried about this malicious firmware getting out into the wild, [MalwareTech] assures us that he does not intend to release the actual code to the public.