Android x86 Dirty Cow注入Shellcode时libcutils.so加载失败求助

Hey there, let's work through this issue you're hitting with your school paper's Dirty Cow shellcode injection project. That libcutils.so error is a common pitfall on Android x86, so let's break down possible causes and fixes:

1. Why libcutils.so is causing problems #

• First, libcutils.so is a system utility library, but its presence and path vary across Android x86 versions (different API levels, custom builds). Newer Android releases often merge parts of libcutils into other libraries like libutils.so or change its installation directory entirely.
• Chances are, your injection tool is hardcoding a path to libcutils.so that doesn't exist on your target system, or it's trying to load the library without proper root permissions to access protected system directories.

2. Immediate troubleshooting steps #

• Verify libcutils.so exists on your target:
  Run this command via adb shell:

  find / -name libcutils.so 2>/dev/null
  

  Check if it lives in /system/lib/ (32-bit x86) or /system/lib64/ (x86_64). If it's missing, consider switching to an older Android x86 image (API 21-25) where libcutils was more commonly a standalone library.
• Fix library path in your injection tool:
  If your code uses a hardcoded path like /system/lib/libcutils.so, replace it with a dynamic lookup, or ensure the tool leverages the system's LD_LIBRARY_PATH when loading libraries.
• Double-check root permissions:
  Dirty Cow requires root access to modify system libraries like libc.so. Confirm you've rooted your Android x86 image (e.g., using su in adb shell) and that your injection tool runs with elevated privileges.

3. Shellcode and Injection Target Tips #

• Validate your execve shellcode:
  Android x86 follows Linux syscall conventions:
  • For 32-bit x86: execve uses syscall number 0xb (11), passed in eax.
  • For x86_64: execve uses syscall number 59, passed in rax.
    Double-check that your assembly uses the correct syscall number for your target architecture, and that your stack-based argument setup is properly aligned.
• Choose a safer injection target:
  Overwriting the time function in libc.so can disrupt other system processes that depend on it. Consider injecting into a less critical function (like getpid or a rarely used utility) to minimize side effects. Alternatively, inject into your own process's memory instead of system libc—this avoids system-wide library conflicts and reduces permission requirements.

4. Alternative Injection Approach #

If libcutils.so dependency is a showstopper, try a direct Dirty Cow method that doesn't rely on external system libraries:

• Use /proc/self/mem to write your shellcode directly into a writable memory region of your target process. This bypasses the need to load helper libraries like libcutils.
• Since you're already using stack-relative addressing, your shellcode is position-independent—ensure this stays intact so it executes correctly no matter where it's injected.

内容的提问来源于stack exchange，提问作者Topper Harley