DotFix NiceProtect provides leading-edge, solid protection for your Windows applications
One year ago we released DotFix NiceProtect 6.0, a revamped version of our product. There are so many changes in version 6.x that it would take a full-size article to describe all of them! Though we had painstakingly tested and debugged NiceProtect, we decided not to publish such an article right away but instead try to further improve our product. Among other things, we provided it to the major anti-virus vendors to let them check it out. We worked together with many of them to help them prevent false positives. We shared our technology with them to help their anti-virus products accurately analyze code protected by NiceProtect. We have carefully debugged and tested the latest version of our product, and our clients have successfully used it to protect their software. We believe it's time to tell you about all the new technologies and approaches we used in DotFix NiceProtect 6.
None of the major improvements would be possible if we had based the new version of our product on the original architecture. DotFix NiceProtect 5.x was based on the architecture we developed back in 2006. That architecture, in turn, replaced the earlier one used in DotFix LiteProtect 3.x. Though we made a lot of changes, we kept the major parts, which dramatically slowed down the implementation of new technologies. But when developing DotFix NiceProtect 6.x, we designed the entire code protection architecture from scratch! This time, we used a different approach to protecting code and using code protection modules. As a result, now our product is both more functional and much faster than before!
Another thing that slowed down the development of our product was the binary data compression algorithm. When we initially designed it, we only intended to support 32-bit files. Moreover, the need to protect the loader and the unpacker imposed limitations on using relocation tables, which was critical for .dll and .ocx files. The bottom line is that it would be pretty difficult to add support for .dll and .ocx files and for 64-bit code in the future versions. So we decided to design a new packer from scratch using leading-edge data packing and data protection technologies.
Now our packer, which is based on a new architecture, has features that are unavailable in other code protection products available in the market. Many products developed by our competitors are based on code written in the early 2000s, but a lot of things have changed since then. Many products heavily rely on the compatibility options available in the newer operating systems. Luckily for them, such options are still available even in the latest version of Windows. However, the need to use such options imposes certain restrictions on the ability to protect code and makes it difficult or impossible to use the latest run-time code protection methods. For example, many packers are incompatible with ASLR (address space layout randomization), and some of them are still incompatible with DEP (data execution prevention).
DotFix NiceProtect doesn't have such drawbacks! Moreover, we have implemented separate packing of application resources and packing of the decompression algorithm, so the attacker cannot analyze and modify it. Last but not least, our product generates a different unpacker code or any other NiceProtect module each time it is used. It also adds a lot of garbage code to the code being protected, so using scripts, automatic analyzers, and unpackers won't be an option for the attacker.
Among other things, our company specializes in developing decompilers. We know a lot about the internals of many compilers, especially those for Delphi, Free Pascal, and Visual Basic. As we develop leading-edge decompilers, we can use our vast experience in that area to better protect code and data from unwanted analysis. Most other code protection products can only protect your application code by using virtualization or mutation techniques. The problem is, they do not modify the compiler's housekeeping data, which can be used by the attacker to analyze and eventually crack your software.
Different compilers add different housekeeping data to the files. The software development framework that you use also adds its meta data. Any files compiled in Delphi (including Delphi 10.2.2 Berlin, the latest version available at the time of writing this article), Free Pascal (Lazarus), and Visual Basic (5.0 or 6.0) contain the names of all classes, forms, and form objects. Such files also contain the names of public functions in Delphi classes or the names of public procedures or functions in Visual Basic forms or class modules. They are used to generate virtual method tables in Visual Basic 6 or run-time type information (RTTI) tables for each class in Delphi (for built-in VCL classes or user-defined classes).
Moreover, such files contain all kinds of references to objects, which makes the attacker's job even easier. To protect all of that information from the attacker, you need to decompile the file, make a list of values to be modified (filtering out the values that should not be modified), and make the necessary changes. To do it, you need to have a decompiler for each version of each supported compiler or software development framework. No need to say it takes a lot of work to develop all of them. Naturally, it's only reasonable to do it if you develop decompilers, too. That's why only DotFix NiceProtect can obfuscate different compilers' housekeeping data! And we are happy to provide that functionality to our clients.
Thanks to the new architecture, we finally were able to add support for the standard .dll, ActiveX .dll (containing TypeLibrary information), and .ocx (COM OLE control) files. The major problem was to generate unique loader code each time when protecting the same file. When loading .dll or .ocx files, the operating system can place their data anywhere in the memory, and such files must contain the addresses of all address-dependent data. All of that makes it easier for the attacker to analyze and crack the software. The approach that you can use to protect .exe files cannot be applied to .dll or .ocx files.
There are two options:
1) You can let the operating system modify only one address in the loader, and then, based on that change, the loader can modify all the address-dependent parts of the software being protected. Most other code protectors available in the market use this approach.
2) Generate relocation tables not only for the code being protected, but also for the garbage code added to it. This approach increases the number of items relocated by a factor of 100, making it extremely difficult for the attacker to analyze such code.
DotFix NiceProtect can use the first approach or the second one, depending on the type, content, or other parameters of the file being protected. In some cases, it even combines the two approaches. As a result, NiceProtect provides the most effective code protection and makes nearly impossible for the attacker to use scripts or automatic unpackers, because such software cannot automatically analyze all the combinations of protection methods.
Commercial software products rarely use TLS technology. Even when they use it, it is usually only an initial callback generated by the compiler. That's why many code protection products only support the initial callback but not full-fledged TLS tables. Unlike them, DotFix NiceProtect 6.x supports any number of TLS callbacks, both service callbacks and user-defined ones. That functionality works similarly for .exe and .dll/.ocx files, so the software developers have more options when protecting their code.
DotFix NiceProtect has always been able to protect functions selected in the .map file generated by the compiler. There was only one limitation: It supported only the Microsoft and Borland/Embarcadero compilers (Visual C++, Visual Basic, and Delphi).
Recently the Qt cross-platform software development environment, which is based on the C++ programming language and the Qt library set, has gained popularity. The Lazarus project based on the Free Pascal compiler has picked up momentum, too. The problem is that the .map files generated in these two software development environments have a completely different structure and are totally incompatible with the Microsoft and Borland standards.
We have done a lot of research to analyze all kinds of .map files and add support for them. As a result, now DotFix NiceProtect has the best support for different .map files. No other code protection product available in the market can offer the same capabilities!
We believe that each software product should be easy to use. In many other code protection products, the disassembler that displays the functions being protected has been implemented without much thinking about the user's needs. But when selecting the functions to be protected, it's very useful to see such information as the function's name, what it does, and how the compiler implemented it. Surely the user can use an external tool, but why? If your product is used to protect some code, it should be able to display that code, too. Even the earliest versions of DotFix NiceProtect displayed not only the disassembled code of the function being protected, but also the code that the attacker would see after the protection method (virtualization or mutation) has been applied.
We decided that's not enough to achieve the best user experience! So we added a function name demangler for Delphi, C++, and FreePascal. (The function name demangler for Visual Basic 6.0 was already available.) Such things make it much easier to select functions to be protected.
But we wanted to do even more! We added a syntax highlighter for the disassembler to highlight all calls and jumps, and highlight strings and functions called using different colors. As a result, the user can easily view and identify such things.
DotFix NiceProtect has been supporting IEEE Taggant certificates (cryptographic signatures) for quite a long time. We provide a Taggant certificate to each client for free. The taggant can be used in addition to the code signing certificate. The only difference is that taggants only allow anti-viruses and internet security software to identify the files. Many anti-virus products already support IEEE Taggants and trust the files containing such signatures. The structure of a software taggant is very similar to that of a Code Signing Certificate. We issue taggants using the name of the client (person or company). Unlike many of our competitors, we issue taggants using the actual name of the client or of the company, not a template name like "Customer121". Thanks to that, anti-malware solutions can trust the files protected by DotFix NiceProtect, especially if the Code Signing Certificate and the IEEE Taggant are issued using the same name.
There were many changes in the IEEE taggant system in 2016-2017: The IEEE timestamp servers sometimes changed without prior notice; taggant verification on the VirusTotal server worked incorrectly from time to time; etcetera, etcetera. Alas, the taggant working group of the IEEE Standards Association respond to many issues, to put it mildly, not fast enough. So we added additional settings to DotFix NiceProtect to let the user change the timestamp server or avoid using an additional timestamping on the IEEE servers. Hopefully, it can help prevent downtime and ensure stable operation of the software product regardless of the changes in the IEEE taggant system.
We have also fixed all the previously found bugs and incompatibilities. Moreover, we have improved the user interface and finalized the documentation. As a result, now DotFix NiceProtect is even greater than before! If you are already our client, you can always get the latest update at a reduced price. If you have just learned about our product, we'll be happy to see you among our clients!
New architecture
None of the major improvements would be possible if we had based the new version of our product on the original architecture. DotFix NiceProtect 5.x was based on the architecture we developed back in 2006. That architecture, in turn, replaced the earlier one used in DotFix LiteProtect 3.x. Though we made a lot of changes, we kept the major parts, which dramatically slowed down the implementation of new technologies. But when developing DotFix NiceProtect 6.x, we designed the entire code protection architecture from scratch! This time, we used a different approach to protecting code and using code protection modules. As a result, now our product is both more functional and much faster than before!
New packer
Another thing that slowed down the development of our product was the binary data compression algorithm. When we initially designed it, we only intended to support 32-bit files. Moreover, the need to protect the loader and the unpacker imposed limitations on using relocation tables, which was critical for .dll and .ocx files. The bottom line is that it would be pretty difficult to add support for .dll and .ocx files and for 64-bit code in the future versions. So we decided to design a new packer from scratch using leading-edge data packing and data protection technologies.
Now our packer, which is based on a new architecture, has features that are unavailable in other code protection products available in the market. Many products developed by our competitors are based on code written in the early 2000s, but a lot of things have changed since then. Many products heavily rely on the compatibility options available in the newer operating systems. Luckily for them, such options are still available even in the latest version of Windows. However, the need to use such options imposes certain restrictions on the ability to protect code and makes it difficult or impossible to use the latest run-time code protection methods. For example, many packers are incompatible with ASLR (address space layout randomization), and some of them are still incompatible with DEP (data execution prevention).
DotFix NiceProtect doesn't have such drawbacks! Moreover, we have implemented separate packing of application resources and packing of the decompression algorithm, so the attacker cannot analyze and modify it. Last but not least, our product generates a different unpacker code or any other NiceProtect module each time it is used. It also adds a lot of garbage code to the code being protected, so using scripts, automatic analyzers, and unpackers won't be an option for the attacker.
Revamped obfuscator
Among other things, our company specializes in developing decompilers. We know a lot about the internals of many compilers, especially those for Delphi, Free Pascal, and Visual Basic. As we develop leading-edge decompilers, we can use our vast experience in that area to better protect code and data from unwanted analysis. Most other code protection products can only protect your application code by using virtualization or mutation techniques. The problem is, they do not modify the compiler's housekeeping data, which can be used by the attacker to analyze and eventually crack your software.
Different compilers add different housekeeping data to the files. The software development framework that you use also adds its meta data. Any files compiled in Delphi (including Delphi 10.2.2 Berlin, the latest version available at the time of writing this article), Free Pascal (Lazarus), and Visual Basic (5.0 or 6.0) contain the names of all classes, forms, and form objects. Such files also contain the names of public functions in Delphi classes or the names of public procedures or functions in Visual Basic forms or class modules. They are used to generate virtual method tables in Visual Basic 6 or run-time type information (RTTI) tables for each class in Delphi (for built-in VCL classes or user-defined classes).
Moreover, such files contain all kinds of references to objects, which makes the attacker's job even easier. To protect all of that information from the attacker, you need to decompile the file, make a list of values to be modified (filtering out the values that should not be modified), and make the necessary changes. To do it, you need to have a decompiler for each version of each supported compiler or software development framework. No need to say it takes a lot of work to develop all of them. Naturally, it's only reasonable to do it if you develop decompilers, too. That's why only DotFix NiceProtect can obfuscate different compilers' housekeeping data! And we are happy to provide that functionality to our clients.
Support for .dll and .ocx files
Thanks to the new architecture, we finally were able to add support for the standard .dll, ActiveX .dll (containing TypeLibrary information), and .ocx (COM OLE control) files. The major problem was to generate unique loader code each time when protecting the same file. When loading .dll or .ocx files, the operating system can place their data anywhere in the memory, and such files must contain the addresses of all address-dependent data. All of that makes it easier for the attacker to analyze and crack the software. The approach that you can use to protect .exe files cannot be applied to .dll or .ocx files.
There are two options:
1) You can let the operating system modify only one address in the loader, and then, based on that change, the loader can modify all the address-dependent parts of the software being protected. Most other code protectors available in the market use this approach.
2) Generate relocation tables not only for the code being protected, but also for the garbage code added to it. This approach increases the number of items relocated by a factor of 100, making it extremely difficult for the attacker to analyze such code.
DotFix NiceProtect can use the first approach or the second one, depending on the type, content, or other parameters of the file being protected. In some cases, it even combines the two approaches. As a result, NiceProtect provides the most effective code protection and makes nearly impossible for the attacker to use scripts or automatic unpackers, because such software cannot automatically analyze all the combinations of protection methods.
TLS callbacks
Commercial software products rarely use TLS technology. Even when they use it, it is usually only an initial callback generated by the compiler. That's why many code protection products only support the initial callback but not full-fledged TLS tables. Unlike them, DotFix NiceProtect 6.x supports any number of TLS callbacks, both service callbacks and user-defined ones. That functionality works similarly for .exe and .dll/.ocx files, so the software developers have more options when protecting their code.
MAP files
DotFix NiceProtect has always been able to protect functions selected in the .map file generated by the compiler. There was only one limitation: It supported only the Microsoft and Borland/Embarcadero compilers (Visual C++, Visual Basic, and Delphi).
Recently the Qt cross-platform software development environment, which is based on the C++ programming language and the Qt library set, has gained popularity. The Lazarus project based on the Free Pascal compiler has picked up momentum, too. The problem is that the .map files generated in these two software development environments have a completely different structure and are totally incompatible with the Microsoft and Borland standards.
We have done a lot of research to analyze all kinds of .map files and add support for them. As a result, now DotFix NiceProtect has the best support for different .map files. No other code protection product available in the market can offer the same capabilities!
Easy-to-use disassembler
We believe that each software product should be easy to use. In many other code protection products, the disassembler that displays the functions being protected has been implemented without much thinking about the user's needs. But when selecting the functions to be protected, it's very useful to see such information as the function's name, what it does, and how the compiler implemented it. Surely the user can use an external tool, but why? If your product is used to protect some code, it should be able to display that code, too. Even the earliest versions of DotFix NiceProtect displayed not only the disassembled code of the function being protected, but also the code that the attacker would see after the protection method (virtualization or mutation) has been applied.
We decided that's not enough to achieve the best user experience! So we added a function name demangler for Delphi, C++, and FreePascal. (The function name demangler for Visual Basic 6.0 was already available.) Such things make it much easier to select functions to be protected.
But we wanted to do even more! We added a syntax highlighter for the disassembler to highlight all calls and jumps, and highlight strings and functions called using different colors. As a result, the user can easily view and identify such things.
IEEE Taggant Certificates
DotFix NiceProtect has been supporting IEEE Taggant certificates (cryptographic signatures) for quite a long time. We provide a Taggant certificate to each client for free. The taggant can be used in addition to the code signing certificate. The only difference is that taggants only allow anti-viruses and internet security software to identify the files. Many anti-virus products already support IEEE Taggants and trust the files containing such signatures. The structure of a software taggant is very similar to that of a Code Signing Certificate. We issue taggants using the name of the client (person or company). Unlike many of our competitors, we issue taggants using the actual name of the client or of the company, not a template name like "Customer121". Thanks to that, anti-malware solutions can trust the files protected by DotFix NiceProtect, especially if the Code Signing Certificate and the IEEE Taggant are issued using the same name.
There were many changes in the IEEE taggant system in 2016-2017: The IEEE timestamp servers sometimes changed without prior notice; taggant verification on the VirusTotal server worked incorrectly from time to time; etcetera, etcetera. Alas, the taggant working group of the IEEE Standards Association respond to many issues, to put it mildly, not fast enough. So we added additional settings to DotFix NiceProtect to let the user change the timestamp server or avoid using an additional timestamping on the IEEE servers. Hopefully, it can help prevent downtime and ensure stable operation of the software product regardless of the changes in the IEEE taggant system.
We have also fixed all the previously found bugs and incompatibilities. Moreover, we have improved the user interface and finalized the documentation. As a result, now DotFix NiceProtect is even greater than before! If you are already our client, you can always get the latest update at a reduced price. If you have just learned about our product, we'll be happy to see you among our clients!
(C) Sergey Chubchenko, DotFix NiceProtect's main developer