Jeremy Cook Is Living His Strandbeest Dream

The first thing Jeremy Cook thought when he saw a video of Theo Jansen’s Strandbeest walking across the beach was how incredible the machine looked. His second thought was that there was no way he’d ever be able to build something like that himself. It’s a feeling that most of us have had at one time or another, especially when starting down a path we’ve never been on before.

But those doubts didn’t keep him from researching how the Strandbeest worked, or stop him from taking the first tentative steps towards building his own version. It certainly didn’t happen overnight. It didn’t happen over a month or even a year, either.

ClearCrawler at the 2019 Hackaday Superconference

For those keeping score, his talk at the 2019 Hackaday Superconference, “Strandbeests: From Impossible Build to Dominating My Garage” is the culmination of over six years of experimentation and iteration.

His first builds could barely move, and when they did, it wasn’t for long. But the latest version, which he demonstrated live in front of a packed audience at the LA College of Music, trotted across the stage with an almost otherworldly smoothness. To say that he’s gotten good at building these machines would be something of an understatement.

Jeremy’s talk is primarily focused on his Strandbeest creations, but it’s also a fascinating look at how a person can gradually move from inspiration to mastery through incremental improvements. He could have stopped after the first, second, or even third failure. But instead he persisted to the point he’s an expert at something he once believed was out of his reach.

Continue reading “Jeremy Cook Is Living His Strandbeest Dream”

Linux Fu: Leaning Down With Exec

Shell scripting is handy and with a shell like bash it is very capable, too. However, shell scripting isn’t always very efficient. Think about it. If you run grep or tr or sort to do some operation in a shell script, you are spawning a whole new process. That takes time and resources. But there are some answers to reducing — but not eliminating — the problem.

Have you ever written a program like this (in any language, but I’ll use C):

int foo(void)
{
  ...
  bar();

}

You hope the compiler doesn’t write assembly code like this:

_foo: 
....

      call _bar
      ret

Most optimizers should pick up on the fact that you can convert a call like this to a jump and let the ret statement in _bar return to foo’s caller. However, shell scripts are not that smart. If you have a shell script called MungeData and it calls another program or shell script called PostProcess on its last line, then you will have at one time three processes in play: your original shell, the shell running MungeData, and either the PostProcess program or a shell running the script. Not to mention, the processes to do things inside post process. So what do you do?

Continue reading “Linux Fu: Leaning Down With Exec”

36C3: All Wireless Stacks Are Broken

Your cellphone is the least secure computer that you own, and worse than that, it’s got a radio. [Jiska Classen] and her lab have been hacking on cellphones’ wireless systems for a while now, and in this talk gives an overview of the wireless vulnerabilities and attack surfaces that they bring along. While the talk provides some basic background on wireless (in)security, it also presents two new areas of research that she and her colleagues have been working on the last year.

One of the new hacks is based on the fact that a phone that wants to support both Bluetooth and WiFi needs to figure out a way to share the radio, because both protocols use the same 2.4 GHz band. And so it turns out that the Bluetooth hardware has to talk to the WiFi hardware, and it wouldn’t entirely surprise you that when [Jiska] gets into the Bluetooth stack, she’s able to DOS the WiFi. What this does to the operating system depends on the phone, but many of them just fall over and reboot.

Lately [Jiska] has been doing a lot of fuzzing on the cell phone stack enabled by some work by one of her students [Jan Ruge] work on emulation, codenamed “Frankenstein”. The coolest thing here is that the emulation runs in real time, and can be threaded into the operating system, enabling full-stack fuzzing. More complexity means more bugs, so we expect to see a lot more coming out of this line of research in the next year.

[Jiska] gives the presentation in a tinfoil hat, but that’s just a metaphor. In the end, when asked about how to properly secure your phone, she gives out the best advice ever: toss it in the blender.

Parallel Pis For Production Programming; Cutting Minutes And Dollars Off Of Assembly

Assembly lines for electronics products are complicated beasts, often composed of many custom tools and fixtures. Typically a microcontroller must be programmed with firmware, and the circuit board tested before assembly into the enclosure, followed by functional testing afterwards before putting it in a box. These test platforms can be very expensive, easily into the tens of thousands of dollars. Instead, this project uses a set of 12 Raspberry Pi Zero Ws in parallel to program, test, and configure up to 12 units at once before moving on to the next stage in assembly.

Continue reading “Parallel Pis For Production Programming; Cutting Minutes And Dollars Off Of Assembly”

Image Sensor From Discrete Parts Delivers Glorious 1-Kilopixel Images

Chances are pretty good that you have at least one digital image sensor somewhere close to you at this moment, likely within arm’s reach. The ubiquity of digital cameras is due to how cheap these sensors have become, and how easy they are to integrate into all sorts of devices. So why in the world would someone want to build an image sensor from discrete parts that’s 12,000 times worse than the average smartphone camera? Because, why not?

[Sean Hodgins] originally started this project as a digital pinhole camera, which is why it was called “digiObscura.” The idea was to build a 32×32 array of photosensors and focus light on it using only a pinhole, but that proved optically difficult as the small aperture greatly reduced the amount of light striking the array. The sensor, though, is where the interesting stuff is. [Sean] soldered 1,024 ALS-PT19 surface-mount phototransistors to the custom PCB along with two 32-bit analog multiplexers. The multiplexers are driven by a microcontroller to select each pixel in turn, one row and one column at a time. It takes a full five seconds to scan the array, so taking a picture hearkens back to the long exposures common in the early days of photography. And sure, it’s only a 1-kilopixel image, but it works.

[Sean] has had this project cooking for a while – in fact, the multiplexers he used for the camera came up as a separate project back in 2018. We’re glad to see that he got the rest built, even with the recycled lens he used. One wonders how a 3D-printed lens would work in front of that sensor.

Continue reading “Image Sensor From Discrete Parts Delivers Glorious 1-Kilopixel Images”

VGA Signal In A Browser Window, Thanks To Reverse Engineering

Epiphan VGA2USB LR VGA-to-USB devices

[Ben Cox] found some interesting USB devices on eBay. The Epiphan VGA2USB LR accepts VGA video on one end and presents it as a USB webcam-like video signal on the other. Never have to haul a VGA monitor out again? Sounds good to us! The devices are old and abandoned hardware, but they do claim Linux support, so one BUY button mash later and [Ben] was waiting patiently for them in the mail.

But when they did arrive, the devices didn’t enumerate as a USB UVC video device as expected. The vendor has a custom driver, support for which ended in Linux 4.9 — meaning none of [Ben]’s machines would run it. By now [Ben] was curious about how all this worked and began digging, aiming to create a userspace driver for the device. He was successful, and with his usual detail [Ben] explains not only the process he followed to troubleshoot the problem but also how these devices (and his driver) work. Skip to the end of the project page for the summary, but the whole thing is worth a read.

The resulting driver is not optimized, but will do about 7 fps. [Ben] even rigged up a small web server inside the driver to present a simple interface for the video in a pinch. It can even record its output to a video file, which is awfully handy. The code is available on his GitHub repository, so give it a look and maybe head to eBay for a bit of bargain-hunting of your own.

At Three Grand A Tail Light, There’s An Opportunity For A Hacker

It can be amusing sometimes, to read an incredulous reaction from outside our community to something that would be bread-and-butter in most hackerspaces. Take the sorry saga of the Cadillac XLR tail light, as reported by Jalopnik. This car was a more-expensive Corvette with a bit of lard around its midriff, and could appear a tempting pick for a bit of inexpensive luxury rubber-burning were it not for the revelation that a replacement second-hand tail light for one of these roadsters can set you back as much as three grand. The trusty auto on the drive outside where this is being written cost around a tenth that sum, so what on earth is up? Is it because a Caddy carries some cachet, or is something else at play?

It appears that the problem lies in the light’s design. It’s an LED unit, with surface mount parts and a set of fragile internal PCBs that are coated in something that makes reworking them a challenge. On top of that, the unit is bonded together, and instead of being a traditional on-off tail light it’s a microprocessor-controlled device that gets its orders digitally. This is all too much for XLR owners and for the Jalopnik hacks, who castigate General Motors for woefully inadequate design and bemoan the lack of alternatives to the crazy-expensive lights, but can’t offer an alternative.

Reading about the problem from a hardware hacker perspective they are right to censure the motor manufacturer for an appalling product, but is there really nothing that can be done? Making off-the-shelf microcontroller boards light up LEDs is an elementary introduction project for our community, and having the same boards talk to a car’s computer via CAN is something of a done deal. Add in LED strips and 3D printing to create a new backing for the tail light lens, and instead of something impossibly futuristic, you’re doing nothing that couldn’t be found in hackerspaces five years ago.

So what’s to be learned from the Cadillac XLR tail light? First of all, there’s scope for an enterprising hacker to make a killing on a repair kit for owners faced with a three grand bill. Then, there’s another opportunity for us to be acquainted with the reality that the rest of the world hasn’t quite caught up with repair culture as we might imagine. And finally there’s the hope that a badly designed automotive component might just be the hook by which the issue of designed-in obsolescence moves up the agenda in the public consciousness. After all, there will be other similar stories to come, and only bad publicity is likely to produce a change in behavior.

Of course, to get it really right you need a car that’s hackable in the first place. Or better still, one designed by and for hackers.

Thanks [str-alorman] for the tip.

Cadillac XLR header image:Rudolf Stricker [CC BY-SA 3.0].