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.