Thread by @mame82

Okay, I managed to instrument the "DJI Go 4" Android application (packed with SecNeo, ptrace-based debugger avoidance).

Here's a quick example with @fridadotre frida-trace utiliy (tracing lib.c->open calls).

Steps to reproduce in a few minutes in this thread ... stay tuned

First things first:

1) I am running the app on a arm32 device (armeabi-v7a)
2) I want to avoid repackaging the APK, thus modifications are done directly on the device, once "DJI Go 4" is installed (requires root)
3) @fridadotre is used in gadget-mode

Step 1)

The SecNeo packed APK ships with various native libs.
The most interesting one is "libDexHelper.so".

Unfortunately this ELF lib has no dynamic section, thus we need an easier target to inject the Frida agent.

Here's an excerpt of the apps '/proc/self/map'

I opted for 'libc++_shared.so' to inject a dependency for the frida-gadget library, as it gets loaded before early and has a 'dynamic' section for library imports.
...

Step 2)

I used the python3 package 'lief' to inject a dependency for 'libgadget.so' into the aforementioned stdc++ lib (no idea why the first attempt failed)

Result is stored into 'libc++_shared.so.inj"

Step 3)

Check the modified c++ library for the newly added 'libgadget.so' library with readelf (optional verification step)

Step 4)

Find the path where the app resides on the device, using adb (in this case I just grep'ed for packages containing the string "dji") to locate the native library path (remember arm32 in my case, path likely differs in your case)

Step 5)

Push the modified 'libc++_shared.so' to the device, create a backup of the original lib of the application and replace it with the modified one.

(Note: My device is magisk rooted and adb has no root permissions by default, that's why I use the tmp folder in between)

Step 6)

Verify that the "DJI Go 4" app misbehaves, once started again, because it can not load the missing 'libgadget.so' dynamic library. In my case the app crashes and logcat clearly show the error we want to see (dlopen can't find "https://t.co/zXVenodpCJ")

Step 7)

Push the current frida-gadget for your architecture (again, arm32 in my case) to the device.

Also push a config file with the naming convention 'lib<yourgadgetname>.config.so'.

The gadget could be found in release tab of Frida's github repo.

Note: I used a configuration file which puts the gadget into "listen" mode, meaning the process gets halted until a "Frida client" attaches. This closely mimics "early instrumentation" as doable with Frida server (spawn gating)

Step 8)

Copy the gadget library and the created config to the native library path of the app (pay attention to proper file naming and a library path matching your device architecture)

Step 9)

Once this is done, the app could be launched again and Frida could be attached as usual. Because of the "listen" mode use here, the app is only resumed once Frida attaches.

This is shown in the video of the first tweet with frida-trace. Please note the '-F' switch ...

... which attaches to the app currently running in foreground (which should be the one with the injected agent, so be sure to have it started first).

That's it !

Hope this helps somebody