For the second edition of Off-By-One, RandoriSec went to Singapore and attended this nice and welcoming conference. Thanks to all those involved in making this great event!
Spyware for rent & the world of offensive cyber - Fred Raynal
For the first talk of this Off By One 2025 edition, the keynote was given by a very well-known French guy: Fred Raynal, the famous ‘pappy’ (CEO of Quarkslabs, which was also sponsoring the event). This was not a technical talk like we are used to; instead Fred Raynal presented the landscape of private spyware companies which are mostly targeting mobile phone devices.
He started by a quick presentation about the definition of a spyware software and what is the purpose of thus type of tool. He presented how the initial access is performed now with 0-day vulnerabilities, mostly 0-click, and that a whole ecosystem emerged on top of that: Researchers, Brokers, Investors, and so on. The second parts of the presentation focused on the marketing, pricing and economy employed by these companies. Most of these companies label themselves as good guys, selling only to trusted government for hunting terrorist and pedophiles. Actors of these companies (CEO, Researchers, etc.) are often found in other structures, linked together. Fred introduced the work made by DFRLab, which is actively watching these actors, and mapping them. Many of these actors are “serial entrepreneurs”, which can be found in many different companies. When one structure closed or is publicly burned, one other is born, like a Hydra. These structures are opaque in many ways: relying on obscured ownership through offshore registration, with front man, using legal loopholes to easily export their products.
Fred introduced many concepts about this opaque world, this was a nice keynote, even if there was a bias since the beginning.
Patch Diffing, You Are My Sword! A Deep Dive into Two Critical N-day Vulnerabilities in FortiGate - Qian Chen & Zibo Li
The talk explores two critical n-day vulnerabilities discovered in FortiGate firewalls. Their work focuses on the use of patch diffing, a technique that involves comparing a vulnerable binary with its patched version to identify changes introduced by a security patch. This makes it easier to identify the parts of the code affected by a vulnerability. The researchers were targeting two vulnerabilities in particular: CVE-2024-23113, a format string vulnerability in the fgfmd service, and CVE-2024-21762, an out-of-bounds write in the sslvpnd module.
They begin by outlining the difficulties associated with analyzing FortiGate, in particular the fact that the /bin/init binary is 70 MB and contains almost all the services, which makes patch diffing complex. To get around this, they suggest logically splitting the binary into sub-components (such as fgfmd, httpsd, sslvpnd, etc.), making it possible to isolate the areas of interest and better analyze changes between versions.
The CVE-2024-23113 flaw affects the communication protocol between FortiGate and FortiManager (FGFM). The bug lies in the misuse of the snprintf function with an insecure format string. To analyze this flaw, they are using a partial firmware emulation technique, in particular with tools such as QEMU and Qiling, to reach the vulnerable functions without having to emulate the entire system.
Exploitation Against the Clock: Xiaomi S3 Smartwatch - Sergei Volokitin
A talk about describing the findings from the HardPwn event in Hardwear.io Netherlands 2024 conference. This event consists of 3 days to find vulnerabilities, exploit and report it to the vendor. Sergei chose the Xiaomi Outdoor Camera BW500 and Xiaomi S3 Smartwatch from the available targets, and started hardware hacking. In his presentation, he explains different levels of hardware hacking, from UART to laser injection faults.
The camera runs U-Boot from SPI memory, then loads Linux OS from flash. From the storage’s content, he extracted two sensitive user tokens.
Then, he presented features of the smartwatch and why it is an interesting target for attackers: it holds personal information, payment cards and allows unlocking associated Xiaomi phone. The smartwatch has two buttons, a touchscreen and wireless communication (BLE, NFC). Opening it to access the PCB, an unpopulated SoC header appears, strangely, and an eMMC chip is identified.
Through analysis of the eMMC, he extracted multiple partitions. Notably one called Coredump, with logs from previous executions but no user’s PIN. While we could fly to the moon with only one OS on Apollo, the smartwatch has actually 4 concurrently running OS: TEE (Trusted Execution Environment), AP (Application Processor), Audio, and CP (Communication Processor), all based on Apache NuttX RTOS. The logs from the TEE are obfuscated, maybe with an error message CRC and an error code, but the AP logs successful PIN verification.
Just before PIN verification logs are touchscreen logs including X and Y coordinates of the touch on the screen! Using a previous failed attempt where Sergei tried the 000000 PIN, he could confirm the coordinates can be translated to one of the buttons of the locked keyboard and found out the actual PIN number. An example real-life scenario consists of stealing the device, unsoldering the eMMC, analysing logs, resoldering eMMC, unlocking the device with the uncovered PIN.
S.H.I.E.L.D: Scudo Heap Implementation Exploits, Leaks, and Defenses - Tom Mansion
Tom Mansion talks about the scudo dynamic memory allocator. He starts with a refresher on a previous allocator, ptmalloc2: deterministic allocations of different sizes in the same area, with free list metadata stored on the heap. Hence, exploitation of a vulnerability can corrupt metadata and lead to arbitrary control of data.
Then on to scudo, which is designed with security in mind, using randomness as much as possible, protecting metadata with a checksum based on a secret in libc and removing control metadata from the heap. An optional quarantine is possible and recently freed memory chunks, but it is not used on Android. Based on allocation size, scudo uses two different methods: primary and secondary, where secondary relies on primary.
Without quarantine and MTE (Memory Tagging Extension), scudo doesn’t protect against use-after-tree leading to type confusion of the overwritten data. The talk also describes the “Forged Commitbase” & “Safe Unlink” previously documented techniques, and specially how their heavy prerequisites are circumvented by Zygote thus allowing a local process to attack another local process. Forged Commitbase overwrite data with a fake secondary header that leads to a chunk at arbitrary address once the victim chunk is freed and another allocation is made. The checksum can be calculated as the random seed is the same in both process! Safe Unlink overwrites the prev and next pointer in the secondary header but is patched now with “Compact Pointers”. They are offsets from the beginning of a region rather than absolute pointers. Yet, using Forged Commitbase, it is possible to poison the local cache with arbitrary Compact Pointers so as to circumvent the patch. Closing notes depicts a grim future for exploitation, as MTE would prevent these attacks.
The Matrix Unloaded: Escaping the JTAG Reality - Thomas Sermpinis
Thomas Sermpinis is an automotive cybersecurity expert denouncing the automotive industry’s inertia in the face of hardware security flaws, pointing out that “almost nothing has changed” despite the years. His talk is an analysis of the state of cybersecurity in the automotive industry.
He revealed the process of his research on the WOLFBOX Level 2 EV charger, which was a target for Pwn2Own Automotive in Tokyo this year. He illustrates the risk of leaving JTAG activated or poorly secured in ECUs, a common but dangerous practice. After connecting to the SWD interface on the ECU, he was able to dump the firmware with no problem, helping himself with some documentation on the mapping. Extracting firmware from the communications module was the next step and he based his work on previous research documented on ZDI.
In the end his team was not able to register for the competition in time, apparently the Pwn2Own team received its application in the spam folder.
After this, he shows us some research done on another vendor, where two SoCs are used. One Secure Controller and one Application Controller, which both have JTAG interface being locked. But after some tries, it was found that there is a tiny window during the boot process of the Secure Controller where we can attach to the interface. It was possible because the JTAG was locked during the boot process and not by a fuse or password.
He shows another example where the vendor did not prevent access to EDL mode on a board, so he could boot in EDL and dump the firmware to begin fuzzing the CAN bus. In the end, the OEM decided to not fix the issue cause it would cost too much for them, and apparently their next architecture will fix those issues.
His research ended with 24 vulnerabilities responsibly disclosed:
- 4 of them approved and CVE assigned
- 20 of them were neglected, the manufacturer did not answer
- All of them are a result of hardware analysis and firmware extraction
In conclusion, he gives some solutions to address these challenges. He proposes dedicated physical interfaces, secure and obfuscated ports, designed to restrict access to specific memory locations containing forensic data, although their adoption is hampered by increased complexity and cost. He criticizes the industry’s lack of commitment, questioning whether it really cares about cybersecurity, and points to outdated practices that neglect user safety.
He encourages the hacker community to get involved in automotive security, notably through competitions such as Pwn2Own and calls for a collective awareness to integrate secure forensic practices and protect automotive systems against growing threats.
Breaking Decompilers - Jordan Wiens
The talk explains in an accessible way how decompilers work and how they can be deliberately interfered with. A decompiler is a tool that transforms an executable file into readable source code, but this process is imperfect because a lot of information is lost during compilation, such as variable names, comments or the original logical structure. Jordan works at Binary Ninja so the talk is focused on Binary Ninja behavior but it also shows the difference with IDA and Ghidra.
Jordan begins by showing why decompilers are limited by design, talking about Rice’s theorem, which demonstrates that it is impossible to reliably determine certain properties of a program just by analysing its code. He then details the three main stages in the operation of a decompiler: parsing, lifting, and optimization.
He explains that each stage can be deliberately sabotaged using specific techniques. For example, to break parsing, memory segments or binary relocations can be manipulated. To break the lifting, you can use misaligned or rare instructions. And to break the optimizations, you can insert unnecessary code, use packers like UPX, or manipulate memory permissions in a non-standard way.
Each technique is evaluated according to three criteria: its effectiveness in preventing analysis, its visibility (how easy it is to notice), and the effort required to implement it. Jordan also shows a number of concrete demonstrations to illustrate these ideas which you can find here. He also presents tools such as SCC (Shellcode Compiler) that automatically generate code that is difficult to analyze. In conclusion, he points out that decompilers are very useful but also very vulnerable: they are easy to fool, and creating a tool that is reliable in all cases is almost impossible.
Simple is Best, The journey of taking over a mobile system using a GPU logical bug - Shang Hongze
A really nice talk from Shang Hongze, about the Kirin GPU. It seems that Kirin SoC are popular at Off By One this year! After a short introduction about why Shang needed to be root, he introduces the GPU integration in Android.
As many already know, the GPU is generally easily accessible from restricted context on Android, making it a nice attack surface for privilege escalation. Huawei started to use their own GPU called Maleoon, older Kirin SoC were using mali. Shang targeted a Kirin 9000S SoC, as used on a Mate60 Pro. He started by looking at how the GPU driver manage the GPU memory, and list all the various operations which can be realized. The GPU has access to its own virtual memory (GVA), which is managed by the driver.
Shang found a really nice logical bug in the way the GVA were freed. It was relying on multiple function, and the returned value wasn’t check. This allowed to obtains a dangling PTE entry by making vm_munmap fail. Later on, Shang demonstrated its exploitation strategy and a nice demo. The bug is really nice and subtle, kudos !
Don’t believe the hype(rvisor)! - Laszlo Szapula
This was an interesting talk about HKIP, the hypervisor employed on Hisilicon (read Huawei) Kirin SoC, by Laszlo Szapula. He presented the research he made during his internship at Taszk security.
Huawei developed their own hypervisor, running at EL2 on Aarch64 Application Processor. This hypervisor, like RKP on Exynos chips, enforce many things: page’s permission, monitoring of critical kernel structures, etc. Laszlo goals was to obtain a privileged shell from two primitives: a kernel memory R/W and a KASLR leak. He couldn’t simply overwrite the cred structure, because HKIP is monitoring them and would detect the tampering.
The hypervisor memory protection rely on stage 2 pages table, introducing the translation from VA -> IPA -> PA, where IPA (Intermediary Physical Address) is the intermediary stage 2 translation, controlled by the hypervisor. He presented how he tried to find a new vulnerability by emulating and fuzzing the hypervisor, through two attack surfaces (Hypervisor Calls and Shared memory). He relied on Qemu to emulate the hypervisor, with the need to patch the board definition to obtain the same memory layout than its target. To obtain the initial register content, he used a patched hypervisor on an debugging environment to save the content of the register. Sadly, this did not pay off, as only false-positive bugs has been found through fuzzing.
He resorted to static analysis, digging through the hypervisor call handlers. He discovered that the PRMEM (Protected Memory) operations used the reserved bits of the OA granule to store the permissions bits of the pointed memory. There was no validation on these bits, he could simply call the appropriate handler of the hypervisor from the kernel, and kindly ask to set these bits through HKIP_HVC_ROWM_SET_BIT operations. This allowed him to manipulate the memory as there was no protection at all. He then introduced an SELinux bypass, using the same trick.
Huawei answered that they would not fix that, as the purpose of HKIP is to “make the attack more difficult”, not to be an exploitation mitigation.
Five years of hacking ICS/IoT in Pwn2Own - Sharon Brizinov
Another talk about Pwn2Own, by Sharon Brizinov from Claroty Team82. It started with an explanation of what Pwn2Own is, the different editions and why Sharon & his team focused on the ICS edition: the expertise of Team82. This specific edition pays DoS as well as RCE, so such exploitation was also investigated.
Then, after an explanation about ICS/SCADA, he described their lab setup with the different VMs and the OPC-UA standard with compatible Pwn2Own targets. Using the protocol documentation, and example implementation, they identified a potential issue in the handling of chunked messages so they built their own OPC-UA protocol stack for testing. They tried fuzzing using this stack, with AFL for coverage fuzzing and boofuzz for network fuzzing and found multiple issues.
With a technique called Chunk Flooding, they flood the target with chunked message but never the final chunk. This results in resource exhaustion and the targets crash. Another technique is Method Calling From Dead Session where a session is created, sending as many Call Method Request but immediately closing the session. It ends up in access violation as the code tries to use the (freed) session for the last calls.
After DoS examples, Sharon goes on with RCE: KepServerEx converts UTF-8 to UTF-16 but mishandle invalid UTF-8 sequence so that string ending with 0xc3 0x00 leads to heap overflow. The bug is triggered on both READ_TAG and WRITE_TAG functions, hence OOB read to defeat ASLR and OOB write to build a ROP chain.
Last but not least, an attack from a malicious OPC-UA server using an XSS in the client (with specially crafted tag names). The XSS then uses the scripting features of the client to define and run a Python script on the client’s host OS.