Android may soon restrict on-device ADB • Hacker News Board

Re: Android may soon restrict on-device ADB

#331

Post by kitsumed » Sat, Jul 25, 2026, 5:33 PM UTC

ignoramous wrote: post #49

The article overlooks security implications from spyware, which is a huge problem not only for financial applications, but personal safety, too [0]. Per FTC, a stalkerware will: geo locate, read call list & record calls, read notifications, texts, & possibly emails, access gallery, camera, & files, and monitor network activity. [1] You could do all of those with "on-device adb" (in some cases, with just the appropria…

Spyware using ADB could be a thing (assuming someone has full access to your phone, including the password). However, it is impractical, as a reboot, system update, or Wi-Fi change would likely break everything.

It is much easier for spyware to be installed as a device administrator, granted accessibility privileges, and then given every possible Android permission via AppOps as a one-time setup.

At that point, ADB no longer matters. The spyware is already configured and ready to run. Even if on-device ADB were patched, anyone with physical access to the phone would still be able to install and configure their spyware via a USB cable.

As for attacks without physical access, as explained in the article with the 3 scenario, this is neither practical nor realistic. It only affects a very small subset of users (primarily Android developers) under very specific circumstances and during limited time windows.

Re: Android may soon restrict on-device ADB

#332

Post by stavros » Sat, Jul 25, 2026, 5:36 PM UTC

surajrmal wrote: post #327

stavros wrote: post #324

Earlier quoted context omitted.

No, I bought the device, I should be able to do whatever I want with it.

And app developers have the right to not offer their services to users who don't give them the security model they want. You are free to install a custom OS which provides you the security model you desire. You have choices.

No, when you can't participate in modern society without specific apps, I would argue those developers, in fact, don't have the right to not offer me their services.

Re: Android may soon restrict on-device ADB

#333

Post by kitsumed » Sat, Jul 25, 2026, 5:37 PM UTC

pigggg wrote: post #40

microtonal wrote: post #30

I am generally in favor of security improvements, but I do not really see much of a benefit here. This attack vector requires both that the user enabled developer settings and that they have remote adb enabled. So, this does not seem to be a realistic attack vector for 99.9% of the users and most of the other 0.1% probably know what they are doing. The other proposed change (to restrict access to certain interfaces o…

Isn't this because of the kimwolf (and now 6+ other botnets) that are taking advantage of people running residential proxyware unknowingly on the device which permits outbound connections to 127.0.0.1 on tcp/5555 to auth in and exec wgets or drops a loader that grabs the ddos malware APKs and install it?

From memory, for the kimwolf exploit things, other user already had good points about the device already beeing compromised. But also, the authentification part of ADB was just completly disabled, which is why this worked. Basically it was so-compromised as-is that ADB was just sitting here open, as is you where to put SSH with no authentification at all.

Re: Android may soon restrict on-device ADB

#334

Post by eviks » Sat, Jul 25, 2026, 5:47 PM UTC

AussieWog93 wrote: post #138

eviks wrote: post #18

> Spamming the thread will only cause Google developers to lock the issue, ignore valuable community feedback, or stop sharing public updates about this change entirely. So nothing would change (they can also lock away your "valuable community feedback" because what bothers them is the criticism itself), thus feel free to express your approval

> because what bothers them is the criticism itself I think there's a difference between criticism of a policy and being brigaded by a reddit mob.

You think wrong, "mob" is a collective way of criticizing a policy.

Sure, there are differences in types criticisms, but then try to actually articulate those and address whatever you think the issues with those are

Re: Android may soon restrict on-device ADB

#335

Post by sunaookami » Sat, Jul 25, 2026, 5:48 PM UTC

59percentmore wrote: post #199

microtonal wrote: post #120

Earlier quoted context omitted.

Snarks do not lead to productive discussions. You also know that there is has always been an implicit social contract between users and vendors. The vendor rolls out updates as part of the service attached to the device (typically included in the purchase price) and that the vendor does not abuse the update mechanism to make things worse for the user. If vendors use updates to restrict functionality that the user had…

>implicit social contract Sounds worthless (in court).

And that's how you get a low-trust society.

Re: Android may soon restrict on-device ADB

#336

Post by zzril » Sat, Jul 25, 2026, 5:55 PM UTC

createful wrote: post #254

999900000999 wrote: post #219

I just installed CachyOS on one of my laptops. I like Open Suse a bit more, but my vpn and a few other applications work better on Arch. Android is turning into the iOS/OSX/Win11 model. It’s not your device, you’re just renting it. You need permission to install applications, or do anything else outside of consuming subscription services. Where are the Linux phones ?

Linux phones exist but work on a limited number of devices (see PostMarketOS) or Linux primary devices like Purism or Pinephone (which I've heard are expensive). That's the primary issue, you either need to buy an expensive and potentially underpowered phone OR have one that is supported most of the way with PostMarketOS (Wifi, SIM card, GPU, etc. sometimes may not work even though the phone can boot PostMarketOS). I…

I've paid 200€ for my PinePhone. It is underpowered, but at least it doesn't have to waste its resources on rendering ads.

Where Android/iPhone users have "apps", I mostly end up writing small shell scripts around existing linux tools. My alarm clock "app" is realized via cron jobs; my TOTP "app" is a one-liner around `oathtool`.

Messenger apps are a bit tricky; I'll probably end up hosting my own matrix homeserver and then have bridges running for Signal and the likes.

Re: Android may soon restrict on-device ADB

#337

Post by cat_plus_plus » Sat, Jul 25, 2026, 6:14 PM UTC

Do you want your smart TV to become a persistent access point to your home network? If not, you should prefer to have an explicit unbypassable confirmation before another device is allowed to install arbitrary apps on it and pregrant them arbitrary permissions.

Re: Android may soon restrict on-device ADB

#338

Post by Grombobulous » Sat, Jul 25, 2026, 6:18 PM UTC

ffsm8 wrote: post #310

Danox wrote: post #296

Earlier quoted context omitted.

Which is a federal sales tax against the citizens of the United States countries abroad do not pay no matter how many times taco lies.

You're splitting hairs in this case, while that's unquestionably true, it's irrelevant if there tariffs are only set on one party. That's why Trump's tariffs on everything was so ... Uh ... "Interesting". If only one party gets the tariffs, you end up with other parties selling the goods instead, which does cause meaningful damage to the tariffed party

Or the tariffing party just continues buying very nearly the same amount of things at higher prices in many categories because those items don’t have perfectly elastic supply and demand.

Re: Android may soon restrict on-device ADB

#339

Post by xg15 » Sat, Jul 25, 2026, 6:24 PM UTC

kitsumed wrote: post #329

xg15 wrote: post #96

> Scenario 3: A Developer Using ADB over TCP/IP - You install a malicious application. - You enable USB debugging, starting ADBD. - You connect via USB ADB to enable TCP/IP, then disconnect the USB cable. - ADBD continues running and listens on all network interfaces. - The application initiates a connection, causing an authorization prompt to appear on the screen. If the user selects No, the connection is rejected.…

> However, ADBD in this situation only sees a connection attempt, not which app made the attempt, right? Every ADB connection has some kind of certificate / key that is saved locally. This means that a new application would have a different certificate. That certificate is shown in the yes/no prompt. > Does that mean that a Shizuku-enabled app would prompt the user again for ADB access any time it's started? You can…

Ah, that makes more sense and then of course the scenario would not work that way. Thanks for clearing that up!

Re: Android may soon restrict on-device ADB

#340

Post by dns_snek » Sat, Jul 25, 2026, 6:24 PM UTC

tekchip wrote: post #312

dns_snek wrote: post #78

Earlier quoted context omitted.

Can you provide a reasonable definition where an authentication bypass in ADB doesn't qualify as a vulnerability? Is there a use case for allowing anyone on your network to run adb commands without your approval? There are 3 things which I feel like are being confused here: 1. There was a genuine authentication bypass vulnerability in ADB (bad) 2. Initial proposed change wants to add an option to limit the ADB server…

The act of "allowing“ negates the “without your approval“. You see the failure in the logic here I hope.

I thought we were having a technical discussion not a linguistic one. Baseline level of technical understanding is expected. s/allowing/enabling/.

allow [intransitive verb]: to make a possibility

https://www.merriam-webster.com/dictionary/allow