Author:MJ0011
Hardlink file traps ~
First, use oo.exe to create a file c: 1.txt ~
The file cannot be opened ~
Figure 1:
Fsutil.exe hardlink create c: 7.txt c: 1.txt
Create a hard link ~
Figure 2:
You will find that 7.txt is also exclusive ~ Cannot open, cannot open,
Figure 3:
When you get 7.txt and unlockme, go to process explorer., when you go to the super patrol to delete the location, you will find that the location cannot be found, cannot be deleted, and cannot be deleted.
Figure 4: who lock me, not found ~
The hacker got down.
Therefore, unlockme, process explorer, and super patrol force delete files are dumb and dumb.
Well, that's why niubi is 360.
Our XCB algorithm can kill this file.
Figure 5 ~, XCB big-way testing tool. After force delete, 7.txt disappears instantly ~
You can also delete this 7.txt file by adding a batch and using a batch of objects,
It is dangerous that 1.txt is also killed at the bottom layer because it is a shared file record ~, At this time, if the attacker takes c: windowssystem32configsystem to the Station Pit ~ The disk-layer dumb tool is dumb.
Therefore, it is unreliable to delete files from a disk ~
Xcbdafa will not have this question. After deleting 7.txt, 1.txtis removed, and 1.txt data is still well preserved ~
Therefore, XCB combined with HARDLINK can actually unlock files in disguise ~ For example, if you first use hivehardlinkto occupy the trap 4.txt, then the xcbdafa deletes the 4.txt file, and then hive can access it normally ~
See Figure ~ :
But in fact, the file handle is still there, and the SYSTEM process can still normally access System hive ~
See the figure below:
Therefore, the XCB method is to unlock it safely ~ Do not hurt the handle ~