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.

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.

Recently we have disclosed new advisories related to the remote exploitation of Huawei smartphones. The research that led to these findings was motivated by analyzing new interfaces for remote code execution on a mobile platform. After our work on exploiting Huawei’s Kirin via its baseband interface, we wanted to explore the possibilities of logic bugs as RCE vectors in a modern smartphone chipset, as opposed to memory corruption scenarios that are more common in public research. Logic bugs can be the most powerful because they have the potential to bypass almost all the exploit mitigations that are the typical focus these days, like ASLR, N^X, sandboxing parser code, etc.

Today we share a fun little Huawei bug that adds a twist to our previous forays into Neural Networking-based exploitation of Android devices. In previous posts, we have shown that the Neural Networking features of modern Android devices can lead to serious - if quite traditional - vulnerabilities. This time, we present a vulnerability in which Machine Learning is not the culprit - but the tool we use to actually exploit a seemingly minor permission misconfiguration issue! Introduction This time last year while auditing vendor-specific filesystem node access rights, we’ve spotted an SELinux permission misconfiguration issue that, at first, looked somewhat innocuous: all untrusted applications could access a sysfs-based log file of condensed haptic event statistics.

Recently we have presented our research on the remote exploitation of Huawei basebands at Black Hat USA 2021. As part of our findings, we have identified several bootloader vulnerabilities in Huawei Kirin chipsets. In addition to that publication, we have also recently disclosed an additional bootrom vulnerability (CVE-2021-22429) in Huawei Kirins. As it has been publicized, many of these bootloader vulnerabilities were present in bootrom code. As such, it can come as a surprise that Huawei in fact created a mitigation which was published just before Black Hat, in a July OTA update (updates started from June 29th, to be precise).

Samsung’s neural processing framework has received a lot of attention from the security community since its introduction. Hardware isolation vulnerabilities have been demonstrated, both on the NPU and DSP cores (1, 2), that could be used to compromise the kernel. The surrounding kernel code was also exploited by multiple researchers to gain local privilege escalation (1, 2). I, too, explored in a previous blog post how a kmalloc overflow within the Samsung NPU kernel driver can be exploited to gain arbitrary kernel read/write access. As a follow up work, I’ve decided to investigate Huawei’s implementation of their neural processing framework. Despite being the second largest vendor on the Android market, recently there have been lot fewer technical papers published about the security of their devices.