alt Hacker NewsAndroid May Soon Restrict On-Device ADB
Comments
RIP phones
I'm sorry but F* Google.
They started with "we love open" and when became virtual monopoly they extort the position :/
Another day of AI another day of AI not being able to maintain useful features people used to take for granted
> 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. No silent exploitation attempts are possible.
I understand the author's rationale and think the reasons why that whole ecosystem is accessing ADB are legitimate - but I have some questions here.
The above flow is basically what apps that use Shizuku have to do as well, right? Only that in that case, the user would deliberately install the app and have the knowledge it uses ADB features and therefore would also confirm the permission prompt.
However, ADBD in this situation only sees a connection attempt, not which app made the attempt, right?
So it also cannot remember that a particular app was already authorized by the user and has to display the prompt again on each connection attempt?
Does that mean that a Shizuku-enabled app would prompt the user again for ADB access any time it's started?
This seems honestly like Shizuku itself would increase the risk of a user granting ADB access to a bad actor (i.e. a second app or external connection that is different from the app the user wanted to authorize).
Thinking of "scenario 3" if a Shizuku-enabled app is already running on the device and something else wants to connect to ADB:
- I'm assuming a malicious app was already installed (without privileges) or something tries to connect to port 5555 from outside or via proxyware.
- ADBD is already running and listening for TCP to serve the Shizuku app, so those steps can be taken for granted.
- The malicious app or connection triggers a permission prompt from ADBD. However, by that time, the user has grown used to those prompts, because the Shizuku triggers them frequently, so they are more likely to select "yes".
If ADBD has no information about who is connecting, it also can't show any meaningful information in the prompt. So it cannot really help the user distinguish prompts from the legitimate Shizuku app from malicious prompts. A user still has the timing and context to distinguish prompts, i.e. prompts that appear out of the blue when they aren't using the app are suspicious.
...why? Android is the holy grail of freedom, since iOS never was. It's gotten worse since ~2024, despite the lawsuit.
Or maybe Google is genuinely about thinking this in good faith. I can't see how, though.
These are not accidents. Google declared total war against open source. You only need to remember how it declared war against ublock origin. In the long run this will also fail, but until then Google causes a lot of damage. Legislation needs to control this tyrant but unfortunately the oligarchs run the country of the mad orange king right now.
Louis Rossman will have a field day with Google here. I think it is time to end Evil - that is, to end Google. This company serves no more useful purpose on this planet anymore.
It's frankly amazing how many Google developers will associate their real identities and contact info with such hostility, believing they're invincible.
Perhaps they should be subjected to the full force of the First Amendment.
To quote Scott McNealy, then CEO of Sun microsystems, circa 1999:
"You have zero privacy anyway. Get over it".
It has become truer every year that has passed since then.
The 2026 version : "If you believe you will be allowed to keep any kind of control over the devices you "own", you are deluding yourself".
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 appropriate permissions), without root access. Stalkerware & financial fraud enabled merely due to the scale & reach of Android (half of humanity uses it!) and lack of basic security literacy warrants such protective measures, as (Thaler & Sunstein would like to remind us) defaults matter.
With conspiracies abound, we must not lose sight of tech safety and related issues, which almost exclusively affect the most vulnerable & the most disadvantaged.
[0] https://www.techsafety.org/spyware-and-stalkerware-phone-sur...
adb connecting a device to itself is just bad design and a hack. Either the capabilities should just be granted directly to the app or it should all be blocked.
bullish on google stock
revenue must go up
"AI ... please create a very efficient emulator which will take an Android app, and convert it to any other operating system"
Anyone up for the challenge? Or a better solution.
Fuck this bullshit. It's only going to get worse.
[flagged]
[flagged]
[flagged]
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
And I might soon restrict use of Android and iOS in my life. Because of this nonsense, how will I get around the app issue is something I am still trying to figure out but I won't pay money to companies that make my products(I own them after I bought them) worse bit by bit anymore.