I want to understand if end user is doing MITM attack on my app and i want my API server to receive this. Is there any way i can hook an SDK or some listener that tracks which certificate is being used for outgoing / incoming requests at some particular moment and if that doesnt match something i hard coded or my own server to just log it somewhere? I understand that tools such as Frida and others inject specific code that override ssl certificate with MITM software's certificate but I'm also wondering is it possible to have something that works in background that keeps checking which certificates are being used and to react accordingly if it isnt something i know off?

Best regards

  • 4
    You can make it more difficult, but you can't avoid it. If you don't own the client, you have no control over what the user does to it.
    – vidarlo
    Mar 16, 2021 at 14:29
  • I am aware of that. I ask technically is it possible to have something that works in background that checks which public keys were used for encryption for all TLS requests that were made. I don't really want to prevent it in that way that he can't do it but rather to know if he is doing it or not. @vidarlo
    – TrueStar
    Mar 16, 2021 at 14:49
  • It sounds like you might want to consider using a client certificate as part of your authentication process. Your server can check that the client is presenting the expected certificate, and that the client is in possession of the private key corresponding to the public key in the certificate. That way, if an attacker tries to MITM the connection using a different certificate, your server will detect it.
    – mti2935
    Mar 16, 2021 at 15:06
  • 1
    If you control an Android app - you can pin your server certificate, so that the app will refuse to communicate with the server if the certificate is not the one that was pinned. You can also use mutual authentication, where the server issues client certificates. The client then uses this certificate for authentication. When something intercepts the traffic, the server will detect the new MIM certificate which wasn't issued by the server and can run specific logic - most of the times it just drops a connection, but you can do some logging or whatever.
    – oleksii
    Mar 16, 2021 at 15:09
  • I don't think you guys understood me really here. I am aware of how certificates work and how ssl pinning works in general as well as entire client hello process that goes around it on lower layer of abstraction. I just want to understand if i can make something that works in background of the app and that sniffs all certificates used during the runtime so for example if someone does ssl pin bypass that i can catch what certificate he was using to communicate to the proxy or any sort of mitm module he used during this process. @oleksii
    – TrueStar
    Mar 16, 2021 at 15:40

2 Answers 2


You cannot win against a user running your app on their own device.

I'm not sure exactly what you mean by "in the background", but sure, you could implement all sorts of checks all over the place to try and verify that certificate pinning is working and you are talking to the real server. However, no matter what you do, it can be identified and circumvented by a competent user. Especially on a rooted device, the user has complete control over your entire process and can forge whatever information they want and bypass all checks at every level. You can make it more difficult and slow them down by adding more checks, but it will not stop a determined adversary.

It may be time to reconsider your threat model. What are you so concerned about the user seeing in transit, if the information is already sent to/from their device? Or maybe you are worried about security of the API service itself, in which case your efforts are better directed towards reviewing/auditing that component.


No, you cannot win.

Client have his own computer or phone, and can run anything he wants, your software included. And he can alter your software to bypass the protections.

So you include a tamper detection function, or a dozen. No problem, if the client can bypass the protection, he can bypass the tamper protection.

You can verify all the certificates and a function returns false when the certificate is invalid? No problem, the user can change your function to always say that the certificate is valid.

So you create an external, second app that hooks API calls made by the primary app and detects changes. Guess what? There's nothing that can stop the user from changing this app too.

And the app have to send to your server if he is using a valid certificate, right? He can tap on that channel, and change the information there.

So you add a client side certificate. But where do you store the key? On the client device? He can dump memory and extract the key.

Digital signatures, client-side certificates, code fingerprinting, code obfuscation, undocumented API, it does not matter. Client-side protections can only delay an attacker, never stop a determined one.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .