Noobs guide to turn off cloud?

[UmbraAtrox]

Hy, I have read everything and understood almost a third. from what i gathered you pwned the thing and have root shell. That's what i wanted too to turn off things until it goes from smart ip cam to just a ip cam that won't work with its app, not talk to any cloud, but only gives a stream when given a password.

Soldering etc is no problem but tbh when that one guy said changes don't persist across power down because doesn't write to flash because idk https://github.com/nervous-inhuman/tplink-tapo-c200-re/issues/1#issuecomment-792362191 i've practically given up because my gnunix is wonky as it is, wtf do i do when the thing reboots and suddenly wants to cloud?

Do you know, can you tell me, how to make those c200 a dumb cam?

[striderwhite]

I am currently working on this @UmbraAtrox actually.

I think you should be able to block all outgoing traffic from the device on your home router. This would effectively kill its cloud access - at least, this was my plan.

These are a few ideas and my plan of attack right now:

1. Better understanding how the camera is sharing its feed: MITM between cam and my network and MITM between android and network/cam to better understand how both the camera actually broadcasts its feed and how the mobile app requests its feed. This will likely influence alot of my path forward, or try to take advantage of current RE efforts
2. I am considering flashing the known vuln firmware try to and exploit the possible RTSP vuln "RTSP and Possible Authentication Bypass" documented here: https://drmnsamoliu.github.io/video.html - I fiddled around with the RTSP service and created a python script that interacts with it to some extent but haven't been able to authenticate - I haven't reversed the binary on my current devices firmware to see if this vuln is still there or not. There may also be other vulns in the binary which have not been discovered yet

From what I understand, the RTSP approach may be the best way to do this, especially considering there is a possible vuln to bypass authentication. I am not an expert on RTSP, but basically this protocol acts as a "remote control" and a liaison for accessing video streams. Once its authenticated you can ask for resource streams which you can then process for video. I think its a matter of bypassing authentication here then figuring out a way to handle the data stream.

As an aside to answer your question a little bit better in terms of a persistent attack, you could unpack the firmware image, patch your modifications to the firmware (for example enabling telnet in the bootstrap script if it was disabled), then reflashing it. I didn't really fully read or understand this: https://drmnsamoliu.github.io/telnet.html yet, but it looks like they try to do is exploit a command injection at runtime. The approach I am suggesting here will actually modify the firmware itself. This is a topic I want to explore more because theoretically you modify any binaries on the firmware to introduce whatever code you want, but requires good RE and assembly skills. There are some good videos on this general topic, mostly about extracting: https://www.youtube.com/watch?v=GIU4yJn2-2A and https://www.youtube.com/watch?v=hV8W4o-Mu2o - the latter being a bit more in-depth in terms of "repacking" the image. This is a much more advance topic though and something I am currently not able to do (but interested in!) EDIT: Also it popped into my head that if you have root access, you could technically just modify/patch a binary right on the disk of the embedded system itself. This would be persistent until a new firmware flash (which you can actually disable auto updates in the Tapo app). This is more straightforward then trying to create a modified firmware update.

I think the best approach is to flash an older version of the firmware on the device and reverse some of the binaries responsible for the RTSP service, HTTP service, and video feed, to find possible vulnerabilities and exploit those.

[DrmnSamoLiu]

@striderwhite Just to save you some time:

Your idea of "if you have root access, you could technically just modify/patch a binary right on the disk of the embedded system itself." will work, but not as easy as I assume you thought. Most embedded devices use SquashFS for its rootfs to save space, and it is a read-only file system. So you cannot just write anything into it like you would on a PC. The only way to add or patch things is to pack a new SquashFS with your custom binaries and write it back to the flash chip. An exception is if there are write-able FS used in the device (for example, JFFS2). Then you can write anything you want with a shell. But in these Tapo cam's case AFAIK none of the models uses JFFS2.

---

By the way, someone reported in one of my repos that you can actually use localhost as username to trigger the RTSP bypass vuln if its still there, because the actual URL sent to the RTSP server is rtsp://username:password@IPaddr, so username localhost will be in the URL. I haven't tried it myself on a vulnerable FW version though.

Last time I checked, some student mentioned they reported the vuln to TP-Link in his/her master's thesis and iirc it surely was patched at some point.

[DrmnSamoLiu]

To answer the original question:

The easiest way to avoid the cam connecting to cloud is to block all the cloud domains on your router. You can't really do much on the device side if you don't have the knowledge and hardware to modify the flash content. The OTA firmware is signed and checked when performing the "SD card downgrade" mentioned in other issues here, so modifying the OTA firmware and try to flash it will not work.