Input method injection uses DLL data link library files. You can simply understand it this way: you want to modify something, then write a program, save the content and function to be modified in a DLL, and then inject it into the process module of the input method, so that as long as the input method runs, your function will always be running, thus achieving the purpose of modifying something. As for system-driven injection, it should be that the program associates its add-in with the driven sys file. Drivers have higher authority. Many drivers work in the ring0 layer, and the drivers are loaded earlier than the security software in the operating system because they work in the ring3 layer. The so-called DLL injection is to put a DLL into the address space of a process and make it a part of that process. To realize DLL injection, you need to open the target process first. Edit this example: hremoteprocess = openprocess (process _ create _ thread |//Allow remote creation of thread PROCESS_VM_OPERATION | // Allow remote VM to operate PROCESS_VM_WRITE,//Allow remote VM to write FALSE, DwRemoteProcessId) Because we need to write into the memory address space of the remote process and establish the remote thread later, we need to apply for sufficient permissions (PROCESS _ CREATE _ THREAD, VM_OPERATION, VM_WRITE). If the process can't be opened, you can't think about future operations. After the process is opened, the remote thread can be established, but don't worry, what is the thread function of this remote thread first? Our goal is to inject a DLL. We know that we can use LoadLibrary to load a DLL into the address space of this process. So it is natural to think that if you can call LoadLibrary in the target process, you can load the DLL into the address space of the target process. Yes! That's it. The remote thread is only used once here. The thread function of the established remote thread is LoadLibrary, and the parameter is the file name of the DLL to be injected. You need to think for yourself here. Have you noticed that the thread function ThreadProc is very similar to the LoadLibrary function, with the same return value and number of parameters? There is another question, where is the address of the LoadLibrary function? Maybe you will say, this is simple, and GetProcAddress can handle it. So the code came out. char * pszLibFileRemote = " my . dll "； PTHREAD _ START _ ROUTINE pfnStartAddr =(PTHREAD _ START _ ROUTINE)GetProcAddress(GetModuleHandle(" kernel 32 ")，" loadlibrary a ")； create remote thread(hRemoteProcess，NULL，0，pfnStartAddr，pszLibFileRemote，0，NULL)； But no! Don't forget, this is a remote thread, not in your process, but pszLibFileRemote points to the data in your process. When it reaches the target process, this pointer doesn't know where it went. Similarly, the code of pfnStartAddr doesn't know what it is when it reaches the target process, and it doesn't know whether it is the LoadLibraryA you want. However, problems can always be solved. Windows has some powerful API functions that can allocate memory in the target process and copy the data in your process to the target process. So the problem of pszLibFileRemote can be solved. Char * pszlibfilename = "my.dll//, note that this must be a complete path file name, unless it is in the system directory; The reason is that everyone thinks about it. //Memory space required for calculating the path name of DLL IntCB = (1+lstrLena (pszlibfilename)) * sizeof (char); //Use the VirtualAllocEx function to allocate the DLL file name buffer pszlibfileremote = (char *) VirtualAllocex (h remote process, null, CB, mem _ commit, page _ readwrite) in the memory address space of the remote process; //Use the WriteProcessMemory function to copy the path name of the DLL to the memory space of the remote process ireturncode = writeprocessmemory (hremoteprocess, pszlibfileremote, (pvoid) pszlibfilename, CB, null); Ok, now the target process also knows about pszLibFileRemote, but pfnStartAddr seems to be difficult to handle. How can I know the address of LoadLibraryA in the target process? In fact, Windows has solved this problem for us. The function LoadLibraryA is in Kernel32.dll's core DLL, which is very special. No matter which process, Windows always loads to the same address. So the address of LoadLibraryA in your process is the same as that of LoadLibraryA in the target process (in fact, all functions in this DLL are the same). At this point, DLL injection is over.