I'm trying to reverse-engineer a protocol (it's for a game whose server's are closing soon). I have two things: 1) the binary for the program 2) a packet dump from Wireshark (I am still able to get another dump, if needed). Now, the protocol, from what I can see from the dumps, is TLS/SSL (not sure which one) encrypted. I am aware that Wireshark has the capabilities to decrypt these packets, given that I have the required keys.. but how in the world do I extract the keys out of the binary?

tl;dr Can I access plaintext SSL given the originating binary?

  • 1
    To answer the question in your title: no, it isn't possible to decrypt an SSL connection if you don't have the key. Brute force would take more than the age of the universe. – Gilles Aug 23 '13 at 23:52
  • Gilles: Would I have any luck looking through a disassembly? – bobbybee Aug 23 '13 at 23:59
  • @bobbybee - No. See this thread: How does SSL work? Three excellent answers there. ;) – TildalWave Aug 24 '13 at 0:25
  • In fact, your question is more: « How to crack an SSL connection by reverse-engineering the client ? ». Because, indeed, SSL is known to be safe when you try to crack it from outside, but what happen when you can totally control one side of the connection ? This is what you have to investigate (edit and rephrase your question in this way, you will get more relevant answers) – perror Aug 24 '13 at 10:15
  • @Gilles: I disagree about the last sentence. It should include something like "at the current computing speed". We also cannot rule out that the prime number factorization problem will be solved in the future. – 0xC0000022L Aug 26 '13 at 11:44

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 lsass.exe, at:

Caller:  ncrypt!_Tls1ComputeMasterKey@32+0x57 
EIP:     ncrypt!_PRF@40+0x11a

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:

  1. 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 end_record <session_name>.
  2. Run scripts/list_enc.py on the packet capture to extract the information needed by the keyfind plugin. Place this information in keyfind_config.txt.
  3. 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 key_matches.txt.

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

Properly implemented SSL traffic has a property of forward secrecy. Which means that you can't decrypt it even if you have the whole packet dump and required private keys. As Brendan Dolan-Gavitt points out in his answer, you need access to the binary while it's running to do that.

What you can try to do is set up SSL mitm using something like ettercap. Which might be a bit involved and might not work depending on the SSL implementation.

Now, not a direct answer to your question, but it might help you achieve what you want:

Another thing you could to, since your goal is to analyze the underlying protocol is to make hooks on the higher level. I have use oSpy before to do similar work.

oSpy is a tool which aids in reverse-engineering software running on the Windows platform. With the amount of proprietary systems that exist today (synchronization protocols, instant messaging, etc.), the amount of work required to keep up when developing interoperable solutions will quickly become a big burden when limited to traditional techniques. However, when the sniffing is done on the API level it allows a much more fine-grained view of what's going on.

oSpy works by attaching to the process whose traffic you want to analyze and then monitor certain APIs.

  • Emphasis should be put on properly implemented in the very first sentence ;) – 0xC0000022L Aug 26 '13 at 18:08
  • Acknowledged and corrected :) – 0xea Aug 26 '13 at 21:16

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.