Cyclists Use Tiny Motors To Cheat

April 25, 2016 by Elliot Williams 138 Comments

Blood doping is so last decade! The modern cyclist has a motor and power supply hidden inside the bike’s frame.

We were first tipped off to the subject in this article in the New York Times. A Belgian cyclocross rider, Femke Van den Driessche, was caught with a motor hidden in her bike.

While we don’t condone sports cheating, we think that hiding a motor inside a standard bike is pretty cool. But it’s even more fun to think of how to catch the cheats. The Italian and French press have fixated on the idea of using thermal cameras to detect the heat. (Skip to 7:50 in the franceTVsport clip.) We suspect it’s because their reporters recently bought Flir cameras and are trying to justify the expense.

The UCI, cycling’s regulatory body, doesn’t like thermal. They instead use magnetic pulses and listen for the characteristic ringing of a motor coil inside the frame. Other possibilities include X-ray and ultrasonic testing. What do you think? How would you detect a motor inside a bike frame or gearset?

This Teddy Bear Steals Your Ubuntu Secrets

April 22, 2016 by Elliot Williams 20 Comments

Ubuntu just came out with the new long-term support version of their desktop Linux operating system. It’s got a few newish features, including incorporating the “snap” package management format. One of the claims about “snaps” is that they’re more secure — being installed read-only and essentially self-contained makes them harder to hack across applications. In principle.

[mjg59] took issue with their claims of increased cross-application security. And rather than just moan, he patched together an exploit that’s disguised as a lovable teddy bear. The central flaw is something like twenty years old now; X11 has no sense of permissions and any X11 application can listen in on the keyboard and mouse at any time, regardless of which application the user thinks they’re providing input to. This makes writing keylogging and command-insertion trojans effortless, which is just what [mjg59] did. You can download a harmless version of the demo at [mjg59]’s GitHub.

This flaw in X11 is well-known. In some sense, there’s nothing new here. It’s only in light of Ubuntu’s claim of cross-application security that it’s interesting to bring this up again.

And the teddy bear in question? Xteddy dates back from when it was cool to display a static image in a window on a workstation computer. It’s like a warmer, cuddlier version of Xeyes. Except it just sits there. Or, in [mjg59]’s version, it records your keystrokes and uploads your passwords to shady underground characters or TLAs.

We discussed Snappy Core for IoT devices previously, and we think it’s a step in the right direction towards building a system where all the moving parts are only loosely connected to each other, which makes upgrading part of your system possible without upgrading (or downgrading) the whole thing. It probably does enhance security when coupled with a newer display manager like Mir or Wayland. But as [mjg59] pointed out, “snaps” alone don’t patch up X11’s security holes.

Embed With Elliot: Keeping It Integral

April 22, 2016 by Elliot Williams 66 Comments

If there’s one thing that a lot of small microcontrollers hate (and that includes the AVR-based Arduini), it’s floating-point numbers. And if there’s another thing they hate it’s division. For instance, dividing 72.3 by 12.9 on an Arduino UNO takes around 32 microseconds and 500 bytes, while dividing 72 by 13 takes 14 microseconds and 86 bytes. Multiplying 72 by 12 takes a bit under 2.2 microseconds. So roughly speaking, dividing floats is twice as slow as dividing (16-bit) integers, and dividing at all is five to seven times slower than multiplying.

There’s a whole lot of the time that you just don’t care about speed. For instance, if you’re doing a calculation that only runs infrequently, it doesn’t matter if you’re using floats or slow division routines. But if you ever find yourself in a tight loop that’s using floating-point math and/or doing division, and you need to get a bit more speed, I’ve got some tips for you.

Some of these tips (in particular the integer division tricks at the end) are arcane wizardry — only to be used when the situation really calls for it. But if you’re doing the same calculations repeatedly, you can often gain a lot just by giving the microcontroller numbers in the format it natively understands. Have a little sympathy for the poor little silicon beasties trapped inside!

Continue reading “Embed With Elliot: Keeping It Integral” →

All Prior Art

April 21, 2016 by Elliot Williams 31 Comments

Disclosed herein is a device for gauging medication dosage. The method may include displaying first, second and third navigation controls. A switch is connected in parallel to the relay contacts and is configured for providing a portion of the input power as supplemental load power to the output as a function of back EMF energy.

We’ve had patents on the mind lately, and have been reading a fair few of them. If you read patent language long enough, though, it all starts to turn into word-salad. But with his All Prior Art and All the Claims websites, [Alexander Reben] tosses this salad for real. He’s got computers parsing existing patents and randomly reassembling them.

Rather than hoping that his algorithm comes up with the next great idea, [Alexander] is hoping to nip the truly trivial ones in the bud. Because prior art — the sum of all pre-existing ideas — is enough to disqualify a patent, if an idea is so trivial that his algorithm could have come up with it, it’s sooner or later going to be off the table.

Most of the results are insane, of course. And it seems to be producing a patent at a rate of about one per 10-15 seconds, so we’re guessing that it’ll take quite a few years for these cyber-monkeys to come up with the works of Shakespeare. But with bogus and over-broad patents filtering through the system every day, it’s not implausible that some day it’ll prove useful.

[Via New Scientist, thanks Frank!]

BeagleBone Pin-Toggling Torture Test

April 21, 2016 by Elliot Williams 20 Comments

Benchmarks often get criticized for their inability to perfectly model the real-world situations that we’d like them to. So take what follows in the limited scope that it’s intended, and don’t read too much into it. [Joonas Pihlajamaa]’s experiments with toggling a hardware pin as fast as possible on different single-board computers can still show us something.

The take-home result won’t surprise anyone who’s worked with a single-board computer: the higher-level interfaces are simply slow compared to direct memory-mapped GPIO access. But really slow. We’re talking around 5 kHz from Python or any of the file-based interfaces to the pins versus 3 MHz for direct access. Worse, as you’d expect when a non-realtime operating system is in the middle, there are glitches on the order of ten milliseconds with all the file-based methods.

This test only tells us so much, though, and it’s not really taking advantage of the BeagleBone Black’s ace in the hole, the PRUs — onboard hardware processors that bring real-time IO capabilities to the system. We’d like to see a re-write of the code to take advantage of libpruio, for instance. A 20 MHz square wave is a piece of cake with the PRUs.

Of course, it’s not interacting, which is probably in the spirit of the benchmark as written. But if raw hardware speed on a BeagleBone is the goal, it’s likely that the PRUs are going to feature prominently in the solution.

[Sprite_tm] Gives Near Death VFD A Better Second Life

April 20, 2016 by Elliot Williams 16 Comments

[Sprite_tm] picked up some used VFD displays for cheap, and wanted to make his own custom temperature and air-quality display. He did that, of course, but turned it into a colossal experiment in re-design to boot. What started out as a $6 used VFD becomes priceless with the addition of hours of high-powered hacking mojo.

You see, the phosphor screen had burnt-in spots where the old display was left static for too long. A normal person would either live with it or buy new displays. [Sprite_tm] ripped off the old display driver and drives the row and column shift registers using the DMA module on a Raspberry Pi2, coding up his own fast PWM/BCM hybrid scheme that can do greyscale.

He mapped out the individual pixels using a camera and post processing in The Gimp to establish the degradation of burnt-in pixels. He then re-wrote a previous custom driver project to compensate for the pixels’ inherent brightness in firmware. After all that work, he wrapped the whole thing up in a nice wooden frame.

There’s a lot to read, so just go hit up his website. High points include the shift-register-based driver transplant, the bit-angle modulation that was needed to get the necessary bit-depth for the grayscale, and the PHP script that does the photograph-based brightness correction.

Picking a favorite [Sprite_tm] hack is like picking a favorite ice-cream flavor: they’re all good. But his investigation into hard-drive controller chips still makes our head spin just a little bit. If you missed his talks about the Tamagotchi Singularity from the Hackaday SuperCon make sure you drop what you’re doing and watch it now.

The Sincerest Form Of Flattery: Cloning Open-Source Hardware

April 19, 2016 by Elliot Williams 79 Comments

We’re great proponents (and beneficiaries) of open-source hardware here at Hackaday. It’s impossible to overstate the impact that the free sharing of ideas has had on the hacker hardware scene. Plus, if you folks didn’t write up the cool projects that you’re making, we wouldn’t have nearly as much to write about.

We also love doing it ourselves. Whether this means actually etching the PCB or just designing it ourselves and sending it off to the fab, we’re not the types to pick up our electronics at the Buy More (except when we’re planning to tear them apart). And when we don’t DIY, we like our electrons artisanal because we like to support the little guy or girl out there doing cool design work.

So it’s with a moderately heavy heart that we’ll admit that when it comes to pre-built microcontroller and sensor boards, I buy a lot of cheap clones. Some of this is price sensitivity, to be sure. If I’m making many different one-off goofy projects, it just doesn’t make sense to pay the original-manufacturer premium over and over again for each one. A $2 microcontroller board just begs to be permanently incorporated into give-away projects in a way that a $20 board doesn’t. But I’m also positively impressed by some of the innovation coming out of some of the clone firms, to the point that I’m not sure that the “clone” moniker is fair any more.

This article is an attempt to come to grips with innovation, open source hardware, and the clones. I’m going to look at these issues from three different perspectives: the firm producing the hardware, the hacker hobbyist purchasing the hardware, and the innovative hobbyist who just wants to get a cool project out to as many people as possible. They say that imitation is the sincerest form of flattery, but can cloning go too far? To some extent, it depends on where you’re sitting.

Continue reading “The Sincerest Form Of Flattery: Cloning Open-Source Hardware” →