The Gorgeous Hardware We Can’t Take Our Eyes Away From

August 30, 2019 by Tom Nardi 1 Comment

High resolution digital cameras are built into half of the devices we own (whether we want them or not), so why is it still so hard to find good pictures of all the incredible projects our readers are working on? In the recently concluded Beautiful Hardware Contest, we challenged you to take your project photography to the next level. Rather than being an afterthought, this time the pictures would take center stage. Ranging from creative images of personal projects to new ways of looking at existing pieces of hardware, the 100+ entries we received for this contest proved that there’s more beauty in a hacker’s parts bin than most of them probably realize.

As always, it was a struggle to narrow down all the fantastic entries to just a handful of winners. But without further adieu, let’s take a look at the photos that we think truly blurred the line between workbench and work of art:

Continue reading “The Gorgeous Hardware We Can’t Take Our Eyes Away From” →

FiberGrid: An Inexpensive Optical Sensor Framework

August 30, 2019 by Ben James 21 Comments

When building robots, or indeed other complex mechanical systems, it’s often the case that more and more limit switches, light gates and sensors are amassed as the project evolves. Each addition brings more IO pin usage, cost, potentially new interfacing requirements and accompanying microcontrollers or ADCs. If you don’t have much electronics experience, that’s not ideal. With this in mind, for a Hackaday prize entry [rand3289] is working on FiberGrid, a clever shortcut for interfacing multiple sensors without complex hardware. It doesn’t completely solve the problems above, but it aims to be a cheap, foolproof way to easily add sensors with minimal hardware needed.

The idea is simple: make your sensors from light gates using fiber optics, feed the ends of the plastic fibers into a grid, then film the grid with a camera. After calibrating the software, built with OpenCV, you can “sample” the sensors through a neat abstraction layer. This approach is easier and cheaper than you might think and makes it very easy to add new sensors.

Naturally, it’s not fantastic for sample rates, unless you want to splash out on a fancy high-framerate camera, and even then you likely have to rely on an OS being able to process the frames in time. It’s also not very compact, but fortunately you can connect quite a few sensors to one camera – up to 216 in [rand3289]’s prototype.

There are many novel uses for this kind of setup, for example, rotation sensors made with polarising filters. We’ve even written about optical flex sensors before.

CCCamp: 5,000 Hackers Out Standing In Their Field

August 30, 2019 by Elliot Williams 12 Comments

What do hackers do on vacation? What do hackers do whenever they have free time? What do you love to do? That’s right. But how much more fun would it be if you could get together with 5,000 other hackers, share your crazy projects and ideas, eat, drink, dance, swim, and camp out all together for five days, naturally with power and Internet? That’s the idea of the Chaos Communication Camp, and it’s a once-in-four-years highlight of hacker life.

Held not too far outside of Berlin, the Camp draws heavily on hackers from Europe and the UK, but American hackers have been part of the scene since almost the beginning. (And Camp played an important role in the new-wave hackerspaces in the US, but that’s another story.) It’s one thing to meet up with the folks in your local hackerspace and work together on a project or brainstorm the next one, but it’s entirely a different thing when you’re drawing on hackers from all over the world. There was certainly more to see and do at Camp than you could in a month, not to mention in only five days, and this could be overwhelming. But if you dig in, the sense of community that came from shared effort and shared interests was the real take-home. And nearly everything at Camp should have its own article on Hackaday.

Continue reading “CCCamp: 5,000 Hackers Out Standing In Their Field” →

Hackaday Podcast 033: Decompressing From Camp, Nuclear Stirling Engines, Carphone Or Phonecar, And ArduMower

August 30, 2019 by Mike Szczys 4 Comments

Hackaday Editors Mike Szczys and Elliot Williams are back from Chaos Communication Camp, and obviously had way too much fun. We cover all there was to see and do, and dig into the best hacks from the past week. NASA has a cute little nuclear reactor they want to send to the moon, you’ve never seen a car phone quite like this little robot, and Ardupilot (Ardurover?) is going to be the lawn mowing solution of the future. Plus you need to get serious about debugging embedded projects, and brush up on your knowledge of the data being used to train facial recognition neural networks.

Take a look at the links below if you want to follow along, and as always tell us what you think about this episode in the comments!

Take a look at the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

Direct download (60 MB or so.)

Continue reading “Hackaday Podcast 033: Decompressing From Camp, Nuclear Stirling Engines, Carphone Or Phonecar, And ArduMower” →

Your Arduino SAMD21 ADC Is Lying To You

August 30, 2019 by Ted Yapo 64 Comments

One of the great things about the Arduino environment is that it covers a wide variety of hardware with a common interface. Importantly, this isn’t just about language, but also about abstracting away the gory details of the underlying silicon. The problem is, of course, that someone has to decode often cryptic datasheets to write that interface layer in the first place. In a recent blog post on omzlo.com, [Alain] explains how they found a bug in the Arduino SAMD21 analogRead() code which causes the output to be offset by between 25 mV and 57 mV. For a 12-bit ADC operating with a reference of 3.3 V, this represents a whopping error of up to 70 least-significant-bits!

Excerpt from the SAMD wiring_analog.c file in the Arduino Core repo.

While developing a shield that interfaces to 24 V systems, the development team noticed that the ADC readings on a SAMD21-based board were off by a consistent 35 mV; expanding their tests to a number of different analog pins and SAMD21 boards, they saw offsets between 25 mV and 57 mV. It seems like this offset was a known issue; Arduino actually provides code to calibrate the ADC on SAMD boards, which will “fix” the problem with software gain and offset factors, although this can reduce the range of the ADC slightly. Still, having to correct for this level of error on a microcontroller ADC in 2019 — or even 2015 when the code was written — seems really wrong.

After writing their own ADC read routine that produced errors of only between 1 mV and 5 mV (1 to 6 LSB), the team turned their attention to the Arduino code. That code disables the ADC between measurements, and when it is re-enabled for each measurement, the first result needs to be discarded. It turns out that the Arduino code doesn’t wait for the first, garbage, result to finish before starting the next one. That is enough to cause the observed offset issue.

It seems odd to us that such a bug would go unnoticed for so long, but we’ve all seen stranger things happen. There are instructions on the blog page on how to quickly test this bug. We didn’t have a SAMD21-based Arduino available for testing before press time, but if you’ve got one handy and can replicate these experiments to verify the results, definitely let us know in the comments section below.

If you don’t have an Arduino board with a SAMD21 uC, you can find out more about them here.

This Week In Security: VPN Gateways, Attacks In The Wild, VLC, And An IP Address Caper

August 30, 2019 by Jonathan Bennett 7 Comments

We’ll start with more Black Hat/DEFCON news. [Meh Chang] and [Orange Tsai] from Devcore took a look at Fortinet and Pulse Secure devices, and found multiple vulnerabilities. (PDF Slides) They are publishing summaries for that research, and the summary of the Fortinet research is now available.

It’s… not great. There are multiple pre-authentication vulnerabilities, as well as what appears to be an intentional backdoor.

CVE-2018-13379 abuses an snprintf call made when requesting a different language for the device login page. Snprintf is an alternative to sprintf, but intended to prevent buffer overflows by including the maximum string length to write to the target buffer, which sounds like a good idea but can lead to malicious truncation.

The code in question looks like snprintf(s, 0x40, "/migadmin/lang/%s.json", lang);.
When loading the login page, a request is made for a language file, and the file is sent to the user. At first look, it seems that this would indeed limit the file returned to a .json file from the specified folder. Unfortunately, there is no further input validation on the request, so a language of ../../arbitrary is considered perfectly legitimate, escaping the intended folder. This would leak arbitrary json files, but sincesnprintf doesn’t fail if it exceeds the specified length, sending a request for a lang that’s long enough results in the “.json” extension not being appended to the request either.

A metasploit module has been written to test for this vulnerability, and it requests a lang of /../../../..//////////dev/cmdb/sslvpn_websession. That’s just long enough to force the json extension to fall off the end of the string, and it is Unix convention is to ignore the extra slashes in a path. Just like that, the Fortigate is serving up any file on its filesystem just for asking nice.

More worrying than the snprintf bug is the magic value that appears to be an intentional backdoor. A simple 14 character string sent as an http query string bypasses authentication and allows changing any user’s password — without any authentication. This story is still young, it’s possible this was intended to have a benign purpose. If it’s an honest mistake, it’s a sign of incompetence. If it’s an intentional backdoor, it’s time to retire any and all Fortinet equipment you have.

Pulse Secure VPNs have a similar pre-auth arbitrary file read vulnerability. Once the full report is released, we’ll cover that as well.

Exploitation in the Wild

But wait, there’s more. Hide your kids, hide your wife. Webmin, Pulse Secure, and Fortigate are already being exploited actively in the wild, according to ZDNet. Based on reports from Bad Packets, the Webmin backdoor was being targeted in scans within a day of announcement, and exploited within three days of the announcement. There is already a botnet spreading via this backdoor. It’s estimated that there are around 29,000 vulnerable Internet-facing servers.

Both Pulse Secure and Fortinet’s Fortigate VPN appliances are also being actively targeted. Even though the vulnerabilities were reported first to the vendors, and patched well in advance of the public disclosure, thousands of vulnerable devices remain. Apparently routers and other network appliance hardware are fire-and-forget solutions, and often go without important security updates.

VLC is Actually Vulnerable This Time

The VLC media player has released a new update, fixing 11 CVEs. These CVEs are all cases of mishandling malformed media files, and are only exploitable by opening a malicious file with VLC. Be sure to go update VLC if you have it installed. Even though no arbitrary code execution has been demonstrated for any of these issues, it’s likely that it will eventually happen.

Gray Market IP Addresses

With the exhaustion of IPv4 addresses, many have begun using alternative methods to acquire address space, including the criminal element. Krebs on Security details his investigation into one such story: Residential Networking Solutions LLC (Resnet). It all started with an uptick in fraudulent transactions originating from Resnet residential IP addresses. Was this a real company, actually providing internet connectivity, or a criminal enterprise?

Arduino On MBed

August 30, 2019 by Al Williams 22 Comments

Sometimes it seems like Arduino is everywhere. However, with a new glut of IoT processors, it must be quite a task to keep the Arduino core on all of them. Writing on the Arduino blog, [Martino Facchin], Arduino’s chief of firmware development, talks about the problem they faced supporting two new boards from Nordic.

The boards, the Nano 33 BLE and Nano 33 BLE Sense are based on an ARM Cortex M4 CPU from Nordic. The obvious answer, of course, is to port the Arduino core over from scratch. However, the team didn’t want to spend the time for just a couple of boards. They considered using the Nordic libraries to interact with the hardware, but since that is closed source, it didn’t really fit with Arduino’s sensitivities. However, in the end, they took a third approach which could be a very interesting development: they ported the Arduino core to the Mbed OS. There’s even an example of loading a sketch on top of Mbed available from [Jan Jongboom].

Continue reading “Arduino On MBed” →