Native Android and JNI reverse engineering

Start at the Java declaration

A native method gives us its class, method name, argument types and return type. Static binding can expose a symbol shaped like Java_package_Class_method. Dynamic binding uses RegisterNatives, which stores a method name, JNI signature and function pointer. We inspect every ABI library shipped with the app and match the registration to the Java call.

Follow bytes across JNI

Encoding is part of the algorithm. Java strings use UTF-16. GetStringUTFChars returns Modified UTF-8, which differs from normal UTF-8 for some text. A Java byte[] crosses JNI as bytes. We record the JNI function used before reproducing a signed or encrypted value.

• Test empty text, ASCII, non-ASCII text and a null character when accepted.
• Keep byte arrays as bytes.
• Record lengths because binary data can contain zero.
• Release JNI pointers through the matching function.

Map the full native data path

Imports, exports, strings and call references are leads. Stripped libraries can remove useful symbol names. Runtime registration can hide Java-style exports. We trace the call from Java arguments through native helpers to returned bytes, stored state or a request field.

// Synthetic data-flow sketch. Names and values are examples.
method + path + body bytes
        ↓
exact serialization and encoding
        ↓
signing or encryption function
        ↓
header or request body returned through JNI

Example flow only. The real inputs and functions come from the APK under review.

Check dependencies before porting

Android Keystore keys can be non-exportable and bound to secure hardware. A server that requires proof from that hardware has a runtime dependency that copied code cannot remove. We check this during the APK review and state the deployment requirements before the quote. Android Keystore documentation.

Deliver the full native layer

The project maps every native function used by the APK’s APIs and backend workflows. Tests compare the app and the delivered clients with fixed inputs, Unicode inputs, empty bodies, current sessions and failure responses.

The full APK is the project

You receive Python, JavaScript/TypeScript, Postman and API documentation for the full application. The work covers endpoints, authentication, request signatures, encryption, decryption, sessions and backend workflows.

Run the complete public demonstration to inspect one matching workflow in every format.

Send the APK on WhatsApp or email. The 24–72 hour delivery window starts after we receive the APK and any account access needed to run it. The fixed quote states the deadline. Most projects finish sooner.