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“)

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

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.

Continue reading “Patching .so files of an installed Android App”