Considering that it's rare to get kernel (or any) updates on non-flagship phones, it seems likely.
Backporting an old kernel should be possible, but the only indicator is the system update changelog that explicitly mentions it, I rarely see CVEs mentioned in changelogs on any smartphone. A tool to test the vulnerability is the only way.
Any compromised app on the Play store or external can get root access instantly, but we can still rely on trust and audits when installing apps which should always be the rule.
I suspect that this will be added to all Google Play integrity levels, limiting many apps from being installed on unpatched phones in the future.
That's not the case with browsers with random sites and ads which is hardly avoidable, having any sandbox escape is now more severe considering that it bypasses the app container. It's similar to JailbreakMe on iOS [0]
Google is the good actor here. 7 years of updates, unlocked bootloader, support for LineageOS, etc. The reason it sucks is all the other OEMs who don't care about anything other than the current year's models.
That's Google as the hardware OEM, not Google as the OS/platform vendor. They should be standing on Qualcomm's neck until they upstream their drivers and whatever else is necessary to make it practical for anyone to run updated kernels on their hardware, the same as it has worked for PCs for decades.
FWIW, when Windows NT was ported to mobile it also was compiled against binary blobs for specific Qualcomm SoCs. It's not an Android deficiency; what works on PCs just doesn't really work in mobile-land.
The reason it's like that is that 1990s Microsoft used carrot and stick to make the hardware vendors do the right thing and present day Google isn't doing that when they're the ones who would need to.
The alternative would be for the hardware market to be less consolidated (the government keeps allowing Qualcomm to buy up competitors) so that the chip companies would have to compete on things like this. But that's no excuse for Google to be sitting on their hands when they could fix it too.
Part of the problem I believe sits on how chip manufacturers (looking at you Qualcomm) handle device trees that should be part of upstream, but are never done due to differences in tooling/proprietary blobs which are also part of the DT. This increases the effort on the OEMs to keep comptability across kernel versions.
> I suspect that this will be added to all Google Play integrity levels, limiting many apps from being installed on unpatched phones in the future.
You do realize that a full kernel vulnerability like this allows you to feed falsified information to SafetyNet? Just like DRM, it gives the developer the illusion of control, but doesn't do anything to actually improve "safety" or "integrity".
It's silly that whenever I see a vulnerability like this, all I can think about is "finally, a way to get control over my own devices back". Once again, Stallman was right.
Personally, I'll use this to root my Android TV and Chromecast devices and remove the shitty ads in the launcher (which Google added after I bought the devices!).
Agreed, but I think this will force the average user to upgrade* their phones after losing access to sensitive apps (bank, gov) before getting compromised.
Good news for reusing old phones and taking control.
We should be fighting against SafetyNet and similar attestation systems.
The proper solution is one we had with desktop computing for decades. If you keep the key material on your eID or bank card, you don't need a locked down operating system. Which then allows devices to live for much longer.
We're slowly losing the war on General Purpose Computing.
> We should be fighting against SafetyNet and similar attestation systems.
The proper solution is one we had with desktop computing for decades. If you keep the key material on your eID or bank card
So you want a bank card/ID card to be required each time you use Google Pay? What's the point of Google Pay then.
Actually I have a better idea. What if, instead of holding my phone up to the payment terminal, the bank could give me a plastic card with an antenna and chip, that I could hold up to the payment terminal. The chip could be powered by induction from the terminal.
Maybe I could even duct-tape it to my phone if I really want to do that.
The obvious way to do this is that you need to physically attach the bank card in order to authorize a new vendor. So then when you sign up for Google Pay or Paypal or what have you, you need to get out your card -- which is good. You can't steal a physical card by breaching some other merchant it was used at.
From then your Google Pay account is authorized to initiate charges until you tell your bank otherwise and you don't need the card again unless you want to sign up for Venmo etc.
And it makes things easy if someone steals your phone, because you just sign into the payment processor and deauthorize the device or, if they've already changed your password etc., sign into (or go to) the bank and deauthorize the payment processor.
"this will force the average user to upgrade their phones"
A lot of phones don't receive any upgrades after 1 or 2 years...
I wish that Google would have forced vendors to implement a proper hardware abstraction (uefi or similar) so that a single kernel could run on any smartphone, just like it's the case for PCs...
> Agreed, but I think this will force the average user to upgrade* their phones after losing access to sensitive apps (bank, gov) before getting compromised.
The problem being that there are many millions of people who can't afford to replace a phone they only recently bought just because the vendor never updates it, which means those banks and things can't in practice demand that people do that. Indeed, it creates the opposite problem, because installing a custom ROM on that device would give it a patched kernel but cause it to fail attestation, so what the attestation is actually doing is requiring those people to continue to use the vulnerable OS.
> You do realize that a full kernel vulnerability like this allows you to feed falsified information to SafetyNet?
Are you sure that's true? The whole reason why modern Safetynet/Play Integrity uses HSM data where possible is that you can't spoof that with root (without a microcode bug). It does not trust the running OS by design
I just tried GrapheneOS's https://attestation.app/ on a stock Pixel, and all of the OS version info shows in the "hardware verified" section
There's a lot of confusion around attestation, some of which is IMO done intentionally.
First there is Android's attestation framework. That does actual hardware attestation, as used by GrapheneOS, and supported by literally no app whatsoever.
Then there is SafetyNet, now Play Integrity. Depending on what level of integrity checking is being done, this will do a combination of cursory surface-level software checks, delegation to the aforementioned hardware attestation framework, and several other checks.
Importantly, SafetyNet/Play Integrity rejects some devices that pass hardware attestation (e.g., Graphene OS), and accepts some devices that fail hardware attestation (fairphone, many cheaper devices with broken ROMs, etc).
e.g., fairphone leaked the private key for their attestation, but many of their devices still pass SafetyNet, while some other devices that pass attestation but have known bootloader flaws are blocked by SafetyNet.
Because this isn't strict cryptographic verification, but a mess of heuristics and guesswork, it's a constant cat and mouse game.
What Google really achieved here is to make it expensive enough that no casual user can bypass it to e.g. cheat in Pokemon Go, but only a determined attacker has a chance.
And with "determined attacker" I'm not just talking about states, but even e.g. movie pirates breaking DRM to rip Netflix movies.
Of course, even full cryptographic attestation isn't perfect, and can be bypassed with enough effort. As shown by the famous iPhone hardware jailbreak, where you drill into the SoC and solder directly to the CPU's internal wiring.
Tip: Install a Chromium flavor browser (Chromite) separate from the main browser.
Disable Javascript and hardware accelerated video decoder (commonly exploited) from the flags page and enable reader mode to fix broken JS-dependent websites when browsing blogs and random sites on your personal devices, else dedicate a tablet.
Thanks for testing, we currently only tested it on Pixel 10, but there are a few people on our repo creating PR to support other devices, you can take a look here https://github.com/NebuSec/CyberMeowfia
I've been noodling with porting the kernel exploit to other devices, and the exploit is very sensitive to how the compiler happens to lay out stack frames, which varies between kernel builds. Once you figure out the right "stamp method" and offsets for a particular kernel build though, it's fairly reliable.
Root for these RCs has been available under the guise of “FCC hack” for a really long time now; different groups have different exploits (it’s DJI so there are plenty) that work on different firmware versions.
Mostly they’re used to enable illegal RF parameters in Europe (FCC hack); DJI disabled strict geofencing in most of the “west” several years ago and that was also enforced in the drone anyway.
2. I saw some output from the execution of the POC.
However, after I went to <https://rootme.nebusec.io/b9e3f1a4-7c82-4d6e-9a51-2f8c4b3e0d...> the phone froze and refused to respond to any input. The only thing that worked was restarting, which I wonder how it works given the, I think, the kernel has hung. Does anyone know how the kernel is able to respond to events whilst the system has hung? The screen remains on with the partial output of the execution of the POC until the screen saver kicks in ...
The kernel is not a single-threaded process - a "kernel hang" is not a very specific description and you don't have a way to know that it happened anyway. The screen timing out is evidence that the kernel was largely working, actually. Of course if some data structure got corrupted it could have affected a specific essential part of the system, such as the touchscreen driver or the display compositor.
> Two boot looped, I had to enter recovery and the other just powered off [0].
Absolutely crazy that it is possible to brick someone's phone via an exploit but ... hey.
After the power off what happened? Do things seem normal?
When it entered recovery mode where you able to get the phone in a clean state again? I take it that you did?
I'd really like to run this but I, ideally, do not want to run something random from the internet. It's a shame there is no `Dockerfile` to build this exploit/POC. All I want is LPE to `root` on a Samsung (Snapdragon) phone.
It's not just a gaming and performance distro, it includes QoL fixes on modern hardware.
On my Lenovo laptop, fixes that would take over a day to enable and patch on most distros:
- Wake from sleep
- Nvidia GSP firmware workarounds and correct version OOTB (proprietary)
- Mouse lag/jitter
- External display hotplug
- DDC/CI over type-c
- Embedded controller power profiles from taskbar with correct TDP limits for CPU/GPU
- Battery charge limiter support right from KDE settings
- Working `switcherooctl` in hybrid graphics mode on AMD
- Firefox with video decode acceleration (YouTube) on almost all GPU models
Another gaming feature that is otherwise useful in workstations is the external scheduler support.
Currently using BPFland which makes multitasking as responsive as idle while compiling Yocto/Chromium in the background.
Windows, Mac (mini M1), and kernel built-in scheduler Linux jank and become almost unusable (Ryzen 5800H).
I tried CachyOS and Niri this weekend, and was pleasantly surprised hibernate/suspend actually worked with no customizations on my Desktop.
I’ve tried like 5 other distros and usually when it goes into sleep/hibernate the monitor never wakes up so I have to force shutdown using the power button.
I’m going to install this on an older machine and see how it goes. So far it’s been great!
Question to the Arch Linux veterans out there. Is CachyOS better than EndeavourOS or vice versa?
From what I read Cachy comes with a lot of proprietary repos and gaming stuff already installed along with a custom kernel tuned for gaming performance which makes it more bloated and less stable than vanilla Arch distros like Endeavour which just ships with the bare minimum quality of life tweaks over installing arch from scratch.
What's your experience and what would you recommend for someone switching their laptop from Windows mostly for dev work but who doesn't play too many games. I see arch is the most popular community favorite now, but I was thinking maybe a Fedora based distro would be a better fire-and-forget daily driver after the Arch AUR malware attack conundrum, as I don't have the time to deal with stuff like that on a daily basis.
CachyOS takes the default arch repos and re-builds packages targeting CPU generations and their instruction sets. There are no proprietary repos. Cachy has their own personal repo where some packages not in arch repos are built.
Gaming stuff is NOT installed by default, but there is a button in the Hello app new users can click that installs 2 meta packages that install almost everything one might want for gaming. Take a look at it in a VM and see for yourself.
The performance increases from their kernel + optimized packages are small but noticeable to me. Give their wiki a read-through:
https://wiki.cachyos.org/
I've used Cachy for about 2 months, having used Arch for a long time prior to that.
It just feels a lot faster (anecdotally) than Arch. I don't tend to play a lot of games either, but for tasks like web browsing and watching YouTube, it feels smoother. I don't think I'd go back to Arch unless Cachy did something really stupid to mess up which I hope they won't. No point in leaving free performance on the table with little downside.
Also you should never need the AUR. I've never needed it for anything in years, so the malware attack wasn't a concern at all. Yes, absolutely do switch away from Windows.
You can stick to 802.11r only by lowering the transmission power and have all the APs on the same channel, in my tests it ended up switching much faster than K/V. (~75ms)
On iOS, equal channel with correct ESS will switch liberally. On Android 14+ with Broadcom chip it will start conservative, then switch liberally after the first poor signal switch-over event, up until disconnection.
Android (Pixel/Moto) will never switch (even with K/V) on large network activity, only VoIP/video call. It depends on vendor implementation. [0]
I use "dp.logcatapp" log reader while roaming, "com.android.location.fused" can be used to show score and current load.
Samsung is known to push protocol support early: 802.11r in 2013, 802.11w 2015, some models do not use Android's default connectivity manager.
To add, WPA3 with 802.11r is known to have issues on Apple hardware before 2021 on all iOS versions, many Android devices, especially smart TVs don't support it, will not connect or are unreliable (protected beacon frame), can be searched in buried report results at OpenWrt forum mega threads and Ubiquity. WPA2+FT and forced MFP with a long password is a safe alternative. 802.11r use PMK push on WPA3 compared to WPA2, which was known to be problematic on older hardware.
802.11K/V is more suitable for campus and load balancing, tuning it based on RSSI and station metrics is very difficult, enterprise hardware rely on network traffic and air time.
Until it gets stuck on a far away AP because it was the first AP to come online the last time the network rebooted.
Not sure if roaming is actually the fix for this problem. For whatever reason my Ring cameras just love connecting to the worst and most far away AP in my house.
Not sure how widely available this feature is, but the unifi controller software for the popular Ubiquiti APs lets you bind individual client devices to specific APs such that they can only connect to the ones you choose.
I had to solve a similar issue for some crap IoT lights that would join the incorrect AP after a power cut every time.
That works for fixed devices like a TV, but also tends to shrink the effective coverage area of the wireless network as a whole.
That can mean that the portable wifi speaker-widget (which itself doesn't need much bandwidth) might go from working fine on the back deck or well-enough about anywhere else in the yard, to not working at all outside.
> That works for fixed devices like a TV, but also has the effect of shrinking the effective coverage area of the wireless network as a whole.
Which is normally a good thing to push the clients to roam to a better AP, OR you walked out of the building and want you phone to disconnect. But yes, does impact overall coverage area size.
That only works if there's a better AP to roam to. It's often very easy to add more APs indoors; but hanging them outside is a whole different animal.
Meanwhile: As a practical matter, shrinking coverage means "Hey, honey! I fixed the TV!" gets met with a response like "Oh, so that's why I can't listen to Audible on the veranda anymore!" :)
Experimentally probe: say you "fixed" something when you haven't touched anything and see what responses you get.
Obviously only if your honey is the type that enjoys being experimented upon (So long as it isn't mean, I like thoughtful attention like that, but some might not).
I need my TV to rapidly switch APs in very heavy load wide area networks with thousands of devices while I'm cruising through the venue with my motorized couch and entertainment system.
Now I want to actually build that for GPN24 next week. Wouldn't use AndroidTV for that though.
Good luck watching the office when your cat pushed your upstairs AP off the balcony. Your tv won't auto switch to the downstairs AP which is now closer than the one that's suddenly in the driveway.
On my Unifi setup at home with multiple APs I had to disable 802.11r to get things to roam fast. I have Android and Linux laptop, wife has iPhone and MacBook.
With 802.11r on, things would disconnect for 60+ seconds before reconnecting. It was a constant frustration of "arrrrrrrggghhhh fucking connect damnit I'm standing a meter in front of the AP can't you fucking see it fuck fuck fuck just connect, it's right THERE, connect NOW, arghhh" and then it would completely disconnect (no wifi found) and then reconnect a minute later.
With 802.11r off things just roam smoothly. I guess the people who inventned the tech didn't test it thoroughly enough.
It might be that UBNT has screwed up the settings when in 802.11r mode. I have 802.11r set up on my OpenWRT Ones and I'm seeing what appears to be A-OK roaming with my Linux laptop and Pixel 5a. I do also have DAWN installed (solely to populate the "hearing map") and umdns installed... but it's not clear to me if those are actually useful.
Unless they've reimplemented the whole damn thing since like 2018 or so, UniFi is OpenWRT with the serial numbers filed off, and UBNT is known to be not especially great at having good software on the APs. I had a square UAP-AC and then an AC-LITE and an AC-LR all running the official software for several years. While the management GUI seemed like it'd come in handy if you had to manage like a hundred APs, I wasn't impressed with either official support or the rest of the software.
I've been using the U6-Pro backed by UCG-Max and couldn't be happier.
Yes - the software running on the standalone APs is still basically OpenWRT wrapped with a management layer. But UniFi has grown to a much larger system. All the router boxes are running Debian, for example (even those with a built-in AP).
> They have come a very long way since the UAP-AC.
I agree. The AC-LR and AC-LITE were way better than the -AC. That guy ran extremely hot and was dogshit at multicast. In contrast, the -LITE and -LR merely ran notably hot and were merely intermittently bad at multicast.
Loading up OpenWRT on the -LR and -LITE made them work quite a lot better (though -obviously- they still ran just as warm). Ditching them for the OpenWRT One was even nicer.
Once you're not using default settings, here be dragons. In theory 802.11r is a standard. In practice enabling 802.11r puts you into the minority of users who do so. There's a lot less quality assurance coverage there.
You're at the mercy of UniFi not having any show stopping bugs (haha), the client device supporting 802.11r or at least tolerating it, and the interaction between UniFi and the client not having any show stopping bugs.
> You can stick to 802.11r only by lowering the transmission power and have all the APs on the same channel
Fast roaming has not, does not, and never will require APs be on the same channel. Only the SSID and password needs to match.
Setting them to the same channel will cause the APs to interfere (when they can't "hear" each other) or block each other from transmitting, or both. You set APs near each other so they are on non-overlapping bands. Always.
This is basic WiFi networking 101
> Samsung is known to push protocol support early: 802.11r in 2013
802.11r was released in 2008 and rolled into 802.11-2012.
> Fast roaming has not, does not, and never will require APs be on the same channel. Only the SSID and password needs to match.
There were no mentions of requirements for 802.11r in the comment. You removed "much faster than K/V." from the quote. "only" was referring to 802.11r exclusively. You can have the same results with different channels with K/V, provided that the clients support it as the rest of the comment mentions.
802.11r-only on different channels is ineffective for devices without K/V, since the reductions are insignificant.
You will be shaving 100ms from a 700ms delay on scan and association, compared to no-scan association which is around 20ms, hence the 75ms note.
And even then, FT is only needed for short buffer streaming like VoIP and VoWiFi. It's more important for WPA3, since handshake roundtrips are even longer (~300ms) which can degrade video/voice internet calls with a lengthy time to recover and complete silence for second or two on VoIP, it's not really needed for the average user back when WPA2 was standard.
Android and iOS will first scan on the same frequency, then rotate through the channels, which is now even longer on 6Ghz capable devices with the total number of channels.
The transition time is significantly faster with equal channels on most hardware, this is where 802.11k helps with different channels, especially in iOS. Without it, they cache scan results provided that the farthest AP is detected, this rarely happens since the scan time is so short.
Scanning different channels while connected causes large amount of jitter on station optimized WiFi SoCs, affecting VoIP on mediocre connections while the user is moving and actively losing signal, so its done as quick as possible, often missing many beacons. They can scan longer on the same channel without degradation. [0]
Without K/V, iOS/Android goes to the extent of doing frequent rescans on low network activity on body movement, you can install a Wi-Fi diagnostic profile to view the current activity on iOS, logcat on "fused" for Android.
The suggestion doesn't bash on 802.11k/v, it's just a compatibility alternative, considering that very few clients support it, let alone off the shelf consumer AP support.
> Setting them to the same channel will cause the APs to interfere (when they can't "hear" each other) or block each other from transmitting, or both. You set APs near each other so they are on non-overlapping bands. Always.
> This is basic WiFi networking 101
This is only true under large air time traffic and in large scale indoor setups. Not satellite APs that are far. Qualcomm, Mediatek and many systems implement their own spatial reuse technology.
WiFi 6+ introduces BSS coloring for channel width overlaps to further improve speeds on mixed traffic, not to mention the generally low penetration / TX power of 5Ghz+ on SNR.
>> Samsung is known to push protocol support early: 802.11r in 2013
> 802.11r was released in 2008 and rolled into 802.11-2012.
> Also, the iPhone 5S (2013) has 802.11r support.
The Samsung line in the comment was referring to Androids, many Android didn't support these until 2020, some non-flagship still don't (disabled), Samsung was notable to include it early, there are three paragraphs underneath referring to old phones and smart TVs, both Androids.
It is not enabled by default on many off the shelf APs for these reasons.
The elevators are probably causing rapid blind spots (shadows) while the user is moving around, 802.11k is indeed useful in this case for cutting down scan time, since iOS will still scan with filtered channels.
It's an interesting setup, looking forward to an update.
The post to which you're replying is implying that the lift shafts are entirely opaque to the wireless signal.
So it's fine if the user doesn't have a shaft between them and the AP. When they move so a straight line from the device to the AP crosses through a lift shaft, they enter the wireless "shadow" cast by that shaft, preventing them from contacting the AP. When they take another step forward the device might "come out of the shadow".
This is a difficult situation to deal with in roaming, where the visible AP set changes rapidly as the user moves a small amount.
TL;DR: I'm pretty sure the parent you're replying to "got it" and you didn't understand what they were trying to say.
For reference, Octopart is useful to track prices from many distributors, linked below [0] is a commonly used memory (1G) for Rockchip, Amlogic, Allwinner on many Radxa and Orange Pis.
You can now run Docker images in Termux with Udocker/proot[0], the disk IO can be a bottleneck for large databases when using proot.
Tailscale works with "--tun=userspace-networking" [1].
I had it running on an old phone as a Frigate server with a solar powerbank in remote area, using the 4G as a failover. The uptime is almost a week without solar.
Attiny hooked to the power button and a photodiode on the phone flash [2] (blink per minute) used as a watchdog for shutdowns/hangs to hardware reset. The button cap is removed without disassembling the phone.
Old phones are still more efficient than most off the shelf SBCs, especially under load.
~3W compared to 12W with a Pi5 in the same performance ballpark.
The new(er) mid range chipsets indeed are so so nice now. Pretty/fully modern process nodes, battery efficient, still very respectable cores.
Really glad to see we've finally landed at a place where finding an old refurbished flagship is not the only logical choice, where the mid-range has a lot going on for it.
Just wish we had some mainline kernel support, could put Debian on these things! I've had a OnePlus 6T (2018) that supposedly does pretty ok that I've been meaning to try Mobian on, and it felt like for a bit Snapdragons were getting better and better Linux support. But that motion seems to have really tapered off in the last ~2 years?
I had a Moto X4 which was quite cheap for $200 or $250. It did everything perfectly. No discernable lag for any operation. Plenty of storage. Great battery life. I can't imagine "needing" more phone than this.
Unfortunately it reached the end of its (security) updates so I figured it would be unsafe to keep using it since I have banking apps on the phone. Sad.
