Getting Root Access On A Tesla

A growing number of manufacturers are locking perfectly good hardware behind arbitrary software restrictions. While this ought to be a bigger controversy, people seem to keep paying for things like printers with ink subscriptions, cameras with features disabled in firmware, or routers with speed restrictions, ensuring that this practice continues. Perhaps the most blatant is car manufacturers that lock features such as heated seats or even performance upgrades in the hopes of securing a higher price for their vehicles. This might be a thing of the past for Teslas, whose software has been recently unlocked by Berlin IT researchers.

Researchers from Technische Universität Berlin were able to unlock Tesla’s driving assistant by inducing a two-microsecond voltage drop on the processor which allowed root access to the Autopilot software. Referring to this as “Elon mode” since it drops the requirement for the driver to keep their hands on the steering wheel, they were able to access the full self-driving mode allowing autonomous driving without driver input. Although this might be a bad idea based on the performance of “full self-driving” in the real world, the hack at least demonstrates a functional attack point and similar methods could provide free access to other premium features.

While the attack requires physical access to the vehicle’s computer and a well-equipped workbench, in the short term this method might allow for owners of vehicles to use hardware they own however they would like, and in the long term perhaps may make strides towards convincing manufacturers that “features as a service” isn’t a profitable strategy. Perhaps that’s optimistic, but at least for Teslas it’s been shown that they’re not exactly the most secured system on four wheels.

Close To The Metal

Firmware is caught between hardware and software. What do I mean? Microcontroller designers compete on how many interesting and useful hardware peripherals they can add to the chips, and they are all different on purpose. Meanwhile, software designers want to abstract away from the intricacies and idiosyncrasies of the hardware peripherals, because code wants to be generic and portable. Software and hardware designers are Montagues and Capulets, and we’re caught in the crossfire.

I’m in the middle of a design that takes advantage of perhaps one of the most idiosyncratic microcontroller peripherals out there – the RP2040’s PIOs. Combining these with the chip’s direct memory access (DMA) controllers allows some fairly high-bandwidth processing, without bogging down the CPUs. But because I want this code to be usable and extensible by a wide audience, I’m also trying to write it in MicroPython. And configuring DMA controllers is just too idiosyncratic for MicroPython.

But there’s an escape hatch. In my case, it’s courtesy of the machine.mem32 function, which lets you read and write directly into the chip’s memory, including all of the memory-mapped configuration registers. Sure, it’s absurdly low-level, but it means that anything you read about in the chip’s datasheet, you can do right away, and from within the relative comfort of a Micropython program. Other languages have their PEEK and POKE equivalents as well, or allow inline assembler, or otherwise furnish you the tools to get closer to the metal without having to write all the rest of your code low level.

I’m honestly usually a straight-C or even Forth programmer, but this experience of using a higher-level language and simultaneously being able to dive down to the lowest levels of bit-twiddling at the same time has been a revelation. If you’re just using Micropython, open up your chip’s datasheet and see what it can offer you. Or if you’re programming at the configure-this-register level, check out the extra benefits you can get from a higher-level language. You can have your cake and eat it too!

Explore Linux Space Time

If you’ve ever wondered how much memory a process uses, you’ve probably used a form of task manager or system monitor. System monitors can be useful to identify resource hogs, but are often less versatile if you want more details about just one process. If you’ve ever faced this problem, then [Fabien Sanglard]’s Space-Time explorer is for you!

The wonderfully punny Space-Time tool records physical memory usage, time spent in user space vs. kernel space and even threads and subprocesses created. These words may not mean much to some readers, so let’s quickly go over them: Physical memory usage is the actual amount of RAM given (not always the same as requested). The kernel (which lives in kernel space) is the supervisor to all processes on a computer. In contrast, every process lives in it’s own “user space”, a way of protecting the kernel. Finally, a subprocess (or “child process”) is simply a process started by another process (the “parent”). Continue reading “Explore Linux Space Time”

Do Bounties Hurt FOSS?

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?”

PyOBD Gets Python3 Upgrades

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.

Open-Source Cell Phone Based On ESP32

Over the past decade or so, smartphones have exploded in popularity and seamlessly integrated themselves into nearly every aspect of most people’s lives. Although that comes with a few downsides as well, with plenty of people feeling that the smart phone makes it a little too easy to waste time and looking to switch to something simpler, like an older-style flip phone. If this style of phone is more your speed, take a look at this DIY cell phone which takes care of everything a phone really needs to do. (Google Translate from French)

The phone uses an ESP32 at its core, with a SIM800L GSM modem to interact with the cell network, including retrieving the system time. A small battery is included as well as all of the support circuitry for charging it as well as a USB interface that can communicate to a PC. The operating system for the phone is built from the ground up as well, with a touch screen interface allowing the user to make phone calls, send text messages, store contacts, and a few other basic features. There’s also a GPS application though, allowing the phone to know basic location information.

Another perk of this device is that its creator, [Gabriel], made the design schematics, print files for the case, and the operating system software completely open source for anyone to build this phone on their own. Everything is available on the project’s GitHub page. It’s a fairly remarkable achievement, especially considering [Gabriel] is only 16. And, if you’re not one to eschew modern smart phone technology there are some DIY smart phones available to build as well.

Thanks to [come2] for the tip!

An Open-Source, Free Circuit Simulator

The original circuit simulation software, called the Simulation Program with Integrated Circuit Emphasis, or SPICE as it is more commonly known, was originally developed at the University of Califorina Berkeley in the 1970s with an open-source license. That’s the reason for the vast versions of SPICE available now decades after the original was released, not all of which are as open or free as we might like. Qucs is a GPL circuit simulator. And if you want the GUI option, you might want to try out QucsStudio, which uses Qucs under the hood, and is free to use, but binary-only.

(Editor’s note: the author was confused between the GPL open-source Qucs and the closed-source, binary-only QucsStudio. We’ve cleaned that up.)

QucsStudio supports a wide range of circuit components and models much in the same fashion as other more popular SPICE programs, including semiconductor devices, passive components, and digital logic gates. Qucs also utilizes SPICE-based simulation, which can model various types of circuit behavior, such as DC, AC, transient, and small-signal analysis.

Unfortunately there are only Windows versions available, and although some might have some success running it under WINE. There are plenty of other options for those of us running non-Windows operating systems though. Here’s a review of 30 of them.

Thanks to [Electroagenda] for the tip!