CN115186264A - Monitoring method, monitoring device, electronic equipment and computer readable storage medium - Google Patents
Monitoring method, monitoring device, electronic equipment and computer readable storage medium Download PDFInfo
- Publication number
- CN115186264A CN115186264A CN202210887253.XA CN202210887253A CN115186264A CN 115186264 A CN115186264 A CN 115186264A CN 202210887253 A CN202210887253 A CN 202210887253A CN 115186264 A CN115186264 A CN 115186264A
- Authority
- CN
- China
- Prior art keywords
- function
- called
- deserialization
- interface function
- net
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/55—Detecting local intrusion or implementing counter-measures
- G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
- G06F21/566—Dynamic detection, i.e. detection performed at run-time, e.g. emulation, suspicious activities
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/55—Detecting local intrusion or implementing counter-measures
- G06F21/552—Detecting local intrusion or implementing counter-measures involving long-term monitoring or reporting
Abstract
The application provides a monitoring method, a monitoring device, an electronic device and a computer readable storage medium, wherein the monitoring method comprises the following steps: monitoring whether a NET framework module is loaded; when the NET framework module is loaded, judging whether a dynamic call interface function is called or not; if the dynamic call interface function is called, comparing the stored deserialization result with an object called by the dynamic call interface function; and if the deserialization result is the same as the object called by the dynamic call interface function, determining that the dynamic call after the deserialization of the NET occurs. By the method, the monitoring of the behavior dynamically called after the deserialization is NET objects is realized, and the defects of the prior art are overcome.
Description
Technical Field
The present application relates to the field of information security, and in particular, to a monitoring method, an apparatus, an electronic device, and a computer-readable storage medium.
Background
Currently, there are some malicious scripts that deserialize a specifically encoded string into a primitive NET object with malicious behavior through a deserialization Interface function (also called an deserialization API), and then call the primitive NET object to perform the malicious behavior through a dynamic call Interface function (also called a dynamic call API).
Then, in order to effectively identify the malicious scripts, whether dynamic call of the NET after deserialization occurs in the system needs to be monitored, so that whether the dynamic call of the NET after deserialization occurs is judged through relevant malicious script identification technologies.
However, the existing monitoring technology cannot monitor the behavior of dynamic call after the deserialization is performed on the NET object, so that the identification effect on the malicious scripts is poor.
Disclosure of Invention
An embodiment of the present application aims to provide a monitoring method, a monitoring device, an electronic device, and a computer-readable storage medium, so as to solve a problem that an existing monitoring technology cannot monitor a behavior that is dynamically invoked after an anti-serialization NET object.
The embodiment of the application provides a monitoring method, which comprises the following steps: monitoring whether a NET framework module is loaded; after the NET framework module is loaded, judging whether a dynamic call interface function is called or not; if the dynamic call interface function is called, comparing the stored deserialization result with an object called by the dynamic call interface function; and if the deserialization result is the same as the object called by the dynamic call interface function, determining that the dynamic call after the deserialization of the NET occurs.
It should be understood that the dynamic call after deserialization of the.net requires loading the.net framework module, so in the above implementation, it is first determined whether the dynamic call after deserialization of the.net is likely to occur by monitoring whether the.net framework module is loaded. If the NET framework module is loaded, whether the dynamic call after the deserialization of the NET occurs or not can be determined by judging whether the dynamic call interface function is called or not and judging whether the stored deserialization result is the same as the object called by the dynamic call interface function or not once the dynamic call interface function is called. By the method, the monitoring of the behavior dynamically called after the deserialization is NET objects is realized, and the defects of the prior art are overcome.
Further, after the NET framework module is loaded, the method further comprises: judging whether the deserialization interface function is called or not; and if the deserialization interface function is called, saving the deserialization result of the deserialization interface function.
In the implementation process, after the NET framework module is loaded, whether the deserialization interface function is called is judged, so that the deserialization result of the deserialization interface function is stored after the deserialization interface function is called, and once the subsequent dynamic calling interface function is called, whether the stored deserialization result is the same as the object called by the dynamic calling interface function can be judged, so that whether the dynamic calling of the NET occurs or not is determined.
Furthermore, the deserialization interface function and the function called by the dynamic calling interface function are the same bottom function;
after the. NET framework module is loaded, the method further comprises: monitoring whether the bottom layer function is called; if the bottom function is called, determining a calling number when the bottom function is called;
the judging whether the deserializing interface function is called includes: judging whether the calling number is consistent with a preset calling number of the dynamic calling interface function or not; if the dynamic calling interface function is consistent with the dynamic calling interface function, determining that the dynamic calling interface function is called; otherwise, determining that the dynamic call interface function is not called;
the judging whether the deserializing interface function is called includes: judging whether the calling number is consistent with a preset calling number of the deserialization interface function or not; if the interface function is consistent with the deserialization interface function, determining that the deserialization interface function is called; otherwise, determining that the deserialization interface function is not called.
In the implementation process, the function called by the bottom layers of the deserialization interface function and the dynamic calling interface function is configured to be the same bottom layer function, and different bottom layers of the deserialization interface function and the dynamic calling interface function have different calling numbers when calling the bottom layer function, so that whether the deserialization interface function or the dynamic calling interface function is called can be accurately determined by monitoring whether the bottom layer function is called and then calling the calling number when calling the bottom layer function.
Further, monitoring whether the underlying function is called comprises: acquiring a function address of the bottom layer function; and monitoring whether the bottom layer function is called or not according to the function address.
Considering that the underlying function may be a non-derived function (that is, may not be a derived function), in the implementation manner described above, by obtaining a function address of the underlying function, it is possible to implement monitoring on whether the underlying function is called or not through the function address when the underlying function is the non-derived function, so as to ensure that the scheme of the present application can be reliably executed.
Further, obtaining a function address of the underlying function includes: creating a NET interface example; according to the virtual function table of the NET interface embodiment, calling a NET embodiment object creating function to obtain a NET embodiment object created by the NET embodiment object creating function; and querying a virtual function table of the NET instance object to obtain a function address of the bottom-layer function.
It should be understood that the function address of the underlying function is not typically preloaded into memory and therefore cannot be directly retrieved. In the implementation manner, by using the characteristic that the bottom function is an deserialization interface function and a function called by the dynamic call interface function bottom (the characteristic indicates that the bottom function is inevitably called in the creation process of the NET instance object), the NET instance object is created by creating the NET interface object and then using the NET instance object creation function, the NET instance object can be further searched from the virtual function table of the NET instance object to obtain the function address of the bottom function, so that the function address of the bottom function can be effectively obtained, and the scheme of the application can be reliably executed.
Further, the deserialization interface function is a Deserialize function, and the dynamic call interface function is a dynamic invoke function.
Further, the calling number of the Deserialize function is 0x60020006; the calling number of the dynamic invoke function is 0x60020007.
NET framework modules are loaded, including: monitoring whether an identifier described in an identifier description parameter of the ntdll derivation function is the name of the NET framework module; if yes, determining that the NET framework module is loaded; if not, determining that the NET module is not loaded.
Generally speaking, a NET framework module belongs to a Dll (Dynamic Link Library) file, and the NET framework module is generally loaded by an ntdll export function (e.g. LdrLoadDll function) when being loaded, and an identification description parameter (e.g. parameter Dllname) of the ntdll export function specifies an identification of the loaded Dll file (e.g. the dlll name of the loaded Dll file). Therefore, in the above implementation, whether the identifier described in the identifier description parameter of the ntdll derivation function is the name of the.net framework module or not is monitored, so that whether the.net framework module is loaded or not can be monitored. The method is simple to realize, good in monitoring effect, beneficial to popularization in industrial application and universal.
An embodiment of the present application further provides a monitoring device, including: the monitoring module is used for monitoring whether the NET framework module is loaded or not; the judging module is used for judging whether the dynamic calling interface function is called or not when the NET framework module is loaded; the processing module is used for comparing the stored deserialization result with an object called by the dynamic call interface function when the dynamic call interface function is called; the processing module is further configured to determine that the dynamic call after deserialization of the NET occurs when the deserialization result is the same as the object called by the dynamic call interface function.
The embodiment of the application also provides an electronic device, which comprises a processor and a memory; the processor is configured to execute one or more programs stored in the memory to implement any of the monitoring methods described above.
Also provided in an embodiment of the present application is a computer-readable storage medium storing one or more programs, which are executable by one or more processors to implement the monitoring method of any one of the above.
Drawings
To more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are required to be used in the embodiments of the present application will be briefly described below, it should be understood that the following drawings only illustrate some embodiments of the present application and therefore should not be considered as limiting the scope, and that those skilled in the art can also obtain other related drawings based on the drawings without inventive efforts.
Fig. 1 is a schematic flowchart of a monitoring method according to an embodiment of the present disclosure;
fig. 2 is a schematic monitoring flow chart provided in an embodiment of the present application;
fig. 3 is a schematic structural diagram of a monitoring device according to an embodiment of the present disclosure;
fig. 4 is a schematic structural diagram of an electronic device according to an embodiment of the present application.
Detailed Description
The technical solutions in the embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application.
The first embodiment is as follows:
in order to solve the problem that the existing monitoring technology cannot monitor the behavior of dynamic calling after the deserialization is NET objects, the embodiment of the application provides a monitoring method. As shown in fig. 1, fig. 1 is a schematic flow chart of a monitoring method provided in an embodiment of the present application, and includes:
s101: monitoring whether a NET framework module is loaded.
It should be understood that the dynamic call after deserialization of the. NET needs to be loaded the NET framework module, e.g., mscorrwks. Dll needs to be loaded, so it can be determined whether the dynamic call after deserialization of the. NET is likely to occur by determining whether the NET framework module is loaded.
Generally speaking, a NET framework module belongs to a Dll file, the NET framework module is loaded through an ntdll export function (i.e. an export function in ntdll, such as LdrLoadDll function), and an identification description parameter of the ntdll export function (the identification described in the identification description parameter may be a module name, and the identification description parameter may be a parameter DLLName) specifies an identification of the loaded Dll file (e.g. the Dll name of the loaded Dll file). Therefore, in the embodiment of the present application, it may be monitored whether the identifier described in the identifier description parameter of the ntdll export function is the name of the. NET framework module; if yes, the NET framework module is determined to be loaded; if not, determining that the NET module is not loaded. Therefore, whether the NET framework module is loaded or not can be simply, quickly and accurately monitored.
It should be understood that ntdll is a DLL file, which is an entry from ring3 to ring0 in the Windows system, and has many basic functions implemented therein, for example, ldrLoadDll function that can be used for module loading, so that the monitoring of whether the. NET framework module is loaded or not can be implemented through the HOOK ntdll export function (for example, ldrLoadDll function).
It should also be understood that the above is only one possible implementation of the examples of the present application and is not intended as a limitation on the embodiments of the present application. In fact, when the monitoring of whether the NET frame module is loaded is implemented in other ways, the monitoring may also be adopted in the embodiment of the present application, for example, the monitoring of whether the NET frame module is loaded may also be implemented by writing a program that specially monitors the NET frame module.
S102: when the NET framework module is loaded, whether the dynamic call interface function is called or not is judged.
S103: if the dynamic call interface function is called, comparing the stored deserialization result with the object called by the dynamic call interface function.
In this embodiment, after the NET framework module is loaded, it may be further determined whether the deserialization interface function is called. And if the deserialization interface function is called, saving the deserialization result of the deserialization interface function. If the deserialization interface function is not called, then monitoring continues.
It should be noted that, after the deserialization interface function is called, the specifically encoded character string may be deserialized into the NET object. Thus, the deserialization result in the embodiment of the present application may include the.
It should be noted that, in the embodiment of the present application, after the NET framework module is loaded, it may be synchronously performed to determine whether the deserialization interface function is called or not, and determine whether the dynamic call interface function is called or not.
In one possible embodiment, if the dynamic call interface function is called but the deserialization interface function has not yet been called, the operation of comparing the deserialization result with the object called by the dynamic call interface function may also be performed. At this time, because the deserializing interface function is not called yet, the deserializing result is null, so that the comparison result is that the deserializing result is different from the object called by the dynamic call interface function, a more complex judgment logic does not need to be designed, and the execution logic of the machine can be simplified.
In another possible implementation, if the dynamic call interface function is called but the deserialization interface function is not called yet, the deserialization result may not be compared with the object called by the dynamic call interface function, and it may be directly determined that the deserialization dynamic call of the NET does not occur in the current call of the dynamic call interface function, thereby saving processing time.
S104: and if the deserialization result is the same as the object called by the dynamic call interface function, determining that the dynamic call after the deserialization of the NET occurs.
Correspondingly, if the deserialization result is different from the object called by the dynamic call interface function, it is indicated that the object called by the dynamic call interface function is not the deserialized object.
Optionally, in this embodiment of the present application, the deserialization interface function may be a deseriaize function, and the dynamic call interface function may be a dynamic invoke function, but is not limited to this.
It should be understood that the deserialization interface function and the dynamic call interface function may perform their own functions by calling the underlying function (i.e., the underlying called function). Therefore, in the embodiment of the present application, whether the deserializing interface function is called or not may be determined by monitoring the bottom function called by the deserializing interface function, and whether the deserializing interface function is called or not may be determined by monitoring the bottom function called by the deserializing interface function.
In the embodiment of the present application, whether the underlying function is called or not may be monitored in a mode of the HOOK underlying function.
In the embodiment of the present application, the same underlying function may be configured for the deserialization interface function and the dynamic call interface function. For example, the Deserialize function and the dynamic Invoke function are configured with the same underlying function InternalDispatchImpl _ Invoke _ Wrapper. It should be understood that different interface functions may use different call numbers when calling the same underlying function. Therefore, in the embodiment of the application, whether the bottom layer function is called can be monitored, and when the bottom layer function is called, whether the deserialization interface function or the dynamic calling interface function is called can be judged based on the calling number when the bottom layer function is called.
For example, the call number of the deserialization interface function and the call number of the dynamic call interface function may be saved in advance in the device. If the bottom function is called, the calling number when the bottom function is called can be obtained. If the call number is consistent with the call number of the deserialization interface function, determining that the deserialization interface function is called; and if the calling number is consistent with the calling number of the dynamic calling interface function, determining that the dynamic calling interface function is called. Therefore, whether the deserialization interface function or the dynamic calling interface function is called can be accurately determined by monitoring whether the bottom function is called and then calling the calling number when the bottom function is called.
For example, when the deserialized interface function is a Deserialize function and the dynamic call interface function is a dynamic Invoke function, the call number of the Deserialize function is 0x60020006, and the call number of the dynamic Invoke function is 0x60020007, so that the determination of whether the deserialized interface function or the dynamic call interface function is called can be realized by identifying whether the call number when the underlying function (which is an inter dispatch _ Invoke _ Wrapper function) is 0x60020006 or 0x60020007.
It should be noted that, in practical applications, the underlying function may be a non-derived function (i.e. may not be a derived function), for example, for the internalDispatchImpl _ Invoke _ Wrapper function, it belongs to the non-derived function, and thus cannot be directly monitored. Therefore, in the embodiment of the present application, the function address of the underlying function may be obtained first, and then whether the underlying function is called may be monitored according to the function address. Therefore, by means of acquiring the function address of the bottom-layer function, whether the bottom-layer function is called can be monitored through the function address when the bottom-layer function is a non-derived function, and therefore the scheme provided by the embodiment of the application can be reliably executed.
It should be understood that the function address of the underlying function is generally not preloaded into the memory, and thus cannot be directly obtained. Therefore, in order to obtain the function address of the underlying function, in the embodiment of the present application, a.net interface instance may be created first, then the.net instance object creation function is called according to the virtual function table of the.net interface instance to obtain a.net instance object created by the.net instance object creation function, and finally the virtual function table of the.net instance object is queried to obtain the function address of the underlying function.
Therefore, the function address of the bottom function can be searched from the virtual function table of the NET example object, and the effective acquisition of the function address of the bottom function is realized.
The monitoring method provided by the embodiment of the application firstly determines whether the dynamic call of the deserialization of the NET is possible or not by monitoring whether the NET framework module is loaded or not. If the NET framework module is loaded, whether the dynamic call after the deserialization of the NET occurs is determined by judging whether the dynamic call interface function is called or not, and if the dynamic call interface function is called, judging whether the stored deserialization result (whether the deserialization interface function is called or not can be judged, and then the deserialization result obtained after the deserialization interface function is called is stored after the deserialization interface function is called) is the same as the object called by the dynamic call interface function. The method realizes the monitoring of the behavior of dynamic calling after the deserialization is the NET object, and makes up the defects of the prior art.
Example two:
for the convenience of understanding the solution of the embodiment of the present application, in the embodiment one, based on the case that the NET framework module is mscorwks.
Referring to fig. 2, the whole process includes the following three steps:
s201: dll is monitored for loading.
It should be understood that the. NET framework module mscorwks. Dll needs to be loaded after deserialization of the. NET calls, so it can be determined whether to make the. NET call by determining whether to load the dll (i.e., mscorwks. Dll).
In this embodiment, when mscorwks.dll is loaded, the ntdll exports the parameter DllName of the function LdrLoadDll, and the name of the loaded Dll is specified, so that whether mscorwks.dll is loaded can be monitored through the HOOK ldloaddll function. The specific implementation code is as follows:
s202: the function address of the InternalDispatchImpl _ Invoke _ Wrapper function is obtained.
The functions of the bottom calls of the Deserialize function and the dynamic invoke function are the same function: mscorwks! The InternalDispatctchImpl _ Invoke _ Wrapper function can thus monitor whether the Desrialize function is called and whether the dynamic Invoke function is called by passing the function through HOOK.
The internalldispatch identifier _ Invoke _ Wrapper function is a non-exit function, and therefore the function address needs to be obtained first. To this end, in this embodiment, a NET interface instance may be created first, and mscorwks!is found by the virtual function table of this instance! EEClassFactory:: createInstance function (i.e., NET instance object creation function), call this function to return the NET instance object, then traverse the virtual function table of the NET instance object, query to get mscorwks! Function address of InternalDispatctchImpl _ Invoke _ Wrapper function.
It should be understood that in the virtual function table of the NET instance object, each row pre-defines which function address it needs to store, so that only the number of entries in the pre-defined virtual function table and mscorwks! The mscorwks | recorded in the corresponding item in the virtual function table of NET instance object can be found from the corresponding relationship of InternalDispatchImpl _ Invoke _ Wrapper function! Function address of InternalDispatctchImpl _ Invoke _ Wrapper function.
Following is the acquisition of mscorwks! Pseudo code for function address of InternalDispatctchImpl _ Invoke _ Wrapper function:
s203: it is determined whether an deserialized dynamic call of the NET has occurred.
In this embodiment of the application, after the function address of the interraptchimpl _ Invoke _ Wrapper function is obtained in step S202, the interraptchimpl _ Invoke _ Wrapper function may be hoak, and whether a call of the Deserialize function and the DynamicInvoke function is generated is determined by the parameter call number dispidMember, where the call number of the Deserialize function is 0xm20006, and the call number of the DynamicInvoke function is 0x60020007.
When the calling of the Deserialize function occurs, the deserialization result of the Deserialize function is obtained and saved. If the dynamic call of the NET is generated subsequently, comparing whether the stored deserialization result is the same as the object called by the dynamic invoke function or not (it should be understood that when the dynamic invoke function is called, the value recorded in the first parameter is the object called by the dynamic invoke function), and if so, determining that the dynamic call of the NET after deserialization is generated. The pseudo code for this process is as follows:
by the scheme, the dynamic calling behavior after deserialization of the NET interface can be effectively monitored, the monitoring of the behavior after deserialization of the NET object is realized, and the defects of the prior art are overcome.
Example three:
based on the same inventive concept, the embodiment of the present application further provides a monitoring apparatus 300. Referring to fig. 3, fig. 3 illustrates a monitoring apparatus using the method of fig. 1. It should be understood that the specific functions of the apparatus 300 can be referred to the above description, and the detailed description is omitted here as appropriate to avoid redundancy. The apparatus 300 includes at least one software functional module that can be stored in a memory in the form of software or firmware or solidified in an operating system of the apparatus 300. Specifically, the method comprises the following steps:
referring to fig. 3, the apparatus 300 includes: a monitoring module 301, a judging module 302 and a processing module 303. Wherein:
a monitoring module 301 for monitoring whether the NET framework module is loaded;
a judging module 302, configured to judge whether the dynamic call interface function is called when the NET framework module is loaded;
the processing module 303 is configured to compare the stored deserialization result with an object called by the dynamic call interface function when the dynamic call interface function is called;
the processing module 303 is further configured to determine that the dynamic call after deserialization of the NET occurs when the deserialization result is the same as the object called by the dynamic call interface function.
In this embodiment of the present application, the determining 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 store the deserialization result of the deserialization interface function if the deserialization interface function is called.
In a possible implementation manner of the embodiment of the present application, the deserialization interface function and the function called by the dynamic call interface function at the bottom layer are the same bottom layer function; the determining module 302 is specifically configured to monitor whether the bottom layer function is called; judging whether the calling number is consistent with a preset calling number of the dynamic calling interface function or not; if the dynamic calling interface function is consistent with the dynamic calling interface function, determining that the dynamic calling interface function is called; otherwise, determining that the dynamic call interface function is not called; judging whether the calling number is consistent with a preset calling number of the deserialization interface function or not; if the interface function is consistent with the deserialization interface function, determining that the deserialization interface function is called; otherwise, determining that the deserialization interface function is not called.
In the above feasible embodiment, the determining module 302 is specifically configured to obtain a function address of the bottom-layer function, and monitor whether the bottom-layer function is called according to the function address.
In the above possible implementation, the determining module 302 is specifically configured to create a NET interface instance;
according to the virtual function table of the NET interface embodiment, a NET embodiment object creating function is called to obtain a NET embodiment object created by the NET embodiment object creating function;
and inquiring the virtual function table of the NET instance object to obtain the function address of the bottom function.
In this embodiment of the present application, the deserialization interface function is a Deserialize function, and the dynamic call interface function is a dynamic invoke function.
In the embodiment of the present application, the call number of the deseriaize function is 0x60020006; the calling number of the dynamic invoke function is 0x60020007.
In this embodiment of the application, the monitoring module 301 is specifically configured to monitor whether an identifier described in an identifier description parameter of the ntdll derivation function is the name of the NET framework module; if yes, determining that the NET framework module is loaded; if not, determining that the NET module is not loaded.
It should be understood that, for the sake of brevity, the contents described in some embodiments are not repeated in this embodiment.
Example four:
the present embodiment provides an electronic device, which is shown in fig. 4 and comprises a processor 401 and a memory 402. Wherein:
the processor 401 is configured to execute one or more programs stored in the memory 402 to implement the monitoring method in the first embodiment and/or the second embodiment.
It will be appreciated that in embodiments of the present application, the processor 401 may be used to provide computing and control capabilities to support the operation of the entire electronic device. The processor 401 may be, for example and without limitation, a CPU (Central Processing Unit), an MPU (micro processor Unit), an MCU (micro controller Unit), a single chip microcomputer, a programmable logic gate device, or the like.
It is to be appreciated that in the subject embodiment, the memory 402 can include at least one of a non-volatile memory 15 storage medium, an internal memory, and the like.
It will also be appreciated that the configuration shown in fig. 4 is merely illustrative, and that the electronic device may include more or fewer components than shown in fig. 4, or have a different configuration than shown in fig. 4.
The electronic device may also have a communication bus for enabling connection communication between the processor 401 and the memory 402, for example. For another example, the electronic device may further have a wireless communication module to enable wireless communication with other devices.
It should be understood that, in the embodiment of the present application, the electronic device may be a terminal (for example, a smart phone, a computer, and the like), and may also be a server, and the embodiment of the present application is not limited thereto.
The present embodiment also provides a computer-readable storage medium, such as a floppy disk, an optical disk, a hard disk, a flash Memory, a usb (Secure Digital Memory Card), an MMC (Multimedia Card), etc., in which one or more programs implementing the above steps are stored, and the one or more programs can be executed by one or more processors to implement the monitoring method in the first embodiment and/or the second embodiment. And will not be described in detail herein.
In the embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other ways. The above-described apparatus embodiments are merely illustrative, and for example, the division of the units into only one type of logical function may be implemented in other ways, and for example, multiple units or components may be combined or integrated into another system, or some features may be omitted, or not implemented. In addition, the shown or discussed coupling or direct coupling or communication connection between each other may be through some communication interfaces, indirect coupling or communication connection between devices or units, and may be in an electrical, mechanical or other form.
In addition, units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.
Furthermore, the functional modules in the embodiments of the present application may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.
In this document, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions.
In this context, a plurality means two or more.
The above description is only an example of the present application and is not intended to limit the scope of the present application, and various modifications and changes may be made by those skilled in the art. Any modification, equivalent replacement, improvement and the like made within the spirit and principle of the present application shall be included in the protection scope of the present application.
Claims (11)
1. A method of monitoring, comprising:
monitoring whether a NET framework module is loaded;
after the NET framework module is loaded, judging whether a dynamic call interface function is called or not;
if the dynamic call interface function is called, comparing the stored deserialization result with an object called by the dynamic call interface function;
and if the deserialization result is the same as the object called by the dynamic call interface function, determining that the dynamic call after the deserialization of the NET occurs.
2. The monitoring method of claim 1, wherein after the. NET framework module is loaded, the method further comprises:
judging whether the deserialization interface function is called or not;
and if the deserialization interface function is called, saving the deserialization result of the deserialization interface function.
3. The monitoring method of claim 2, wherein the deserializing interface function and the function called by the dynamic call interface function bottom layer are the same bottom layer function;
after the.NET framework module is loaded, the method further comprises: monitoring whether the bottom layer function is called; if the bottom function is called, determining a calling number when the bottom function is called;
the judging whether the deserializing interface function is called comprises the following steps:
judging whether the calling number is consistent with a preset calling number of the dynamic calling interface function or not; if the dynamic calling interface function is consistent with the dynamic calling interface function, determining that the dynamic calling interface function is called; otherwise, determining that the dynamic call interface function is not called;
the judging whether the deserializing interface function is called includes:
judging whether the calling number is consistent with the preset calling number of the deserialization interface function or not; if the interface function is consistent with the deserialization interface function, determining that the deserialization interface function is called; otherwise, determining that the deserialization interface function is not called.
4. The monitoring method of claim 3, wherein monitoring whether the underlying function is called comprises:
acquiring a function address of the bottom layer function;
and monitoring whether the bottom layer function is called or not according to the function address.
5. The monitoring method of claim 4, wherein obtaining the function address of the underlying function comprises:
creating NET interface examples;
according to the virtual function table of the NET interface embodiment, calling a NET embodiment object creating function to obtain a NET embodiment object created by the NET embodiment object creating function;
and inquiring the virtual function table of the NET instance object to obtain the function address of the bottom function.
6. A monitoring method in accordance with claim 3, wherein the deserialization interface function is a deseriaize function and the dynamic call interface function is a dynamic invoke function.
7. A monitoring method according to claim 6, characterized in that the call number of the Desriaize function is 0x60020006; the calling number of the dynamic invoke function is 0x60020007.
8. The monitoring method of any one of claims 1-7, wherein the monitoring whether a NET framework module is loaded comprises:
monitoring whether an identifier described in an identifier description parameter of the ntdll derivation function is the name of the NET framework module;
if yes, determining that the NET framework module is loaded;
and if not, determining that the NET framework module is not loaded.
9. A monitoring device, comprising:
the monitoring module is used for monitoring whether the NET framework module is loaded or not;
the judging module is used for judging whether the dynamic calling interface function is called or not when the NET framework module is loaded;
the processing module is used for comparing the stored deserialization result with an object called by the dynamic calling interface function when the dynamic calling interface function is called;
the processing module is further configured to determine that the dynamic call after deserialization of the NET occurs when the deserialization result is the same as the object called by the dynamic call interface function.
10. An electronic device, comprising: a processor and a memory;
the processor is configured to execute one or more programs stored in the memory to implement the monitoring method of any one of claims 1-8.
11. A computer-readable storage medium storing one or more programs, the one or more programs being executable by one or more processors to implement the monitoring method of any one of claims 1-8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210887253.XA CN115186264A (en) | 2022-07-26 | 2022-07-26 | Monitoring method, monitoring device, electronic equipment and computer readable storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210887253.XA CN115186264A (en) | 2022-07-26 | 2022-07-26 | Monitoring method, monitoring device, electronic equipment and computer readable storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN115186264A true CN115186264A (en) | 2022-10-14 |
Family
ID=83522066
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210887253.XA Pending CN115186264A (en) | 2022-07-26 | 2022-07-26 | Monitoring method, monitoring device, electronic equipment and computer readable storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115186264A (en) |
-
2022
- 2022-07-26 CN CN202210887253.XA patent/CN115186264A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20240095043A1 (en) | Execution of sub-application processes within application program | |
| CN107832100B (en) | APK plug-in loading method and terminal thereof | |
| CN110865888B (en) | Resource loading method and device, server and storage medium | |
| TWI715762B (en) | Method and apparatus for creating virtual machine | |
| US20220035655A1 (en) | Method and Device for Anonymous Page Management, Terminal Device, and Readable Storage Medium | |
| WO2021248754A1 (en) | System testing method and apparatus, and storage medium and electronic device | |
| CN110908837B (en) | Application program exception handling method and device, electronic equipment and storage medium | |
| US20160188243A1 (en) | Memory access protection using processor transactional memory support | |
| CN106603125B (en) | Method and device for data interaction with Bluetooth equipment | |
| WO2024078348A1 (en) | Method and apparatus for processing registry operation in application porting environment, and medium | |
| CN103425539B (en) | Information processing method and device | |
| CN110990116B (en) | Method, device and system for transmitting data between intelligent network card and virtual machine | |
| WO2023185335A1 (en) | Crash clustering method and apparatus, electronic device and storage medium | |
| WO2023143545A1 (en) | Resource processing method and apparatus, electronic device, and computer-readable storage medium | |
| US9395987B2 (en) | Method and device for detecting a race condition | |
| CN115186264A (en) | Monitoring method, monitoring device, electronic equipment and computer readable storage medium | |
| WO2020210955A1 (en) | Application program starting method and apparatus, and electronic device and storage medium | |
| CN108062224B (en) | Data reading and writing method and device based on file handle and computing equipment | |
| CN110993014A (en) | Behavior test method and device of SSD in idle state, computer equipment and storage medium | |
| CN112463037B (en) | Metadata storage method, device, equipment and product | |
| CN114490266A (en) | Data acquisition method, device, equipment and storage medium | |
| CN110908644B (en) | Configuration method and device of state node, computer equipment and storage medium | |
| CN114490265A (en) | Data acquisition method, device, equipment and storage medium | |
| CN114356446A (en) | Method, device and equipment for processing inter-process event and storage medium | |
| CN113961366A (en) | Kernel function calling method of operating system and computer equipment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |