Live data from Hacker News

Wanted to spy on my dog, ended up spying on TP-Link

kennedn.com

51–60 of 181 posts

Re: Wanted to spy on my dog, ended up spying on TP-Link

#51
post #13

Are techniques like using Frida and mitmproxy on Android apps still going to be possible after the signing requirement goes into effect next year?

They're already barely possible as it is.

For frida to work you need to root the device, which is impossible on ever more models, and there's an endless supply of very good rooting detection SDKs on the market, not to mention Play Integrity.

Re: Wanted to spy on my dog, ended up spying on TP-Link

#52
post #22
post #13

Are techniques like using Frida and mitmproxy on Android apps still going to be possible after the signing requirement goes into effect next year?

Overall: yes, but it will get much harder for apps which need attestation, which is sort of the point, for better or for worse. As far as I know you'll still be able to OEM unlock and root phones where it's always been allowed, like Pixels, but then they'll be marked as unlocked so they'll fail Google attestation. You should also be able to still take an app, unpack it, inject Frida, and sideload it using your _own_…

So for people with any practical needs what so ever (like banking): No.

At this point Android isn’t meaningfully an open-source platform any more and it haven’t been for years.

On the somewhat refreshing side, they are no longer being dishonest about it.

Re: Wanted to spy on my dog, ended up spying on TP-Link

#53
tapo annoyingly is also one of the only cameras that doesn't have a still snapshot url after all these years and endless requests from many

someone needs to make replacement firmware

ffmpeg can fake it but takes a few seconds to grab from the video stream and of course you can't run ffmpeg from your browser (or wait, can you now?)

     ffmpeg -rtsp_transport tcp -i "rtsp://cameraname:camerapass@192.168.1.23:554/stream1" -an   -y  -vframes 1 -f image2 -vcodec mjpeg  "snap.jpg"

Re: Wanted to spy on my dog, ended up spying on TP-Link

#56
post #20
post #18

Earlier quoted context omitted.

The device should ideally have some kind of secret material derived per device, like a passphrase generated from an MCU serial number or provisioned into EEPROM and printed on a label on the device. Some form of "enter the code on the device" or "scan the QR code on the device" could then mutually authenticate the app using proof-of-presence rather than hardcoded passwords. This can still be done completely offline w…

AT&T routers, for example, ship like this. There's a wifi network and a wifi password printed onto the device. But that also means then that often anyone with physical access can easily get into the device. The complicated password provides an additional layer of illusion of security, because people then figure "it's not a default admin password, it should be good". The fundamental problem seems to be "many people ar…

I feel seen. Why is the security illusory? I still don't understand the problem with this. Is the concern that someone will break into my house to covertly get access to my wifi password?

Re: Wanted to spy on my dog, ended up spying on TP-Link

#57
post #13

Are techniques like using Frida and mitmproxy on Android apps still going to be possible after the signing requirement goes into effect next year?

They're already barely possible as it is. For frida to work you need to root the device, which is impossible on ever more models, and there's an endless supply of very good rooting detection SDKs on the market, not to mention Play Integrity.

As far as I'm aware it is possible to use Frida without rooting, by using Objection https://github.com/sensepost/objection

Re: Wanted to spy on my dog, ended up spying on TP-Link

#58
post #34
post #18

Earlier quoted context omitted.

The device should ideally have some kind of secret material derived per device, like a passphrase generated from an MCU serial number or provisioned into EEPROM and printed on a label on the device. Some form of "enter the code on the device" or "scan the QR code on the device" could then mutually authenticate the app using proof-of-presence rather than hardcoded passwords. This can still be done completely offline w…

I agree that would be nice, but it also doesn't sound all that practical for a small vendor. I used to sell a home networking device,[0] and I wouldn't do what you're describing. If there were an issue where the labels calculate the wrong password or the manufacturer screws up which device gets which label, you don't find out until months later when they're in customer hands and they start complaining, and now you ha…

Slight tangent: I just read your Tiny Pilot blog post, which was interesting and worthwhile. Thanks for sharing that!

Re: Wanted to spy on my dog, ended up spying on TP-Link

#59
post #22

Earlier quoted context omitted.

Overall: yes, but it will get much harder for apps which need attestation, which is sort of the point, for better or for worse. As far as I know you'll still be able to OEM unlock and root phones where it's always been allowed, like Pixels, but then they'll be marked as unlocked so they'll fail Google attestation. You should also be able to still take an app, unpack it, inject Frida, and sideload it using your _own_…

So for people with any practical needs what so ever (like banking): No. At this point Android isn’t meaningfully an open-source platform any more and it haven’t been for years. On the somewhat refreshing side, they are no longer being dishonest about it.

I don't think any vendor should be solving for "I want to do app RE and banking on the same device at the same time;" that seems rather foolish.

These are sort of orthogonal rants. People view this as some kind of corporate power struggle but in this context, GrapheneOS, for example also doesn't let you do this kind of thing, because it focuses on preserving user security and privacy rather than using your device as a reverse-engineering tool.

There is certainly a strong argument that limiting third-party app store access and user installation of low-privilege applications is an anticompetitive move, but by and large, that's a different argument from "I want to install Frida on the phone I do banking on," which just isn't a good idea.

The existence of device attestation is certainly hostile to reverse engineering, and that's by design. But from an "I own my hardware and should use it" perspective, Google continue to allow OEM unlock on Play Store purchased Pixel phones, and the developer console will allow self-signing arbitrary APKs for development on an enrolled device, so not so much has changed with next year's Android changes.

Re: Wanted to spy on my dog, ended up spying on TP-Link

#60

Earlier quoted context omitted.

They're already barely possible as it is. For frida to work you need to root the device, which is impossible on ever more models, and there's an endless supply of very good rooting detection SDKs on the market, not to mention Play Integrity.

As far as I'm aware it is possible to use Frida without rooting, by using Objection https://github.com/sensepost/objection

> Patch iOS and Android applications, embedding a Frida gadget that can be used with objection or just Frida itself.

This is the key thing, and the part that will change next year: previously, you could unpack, patch, and repack an APK with the Frida gadget and install it onto an Android device in Developer mode, while the device remained in a "Production" state (with only Developer mode enabled, and no root). Now, the device would either need to be removed from the Android Certified state (unlocked/rooted) or you would need to sign the application with your own Developer Console account and install it on your own device, like the way iOS has worked for years.

Post reply on HN