If you have access to the binary while it is running, it is entirely possible to extract the keys you need to decrypt the SSL/TLS session even with perfect forward secrecy. There is a 48-byte secret, called the master secret, which is shared by both sides and used to generate the session keys for the connection.
If the application uses the standard Win32 API to make the SSL connection, the point to intercept the key generation is inside
More information can be found in my answer to "Decryping TLS packets between Windows 8 apps and Azure".
More generally, I have (with several excellent co-authors) recently developed techniques for scanning all memory accesses for interesting data such as SSL/TLS keys. A paper on this ("Tappan Zee (North) Bridge: Mining Memory Accesses for Introspection") has been published at CCS, and the software to do it is available on github: PANDA/TZB. Particularly take a look at the
keyfind plugin, which takes a sample (encrypted) packet and scans memory accesses for TLS master secrets.
The procedure for finding the place where TLS master key generation happens with a new application is:
- Use PANDA to create a recording of the app making an encrypted connection, and save a packet capture (in the QEMU monitor,
begin_record <session_name>, run the app, then
scripts/list_enc.py on the packet capture to extract the information needed by the
keyfind plugin. Place this information in
- Run a replay of the session (
begin_replay <session_name> in the QEMU monitor) with
-panda-plugin x86_64-softmmu/panda_plugins/panda_keyfind.so specified on the command line. After a (very) long time, it will spit out the code locations where a matching TLS key was read or written to
The documentation is pretty sketchy at the moment, but looking at the source should resolve any questions you have (and feel free to ask for clarification here!).
For more information on using panda for this see: here