Transparent encryption and decryption of apihook

 

Transparent encryption implemented by apihook technology is not secure and can be easily cracked.

I am afraid that this argument is put forward by a vendor who uses transparent encryption on the driver layer. Moreover, it is said that the vendor has cracked many encryption software from other companies, but it has not yet been cracked.

In fact, it is very easy to recognize this problem. The core of transparent encryption software is encryption. There are still many auxiliary modules around it, for example, clipboard control, drag-and-drop control, and Ole embedded control. These modules cannot be processed through kernel-level modules (theoretically feasible, but I believe no one dares to do so, because they are non-public interfaces, and stability is not guaranteed ). Naturally, these modules need to be completed at the application layer.

A water pipe, from the water plant to the home, the more joints there are, the higher the possibility of problems. The same is true for encryption software. If you do the same thing, the higher the link, the higher the risk of leakage. The leakage risks of apihook-level products must also exist (because they still need to use apihook), while the driver-level products must bear the risk of leakage of the driver layer.

So why is a company able to crack a lot of other people's products and rarely crack its own products? It's very simple that the level of developers is not at the same level, at present, most of the application-layer transparent encryption software on the market is implemented by generating temporary files, and there is no effective protection for unhook, DLL force uninstallation, DLL injection, and so on. Products are full of holes and can be easily cracked without professional skills. On the other hand, the release of his product trial version is very strict, and you will not be able to crack the product if you cannot get it.

What is the relationship between the use of temporary files and the use of apihook technology for low product security?

This proposition is actually a pseudo proposition. At present, there is no evidence to prove that the apihook technology has an unsolved problem, and there is no evidence to prove that the security of apihook technology is not high. However, this is an argument raised by a netizen, so I would like to refute it here.

The quality of a transparent encryption software is critical to three aspects: robustness, performance, and stability. Because of the complexity, the stability of driver-level products has not been very good, so we will not compare them here. The rest is robustness and performance. When temporary files are generated, the plaintext is implemented, at this time, no matter whether you adopt any method to protect it, it is impossible (this has been determined by the academic community). Our country also has this requirement for encryption products. Of course, most vendors will still do some protection, such as adding a driver to prevent it from copying this plaintext (with its name-based drive encryption), or separately processing Filemon, prevent him from monitoring the temporary file. But all of this is so fragile. It is like building a bean curd project, and then adding some bamboo inside and outside.

However, for performance, the gap is even more obvious. We know that the computing speed of the CPU in modern computers has far exceeded our general needs, and the slowest device in the computer, the device that truly makes the user feel fast is the hard disk. The core of the temporary file solution is to act on the hard disk. For example, you can preview a file in Photoshop before opening it. For example, if a file is 100 MB (this is not big, most of the files I have seen in advertising companies exceed MB ). Photoshop needs to preview the file at this time. It may only need to read KB of data, but in order to read the KB of plain text, it has to read the MB file and decrypt it, then write it to the temporary files on the hard disk. In our test, decrypt the M file to the hard disk. According to the performance of the machine, it may take 8 ~ 15 seconds. You don't have to wait to preview a file. After installing the encryption software, you have to spend so much time previewing each file. If a directory contains many files, you need to find them one by one, I believe that users will be worried.

Some may say that with the promotion of SSD hard disks, the performance gap will be reduced. I agree with this idea for the moment, but don't forget that the security impact of this solution will never be solved. Of course, if you use an SSD hard disk, it will bring another and more serious problem, because the MLC chip has a very short life, it can only be written about 0.1 million times, and although the SLC chip is growing much, it is still several orders of magnitude different from the traditional Wenshi hard disk. If a temporary file scheme is used, the hard disk may be suspended one day.

So many software on the market are redirected by relying on temporary files

If all the software is implemented by means of redirection, we may feel at ease. However, this is only wishful thinking. There are still many products that use real transparent encryption technology. Fake Li GUI will be able to meet Li Yun sooner or later. As long as you talk about the working principle, which customer will use the File redirection method for the product?

Software and house building are really like, and the core technology is like the foundation. If the core technology is a pseudo technology, then the Products built on it, no matter how rich the functions are, the beautiful interface is nothing more than the luxurious decoration of bean curd. If the customer finds that there is no foundation after the house is built, I am afraid that it can only be demolished and rebuilt.

The 64-bit operating system will no longer be able to perform apihook
What a surprise. I don't know how to make such a statement, but I have encountered many people who do not know the truth to ask me this question. I want to say that I am angry with some people who spread rumors.

Speaking of everyone, the 64-bit system has added patchguard to prevent malware from entering the kernel for higher security. At the same time, he also blocked products like anti-virus software that are closely connected to the kernel, which caused companies like McAfee and symentec to report and threaten to file monopoly allegations against Microsoft. In the end, Microsoft had to make concessions to provide relevant technical materials to these vendors. However, there is no doubt that he will never provide this technology to all vendors. Unfortunately, the vast majority of Chinese vendors cannot obtain technical information in this area. To break through patchguard, you can only dimongoing. Just like the author of a virus Trojan.

Let's get started and talk about whether apihook technology works normally in a 64-bit system. We know that Microsoft has a product called detours -- the latest version is 2.1 -- a library that provides the apihook function. He provides support for three command systems: x86, x64, and IA64. Detours is widely used in Microsoft to debug some underlying software. He also provides commercial products and source code for non-commercial applications (of course, only x86 systems are supported ). I have studied the source code of detours and changed the non-commercial source code to support x64. The workload is not big, mainly because the CPU Instruction Set has changed and the address length is different.

If you want to plug yourself into the safe, ask a friend in North America to buy a commercial version of the detours source code. Otherwise, you can refer to AMD's x64 instruction set to re-Modify the source code of detours, which is much simpler and more justified than breaking through patchguard.

FAQs about the TES transparent encryption module

Q: Can I add a password? (For example, can I add some Suffixes in a word without any suffixes ?)
A: Yes.

Q: Can I perform operations in security mode and in virtual machines?
A: Yes.

Q: Can ghost, long-time cat, tomato home, and computer company versions be installed on the system except for operations below 2000 of Vista?
A: Yes.

Q: Can notepad be encrypted?
A: Yes.

Q: How do I deal with temporary files?
A: we do not need to generate additional temporary files.

Q: How is screenshot taken?
A: You can handle the problem by yourself or purchase an anti-screenshot module.

Q: What is the stability of xes? Will the screen be blue or dead? Will encrypted files be decrypted and cannot be opened?
A: It is very stable. This is our biggest advantage. At the same time, application-layer solutions cannot lead to blue screens. The application-layer solution does not open files.

Q: I heard that the transparent encryption technology based on the driver layer is easier to crack, right?
A: At present, the vast majority of encryption software on the market is based on the application layer. Because it cannot handle several key technical issues, most of them adopt file redirection, that is, to open an encrypted file, first decrypt the file to a temporary file, and then redirect all the reads and writes to the encrypted file to the decrypted file. There is no doubt that using this method has a very high speed impact. What's more important is that the plaintext is generated on the hard disk. As long as there is a little technical knowledge, you can know where the file is decrypted, then you can crack it. There is no doubt that this method of application-layer encryption is easily cracked. The TES transparent encryption module uses a breakthrough technology to truly achieve the hard disk's goal of ignorance, and does not significantly affect the speed.

Q: Will the TES encryption module affect performance?
A: theoretically, an extra layer of encryption will certainly have a certain impact. However, the transparent encryption of TES is completed on demand. He does not have instant concurrent processing, so the user will not feel this difference when using it. For example, when Photoshop opens a graph, the preview of the graph may be displayed first. If the image is 100 MB. The data required for previewing is 20 kb. In fact, we only need to decrypt the 20 k Data and the process is completed in the memory. In today's high-performance CPUs, this impact is impossible for users to feel.

Q: What are the main differences between the TES transparent encryption module and kernel-layer encryption technologies such as TEFs and SEFs?
A: Unlike the encryption technology based on the driver layer, Tes always gives priority to stability and compatibility. First, technically, it is impossible for him to produce blue screens. Secondly, because of the closeness of Microsoft's operating system, the more difficult it is to manipulate the underlying technical details, the less unknown it is. Therefore, encryption based on the driver layer often causes problems such as permanent file damage, which cannot be effectively solved. However, all apsaradb for TES uses mature technologies. Currently, it is used on around 13,000 servers. No record indicates that it will cause file damage. In addition, the genuine version in China is poor. A large number of systems contain Trojans, viruses, and other malware. the driver-layer-based encryption has poor compatibility with these systems and usually requires the customer's computer to be clean, in this regard, the requirements of TES are much looser.

Q: What is the difference between the TES transparent encryption module and other application-layer encryption technologies?
A: compared with the application-layer encryption technology adopted by some companies, Tes has a fundamental breakthrough. In terms of scalability, Tes adopts the same processing method as the drive layer encryption, and adopts a unified processing method for all Io operations. Therefore, it is not necessary to develop different application software separately. In terms of speed, the working principle of TES does not cause a significant reduction in performance. In terms of anti-cracking, the TES has already dealt with the available cracking methods.

Q: Since Tes is based on the application layer, do you need to develop different applications?
A: The internal implementation of TES is similar to that of the kernel layer. It is a complete process of the input and output interfaces of the system, so no specific development is required. Including console programs and programs that use memory ing to read and write files can be processed normally.

 

 

I saw a transparent encryption software that introduced Nb a few days ago.

We can see that it supports memory ing files, but the common practice is file redirection, that is, to decrypt the file when it is opened and to encrypt the file when it is closed. I don't know how this software works. in the usual way, run word, write a piece of text, run Filemon, and set the filter condition to writefile. OK. Save the file. If there is no obvious record, the redirection method is used. If it is not, the processing method similar to tes is also implemented. But it seems a bit strange. There is a point card when saving files. I suddenly think of the many difficulties I encountered during the development of the TES kernel, and I plan to give up and adopt redirection. At that time, Filemon detected a disgusting way to prevent redirection. This buddy is also very talented.

In this case, the Filemon enhanced version procmon is used. The process is still the same. Run word and set the condition of procmon to processname=winword.exe and operation = write_file. OK, save the file, and finally the fox tail comes out. The log clearly shows the redirection path.

It seems that I have no idea at all. I used the processing method I thought of N years ago. We know that Filemon obtains various file operations from the driver and then transmits them to the application layer module for display. Earlier versions of Filemon were open-source, and the format for transferring data was public. With this, we can separately process the Filemon software. When the log content is a redirection file, this log is cleared.

Run Filemon again, and then run rku. Click COOD hooks to verify my opinion again. The deviceiocontrol of Filemon is hooked.

After completing this step, the system prompts me to say that the virtual memory usage, I quickly checked the memory, and found that the memory occupied by assumer.exe accounted for more than 800 mb of memory. It seems that this Nb software is very Nb in terms of Memory leakage.