I want to decrypt a SSL connection that is established by an unknown binary file on a Windows 7 Computer. This binary doesn't exist on any other computer on our network and establishes SSL encrypted Connections to a specific host in irregular intervals. I now want to decrypt the connection to be able to determine which data is transfered.

I already tried to intercept the connection using mitmproxy and a fake CA which did not work. Is there a way to detect SSL keys in the RAM or is there another way to "catch" all keys used to decrypt SSL connections?

// The connecton breaks when I try to use mitmproxy. I assume the binary brings its own list of valid CA certificates.

  • When you tried with the fake CA did you add that to the operating system CA list?
    – alxjsn
    Commented Oct 28, 2015 at 15:06
  • I did add the certificate to the is list!
    – davidb
    Commented Oct 28, 2015 at 15:54
  • If this binary was created by Java, then there is a chance to find the keystore at the folder jre/lib/security/cacerts. en.wikipedia.org/wiki/Keystore
    – JOW
    Commented Oct 28, 2015 at 16:23

3 Answers 3


You might try the methodology listed in this article: http://blog.erratasec.com/2015/02/extracting-superfish-certificate.html

The author dumps the memory of the running process, and then finds the key in that dump. He uses a list of strings from the memory dump as inputs to a dictionary attack to crack the password for the key.

If, as you suspect, the binary has its own certs, then this might be a general plan of attack for you.


You might need to attach a debugger to the questionable process or cause a system crash and memory dump. Then examine the memory dump - if you can extract either the password to the certificate; or the certificate itself you'll be able to use a tool like Wireshark to intercept and decrypt the traffic.

Is the program persistent? Can you shut the machine down and make a copy of it? Maybe some static analysis in a standalone VM would be possible?


You need to install the root CA and the chain leading to the website of interest on the computer you are trying to analyze. This should make the victim assume the intercepted and decrypted-re-encrypted traffic is coming from a legitimate source.

If the ssl implementation is tls1.2 then you wont be able to decrypt the traffic, and the only option would be to try intercept the message off the suspicious process before the web request actually fires.

You must log in to answer this question.

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