Start with what the status code proves
HTTP 401 means the request lacks valid authentication credentials for that resource. A server can include a WWW-Authenticate challenge that names the expected scheme. HTTP 403 means the server understood the request and refused it. The same backend can still use either code for an expired session, a failed signature, missing device state or a blocked request sequence, so the response body and the app's own error path matter.
We compare a fresh app request with the failed replay at the byte level. That includes the method, encoded path, query order, headers, cookies and body after compression or serialization. A request that looks the same in Burp or Postman can produce different signed bytes.
Authentication has a lifecycle
Login is often the first step in a longer state machine. The app may register a device, exchange a refresh token, obtain a challenge, set cookies, fetch a key or call a bootstrap endpoint before the protected request. A copied bearer token cannot recreate that lifecycle.
We trace where each value is created, where it is stored and what refreshes it. We then rebuild the same order in code, including cookie scope, token expiry and retry rules. The client starts a new session instead of depending on one captured session.
Signing errors often appear as access errors
A signature can cover the exact request target, selected headers, a timestamp, nonce and a digest of the body. HTTP Message Signatures defines this same core idea: components are collected into a signature base, then signed. If the Python client changes JSON spacing, URL escaping, header case rules or body bytes, the server checks a different message.
We find the app's canonicalization and signing code, including JNI or encrypted code when it lives outside Java and Kotlin. The rebuilt clients generate fresh signatures for every call.
What you receive
The full APK becomes a callable API in Python and JavaScript/TypeScript, with an importable Postman collection. The delivery includes login, refresh, cookies, signatures, encryption and decryption, device state, request order, response parsing and working examples for the app's flows.
Sources
Reviewed 30 August 2026 · SReverse research desk