Win32 and .NET Application Protection: Themida Tread Overview (X-Protector)

    This review is about Themida (formerly X-Protector), one of the most powerful and reliable Win32 application protectors. Since I recently needed Themida for one of my applications, I decided to write a short review on it. At the same time, he asked the author to answer some questions that interest me. I think the answers will be of interest to you too. Look for the results of this short interview at the end of the article.

    I want to draw attention to the fact that the article was written based on Themida version 2.1.3.30, the latest as of the date of this review. It has several new features regarding macros. A demo of two years ago from the official site, they are deprived.




    Basic information



    In fact, there are four products based on Themida technology.

    The basic version from Professional differs only in the lack of ability to work with .NET applications. Everything we talk about further will work both in Themida and in WinLicense.
    • Themida is the protector itself, which is the main subject of this article.
    • WinLicense is Themida with the addition of the ability to protect applications based on various kinds of serial numbers. The WinLicense SDK itself can generate these serial numbers, check them, store them safely, bind to hardware, create trial serial numbers with the expiration of the specified date or through the specified number of starts, create password-protected applications, and so on.
    • X-Bundler is a plugin for Themida and WinLicense, which allows you to embed external files in a secure application. For example, you can embed a help file or * .mp3 file. Moreover, you can access this file from the application as an external one lying on the disk. The application will not even know that the file is protected by Themida and is inside your * .exe. You can also embed the assemblies used by the .NET application inside the main * .exe file.
    • WinLicense DLL Control is a plugin for WinLicense, with which you can implement your protection options based on serial numbers.
    • CodeVirtualizer is a small independent piece of Themida that allows you to exclusively convert the specified functions inside your application into code for Themida virtual machine. It does not provide any other protection (protection from debugging, encryption, integrity checks and other things is not in it). Allows you to protect both x32 and x64 applications, including drivers.

    Themida Auto-Protect Features


    First, about the "boring platitudes."
    • Anti debugger. Both detection of standard debuggers and kernel level debuggers are supported. There is also an aggressive search mode, but in this case, the application may refuse to run on computers with active anti-Russians, rootkits or under Wine.
    • Anti-dumper. Themida protects applications constantly. A dump of the application’s memory to disk with subsequent launch will not remove protection (who would doubt it ... Such primitive methods have not been working for a long time)
    • Entry Point Obfuscation (OEP). Themida hides the entry point to the library or application.
    • Resource encryption. If any resources (icons, files, etc.) are included in your application, they will be encrypted and decrypted only when accessing them.
    • VMWare / VirtualPC compatibility. You can activate this mode so that a protected application can run under hypervisors.
    • Wrapping calls to the Windows API. Themida hides information about the Windows API functions that your application calls. Information about the libraries required to run is also not available to the cracker.
    • Protection of the application from modification. Themida can check the integrity of the application when it starts, preventing the modified copy of the application from starting. You can activate the mode in which the application after protection can be freely signed.
    • Protecting application memory from modification during execution (useful if you are developing, for example, a game).
    • Code mutation technology. All Themida kernel code that is associated with your application is mutated and smeared. Each time this code is regenerated using virtualization techniques (see below).
    • Protection against file and registry monitoring. Themida does not allow external programs to track the access of a protected application to files or the registry.
    • Compression. The application of protection leads to a rather large increase in the size of the executable file on disk. To reduce this size, Themida supports compression of both the application itself (with a built-in security code) and its resources.
    • Themida is able to protect forms of Delphi / C ++ Builder from a special way. The contents of the forms (in fact, a * .dfm file) cannot be extracted both from * .exe or during application execution.

    Almost all of the described features can be turned on / off as you wish.

    CodeReplace Technology


    CodeReplace technology extracts parts of an application, inserts junk code in their place, mixes the original code with the security code and stores it elsewhere in the application. When you run a piece of code protected by CodeReplace, after numerous checks, it is extracted and decrypted. After execution, it is again replaced by garbage. Themida itself can analyze your application and select functions that seem to be suitable for such protection. But it will be better if you do it yourself with the help of macros (we will discuss them later).



    Virtual machine


    Themida Virtual Machine is one of the most powerful ways to protect an application. Its essence is that parts of your code are replaced with the generated assembler code, but not native to Intel processors, but code for an abstract virtual processor with its own instruction system and internal structure. Themida randomly generates a plan of its architecture each time. Thus, it becomes difficult to understand the security code.
    Themida supports several types of virtual processors:
    • CISC. Basic protection, protected code is relatively fast.
    • CISC-2. Extended protection, the code takes up more space than in the case of CISC. A bit slower.
    • RISC-64. Each virtual instruction takes 64 bits, protection is stronger than CISC, but protected code is slow to execute.
    • RISC-128. Advanced Super Slow and Super Protected RISC-64

    CISC processors support the simultaneous embedding of several virtual processors of the same type in a secure application, but with a different system of instructions. This increases security, but increases the size of the application executable code.

    Noise generation allows you to mix useful work instructions with nothing meaningful to make the hacker even more difficult to work with.

    As with CodeReplace, Themida can choose which functions within your program to protect by converting to code for a virtual machine. But it is better to do it yourself (see below).



    Other


    • Themida allows you to hide the application from PE-scanners, which determine what the application is protected with.
    • There are options for localizing the application interface (windows with errors and system messages) and inserting screensavers (nevertheless, the launch time of the protected application increases by 500-5000 milliseconds depending on the protection settings, you need to keep the user busy at this time).
    • Themida supports command-line management, which allows you to integrate it into the Build system.

    Now a little about sad things. Even if you use everything listed above, your application can still be broken. To make the hacker more difficult, use Themida macros. We’ll talk about them now.

    Themida Macros.


    Themida macros are byte sequences embedded in an application that do not affect its operation in any way until you protect the Themida application. They have a special meaning for the tread. In fact, they inform Themida about the intricacies of the internal structure of your code, allowing you to more effectively protect it.
    Macros have start and end markers, determining the amount of source code to which they apply. There are ready-made macros in the SDK for assembler, C, D, Delphi and VisualBasic / Pure Basic. But in principle, they can be redone in two minutes for any language that supports assembler or just byte insertions into the code. Here I will use the Delphi syntax that is closest to me.

    Attention! Macros cannot be used in .NET applications or in Visual Basic applications compiled into P code.

    VM


    The VM macro limits the area of ​​code that Themida should virtualize (turn it into instructions for the virtual machine whose settings you specify in the interface). It is used as follows: In this macro, it is recommended to wrap sections of code whose algorithm is of particular secrecy. For example, checking an activation key, decrypting data files, checking for a security key, and so on. Limitations:

    {$I VM_Start.inc}
    // код программы
    {$I VM_End.inc}





    • Directly inside the block there should be no work with exceptions (try, raise)
    • No other macros can be used inside the block.


    VM_WithLevel


    The macro is similar in everything to the VM macro, but provides additional protection by increasing the level of virtualization by the amount you specify. It is also used. To specify the required level of virtualization, you will have to edit the corresponding * .inc file in Delphi (see the comment in it). The high value of the virtualization level will lead to strong bloating of the code. At level 0, a macro behaves the same as a VM macro.

    The limitations are the same as for the VM macro.

    CodeReplace


    The macro marks the code for processing by the CodeReplace technology, which we talked about above. Used in the same way as the VM macro.
    The limitations are the same as for the VM macro.
    Encode
    Macro marks a block of code that needs to be encrypted and decrypted exclusively before execution, encrypted backward when exiting the block. It is used the same as the VM macro. This macro provides weaker protection than the VM and CodeReplace macros, but the code under it works much faster.

    Limitations:
    • Cannot be used in DLL
    • Inside a block, you cannot declare variables or exit a procedure (return / exit)


    Clear


    The macro marks a block of code that will be removed from the process after the first call. This macro is recommended for operations that your program performs only once on startup. For example, calculating session keys for exchanging data or checking for a license key. Used in the same way as the VM macro.

    Limitations:
    • Cannot be used in DLL


    Unprotected


    Marks the block that will be deleted from the application after protection. For example, it can be used to make the application report if it is not protected. It is used as well as all described macros. It has no limitations.

    Checkprotection


    In the demo version of Themida, this macro is not available. It is used to verify the correctness of the application security system. Its use is best shown by an example taken from Themida SDK.
    procedure TForm1.Button4Click (Sender: TObject);
    var
      StatusProtection: Integer;
    begin
        {$ I CheckProtection_Prolog.inc}
        asm
          push $ 33333333
          pop StatusProtection
        end;
        {$ I CheckProtection_Epilog.inc}
        if StatusProtection = $ 33333333 then
          MessageBox (0, 'Protection OK.', 'Security Validation Macro', MB_OK + MB_ICONINFORMATION)
        else
          MessageBox (0, 'Application protection is violated!', 'Caution!', MB_OK + MB_ICONERROR);
    end;
    

    You define a number (of type Integer / Cardinal) that the macro should return if everything is ok with the protection. In this example, 0x33333333. When protected, assembler push and pop instructions will be removed from the program. Instead, a complex verification procedure will be inserted, which will return the number you specified in the specified variable (in our example, StatusProtection) only if it does not detect security violations. If a security breach is detected, the number will be random.

    Of course, in real life, as shown, this macro cannot be used. The simplest thing is to take any important constant used in the project, the value of which is not too obvious in the context and replace it with a variable. Then use this macro on this new variable somewhere earlier in the code. If protection is removed, the value of this constant / variable will turn out to be incorrect, which, most likely, will lead to the crash of the application in the most unexpected places.

    Inside the macro block, there should be nothing but the specified assembler instructions.

    CheckCodeIntegrity


    In the demo version of Themida, this macro is not available. The macro is very similar to CheckProtection, it just works with another part of the security system. Its use is exactly the same.

    CheckVirtualPC


    In the demo version of Themida, this macro is not available. The macro is similar to the previous two, but it doesn’t check for a security system, but for launching a protected application under a hypervisor like VirtualPC or VMWare. Its use is exactly the same. Unless it should be combined with the corresponding checkmark in the program interface. Then, in a protected application, when a launch is detected under Themida hypervisor, it will give a warning, and if under VirtualPC they try to run a variant of the application with the Themida protection part removed, you will be helped out by a macro.

    Security features for .NET applications.


    Despite the fact that Themida can protect .NET applications, you need to keep in mind the following:
    • After .NET protection, the application (* .exe) ceases to be a .NET assembly and becomes a regular Win32 application (with the preservation, however, of all its functions, it was tested on the * .exe file of Paint.NET). Downloading the application as a .NET assembly will no longer work. Of course, this prevents utilities like ILDASM from working.
    • Macros within .NET applications are not supported.
    • The IL code inside the application remains untouched, although it is encrypted, like all the contents of a * .exe file. It can be treated with an obfuscator before protecting Themida.
    • Protection of individual assemblies as * .dll is not yet supported. However, using the X-Bundler, assemblies can simply be integrated into the main * .exe file.


    A short interview with Raphael


    • What was the reason for the discontinuation of the development of X-Protector and the release of Themida?
    • A few reasons. X-Protector was notorious for compatibility issues. We wanted to release a new product devoid of these shortcomings. In addition, the development team has changed somewhat.
    • What are your plans for Themida64 (support for protecting 64-bit applications)?
    • Themida for x64 will be released in the coming months, and in the very near future our beta testers will receive it.
    • What are the benefits of Themida custom builds?
    • Unfortunately, we do not currently provide such a service, although we do have some options for customers with specific compatibility requirements.
    • I have seen Wine and ReactOS mentioned in the help file. Are Themida-protected applications working in these environments?
    • Yes, applications protected by our tread should work successfully in these environments. These are the requirements of a large number of our customers.
    • Does Themida use ring-0 based protection?
    • Some time ago, the first versions of Themida did offer such protection. But after some time we removed the use of ring-0 to increase compatibility with new versions of Windows, implementing protection based on code virtualization instead.
    • Themida is an extremely powerful tread. But what do you think about the approach that was implemented in ExeCryptor (the code there did not turn into codes for a virtual machine, but simply mutated and complicated, remaining native to the processor).
    • I think ExeCryptor still had its own virtual machine. The opcodes that could be emulated were emulated. Those that can not - mutated in the x86 version. In any case, this is what I heard, for sure I do not know.
    • What are your plans for the future of Themida?
    • In general, we are thinking of a serious redesign to further enhance protection. But first of all, x64 support will be released, and all subsequent versions of the tread will support both x32 and x64 applications.



    Also popular now: