3

Say we have a Windows application, which sends some packets over HTTPS. We need to extract the content of this packets (unencrypted of course).

There is no way to get hands on server private certificate and MitM attack doesn't work (some MitM defense is used by this application). So, decryption seems to be off the table.

The only choice (I suppose) is to extract these packets from the application before they get encrypted. Application is well protected, it has no dependency on OpenSSL DLLs. However, we have a certain feeling that it uses OpenSSL (but, statically linked, may be OpenSSL source was even modified before compiling/linking).

Hooking a call to OpenSSL functions (like ssl_write()) is not simple, because the application's executable is packed and obfuscated. It also has a debugging protection, but a stealth debugger, which avoid this defense, is already found. So, we can debug this application. However, the code, as seen during debugging, is a complete mess (obfuscated). Even the system DLLs, being loaded by this application, are completely messed. Here is an example of how the send() function from WS2_32.dll looks like during debugging of this application. For reference, here is how it looks like from normal (unprotected) application. So, it's very hard to understand how the function arguments are passed, moreover it looks like they can be passed via different ways (not sure, but looks so according debugging experiments).

This seems to be a quite common task, since there are many Windows applications which use HTTPS and statically linked OpenSSL.

Hopefully somebody have such experience and can share it.

Improve this question
3
  • except that one is x86_64, and the other i386 code, it does not seem obfuscated to me, that send function.
    – Willem Hengeveld
    Jan 15, 2015 at 11:17
  • maybe what you missed, as that some compilers reverse stack space first, then move arguments to the stack, instead of pushing.
    – Willem Hengeveld
    Jan 15, 2015 at 11:19
  • ... i mean 'reserve', not reverse.
    – Willem Hengeveld
    Jan 15, 2015 at 19:44

2 Answers 2

Reset to default
1

Since you are want to bypass HTTPS encryption, why not use Fiddler?

Fiddler is a web debugging proxy that auto-sets itself as the system proxy. It also offers the option to install a self-signed root certificate at the system, so HTTPS sniffing can be done.

All you have to do is start Fiddler, go to Tools -> Fiddler Optios -> HTTPS tab -> check "Decrypt HTTPS traffic". After that click yes in the dialogs asking if it is ok to install the root certificate as trusted and you are good to go (if I am not mistaken Fiddler also needs to be restarted for this to work).

Then, all HTTPS traffic from the computer running fiddler will be available to inspect in the respective tab of the application.

Improve this answer
4
  • The author says MiTM don't work with his app. I also have some apps/sites that won't work with fiddler enabled.
    – Filipe YaBa Polido
    Jan 15, 2015 at 22:20
  • Maybe try to patch the app with ImmunityDebugger so that it does not check for Fiddler ?
    – The Dart Code
    Jan 16, 2015 at 13:16
  • I tried Fiddler. I don't think that app checks if Fiddler is running. Instead it just uses certificate pinning or may be just have a certificate hard-coded inside it. So, it doesn't work with Fiddler's certificate. If Fiddler is enabled, but HTTPS decryption is disabled there (and Fiddler's certificate is not installed into system), the app works and Fiddler shows the packets (encrypted though, so no help).
    – McTraher
    Jan 16, 2015 at 18:26
  • maybe it would be simpler to find out how/where the pinned cert is stored and override that so fiddler could be used?
    – graywolf
    Feb 22, 2018 at 14:44
1

Maybe some of the following tools may help you:

  1. "SSLHOOK is a Win32 DLL that allows hooking of the OpenSSL functions SSL_read and SSL_write" https://github.com/strobejb/sslhook

  2. Immunity Debugger (immdbg) has the !hookssl command (hookssl.py)

Improve this answer
3
  • 1
    Thank you. I'll take a look, but if that's DLL hooking, it won't help, since, as I said, this application doesn't use OpenSSL as DLL, but instead it's just compiled with OpenSSL source (i.e. statically linked, not Dinamically Linked).
    – McTraher
    Jan 16, 2015 at 18:28
  • 1
    I knew about github.com/strobejb/sslhook it works against statically linked OpenSSL, but it's hard to use, because the application's binary is packed. And not just packed, but also uses complicated plugin technique.
    – McTraher
    Jan 16, 2015 at 20:10
  • 1
    Immunity Debugger looks promising, but, unfortunately, it closes right after start on my PC :(
    – McTraher
    Jan 16, 2015 at 20:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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