Analysis of "pseudo-hiding" technology and implementation of processes

Process hiding? Why? You don't know? I'm dizzy! Process hiding technology is mostly used in Trojans and viruses (you can also say ?!), It is used to improve the survival rate. The implementation methods vary depending on the WIN system architecture. There are many materials for some common methods, so I will not talk about them here!

Here, "pseudo-hide" means that although the process exists in the "WINDOWS Task Manager" process list, however, it is difficult to find the corresponding program file in the hard disk.
I. Qiankun big migration
As we all know, when a program is running, the WIN system does not allow us to delete it (so someone will look for the Self-deletion technology of the Program), but I wonder if you have noticed it, in WIN2000, when a program is running, although we cannot delete it, we can move and rename the program file in the same partition. You can try it yourself! This is the method used for "Windows File Protection! Imagine if our program immediately moves and renames itself after it is running, but the original program name is displayed in the "WINDOWS Task Manager" process list, then how do you find the corresponding program file? Of course, if the program is not deformed in the memory, you can use the memory to view the software (such as WINHEX) and find the corresponding program file using the search function, but if the program is deformed in the memory
It can also be said that decryption makes the memory image different from the original program file in the hard disk, so I cannot find it now!
The implementation code is as follows (MASM ):

; Process hiding-Qiankun big migration (can only be moved within the same partition)
. 386
. Model flat, stdcall
Option casemap: none

Include windows. inc
Include kernel32.inc
Includelib kernel32.lib
Include user32.inc
Includelib user32.lib
. Data?
Selfname db MAX_PATH dup (?)
. Data
Movename db "c: mm.jpg", 0
. Code
Main:
Invoke GetModuleFileName, NULL, addr selfname, MAX_PATH;
Mov al, byte ptr selfname; get the partition
Mov byte ptr movename, al; Modify movename to move it in the same partition
Invoke MoveFile, addr selfname, addr movename; change the Mobile Location
Invoke MessageBox, NULL, offset selfname, offset movename, MB_ OK
Invoke ExitProcess, NULL
End main

This routine is successfully debugged in WIN2000. XP and WIN2003 should also be supported. If you have any conditions for testing, WIN98 and WINME cannot be used and it has nothing to do with the hard disk format!

Ii. program self-deletion (only applicable to NTFS hard disk partition formats)
The existence of file streams in the NTFS partition is no longer a secret, but we mainly use it to hide files. In a test, I found that when I ran a file stream program, the host file of this file stream program can be deleted! Further tests show that the file stream program cannot be directly deleted when the program runs. You can only delete the host file to delete the file stream program. With this feature, we can also achieve the effect similar to the previous example, and it is better than its hidden effect. The method is as follows: Determine whether the partition is in NTFS format. If yes, copy itself into a file stream and run the copied file stream, when the runtime detects that it exists in the file stream, it deletes the host file.
The implementation code is as follows (MASM ):

Process-hidden file streams (only available in NTFS partition format)
. 386
. Model flat, stdcall
Option casemap: none

Include windows. inc
Include kernel32.inc
Includelib kernel32.lib
Include user32.inc
Includelib user32.lib
. Data?
Selfname db MAX_PATH dup (?)
SzFileSystemName db 10 dup (?)
. Data

Delname db "'.': icyfox.exe", 0
"'.': Icyfox.exe" can be changed to another file name, for example, "cs.txt: cs.exe"
I use '.' here to prevent other existing files from being deleted.

SzErr db "I am not in the NTFS format partition. Exit! ", 0
SzYes db "I have been deleted in the following stream! ", 0
. Code

Main:
Invoke GetModuleFileName, NULL, addr selfname, MAX_PATH
Mov bl, byte ptr selfname + 3
Mov byte ptr selfname + 3, 0
Xor eax, eax

Obtain the format of the partition and determine whether it is in NTFS format.
Invoke GetVolumeInformation, addr selfname, eax, eax,
Eax, addr szFileSystemName, sizeof szFileSystemName
Mov byte ptr selfname + 3, bl
. If dword ptr szFileSystemName! = SFTN; NTFS
Invoke MessageBox, NULL, offset szErr, NULL, MB_ OK
Invoke ExitProcess, NULL
. Endif

Next, determine whether you are in the STREAM.
If the path contains two signs:
Lea esi, selfname
Xor edx, edx
@@:
LODSB
Or al, al
Jz @ F; 0 ends
. If al = ":"
INC edx
. Endif
. If edx = 2
Mov byte ptr [esi-1], 0
Invoke DeleteFile, addr selfname; Delete the host file
Invoke MessageBox, NULL, offset delname, offset szYes, MB_ OK
Invoke ExitProcess, NULL
. Endif
Jmp @ B

When the object is not in the file stream, copy the object to the stream and run it.
@@:
Invoke CopyFile, addr selfname, addr delname, FALSE
Invoke WinExec, addr delname, NULL
Invoke ExitProcess, NULL
End main

Additional items:
During the test, I found that when the delname (that is, the stream name) is ".: icyfox.exe "(. A space before, or other characters), will generate a file that cannot be deleted ". ", I still keep it in my drive. Please try to delete it for me! I suspect it may be related to the folder vulnerability, but it is now a file and cannot be deleted after it is added!