Nice project, great to see the scripts doing good work in the wild. If you needed any extra additions or tweaks to get them working, I'd love to hear about it.
Http toolkit is one of the best software i have used. I have used mitmproxy, proxyman and charles proxy and httptoolkit is the best and is open source too.
> SIDENOTE: If you want 2 way audio to work in frigate you must use the tapo:// go2rtc configuration for your main stream instead of the usual rtsp://. TP-Link are lazy and only implement 2 way audio on their own proprietary API.
Annoyingly when this is in use, I can't use ONVIF which seems like the only way to pan and tilt the camera using open tools. So if I want to use two way audio and also control the camera, I have to stop the process reading tapo:// stream, start onvif client and rotate, turn off onvif client and start streaming using tapo:// again
IoT security is generally terrible, but the fact that consumer routers are essentially unaudited black boxes processing all your network traffic is genuinely concerning.
Most people have no idea their router firmware hasn't been updated in years and is probably running known CVEs. The supply chain trust model for networking hardware is broken.
There are countless routers in between you and your destination which you can't audit anyway. End devices long since consider the routers to be compromised and have everything verified and encrypted in transit. So unless your router is participating in a DDoS or mining bitcoins it doesn't really matter how secure it is.
Many IoT devices (or Windows when the LAN network location is set to “Private”) expose a wider surface area to local network addresses. Having a competent firewall on your residential router is still useful, especially for those that have no idea how to configure their endpoints securely.
Comparing a residential router to a network operator’s router is spurious: those routers don’t perform any sort of filtering for the public internet traffic flowing through them.
Is there any residential router that exposes internal endpoints be default? I've yet to come across one that does not have a deny-any policy on it's WAN interface and has incoming destination NATs setup up.
What use is reducing the attack surface of a device which only ever initiates connections?
Edit: also there are network operators that block customer traffic on certain ports liike NetBIOS, SMB or SMTP to name a few.
If your home router is compromised (which is what the parent comment was talking about, considering it mentioned CVEs) the attacker who now controls it can easily make connections to devices on your network via the router’s local address.
As for how the router that is theoretically not accepting incoming connections from the internet itself gets compromised in the first place: among other issues some routers can be RCEd by a webpage visited by someone inside the LAN[1]. That’s just one example, you can find tons of these if you search for router vulnerabilities. In practice out of date routers end up in botnets frequently.
It has nothing to do with network operators blocking SMB traffic; the attacker can communicate with the router via whatever C2 mechanism they put in the malware, which probably won’t even involve opening a port on the router. The SMB or what have you to the endpoint would be entirely within the LAN.
I mean, your router is the single key to your kingdom—-your local network. If you don’t treat all your local devices as hostile (which is a reasonable thing to do but almost no one does it), then having your router in shape is somewhere in the important to critical range.
Most people only care about how strong the signal is when buying a router, but almost no one checks if the firmware is outdated, or bothers to change the default password or disable remote access. And manufacturers rarely remind you either, so over time it just becomes a hidden risk.
Most people don't buy routers, they get them from the ISP and never think about them again unless the wifi goes out, in which case they unplug and plug back in.
Yup, that's definitely me. After reading this I was like, oh shit, I better check for firmware updates for my ISPs router, but as it turns out, I have no idea how to, and there's no information online about how to do it.
Most people are using routers given to them (and configured by) their ISP... so really they are blackboxes connected to an upstream blackbox for most people.
I am always surprised by how many people give me their ISP chosen router name and ISP chosen password when I connect to their WiFi. I don't want to give my ISP that much control.
Are you really surprised though or are you talking about the HN reading subset of your "many people"?
Coz I would absolutely 100% not be surprised for your average consumer.
For your average HN reader I would hope they treat whatever their ISP gave them as just some dumb "switch" type device that sits outside their trusted network and handles nothing but encrypted traffic. Like my ISPs device definitely does have a WiFi and such, which I disabled. I treat it as a bridge / modem and it's definitely not part of my "inner circle". Hasn't been in 25 years.
Like sometimes I want IoT devices to just bloody connect, and if I have to use a published exploit that circumvents online only requirements I will do it.
But some people do genuinely have use cases for cloud speaking IoT stuff.
Really I think the device should ask at first run, and then burn in your response and act only in the selected mode. If you want it to require Cloud MFA, thats an option, if you want to piss python at your lightbulb to make it blink, then thats where it lives permanently.
The stuff on the shelf, sure, but you can always go 'prosumer-grade' like Ubiquiti or Mikrotik for hardware that actually receives timely updates and has competently written firmware.
Ubiquiti is awful, it's a cloud-centric ecosystem. The best "prosumer-grade" stuff is probably OpenWrt. If you need more power, opnSense or a plain Linux distro on an x86 machine.
Not entirely true. There's a local admin option, where your Ubiquiti devices never see the internet (well, except your gateway). You can then connect and admin the whole thing remotely via your own VPN. It's quite nice, actually.
OpenWRT is trading money for time. It's fine to recommend to someone interested in setting up their own custom router, but for most "prosumers" Ubiquiti will provide a better experience.
It's worth noting that Ubiquiti provides local admin support, and that the Ubiquiti Cloud data breach was actually a false story spread by a disgruntled internal engineer in an attempt to extort his employer.
As a MikroTik user. Do not start unless you know your ways around networking. And if you do prepare some time to get used to it. Once you do it isn't hard but the onboarding and having 20-40 options for everything you can do is confusing.
Fritzbox brand and possibly others updates itself automatically by default. ISPs often also control the devices they ship to clients and install updates as part of a "fleet management".
Actually, pfsense kind of has a shitty reputation in the FOSS community and opnSense is preferred.
But I don't like the limitations of BSD systems in terms of hardware compatibility and performance, so I build my router using a plain Linux distro (Debian).
Nitpick but "known CVEs" doesn't mean a vulnerable device. The majority of CVEs in your NAT box sw (aside: NAT is not routing) are going to be things like "insecure temp file handling".
Your point of course stands, the situation is terrible.
Personally I treat any ISP provided (or big box store) router as compromised anyway. I install my own router as a replacement, or if not possible, just as the sole device downstream of it, and connect all my stuff to my own router. And I use Tailscale + other routing DNS servers, etc.
really like how this blog is written. a lot of writeups like this recently have been generated by an LLM, and it's quite distracting to read - this was a pleasant surprise. it strikes a good balance between technical and laid-back
(yes i know the cover image is AI-generated, that's incidental to the content)
I've been blocking by default bigger media files with uBlock Origin to avoid needless resource usage. Cover images are typically blocked, and they are usually useless anyway.
It's too bad people spend energy for generating them now.
>> It's too bad people spend energy for generating them now.
How do you mean?
Some quick back of the napkin math.
Creating a 'throwaway' banner image by hand, maybe 15 minutes on a 100W CPU in Photoshop:
15 minutes human work time + 0.025 kWh (100W*0.25h)
Creating a 'throwaway' banner image by stable diffusion on a 600W GPU. In reality it's probably less than 20 seconds to generate, but let's round it up to one full minute of compute time:
5 minutes human work time + 0.01 kWh (600W*(1/60)h)
The way I see it it seems to spend less energy, regardless of whether you're talking about human energy or electrical energy. What's the issue here exactly?
You can't take the human energy in account, because there's no reason to believe they won't live for the same amount of time and use the same amount of energy regardless.
You are not accounting for the model training (which can't be ignored, first because you can't ignore fixed costs, and second, because we keep training newer models, so amortizing doesn't quite work), rebound effect, the subsidized bot crawling, etc.
I won't comment further on this, this discussion has been rehashed to death anyway and in better ways that I can.
IMHO the better way is to not do meaningless cover images, and this is also true of stock, non-AI generated images (I'm not against art, so if it's your strength, by all means, please do meaningful or nice cover images).
It all depends on the scale you use. At the individual, sure. But it's like cars. They keep getting more effecient, yet total energy consumption keeps increasing.
The further we can go, the further we will go.
The more CPU power we get, the more JS heavy websites get.
The more images we can generate, the more we will generate.
The more we can do, the more we do, whether we should or not.
To add to the sibling comment, your CPU is not going to be using 100 W (if it can even reach that!) for more than a few seconds in total during 15 min of typical Photoshop use.
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_ developer account (kind of like you can do on iOS today), but it will also fail attestation and is vulnerable to anti-tampering / anti-debugging code at the application level.
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.
> 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 [...]
But that's not really using it, is it? If the process of getting access to do whatever I want on my smartphone makes it cease to be a viable smartphone, can you really count that as being able to use it?
It's like if having your car fixed by a third party mechanic made it not street legal. It is still a car and it does still drive, but are you really still able to meaningfully use it?
And before anyone jumps on my metaphor with examples of where that's actually the case with cars, think about which cases and why. There are modifications that are illegal because they endanger others or the environment, but everything else is fair game.
What I don't get is, if I am using my bank website on linux (with full root ability), it's still almost nearly the same as having the app on Android. The argument of "we lock it down to protect you makes 0 sense to me"
* Your bank (and Google) want to deal with as little fraud as possible.
* Market forces demand they provide both a website and an Android app.
* If both platforms are equally full of fraud, have the same features, and both have similar use, they cut out half the fraud even if they can only make one or the other fraud proof.
* But it isn't like that in reality: in reality, something more like 80% of their use and 90% of their fraud comes from mobile devices, and so cutting off that route immediately reduces their fraud-load by a lion's share.
Ergo, locking down the app is still in everyone's best interest, before we even get into the mobile app having features the desktop one does not (P2P payments, check deposit, etc.)
And this isn't just a weird theory / ivory tower problem: Device Takeover banking fraud on Android is _rampant_ (see Gigabud/GoldDigger).
Why does most fraud come from locked down mobile devices and not open Windows/Linux PCs?
If it's true that 90% of fraud comes from mobile despite all of the restrictions, what that tells me is that locking down devices doesn't actually prevent fraud.
---
> before we even get into the mobile app having features the desktop one does not (P2P payments, check deposit, etc.)
I think it would be reasonable to disable those specific features on mobile while leaving the rest of the app accessible.
Actually, back when jailbreaking iOS was still actually feasible, I recall the Chase app doing exactly that. The app worked fine, but it wouldn't let me deposit checks, I had to go to a branch for that. A bit annoying, but I can mostly understand that one.
> If it's true that 90% of fraud comes from mobile despite all of the restrictions
Statistics on mobile vs. desktop banking will really shock you; the mobile usage penetration is easily well upwards of 90% in many markets. There's also a skewed distribution for fraud-vulnerable users and scenarios.
> I think it would be reasonable to disable those specific features on mobile while leaving the rest of the app accessible.
I agree with you in an idealist sense; it would be awesome to be able to use GrapheneOS and have 80% app functionality instead of 0% app functionality. I also completely understand why nobody does it; supporting what's probably <0.001 (if not lower)% of legitimate users in exchange for development time and fraud risk isn't a particularly appealing tradeoff. If I were in a situation to advocate for such a trade-off, I probably would, but I don't think it's evidence of a sinister conspiracy that nobody does that.
> Statistics on mobile vs. desktop banking will really shock you; the mobile usage penetration is easily well upwards of 90% in many markets. There's also a skewed distribution for fraud-vulnerable users and scenarios.
But if my goal was to commit fraud, wouldn't I go to wherever it was easiest to commit fraud? The actual market penetration of each platform shouldn't matter.
It's usually done in bulk, so the overall payoff is the combination of value and number of targets, but the effort is typically sublinear with the targets. Something easier to attack but relatively low in number is not as juicy as something a bit harder (where the effort is mostly a one-off up-front rather than per target) but having many, many more targets.
It's unclear what device attestation does here. You can print a fake check and take whatever picture you want. If it's using dead pixels or something as a device fingerprint, you get those dead pixels. You can also fake dead pixels, of course. Authenticating the phone's OS doesn't authenticate the camera, or what the camera's looking at. It's a signal, maybe, but the weak link in "a napkin with the right numbers and scribble on it is a money transfer" is probably not whether someone has root on the device that's taking a picture of the napkin.
GrapheneOS strongly recommends that you do not do it, but it will not stop you if you want to.
You can root and leave your bootloader unlocked or create a custom user signed image with root support included. Plenty of user written guides out there how to do so.
No, you can do that on GrapheneOS as well. You just follow their install guide and skip the final step and then just flash magisk.
The updates become slightly tedious, but you can if you want to.
Firmware which requires updates to be signed with a manufacturer key can still be open source. As long as its code is available publicly, under a license which lets the user create derivative works, it meets the definition. You can still make a version of it that doesn't contain that check, you just can't install that version on the device you bought from the original firmware developer. Some FIDO keys (and I think Bitcoin wallets) do this.
That's not universally true, it depends on the license we're talking about.
As an arbitrary counterexample, the LGPL specifically requires you to give end users of your thing a way to link your object code with their own modified version of the LGPL'd library.
>At this point Android isn’t meaningfully an open-source platform any more
Google Android as installed on 99% of stock android phones never was open source. AOSP continues to be open source and is not effected by any changes made in the proprietary google android and google play services eco system.
I'm stuck on iOS for various reasons, but if I was on Android I could do without mobile banking in exchange for having root privileges. I don't entirely understand why this is such a big deal.
If e.g. Slack required attestation that would be a different story. I need that for work.
It's not really going to be directly affected by that change I would expect. Most reverse engineering is on rooted devices & emulators anyway, which are already outside the bounds of those kinds of Google restrictions.
For the (less common) cases where you want to use a non-rooted device (e.g. using Frida by injecting it into the APK via gadget) it gets trickier, but I think in practice there will still be a way for developers to build & install their own APKs with developer mode enabled. This will be tightened, but removing that restriction would effectively make Android development impossible so it seems very unlikely - I think they will block sideloading on all non-developer devices only, or allow you to add your own developer cert for development or similar (all of which would probably be fine for development & reverse engineering, while still being a massive pain for actual distribution of apps).
The larger issue is device attestation, which _could_ make all rooted/non-certified devices progressively less practical, as more apps attempt to aggressively detect unmodified devices. Right now that's largely limited to big financial apps, and has some downsides (you get a bunch of complaints from all 3 GrapheneOS users, and it requires a bunch of corresponding server work to be reliable) but it could become more widespread.
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.
> For frida to work you need to root the device, which is impossible on ever more models
There's plenty of physical devices where it is possible, and Google publish official emulator images with root access for every Android version released to date. This part is still OK.
> there's an endless supply of very good rooting detection SDKs on the market, not to mention Play Integrity
Most of the root detection is beatable with Frida etc, mostly.
Play Integrity & attestation (roughly: 'trusted computing' on your phone, which signs messages as 'from an unmodified certified device' in a way that the server can verify, to only allow connections from known-good devices) is a much larger problem. Best hope here is that a) it creates much work for most apps to bother and b) it eventually gets restricted as anti-competitive. It's literally them charging & setting rules on their competitors for how they get a certificate which allows phones they make to function with all the Android apps on the market, and pushing app makers to restrict their apps to not work on phones from competitors who don't play ball, so I don't think anti-competition pushback here is that implausible medium term.
> There's plenty of physical devices where it is possible
Yup, but say Samsung, kiss KNOX goodbye. Fused off once you flash a non-Samsung image.
> and Google publish official emulator images with root access for every Android version released to date. This part is still OK.
Many apps will straight refuse to run in emulators unless you're lucky to snag a debug build that accidentally got pushed to production.
> Most of the root detection is beatable with Frida etc, mostly.
It's a cat and mouse game and frankly, I'm sick of it - and especially about the fact that it's either "accept that you'll need to wait X weeks until <Magisk plugin> gets an update" or "install some unofficial closed source fork that may or may not be laced with malware".
> Best hope here is that a) it creates much work for most apps to bother and b) it eventually gets restricted as anti-competitive.
Rooting detection used to be too much work, then SDKs cropped up that made it very easy, and that will be the case for remote-verifiable hardware attestation.
And restrictions from anti-trust? No way that will happen in the next three years in the US, and here in the EU it takes about 5-10 years until our parliament finally gets to work after a problem gets too much attention for their lazy asses to ignore. And even then, the lobby from banks, game studios ("them cheaters!!!" in f2p scam games) and other influential lobbyists will likely prevent any serious action.
> 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.
It's a hardcoded default password, not a permanent backdoor. If I'm understanding the post correctly, the user changes it as part of the onboarding flow.
This is the way most apps work if they have a default password the user is supposed to change.
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 with no "cloud" or other access, or "lock in"; the app just uses the device secret to authenticate with the device locally. Then the user can set a raw RTSP password if desired.
This way unprovisioned devices are not nearly as vulnerable to network-level attacks. I agree that this is Not Awful but it's also Not Good. Right now, if you buy this camera and plug it into a network and _forget_ to set it up, it's a sitting duck for the time window between network connection and setup.
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 have to unwind your manufacturing and fulfillment pipeline to get back all the devices you've shipped.
All that to protect against what attack? One where there's malicious software on the user's network that changes the device password before the user can? In that case, the user would just not use the camera because they can't access the feed.
> I agree that would be nice, but it also doesn't sound all that practical for a small vendor.
Personalizing / customizing per device always introduces a huge amount of complexity (and thus cost). However, this is TP-Link we're talking about, who definitely have the ability to personalize credentials at scale on other product lines.
And again, to be clear, I'm not trying to argue that the current way is some horrible disaster from TP-Link, just advocating for a better solution where possible. I think the current system reads as fine, honestly, it sounds like typical cobbled together hardware vendor junk that probably has some huge amount of "real" vulnerability in it too, but this particular bit of the architecture doesn't offend me badly.
> now you have to unwind your manufacturing and fulfillment pipeline to get back all the devices you've shipped.
This can be avoided with some other type of proof-of-presence side channel which doesn't rely on manufacturing personalization - for example, a physical side-channel like "hold button to enable some PKI-based backup pairing or firmware update mode." For a camera, there should probably be an option to make this go away once provisioning is successful, since you don't want an attacker performing an evil maid attack on the device, but for pre-provisioning, it's a good option.
> Personalizing / customizing per device always introduces a huge amount of complexity (and thus cost)
For a hardware product mass produced like this, they should already have a custom label that has the unique serial number on it which is also programmed into each device, so they should already have the infrastructure to do that (potentially as part of automated board testing/flashing).
Adding a randomly generated password is hardly more work once you have the ability to do that.
For a large manufacturer, it can be flashed onto the device automatically by a machine as part of the production line. That's not easy to set up, but basically something they already need to have set up (you don't want to have humans have to plug in boards to flash firmware and load serial numbers, etc. on to every unit).
> 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.
It is better than simple secret like 12345678 but it can go wrong too, like in the case of UPC UBEE routers where the list of potential passwords can be narrowed down to like ~60 possibilities using a googled generator [1] whilst knowing only the SSID.
It did require firmware reverse engineering to figure out [2][3] but applies to most devices I've encountered. User should ideally always change the default password regardless.
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 are bad at passwords and onboarding flows", and so trying variations on shipping passwords seem to result in mostly the same problems.
That's fair, though at least resetting would indicate that an attack happened. Default passwords and printed passwords can result in undetected attacks, which are arguably worse.
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?
These may be illegal in some jurisdictions due to accessibility laws, and are a bad idea in general, for these reasons as well as unattended configuration scenarios.
If you buy the camera, plug it in, and forget to set it up, you just flat out can't use it right? I agree that proof of presence is way better but how many people are seriously going to be affected?
No, if you buy the camera, plug it in, and forget to set it up, then someone can use the default password and key material stored in the app to pretend to be the app and provision it on your behalf.
That's the only real vulnerability here, and it's no big deal, but it is A Thing and there is definitely a better way to do this that doesn't lose the freedom of full-offline.
There could be another scenario. I assume that factory resetting the camera will bring back the default password. Factory reset is a long press on the power button (in some cheap TPlink camera), so in theory someone with physical access can take control over the camera without you noticing until you try and use it.
I mean, given that it's updated after setup with the normal flow, I'm okay with it.
The thing I've most been convinced of in the past 5 years of building as much 'iot/smart home' stuff out as possible in my house is that nearly every vendor is selling crap that has marginal usefulness outside of a 'party trick' in isolation. Building out a whole smart home setup is frustrating unless it's all from one vendor, but there isn't one vendor which does all of it well for every need.
On my phone I have apps for: Ecobee, Lutron, Hue, 4 separate camera vendors[1], Meross, and Smart Life. Probably a couple more that I'm forgetting.
Only Lutron and Hue are reasonable in that they allow pretty comprehensive control to be done by a hub or HomeKit so I never have to use those apps.
It's been years since Matter and Thread were supposedly settled upon as the new standards for control and networking, but the market is, instead of being full of compatible devices, instead absolutely packed with cheap wi-fi devices, each of which is cloud-dependent and demands to be administered and even used day-to-day only through a pile-of-garbage mobile app whose main purpose is to upsell you on some cloud services.
[1] I admit the fact I have 4 is my fault for opportunistically buying cameras that were cheap rather than at least sticking with one vendor. But many people have a good excuse, perhaps one vendor makes the best doorbell camera, while another might make a better PTZ indoor camera.
> Even if your hardware doesn't support local APIs, there's a good chance someone has made an HA integration to talk to their cloud API.
And if they haven’t, you can pretty trivially write your own and distribute it through HACS (I’ve got three integrations in HACS and one in mainline now)
I love it! But my setup has a lot of sharp edges. It's a combo of things where the "standards compatible" way to connect to HA lacks things like camera control, by dastardly vendors like Chamberlain who basically killed HA support for spite, and finally, by having to use Google or Amazon for voice assistants.
My #1 wish would be for someone to build a HA-native voice assistant speaker. I'd pay $100 each for a smart speaker of the physical quality of the $30 Google Home Mini but which integrated directly with HA and used a modern LLM to decide what the user's intent was, instead of the Google Assistant or Siri nonsense which is like playing a text adventure whose preferred syntax changes hourly. I'd pay that plus a monthly fee to have that exist and just work.
Chamberlain can't change MyQ to get around the fact that HA can operate the switch in your garage with a simple controller attached to it. It is very annoying that they are anti-hacker though.
This M5 Stack ASR unit costs $7.50, and has a vocab of about 40-70 words. That's enough to turn on/off lights and timers. You might need to come up with your own command language, but all of the ASR is extremely local
That is probably a great and fun way to solve the problem for those with even a little free time.
Sadly for family reasons I sadly can't take on projects that require more than a few minutes, so I'm holding out hope for someone to bridge the gap between the "project boards that require writing a bunch of code to interface with Home Assistant and define all of its possible abilities and commands" and "dumb as a post Google thing that you just plug in" with a hardware device that is easy to connect to HA and starts out doing what the Google thing can do, but smart instead of stupid like the legacy voice assistants are.
I know people who are still using the router their ISP gave them, and they’ve never even changed the default password. The thing is, they don’t even know it can be updated, let alone that there might be security vulnerabilities. To most users, if the internet works, that’s all that matters.
As it should be. The problem is that for ISPs, "Internet works" is defined as minimum possible service level that doesn't cause active revolt of majority of customers.
Good hardware? Costs money. Connecting to anything that goes beyond Netflix and Facebook requirements? Costs money, operations isn't cheap. Anything unusual (so much so as being seen borderline criminal) as hosting your own server, email, or $deity forbid networking hardware? Forget it, support costs money.
I love little projects like this, but man does this make me glad things like Thingino exists. Installing the firmware takes like 5 minutes, a little self-hosted web configurator pops up, you put in an SSID and a password, the camera reboots, and its yours. We should not have to reverse engineer crap like this.
I used to get in the kind of frustrated situations where, like the author, I spent two days reverse-engineering something I had just bought just to get it to do what I thought it obviously would when I bought it.
IOT things like the thing he bought are (were) typically the worst kind of offenders.
I just don't do that anymore. It used to bring me pleasure cracking the nut, and that's not the case any longer.
These days, if it does not do what I need more or less out of the box, I just return it / send it back and research the follow-up buy better.
Does anyone have a good reference for which tapo cameras support rtsp? I have a c210 that works well (sort of, you can't use it with their cloud capture) and I have it working with frigate.
But today I got a c402 (outdoor) thinking I could use it to capture my son's soccer practice. But that doesn't have the camera account option under advanced.
I love the price point of these devices but the functionality is all over the place.
If anyone knows a good outdoor camera, preferably with solar panel, that is cheap and has an rtsp stream, please let me know.
You should still be able to use the tapo:// go2rtc stream source even if the camera does not support the rtsp:// via the camera account option. Have a look at my frigate configuration for reference - https://github.com/kennedn/frigate/blob/7c56604e819d2cb1da28...
If the author is here, did you find a way to prevent the tapo from trying to connect to the internet every 20s? (I just blocked it's access, but it's annoying to see it all the denied requests in my router logs.)
I'm guessing not, and it's not really an issue since it can be used entirely locally without, but it's still kinda annoying.
Not aware of a list or something, but before buying any appliance I try searching if it's "jailbreak-able".
For example I'll search if the router I want to purchase has guides to install openWRT on it, how hard it is to break out of the vendor software loop.
Recently even my Aircon had a mandatory app that it required to even finish installation. I got so pissed I dumped the firmware and reverse engineered the protocol enough to figure out how to set fan speed, temperature and mode. Sitting in the sweltering New Delhi heat really expedited the process.
At this point, I'd pay extra for a camera, thermostat, or doorbell that just does its job without demanding an account, a cloud link, and a monthly fee to unlock basic features
And eggcorn means "a word or phrase that results from a mishearing or misinterpretation of another, an element of the original being substituted for one which sounds very similar (e.g. tow the line instead of toe the line )."
I tried and failed at enough suggestions I found on the internet and via AI to cobble together a frigate configuration that eventually worked with the Tapo cameras.
RTC setup section:
go2rtc:
streams:
<Camera RTC name>:
- rtsp://tapoadmin:<local camera account password>@<camera IP address>:554/stream1
- ffmpeg:<Camera RTC name>#audio=opus
- tapo://<Tapo cloud password>@<camera IP address>
<Camera RTC name>_sub:
- rtsp://tapoadmin:<local camera account password>@<camera IP address>:554/stream2
- ffmpeg:<Camera RTC name>_sub#audio=opus
- tapo://<Tapo cloud password>@<camera IP address>
* <Camera RTC name> is just any old short name you want to assign to the camera.
* <Camera name> is the main name for the camera that will be shown in the frigate UI
* <local camera account password> is something set individually on each camera (settings > Advanced > Camera Account, set it to On and setup username/password > Account Information)
* <Tapo cloud password> is the password setup for the Tapo app (I'm not sure how necessary this is, since there's nowhere that the username is specified... this is the only bit I'm fuzzy on)
This is the basics that works for me for the Tapo cameras. There are a boatload of other settings specific to Frigate (but not specific to Tapo cameras).
This is nowhere near as cool hack as the article, however.
Hello, as I alluded to in my blog post you should use tapo:// as the main stream source to get two-way audio. You can then optionally use rtsp://.../stream2 as a lower resolution sub stream source for detections. Defining both tapo:// and rtsp:// in a single stream is redundant as go2rtc only picks one or the other. My own configuration is here for reference https://github.com/kennedn/frigate/blob/7c56604e819d2cb1da28...
I use Reolink's for outdoor. The Tapo's are all indoor C210/C211 (cheap, but do the job just fine).
Looks like the C402 has two different hardware versions[0] so maybe the old one doesn't work but the new one does? A firmware upgrade might also be worth trying. This reddit page suggests trying ONVIF as the go2RTC connection[1].
On your dhcp server (probably your router/gateway), statically assign (reserve) the camera's MAC address to the IP that you want it to have. Sometimes called MAC binding.
Are any of these outdoor cameras? Do you use rtsp if so? I'm trying to find an outdoor camera that supports frigate and surprised my new c402 does not.
try reducing your buffer size and -probesize to help with that delay (and/or optionally fixing the video format parameters so probing isn't needed at all)
Hacking together something usable out of cloud-first piece of hardware you ended up with is respectable, but I would like to bring up another option to go with if you're choosing a new device: buy camera that doesn't require a phone app to initial setup and serves RTSP out of the box.
Note that I didn't say "cheap". If price difference comes from manufacturer's hope of selling its cloud service, then the time and effort required to set it up is not worth the money.
If I were to solve one-time task of keeping an eye on someone indoors I would go with USB camera (if lighting conditions allows even the laptop's build in), which is going to be cheaper than ones with IP and WiFi support.
Oh awesome, this is using my Frida scripts! These: https://github.com/httptoolkit/frida-interception-and-unpinn....
Nice project, great to see the scripts doing good work in the wild. If you needed any extra additions or tweaks to get them working, I'd love to hear about it.
They worked amazingly out of the box, thanks Tim! The command I used in the end was just a subset of the example given in your repository:
frida -U \
-f com.tplink.iotHttp toolkit is one of the best software i have used. I have used mitmproxy, proxyman and charles proxy and httptoolkit is the best and is open source too.
HTTP Toolkit is fantastic, great job Tim!
> SIDENOTE: If you want 2 way audio to work in frigate you must use the tapo:// go2rtc configuration for your main stream instead of the usual rtsp://. TP-Link are lazy and only implement 2 way audio on their own proprietary API.
Annoyingly when this is in use, I can't use ONVIF which seems like the only way to pan and tilt the camera using open tools. So if I want to use two way audio and also control the camera, I have to stop the process reading tapo:// stream, start onvif client and rotate, turn off onvif client and start streaming using tapo:// again
IoT security is generally terrible, but the fact that consumer routers are essentially unaudited black boxes processing all your network traffic is genuinely concerning. Most people have no idea their router firmware hasn't been updated in years and is probably running known CVEs. The supply chain trust model for networking hardware is broken.
There are countless routers in between you and your destination which you can't audit anyway. End devices long since consider the routers to be compromised and have everything verified and encrypted in transit. So unless your router is participating in a DDoS or mining bitcoins it doesn't really matter how secure it is.
Many IoT devices (or Windows when the LAN network location is set to “Private”) expose a wider surface area to local network addresses. Having a competent firewall on your residential router is still useful, especially for those that have no idea how to configure their endpoints securely.
Comparing a residential router to a network operator’s router is spurious: those routers don’t perform any sort of filtering for the public internet traffic flowing through them.
Is there any residential router that exposes internal endpoints be default? I've yet to come across one that does not have a deny-any policy on it's WAN interface and has incoming destination NATs setup up.
What use is reducing the attack surface of a device which only ever initiates connections?
Edit: also there are network operators that block customer traffic on certain ports liike NetBIOS, SMB or SMTP to name a few.
If your home router is compromised (which is what the parent comment was talking about, considering it mentioned CVEs) the attacker who now controls it can easily make connections to devices on your network via the router’s local address.
As for how the router that is theoretically not accepting incoming connections from the internet itself gets compromised in the first place: among other issues some routers can be RCEd by a webpage visited by someone inside the LAN[1]. That’s just one example, you can find tons of these if you search for router vulnerabilities. In practice out of date routers end up in botnets frequently.
It has nothing to do with network operators blocking SMB traffic; the attacker can communicate with the router via whatever C2 mechanism they put in the malware, which probably won’t even involve opening a port on the router. The SMB or what have you to the endpoint would be entirely within the LAN.
[1]: https://www.malwarebytes.com/blog/news/2023/02/arris-vulnera...
Many happily do Network PNP, etc. which allows them to open ports on the public facing side of the router.
I mean, your router is the single key to your kingdom—-your local network. If you don’t treat all your local devices as hostile (which is a reasonable thing to do but almost no one does it), then having your router in shape is somewhere in the important to critical range.
Most people only care about how strong the signal is when buying a router, but almost no one checks if the firmware is outdated, or bothers to change the default password or disable remote access. And manufacturers rarely remind you either, so over time it just becomes a hidden risk.
Most people don't buy routers, they get them from the ISP and never think about them again unless the wifi goes out, in which case they unplug and plug back in.
Exactly. This really is the reality of it.
Yup, that's definitely me. After reading this I was like, oh shit, I better check for firmware updates for my ISPs router, but as it turns out, I have no idea how to, and there's no information online about how to do it.
Most people are using routers given to them (and configured by) their ISP... so really they are blackboxes connected to an upstream blackbox for most people.
I am always surprised by how many people give me their ISP chosen router name and ISP chosen password when I connect to their WiFi. I don't want to give my ISP that much control.
Are you really surprised though or are you talking about the HN reading subset of your "many people"?
Coz I would absolutely 100% not be surprised for your average consumer.
For your average HN reader I would hope they treat whatever their ISP gave them as just some dumb "switch" type device that sits outside their trusted network and handles nothing but encrypted traffic. Like my ISPs device definitely does have a WiFi and such, which I disabled. I treat it as a bridge / modem and it's definitely not part of my "inner circle". Hasn't been in 25 years.
>IoT security is generally terrible
I think IoT demands a rethink of security.
Like sometimes I want IoT devices to just bloody connect, and if I have to use a published exploit that circumvents online only requirements I will do it.
But some people do genuinely have use cases for cloud speaking IoT stuff.
Really I think the device should ask at first run, and then burn in your response and act only in the selected mode. If you want it to require Cloud MFA, thats an option, if you want to piss python at your lightbulb to make it blink, then thats where it lives permanently.
The stuff on the shelf, sure, but you can always go 'prosumer-grade' like Ubiquiti or Mikrotik for hardware that actually receives timely updates and has competently written firmware.
Ubiquiti is awful, it's a cloud-centric ecosystem. The best "prosumer-grade" stuff is probably OpenWrt. If you need more power, opnSense or a plain Linux distro on an x86 machine.
Not entirely true. There's a local admin option, where your Ubiquiti devices never see the internet (well, except your gateway). You can then connect and admin the whole thing remotely via your own VPN. It's quite nice, actually.
OpenWRT is trading money for time. It's fine to recommend to someone interested in setting up their own custom router, but for most "prosumers" Ubiquiti will provide a better experience.
It's worth noting that Ubiquiti provides local admin support, and that the Ubiquiti Cloud data breach was actually a false story spread by a disgruntled internal engineer in an attempt to extort his employer.
100% this.
As a MikroTik user. Do not start unless you know your ways around networking. And if you do prepare some time to get used to it. Once you do it isn't hard but the onboarding and having 20-40 options for everything you can do is confusing.
A lot of them violate the GPL and BSD licenses too.
they violate the BSD license by not acknowledging the Regents of the University of California?
By not distributing the copyright notices and BSD license.
Fritzbox brand and possibly others updates itself automatically by default. ISPs often also control the devices they ship to clients and install updates as part of a "fleet management".
IOT - "S" stands for "Security"!
The password for my IoT wifi is "TheSInIoT"
;)
The solution is pfsense
Or openWRT.
The bsd based distributions sure are powerful, but with the power/heat budget to match.
I love me some OpenWRT but updating it has always been a risky chore.
Check out attended sysupgrade
Actually, pfsense kind of has a shitty reputation in the FOSS community and opnSense is preferred.
But I don't like the limitations of BSD systems in terms of hardware compatibility and performance, so I build my router using a plain Linux distro (Debian).
That's the first I've heard of pfsense having a bad reputation, can you explain? (I haven't used it, genuinely want to know)
They also did this: https://web.archive.org/web/20160314132836/http://www.opnsen...
And WIPO had to take the domain away from them: https://en.wikipedia.org/wiki/PfSense#OPNsense
https://arstechnica.com/gadgets/2021/03/buffer-overruns-lice...
wild read.
sounds like the core of the issue was that Netgate hired a weirdo, and then botched how they handled it when the weirdo got -- go figure -- weird.
and it showed how FreeBSD does commits badly and may not have any (or few) code reviews
honestly makes me feel bad about using netgate boxes -- what else needs to be fixed?
The soulutions is iptables.
The solution is nftables.
The solution is bpf.
The solution is emacs-m-x-butterfly-bpf.
Better go OPNsense
Nitpick but "known CVEs" doesn't mean a vulnerable device. The majority of CVEs in your NAT box sw (aside: NAT is not routing) are going to be things like "insecure temp file handling".
Your point of course stands, the situation is terrible.
Personally I treat any ISP provided (or big box store) router as compromised anyway. I install my own router as a replacement, or if not possible, just as the sole device downstream of it, and connect all my stuff to my own router. And I use Tailscale + other routing DNS servers, etc.
really like how this blog is written. a lot of writeups like this recently have been generated by an LLM, and it's quite distracting to read - this was a pleasant surprise. it strikes a good balance between technical and laid-back
(yes i know the cover image is AI-generated, that's incidental to the content)
I've been blocking by default bigger media files with uBlock Origin to avoid needless resource usage. Cover images are typically blocked, and they are usually useless anyway.
It's too bad people spend energy for generating them now.
>> It's too bad people spend energy for generating them now.
How do you mean?
Some quick back of the napkin math.
Creating a 'throwaway' banner image by hand, maybe 15 minutes on a 100W CPU in Photoshop:
Creating a 'throwaway' banner image by stable diffusion on a 600W GPU. In reality it's probably less than 20 seconds to generate, but let's round it up to one full minute of compute time: The way I see it it seems to spend less energy, regardless of whether you're talking about human energy or electrical energy. What's the issue here exactly?You can't take the human energy in account, because there's no reason to believe they won't live for the same amount of time and use the same amount of energy regardless.
You are not accounting for the model training (which can't be ignored, first because you can't ignore fixed costs, and second, because we keep training newer models, so amortizing doesn't quite work), rebound effect, the subsidized bot crawling, etc.
I won't comment further on this, this discussion has been rehashed to death anyway and in better ways that I can.
IMHO the better way is to not do meaningless cover images, and this is also true of stock, non-AI generated images (I'm not against art, so if it's your strength, by all means, please do meaningful or nice cover images).
It all depends on the scale you use. At the individual, sure. But it's like cars. They keep getting more effecient, yet total energy consumption keeps increasing.
The further we can go, the further we will go.
The more CPU power we get, the more JS heavy websites get.
The more images we can generate, the more we will generate.
The more we can do, the more we do, whether we should or not.
To add to the sibling comment, your CPU is not going to be using 100 W (if it can even reach that!) for more than a few seconds in total during 15 min of typical Photoshop use.
Somewhat related:
The Tapo C200 research project https://drmnsamoliu.github.io/ (https://news.ycombinator.com/item?id=37813013)
PyTapo: Python library for communication with Tapo Cameras https://github.com/JurajNyiri/pytapo (https://news.ycombinator.com/item?id=41267062)
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_ developer account (kind of like you can do on iOS today), but it will also fail attestation and is vulnerable to anti-tampering / anti-debugging code at the application level.
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.
> 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 [...]
But that's not really using it, is it? If the process of getting access to do whatever I want on my smartphone makes it cease to be a viable smartphone, can you really count that as being able to use it?
It's like if having your car fixed by a third party mechanic made it not street legal. It is still a car and it does still drive, but are you really still able to meaningfully use it?
And before anyone jumps on my metaphor with examples of where that's actually the case with cars, think about which cases and why. There are modifications that are illegal because they endanger others or the environment, but everything else is fair game.
What I don't get is, if I am using my bank website on linux (with full root ability), it's still almost nearly the same as having the app on Android. The argument of "we lock it down to protect you makes 0 sense to me"
* Your bank (and Google) want to deal with as little fraud as possible.
* Market forces demand they provide both a website and an Android app.
* If both platforms are equally full of fraud, have the same features, and both have similar use, they cut out half the fraud even if they can only make one or the other fraud proof.
* But it isn't like that in reality: in reality, something more like 80% of their use and 90% of their fraud comes from mobile devices, and so cutting off that route immediately reduces their fraud-load by a lion's share.
Ergo, locking down the app is still in everyone's best interest, before we even get into the mobile app having features the desktop one does not (P2P payments, check deposit, etc.)
And this isn't just a weird theory / ivory tower problem: Device Takeover banking fraud on Android is _rampant_ (see Gigabud/GoldDigger).
Why does most fraud come from locked down mobile devices and not open Windows/Linux PCs?
If it's true that 90% of fraud comes from mobile despite all of the restrictions, what that tells me is that locking down devices doesn't actually prevent fraud.
---
> before we even get into the mobile app having features the desktop one does not (P2P payments, check deposit, etc.)
I think it would be reasonable to disable those specific features on mobile while leaving the rest of the app accessible.
Actually, back when jailbreaking iOS was still actually feasible, I recall the Chase app doing exactly that. The app worked fine, but it wouldn't let me deposit checks, I had to go to a branch for that. A bit annoying, but I can mostly understand that one.
> If it's true that 90% of fraud comes from mobile despite all of the restrictions
Statistics on mobile vs. desktop banking will really shock you; the mobile usage penetration is easily well upwards of 90% in many markets. There's also a skewed distribution for fraud-vulnerable users and scenarios.
> I think it would be reasonable to disable those specific features on mobile while leaving the rest of the app accessible.
I agree with you in an idealist sense; it would be awesome to be able to use GrapheneOS and have 80% app functionality instead of 0% app functionality. I also completely understand why nobody does it; supporting what's probably <0.001 (if not lower)% of legitimate users in exchange for development time and fraud risk isn't a particularly appealing tradeoff. If I were in a situation to advocate for such a trade-off, I probably would, but I don't think it's evidence of a sinister conspiracy that nobody does that.
> Statistics on mobile vs. desktop banking will really shock you; the mobile usage penetration is easily well upwards of 90% in many markets. There's also a skewed distribution for fraud-vulnerable users and scenarios.
But if my goal was to commit fraud, wouldn't I go to wherever it was easiest to commit fraud? The actual market penetration of each platform shouldn't matter.
It's usually done in bulk, so the overall payoff is the combination of value and number of targets, but the effort is typically sublinear with the targets. Something easier to attack but relatively low in number is not as juicy as something a bit harder (where the effort is mostly a one-off up-front rather than per target) but having many, many more targets.
They usually don't let you deposit checks via web app.
It's unclear what device attestation does here. You can print a fake check and take whatever picture you want. If it's using dead pixels or something as a device fingerprint, you get those dead pixels. You can also fake dead pixels, of course. Authenticating the phone's OS doesn't authenticate the camera, or what the camera's looking at. It's a signal, maybe, but the weak link in "a napkin with the right numbers and scribble on it is a money transfer" is probably not whether someone has root on the device that's taking a picture of the napkin.
GrapheneOS strongly recommends that you do not do it, but it will not stop you if you want to. You can root and leave your bootloader unlocked or create a custom user signed image with root support included. Plenty of user written guides out there how to do so.
Locking the bootloader is important as it enables full verified boot https://grapheneos.org/install/cli#locking-the-bootloader
> You can root and leave your bootloader unlocked
That's Google, not GrapheneOS.
No, you can do that on GrapheneOS as well. You just follow their install guide and skip the final step and then just flash magisk. The updates become slightly tedious, but you can if you want to.
Open source has nothing to do with hackability.
Firmware which requires updates to be signed with a manufacturer key can still be open source. As long as its code is available publicly, under a license which lets the user create derivative works, it meets the definition. You can still make a version of it that doesn't contain that check, you just can't install that version on the device you bought from the original firmware developer. Some FIDO keys (and I think Bitcoin wallets) do this.
> Open source has nothing to do with hackability.
That's not universally true, it depends on the license we're talking about.
As an arbitrary counterexample, the LGPL specifically requires you to give end users of your thing a way to link your object code with their own modified version of the LGPL'd library.
>At this point Android isn’t meaningfully an open-source platform any more
Google Android as installed on 99% of stock android phones never was open source. AOSP continues to be open source and is not effected by any changes made in the proprietary google android and google play services eco system.
People would do good by stop conflating the two.
I'm stuck on iOS for various reasons, but if I was on Android I could do without mobile banking in exchange for having root privileges. I don't entirely understand why this is such a big deal.
If e.g. Slack required attestation that would be a different story. I need that for work.
they leave that up to your organization: https://slack.com/help/articles/360042097113-Block-jailbroke...
It's not really going to be directly affected by that change I would expect. Most reverse engineering is on rooted devices & emulators anyway, which are already outside the bounds of those kinds of Google restrictions.
For the (less common) cases where you want to use a non-rooted device (e.g. using Frida by injecting it into the APK via gadget) it gets trickier, but I think in practice there will still be a way for developers to build & install their own APKs with developer mode enabled. This will be tightened, but removing that restriction would effectively make Android development impossible so it seems very unlikely - I think they will block sideloading on all non-developer devices only, or allow you to add your own developer cert for development or similar (all of which would probably be fine for development & reverse engineering, while still being a massive pain for actual distribution of apps).
The larger issue is device attestation, which _could_ make all rooted/non-certified devices progressively less practical, as more apps attempt to aggressively detect unmodified devices. Right now that's largely limited to big financial apps, and has some downsides (you get a bunch of complaints from all 3 GrapheneOS users, and it requires a bunch of corresponding server work to be reliable) but it could become more widespread.
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.
> For frida to work you need to root the device, which is impossible on ever more models
There's plenty of physical devices where it is possible, and Google publish official emulator images with root access for every Android version released to date. This part is still OK.
> there's an endless supply of very good rooting detection SDKs on the market, not to mention Play Integrity
Most of the root detection is beatable with Frida etc, mostly.
Play Integrity & attestation (roughly: 'trusted computing' on your phone, which signs messages as 'from an unmodified certified device' in a way that the server can verify, to only allow connections from known-good devices) is a much larger problem. Best hope here is that a) it creates much work for most apps to bother and b) it eventually gets restricted as anti-competitive. It's literally them charging & setting rules on their competitors for how they get a certificate which allows phones they make to function with all the Android apps on the market, and pushing app makers to restrict their apps to not work on phones from competitors who don't play ball, so I don't think anti-competition pushback here is that implausible medium term.
> There's plenty of physical devices where it is possible
Yup, but say Samsung, kiss KNOX goodbye. Fused off once you flash a non-Samsung image.
> and Google publish official emulator images with root access for every Android version released to date. This part is still OK.
Many apps will straight refuse to run in emulators unless you're lucky to snag a debug build that accidentally got pushed to production.
> Most of the root detection is beatable with Frida etc, mostly.
It's a cat and mouse game and frankly, I'm sick of it - and especially about the fact that it's either "accept that you'll need to wait X weeks until <Magisk plugin> gets an update" or "install some unofficial closed source fork that may or may not be laced with malware".
> Best hope here is that a) it creates much work for most apps to bother and b) it eventually gets restricted as anti-competitive.
Rooting detection used to be too much work, then SDKs cropped up that made it very easy, and that will be the case for remote-verifiable hardware attestation.
And restrictions from anti-trust? No way that will happen in the next three years in the US, and here in the EU it takes about 5-10 years until our parliament finally gets to work after a problem gets too much attention for their lazy asses to ignore. And even then, the lobby from banks, game studios ("them cheaters!!!" in f2p scam games) and other influential lobbyists will likely prevent any serious action.
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.
Wow that's horrifying. I guess apk modding era is over for most users.
Not yet. If I recall correctly only very few countries affected in the beginning.
Also somewhat related:
(TP-Link Firmware Decryption C210 V2 cloud camera bootloaders) https://watchfulip.github.io/28-12-24/tp-link_c210_v2.html?u...
They cracked the APK to get the default password, but googling for it I see it is in a CVE from 2022
https://nvd.nist.gov/vuln/detail/CVE-2022-37255
Mon key toge ther strong
So we're at the point that finding hardcoded admin passwords is no big deal.
It's a hardcoded default password, not a permanent backdoor. If I'm understanding the post correctly, the user changes it as part of the onboarding flow.
This is the way most apps work if they have a default password the user is supposed to change.
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 with no "cloud" or other access, or "lock in"; the app just uses the device secret to authenticate with the device locally. Then the user can set a raw RTSP password if desired.
This way unprovisioned devices are not nearly as vulnerable to network-level attacks. I agree that this is Not Awful but it's also Not Good. Right now, if you buy this camera and plug it into a network and _forget_ to set it up, it's a sitting duck for the time window between network connection and setup.
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 have to unwind your manufacturing and fulfillment pipeline to get back all the devices you've shipped.
All that to protect against what attack? One where there's malicious software on the user's network that changes the device password before the user can? In that case, the user would just not use the camera because they can't access the feed.
[0] https://mtlynch.io/i-sold-tinypilot/
Ha! I actually use TinyPilot all the time, nice!
> I agree that would be nice, but it also doesn't sound all that practical for a small vendor.
Personalizing / customizing per device always introduces a huge amount of complexity (and thus cost). However, this is TP-Link we're talking about, who definitely have the ability to personalize credentials at scale on other product lines.
And again, to be clear, I'm not trying to argue that the current way is some horrible disaster from TP-Link, just advocating for a better solution where possible. I think the current system reads as fine, honestly, it sounds like typical cobbled together hardware vendor junk that probably has some huge amount of "real" vulnerability in it too, but this particular bit of the architecture doesn't offend me badly.
> now you have to unwind your manufacturing and fulfillment pipeline to get back all the devices you've shipped.
This can be avoided with some other type of proof-of-presence side channel which doesn't rely on manufacturing personalization - for example, a physical side-channel like "hold button to enable some PKI-based backup pairing or firmware update mode." For a camera, there should probably be an option to make this go away once provisioning is successful, since you don't want an attacker performing an evil maid attack on the device, but for pre-provisioning, it's a good option.
> Personalizing / customizing per device always introduces a huge amount of complexity (and thus cost)
For a hardware product mass produced like this, they should already have a custom label that has the unique serial number on it which is also programmed into each device, so they should already have the infrastructure to do that (potentially as part of automated board testing/flashing).
Adding a randomly generated password is hardly more work once you have the ability to do that.
TP-Link is far from being a small vendor, though.
Ah, I see. I thought OP used TP-Link for their router. I missed that Tapo (the camera manufacturer) is a subsidiary of TP-Link.
I think he has it backwards: Easy for a small vendor, very hard for a large one.
For a large manufacturer, it can be flashed onto the device automatically by a machine as part of the production line. That's not easy to set up, but basically something they already need to have set up (you don't want to have humans have to plug in boards to flash firmware and load serial numbers, etc. on to every unit).
Slight tangent: I just read your Tiny Pilot blog post, which was interesting and worthwhile. Thanks for sharing that!
> 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.
It is better than simple secret like 12345678 but it can go wrong too, like in the case of UPC UBEE routers where the list of potential passwords can be narrowed down to like ~60 possibilities using a googled generator [1] whilst knowing only the SSID.
It did require firmware reverse engineering to figure out [2][3] but applies to most devices I've encountered. User should ideally always change the default password regardless.
[1] https://upcwifikeys.com/UPC1236567
[2] https://deadcode.me/blog/2016/07/01/UPC-UBEE-EVW3226-WPA2-Re...
[3] https://web.archive.org/web/20161127232750/http://haxx.in/up...
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 are bad at passwords and onboarding flows", and so trying variations on shipping passwords seem to result in mostly the same problems.
If you have physical access you can just factory reset the device and onboard it with the normal flow though
That's fair, though at least resetting would indicate that an attack happened. Default passwords and printed passwords can result in undetected attacks, which are arguably worse.
It doesn't change anything in this case though, you can't use the default password against a tp-link device after it's been onboarded.
Same with Orange branded ones. There is even a QR code that you can scan on your phone - no more typing 16-24 hex characters.
It's hard to decide whether it's good or bad. It is definitely easier. Which I guess matters most in consumer grade routers.
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?
> The device should ideally have some kind of secret material derived per device
Thats the wrong way to do it, just require the user create a secret on first boot, and have factory reset functionality for when you forget it.
Well it was "the cheapest cam in Amazon" according to the article so my expectations were that this would not be "ideal".
These may be illegal in some jurisdictions due to accessibility laws, and are a bad idea in general, for these reasons as well as unattended configuration scenarios.
If you buy the camera, plug it in, and forget to set it up, you just flat out can't use it right? I agree that proof of presence is way better but how many people are seriously going to be affected?
No, if you buy the camera, plug it in, and forget to set it up, then someone can use the default password and key material stored in the app to pretend to be the app and provision it on your behalf.
That's the only real vulnerability here, and it's no big deal, but it is A Thing and there is definitely a better way to do this that doesn't lose the freedom of full-offline.
There could be another scenario. I assume that factory resetting the camera will bring back the default password. Factory reset is a long press on the power button (in some cheap TPlink camera), so in theory someone with physical access can take control over the camera without you noticing until you try and use it.
Ok yeah I think we're in agreement then.
on the other hand "onboarding" seems to be a less offensive normalizing word which really means "ask permission to use device"...
"if you don't know what you're doing don't do it" vs. "Secure out of the box"
Hard coded admin passwords that you have to change in order to start using the device aren't really an issue.
I mean, given that it's updated after setup with the normal flow, I'm okay with it.
The thing I've most been convinced of in the past 5 years of building as much 'iot/smart home' stuff out as possible in my house is that nearly every vendor is selling crap that has marginal usefulness outside of a 'party trick' in isolation. Building out a whole smart home setup is frustrating unless it's all from one vendor, but there isn't one vendor which does all of it well for every need.
On my phone I have apps for: Ecobee, Lutron, Hue, 4 separate camera vendors[1], Meross, and Smart Life. Probably a couple more that I'm forgetting.
Only Lutron and Hue are reasonable in that they allow pretty comprehensive control to be done by a hub or HomeKit so I never have to use those apps.
It's been years since Matter and Thread were supposedly settled upon as the new standards for control and networking, but the market is, instead of being full of compatible devices, instead absolutely packed with cheap wi-fi devices, each of which is cloud-dependent and demands to be administered and even used day-to-day only through a pile-of-garbage mobile app whose main purpose is to upsell you on some cloud services.
[1] I admit the fact I have 4 is my fault for opportunistically buying cameras that were cheap rather than at least sticking with one vendor. But many people have a good excuse, perhaps one vendor makes the best doorbell camera, while another might make a better PTZ indoor camera.
Home Assistant is making more and more sense to make your own fully local and private home automation system.
Absolutely. I've been using Home Assistant for around 6 years now and it's absolutely amazing for tying hardware from varying ecosystems together.
Even if your hardware doesn't support local APIs, there's a good chance someone has made an HA integration to talk to their cloud API.
> Even if your hardware doesn't support local APIs, there's a good chance someone has made an HA integration to talk to their cloud API.
And if they haven’t, you can pretty trivially write your own and distribute it through HACS (I’ve got three integrations in HACS and one in mainline now)
Thank you for your contributions btw! There is so much amazing work that's gone into HA and I appreciate it every day.
Thanks, but it really is a community effort. Even the one I wrote the most of was still me and another guy (the Lucid Motors integration).
I'd love to see what's needed to get some of these integrations in core!
I love it! But my setup has a lot of sharp edges. It's a combo of things where the "standards compatible" way to connect to HA lacks things like camera control, by dastardly vendors like Chamberlain who basically killed HA support for spite, and finally, by having to use Google or Amazon for voice assistants.
My #1 wish would be for someone to build a HA-native voice assistant speaker. I'd pay $100 each for a smart speaker of the physical quality of the $30 Google Home Mini but which integrated directly with HA and used a modern LLM to decide what the user's intent was, instead of the Google Assistant or Siri nonsense which is like playing a text adventure whose preferred syntax changes hourly. I'd pay that plus a monthly fee to have that exist and just work.
you may be interested in https://www.home-assistant.io/voice-pe/
or
https://www.home-assistant.io/voice_control/thirteen-usd-voi...
Chamberlain can't change MyQ to get around the fact that HA can operate the switch in your garage with a simple controller attached to it. It is very annoying that they are anti-hacker though.
or roll your own.
This M5 Stack ASR unit costs $7.50, and has a vocab of about 40-70 words. That's enough to turn on/off lights and timers. You might need to come up with your own command language, but all of the ASR is extremely local
https://shop.m5stack.com/products/asr-unit-with-offline-voic...
That is probably a great and fun way to solve the problem for those with even a little free time.
Sadly for family reasons I sadly can't take on projects that require more than a few minutes, so I'm holding out hope for someone to bridge the gap between the "project boards that require writing a bunch of code to interface with Home Assistant and define all of its possible abilities and commands" and "dumb as a post Google thing that you just plug in" with a hardware device that is easy to connect to HA and starts out doing what the Google thing can do, but smart instead of stupid like the legacy voice assistants are.
Hardcoded admin creds should've gone extinct with Flash-based websites, but here we are
Well, they aren’t here though.. I feel like you just wanted to be annoyed at this tech
Smartphones can be seen by some as the initial hostile devices.
Network devices can at least be monitored and discovered like this.
Unrelated, but I wonder if the OP's dog moves from the bed to the floor because the radiator turns on? might need more sensor data :D
Or just because she noticed she was cold
I know people who are still using the router their ISP gave them, and they’ve never even changed the default password. The thing is, they don’t even know it can be updated, let alone that there might be security vulnerabilities. To most users, if the internet works, that’s all that matters.
As it should be. The problem is that for ISPs, "Internet works" is defined as minimum possible service level that doesn't cause active revolt of majority of customers.
Good hardware? Costs money. Connecting to anything that goes beyond Netflix and Facebook requirements? Costs money, operations isn't cheap. Anything unusual (so much so as being seen borderline criminal) as hosting your own server, email, or $deity forbid networking hardware? Forget it, support costs money.
And so on.
Thank you for including the final part about what your dog has been up to :)
> "She sleeps"
The fact that OP did all this work to find out the dog sleeps is pure hacker culture. Love to see it :)
I love little projects like this, but man does this make me glad things like Thingino exists. Installing the firmware takes like 5 minutes, a little self-hosted web configurator pops up, you put in an SSID and a password, the camera reboots, and its yours. We should not have to reverse engineer crap like this.
https://thingino.com
I used to get in the kind of frustrated situations where, like the author, I spent two days reverse-engineering something I had just bought just to get it to do what I thought it obviously would when I bought it.
IOT things like the thing he bought are (were) typically the worst kind of offenders.
I just don't do that anymore. It used to bring me pleasure cracking the nut, and that's not the case any longer.
These days, if it does not do what I need more or less out of the box, I just return it / send it back and research the follow-up buy better.
Does anyone have a good reference for which tapo cameras support rtsp? I have a c210 that works well (sort of, you can't use it with their cloud capture) and I have it working with frigate.
But today I got a c402 (outdoor) thinking I could use it to capture my son's soccer practice. But that doesn't have the camera account option under advanced.
I love the price point of these devices but the functionality is all over the place.
If anyone knows a good outdoor camera, preferably with solar panel, that is cheap and has an rtsp stream, please let me know.
You should still be able to use the tapo:// go2rtc stream source even if the camera does not support the rtsp:// via the camera account option. Have a look at my frigate configuration for reference - https://github.com/kennedn/frigate/blob/7c56604e819d2cb1da28...
Fantastic.
Why do you use rtsp for some streams and then tapo protocol for others? Are these all tapo cameras?
The other two are Annke C500 outdoor cameras.
Can I ask why you chose those?
Go2rtc is working flawlessly now with these tapo cameras. Thanks so much. Incredible how easy it was. And integrated with frigate as well.
This is the most gloriously overengineered way to find out your dog naps all day, and I respect the hell out of it.
If the author is here, did you find a way to prevent the tapo from trying to connect to the internet every 20s? (I just blocked it's access, but it's annoying to see it all the denied requests in my router logs.)
I'm guessing not, and it's not really an issue since it can be used entirely locally without, but it's still kinda annoying.
Very nice project and writeup.
I wish there was a repository of "appliances that don't try to shove an app and a subscription down your throat"
I mirror this sentiment so much as well.
Not aware of a list or something, but before buying any appliance I try searching if it's "jailbreak-able".
For example I'll search if the router I want to purchase has guides to install openWRT on it, how hard it is to break out of the vendor software loop.
Recently even my Aircon had a mandatory app that it required to even finish installation. I got so pissed I dumped the firmware and reverse engineered the protocol enough to figure out how to set fan speed, temperature and mode. Sitting in the sweltering New Delhi heat really expedited the process.
At this point, I'd pay extra for a camera, thermostat, or doorbell that just does its job without demanding an account, a cloud link, and a monthly fee to unlock basic features
Side note - “full-proof” is an eggcorn of “foolproof”.
And eggcorn means "a word or phrase that results from a mishearing or misinterpretation of another, an element of the original being substituted for one which sounds very similar (e.g. tow the line instead of toe the line )."
I'd never heard of it before
I tried and failed at enough suggestions I found on the internet and via AI to cobble together a frigate configuration that eventually worked with the Tapo cameras.
RTC setup section:
Main section: Where:* <Camera RTC name> is just any old short name you want to assign to the camera.
* <Camera name> is the main name for the camera that will be shown in the frigate UI
* <local camera account password> is something set individually on each camera (settings > Advanced > Camera Account, set it to On and setup username/password > Account Information)
* <Tapo cloud password> is the password setup for the Tapo app (I'm not sure how necessary this is, since there's nowhere that the username is specified... this is the only bit I'm fuzzy on)
This is the basics that works for me for the Tapo cameras. There are a boatload of other settings specific to Frigate (but not specific to Tapo cameras).
This is nowhere near as cool hack as the article, however.
Hello, as I alluded to in my blog post you should use tapo:// as the main stream source to get two-way audio. You can then optionally use rtsp://.../stream2 as a lower resolution sub stream source for detections. Defining both tapo:// and rtsp:// in a single stream is redundant as go2rtc only picks one or the other. My own configuration is here for reference https://github.com/kennedn/frigate/blob/7c56604e819d2cb1da28...
Aaaah, I should have specified above that I don't use (or care about) the two-way audio in the frigate config.
Thanks for the info, I just hacked away at various config suggestions until one combination worked.
Cheers!
Do you use an outdoor camera with this? I'm trying to find one and my c402 does not appear to have that support.
Sorry no.
I use Reolink's for outdoor. The Tapo's are all indoor C210/C211 (cheap, but do the job just fine).
Looks like the C402 has two different hardware versions[0] so maybe the old one doesn't work but the new one does? A firmware upgrade might also be worth trying. This reddit page suggests trying ONVIF as the go2RTC connection[1].
Good luck!
[0]: https://www.tp-link.com/us/support/download/tapo-c402/
[1]: https://www.reddit.com/r/frigate_nvr/comments/1liosei/tapo_c...
go2rtc (discussed in another thread here) works flawlessly with that c402. I'm blown away.
Thanks for your comments.
The password `TPL075526460603` is also mentioned in CVE-2022-37255[1].
[1]: https://nvd.nist.gov/vuln/detail/CVE-2022-37255
go2rtc is great. the compatibility range it offers is just huge and gets rid of 90% of the difficulty in making a decent NVR app.
Got one for my house but what really annoyed me was that I wasn't able to set a fixed IP for it
On your dhcp server (probably your router/gateway), statically assign (reserve) the camera's MAC address to the IP that you want it to have. Sometimes called MAC binding.
Some of them support it but not all.
Really? Mine has a switch for static. You aren't seeing that in the app? Configuration -> Advanced settings -> Network
Confirmed here. I've got four of them, and they all have this setting. I know because I changed them from DHCP reservation to static IP recently.
Are any of these outdoor cameras? Do you use rtsp if so? I'm trying to find an outdoor camera that supports frigate and surprised my new c402 does not.
Every single post on this site is worth reading. Loads of fun with hacking electronics. :)
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?)
try reducing your buffer size and -probesize to help with that delay (and/or optionally fixing the video format parameters so probing isn't needed at all)
Interesting... from the terminal I see he named his laptop the same thing I've named one of my cheaper laptops too... craptop. LOL.
Hacking together something usable out of cloud-first piece of hardware you ended up with is respectable, but I would like to bring up another option to go with if you're choosing a new device: buy camera that doesn't require a phone app to initial setup and serves RTSP out of the box.
What cheap camera doesn't require a phone app and serves RTSP out of the box?
Note that I didn't say "cheap". If price difference comes from manufacturer's hope of selling its cloud service, then the time and effort required to set it up is not worth the money.
If I were to solve one-time task of keeping an eye on someone indoors I would go with USB camera (if lighting conditions allows even the laptop's build in), which is going to be cheaper than ones with IP and WiFi support.
The cover image is a 2.8M png, if the author is reading. I gave up my github account so cannot comment.
Now a ~300kB webp, thanks.
Oof, I need to go through my personal site and resize some images. I never considered that.
Also, fantastic write-up
Anyone have a similar fix for Yi/Kami cameras?
Yes Pls I'm begging u
[dead]