A phone running the XFCE desktop environment is placed on a desk, with a wireless keyboard in front of it.

Linux On Android Provides Inexpensive, Powerful Computing

In some parts of the world it’s common for cell service providers to sell new phones at a price significantly below market value, with the caveat that these phones are locked to that service provider alone. It’s questionable whether this practice is good for consumers, but as [Gabriel Broussard Korr] notes, it’s an opportunity for hackers: since it’s possible to run a Linux environment on these phones, they make an inexpensive source of quite powerful computing hardware.

In this case, [Gabriel] was using the Moto G Power 2024, which has 128 GB of storage, 12 GB of RAM, and costs less than $50 when carrier-locked. Rather than trying to install a mobile-oriented Linux distribution (such as postmarketOS), [Gabriel] installed Termux, a terminal emulator which provides a Linux environment within Android. Before doing this, he set up the phone and configured a number of settings for a better Linux experience. Since automatic updates can interfere with these settings, and since none of the provided settings effectively disable these, he used NetGuard to block Internet access from the updater app and from Google Play services.

The next step was to actually install Termux, as well as an X11 extension and an app which exposes an API for Termux. The desktop environment (XFCE in this case) was installed through Termux, and [Gabriel] wrote a shell script to go through the steps of starting it. XFCE worked well on mobile devices because of its full-desktop zoom capability. Even running Linux indirectly, the experience was smooth; [Gabriel] found that GIMP, Shotcut, and VS Code all performed well.

It’s not quite the same set of software, but we’ve previously featured a guide to setting up a similar Linux environment using Termux and AnLinux. Lindroid provides a similar containerized Linux environment; on the other hand, you can also use postmarketOS to make a server from an old phone.

This Week In Security: AI Generated Reports, More AI Generated Reports, GitHub Chaos, And More Linux Vulnerabilities

Google’s Project Zero demonstrates a new zero-click exploit for the Pixel 10 phones, showing a full escalation from remote to kernel without user interaction. During the investigation Project Zero found unprotected memory access from userspace in the Tensor G5 video processing chip driver, which allows direct write access to kernel memory.

Using previously discovered flaws in media decoding components — in this case CVE-2025-54957 in the Dolby digital audio decoder — Project Zero modified a Pixel 9 attack to work on the Pixel 10, despite newer protections built into the hardware to harden the system against memory corruption.

The author’s takeaway is mixed. Once the bug on Pixel 9 was reported, one could hope that the Android team would look into similar bugs in their newer systems. On the positive side, though, Project Zero reported the vulnerabilities to the Android team in November 2025 and they were patched in February of 2026, 71 days later. That’s 19 days short of the 90-day timeline.

Continue reading “This Week In Security: AI Generated Reports, More AI Generated Reports, GitHub Chaos, And More Linux Vulnerabilities”

This Week In Security: Android Exposes ADB, ShinyHunters Get Paid, Robot Dogs, And More

Google has patched an Android ADB bug in the May security patch set. If you have a Pixel phone you should already have the patches, and most other major manufacturers should be close behind. Unfortunately, the biggest risk from this patch will be to the vendors who are also the least likely to release timely – or any – security updates.

ADB, the Android Debug Bridge, is the main tool for installing apps during development and debugging apps while they’re running. It can also be used to side-load apps from a PC. While most normal users are unlikely to ever enable it, developers typically do and some power users might when jailbreaking a device or setting parameters not exposed in the Android UI. Debugging can be done locally via USB, or optionally over the network. To protect the device, the user must unlock the Android device and authorize each new debug agent.

Covered by Risky.Biz, a bug introduced in 2020, and present in every Android release since, allowed bypassing authorization entirely if network debugging was enabled and at least one connection had been made to the ADB service in the past. This happens because ADB compares the certificate of the incoming debug connection with the list of saved certificates. If the certificate type does not match — for instance supplying an Ed25519 certificate instead of a RSA certificate — ADB has been incorrectly handling the error code, and allowing the connection.

In most programming languages, false is considered zero, and true is considered anything not zero. The certificate API returns a 1 for a valid match, a zero for an invalid match, and a negative-one for a type mismatch. Negative one is not zero, so when treated as a boolean value, it becomes true.

To exploit the bug, ADB must be enabled in wireless mode, and there must be at least one trusted device in the ADB configuration. For the average user this is an unlikely combination, but for developers, the time to update is now.

Continue reading “This Week In Security: Android Exposes ADB, ShinyHunters Get Paid, Robot Dogs, And More”

This Week In Security: Flatpak Fixes, Android Malware, And SCADA Was IOT Before IOT Was Cool

Rowhammer attacks have been around since 2014, and mitigations are in place in most modern systems, but the team at gddr6.fail has found ways to apply the attack to current-generation GPUs.

Rowhammer attacks attach the electrical characteristics of RAM, using manipulation of the contents of RAM to cause changes in the contents of adjacent memory cells. Bit values are just voltage levels, after all, and if a little charge leaks across from one row to the next, you can potentially pull a bit high by writing repeatedly to its physical neighbors.

The attack was used to allow privilege escalation by manipulating the RAM defining the user data, and later, to allow reading and manipulation of any page in ram by modifying the system page table that maps memory and memory permissions. By 2015 researchers refined the attack to run in pure JavaScript against browsers, and in 2016 mobile devices were shown to be vulnerable. Mitigations have been put in place in physical memory design, CPU design, and in software. However, new attack vectors are still discovered regularly, with DDR4 and DDR5 RAM as well as AMD and RISC-V CPUs being vulnerable.

The GDDR6-Fail attack targets the video ram of modern graphics cards, and is able to trigger similar vulnerabilities in the graphics card itself, culminating in accessing and changing the memory of the PC via the PCI bus and bypassing protections.

For users who fear they are at risk — most likely larger AI customers or shared hosting environments where the code running on the GPU may belong to untrusted users — enabling error correcting (ECC) mode in the GPU reduces the amount of available RAM, but adds protection by performing checksums on the memory to detect corruption or bit flipping. For the average home user, your mileage may vary – there’s certainly easier ways to execute arbitrary code on your PC – like whatever application is running graphics in the first place!

Continue reading “This Week In Security: Flatpak Fixes, Android Malware, And SCADA Was IOT Before IOT Was Cool”

Google Unveils New Process For Installing Unverified Android Apps

It’s no secret that Google really doesn’t like it that people are installing Android applications from any other source than the Play Store. Last year they proposed locking everyone into their official software repository by requiring all apps to be signed by verified developers, an identity which would be checked against a Google-maintained list. After a lot of pushback a so-called ‘advanced flow’ for installing even unsigned APKs would be implemented, and we now know how this process is supposed to work.

Instead of the old ‘allow installing from unknown sources’ toggle, you are now going to have to dig deep into the Developer Options, to tap the Allow Unverified Packages setting and confirm that nobody is forcing you to do this. This starts a ‘security delay’ of twenty-four hours after you restart the device, following which you can finally enable the setting either temporarily or permanently. It would seem these measures are in place to make it more difficult for a scammer to coerce a user into installing a malicious app — whether or not that’s a realistic concern or not, we’re not sure.

When we last covered this issue this ‘advanced flow’ had just been introduced as an appeasement option. In addition to this a limited free developer account was also pitched, which now turns out to allow for up to only 20 device installations. If you want more than this, you have to pay the $25 fee and provide your government ID.

Although Google’s public pitch is still that this is ‘for user security’, it will also mean that third-party app stores are swept up in these changes, with developers who publish on these stores subject to the same verification rules. This means that Android users will have to learn quickly how to enable this new option as it will be rolled out to more countries over the coming months.

The reality is that scammers will simply work around this issue by buying up already verified developer accounts. At the same time, it’ll cripple third-party app stores and indie developers who had intended to distribute their Android app by simply providing an APK download.

What Is A Computer?

On the podcast, [Tom] and I were talking about the new generation of smartphones which are, at least in terms of RAM and CPU speed, on par with a decent laptop computer. If so, why not just add on a screen, keyboard, and mouse and use it as your daily driver? That was the question posed by [ETA Prime] in a video essay and attempt to do so.

Our consensus was that it’s the Android operating system holding it back. Some of the applications you might want to run just aren’t there, and on the open side of the world, even more are missing. Is the platform usable if you can’t get the software you need to get your work done?

But that’s just the computer-as-a-tool side of the equation. The other thing a computer is, at least to many of our kind of folk, is a playground. It’s a machine for experimenting with, and for having fun just messing around. Android has become way too polished to have fun, and recent changes on the Google side of things actively prevent you from installing arbitrary software. The hardware is similarly too slimmed-down to allow for experimentation.

Looking back, these have been the same stumbling blocks for the last decade. In 2018, I was wondering aloud why we as a community don’t hack on cell phones, and the answer then was the same as it is now – the software is not friendly to our kind. You can write phone apps, and I have tried to do so, but it’s just not fun.

The polar opposites of the smartphone-as-computer are no strangers in our community. I’m thinking of the Linux single-board computers, or even something like a Steam Deck, all of which are significantly less powerful spec-wise than a flagship cell phone, but which are in many ways much more suitable for hacking. Why? Because they make it easy to do the things that we like to do. They’re designed to be fun computers, and so we use them.

So for me, a smartphone isn’t a computer, but oddly enough it’s not because of the hardware. It’s because what I want out of a computer is more than Turing completeness. What I want is the fun and the freedom of computering.

Hackaday Links Column Banner

Hackaday Links: February 22, 2026

We’ll start things off this week with some breaking news from NASA: just days after the space agency announced the Artemis II crew was preparing to blast off towards the Moon as soon as March 6th, a new problem with the Space Launch System rocket has pushed the launch back indefinitely. According to NASA Administrator Jared Isaacman, problems encountered while loading helium into the Interim Cryogenic Propulsion Stage (ICPS) necessitate rolling the massive rocket back to the Vehicle Assembly Building (VAB) for diagnosis and repair.

The logistics of shuffling the vehicle 6.8 kilometers (4.2 miles) from the pad to the VAB is going to eat up at least a week, and sending it back the other way is naturally just as much of a production. Add in the time they’ll need to actually figure out what’s wrong with the ICPS and make the necessary repairs, and it’s easy to see why a March launch is almost certainly off the table. It’s frustrating to see the Artemis II mission get delayed this close to launch, but sending humans into space isn’t the sort of thing you can cut corners on.

Continue reading “Hackaday Links: February 22, 2026”