Monitoring method and device, electronic equipment and computer readable storage medium
By monitoring the loading of .NET framework modules and dynamic calls to interface functions, combined with the call numbers and addresses of underlying functions, the problem of not being able to monitor dynamic calls after deserialization into .NET objects in existing technologies has been solved, thus achieving effective identification and monitoring of malicious scripts.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- QI AN XIN TECHNOLOGY GROUP INC
- Filing Date
- 2022-07-26
- Publication Date
- 2026-05-29
AI Technical Summary
Existing monitoring technologies cannot effectively monitor the dynamic calls after deserialization into .NET objects, resulting in poor identification of malicious scripts.
By monitoring whether .NET Framework modules are loaded, it can determine whether dynamic call interface functions are invoked, and compare the saved deserialization results with the objects called by the dynamic call interface functions. The monitoring of deserialized dynamic call behavior is achieved by using the call number and function address of the underlying function.
It enables effective monitoring of the dynamic invocation behavior after deserialization into .NET objects, improving the accuracy and efficiency of malicious script identification.
Smart Images
Figure CN115186264B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of information security, and more specifically, to a monitoring method, apparatus, electronic device, and computer-readable storage medium. Background Technology
[0002] Currently, some malicious scripts deserialize specially encoded strings into raw .NET objects with malicious behavior using deserialization interface functions (also known as deserialization APIs). Then, they use dynamic call interface functions (also known as dynamic call APIs) to invoke the raw .NET objects to perform malicious actions.
[0003] Therefore, in order to effectively identify such malicious scripts, it is necessary to first monitor whether dynamic calls after .NET deserialization occur within the system. Once dynamic calls after .NET deserialization are detected, relevant malicious script identification technologies can be used to determine whether the script implementing the dynamic calls after .NET deserialization is a malicious script.
[0004] However, existing monitoring technologies cannot monitor the behavior of dynamic calls after deserialization into .NET objects, resulting in poor identification of such malicious scripts. Summary of the Invention
[0005] The purpose of this application is to provide a monitoring method, device, electronic device, and computer-readable storage medium to solve the problem that existing monitoring technologies cannot monitor the behavior of dynamic calls after deserialization into .NET objects.
[0006] This application provides a monitoring method, including: monitoring whether a .NET framework module is loaded; after the .NET framework module is loaded, determining whether a dynamic call interface function is called; if the dynamic call interface function is called, comparing the saved deserialization result with the object called by the dynamic call interface function; if the deserialization result and the object called by the dynamic call interface function are the same, determining that a dynamic call after .NET deserialization has occurred.
[0007] It should be understood that dynamic invocation after .NET deserialization requires loading the .NET Framework module. Therefore, in the above implementation process, the possibility of dynamic invocation after .NET deserialization is first determined by monitoring whether the .NET Framework module is loaded. If the .NET Framework module is loaded, it is determined whether the dynamic invocation interface function is called. Once the dynamic invocation interface function is called, it is determined whether the saved deserialization result and the object called by the dynamic invocation interface function are the same, thus determining whether a dynamic invocation after .NET deserialization has occurred. The method of this application realizes the monitoring of the dynamic invocation behavior after deserialization into a .NET object, making up for the shortcomings of the prior art.
[0008] Furthermore, after the .NET framework module is loaded, the method further includes: determining whether the deserialization interface function is called; if the deserialization interface function is called, saving the deserialization result of the deserialization interface function.
[0009] In the above implementation process, after the .NET framework module is loaded, it is determined whether the deserialization interface function has been called. After the deserialization interface function is called, the deserialization result of the deserialization interface function is saved. In this way, once the dynamic call interface function is called later, it can be determined whether a dynamic call after .NET deserialization has occurred by comparing whether the saved deserialization result is the same as the object called by the dynamic call interface function.
[0010] Furthermore, the deserialization interface function and the dynamic call interface function call the same underlying function.
[0011] After the .NET Framework module is loaded, the method further includes: monitoring whether the underlying function is called; if the underlying function is called, determining the call number when the underlying function is called;
[0012] The step of determining whether the deserialization interface function has been called includes: determining whether the call number is consistent with the preset call number of the dynamic call interface function; if they are consistent, determining that the dynamic call interface function has been called; otherwise, determining that the dynamic call interface function has not been called.
[0013] The step of determining whether the deserialization interface function has been called includes: determining whether the call number is consistent with the preset call number of the deserialization interface function; if they are consistent, determining that the deserialization interface function has been called; otherwise, determining that the deserialization interface function has not been called.
[0014] In the above implementation process, by configuring the deserialization interface function and the dynamic call interface function to call the same underlying function, and different deserialization interface functions and dynamic call interface functions have different call numbers when calling the underlying function, by monitoring whether the underlying function is called, and then by using the call number when the underlying function is called, it is possible to accurately determine whether the deserialization interface function or the dynamic call interface function has been called.
[0015] Furthermore, monitoring whether the underlying function is called includes: obtaining the function address of the underlying function; and monitoring whether the underlying function is called based on the function address.
[0016] Considering that the underlying function may be a non-exported function (i.e., it may not be an exported function), in the above implementation, by obtaining the function address of the underlying function, it is possible to monitor whether the underlying function is called when it is a non-exported function, thereby ensuring that the solution of this application can be executed reliably.
[0017] Further, obtaining the function address of the underlying function includes: creating a .NET interface instance; calling the .NET instance object creation function according to the virtual function table of the .NET interface instance to obtain the .NET instance object created by the .NET instance object creation function; and querying the virtual function table of the .NET instance object to obtain the function address of the underlying function.
[0018] It should be understood that the function addresses of underlying functions are generally not pre-loaded into memory, therefore, the function addresses of underlying functions cannot be directly obtained. However, in the above implementation, by leveraging the characteristic that the underlying function is the function called by the deserialization interface function and the underlying function of the dynamic call interface function (this characteristic indicates that the underlying function will inevitably be called during the creation of a .NET instance object), a .NET interface instance is created, and then a .NET instance object is created using the .NET instance object creation function. The function address of the underlying function can then be found in the virtual function table of the .NET instance object, thus achieving effective acquisition of the function address of the underlying function and ensuring that the proposed solution can be reliably executed.
[0019] Furthermore, the deserialization interface function is the Deserialize function, and the dynamic invocation interface function is the DynamicInvoke function.
[0020] Furthermore, the call number of the Deserialize function is 0x60020006; the call number of the DynamicInvoke function is 0x60020007.
[0021] Furthermore, the monitoring of whether the .NET Framework module is loaded includes: monitoring whether the identifier described in the identifier description parameter of the ntdll exported function is the name of the .NET Framework module; if yes, it is determined that the .NET Framework module is loaded; if no, it is determined that the .NET module is not loaded.
[0022] Generally, .NET Framework modules are DLL (Dynamic Link Library) files. When a .NET Framework module is loaded, it is typically loaded through an ntdll exported function (such as the LdrLoadDll function). The identifier description parameter (such as the Dllname parameter) of the ntdll exported function specifies the identifier of the loaded DLL file (such as the DLL name). Therefore, in the above implementation, by monitoring whether the identifier described in the identifier description parameter of the ntdll exported function matches the name of the .NET Framework module, it is possible to monitor whether the .NET Framework module has been loaded. This method is simple to implement, has good monitoring results, is easy to promote in industrial applications, and has universality.
[0023] This application embodiment also provides a monitoring device, including: a monitoring module for monitoring whether a .NET framework module is loaded; a judgment module for judging whether a dynamic call interface function is called when the .NET framework module is loaded; a processing module for comparing the saved deserialization result with the object called by the dynamic call interface function when the dynamic call interface function is called; the processing module is further used to determine that a dynamic call after .NET deserialization has occurred when the deserialization result and the object called by the dynamic call interface function are the same.
[0024] This application also provides an electronic device, including a processor and a memory; the processor is used to execute one or more programs stored in the memory to implement any of the above-described monitoring methods.
[0025] This application also provides a computer-readable storage medium storing one or more programs that can be executed by one or more processors to implement any of the above-described monitoring methods. Attached Figure Description
[0026] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0027] Figure 1 A flowchart illustrating a monitoring method provided in an embodiment of this application;
[0028] Figure 2 A schematic diagram of a monitoring process provided in an embodiment of this application;
[0029] Figure 3 This is a schematic diagram of the structure of a monitoring device provided in an embodiment of this application;
[0030] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0031] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.
[0032] Example 1:
[0033] To address the issue that existing monitoring technologies cannot monitor the behavior of dynamically invoked functions after deserialization into .NET objects, this application provides a monitoring method. (See also...) Figure 1 As shown, Figure 1 This is a flowchart illustrating a monitoring method provided in an embodiment of this application, including:
[0034] S101: Monitor whether .NET Framework modules are loaded.
[0035] It should be understood that dynamic calls after .NET deserialization require loading .NET framework modules, such as the mscorwks.dll module. Therefore, by checking whether .NET framework modules are loaded, it can be determined whether dynamic calls after .NET deserialization are possible.
[0036] Generally, .NET Framework modules are DLL files. When a .NET Framework module is loaded, it is typically loaded through an exported function of ntdll (i.e., an exported function in ntdll.dll, such as the LdrLoadDll function). The identifier description parameter of the ntdll exported function (the identifier described in the identifier description parameter can be the module name or the parameter DLLName) specifies the identifier of the loaded DLL file (for example, the DLL name of the loaded DLL file). Therefore, in this embodiment, it is possible to monitor whether the identifier described in the identifier description parameter of the ntdll exported function is the name of the .NET Framework module; if it is, it can be determined that the .NET Framework module has been loaded; if not, it can be determined that the .NET module has not been loaded. This allows for simple, fast, and accurate monitoring of whether a .NET Framework module has been loaded.
[0037] It should be understood that ntdll is a DLL file, which is the entry point for the Windows system from ring 3 to ring 0. It implements many basic functions, such as the LdrLoadDll function, which can be used to load modules. Therefore, by hooking the exported functions of ntdll (such as the LdrLoadDll function), it is possible to monitor whether .NET Framework modules are loaded.
[0038] It should also be understood that the above is only one feasible implementation method of the present application and is not intended to limit the implementation of the present application. In fact, when monitoring whether a .NET framework module is loaded is implemented in other ways, it can also be adopted by the embodiments of the present application. For example, a program specifically designed to monitor the .NET framework module can be written to monitor whether the .NET framework module is loaded.
[0039] S102: When a .NET Framework module is loaded, determine whether a dynamically invoked interface function has been called.
[0040] S103: If the dynamic call interface function is called, compare the saved deserialization result with the object called by the dynamic call interface function.
[0041] In this embodiment, after the .NET framework module is loaded, it can be determined whether the deserialization interface function has been called. If the deserialization interface function is called, the deserialization result is saved. If the deserialization interface function is not called, monitoring continues.
[0042] It should be noted that after the deserialization interface function is called, it can deserialize a specially encoded string into a .NET object. Therefore, the deserialization result in this embodiment may include the deserialized .NET object.
[0043] It should be noted that, in the embodiments of this application, after the .NET framework module is loaded, the determination of whether the deserialization interface function has been called and the determination of whether the dynamic calling interface function has been called can be performed synchronously.
[0044] In one feasible implementation, if the dynamic call interface function is invoked but the deserialization interface function has not yet been invoked, the operation of comparing the deserialization result with the object called by the dynamic call interface function can still be performed. Since the deserialization interface function has not yet been invoked, the deserialization result is empty, and the comparison result will necessarily show that the deserialization result and the object called by the dynamic call interface function are different. Therefore, there is no need to design more complex judgment logic, which simplifies the machine's execution logic.
[0045] In another feasible implementation, if the dynamic call interface function is called but the deserialization interface function has not yet been called, the comparison between the deserialization result and the object called by the dynamic call interface function can be skipped. Instead, it can be directly determined that the dynamic call interface function was not dynamically called after .NET deserialization, thus saving processing time.
[0046] S104: If the deserialization result is the same as the object called by the dynamic call interface function, it is determined that a dynamic call after .NET deserialization has occurred.
[0047] Correspondingly, if the deserialization result is different from the object called by the dynamic interface function, it means that the object called by the dynamic interface function is not the .NET object obtained after deserialization. Therefore, it can be determined that the dynamic call to the interface function did not involve dynamic calling after deserialization by .NET.
[0048] Optionally, in this embodiment, the deserialization interface function can be the Deserialize function, and the dynamic invocation interface function can be the DynamicInvoke function, but this is not a limitation.
[0049] It should be understood that deserialization interface functions and dynamic call interface functions execute their own functions by calling underlying functions (i.e., the underlying functions being called). Therefore, in this embodiment, the determination of whether a deserialization interface function has been called can be achieved by monitoring the underlying functions called by the deserialization interface function.
[0050] In this embodiment of the application, the monitoring of whether a low-level function is called can be achieved by hooking the low-level function.
[0051] In this embodiment, the same underlying function can be configured for both the deserialization interface function and the dynamic invocation interface function. For example, the Deserialize function and the DynamicInvoke function are configured with the same underlying function, InternalDispatchImpl_Invoke_Wrapper. However, it should be understood that different interface functions will use different call numbers when calling the same underlying function. Based on this, in this embodiment, it is possible to monitor whether the underlying function is called, and then, when the underlying function is called, determine whether the deserialization interface function or the dynamic invocation interface function has been called based on the call number used to call the underlying function.
[0052] For example, the device can pre-store the call numbers of the deserialization interface function and the dynamic call interface function. If the underlying function is called, the call number at the time of the call can be obtained. If the call number matches the call number of the deserialization interface function, it is determined that the deserialization interface function has been called; if the call number matches the call number of the dynamic call interface function, it is determined that the dynamic call interface function has been called. In this way, by monitoring whether the underlying function is called, and then using the call number at the time of the call, it is possible to accurately determine whether the deserialization interface function or the dynamic call interface function has been called.
[0053] For example, when the deserialization interface function is the Deserialize function and the dynamic invocation interface function is the DynamicInvoke function, the call number of the Deserialize function is 0x60020006 and the call number of the DynamicInvoke function is 0x60020007. Therefore, by identifying whether the call number of the underlying function (InternalDispatchImpl_Invoke_Wrapper function) is 0x60020006 or 0x60020007, it is possible to determine whether the deserialization interface function or the dynamic invocation interface function has been called.
[0054] It is important to note that in practical applications, the underlying function may be a non-exported function (i.e., it may not be an exported function). For example, the `InternalDispatchImpl_Invoke_Wrapper` function is a non-exported function and therefore cannot be directly monitored. Therefore, in this embodiment, the function address of the underlying function can be obtained first, and then the function address can be used to monitor whether the underlying function is called. In this way, by obtaining the function address of the underlying function, even when the underlying function is a non-exported function, monitoring whether the underlying function is called can be achieved through the function address, thereby ensuring that the solution provided in this embodiment can be reliably executed.
[0055] It should be understood that the function addresses of underlying functions are generally not pre-loaded into memory, and therefore cannot be directly obtained. Therefore, in order to obtain the function addresses of underlying functions, in this embodiment, a .NET interface instance can be created first. Then, based on the virtual function table of the .NET interface instance, the .NET instance object creation function can be called to obtain the .NET instance object created by that function. Finally, the virtual function table of the .NET instance object can be queried to obtain the function addresses of the underlying functions.
[0056] Since the underlying function is a deserialization interface function and / or a function called by the underlying dynamic call interface function, it will inevitably be called during the creation of the .NET instance object. Therefore, based on this characteristic, by creating a .NET interface instance, and then using the .NET instance object creation function to create a .NET instance object, the function address of the underlying function can be found in the virtual function table of the .NET instance object, thus achieving effective acquisition of the function address of the underlying function.
[0057] The monitoring method provided in this application first monitors whether the .NET Framework module is loaded to determine if a dynamic call after .NET deserialization is likely to occur. If the .NET Framework module is loaded, it determines whether the dynamic call interface function is invoked. If the dynamic call interface function is invoked, it determines whether the saved deserialization result (which can be used to determine whether the deserialization interface function was invoked, and then save the deserialization result obtained after the deserialization interface function call) is the same as the object invoked by the dynamic call interface function, thereby determining whether a dynamic call after .NET deserialization has occurred. This application's approach monitors the dynamic call behavior after deserialization into a .NET object, overcoming the shortcomings of existing technologies.
[0058] Example 2:
[0059] To facilitate understanding of the solutions in this application, this embodiment, based on Embodiment 1, takes the case where the .NET framework module is mscorwks.dll, the deserialization interface function is the Deserialize function, and the dynamic invocation interface function is the DynamicInvoke function as an example to further illustrate this application.
[0060] See Figure 2 As shown, the entire process includes the following three steps:
[0061] S201: Monitor whether mscorwks.dll is loaded.
[0062] It should be understood that dynamic calls after .NET deserialization require loading the .NET Framework module mscorwks.dll, so whether to make a .NET call can be determined by checking whether this DLL (i.e., mscorwks.dll) is loaded.
[0063] In this embodiment, when mscorwks.dll is loaded, the name of the loaded DLL is specified in the DllName parameter of the ntdll exported function LdrLoadDll. Therefore, by hooking the LdrLoadDll function, it is possible to monitor whether mscorwks.dll is loaded. The specific implementation code is as follows:
[0064]
[0065] S202: Obtain the function address of the InternalDispatchImpl_Invoke_Wrapper function.
[0066] The underlying function called by the Deserialize and DynamicInvoke functions is the same function: mscorwks! InternalDispatchImpl_Invoke_Wrapper. Therefore, by hooking this function, it is possible to monitor whether the Deserialize and DynamicInvoke functions are called.
[0067] The `InternalDispatchImpl_Invoke_Wrapper` function is a non-exported function, so its address needs to be obtained first. Therefore, in this embodiment, we can first create a .NET interface instance, find the `mscorwks!EEClassFactory::CreateInstance` function (i.e., the .NET instance object creation function) through the instance's virtual function table, call this function to return a .NET instance object, and then traverse the virtual function table of the .NET instance object to find the function address of `mscorwks!InternalDispatchImpl_Invoke_Wrapper`.
[0068] It should be understood that in the virtual function table of a .NET instance object, each row is predefined to store the address of which function. Therefore, by simply matching the number of entries in the predefined virtual function table with the mscorwks! InternalDispatchImpl_Invoke_Wrapper function, the address of the mscorwks! InternalDispatchImpl_Invoke_Wrapper function recorded in the corresponding entry of the .NET instance object's virtual function table can be found.
[0069] Below is pseudocode for obtaining the function address of the `mscorwks! InternalDispatchImpl_Invoke_Wrapper` function:
[0070]
[0071] S203: Determine if a dynamic call occurred after .NET deserialization.
[0072] In this embodiment of the application, after obtaining the function address of the InternalDispatchImpl_Invoke_Wrapper function through step S202, the InternalDispatchImpl_Invoke_Wrapper function can be hooked. The call number dispidMember is used to determine whether the Deserialize function and the DynamicInvoke function are called. The call number of the Deserialize function is 0x60020006, and the call number of the DynamicInvoke function is 0x60020007.
[0073] When the `Deserialize` function is called, the deserialization result of `Deserialize` is retrieved and saved. If the `DynamicInvoke` function is subsequently called, the previously saved deserialization result is compared with the object called by the `DynamicInvoke` function (it should be understood that when the `DynamicInvoke` function is called, the value recorded in the first parameter is the object called by the `DynamicInvoke` function). If they are the same, it is determined that a dynamic call after .NET deserialization has occurred. The pseudocode for this process is as follows:
[0074]
[0075]
[0076] The above solution can effectively monitor the dynamic calling behavior of .NET interfaces after deserialization, realizing the monitoring of dynamic calling behavior after deserialization into .NET objects, thus making up for the shortcomings of existing technologies.
[0077] Example 3:
[0078] Based on the same inventive concept, this application also provides a monitoring device 300 in its embodiments. Please refer to... Figure 3 As shown, Figure 3 It shows the use of Figure 1 The monitoring device for the method shown. It should be understood that the specific functions of device 300 can be found in the description above; to avoid repetition, detailed descriptions are appropriately omitted here. Device 300 includes at least one software function module that can be stored in memory or embedded in the operating system of device 300 in the form of software or firmware. Specifically:
[0079] See Figure 3 As shown, the device 300 includes: a monitoring module 301, a judgment module 302, and a processing module 303. Wherein:
[0080] Monitoring module 301 is used to monitor whether .NET Framework modules are loaded;
[0081] The judgment module 302 is used to determine whether the dynamically invoked interface function has been called when the .NET framework module is loaded;
[0082] Processing module 303 is used to compare the saved deserialization result with the object called by the dynamic call interface function when the dynamic call interface function is called;
[0083] The processing module 303 is further configured to determine that a dynamic call after .NET deserialization has occurred when the deserialization result and the object called by the dynamic call interface function are the same.
[0084] In this embodiment of the application, the judgment module 302 is further configured to determine whether the deserialization interface function is called when the .NET framework module is loaded; the processing module 303 is further configured to save the deserialization result of the deserialization interface function if the deserialization interface function is called.
[0085] In one feasible embodiment of this application, the deserialization interface function and the dynamic call interface function call the same underlying function. The judgment module 302 is specifically used to: monitor whether the underlying function is called; determine whether the call number is consistent with the preset call number of the dynamic call interface function; if consistent, determine that the dynamic call interface function has been called; otherwise, determine that the dynamic call interface function has not been called; determine whether the call number is consistent with the preset call number of the deserialization interface function; if consistent, determine that the deserialization interface function has been called; otherwise, determine that the deserialization interface function has not been called.
[0086] In the above feasible implementation, the judgment module 302 is specifically used to obtain the function address of the underlying function and monitor whether the underlying function is called based on the function address.
[0087] In the above feasible implementation, the judgment module 302 is specifically used to create a .NET interface instance;
[0088] Based on the virtual function table of the .NET interface instance, the .NET instance object creation function is called to obtain the .NET instance object created by the .NET instance object creation function;
[0089] Query the virtual function table of the .NET instance object to obtain the function address of the underlying function.
[0090] In this embodiment of the application, the deserialization interface function is the Deserialize function, and the dynamic invocation interface function is the DynamicInvoke function.
[0091] In this embodiment of the application, the call number of the Deserialize function is 0x60020006; the call number of the DynamicInvoke function is 0x60020007.
[0092] In this embodiment of the application, the monitoring module 301 is specifically used to monitor whether the identifier described in the identifier description parameter of the ntdll exported function is the name of the .NET framework module; if yes, it determines that the .NET framework module is loaded; if no, it determines that the .NET module is not loaded.
[0093] It should be understood that, for the sake of brevity, some of the content described in Embodiment 1 will not be repeated in this embodiment.
[0094] Example 4:
[0095] This embodiment provides an electronic device, see [link / reference] Figure 4 As shown, it includes a processor 401 and a memory 402. Wherein:
[0096] The processor 401 is used to execute one or more programs stored in the memory 402 to implement the monitoring methods in Embodiment 1 and / or Embodiment 2 described above.
[0097] It is understood that in this embodiment of the application, the processor 401 can be used to provide computing and control capabilities to support the operation of the entire electronic device. For example, the processor 401 can be a CPU (Central Processing Unit), MPU (Microprocessor Unit), MCU (Microcontroller Unit), microcontroller, programmable logic gate device, etc., but this is not a limitation.
[0098] It is understood that in the embodiments of this application, the memory 402 may include at least one of non-volatile storage media, internal memory, etc.
[0099] It's understandable. Figure 4 The structure shown is for illustrative purposes only; the electronic device may also include components that are more advanced than those shown. Figure 4 The more or fewer components shown, or having the same Figure 4 The different configurations shown.
[0100] For example, the electronic device may also have a communication bus for connecting and communicating between the processor 401 and the memory 402. As another example, the electronic device may also have a wireless communication module to enable wireless communication with other devices.
[0101] It should be understood that in the embodiments of this application, the electronic device may be a terminal (such as a smartphone, computer, etc.) or a server, etc., and there is no limitation on this in the embodiments of this application.
[0102] This embodiment also provides a computer-readable storage medium, such as a floppy disk, optical disk, hard disk, flash memory, USB flash drive, SD (Secure Digital Memory Card), MMC (Multimedia Card), etc., in which one or more programs implementing the above steps are stored. These one or more programs can be executed by one or more processors to implement the monitoring methods in Embodiment 1 and / or Embodiment 2. Further details will not be elaborated here.
[0103] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.
[0104] Furthermore, the units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0105] Furthermore, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.
[0106] In this document, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, without necessarily requiring or implying any such actual relationship or order between these entities or operations.
[0107] In this article, "multiple" refers to two or more.
[0108] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.
Claims
1. A monitoring method, characterized in that, include: Monitor whether .NET Framework modules are loaded; After the .NET Framework module is loaded, determine whether the dynamically invoked interface function has been called; If the dynamic call interface function is invoked, compare the saved deserialization result with the object called by the dynamic call interface function; If the deserialization result is the same as the object called by the dynamic call interface function, it is determined that a dynamic call after .NET deserialization has occurred. After the .NET Framework module is loaded, the method further includes: Determine whether the deserialization interface function has been called; If the deserialization interface function is called, the deserialization result of the deserialization interface function is saved; The deserialization interface function and the dynamic call interface function call the same underlying function. After the .NET Framework module is loaded, the method further includes: monitoring whether the underlying function is called; if the underlying function is called, determining the call number when the underlying function is called; The determination of whether the deserialization interface function has been called includes: Determine whether the call number matches the preset call number of the dynamic call interface function; if they match, determine that the dynamic call interface function has been called; otherwise, determine that the dynamic call interface function has not been called. The determination of whether the deserialization interface function has been called includes: Determine whether the call number matches the preset call number of the deserialization interface function; if they match, determine that the deserialization interface function has been called; otherwise, determine that the deserialization interface function has not been called.
2. The monitoring method as described in claim 1, characterized in that, Monitoring whether the underlying function is called includes: Obtain the function address of the underlying function; Monitor whether the underlying function is called based on the function address.
3. The monitoring method as described in claim 2, characterized in that, Obtaining the function address of the underlying function includes: Create a .NET interface instance; Based on the virtual function table of the .NET interface instance, the .NET instance object creation function is called to obtain the .NET instance object created by the .NET instance object creation function; Query the virtual function table of the .NET instance object to obtain the function address of the underlying function.
4. The monitoring method as described in claim 1, characterized in that, The deserialization interface function is the Deserialize function, and the dynamic invocation interface function is the DynamicInvoke function.
5. The monitoring method as described in claim 4, characterized in that, The call number of the Deserialize function is 0x60020006; the call number of the DynamicInvoke function is 0x60020007.
6. The monitoring method according to any one of claims 1-5, characterized in that, The monitoring of whether the .NET Framework module is loaded includes: Monitor whether the identifier described in the identifier description parameter of the exported function of ntdll is the name of the .NET Framework module; If so, confirm that the .NET Framework module is loaded; If not, it is determined that the .NET Framework module has not been loaded.
7. A monitoring device, characterized in that, include: The monitoring module is used to monitor whether .NET Framework modules are loaded. The judgment module is used to determine whether the dynamically invoked interface function has been called when the .NET framework module is loaded; The processing module is used to compare the saved deserialization result with the object called by the dynamic call interface function when the dynamic call interface function is invoked; The processing module is further configured to determine that a dynamic call after .NET deserialization has occurred when the deserialization result and the object called by the dynamic call interface function are the same. The judgment module is further configured to determine whether the deserialization interface function is called when the .NET framework module is loaded; the processing module is further configured to save the deserialization result of the deserialization interface function if the deserialization interface function is called. The deserialization interface function and the dynamic call interface function call the same underlying function; the judgment module is specifically used to monitor whether the underlying function is called; to determine whether the call number is consistent with the preset call number of the dynamic call interface function; if they are consistent, to determine that the dynamic call interface function is called; Otherwise, it is determined that the dynamically invoked interface function has not been called; Determine whether the call number is consistent with the preset call number of the deserialization interface function; If they match, it is determined that the deserialization interface function has been called; Otherwise, it is determined that the deserialization interface function has not been called.
8. An electronic device, characterized in that, include: Processor and memory; The processor is used to execute one or more programs stored in the memory to implement the monitoring method as described in any one of claims 1-6.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores one or more programs, which can be executed by one or more processors to implement the monitoring method as described in any one of claims 1-6.