SReverseby Simpa Labs

SReverse · frameworks / react native

The JS is right there. The endpoint isn't.

A React Native app ships its JavaScript inside the APK. The base URLs, the endpoints, and the request code are all in that bundle. What may be hidden is signing, which sometimes moves into a native module. We read the bundle, trace the call to the network stack, and rebuild the request.

SReverse · React Native Field guide Bundle + native 7 min read
scan_bundle.sh
# pull the JS out of the APK
unzip -p app.apk assets/index.android.bundle > bundle.js

# every host and path the build knows about
grep -oE 'https?://[a-zA-Z0-9._/-]+' bundle.js | sort -u

# the callsites that build requests
rg -n 'fetch\(|axios|/v[0-9]+/|baseURL' bundle.js

Fig. 01 · the endpoints are readable, the signing may not be

Read the bundle

The bundle is the source, most of the time.

A React Native app ships one JavaScript bundle, usually at assets/index.android.bundle. When the app uses the default JavaScript engine, that bundle is plain text. You can open it, read the fetch calls, and search for the strings that build URLs.

When the app uses Hermes, the bundle is compiled to Hermes bytecode. The strings are still there, but the structure of the functions is not plain JavaScript. Reading the hostnames is easy. Reading the exact signing logic takes more work.

Scan

Scan for endpoints, then read the assembler.

A regex over the bundle catches the obvious hostnames and paths. We then read the code around each match to see how the request is assembled, which header is added, and where the body comes from.

The endpoint is the easy half. The header that the server checks is the part worth finding. React Native apps often build that value in a native module, so the bundle shows the call and the native code shows the signing.

bundle (de-minified)
// where the JS builds the call
fetch(BASE + "/v1/orders", {
  method: "POST",
  headers: {
    "Authorization": "Bearer " + token,
    "X-Device-Sig": NativeModules.Signer.sign(body),
  },
  body: body,
});

Fig. 02 · the JS calls Signer.sign, and the native module answers

Follow the call down

Follow the JS call down to OkHttp.

The JavaScript fetch is a wrapper over the React Native networking module. On Android it lands in OkHttp through a native bridge. That is useful: a React Native app does not invent a new transport, so the server sees a normal HTTP request from a standard client stack.

The bridge is also where the signing hides. We read the native module, find how it builds the value, and reproduce that in the output client. If the value is built in JavaScript instead, we can read it directly from the bundle.

Hermes

Hermes bytecode is not a dead end.

Hermes writes the bundle as bytecode with a known, documented format. A disassembler turns the bytecode back into instruction listings, and the string table stays readable. That recovers the flow and the constants.

Rebuilding the exact semantics from bytecode is more careful work than reading plain JavaScript. It is worth it when the manifest says Hermes, but faster when the bundle has method names that point back to the original source. We read the network behavior either way, and validate the result against the live app.

Output

Reproduce the request as the native module makes it.

We read the JS for the shape, then read the native module for the signing, and return one client that does both. The result behaves the way the app behaves, so it keeps working beyond the capture you started with.

rn_client.py
# the native module produced X-Device-Sig, so we do the same
body = json.dumps(payload).encode()
dev_sig = base64.b64encode(sign_native(body)).decode()

r = requests.post(
  BASE + "/v1/orders",
  json=payload,
  headers={"Authorization": f"Bearer {token}",
           "X-Device-Sig": dev_sig},
)

Fig. 03 · the React Native request, rebuilt as Python

Keep reading

All field guides

Send us the app

Read the bundle, trace the call,
get a working client.

Send the full APK. We return the complete callable API in Python, JavaScript/TypeScript and Postman, with full API documentation.

Projects start at $120. Most are delivered in 24 to 72 hours.

One full APK. One complete delivery.

Projects start at $120. Most are delivered in 24 to 72 hours.

Every format included

Python, JavaScript/TypeScript, Postman and complete API documentation cover the same full endpoint set. Your team runs the clients in its own server or system.

Ready in 24–72 hours

The 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.

Deployment checked before the quote

The package includes signing, encryption, decryption and session handling. We verify device-bound keys and server integrity checks during review and document runtime requirements before you commit.

30 days of fixes

Report a defect within 30 days of delivery. We fix any delivered call that does not match the tested APK at no extra cost.

Start your full APK reconstruction

Send the full APK

Projects start at $120. Choose WhatsApp or email, then attach the APK in the app that opens. We reply within one hour with the next step and send the fixed quote after review.

Want us to contact you?