since GLM 5.2 (perhaps even earlier?) it has been remarkably easy to reverse engineer any closed protocol you want as long as you have a binary. previously, it required so much manual effort as to simply not be worth it 95% of the time.
now all you need is IDA or Ghidra MCP, a binary and some vague sloppy instructions.
some more recent models even started instrumenting a running binary (when possible) to enumerate the protocol without being explicitly instructed to, which is even better.
You don't even need an MCP, I just let the agent write scripts for headless ghidra. The MCPs are fragile and there isn't a whole lot of knowledge about how to use them in the training datasets, whereas there are plenty of ghidra scripts (and proper docs for the APIs).
Seriously, though, the popular Ghidra MCP is really badly architected; it's way better to rearchitect it or just script Ghidra directly. With that said, Opus 5.5 seems to have been trained on CoT from the popular Ghidra MCP. This makes it work better, but also makes it even more inefficient if you modify the MCP without changing its name and shape significantly (it will try to make tool calls using the "mainline" format, then have to retry them when they fail).
Even with Opus 5.5, IMO it's better to just ditch the MCP and let the LLMs eat with bintools and headless Ghidra; with both GLM and Opus this produces significantly more efficient results than the popular MCP. On the other hand the IDA Pro MCP is much better architected and seems to be pretty good.
> there isn't a whole lot of knowledge about how to use them in the training datasets
if you include a SKILL.md for the MCP (or just dump it into the prompt) it's not a problem.
I don't use Ghidra but IDA Pro MCP works extremely well for me for all manner of tasks. for example, some software likes to call home for license checking (and I wish to run it with networking denied to it). it no longer does.
Without admitting to anything, I was surprised by how little time it took to add support for the new protocol to the library. And I didn't even need an MCP server.
I've had good luck aiming for easier targets. Android APKs, Java, and .NET binaries are usually easy to reverse engineer with AI and without any advanced tooling.
I feel like I'm either too dumb to get this, or not the target audience. I don't know what a Tapo is, but it's apparently a library to interact with Tapo devices, whatever that might be. And now it can talk TPAP, whatever that is. TP-Link is mentioned, so I'll guess Routers and move on :)
Tapo devices are basically smart home stuff. You normally have to use their ecosystem to control those devices, i.e. use their apps etc. However, people do not like the fact that you're locked in those apps and want to use those devices via platforms like Homeassistant, so people figure out how to do it by tricks like this.
They’re also a cheap way to get into BirdNET and Apple HomeKit Secure Video if you get their cheapest security cams that have some weather proofing. You can get a microphone (and camera) outdoors without having to shell out a lot of money for a Raspberry Pi + microphone + all the protective casing required to keep it from breaking.
With software like Scrypted or Frigate, I was able to use an Apple TV 4K to get a security feed into my Apple Home with iCloud+. You don’t need to buy Homekit certified product.
They're also really cheap energy monitoring plugs, probably the cheapest from a known brand you can get. I also really like their light switches and they work great in HA. FWIW I also have them completely locked down on the network like all other IOT devices.
We should encourage each other to divest from hardware suppliers who are unfriendly to it's users. TP-Link should be publishing specifications to make it as easy as possible to interact with the hardware you purchase, not trying to maximize lock in or force you into a closed ecosystem.
The transaction should be you give them money, they give you hardware and as much information as they reasonably can to use it effectively and safely, repair it later if necessary, etc.
We have become used to having to take whatever we get as though consumers have no power in the market. Stop buying TP-Link hardware until they treat us as paying customers. Encourage other people to stop also. Don't buy hardware from manufacturers who treat you like crap, and don't participate in attempts to 'make it work' by reverse engineering it while they release firmware to break those attempts again and again. Stop funding your own opposition!
The point of the writing is thinking what you are about to say from difference perspectives. Now, everything gets average and boring if LLMs are getting used all the time. And they still waste so many words that don't benefit reader in any way.
I did my best with the writing, but it clearly didn't land for the two of you. Could you point to one thing, or one pattern, that bothered you most? That would help me improve it.
It's written like one of those long form magazine articles. Which is fine for that kind of thing but maybe not great for software release notes. It goes buildup buildup buildup ... underwhelming payoff.
The disclaimer at the end of the article says AI was used to "polish" the writing. I would guess it's this polish that can be a little off-putting: It reads like a magazine article written by and for people who aren't particularly interested in the topic.
I can bet author didn't even read his own AI generated text.... I don't have any issue with AI, but it would be nice if people spend time over creating quality stuff.
Author here. tapo is an unofficial Rust client library for TP-Link Tapo devices (plugs, lights, hubs, cameras), with a Python wrapper built on the same crate. It is not affiliated with TP-Link.
The short version: since late 2025, firmware updates have made Tapo devices refuse third-party clients unless you turn on a "Third-Party Compatibility" switch in the Tapo app. The switch works by bringing back the older login, KLAP. With it off, devices speak an undocumented protocol called TPAP, which logs in with SPAKE2+ (RFC 9383). The library now speaks TPAP, so the switch can stay off.
The part I found most interesting is the security difference. A recorded KLAP login can be used to test password guesses offline. With SPAKE2+ it can't, and learning the password later doesn't decrypt sessions captured earlier. So the "compatibility" switch is really a security downgrade, and TP-Link's own FAQ says enabling it "may reduce the security of your devices".
Not everything works with the switch off yet: some cameras, such as a C210 on firmware 1.5.2, still need it on.
Happy to answer questions about the protocol work or the library.
We appreciate you posting your work and engaging in the discussion. But it's a no-no on HN to post comments that are generated (including polished or translated) by LLMs or other text-generation tools.
The article is also AI, I recognize its style from a mile away. I don't mind it super much when it's yapping like this about what it did for the tasks that I myself gave it, but I don't enjoy it for reading pleasure on the off-times.
Totally AI-generated, sure. But saying "No AI edits" at all is going way too far, IMO. Taken to its logical extreme, that even bans using a spell-checker. And what about non native English speakers? Is it really wrong for them to use a translation tool so they can participate?
I mean, it's y'all's site, you can do what you want. But FWIW, I think making that too much of an absolute "bright line" is a net negative for HN.
I've built the same code but in swift. I've come to the exact same conclusions that you have on the protocol. I got Claude Code to implement TPAP compatibility solely by interacting with my local plugs, looking at the shape of responses and RFC 9383 to figure out it was SPAKE2+. It took a bit of time to figure out the last bit: that the SHA-1 of the password, then PBKDF2 with the plug's salt, split into two halves; a context of "PAKE V1" plus both sides' random numbers; empty identities
I have a handful of old TP-Link wifi switch devices, but I haven't kept up on the play by play developments. I just know at some point newer ones stopped working with that access method (and I haven't bought any since).
Is KLAP that old local-network UDP protocol with "XOR encryption" ? Or is that something else?
Does using TPAP with your library still require connecting the devices to their "cloud" (warning: surveillance!) ? Or does your library effectively restore the local-only workflow of never allowing the devices Internet access, and controlling them locally ?
That XOR protocol is a different one, and older than anything in the article. It is the original TP-Link Smart Home protocol used by the Kasa line (HS100, HS110 and similar): JSON on port 9999, obfuscated with an XOR autokey cipher, with no authentication at all.
Tapo devices never spoke it. Their original protocol was an AES passthrough over HTTP, KLAP replaced that in 2023, and TPAP is the newest. As far as I know, newer Kasa hardware and firmware moved to KLAP as well, which would explain why your access method stopped working on the newer ones. My library only covers Tapo devices; for Kasa, python-kasa is the one to look at.
On the cloud: the devices do have to be set up through the phone app with a TP-Link cloud account. Once set up, though, most functions of most devices can be used locally through the library, with neither the devices nor the library having internet access. The main catch is credentials: if you change the account password, for example, the devices need to be online for a little while to pick up the new one.
since GLM 5.2 (perhaps even earlier?) it has been remarkably easy to reverse engineer any closed protocol you want as long as you have a binary. previously, it required so much manual effort as to simply not be worth it 95% of the time.
now all you need is IDA or Ghidra MCP, a binary and some vague sloppy instructions.
some more recent models even started instrumenting a running binary (when possible) to enumerate the protocol without being explicitly instructed to, which is even better.
You don't even need an MCP, I just let the agent write scripts for headless ghidra. The MCPs are fragile and there isn't a whole lot of knowledge about how to use them in the training datasets, whereas there are plenty of ghidra scripts (and proper docs for the APIs).
I agree! Don't give it away!
Seriously, though, the popular Ghidra MCP is really badly architected; it's way better to rearchitect it or just script Ghidra directly. With that said, Opus 5.5 seems to have been trained on CoT from the popular Ghidra MCP. This makes it work better, but also makes it even more inefficient if you modify the MCP without changing its name and shape significantly (it will try to make tool calls using the "mainline" format, then have to retry them when they fail).
Even with Opus 5.5, IMO it's better to just ditch the MCP and let the LLMs eat with bintools and headless Ghidra; with both GLM and Opus this produces significantly more efficient results than the popular MCP. On the other hand the IDA Pro MCP is much better architected and seems to be pretty good.
5 replies →
if you include a SKILL.md for the MCP (or just dump it into the prompt) it's not a problem.
I don't use Ghidra but IDA Pro MCP works extremely well for me for all manner of tasks. for example, some software likes to call home for license checking (and I wish to run it with networking denied to it). it no longer does.
2 replies →
Without admitting to anything, I was surprised by how little time it took to add support for the new protocol to the library. And I didn't even need an MCP server.
I've had good luck aiming for easier targets. Android APKs, Java, and .NET binaries are usually easy to reverse engineer with AI and without any advanced tooling.
I feel like I'm either too dumb to get this, or not the target audience. I don't know what a Tapo is, but it's apparently a library to interact with Tapo devices, whatever that might be. And now it can talk TPAP, whatever that is. TP-Link is mentioned, so I'll guess Routers and move on :)
https://www.tapo.com/us/
>Tapo is a brand of TP-Link that offers smart home solutions, such as security cameras, plugs, bulbs, switches, and more.
and TPAP is the "TP-Link Authentication Protocol" which, i believe, is based on 802.1X (https://en.wikipedia.org/wiki/IEEE_802.1X)
Tapo devices are basically smart home stuff. You normally have to use their ecosystem to control those devices, i.e. use their apps etc. However, people do not like the fact that you're locked in those apps and want to use those devices via platforms like Homeassistant, so people figure out how to do it by tricks like this.
They’re also a cheap way to get into BirdNET and Apple HomeKit Secure Video if you get their cheapest security cams that have some weather proofing. You can get a microphone (and camera) outdoors without having to shell out a lot of money for a Raspberry Pi + microphone + all the protective casing required to keep it from breaking.
With software like Scrypted or Frigate, I was able to use an Apple TV 4K to get a security feed into my Apple Home with iCloud+. You don’t need to buy Homekit certified product.
They're also really cheap energy monitoring plugs, probably the cheapest from a known brand you can get. I also really like their light switches and they work great in HA. FWIW I also have them completely locked down on the network like all other IOT devices.
We should encourage each other to divest from hardware suppliers who are unfriendly to it's users. TP-Link should be publishing specifications to make it as easy as possible to interact with the hardware you purchase, not trying to maximize lock in or force you into a closed ecosystem.
The transaction should be you give them money, they give you hardware and as much information as they reasonably can to use it effectively and safely, repair it later if necessary, etc.
We have become used to having to take whatever we get as though consumers have no power in the market. Stop buying TP-Link hardware until they treat us as paying customers. Encourage other people to stop also. Don't buy hardware from manufacturers who treat you like crap, and don't participate in attempts to 'make it work' by reverse engineering it while they release firmware to break those attempts again and again. Stop funding your own opposition!
Reads like AI slop.
AI is still contributing far more to this discussion than you are.
I was always taught: Read good books, that's how you'll write.
I don't even really care AI or human if its written like this. I would rather do anything else than continue reading.
Yeah. I read the first 5 paragraphs, and that's as far as I could get.
"At least nine issues tell the same story"
"every change lands in both at once"
It's Claudlish, so of course a community full of people who spend lots of time talking to Claude would notice this.
Hard to disagree. I'm interested, but... the writing sucks.
And there's no excuse now anyway the latest Opus/Astra models are actually tolerable. Use those if you must.
The point of the writing is thinking what you are about to say from difference perspectives. Now, everything gets average and boring if LLMs are getting used all the time. And they still waste so many words that don't benefit reader in any way.
I'm thinking it might be ESL and/or translated, but I could be wrong. There are posts from 2022, but they seem a lot more terse.
Not being able to effectively proofread will make slop even sloppier.
I did my best with the writing, but it clearly didn't land for the two of you. Could you point to one thing, or one pattern, that bothered you most? That would help me improve it.
5 replies →
What do you think is bad about the writing? It seems fine to me. What do you mean by "written like this"? What is this?
It's written like one of those long form magazine articles. Which is fine for that kind of thing but maybe not great for software release notes. It goes buildup buildup buildup ... underwhelming payoff.
The disclaimer at the end of the article says AI was used to "polish" the writing. I would guess it's this polish that can be a little off-putting: It reads like a magazine article written by and for people who aren't particularly interested in the topic.
[flagged]
5 replies →
Were you not also taught to "say something nice or nothing at all?"
There's no reason to be this nasty. If you don't like the writing, skip the post.
For what it's worth, the writing is clear and it gets the point across.
OP, thank you for doing the work and for sharing it.
How is he being nasty?
I can bet author didn't even read his own AI generated text.... I don't have any issue with AI, but it would be nice if people spend time over creating quality stuff.
3 replies →
Author here. tapo is an unofficial Rust client library for TP-Link Tapo devices (plugs, lights, hubs, cameras), with a Python wrapper built on the same crate. It is not affiliated with TP-Link.
The short version: since late 2025, firmware updates have made Tapo devices refuse third-party clients unless you turn on a "Third-Party Compatibility" switch in the Tapo app. The switch works by bringing back the older login, KLAP. With it off, devices speak an undocumented protocol called TPAP, which logs in with SPAKE2+ (RFC 9383). The library now speaks TPAP, so the switch can stay off.
The part I found most interesting is the security difference. A recorded KLAP login can be used to test password guesses offline. With SPAKE2+ it can't, and learning the password later doesn't decrypt sessions captured earlier. So the "compatibility" switch is really a security downgrade, and TP-Link's own FAQ says enabling it "may reduce the security of your devices".
Not everything works with the switch off yet: some cameras, such as a C210 on firmware 1.5.2, still need it on.
Happy to answer questions about the protocol work or the library.
We appreciate you posting your work and engaging in the discussion. But it's a no-no on HN to post comments that are generated (including polished or translated) by LLMs or other text-generation tools.
See https://news.ycombinator.com/item?id=47340079.
Please write all comments by hand, from your own thoughts, and resist the temptation to copy+paste anything from a chatbot or translation tool.
The article is also AI, I recognize its style from a mile away. I don't mind it super much when it's yapping like this about what it did for the tasks that I myself gave it, but I don't enjoy it for reading pleasure on the off-times.
Totally AI-generated, sure. But saying "No AI edits" at all is going way too far, IMO. Taken to its logical extreme, that even bans using a spell-checker. And what about non native English speakers? Is it really wrong for them to use a translation tool so they can participate?
I mean, it's y'all's site, you can do what you want. But FWIW, I think making that too much of an absolute "bright line" is a net negative for HN.
1 reply →
I've built the same code but in swift. I've come to the exact same conclusions that you have on the protocol. I got Claude Code to implement TPAP compatibility solely by interacting with my local plugs, looking at the shape of responses and RFC 9383 to figure out it was SPAKE2+. It took a bit of time to figure out the last bit: that the SHA-1 of the password, then PBKDF2 with the plug's salt, split into two halves; a context of "PAKE V1" plus both sides' random numbers; empty identities
Great work!
I assume because it has Python wrapper, the HomeAsstant integration can make use of it soon?
Awesome work. Here is hope this will also help improve local access to Tapo devices in Home Assistant.
This is awesome, thanks for the work. I wish I'd come across it sooner.
One thing to keep an eye out for is a communication from TP link telling you to stop using their name.
Great work!
I have a handful of old TP-Link wifi switch devices, but I haven't kept up on the play by play developments. I just know at some point newer ones stopped working with that access method (and I haven't bought any since).
Is KLAP that old local-network UDP protocol with "XOR encryption" ? Or is that something else?
Does using TPAP with your library still require connecting the devices to their "cloud" (warning: surveillance!) ? Or does your library effectively restore the local-only workflow of never allowing the devices Internet access, and controlling them locally ?
That XOR protocol is a different one, and older than anything in the article. It is the original TP-Link Smart Home protocol used by the Kasa line (HS100, HS110 and similar): JSON on port 9999, obfuscated with an XOR autokey cipher, with no authentication at all.
Tapo devices never spoke it. Their original protocol was an AES passthrough over HTTP, KLAP replaced that in 2023, and TPAP is the newest. As far as I know, newer Kasa hardware and firmware moved to KLAP as well, which would explain why your access method stopped working on the newer ones. My library only covers Tapo devices; for Kasa, python-kasa is the one to look at.
On the cloud: the devices do have to be set up through the phone app with a TP-Link cloud account. Once set up, though, most functions of most devices can be used locally through the library, with neither the devices nor the library having internet access. The main catch is credentials: if you change the account password, for example, the devices need to be online for a little while to pick up the new one.
1 reply →
Note that KLAP, afaik, is only for the TAPO range of devices. Those are mostly cameras, doorbells, sensors, robot vacuums, and the like.
1 reply →
[flagged]