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

by kennedn • 10 months ago

556 175 10 months ago

gnabgib• 10 months ago

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)

tripdout• 10 months ago

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...

micah94• 10 months ago

So we're at the point that finding hardcoded admin passwords is no big deal.

j45• 10 months ago

Smartphones can be seen by some as the initial hostile devices.

Network devices can at least be monitored and discovered like this.

xp844• 10 months ago

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.

hleszek• 10 months ago

Home Assistant is making more and more sense to make your own fully local and private home automation system.

mtlynch3• 10 months ago

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.

bri3d9• 10 months ago

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.

m463• 10 months ago

on the other hand "onboarding" seems to be a less offensive normalizing word which really means "ask permission to use device"...

lo0dot02• 10 months ago

"if you don't know what you're doing don't do it" vs. "Secure out of the box"

some_random5• 10 months ago

Hard coded admin passwords that you have to change in order to start using the device aren't really an issue.

jama2112• 10 months ago

Well, they aren’t here though.. I feel like you just wanted to be annoyed at this tech

HexPhantom3• 10 months ago

Hardcoded admin creds should've gone extinct with Flash-based websites, but here we are

GuinansEyebrows• 10 months ago

Thank you for including the final part about what your dog has been up to :)

ssgodderidge• 10 months ago

"She sleeps"

The fact that OP did all this work to find out the dog sleeps is pure hacker culture. Love to see it :)

201984• 10 months ago

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

bri3d9• 10 months ago

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.

josteink• 10 months ago

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.

mschuster912• 10 months ago

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.

crowfunder3• 10 months ago

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

pimterry3• 10 months ago

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.

pimterry3• 10 months ago

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.

Gualdrapo• 10 months ago

Got one for my house but what really annoyed me was that I wasn't able to set a fixed IP for it

hank808• 10 months ago

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.

crazysim• 10 months ago

Some of them support it but not all.

xrd7• 10 months ago

Really? Mine has a switch for static. You aren't seeing that in the app? Configuration -> Advanced settings -> Network

BLKNSLVR5• 10 months ago

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.

pooloo• 10 months ago

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

jama2112• 10 months ago

Or just because she noticed she was cold

serf• 10 months ago

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.

ComputerGuru• 10 months ago

Anyone have a similar fix for Yi/Kami cameras?

bstsb• 10 months ago

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)

jraph2• 10 months ago

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.

concats• 10 months ago

> 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?

pessimizer• 10 months ago

The cover image is a 2.8M png, if the author is reading. I gave up my github account so cannot comment.

kennedn5• 10 months ago

Now a ~300kB webp, thanks.

awilson5454• 10 months ago

Oof, I need to go through my personal site and resize some images. I never considered that.

Also, fantastic write-up

ck2• 10 months ago

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"

g-mork• 10 months ago

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)

fnord77• 10 months ago

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

downrightmike• 10 months ago

Mon key toge ther strong

pimterry3• 10 months ago

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.

stavros• 10 months ago

HTTP Toolkit is fantastic, great job Tim!

cute_boi• 10 months ago

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.

kennedn5• 10 months ago

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 \

    -l ./config.js \

    -l ./android/android-proxy-override.js \

    -l ./android/android-system-certificate-injection.js \

    -l ./android/android-certificate-unpinning.js \

-f com.tplink.iot

rcarmo• 10 months ago

Every single post on this site is worth reading. Loads of fun with hacking electronics. :)

johng• 10 months ago

Interesting... from the terminal I see he named his laptop the same thing I've named one of my cheaper laptops too... craptop. LOL.

selinkocalar• 10 months ago

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.

teaearlgraycold• 10 months ago

The solution is pfsense

arminiusreturns• 10 months ago

The soulutions is iptables.

The solution is nftables.

The solution is bpf.

The solution is emacs-m-x-butterfly-bpf.

baby_souffle• 10 months ago

Or openWRT.

The bsd based distributions sure are powerful, but with the power/heat budget to match.

nuker• 10 months ago

Better go OPNsense

drnick12• 10 months ago

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).

java-man• 10 months ago

IOT - "S" stands for "Security"!

BLKNSLVR5• 10 months ago

The password for my IoT wifi is "TheSInIoT"

;)

briHass• 10 months ago

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.

drnick12• 10 months ago

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.

ThatMedicIsASpy• 10 months ago

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.

cortesoft• 10 months ago

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.

tharkun__• 10 months ago

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.

Gigachad• 10 months ago

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.

johncolanduoni3• 10 months ago

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.

TomaszZielinski• 10 months ago

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.

protocolture• 10 months ago

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.

ByteDrifter• 10 months ago

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.

t-3• 10 months ago

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.

pabs33• 10 months ago

A lot of them violate the GPL and BSD licenses too.

fsckboy• 10 months ago

they violate the BSD license by not acknowledging the Regents of the University of California?

fulafel• 10 months ago

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.

lazide2• 10 months ago

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.

lo0dot02• 10 months ago

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".

levid042• 10 months ago

Yes Pls I'm begging u

BLKNSLVR5• 10 months ago

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>

Main section:

  <Camera name>:
    ffmpeg:
      output_args:
        record: preset-record-generic-audio-aac
      inputs:
        - path: rtsp://127.0.0.1:8554/<Camera RTC name>_sub
          input_args: preset-rtsp-restream
          roles:
            - detect
        - path: rtsp://127.0.0.1:8554/<Camera RTC name>
          input_args: preset-rtsp-restream
          roles:
            - record
            - audio
    detect:
      enabled: true
      width: 640
      height: 360
      fps: 7
    live:
      streams:
        <Camera RTC name>: <Camera RTC name>
    record:
      enabled: true
      retain:
        days: 0
        mode: all

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.

xrd7• 10 months ago

Do you use an outdoor camera with this? I'm trying to find one and my c402 does not appear to have that support.

BLKNSLVR5• 10 months ago

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...

kennedn5• 10 months ago

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...

BLKNSLVR5• 10 months ago

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!

xrd7• 10 months ago

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.

kennedn5• 10 months ago

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...

xrd7• 10 months ago

Fantastic.

Why do you use rtsp for some streams and then tapo protocol for others? Are these all tapo cameras?

bayesianbot• 10 months ago

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

ChaoPrayaWave• 10 months ago

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.

TeMPOraL• 10 months ago

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.

cleartext4122• 10 months ago

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.

roygbiv2• 10 months ago

What cheap camera doesn't require a phone app and serves RTSP out of the box?

cleartext4122• 10 months ago

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.

ur-whale• 10 months ago

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.

marcosscriven• 10 months ago

Side note - “full-proof” is an eggcorn of “foolproof”.

NoPicklez• 10 months ago

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

otikik2• 10 months ago

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"

h4ch1• 10 months ago

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.

HexPhantom3• 10 months ago

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

mijoharas• 10 months ago

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.

wpm• 10 months ago

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

gslin• 10 months ago

The password `TPL075526460603` is also mentioned in CVE-2022-37255[1].

[1] https://nvd.nist.gov/vuln/detail/CVE-2022-37255

HexPhantom3• 10 months ago

This is the most gloriously overengineered way to find out your dog naps all day, and I respect the hell out of it.

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

Related Stories