logo

Watch & Learn

Debugwar Blog

Step in or Step over, this is a problem ...

Discussing Registry and File System Filter Drivers through the Purple Fox Trojan

2020-12-29 @ UTC+0
en-USzh-CN

Preface

The “Dive into kernel” series, literally translated as “Deep into the kernel” series, but I prefer its other name: “Diving series”, after all, it fully shows the author’s years of diving skills;) Getting off the point, let’s get back to the point. The original intention of writing this series is to see that the network is full of analysis reports of various hot events (of course, there is nothing wrong with this). However, as a security researcher, there are not many in-depth analysis articles on system mechanisms in recent years. So the author plans to do a reverse operation and write some in-depth analysis reports at the kernel level. This series does not pursue the analysis of the hottest and latest events, on the contrary, the samples that may be started are old samples that appeared many years ago. This article pursues the deeper mechanism of the system through the means used by these samples. The positioning of this series is hardcore science popularization, suitable for readers with a certain foundation who need to further improve their technical capabilities. As for how many articles this series can write, it depends on whether you audience masters buy it or not, so please like, collect and forward more, I believe your support will make this series go further Orz.

Purple Fox Trojan Family

The family can be traced back to 2018 at the earliest, and we have also found the shadow of this family Trojan on customer machines many times during the recent emergency handling process. There are quite a few analysis reports on this family on the Internet, so this article only briefly explains the key points, and the details can refer to the analysis report from Tencent Security Team cited at the end of this article.

First of all, the means used by the Trojan to persist, from the behavior monitoring tool, we found its path as follows:

Installation package —> Write to the PendingFileRenameOperations registry entry —> Replace system service —> Release Trojan components —> Hide key services and files

Let’s take a look at the content of the PendingFileRenameOperations registry key value written:



The format of this registry key value is:

Source file 1
Destination file 1
Source file 2
Destination file 2
…

If the destination file is empty (0x00), it means to delete the source file. Therefore, the virus actually achieves the startup purpose by replacing the system file sens.dll, and this DLL corresponds to the service:



Due to the Windows file system regulations: files in use cannot be deleted, and the dll files corresponding to the system service must be in use, so the virus uses such a “troublesome” method to delete system files. So the question is, why can this key value be used to delete files?

Take a deep breath, we start the first dive.

Windows boot process

First of all, start with a picture:


You can see that the first process in R3 with a physical file is smss.exe, which means that the service has not started at this moment, so there must be no situation where the service DLL file mentioned above is occupied and cannot be deleted.

It is also because most of the system processes have not started at this moment, the system has a chance to delete any files. During the initialization phase of smss.exe, through the PendingFileRenameOperations key value, the system can know which files to operate on. Through the search of WRK, we found the following code related to this key value:


By querying the function prototype of RtlQueryRegistryValues, we know that this function will call the callback function in SmpRegistryConfigurationTable: SmpConfigureFileRenames. When calling, it will pass SmpFileRenameList as the last parameter to the SmpConfigureFileRenames callback function. By reading the source code of SmpConfigureFileRenames, we found that this function only initializes the SmpFileRenameList linked list based on the value in PendingFileRenameOperations. Therefore, we still need to see who used the SmpFileRenameList linked list, and through the search of cross-references, we got the following call path:


This SmpProcessFileRenames function is the function that performs the delete function:



You can see that when it is judged to be a delete action, you can delete the file by calling NtSetInformationFile and setting SetInfoClass to FileDispositionInformation.

And through the analysis of the call path of the SmpProcessFileRenames function in the above figure, we know that the SmpInit function in the smss.c source file was executed very early in the main function. At this time, most of the windows subsystem has not started working, so naturally there is no problem that the file is occupied and cannot be deleted.

By the way, the MoveFileEx function supports a MOVEFILE_DELAY_UNTIL_REBOOT parameter. This parameter also deletes files during the restart process through the registry entry mentioned in this section:


Registry callback monitoring

After understanding how the virus uses PendingFileRenameOperations to obtain persistence capabilities, let’s take a look at a few points that the virus buried in order to fight against killing.

Through the PCHunter tool to view the “Kernel” tab “System Callback” tab, found a red CmpCallback callback item.



Switch to the “FileSystem” tab, in the “Minifilters”, there are two pre and post hooks for DIRECTORY_CONTROL.


Experienced friends may be able to guess what it is when they see these two hooks. For those who are not familiar with it, this is the moment to witness the miracle——remove these three hooks, we will be “surprised” to find that there is an additional service in the "Service" tab, and an additional file in the system32 directory:



Before these two hooks were removed, the service and files could not be seen in PCHunter, so we currently have sufficient reason to believe that the function of these three hooks is to hide the service items and corresponding files.

But what happened under the hood? It seems that it is time for the second dive.

First of all, we need to understand what CmpCallback is. Use dual-machine kernel debugging, set a breakpoint at the CmpCallback function address (0x95DF64F0) in the above figure, resume running and immediately interrupt, the stack traceback at this time is as follows (because the callback was removed in the above text, restarted once, the callback address changed to 0x961D64F0):


Actually seeing these Cm-starting functions, the meaning of CmpCallback in PCHunter is already very clear. But we still have to take care of friends who are not familiar with the kernel, after all, the positioning of this article is hardcore science popularization;)

From the stack traceback in the above figure, we can know that the most recent system call is CmpCallCallBacks, which is similar to CmpCallback in PCHunter, but it is still “unknown” what it is used for. At this time, we open IDA and look at the disassembly function and cross-reference of this function.

First take a look at the cross-reference:


It seems that all registry operations will eventually call this function, is CmpCallCallBacks used for registry monitoring? All the clues currently point to this answer, but we don’t have a smoking gun evidence yet.

Next, let’s take a look at the disassembly code of CmpCallCallBacks, use the F5 magic of IDA: (This code loads Microsoft’s public symbols, and the key data structure has been adjusted)



The return point after the WinDBG interrupt in the above text is the v8->callback line in line 55 of the above figure. Looking at the above code, it mainly traverses the callback function in the v8 double-linked list and calls it in turn (registry callback suspicion++). v8 comes from the CallbackListHead global variable. If we can find who is adding data to this global linked list, maybe we can dig out the function of CmpCallCallBacks. First, let’s see which functions are using this global variable:



Anyway, for me, I will choose CmpInsertCallbackInListByAltitude, look at the call path of this function, and see who is calling him:


I saw CmRegisterCallbackEx, and then the upper layer of ETW. We dug a big pit for ETW, and we will talk about it later. Here we focus on CmRegisterCallbackEx, the following is MSDN’s explanation


Okay, the case is solved, our guess is correct, this thing is indeed used to monitor registry operations.

After digging out the key data structure (CallbackListHead), let’s take a look at what this structure looks like:

  1. typedef struct _CM_CALLBACK_LIST_INFO {  
  2.     LIST_ENTRY list;  
  3. #ifdef _WIN64
  4.     UHALF_PTR counter;
  5.     UHALF_PTR unknown;
  6. #else
  7.     ULONG_PTR counter;
  8.     PULONG_PTR unknown
  9. #endif
  10.     LARGE_INTEGER cookie;  
  11.     PVOID context;  
  12.     PEX_CALLBACK_FUNCTION callback;  
  13.     UNICODE_STRING attidude;  
  14. } CM_CALLBACK_LIST_INFO, *PCM_CALLBACK_LIST_INFO;  

With the key data structure in hand, you can naturally traverse all the registry callback functions in this linked list. Write a program to verify whether the above data structure is problematic. For teaching purposes, the address of CallbackListHead is hardcoded. This address is obtained from WinDBG and is different every time you restart:


  1. #include   
  2.    
  3. typedef struct _CM_CALLBACK_LIST_INFO
  4.  {  
  5.     LIST_ENTRY list;  
  6. #ifdef _WIN64
  7.     UHALF_PTR counter;
  8.     UHALF_PTR unknown;
  9. #else
  10.     ULONG_PTR counter;
  11.     PULONG_PTR unknown;
  12. #endif
  13.     LARGE_INTEGER cookie;  
  14.     ULONG_PTR context;  
  15.     ULONG_PTR callback;  
  16.     PUNICODE_STRING attidude;  
  17. } CM_CALLBACK_LIST_INFO, *PCM_CALLBACK_LIST_INFO;  
  18.    
  19. NTSTATUS DriverEntry( IN PDRIVER_OBJECT DriverObject, IN PUNICODE_STRING RegistryPath  ) {  
  20.     LIST_ENTRY *CallbackListHead = 0x83d5f570;  
  21.     LIST_ENTRY *i = CallbackListHead;  
  22.     DbgPrint("[IterateSys] start\n");  
  23.     DbgPrint("[IterateSys] i: %x\n", i);  
  24.     do {  
  25.         if (i) {  
  26.             DbgPrint("[IterateSys] address: %x\n", ((PCM_CALLBACK_LIST_INFO)i)->callback);  
  27.             i = i->Flink;  
  28.         } else DbgPrint("[IterateSys] i is NULL\n");   
  29.     } while(i->Flink != CallbackListHead->Blink);  
  30.     DbgPrint("[IterateSys] end\n");  
  31.     return STATUS_SUCCESS;  
  32. }  

Then cross-verify with the data in PCHunter, it is known that the address obtained above is correct:


Windows function call path and service hiding

The above mentioned that the CmpCallCallBacks function can monitor all registry operations. So how does the virus use this monitoring ability to achieve service hiding? To explain this question, we need to first figure out: how to get the current system service list? it is usually like the following program:


  1. #include   
  2. #include   
  3.    
  4. int main() {  
  5.     HKEY hKey;  
  6.     LSTATUS status = RegOpenKeyEx(  
  7.         HKEY_LOCAL_MACHINE,  
  8.         "SYSTEM\\CurrentControlSet\\Services",  
  9.         0,  
  10.         KEY_ALL_ACCESS,  
  11.         &hKey  
  12.     );  
  13.     printf("OpenKey status:%x\n", status);  
  14.     if(status == ERROR_SUCCESS) {  
  15.         printf("success\n");  
  16.         DWORD numSubKey = 0;  
  17.         RegQueryInfoKey(  
  18.             hKey,  
  19.             NULL, NULL, NULL,  
  20.             &numSubKey,  
  21.             NULL,NULL,NULL,NULL,NULL,NULL,NULL  
  22.         );  
  23.         printf("NumSubKey: %d\n", numSubKey);  
  24.         getch();  
  25.         for(int i = 0; i < numSubKey; ++i) {  
  26.             TCHAR subKey[MAX_PATH] = {0};  
  27.             DWORD sizeSubKey = MAX_PATH;  
  28.             status = RegEnumKey(  
  29.                 hKey, i,  
  30.                 subKey, &sizeSubKey  
  31.             );  
  32.             printf("Index:%d \t Status: %x \t SubKey: %s\n", i, status, subKey);  
  33.         }  
  34.     }  
  35. }  

You can see that it is obtained by using the RegEnumKey function to traverse the HKLM\SYSTEM\CurrentControlSet\Services registry key value to get all the services of the current system. We look at the call stack traceback of this behavior under R0:



You can see that the call path from R3 to R0 is like the following figure:


As can be seen from the above figure, R3’s RegEnumKey will call the kernel’s NtEnumerateKey, and NtEnumerateKey will notify the CmpCallCallBacks function of the query result. If we want to hide services, we only need to modify the return data of NtEnumerateKey after being notified, right? In fact, the PurpleFox family uses this to hide their service items. First, the virus hooks the RegNtPostEnumerateKey action through the CmCallCallBacks function:



In the Hook function, by re-calling the ZwEnumerateKey function to skip the current query index, and then modify the return value. This operation makes some items is skipped in return data, thereby achieving the purpose of hiding these services:


If we search for EnumerateKey in ntoskrnl.exe, we will find four functions:


After combing, we find that the call relationship of these four functions is as follows:

NtEnumearteKey —> CmEnumerateKey
VfZwEnumerateKey ---> ZwEnumerateKey

But the function body of ZwEnumerateKey is a bit “strange”:


This is actually the well-known SSDT table call, which involves the KiServiceTable symbol. The 74h in the above figure is the service number of ZwEnumerateKey call in the SSDT table.

The position of the SSDT table in my IDA is as follows:


Take a look at the 74h call, first calculate the address:

0x45c5f4 + 74h * 4 = 0x45c7c4

Turn to this address in IDA to see which function it is:


So we can improve the call chain of the above functions:

VfZwEnumerateKey ---> ZwEnumerateKey -(SSDT)-> NtEnumearteKey ---> CmEnumerateKey

Interlude

In the process of reverse engineering, by searching for the Tag used by the virus driver to allocate memory function ExAllocatePoolWithTag on github, I found the open source code corresponding to this driver:


By comparing the disassembled code in IDA and the source code on github, it is found that the logic is consistent, and it is further determined that the underlying code used by PurpleFox is the code of this project on github (I don’t know if the virus author is in the star list of this project).

File hiding

After finding the source code, the steps of file hiding are clear: register the minifilter filter, filter the results of traversing the file, if it is found to be a file to be hidden, then return the information of the next file. The information of the virus registered filter is as follows, the left side of the following figure is the stack call when the filter is hit, it can be seen that


The core C code corresponding to the logic of hiding files is as follows:

  1. NTSTATUS CleanFileFullDirectoryInformation(PFILE_FULL_DIR_INFORMATION info, PFLT_FILE_NAME_INFORMATION fltName)  
  2. {  
  3.     PFILE_FULL_DIR_INFORMATION nextInfo, prevInfo = NULL;  
  4.     UNICODE_STRING fileName;  
  5.     UINT32 offset, moveLength;  
  6.     BOOLEAN matched, search;  
  7.     NTSTATUS status = STATUS_SUCCESS;  
  8.    
  9.     offset = 0;  
  10.     search = TRUE;  
  11.    
  12.     do  
  13.     {  
  14.         fileName.Buffer = info->FileName;  
  15.         fileName.Length = (USHORT)info->FileNameLength;  
  16.         fileName.MaximumLength = (USHORT)info->FileNameLength;  
  17.    
  18.         if (info->FileAttributes & FILE_ATTRIBUTE_DIRECTORY)  
  19.             matched = CheckExcludeListDirFile(g_excludeDirectoryContext, &fltName->Name, &fileName);  
  20.         else  
  21.             matched = CheckExcludeListDirFile(g_excludeFileContext, &fltName->Name, &fileName);  
  22.    
  23.         if (matched)  
  24.         {  
  25.             BOOLEAN retn = FALSE;  
  26.    
  27.             if (prevInfo != NULL)  
  28.             {  
  29.                 if (info->NextEntryOffset != 0)  
  30.                 {  
  31.                     prevInfo->NextEntryOffset += info->NextEntryOffset;  
  32.                     offset = info->NextEntryOffset;  
  33.                 }  
  34.                 else  
  35.                 {  
  36.                     prevInfo->NextEntryOffset = 0;  
  37.                     status = STATUS_SUCCESS;  
  38.                     retn = TRUE;  
  39.                 }  
  40.    
  41.                 RtlFillMemory(info, sizeof(FILE_FULL_DIR_INFORMATION), 0);  
  42.             }  
  43.             else  
  44.             {  
  45.                 if (info->NextEntryOffset != 0)  
  46.                 {  
  47.                     nextInfo = (PFILE_FULL_DIR_INFORMATION)((PUCHAR)info + info->NextEntryOffset);  
  48.                     moveLength = 0;  
  49.                     while (nextInfo->NextEntryOffset != 0)  
  50.                     {  
  51.                         moveLength += nextInfo->NextEntryOffset;  
  52.                         nextInfo = (PFILE_FULL_DIR_INFORMATION)((PUCHAR)nextInfo + nextInfo->NextEntryOffset);  
  53.                     }  
  54.    
  55.                     moveLength += FIELD_OFFSET(FILE_FULL_DIR_INFORMATION, FileName) + nextInfo->FileNameLength;  
  56.                     RtlMoveMemory(info, (PUCHAR)info + info->NextEntryOffset, moveLength);//continue  
  57.                 }  
  58.                 else  
  59.                 {  
  60.                     status = STATUS_NO_MORE_ENTRIES;  
  61.                     retn = TRUE;  
  62.                 }  
  63.             }  
  64.    
  65.             LogTrace("Removed from query: %wZ\\%wZ", &fltName->Name, &fileName);  
  66.    
  67.             if (retn)  
  68.                 return status;  
  69.    
  70.             info = (PFILE_FULL_DIR_INFORMATION)((PCHAR)info + offset);  
  71.             continue;  
  72.         }  
  73.    
  74.         offset = info->NextEntryOffset;  
  75.         prevInfo = info;  
  76.         info = (PFILE_FULL_DIR_INFORMATION)((PCHAR)info + offset);  
  77.    
  78.         if (offset == 0)  
  79.             search = FALSE;  
  80.     } while (search);  
  81.    
  82.     return STATUS_SUCCESS;  
  83. }  

We can see in PCHunter that the address of the filter set by the virus is: 0x88F8A3D8, and it also prompts that the module does not exist. This address is actually the address of a structure in the second parameter of the callback function registered by the virus:


From the above figure, we know that this address is the _FLT_FILTER structure. In fact, based on this structure, we can get the module name. This is an improvement point of PCHunter:


Knowing this address, we can call the function to cancel this callback to remove the file protection of the virus:

  1. VOID FLTAPI FltUnregisterFilter(  
  2.   PFLT_FILTER Filter  
  3. );  

Traverse the filter

In fact, Microsoft’s minifilter itself provides a series of functions that allow developers to have the ability to traverse various filters. These functions are exported by flgmgr.sys, which is very suitable for our manual traversal research objects. Many important data structures in the Windows kernel are stored in the form of linked lists in global variables. When needed, you only need to find the beginning of the linked list from the global variables, and you can traverse the entire list to find the objects you need to use. Take a look at the functions exported by fltmgr.sys, combined with the _FLT_FILTER structure displayed by PCHunter in the above text, you can “guess” that FltEnumerateFilters is a more suitable entry point:


This function obtains a LIST_ENTRY structure from the global variable g_listFltpFrame_4, and then traverses the entire _FLTP_FRMAE frame through the Flink pointer of this structure, and finally puts the completed pointer into the passed in FilterList array. But there is a pit here, let’s first take a look at where the global variable g_listFltpFrame_4 is assigned:


Through the study of the context of the assignment, it is known that the type of v4 is _FLTP_FRAME *, and g_listFltpFrame_4 is assigned to the address! address!! address!!! (important things say three times) of the Links member domain of this data structure. Next, let’s take a look at what this data structure looks like through windbg:

kd> dt -b fltmgr!_FLTP_FRAME
   +0x000 Type : _FLT_TYPE
   +0x004 Links : _LIST_ENTRY
      +0x000 Flink : Ptr32 
      +0x004 Blink : Ptr32 
   +0x00c FrameID : Uint4B
   +0x010 AltitudeIntervalLow : _UNICODE_STRING
   +0x018 AltitudeIntervalHigh : _UNICODE_STRING
   +0x020 LargeIrpCtrlStackSize : UChar
   +0x021 SmallIrpCtrlStackSize : UChar
   +0x024 RegisteredFilters : _FLT_RESOURCE_LIST_HEAD
      +0x000 rLock : _ERESOURCE
      +0x038 rList : _LIST_ENTRY
    …………省略…………

The Flink member is at the offset +0x4 position, so g_listFltpFrame_4 needs to subtract 4 to be the address of the first _FLTP_FRAME structure, and according to the context of FltEnumerateFilters, we can reasonably speculate that the double-linked list at _FLTP_FRAME+0x4 stores the _FLT_FILTER structure. This trick has a lot of applications in the kernel, such as the code for getting _FLT_INSTANCE from _FLT_FILTER in the following figure:


You can see that the pseudo C code decompiled by IDA’s Hexray is actually problematic. Combined with the assembly code, you can see that the real operation is actually to subtract the pointer size by 0x34. So what is the position of 0x34? Let’s talk about it with the data results:

kd> dt -b fltmgr!_FLT_FILTER
   +0x000 Base : _FLT_OBJECT
      +0x000 Flags : 
      +0x004 PointerCount : Uint4B
      +0x008 RundownRef : _EX_RUNDOWN_REF
      +0x00c PrimaryLink : _LIST_ENTRY
         +0x000 Flink : Ptr32 
         +0x004 Blink : Ptr32 
   +0x014 Frame : Ptr32 
   +0x018 Name : _UNICODE_STRING
   +0x020 DefaultAltitude : _UNICODE_STRING
   +0x028 Flags : 
   +0x02c DriverObject : Ptr32 
   +0x030 InstanceList : _FLT_RESOURCE_LIST_HEAD
      +0x000 rLock : _ERESOURCE
      +0x038 rList : _LIST_ENTRY
         +0x000 Flink : Ptr32 
         +0x004 Blink : Ptr32 
      +0x040 rCount : Uint4B


First, take out an address from _FLT_FILTER->InstanceList->rList->Flink, and then subtract this address by 0x34. What is InstanceList? Look at the name, guess it is a _FLT_INSTANCE *, and then take a look at the _FLT_INSTACNE structure:

kd> dt -b fltmgr!_FLT_INSTANCE
   +0x000 Base : _FLT_OBJECT
   +0x014 OperationRundownRef : Ptr32 
   +0x018 Volume : Ptr32 
   +0x01c Filter : Ptr32 
   +0x020 Flags : 
   +0x024 Altitude : _UNICODE_STRING
   +0x02c Name : _UNICODE_STRING
   +0x034 FilterLink : _LIST_ENTRY
      +0x000 Flink : Ptr32 
      +0x004 Blink : Ptr32 
   …………省略…………

After subtracting 0x34, it is exactly the first address of the _FLT_INSTANCE object. After research, we can draw the relationship between _FLTP_FRAME, _FLT_FILTER, and _FLT_INSTANCE structures as shown in the following figure (note that this structure is different on different versions of the system):


Here, the reverse process from _FLTP_FRAME->RegisteredFilters->rList->Flink to _FLT_FILTER->PrimaryLink->Flink is omitted. You can go and see for yourself. Here, you only need to remember that you need to subtract the offset of 0xC. The negative offset in the above figure is too uncomfortable to look at. Introduce a small IDA trick to make the pseudo code after Hexray decompilation look better. In the figure of the negative array index above, we already know that the i variable is _FLT_INSTANCE type. Right-click on this variable, select Convert to struct *, and then find the _FLT_INSTANCE structure. Fill in the offset address we reversed in the Pointer shift value below, as shown in the following figure:



After regularization, the pseudo C code of the same function is much easier to read:


It can be seen that IDA uses ADJ to identify data structures that have been offset, and i itself is marked as the following type:

_LIST_ENTRY *__shifted(_FLT_INSTANCE, 0x34)

In fact, it is the CONTANING_RECORD macro. Everyone can take a look at the specific definition of this macro, and there are many tricks to use. All the way to this, I must write some code to reward myself ;) The following is the code for traversing various filters of minifilter. Because there are too many data structures involved, we have converted some unused members into pointer arrays of the same size (in fact, you can also refer to the corresponding header files in ReactOS):


  1. #include   
  2.    
  3. union u1  
  4. {  
  5.   NTSTATUS (__stdcall *PreOperation)(int *, int *, void **);  
  6.   int (__stdcall *GenerateFileName)(int *, int *, int *, unsigned int, unsigned __int8 *, int *);  
  7.   int (__stdcall *NormalizeNameComponent)    \
  8.            (int *, const UNICODE_STRING *, unsigned __int16, const UNICODE_STRING *, int *, unsigned int, unsigned int, void **);  
  9.   int (__stdcall *NormalizeNameComponentEx)  \
  10.            (int *, int *, const UNICODE_STRING *, unsigned __int16, const UNICODE_STRING *, int *, unsigned int, unsigned int, void **);  
  11. };  
  12.    
  13. union u2  
  14. {  
  15.   NTSTATUS (__stdcall *PostOperation)(int *, int *, void *, unsigned int);  
  16.   void (__stdcall *NormalizeContextCleanup)(void **);  
  17. };  
  18.    
  19.    
  20. struct _FLT_RESOURCE_LIST_HEAD  
  21. {  
  22.   unsigned int *rLock[14];  
  23.   LIST_ENTRY rList;  
  24.   unsigned int rCount;  
  25. };  
  26.    
  27. struct _CALLBACK_NODE  
  28. {  
  29.   LIST_ENTRY CallbackLinks;  
  30.   struct _FLT_INSTANCE *Instance;  
  31.   union u1  *_u1;  
  32.   union u2 *_u2;  
  33.   int *Flags;  
  34. };  
  35.    
  36. struct _FLT_INSTANCE  
  37. {  
  38.   unsigned int *Base[0x5];  
  39.   int *OperationRundownRef;  
  40.   int *Volume;  
  41.   struct _FLT_FILTER *Filter;  
  42.   int *Flags;  
  43.   UNICODE_STRING Altitude;  
  44.   UNICODE_STRING Name;  
  45.   LIST_ENTRY FilterLink;  
  46.   int *ContextLock;  
  47.   int *Context;  
  48.   int *TransactionContexts;  
  49.   int *TrackCompletionNodes;  
  50.   struct _CALLBACK_NODE *CallbackNodes[50];  
  51. };  
  52.    
  53. struct _FLTP_FRAME  
  54. {  
  55.   unsigned int* usless1;  
  56.   LIST_ENTRY Links;  
  57.   unsigned int FrameID;  
  58.   UNICODE_STRING AltitudeIntervalLow;  
  59.   UNICODE_STRING AltitudeIntervalHigh;  
  60.   unsigned __int8 LargeIrpCtrlStackSize;  
  61.   unsigned __int8 SmallIrpCtrlStackSize;  
  62.   struct _FLT_RESOURCE_LIST_HEAD RegisteredFilters;  
  63.   struct _FLT_RESOURCE_LIST_HEAD AttachedVolumes;  
  64.   LIST_ENTRY MountingVolumes;  
  65.   unsigned int *AttachedFileSystems[11];  
  66.   unsigned int *ZombiedFltObjectContexts[11];  
  67.   unsigned int *KtmResourceManagerHandle;  
  68.   struct _KRESOURCEMANAGER *KtmResourceManager;  
  69.   unsigned int *FilterUnloadLock[14];  
  70.   FAST_MUTEX DeviceObjectAttachLock;  
  71.   unsigned int *Prcb;  
  72.   unsigned int *PrcbPoolToFree;  
  73.   unsigned int *LookasidePoolToFree;  
  74.   unsigned int *IrpCtrlStackProfiler[32];  
  75.   __declspec(align(16)) unsigned int *SmallIrpCtrlLookasideList[20];  
  76.   __declspec(align(64)) unsigned int *LargeIrpCtrlLookasideList[20];  
  77.   unsigned int *BackpocketIrpCtrls[21];  
  78. };  
  79.    
  80. typedef struct _FLT_FILTER  
  81. {  
  82.   unsigned int *Base[0x5];  
  83.   struct _FLTP_FRAME *Frame;  
  84.   UNICODE_STRING Name;  
  85.   UNICODE_STRING DefaultAltitude;  
  86.   unsigned int *Flags;  
  87.   DRIVER_OBJECT *DriverObject;  
  88.   struct _FLT_RESOURCE_LIST_HEAD InstanceList;  
  89.   unsigned int *VerifierExtension;  
  90.   LIST_ENTRY VerifiedFiltersLink;  
  91.   int (__stdcall *FilterUnload)(unsigned int);  
  92.   int (__stdcall *InstanceSetup)(const unsigned int *, unsigned int, unsigned int, unsigned int *);  
  93.   int (__stdcall *InstanceQueryTeardown)(const unsigned int *, unsigned int);  
  94.   unsigned int (__stdcall *InstanceTeardownStart)(const unsigned int *, unsigned int);  
  95.   unsigned int (__stdcall *InstanceTeardownComplete)(const unsigned int *, unsigned int);  
  96.   unsigned int *SupportedContextsListHead;  
  97.   unsigned int *SupportedContexts[6];  
  98.   NTSTATUS (__stdcall *PreVolumeMount)(unsigned int *, const unsigned int *, unsigned int **);  
  99.   NTSTATUS (__stdcall *PostVolumeMount)(unsigned int *, const unsigned int *, unsigned int *, unsigned int);  
  100.   int (__stdcall *GenerateFileName)(unsigned int *, unsigned int *, unsigned int *, unsigned int, unsigned __int8 *, unsigned int *);  
  101.   int (__stdcall *NormalizeNameComponent)   \
  102.      (unsigned int *, const UNICODE_STRING *, unsigned __int16, const UNICODE_STRING *, unsigned int *, unsigned int, unsigned int, unsigned int **);  
  103.   int (__stdcall *NormalizeNameComponentEx) \
  104.      (unsigned int *, unsigned int *, UNICODE_STRING *, unsigned __int16, UNICODE_STRING *, unsigned int *, unsigned int, unsigned int, unsigned int **);  
  105.   unsigned int (__stdcall *NormalizeContextCleanup)(unsigned int **);  
  106.   int (__stdcall *KtmNotification)(const unsigned int *, unsigned int *, unsigned int);  
  107.   unsigned int *Operations;  
  108.   unsigned int (__stdcall *OldDriverUnload)(DRIVER_OBJECT *);  
  109.   unsigned int *ActiveOpens[11];  
  110.   unsigned int *ConnectionList[11];  
  111.   unsigned int *PortList[11];  
  112.   unsigned int *PortLock;  
  113. }*PFLT_FILTER, FLT_FILTER;  
  114.    
  115. NTSTATUS DriverEntry( IN PDRIVER_OBJECT DriverObject, IN PUNICODE_STRING RegistryPath ) {  
  116.     unsigned int *g_filterFrame = (unsigned int *)0x8db819f8;  
  117.     struct _FLTP_FRAME *frame = (struct _FLTP_FRAME*)((char *)(*g_filterFrame) - 0x4);  
  118.     for(LIST_ENTRY *i = frame->RegisteredFilters.rList.Flink; i->Flink != frame->RegisteredFilters.rList.Flink; i = i->Flink) {  
  119.         struct _FLT_FILTER *filter = (struct _FLT_FILTER*)((char*)(i) - 0xC);  
  120.         for(LIST_ENTRY *j = filter->InstanceList.rList.Flink; j->Flink != filter->InstanceList.rList.Flink; j = j->Flink) {  
  121.             struct _FLT_INSTANCE *instance = (struct _FLT_INSTANCE *)((char*)j - 0x34);  
  122.             for(int index = 0; index < 50; index += 1) {  
  123.                 if(instance->CallbackNodes != 0 && instance->CallbackNodes[index] != 0) {  
  124.                     DbgPrint("[IterateFilters] filter:%x\tname:%wZ\tinstance:%x\tindex:%d\tpre_cb:%x\tpost_cb:%x\n",  
  125.                         filter, &filter->Name, instance, index,  
  126.                         instance->CallbackNodes[index]->_u1, instance->CallbackNodes[index]->_u2);  
  127.                 }  
  128.             }  
  129.         }  
  130.     }  
  131.     return STATUS_SUCCESS;  
  132. }  
Finally, compare with the data in PCHunter, and find that they are consistent:


OK, finish work!

Postscript

It seems that there is nothing to say, just to ask the audience for a strong postscript…;) 
Catalog
Purple Fox Trojan Family
Windows boot process
Registry callback monitoring
Windows function call path and service hiding
Interlude
File hiding
Traverse the filter
Postscript
Reference

CopyRight (c) 2020 - 2025 Debugwar.com

Designed by Hacksign