Yes, as you already mentioned, you need to intercept the file / folder enumeration API and filter a specific file / folder from the enumeration result in order to "hide" this file / folder. This can be done either in user mode or in kernel mode.
User Mode:. The user mode hook includes a DLL injection. There are many places where you can hook:
- Capturing IAT executables: Locate the FindXxx entry in the import table of the destination process and rewrite it with the address of the trampoline function present in the injected DLL.
- Capturing DLLs for DLLs loaded by executables: Locate the FindXxx APIs entry in the export address table of the loaded DLL (kernel32.dll in this case) and replace it with the address of the trampoline function present in the embedded DLL.
- Inline hooking: Rewrite the first few instructions of the API code in the loaded DLL using JMP for your trampoline function.
As a rule, user mode usually becomes ugly (hard to manage), since you need to embed your DLL in all running processes if you want a system-wide hook (or at least in Explorer.exe or the target application) . Many applications, such as security software, have security mechanisms to detect and deny insertion of DLLs.
A cleaner way to implement user mode is to connect APIs to NTDLL.dll (using EAT or the built-in host). All other APIs (such as FindFirstFile / FindNextFile) eventually call the equivalent NtXxx APIs (eg. NtQueryDirectoryFile) provided by NTDLL.dll. The NtXxx API is the point at which control enters kernel mode by executing INT 2E / SYSENTER.
Kernel mode: This is related to writing a driver. Again, in kernel mode there are many places where you can set the hook:
- SSDT key: in this case, set the SSDT hook for the required ZwXxx API (ZwQueryDirectoryFile) by overwriting the corresponding SSDT index with the trampoline function address in your driver.
- Built-in kernel hook: rewrite the first few NT kernel API instructions exported by the kernel (in this case, NtQueryDirectoryFile) with JMP to indicate the trampoline function in your driver.
- File System Filter Driver: This is a cleaner approach and no hooks are involved. Install the file system filter driver and intercept IOCTLs for reading / writing / listing and filter the results to hide / lock a specific file / folder.
The kernel mode hook tends to be cleaner since it is usually installed in one "centralized location." However, you must be very careful, as a small error / mishandling in the driver code may result in a BSOD.
PS: many libraries / frameworks are available to facilitate code writing. Some popular:
http://www.madshi.net/madCodeHookDescription.htm
http://easyhook.codeplex.com/
PPS: Hiding files / folders using such methods without user consent can be a dubious act and can be problematic (remember about protecting Sony DRM software ?;)). This is what rootkits do! There are many user modes and kernel mode rootkits that use the methods mentioned above to hide files / folders. There are various anti-rootkit programs available for detecting and recovering all types of interception described above. Many antivirus programs raise the flag when they detect a rootkit such as behavior (for example, API binding, hidden files, SSDT hooks, etc.)
Some resources:
http://www.codeproject.com/KB/threads/APIHooking.aspx
http://www.codeproject.com/KB/DLL/funapihook.aspx
http://www.codeproject.com/KB/system/api_spying_hack.aspx
http://www.codeproject.com/KB/system/hide-driver.aspx
http://www.uc-forum.com/forum/c-and-c/59147-writing-drivers-perform-kernel-level-ssdt-hooking.html
http://www.security.org.sg/code/apihookcheck.html
swatkat
source share