How an Android app configures pinning
An app pins when it validates the server's certificate or public key against a value it carries, instead of accepting any chain the platform trusts. Android supports this in the network security configuration, an XML resource the app declares in its manifest, where a domain entry lists a trust anchor and one or more pins expressed as a digest of the public key. The pin belongs to the domain it is declared under, and the configuration can also scope what is trusted for debug builds.
Apps also pin in code. A common HTTP client has a certificate pinner that takes a host and a set of pins, and the client checks them during the connection. Some apps verify in a native routine reached from a TLS socket callback, and a few repeat the check on a timer so that a connection is validated again after the handshake.
Reading the configuration is the first step, because it tells you which domains are pinned, whether a pin is a leaf key or an intermediate key, and whether a backup pin is present. The pins are hashes, so the expected key cannot be read from the string, but the pin can be compared against the certificate the server actually presents.
Why a proxy fails under pinning
A proxy that inspects TLS generates its own certificate for the target host and asks the device to trust that certificate authority. Without pinning, the connection succeeds because the platform store now includes the proxy authority. With pinning, the app compares the key presented against its stored digest, finds a mismatch, and aborts the connection.
The failure happens during the handshake, which is why the app shows a network error rather than an HTTP status code. No request reaches the server, so nothing appears in your capture, and the endpoint looks broken when the connection never carried a request at all. A client that retries may produce several failed handshakes and one apparent timeout.
A pinning failure and a network security configuration block
The two protections produce similar symptoms and need different responses. Distinguishing them early saves a long detour.
- A pinning failure comes from the app's own validation. The certificate the proxy presents is trusted by the platform, and the app rejects it anyway because the public key does not match the expected value. The error names the client and mentions a pin or a certificate check.
- A network security configuration block comes from platform policy. The configuration refuses user added authorities for the domain, so the connection is disallowed before the app's own check runs. The error mentions trust or a trust anchor, and it holds even for an app that carries no pins.
- A platform wide policy block behaves the same way for every app. When a device is configured not to trust user authorities at all, the failure follows the device rather than one package.
- A pinning failure follows the app. Another app on the same device reaches the same host through the same proxy without trouble.
The last two points are the quick test, because they separate a device setting from an application check without reading any code.
Observing at a layer the pinning check does not guard
When a proxy cannot see the traffic, the capture can be taken from a point inside the app's own stack. The pinning check guards the trust decision, and code that runs after the connection is established is not affected by it.
Hooking the HTTP client at the request level shows the request object the app built, which usually carries the URL, headers and body in a readable form. Hooking at the socket or stream layer shows the bytes the client wrote, after compression and encoding, and those bytes are what the server received. Hooking the signing routine shows the value the server will check, and it is often the piece a proxy capture would not have shown clearly anyway.
Analysing the check itself is a separate line of work and often the most direct one. The check compares a value derived from the certificate with an expected value. Observing that comparison shows which certificates the app accepts, and it confirms whether the check runs once per connection or on a schedule. A build that carries pins in a resource file can also be read statically for the domain list, even when the digests say nothing about the key.
Each of these approaches answers a different question, and the right one follows from what you need. A request that must be reproduced needs the request and the signing inputs. A connection that must be understood needs the bytes on the wire. SReverse analyses pinned Android traffic and selects the layer that produces the values a client needs, whether the pin sits in the network security configuration, in the HTTP client or in native code.
Related work
Reviewed 28 September 2026 · SReverse research desk