Read the value instead of patching the flow
A capture tells you what a request contained. Static reading tells you what the code appears to do. Instrumentation answers the question neither can: what did this build actually compute for this call. That difference decides most investigations, because the gap between a capture and a working client usually sits in a value that exists only at run time.
The discipline that makes instrumentation useful is restraint. A script that changes a return value changes what the server receives and what the app does next, so the observation stops describing the app and starts describing your edit. Reading the return value and leaving it alone keeps every later observation valid.
Hook at the layer that shows you the right bytes
The layer you hook decides what you see. Hooking the code that builds the request shows readable values in the form the app holds them: a URL string and a map of headers. Hooking the HTTP client shows the same request slightly later, after the app's own interceptors have run. Hooking the crypto or encoding routines shows the bytes that go into a transform and the bytes that come out.
Each layer is the right place for a different question. To learn which header carries a signature, hook the request builder. To learn whether an interceptor adds or removes a header, hook the client well into its chain so that the app's interceptors have already run. To learn what a signing routine receives, hook the routine itself.
Ordering matters when the app signs and then encodes. If a body is signed and then compressed, a hook placed after compression shows a different input than a hook placed before it. Locate the transform first, then place the hook on the side you care about, and log enough context to tell which side you landed on.
Log the arguments and the return value of a signing routine
The most informative hook in an API investigation logs the inputs to the signing call and the value it returns. Match those values against the request the app sends, and the signed material stops being a guess. Many routines take a key, a message assembled from the request, and sometimes an algorithm or a flag, so the arguments are usually an array of bytes, an object, or a small number of strings.
Read the message assembly rather than the key material. If you log a key, you have moved from reading the app's behaviour to carrying a secret around, and the log becomes sensitive. Logging the shape of the message is enough: which fields appear, in what order, with what separators, and whether the path is encoded or raw. That is what a replacement implementation has to reproduce.
Compare the returned value with the header the app sends. A match confirms the routine and the layer. A mismatch means the value is transformed after it is produced or that another routine produces the one on the wire. The second case is common when an app has both a legacy and a current signing path, and the hook landed on the overload that runs for a different call.
Keep the observation repeatable
An observation is only useful if someone can repeat it. Record the app version and the device you ran against, keep the script in the project rather than in a shell history, and print a line that identifies each call so two runs can be compared.
Avoid load. Logging every argument of a high frequency routine fills the output buffer and can slow the process enough to change the timing you were trying to observe. Filter on a method, a tag or an endpoint, and keep the printed values short.
Where this ends and a client begins
Instrumentation and a client answer complementary questions. Instrumentation shows what the app computed on one device at one moment. A client has to produce a working value on a different machine with a different clock, and it has to do so without the device.
Getting from one to the other means generalising the observed inputs into a rule, then testing that rule against a live call. The observable behaviour of the app, not the name of its classes, is what the rule is built from, and an obfuscated build changes names while leaving the behaviour in place. SReverse recovers request signing schemes by observing real calls and turning them into code, which is the same loop described here. When the signing routine sits in native code, the hook is placed on the library export rather than on a Java method, and Frida detection analysis covers the checks that decide whether a script attaches at all.
Scope stays with the client's written instruction and the app they own. The purpose of the hook is to read what the app computes so a working client can be built, and nothing in the workflow above hides the instrumentation from anyone.
Related work
Reviewed 28 September 2026 · SReverse research desk