TP-Link Tapo C200: Hardcoded Keys, Buffer Overflows and Privacy

This blog post is pretty readable, but it's still obviously written with the help of an LLM. A common trend is that LLMs lack the nuance and write everything with the same enthusiasm. So in a blogpost it'll infer things are novel or good/bad that are actually neutral.

Not a bad blogpost because of this, but you need to be careful reading. I've noticed most of the article on the HN front page are written with AI assistance.

> I found out that TP-Link have their entire firmware repository in an open S3 bucket.

Nobody tell them about Linux!

I think maybe you’re reading this wrong. Reverse-engineering blog posts like this are just a fun and instructive way of telling the story of how someone did a thing. Having written and read a bunch of these in the past myself, I found this one to be a great read!

Edit: just want to add, the “how I got the firmware” part of this is also the least interesting part of this particular story.

I didn't notice a negative tone at all when he talked about the firmwares being publicly hosted. You did?

Yep, I think it should always be that way, firmwares should be always available.

I didnt really interpret that as a particular criticism really

I think this kind of critique often leans too hard on “security through obscurity” as a cheap punchline, without acknowledging that real systems are layered, pragmatic, and operated by humans with varying skill levels. An open firmware repository, by itself, is not a failure. In many cases it is the opposite: transparency that allows scrutiny, reproducibility, and faster remediation. The real risk is not that attackers can see firmware, but that defenders assume secrecy is doing work that proper controls should be doing anyway.

What worries me more is security through herd mentality, where everyone copies the same patterns, tooling, and assumptions. When one breaks, they all break. Some obscurity, used deliberately, can raise the bar against casual incompetence and lazy attacks, which, frankly, account for far more incidents than sophisticated adversaries. We should absolutely design systems that are easy to operate safely, but there is a difference between “simple to use” and “safe to run critical infrastructure.” Not every button should be green, and not every role should be interchangeable. If an approach only works when no one understands it, that is bad security. But if it fails because operators cannot grasp basic layered defenses, that is a staffing and governance problem, not a philosophy one.

I have my cameras connected to a N150 server running hostapd and dnsmasq and no IP forwarding. That server runs Frigate. I figured if I need a server anyway it might as well be the AP.

It's a little bit of a pain to set up the cameras because of the mobile app. I have to connect to the AP on my phone and as it doesn't have internet access my phone nags me, and this specific model doesn't have an external antenna. If it did I think it might be the ideal setup.

A friend once asked me to do some pen-testing on a machine he was running on his home network. He said I'd need to come round to his house to do this as he didn't want to provide access to the machine via the Internet. Fair enough.

When he opened his front door the conversation went something like this:

    Him: "Ah hello, thanks for coming round to do this. It should be fun, come in and we can get started."
    Me: "OK, but I'm already done."
    Him: "What?"
    Me: "I'm done. I've already got root on the machine and I left a little text file in root's home directory as proof."
    Him: "What? But ... what? Wifi?"
    Me: "Nope. Let me in and I'll explain how."

The short story is he had an PoE IP-based intercom system on his front gate. I remembered this from when he was going on about his plans for his home network setup and how amazing PoE was and how he was going to have several cameras etc. I also remember seeing the purple network cable sticking out of the gate pillar whilst the renovation work was being done and the intercom hadn't yet been installed.

I'd arrived 45 minutes early, unscrewed the faceplate of the intercom system and, with a bit of wiggling, I got access to a lovely Cat-5 ethernet jack. Plugging that into my laptop I was able to see his entire home network, the port for the intercom was obviously not on its own VLAN. Finding and rooting the target machine was a different matter but those details are not relevant to this story.

I suppose I got lucky. He could have put the IoT devices on separate VLANs. He could have had some alerting setup so that he'd be notified that the intercom system had suddenly gone offline. He could have limited access to the important internal machines to a known subset of IPs/ports/networks.

He learned about all of the above mitigations that day.

I've always wondered just how many people have exposed their own internal network in a similar way when trying to improve their external security (well, deterrent, not really security) but configuring it poorly.

do you happen to have a guide on how to achieve this - I am fairly technical but still configuring Vlans and moving devices there would be good with some step by step instructions.

I looked at some older Zyxel products and came to the same conclusion a while back. There's a whole industry of labeling generic hardware as being part of someone's else ecosystem

https://www.hydrogen18.com/blog/hacking-zyxel-ip-cameras-pt-...

https://www.hydrogen18.com/blog/hacking-zyxel-ip-cameras-pt-...

They lend themselves to local connections, however, so they are workable for the tech savvy.

Definitely a problem for regular users.

it does not, there are 5 versions of C200 as of now and thingino only supports one or two, it is very important to get the right chip, you can check https://openipc.org/

I came here to post this, too :) What the thingino community managed to do with their firmware for these cameras is nothing short of amazing - if you happen to have a compatible camera, you really, really should give it a whirl!

> This is so bad that it must be intentional, right? Even though these are dirt cheap, they couldn't come up with $100,000 to check for run-of-the-mill vulnerabilities?

The camera sells for $17.99 on their website right now.

Subtract out the cost of the hardware, the box, warehousing, transit to the warehouse, assembly, testing, returns, lost shipments, warranty replacements, support staff, and everything else, then imagine how much is left over for profit. Let's be very optimistic and say $5 per unit.

That $5 per unit profit would mean an additional $100,000 invested in software development would be like taking 20,000 units of this camera and lighting them on fire. Or they could not do that and improve their bottom line numbers by $100,000.

TP-Link has a huge lineup of products and is constantly introducing new things. Multiply that $100,000 across the probably 100+ products on their websites and it becomes tens of millions of dollars per year.

The only way these ultra-cheap products are getting shipped at these prices is by doing the absolute bare minimum of software development. They take a reference design from the chip vendor, have 1 or 2 low wage engineers change things in the reference codebase until it appears to work, then they ship it.

Some cameras that "charge" with USB also can use a USB network adapter (provided they can supply power).

For the tech savvy, there is thingino as a firmware alternative - works local only, no cloud, and supports mqtt etc.

It's been long known many older TP-Link IoT devices doesn't require any authentication to connect, as my Kasa HS300 strips. Later models requires the account credential [1], but I'm not surprised that they still left something wide open (e.g., WiFi config endpoint for provisioning). I tend to believe this is just poor software engineering (Hanlon's razor).

[1] https://www.home-assistant.io/integrations/tplink/

Don't put them on untrusted networks. This always seemed obvious to me.

> I assume any Wi-Fi camera has basically the same problems.

ftfy

In ipv4 these will be src-natted and thus have a statefuo firewall by necessity.

In IPv6 they likely will auto configure onto a public ip address which may not have a stateful firewall.

Good thing some tapos do have alternative firmware like thingino.

If you call up your contactless payment provider, most will send you a physical device that will do contactless payments on its own, for free even. You can tape it to the back of your phone, or anywhere else for that matter.

I think when your political views cloud your ability to take in information on an objective level, it might be bad.

I think it's hard to say. Grok is pretty good and also fairly free with good usage limits.

Every single AI company in my opinion is committing fairly grave misdeeds with the ruthless scraping of the internet and lack of oversight.

Not to mention the shady backdoor deals going on with big tech and the current administration.

Grok is also pretty bad with its whole gas turbines in one state and datacenter in another and some possible environmental issues

It's more of a pick your poison at this point

It's worth interacting with all models. In my experience, for programming questions grok delivered better answers than ChatGPT (and Claude) often enough that at some point I wasn't sure which model I should be asking first.

No, because it allows us to evaluate the type of person you are. For example, I can tell you're a member of Bluesky.

Which AI providers have access to real-time Twitter data?

not necessarily worried, but like put on some pants before entering the room

If it's isolated from the Internet, no.

As @tehlike said in a sibling comment, it looks like it is supported by https://thingino.com, so you can 'update' the firmware to a more secure (and FOSS) one!

Per the article, the attacker can restart the camera and potentially find the accurate position of it. However, if the attacker can be physically in proximity within the camera range, they can MITM it and intercept the video feed. So it depends on your friend's threat model. If the camera is recording something in a public location and they don't mind the location being exposed and potentially the video feed (like plenty of live public cameras), then it shouldn't be an issue. Otherwise, they need to disable it until it gets fixed.

Yep

If the firmware is not open and buildable, then it can only be an untrustable black box.

If you don't want untrustable black boxes hanging around, then your options become pretty limited.

You can DIY something with an SBC like a Raspberry Pi or whatever. You can hang USB cameras off of your computers like it's 2002 again. You can try to find something that OpenIPC or thingino or whatever supports. (You'll never finish with this project as the years wear on, the hardware fails, product availability ebbs and flows, and the scope changes. Maybe that sounds like a fun way to burn time for someone, but it doesn't sound like fun to me.)

Or, you can accept that the world is corrupted -- and by extension, the cameras are also all corrupted.

The safe solution is then actually pretty simple: Use wired-only cameras that work with Frigate (or whatever your local NVR of choice may be), keep them on their own private VLAN that lacks Internet access, and don't worry about it.

The less-safe solution is also pretty simple: Do what everyone else is doing, and just forget the problem exists at all. Switch your brain off, buy whatever, and use it. (And if there's an area that you don't want other people to see, then: Don't put a camera there.)

(We probably are not as interesting as we may think we are, anyway.)

I've installed Thingino on my cameras such as this. Cheap camera + custom (local only!) firmware is a good solution imo.

No guarantee that it'll be perfect either, obviously, but it's open source and actively maintained. Highly recommended.