A gRPC call is more than a protobuf body
gRPC usually uses protobuf for service and message definitions, then carries calls over HTTP/2. A working client needs the service name, method name, request and response types, call shape and metadata. The call may return one response, a stream of responses, accept a client stream or run both streams at once.
The APK often contains generated stubs and message classes. Those classes can reveal method descriptors, full method names, marshallers and whether the call is unary or streaming. Native libraries, Flutter plugins and stripped builds can move those clues, so we also trace channel creation and the bytes passed into each call.
Rebuild service definitions and call state
We restore the service, rpc and message definitions needed for the full application. Then we map each screen and background job to the method it calls. This catches requests triggered by startup, token refresh, push handling and live updates as well as visible taps.
- Recover package, service and full method names.
- Restore request, response and enum definitions.
- Identify unary, server-streaming, client-streaming and bidirectional calls.
- Map compression, message limits, deadlines and cancellation behavior.
- Parse status codes, response trailers and structured errors.
Metadata carries the app’s private API specification
gRPC metadata uses HTTP/2 headers and trailers. Apps place authentication, tracing IDs and custom request values there. Binary metadata keys end in -bin. We trace every interceptor that creates or changes metadata, including token refresh, device identity and request signatures.
A valid protobuf message can still fail when its deadline, metadata or call order differs from the app. We test each method through the full account and session flow. Streaming clients also reproduce reconnect, resume and cancellation rules so live data stays usable.
The full delivery
You receive a callable API for the full APK in Python and JavaScript/TypeScript, plus a Postman collection. The clients cover every recovered endpoint and workflow. They create fresh signatures, encrypt requests, decrypt responses, keep authentication and session state, and follow the same request order as the app.
Each client includes clear input models, parsed outputs, refresh behavior, uploads, downloads, streaming events and useful errors where the app uses them. We test the delivery against the live service so it runs without copied requests or old tokens.
Reviewed 30 August 2026 · SReverse research desk