How to debug / analyze a Themida protected binary

Question

Background: I have an application that has worked fine up until Windows 10 build 1511 but broke as of build 1607. It produces an access violation:

STACK_TEXT:  
03799f54 00f91cfa     24d1ae78 0000000f 0000001f GDI32!ext-ms-win-gdi-internal-desktop-l1-1-0_NULL_THUNK_DATA_DLB+0xc22b
WARNING: Stack unwind information not available. Following frames may be wrong.
0379a01c 01570000     00000000 00000000 00000023 THEEXE+0xb91cfa
0379a038 77015125     00000000 00000000 01ba0254 THEEXE+0x1170000
0379a088 00cd691c     0379afa8 016a5276 00000000 ntdll!RtlpAllocateHeapInternal+0x155
00000000 00000000     00000000 00000000 00000000 THEEXE+0x8d691c

Win10 1607 and higher have a change in GDI dll's, before there was only gdi32.dll and GdiPlus.dll but as of 1607 gdi32.dll is basically a stub for a new dll, gdi32full.dll

I want to understand why the app crashes and find a workaround. The fact that the exe is packed makes analyzing it with WinDbg, Ida Pro etc very difficult. PE ID tools suggest that the exe is packed with Themida (Themida v2.0.1.0 - v2.1.8.0 (or newer) + Hide PE Scanner Option).

I tried to follow a tutorial involving OllyDBG and a script named Themida - Winlicense Ultra Unpacker 1.4.txt and although this seems to go a long way it does not result in a correct unpacked binary. The issue might be that some of the code is executing outside of the address space as defined in the PE sections because I get several errors like this:

Memory breakpoint range reduced: OllyDbg is unable to activate memory breakpoint on the whole specified address range (EA:   ). Breakpoint is reduced to range 00401000..0086CFFF.

Also tried unthemida 2.0 and unthemida 3.0 but they hang after creating the process (which appears to be terminated). I'm looking for help or pointers on how to unpack the exe so I can analyze the crash.

A free version of the software that has the same issue can be found here (installer). The exe can be found here: removed

The crash can be reproduced by starting the application and click open on the supplied example project (EAExample.eap).

Answer 1

I found the cause of the crash which is... Themida 🤦‍♂️

What happens is that from build 1607 and higher some exports have a double redirection using api sets. The app imports a couple of functions from Usp10.dll which have an apiset redirection to Gdi32.dll and inside Gdi32.dll there is an apiset redirection to Gdi32full.dll.

Themida "understands" or follows the first api set redirection and uses an asm JMP instruction to jump to Gdi32.dll. The ApiSet name is then executed as if it's code, resulting in strange opcodes (but it is of course the api set name in ascii) and thus the crash dump doesn't make sense.

I've resolved it by writing a JMP instruction at the various API's in Gdi32.dll to the actual implementation in Gdi32full.dll using an attached debugger.

Answer 2

You can start with static analysis. Dump the file at runtime and see what you can gather from the dumped file. You can rebuild the import table with tools like Scylla. Generally, the above reconstructed file is pretty good for analysis already. Since you mentioned files relating to gdi32.dll, reconstructing the import table would do you good.

If it is not sufficient, you will need to use OllyDbg with anti-anti-debugging plugins. Try tools such as Phant0m (has a kernel driver), ScyllaHide, etc.. I can't remember the exact configuration - just look it up on Google. After you bypass their anti-debugging features, you should have a much better time analyzing the code or trying the unpacker script.

The hardest part of unpacking Themida would be their code virtualization feature. If it is enabled and used, then you will probably need to rely on the unpacker script, or find someone with deep knowledge to reverse it. Would be very tough then.