Image

Trying To Get Linux Running On A Nokia E6

The Nokia E6 is a smartphone from back in the old days when Symbian was a thing. [fluffleswaffled] has been doing the work to get the ancient handset running Linux instead, because that’s ultimately cooler than what the phone shipped with out of the box.

There isn’t an unlocked bootloader on the E6, so instead, [fluffleswaffled] used an altogether different route to boot Linux. A Symbian app is used to load the kernel and device tree into RAM, at which point the MMU and caches are turned off and the device jumps into Linux. It’s a one-way trip, from which there is no way back to Symbian without a power cycle. The setup nets a terminal on the phone’s own screen, and the hardware keyboard and touchscreen are functional. The display is controlled by a Broadcom VideoCore III, with [fluffleswaffled] capturing messages from Nokia’s original display driver to create a custom kernel driver that replays them.

There’s an issue, though. The phone doesn’t stay in Linux land for long — it always resets within a couple minutes of booting into the alternative OS. [fluffleswaffled] believes this is because the phone’s baseband chip is supervising the application processor, and killing things once it’s detected that the Symbian mobile stack has stopped running. They’re hoping that someone with experience with Nokia basebands or the relevant hardware can point them in the right direction to get this hack running for more than 3.5 minutes at a time.

There probably isn’t a great deal of utility in getting Linux running on a 2011 smartphone, but we love the hustle nonetheless. We’ve seen this done before, though, and it’s always interesting to learn what it takes to get the OS booting on a new platform. If you’re whipping up similar hacks in your home lab, don’t hesitate to let us know on the tipsline.

Image

Meshtastic Sniffer For DragonOS

Meshtastic has gained a lot of popularity over the last few years thanks to its low barrier of entry. No licenses are needed and the hardware is dirt cheap, at least when compared to a lot of ham radio gear. But while that physical barrier is low, there is a bit of a learning curve. Part of that comes from the fact that there are a lot of channels and modes that people could be communicating on, and unless the user knows that information up front it can be hard to find where the conversations are happening. [cemaxecuter] noticed this problem and built a Meshtastic sniffer into his radio-forward Linux distribution, DragonOS.

The sniffing software is built in C and comes as a complete standalone binary and does not rely on GNU Radio. With DragonOS up and running and the software loaded, it can look at the entire bandwidth that Meshtastic operates on and detect any traffic and decode it (as long as the key is known). [cemaxecuter] is using a HackRF as a software-defined radio for this project, which he notes doesn’t quite have enough bandwidth to cover every Meshtastic operating frequency, but it can get most of them. After firing up his own node, the software quickly detects it and shows its details in the terminal.

Software like this opens up a lot of opportunities for things that would be tedious, difficult, or impossible to do with with a standard Meshtastic node. Besides finding places where conversations are happening more easily, [cemaxecuter] also suggests that it could be used for wardriving and for locating or finding other networks much more easily. For those who still haven’t tried it out, take a look at this 2023 treatise on the protocol and hardware and then dive right in.

Continue reading “Meshtastic Sniffer For DragonOS” →

Image

This Week In Security: New Spectre Attacks, Crushing Quantity Of Linux Vulns, Google Gets Too Much AI, And Hacking Lawnmowers

Just-in-time, or JIT, compilation could be considered a fundamental backbone of modern computing.  JIT compilation turns scripting languages like JavaScript or intermediary binary forms like Web Assembly into native code on the fly, giving web apps, and things that are web apps under the covers like Electron-based tools, near native speed.  A new paper explores leveraging JIT systems to revive Spectre-v2 attacks against processors.

Most modern processors gain performance by using a trick called “speculative execution”.  The processor guesses the likely result of a compare, and begins executing some of the next instructions before the results are actually known.  If the processor guessed right, things continue and there is a speed gain because it can jump ahead, but if the processor guessed wrong, any instructions that were run and any side effects of running them are discarded and execution resumes on the actual path.  In theory, anyhow.

In practice, the Spectre class of attacks targets branch prediction. It was discovered that when the wrong branch was chosen, not all of the results were truly hidden; Patterns of failures in guessing branches can be used to leak behavior processing encryption keys and other activities. The attacks evolved with the research dubbed Spectre-V2, which showed that non-privileged contexts, like non-root users and virtual machines, could poison the instruction prediction and use it to read arbitrary memory.  Fixes to the Linux kernel and other platforms were required to mitigate the worst of the effects.

The paper shows that by using self-modifying code in the JIT, the processor can be tricked into loading cached versions of the instructions.  The fixes to the kernel to prevent Spectre attacks include identifying malicious code patterns that attack the branch prediction, and stopping or changing them:  By causing the CPU to execute the cached copy of instructions instead of the live copy, the attack ignores the fixed instructions entirely and can attack the branch prediction algorithm.

To prove the attack is feasible in the real world, the researchers targeted several JIT compilers, including the SpiderMonkey JavaScript engine used by Firefox, the eBPF JIT found in the Linux kernel, and GraalVM, the JIT used in Python.  They found success with each, demonstrating that the attack is at least plausible.

Research like this is unlikely to be an instant world-melter, and will help find possible mitigations in the future to prevent these sorts of attacks.  Operating systems that support a high-security “lock-down” mode, like macOS and iOS, often disable JIT entirely, out of concern about these sorts of attacks.  There’s probably no need to start disabling JIT on every system, but attacks like these have a tendency to evolve.

Continue reading “This Week In Security: New Spectre Attacks, Crushing Quantity Of Linux Vulns, Google Gets Too Much AI, And Hacking Lawnmowers” →

Image

No More Windows For The Dutch Government, Ze Kiezen Nu Linux

The events of the last few years have caused many in Europe to re-evaluate their reliance on large offshore technology companies, with a corresponding move to home-grown EU-based alternatives. It’s one thing when individuals or companies do this, but another entirely when it’s an entire country. So the news that the Netherlands is building their own Linux distribution to replace Microsoft Windows in government installations, is not inconsequential. The Tweakers site linked  actively breaks out of Google Translate, so you may have to rely on your browser’s translation tool if you are not a Dutch speaker.

The Digitaal Autonome Werkomgeving Overheid, or Digital Autonomous Work Environment, is a distro based upon NixOS, itself originally a product of a Dutch university. It comes complete with all the office and collaboration applications needed to replace Windows, and is reported to have been tested already by a small group of Dutch government workers.

The influence of this move is likely to be a huge one for Microsoft, given that governments have huge numbers of operating system seats. But perhaps more important than the OS itself are the extras that Microsoft would like to sell to its OS customers, such as AI services. We’d expect that there will be managers in Redmond paying close attention to Europe in the wake of this move.

Meanwhile the Netherlands has a vibrant hacker community, and we can imagine that this move will be welcomed in those quarters. All Netherlands government online services are accessed through an ID verification app called DigID, and it’s a lament we’ve heard from our Dutch friends that this only works with Windows, Android and Apple platforms. If this means a Linux version will appear on the back of an NL government Linux distro, we know some people who will be very happy indeed.

NL flag: SpinnerLaserzthe2nd, CC0. Tux: Larry Ewing (lewing@isc.tamu.edu) and The GIMP. Attribution.

Hackaday Links Column Banner

Hackaday Links: September 27, 2026

It isn’t quite hailing frequencies open, but researchers from Harvard claim they’ve picked up a radio signal directly from a nearby exoplanet. Before you get too excited, planets in our solar system also emit RF, so no one credible is claiming these are extraterrestrial reruns of their version of I Love Lucy, but it is the first time they’ve localized a radio signal to an exoplanet, in this case, Beta Pictoris B.

Speaking of space, the asteroid formerly known as 1981 EC26 is now sporting a new moniker: (14331) Alyankovic. If you think that sounds like (Weird) Al Yankovic, you aren’t wrong. The Tucson Star reports that, thanks to the efforts of several planetary scientists who are also Weird Al fans, the International Astronomical Union made the name official. Apparently, another asteroid now bears a name in honor of Weird Al’s predecessor, Tom Lehrer.

Image
The postmarketOS — er — Nura logo.

If you follow open mobile phone software, you probably know the name postmarketOS, a Linux distribution based on Alpine aimed at mobile phones and tablets. Well, now you can forget it. The project announced a name change, so we’re now talking about Nura. Why Nura? According to the team, it is a shortened form of Nuraghe, some granite structures in Sardinia that are over 5,000 years old. The FAQ mentions that postmarketOS was hard to remember. We aren’t sure Nura is that much more memorable. Perhaps they should have pivoted to Phonz OS.

Continue reading “Hackaday Links: September 27, 2026” →

Image

How Pixar Stopped Worrying And Learned To Love Linux

If you weren’t already aware, it will probably come as no surprise to hear that the pioneering computer-animation studio Pixar built its early workflow on Silicon Graphics SGI workstations. These were beefy Unix machines that, as the name implied, were developed for graphical work. When the age of the RISC workstation came to a close, many Unix users were pushed onto Windows NT — but not at Pixar. At Pixar, they learned to love the penguin.

It comes down to hardware rather than software. You know the story: PCs got faster and cheaper with different vendors competing for a giant market, while the world of RISC workstations couldn’t keep its lead. Pixar would have been happy staying on Unix workstations, even SGIs if that had been a practical option — but with every project increasing the load on the render farms, it wasn’t. Yet Pixar’s entire workflow was predicated on a Unix environment. They had written a couple million lines of code for their internal use, and really didn’t want to port it over to Windows, even after a mistaken rm command nearly cost the world Toy Story 2.

The path of least resistance would be to port to something more similar to IRIX’s Unix environment, something POSIX compliant. That path led Linux, and by 2001, the port was done. By 2003, a new render farm using Xeon processors brought the whole studio to Linux and x86, which has since become an industry standard.

We’re left with only two questions: one, why didn’t more industries — like the CAD/CAM world — that were also reliant on Unix Workstations follow Pixar and Hollywood onto Linux, and two, why did Pixar go with Linux instead of some variety of BSD? [Crierlon] doesn’t address either question, but we’re betting some of you might have an idea. Let us know in the comments if you have the inside scoop; inquiring minds want to know!

Continue reading “How Pixar Stopped Worrying And Learned To Love Linux” →

Image

Running Linux 6.11 On The ESP32-S3 With A Few Tweaks

With the Xtensa Lx7 twin CPU cores in the ESP32-S3 running at a relatively zippy 240 MHz and accompanying PSRAM of up to 16 MB, you might find yourself wondering whether it could run Linux. As [Paulneja] demonstrates with Linux kernel 6.11, the answer is a ‘yes’, though with the usual caveats.

What complicates matters with the ESP32-S3 is that it lacks certain amenities that spoiled OSes like Linux have come to take for granted, such as a Memory Management Unit (MMU). To deal with this, the NOMMU Linux configuration was used, along with a custom fork() implementation. Although the previous 0.7 version sort-of worked, the current 0.8 release is the first that manages to actually boot reliably and has a usable amount of RAM available after boot.

You can see the comparison between the two versions in the header image, with v0.8 having a blistering 3.7 MB available after booting and with overall resource usage and performance having improved massively. Note that only one core is available to Linux, with the other used by the typical FreeRTOS ESP-IDF stack to provide WiFi and Bluetooth.

This was all run on an ESP32-S3 with the N16R8 configuration, meaning 16 MB Flash that’s also used for writable storage and 8 MB of octal PSRAM. As for practical applications, it’s noted by [Paulneja] that this is a research project, though one could imagine this being an embedded Linux project along the lines of a network router running something like BusyBox.