CVE-2024-3400: PAN-OS Command Injection Vulnerability in GlobalProtect Gateway. Learn More

CVE-2024-3400: PAN-OS Command Injection Vulnerability in GlobalProtect Gateway. Learn More

Services
Capture
Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

twi-managed-portal-color
Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

twi-briefcase-color-svg
Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

tw-laptop-data
Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

twi-database-color-svg
Database Security

Prevent unauthorized access and exceed compliance requirements.

twi-email-color-svg
Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

tw-officer
Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

tw-network
Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Solutions
BY TOPIC
Offensive Security
Solutions to maximize your security ROI
Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Partners
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

Custom Native Library Loader for Android

If you read my co-worker Neal Hindocha's recent post "Debugging Android Libraries using IDA" you notice he mentioned using a "custom library loader". We had used this on a recent mobile penetration test to have complete control over some home grown custom native libraries the target application was using.

The biggest problem we were facing with the test was that the library in question was being used for anit-rooting and anti-debug functionality to protect the app, and part of our job was to bypass this and patch it out. Of course, attaching directly to the running Android app to get at the code in this library was problematic, since most of the protections were likely loaded before we could attach.

What we needed was something like dllloader for Olly or Immunity that we could use to load the target .so file independently of the process, so we could have total control and access.

Here is what we came up with. While obviously not as feature rich as dllloader, this quick and dirty loader did the job:

 

#include <stdio.h>#include <stdlib.h>#include <dlfcn.h>int main(){      printf("Loading libs\n");     int (*pt2Function)(void) = NULL;                        //pointer to a void function - change this to match method sig     void* sdl_library = dlopen("/system/libtarget.so", RTLD_LAZY);     if (sdl_library == NULL) {     // report error ...     printf("Unable to load library\n");     char *errstr;  errstr = dlerror();  if (errstr != NULL)  printf ("A dynamic linking error occurred: (%s)\n", errstr); } else {  printf("Lib loaded, getting dlysm\n");     void* initializer = dlsym(sdl_library,"JNI_OnLoad");  if (initializer == NULL) {     // report error ...   printf("Unable to get address of JNI_OnLoad\n");   char *errstr;   errstr = dlerror();   if (errstr != NULL)   printf ("A dynamic linking error occurred: (%s)\n", errstr);  } else {      // cast initializer to its proper type and use      printf("calling get process\n");      //asm("BKPT #0");      pt2Function = initializer;      printf("got get process, setting up\n");            printf("Ok, lets Calling the function");      int result=pt2Function();      printf("Result of call is %d", result);        //asm("BKPT #0");  } }     return 0;}

As you can see, our target was the 'JNI_Onload' function. In our case, we targeted this because it was in this function that the anti-debug and system monitoring functionality was set up. We could have set up the function pointer to point to ANY of the .so's exported functions and called them.

This code could easily have been compiled on run on any standard linux system. We used dlopen() to dynamically load the library and dlsym() to obtain a pointer to the exported function we wanted to test. We could then call the target function directly and pass in any parameters (if any) the function took in order to follow code execution or even to fuzz, looking for exploits. The only ARM specific code we had (which it turns out we really didn't need) are the commented out ARM breakpoints.

To compile this, you simply use the Android NDK and create an ndk-specific Android.mk file:

 

LOCAL_PATH := $(call my-dir)include $(CLEAR_VARS) # give module nameLOCAL_MODULE    := loader  # list your C files to compileLOCAL_SRC_FILES := test.c# Build executables instead of a library for android.include $(BUILD_EXECUTABLE)

You place the files in the normal Android NDK file structure - code and the Android.mk file, including the C code for the lib goes under the jni directory and your executable will appear under libs/armabi/ directory. To build, you open a terminal in the root of your project directory (same level as jni and libs) and execute the following command:

Mike-Park:android-loader mpark$ /path-to/android-ndk-r8e/ndk-build

In my case, I created a directory called 'android-loader' that contained jni/ and libs/ and ran from there.

After a few warnings, you should get a perfectly useable ARM executable in the libs/armabi/ directory called loader. You can then use adb push to place this in the /system directory (after a remount of course) along with your target .so and run it from there. It works great in the emulator and on the devices we tried.

Again, this is a quick and dirty bit of code that works. We used it for debugging with IDA, but it could easily be adapted for fuzzing and to take the library to load from the command line. I'd like to make it more robust, so any feedback or suggestions are welcome.

In the meantime, enjoy hacking android native code.

 

 

Latest SpiderLabs Blogs

EDR – The Multi-Tool of Security Defenses

This is Part 8 in my ongoing project to cover 30 cybersecurity topics in 30 weekly blog posts. The full series can be found here.

Read More

The Invisible Battleground: Essentials of EASM

Know your enemy – inside and out. External Attack Surface Management tools are an effective way to understand externally facing threats and help plan cyber defenses accordingly. Let’s discuss what...

Read More

Fake Dialog Boxes to Make Malware More Convincing

Let’s explore how SpiderLabs created and incorporated user prompts, specifically Windows dialog boxes into its malware loader to make it more convincing to phishing targets during a Red Team...

Read More