Recognise an encrypted body
An opaque payload is not automatically encrypted. Base64, gzip and protobuf all produce bytes that read as noise in a text view, and each has a trivial answer. Decode before drawing conclusions.
- Check the content type and length. A declared type of application/json with a body that will not parse points at encoding or encryption rather than a different protocol.
- Try base64 and hex decoding. A payload that decodes to readable text needs no cipher work at all.
- Check for compression headers. A gzip or deflate stream starts with recognisable bytes, and decompressing it often reveals the parameters directly.
- Compare two captures that differ in one field. A block cipher leaves a recognisable pattern of unchanged blocks, and a stream cipher changes the whole payload when one byte changes.
Those tests take minutes and they prevent a long detour into cryptography for a body that was merely compressed.
Locate the encryption in the app
Cipher code names its algorithm, because it has to ask the platform for an implementation. The provider strings are ordinary literals, and searching for them lands close to the routine. Look for the cipher classes, the message digest classes and the MAC classes, then read the code around each hit.
- Read the transformation string. It names the algorithm, the mode and the padding, and it usually settles the question of whether the payload uses a block or stream construction.
- Find where the key comes from. Follow the argument that supplies the key into the cipher initialisation call.
- Find where the IV comes from. A random IV is normally sent alongside the ciphertext, and a fixed one may be a literal in the code.
- Check for a native implementation. When the string search finds nothing, the routine may sit in a shared library, and it has to be read there.
Obfuscation hides method names but leaves the algorithm strings in place in most builds, which keeps the search useful. Identifying encryption before reproducing a request covers the case where the strings are hidden as well.
Recover the key and the parameters
- A literal key is the fastest case. A byte array or a string constant near the cipher call is the key, and recovering it is a copy and paste.
- A derived key needs its inputs. Some apps combine a stored secret with a device value, an install identifier or a session value, which means the effective key changes between installs and cannot be reused elsewhere.
- A negotiated key arrives from the server. The app and the server exchange material during a handshake, and the client has to perform the same exchange to obtain the same key.
- A native key sits in the binary. The key may be assembled in a shared object from several constants, which requires reading the disassembly rather than the dex.
Record the mode, the initialisation vector, the padding, the character encoding of the plaintext and the encoding applied to the ciphertext. Each of those has to match, and a mismatch produces a payload the server cannot decrypt. Runtime-derived keys covers keys that exist only while the app runs.
Rebuild the body in your client
Produce the exact bytes the app produces. Serialise the payload the same way, respecting field order, number formats and optional fields, then encrypt, then encode. A different field order still encrypts correctly, and the server decrypts it successfully, which means the failure appears later as a validation error rather than as a decryption error. That gap makes serialisation bugs harder to spot, so compare your plaintext with the app's plaintext before comparing ciphertext.
Reproducing the plaintext generation is the same problem as reproducing any request body. Reproducing payload generation covers that side, and an APK to API engagement delivers the finished client when the full flow has to work end to end.
Test decryption as well as encryption
A client that can send an encrypted request still has to read the encrypted response. Recover the decryption path at the same time, using the same key material, and test it against captured responses. Reading only the request half leaves the client unable to parse what the server returns, which is most of the value of having a client at all.
Related work
Reviewed 28 September 2026 · SReverse research desk