android

CVE-2025-31931 Arbitrary Shared Library Loading in Intel ITT API on Android (affects OpenCV <= 4.10)

Intel® Instrumentation and Tracing Technology (ITT) is a profiling API that developers use to analyze performance. The ITT library is available for many platforms. It used by many Android applications, either directly, or indirectly (e.g: via precompiled OpenCV library for Android officially downloaded from OpenCV website).

Intel advisory is here: https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01337.html

A bug was found that allows ITT to load arbitrary shared library. This shared library can do anything (executing arbitrary code, exfiltrating data, etc). Fortunately the exploitation is not that easy (requires adb access either via PC or Shizuku app, so remote exploitation should not be possible). POC is available on my github, but read on to understand this bug.

OpenCV copies all ITT API files verbatim to their 3rdparty/ittnotify directory. ITT is always built for Android platform (can’t be disabled via CMake config):

OCV_OPTION(BUILD_ITT                "Build Intel ITT from source"
    (NOT MINGW OR OPENCV_FORCE_3RDPARTY_BUILD)
    IF (X86_64 OR X86 OR ARM OR AARCH64 OR PPC64 OR PPC64LE) AND NOT WINRT AND NOT APPLE_FRAMEWORK
)

Any Android application using OpenCV up until 4.10 is affected, 4.11 and later are safe. There is no warning about this CVE in OpenCV because they were released before this CVE was published and they have accidentally fixed the bug (see this) because someone wants to support OpenBSD (“3rdparty/ittnotify had not been updated until 9 years. To support OpenBSD, I suggest to update to latest release version v3.25.4“)

Patching .so files of an installed Android App

If we installed an Android APK and we have a root access, we can modify the .so (native) filesof that app without altering the signature. This is true even if extractNativeLibs is set to false in AndroidManifest.xml. We can also patch the AOT compiled file (ODEX/VDEX) without changing the package signature, but that’s another story, I am just going to focus on the native code.

native libraries are stored uncompressed and page aligned

As a note: this is not a vulnerability, it requires root access. This method was discussed in the Mystique exploit presentation (2022). I just want to show that this is useful for pentest purpose, with an extra tip of how to write binary patch in C.

Background

I was doing a pentest on an Android app with a complex RASP. There are many challenges:

If I unpack the APK file and repack it, it can detect the signature change
If I use Frida, it can detect Frida in memory, even when I change the name using fridare
It can detect Zygisk, so all injection methods that use Zygisk are detected
It can detect hooks on any function, not just PLT. It seems that it is done by scanning the prologue of functions to see if it jumps to a location outside the binary; the app developer needs to call this check manually (this is quite an expensive operation), which is usually done before it performs some critical scenario.
The RASP uses a native library, which is obfuscated

Given enough time, I am sure it is possible to trace and patch everything, but we are time-limited, and I was only asked to check a specific functionality.

When looking at that particular functionality, I can see that it is implemented natively in a non-obfuscated library. In this specific case, If I can patch the native code without altering the signature, I don’t need to deal with all the anti-frida, anti-hook, etc.

Extracting WhatsApp Database (or any app data) from Android 12/13 using CVE-2024-0044

I want to make a WhatsApp message backup from a non-rooted Android 12 Phone. A few years ago, I used Whatsapp-Chat-Exporter to convert the backup to HTML, but first, I had to extract the database from the phone.

The method pointed out by Whatsapp-Chat-Exporter to extract from non-root has remained the same for many years: downgrade to an old version of WhatsApp that allows backup, then create an Android backup that contains the WhatsApp database.

This doesn’t work for WhatsApp for Business because there was no version that allowed backup. Depending on your use case, you might be able to move WhatsApp to a new device that can be rooted and then extract the files there (very easy when you have root access).

When looking at the new Zygote Bug by Meta Red Team X (CVE-2024-31317), I thought it could be used to perform backup extraction, but then I saw the previous entry on that blog (CVE-2024-0044), which is much easier to use (but only works in Android 12 and 13 that has not received Marh 2024 security update).

This exploit can work for any non-system app, not just for extracting data from WhatsApp/WhatsApp business. For an expert, the explanation for the exploit is very obvious. I am writing here for end users or beginners who need a step-by-step guide to extracting their WA database.

Zygisk-based reFlutter

I developed a Zygisk module for rooted Android phones with Magisk (and Zygisk enabled). This module allows you to “reFlutter” your Flutter App at runtime, simplifying the testing and reverse engineering processes.

If you don’t want to read the detail, the release is available at:

https://github.com/yohanes/zygisk-reflutter

Using U-Boot to extract Boot Image from Pritom P7

This is a guide to extract the boot image from a cheap Android tablet based on Allwinner A133 using U-Boot (accessed via UART). The original firmware was not found on the internet. With the boot image and Magisk, you can root your Android tablet to make it more useful.

Pritom P7 is a very cheap Android tablet. I bought it for 33 USD from AliExpress, but it can be found for as low as 27 USD. This is a Google GMS-certified device (it passes Play Integrity, no malware was found when I received it), and it uses 32-bit Android Go. I am only using this to test some 32-bit Android app compatibility.

They may have several variants of this model with different specifications. Mine is: Alwinner A133, 1.5GB RAM (advertised as 2GB, and shown as 2GB in the Android info), 32 GB ROM, only 2.4 GHz WIFI, no GPS.

Unlockable Bootloader

Luckily, we are allowed to unlock the bootloader of this device using the developer menu, adb reboot bootloader then using fastboot oem unlock. Some cheap Android devices don’t allow unlocking (for example, the ones that are based on recent Unisoc SOC).

I can allow bootloader unlock using the OEM Unlocking option

The product ID of my tablet is P7_EEA (Android 11) with kernel version Linux localhost 5.4.180-svn33409-ab20220924-092422 #28 SMP PREEMPT Sun Aug 20 19:13:45 CST 2023 armv8l. The build number is PRITOM_P7_EEA_20230820.

I did not find any Android exploit for this device, and I also didn’t find any backdoors. From my experience, some of these cheap Android devices have hidden su backdoors. Unable to find an exploit, I gave up trying to extract boot image from user space.

With some SOC, you can easily read/dump/extract the flash using PC software. I didn’t find any software for this Allwinner chip. An example of a SOC that allows flash reading is Unisoc (formerly Spreadtrum), but on the other hand, the bootloader on phones and tablets with the latest SOCs from Unisoc (that I know of) is not unlockable.

UART

Fortunately, this device is easy to open, and a UART pin is on the top left near the camera.