Technical analysis of DLL and Trojan horse

Many friends still do not know the rise of the recent years, "DLL Trojan" why. What is a "DLL"? What's the difference between it and a typical Trojan?

First, from the DLL technology.

To understand the DLL, you have to know what this "DLL" means, so let's go back a few years ago, when the DOS system was on its way. At the time, writing a program was a tedious task, because each program's code is independent, sometimes in order to implement a function, it is necessary to write a lot of code, and later with the development of programming technology, programmers put a lot of common code set (common code) into a separate file, and the file called "Library" ( Library, when you write a program, you can add it to the compiler to use all the functionality that the library contains without having to write a bunch of code yourself, a technique called static link. Static link technology Let the tired programmer sigh, everything seems to be beautiful. But it turns out that good things don't last long, because static links are like a rude salesman, and they all stick to your hand, whether you want them or not. Writing a program only wants to use one of the graphic effects contained in a library file, because of this, you have to add all the graphics effects of this library file to the program, keep them as a vase, which is not important, but these vases have blocked the road-static link technology to make the final program into a big, Because the compiler also counted the entire library file.

The development of the Times, static link technology due to the inherent drawbacks, can not meet the wishes of programmers, people began to find a better way to solve the problem of code duplication. Later, the Windows system appeared, the era of the watershed finally emerged. Windows systems use a new link technology, the new technology known as dynamic Link, which also uses library files, which Microsoft calls "dynamic link library" ――dynamic link library,dll. The dynamic link itself is no different from static links, but it also writes the generic code into separate files, but in terms of compiling, Microsoft has gone around and not taken the method of adding library files to the program, but instead of making them into compiled program files, giving them an interface for exchanging data, and when programmers write programs, Once you want to use a function function of a library file, the system puts the library file into memory, connects the task process that this program occupies, then executes the function function that the program uses, and returns the result to the program to display, in our opinion, it is like the function of the program itself. Once the required functionality has been completed, the DLL stops running and the entire call process ends. Microsoft makes these library files can be called by multiple programs to achieve a more perfect sharing, programmers no matter what program to write, as long as the code to add to the relevant DLL invocation declaration can use its full functionality. The most important thing is that the DLL will never let you take a vase, you want what it gives you, you don't want something it will not give you. In this way, the written program can no longer carry a lot of rubbish--absolutely will not let you take the leftover things home, otherwise fine, this is buffet.

The birth of DLL technology makes writing programs a simple thing, Windows provides us with thousands of functional interfaces enough to meet the needs of most programmers. Also, the Windows system itself is made up of thousands of DLL files that support each other and make up a powerful Windows system. If Windows uses static link technology, how big will it be? I don't think so.

Second, application interface API

Above we have a general analysis of DLL technology, in which I mentioned "interface", what is this? Because DLLs can't be stuck in a program like a static library file, how to get the program to know the code and file that implements the functionality is a problem, and Microsoft has made a standard specification for DLL technology, Let a DLL file like cheese opened a lot of small holes, each hole is marked with the name of the function stored inside, the program as long as the standard specifications to find the relevant hole to get it to the delicious, the hole is "Application Interface" (Application programming Interface), each DLL has an interface that is different, minimizing the duplication of code to the fullest extent possible. In Steven's words: The API is a toolbox, you need to remove the screwdriver, wrench, and then put them back in place. In Windows, the most basic 3 DLL files are kernel32.dll, User32.dll, and Gdi32.dll. Together, they form the basic system framework.

Third, DLL and Trojan

A DLL is a compiled code that doesn't make much difference to a normal program, except that it doesn't run independently and requires a program call. So what is the relationship between a DLL and a Trojan horse? If you learn to program and write a DLL, you will find that the DLL's code is almost the same as other programs, just the interface and startup mode, as long as the code portal changes, the DLL becomes a separate program. Of course, DLL files do not have program logic, this is not to say Dll=exe, but still can be considered as missing the main entrance of the Exe,dll band of the function functions can be considered as a program of several function modules. DLL is a realization of the Trojan Horse function code, plus some special code written DLL file, export related APIs, in other people's opinion, this is just a common DLL, but this DLL is carrying a complete Trojan function, this is the concept of the DLL Trojan. Some people may ask, since the same code can be implemented Trojan horse function, then directly to do the program can, why do you have to write a DLL? This is to hide, because the DLL runtime is directly hanging in the process of calling its program, and will not produce another process, so compared to the traditional EXE Trojan, It's hard to find.

Four, the DLL's operation

Although DLLs cannot be run on their own, Windows requires a portal function when loading DLLs, just like main in EXE, otherwise the system cannot reference DLLs. So, according to the authoring specification, Windows must find and execute a function DllMain in the DLL as a basis for loading DLLs, which are not exported as APIs, but intrinsic functions. The DllMain function keeps the DLL in memory, and some DLLs have no DllMain functions, but can still be used, because Windows cannot find the DllMain You will find a default DllMain function that does nothing from the other runtime to start the DLL so that it can be loaded, not that the DLL can discard the DllMain function.