A recording proves the flow once
A recording shows which calls the app makes, in what order, with which headers and bodies. It also expires, because the timestamp, the signature and the session values inside it were produced for one moment. The deliverable is a program that builds those requests from inputs the operator supplies, and reaching it means reading the capture closely enough to sort the values it holds.
Read the recording for sequence as well as content. A token that appears in one call and is used by the next is evidence of a dependency, and a value that returns unchanged across two captures of the same flow is likely to be a constant. Values that differ between two captures of the same action are the ones the client has to compute.
Sort the values in the capture
Every value in a recorded request belongs to one of four groups, and the group decides what the client does with it.
- Constants come from the app. Paths, header names, content types, API keys and fixed flags stay the same on every run. They become configuration or code.
- Computed values the client can derive. A signature over the request, a timestamp, a random nonce and a hash of the body are produced by a routine the client reproduces.
- Values the server issued. Access tokens, session identifiers, challenge values and identifiers created by an earlier call come from a response, and the client fetches them in order.
- Values tied to the install or the device. An install identifier, a keystore-backed value or an attestation result exists only on the device that produced the capture, so the client needs a decision rather than a formula.
Writing those groups down for one request usually exposes the prerequisites of the flow. A call that returns a value another call needs belongs in the client even when it looks incidental in the recording.
Replace the recorded values in dependency order
The order matters because the signature covers the other fields. Replace values in this sequence and the client stays testable at each step.
- Start with the timestamp and the nonce. They depend on nothing else, and replacing them proves the client can send a fresh request at all.
- Compute the signature next. With a current time and nonce in place, the signing routine covers the real fields, and every attempt can rebuild it.
- Move the session values into a login step. Replace the captured token with a call that obtains one, and store it with its expiry. Refresh handling belongs there rather than in the endpoint functions.
- Fetch mid-flow identifiers in sequence. A challenge, an upload identifier or a one-time value has to be requested by the client at the point where the app requests it.
- Decide on the device-bound values last. Reproduce the formula where the app derives a value from readable properties, and treat a value that depends on hardware-held material as a scope boundary.
Verify by reproduction rather than by comparison
A client that replays a capture and receives a success response has proved very little, because the capture was already valid. Change an input the request carries, run the flow again and confirm the response reflects the new input. Send two requests in a row and confirm the server accepts both, which shows the nonce is fresh instead of reused.
Then run the client with no stored capture values available. A missing input should stop the client with a message naming the value, because a fallback to a stale recorded value is the kind of defect that survives testing and appears in production.
Package the result
Keep a request builder that derives the dynamic values, a session store with the refresh path, one function per endpoint and a saved fixture for each call. The fixtures are the tests that catch a server change later, and they double as examples in the documentation.
That structure is what SReverse delivers from an APK: a working client in Python, JavaScript or TypeScript, an importable Postman collection and documentation for the calls in scope. Projects start at $120 and most are delivered in 24 to 72 hours.
Related work
Reviewed 28 September 2026 · SReverse research desk