wyfpmDoes Shuzku / wireless debugging demand a trusted wifi device?
Shizuku runs locally on your Android device on which you want to do debugging or perform automated tasks. It’s just using the ADB wireless interface to gain access to these functions.
Fair enough, thanks.
I know it’s the app itself that executes adb commands. I just wonder.
shizuku.rikka.app/guide/setup/
It says, allow debugging on this network.
So what you’re saying is, this is somewhat misleading, for this step doesn’t automaticallh grant all devices on the network debug-privileges; and were the modem itself, somehow, applying for them, then it wouldn’t have asked for the code as Shizuku is doing, via a notification?
Hope this helps!
Alright, sweet. Ty both vm.
I’d think i had tried starting Shizuku up without a connection. Just now, I tried to enable wireless debugging without wifi on, and Android said i must turn it on first, but perhaps I can turn it off afterwards, the say you can be on airplane mode then turn wifi on. (This once helped my online radio app cease to leak my system language for some reason.)
Will edit this post will further report.
Perhaps my question had semiconsciously stemmed from this:
Why would Android ask me to authorize a whole network for wireless debugging, if it then proceeds to demand device-permissions anyway?
I understand it is just a second layer of security, or, a relic of times when wifi connections were unencrypted. But if so, then wireless debugging should be just unenanable if elsewhere in Android settings, insecure wifi networks are enabled / if you presently are on one.
(Is adb encrypted anyway, as a protocol itself? If I authorized, say, my laptop, wirelessly, would the modem be able to read my comments? Those aren’t questions for you, btw, just musings. I should probably hit ai / Github for those.)
Ah, sorry, seems like I was wrong on the whole “no network connection needed”, but the reason is the explanation for your question!
The only way for your phone to recognize/authenticate the source of an incoming ADB connection is the MAC address. Basically every device that sends/receives ethernet packets has to have a unique “fingerprint”, so everyone knows it’s still the same device if it disconnects & reconnects etc. Everything else (IP address etc.) can change at any time, so the MAC address is the only fingerprint available.
But devices can spoof (change) their MAC address. That’s a really useful feature in many cases, e.g. phones these days use a random MAC for every new network, so a network provider can’t track you moving through multiple different networks. Also there’s no way to prevent it with our current network design. But this means that a malicious actor could wait for your trusted device to disconnect, then change their MAC to the one from your trusted device, and thus send malicious ADB commands.
Androids solution is to make you trust both the network and the device. So as long as you don’t have malicious actors in your trusted network, you’re safe - even if you connect to a different network with malicious actors, they can’t send ADB commands.
I see, makes sense. Thanks.
Hm, so, even if it is true that Shizuku-pairing directly privileges only the phone itself – that the adb commands never leave the phone – it follows that a malicious wifi modem, knowing all devices’ mac addresses, could, perhaps, feign being the phone, mac-wise. And issue its own commands, which the phone wouldn’t tell aren’t its own.
Unless adb privileges are also identified by the ip address of origin. Unless, the modem could also feign those and multicast them, or something. Could it?
Oh well. This is straying quite far from Android. Thank you regardless.
it follows that a malicious wifi modem, knowing all devices’ mac addresses, could, perhaps, feign being the phone, mac-wise. And issue its own commands, which the phone wouldn’t tell aren’t its own.
I just tested some scenarios:
- I start Shizuku in one wifi network (prompt to trust the network, then I had to enter the pairing code since I hadn’t used it before)
- Then switch wifi networks
- Shizuku was immediately disconnected
- When I press “Start” again in Shizuku, I get prompted to trust the network
- Then I switch back
- Shizuku stays running
- Then I disabled Wifi
- Shizuku stays running
- Then I disabled mobile data
- Shizuku stays running
- Then I stop Shizuku & press “Start” again
- It asks me to enable wireless debugging, and that enables wifi
So you’re safe as long as you don’t start Shizuku & trust the network while connected to a potentially malicious network.
That is a lovely analysis for this lowly thread of mine. Thanks again.
Thing is, I don’t trust my modem. Just on principle. It’s nonlibre software.
I’ll reread your posts in a while.
Unfortunately Google is hell-bent on restricting the platform instead of opening it up
Right. The very thing I want adb for is, among other things, to install apps which Google arbitrarily declared obsolete (the api version declaration, I believe it is). I believe many good apps on F-Droid are uninstallable because of that.
And sadly – though that doesn’t seem to be Google’s fault – it still doesn’t seem possible to compile Android apps on Android, so I can’t just get sources, change the manifest, and recompile them and install them myself, to escape that.
But that’s for another thread.
So what you’re saying is, this is somewhat misleading, for this step doesn’t automaticallh grant all devices on the network debug-privileges;
Hell, I hope not.
and were the modem itself, somehow, applying for them, then it wouldn’t have asked for the code as Shizuku is doing, via a notification?
I think the point is that Shizuku sends the ADB commands from your Android device through the network back to the very sane device where the ADB wireless instance listens to the commands and executes them. A malicious actor in the same network would need to pair with your device on the same way that your Shizuku did, i.e. via the 4 digit code or QR code.