Summary Following our hacking of Xiaomi home security cameras, we have decided to look at another market dominating vendor in our region, TP-LINK. In this post, we describe the major findings from our review of new generation TAPO security cameras: a pre-auth RCE stack BOF that can be exploited not only from the LAN but also from the WAN as a browser exploit, a severe authentication bypass vulnerability that allows the exploitation of 10+ post-auth and RCE-able vulnerabilities that we also identified in the HTTP and ONVIF server implementations (all patched in TP-Link’s April advisories), including a heap BOF that we also fully exploited for RCE, another authentication bypass vulnerability similar to the previous; this vulnerability remains unpatched today, with an advisory promised for April 20th but it did not happen a cryptographic design weakness that can enable a full cloud account compromise just from network access to one TP-LINK device of the cloud account; this vulnerability also remains unpatched today, with a patch promised for May All told, in the worst case, our findings would enable an attacker to go from a victim visiting a malicious link via browser from within the same LAN as their TP-LINK smart camera, to full takeover of every TP-LINK smart device connected to the cloud account of the user.

In this blogpost, the newest full-time member of our research team describes his internship project. If you would also like to try your hand at our hacking tools and techniques, don’t hesitate to check out our training offerings! Currently available: https://www.offensivecon.org/trainings/2026/exploiting-smartphones-through-baseband.html Last summer, I had an opportunity to join TASZK Security Labs for a summer internship. The target we selected for this 2 months project was to hack Xiaomi Security Cameras, specifically a Xiaomi C400 Smart Camera, a very popular device in our market that we also happened to already have at hand. We defined two end goals: create an RCE exploit via any wireless/LAN interface use the exploit to create a full “cloud jailbreak” The motivation for the latter was that we knew that these devices are heavily dependent for their operation on the Xiaomi Smartphone Application and Xiaomi Cloud Server.

In the past few years, we’ve tried our hand at Vulnerability Reward Programs of all kinds of mobile vendors’ products and attack surfaces. Like many others, we’ve encountered as many misses as hits, learning valuable lessons from the mistakes we (and sometimes the vendors) have made. We presented our experiences in a talk this summer at Troopers and Le Hack. You can download the slides from here. A video of the presentations is not available yet, but the Troopers one will eventually be available here. The talk covered several VR projects which were discussed publicly for the first time. We have now released advisories for all of these newly discussed vulnerabilities, including:

Once upon a time, I started at TASZK Security Labs as an intern. My internship project was about hacking hypervisors, and the target we picked for it was Huawei’s HEE (Hypervisor Execution Environment). The research was carried out in late 2020 to early 2021. Although we didn’t publish this work all the way until 2025, it was kept relevant by the fact that the issues remained unaddressed, to the best of our knowledge. If that piqued your interest in the story of the disclosure, please check out our recent Troopers/LeHack talk titled Eastern Promises. In this blogpost, I’ll focus on the technical aspects of the project.

We have written extensively about remote baseband vulnerability research in the past, examining various vendors’ baseband OS micro-architectures and exploring their implementations for remotely exploitable bugs. So have many others. One might say, our research exists in the context in which it lives and what came before it: whether it be about finding (1, 2, 3, 4, 5, 6, 7) or exploiting (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14) vulnerabilities. However, one area that has been absent from prior art was a direct examination of lower layers of Radio Layer protocols for security vulnerabilities.

In our previous blog post, we have introduced our latest research into full chain baseband exploits. We have showcased new research tools (our nanoMIPS decompiler, debugger, and emulator for Mediatek basebands) and explored the interconnected components across the Cellular Processor and the Application Processor of Samsung and Mediatek radio interface stacks. The most serious of vulnerabilities in these interfaces can lead to over-the-air exploitation of the device: zero-click remote code execution not only in the baseband, but in the Android runtime as well. It’s no secret that baseband full-chains of this kind have existed privately and been used In-The-Wild, as recently documented by the “Predator Files” disclosures, for example.

Additional posts in this series: Part 1 Part 3 If you’ve watched my Basebanheimer talk, you will have noticed that concrete ideas for exploiting CVE-2022-21744, a heap buffer overflow in Mediatek baseband, were omitted from the talk for brevity. This heap overflow vulnerability has an important limitation: the overwriting value is a pointer to an allocation with attacker controlled bytes. In other words, as explained in the talk, we aren’t controlling the bytes we corrupt with directly, we write 4 byte pointer values that each point to an allocation with content controlled by the attacker. This creates new challenges, since the Mediatek heap exploitation techniques that we disclosed in 2022 would not apply directly due to the nature of our overwrite primitive.

Additional posts in this series: Part 1 Part 2 In my Basebanheimer talk at Hardwear.io, I explained a method for exploiting the Mediatek Baseband Pivot vulnerability CVE-2022-21765 for arbitrary code execution in the Linux kernel on Mediatek’s older (“Helio”) chipsets, which use 32-bit kernels. I also mentioned that using previous ideas, the vulnerability could theoretically be exploited on Mediatek’s newest chipset family (Dimensity, which uses 64-bit kernels) as well. After the conference, with my college Lorant Szabo we have completed this exercise. The vulnerabilities: CVE-2022-21765 and CVE-2022-21769 To recap, the vulnerabilities provide an OOB read/write in the Linux kernel driver that implements the Application (AP) and Cellular Processor (CP) interface, which Mediatek calls the CCCI driver.

Talks about baseband vulnerabilities are certainly in fashion these days. However, most publications so far omit the step of escaping the baseband runtime. With the novelty of baseband-only vulns wearing off, we decided to look at some popular targets (Samsung and MediaTek smartphones) with full chain exploitation in mind. Over the last year, our research has resulted in a dozen+ CVEs, including both remote code execution vulnerabilities and baseband-to-Android pivot vulnerabilities. I will be presenting the details of our work at the upcoming Hardwear.io conference, where we’ll also deliver a training on the subject. Full vulnerability details will be held back until the conference at vendor request.

Last year we published UnZiploc, our research into Huawei’s OTA update implementation. Back then, we have successfully identified logic vulnerabilities in the implementation of the Huawei recovery image that allowed root privilege code execution to be achieved by remote or local attackers. After Huawei fixed the vulnerabilities we have reported, we decided to take a second look at the new and improved recovery mode update process. This time, we managed to identify a new vulnerability in a proprietary mode called “SD-Update”, which can once again be used to achieve arbitrary code execution in the recovery mode, enabling unauthentic firmware updates, firmware downgrades to a known vulnerable version or other system modifications.