The SDK sits between the app and the socket
An enterprise SDK for mobile banking or retail provides its own networking layer so that applications built on it inherit a consistent security policy. Certificate pinning is one of those policies. The application developer usually does not configure it, and often cannot turn it off.
The result is an app whose pinning code is not in the application package but in the SDK dependency. When you look for the pinning implementation, the class names belong to the vendor rather than to the app. That is the first practical signal: the network client, the interceptor chain and the trust configuration all carry vendor names, and the application code only calls into them.
Products in this category are configured rather than coded by hand, which means the pin set is data. Look for a resource file, an assets entry, or a generated configuration object that lists host names alongside certificate digests. In managed deployments the list often arrives in a configuration payload that the app fetches or that a build step injects, so the same application build can carry a different pin set in a different deployment.
Rotation is built into the design
A hand-written pin breaks the moment the server certificate changes, so enterprise products ship a mechanism for changing pins without a store release. Typical designs keep more than one acceptable pin per host, carry a validity period alongside each pin, and accept a backup pin that is not yet in use. Some accept a pin that is delivered at run time and stored alongside the configuration.
That design changes how a failure presents itself. A pin can stop being valid without the certificate changing, if the pin carries an expiry or if the configuration is refreshed. An app that worked yesterday can refuse today's connection while both the certificate and the app build are unchanged.
It also gives you a way to reason about what a reconstruction must contain. A client built from the app should treat trust settings as configuration that may change, rather than as a constant copied out of the binary. Recording the current pin set is useful, and recording the mechanism that changes it matters even more for a client that has to keep working.
Telling a pin refusal from an authentication refusal
Both arrive as failures around a protected request, and they need different treatment.
- A pin refusal ends the connection before a request is written, so no status line and no response body exist for that attempt.
- An authentication refusal arrives as a response, which means the transport layer accepted the peer and the request was evaluated.
- A pin refusal from an SDK usually surfaces as a platform certificate exception, sometimes wrapped in a vendor exception type. The nested cause is where the certificate detail lives.
- An authentication refusal is often accompanied by a refresh attempt, so a single logical call can produce several network entries before it fails.
- A configuration error produces a failure that names the host or the configuration rather than the certificate, which points at the pin set rather than at the peer.
Establishing which layer refused the call is the first step for any investigation, and the same triage applies across clients. It is set out for the general case in intercepting pinned traffic.
Where the request is still observable
The SDK's interceptor chain is the last point at which the request exists in a readable form before it reaches the socket. In a product of this kind, that chain is where device headers, tenant identifiers, session tokens and any request signature are attached. Those are the values a reconstruction has to reproduce.
Two details are worth recording while the chain is visible. The first is the order of the interceptors, because a value added by one interceptor can be signed by another, and the order determines which. The second is which of the values depend on device state, because those cannot be copied from a capture and have to be derived.
A vendor SDK also tends to layer other checks around the same call. An integrity or attestation check that runs before the request produces a failure that looks like a transport problem, and the distinction matters for how the work is planned. AppDome reverse engineering covers one class of such layered protection.
The useful output of this stage is a record of the pinned host list, the pin source, the trust configuration, the interceptor order and the values each interceptor adds. Android certificate pinning traffic analysis describes how that record is produced.
Related work
Reviewed 28 September 2026 · SReverse research desk