Open-source software has gone a long way into making modern technology the way it is today. The Linux kernel alone is almost single-handedly holding up the entire Internet, and various other open-source projects allow for more access to computing resources not just because the software is often free, but because it’s possible to look under the hood and modify it for specific needs. Without open-source software available we often run into problems both expected, such as software licensing costs, and unexpected, which often come up because a developer can’t or won’t fix issues or add features. To that end, a group at Ghent University in Belgium are attempting to rectify a problem with the ESP32 by eliminating one of its binary blobs and replacing it with an open source driver.
The ESP32 is famously a low-cost microcontroller with on-board wireless capabilities, but its Wi-Fi functionality currently relies on closed-source software from Espressif. The team is currently working on building a fully working open-source networking stack with the hopes of enabling greater flexibility of these devices but also making things like security auditing possible. The other major goal is to improve low-cost mesh networking which is currently not available with the proprietary driver. Reverse engineering is the name of the game here, both from a hardware and a software level, but current versions of the software already able to send and receive packets.
The source code for the project is available on the team’s GitHub page for any open-source aficionados to take a look at. We certainly hope the project gains some steam, as any new open source project helps all of us using the platform. Open source projects frequently get stymied by a single or small handful of binary blobs too, often with little hope for recourse. Examples include Android being an open-source operating system but generally using the closed-source Google Play suite in practice, or Firefox including support for Adobe Flash. Another great example is that even computers running 100% open-source code once they boot their operating systems, there’s still some black boxes running in the background few of us think about.
Thanks to [Crote] for the tip!
In an interesting step for anyone who follows electric car technology, the automaker Tesla has released a trove of information about its first-generation Roadster car into the public domain. The documents involved include service manuals, circuit diagrams, and technical details, and Elon Musk himself
Tweeted posted on X that “All design & engineering of the original @Tesla Roadster is now fully open source.”
We like the idea and there’s plenty of interesting stuff there, but we can’t find an open-source licence anywhere and we have to take issue with his “Whatever we have, you now have” comment. What we have is useful maintenance information and presents a valuable window into 2010’s cutting edge of electric vehicles, but if it’s everything they have then something must have gone very wrong in the Tesla archives. It’s possible someone might take a Lotus Elise and produce something close to a Roadster replica with this info, but it’s by no means enough to make a car from. Instead we’re guessing it may be a prelude to reducing support for what is a low-production car from over a decade ago.
When it comes to electric vehicle manufacturers open-sourcing their older models we already have a model in the form of Renault’s open-source version of their Twizy runabout. This is a far more credible set of information that can be used to make a fully open-source version of the car, rather than a set of workshop manuals.
Tesla Roadster, cytech, CC BY 2.0.
DIY e-bikes are often easy to spot. If they’re not built out of something insane like an old washing machine motor, the more subtle kits that are generally used still stand out when compared to a non-assisted bike. The motors tend to be hub- or mid-drive systems with visible wires leading to a bulky battery, all of which stand out when you know what to look for. To get a stealthy ebike that looks basically the same as a standard bicycle is only possible with proprietary name-brand solutions that don’t lend themselves to owner repair or modification, but this one has at least been adapted for use with an open source motor controller.
The bike in use here is a model called the Curt from Estonian ebike builder Ampler, which is notable in that it looks indistinguishable from a regular bicycle with the exception of the small 36-volt, 350-watt hub motor somewhat hidden in the rear wheel. [BB8] decided based on no reason in particular to replace the proprietary motor controller with one based on VESC, an open-source electric motor controller for all kinds of motors even beyond ebikes. Installed on a tiny Arduino, it fits inside the bike’s downtube to keep the stealthy look and can get the bike comfortably up to around 35 kph. It’s also been programmed to turn on the bike’s lights if the pedals are spun backwards, and this method is also used to change the pedal assist level, meaning less buttons and other user-interface devices on the handlebars. Continue reading “An Open-Source Ebike Motor Controller”
[Max Woolf] has been working in the AI space since 2015, and among other work has created numerous useful open-source tools. He also recently wrote a thoughtful blog post that attempts to put into words his feelings on the state of things in the wake of experiencing a bit of an AI backlash-related burnout. Essentially, people effortlessly creating vast amounts of bad AI content has caused a bigger problem than we may realize.
How so? Well, Sturgeon’s law (summarized as “ninety percent of everything is crud”) applies to AI as much as it does to anything else. Theodore Sturgeon was a science fiction author and critic (and writer of multiple Star Trek episodes) who observed in the 1950s that while Science Fiction — the hot new popular thing at the time — was often derided by critics as being little more than low quality pap, so was everything else. It was true that most Science Fiction was garbage. But most work in other fields was of similarly low quality, and thus Science Fiction was really no different. It’s all trash, except for the parts one likes. Just like anything else.
What makes this observation particularly applicable to the current AI landscape is that, according to [Max], the incredible ease of use makes AI’s “ninety percent crud” very large indeed, and the attached backlash is similarly big. The remaining ten percent of AI that is absolutely fantastic and full of possibilities? It’s practically invisible due to how quickly the industry is moving, the speed with which the big players are vying to control it, and how unfashionable it has become to admit one is using AI tools at all.
[Max] knows the scene better than most. One of his projects is simpleaichat, a tool aimed not just at enabling people to integrate AI into projects easier, but piercing the hype around AI to more easily reveal just how these tools actually work. Sadly, a general AI backlash has made developing these tools feel rather less rewarding than it once did.
This week starts out with a nifty vulnerability in the glibc dynamic loader. This is an important step in running a binary executable on Linux, as it pulls the list of required shared libraries, and loads those libraries into memory. Glibc also includes a feature to adjust some runtime settings, via the GLIBC_TUNABLES environment variable. That’s where the vulnerability resides, and researchers from Qualsys obviously had a bit of fun in taking inspiration to pick the vulnerability name, “Looney Tunables”.
The problem is memory handling in the sanitizing parser. This function iterates through the environment variable, looking for strings of
tunable1=aa, separated by colons. These strings get copied to the sanitized buffer, but the parsing logic goes awry when handling the malformed
tunable1=tunable2=AAA. The first equals sign is taken at face value, copying the rest of the string into the buffer. But then the second equals sign is also processed as another
key=value pair, leading to a buffer overflow.
The reason this particular overflow is interesting is that if the binary to be run is a Set-User-ID (SUID) root application, the dynamic loader runs as root, too. If the overflow can achieve code execution, then it’s a straightforward privilege escalation. And since we’re talking about it, you know there’s a way to execute code. It turns out, it’s possible to overwrite the pointer to the library search path, which determines where the dynamic loader will look for libraries. Tell it to look first in an attacker-controlled location, and you can easily load a malicious
libc.so for instant code execution.
This vulnerability affects many Linux distros, and there’s already a Proof of Concept (PoC) published. So, it’s time to go check for updates for cve-2023-4911. Continue reading “This Week In Security: Looney Tunables, Not A 0-day*, And Curl Warning”
As with many things in life, motivation is everything. This also applies to the development of software, which is a field that has become immensely important over the past decades. Within a commercial context, the motivation to write software is primarily financial, in that a company’s products are developed by individuals who are being financially compensated for their time. This is often different with Free and Open Source Software (FOSS) projects, where the motivation to develop the software is in many cases derived more out of passion and sometimes a wildly successful hobby rather than any financial incentives.
Yet what if financial incentives are added by those who have a vested interest in seeing certain features added or changed in a FOSS project? While with a commercial project it’s clear (or should be) that the paying customers are the ones whose needs are to be met, with a volunteer-based FOSS project the addition of financial incentives make for a much more fuzzy system. This is where FOSS projects like the Zig programming language have put down their foot, calling FOSS bounties ‘damaging’.
Continue reading “Do Bounties Hurt FOSS?”
One of the best things about open source software is that, instead of being lost to the ravages of time like older proprietary software, anyone can dust off an old open source program and bring it up to the modern era. PyOBD, a python tool for interfacing with the OBD system in modern vehicles, was in just such a state with its latest version still being written in Python 2 which hasn’t had support in over three years. [barracuda-fsh] rewrote the entire program for Python 3 and included a few other upgrades to it as well.
Key feature updates with this version besides being completely rewritten in Python 3 include enhanced support for OBD-II commands as well as automating the detection of the vehicle’s computer capabilities. This makes the program much more plug-and-play than it would have been in the past. PyOBD now also includes the python-OBD library for handling the actual communication with the vehicle, while PyOBD provides the GUI for configuring and visualizing the data given to it from the vehicle. An ELM327 adapter is required.
With options for Mac, Windows, or Linux, most users will be able to make use of this software package provided they have the necessary ELM327 adapter to connect to their vehicle. OBD is a great tool as passenger vehicles become increasingly computer-driven as well, but there are some concerns surrounding privacy and security in some of the latest and proposed versions of the standard.