CN115220859A - Data input mode monitoring method and device, electronic equipment and storage medium - Google Patents
Data input mode monitoring method and device, electronic equipment and storage medium Download PDFInfo
- Publication number
- CN115220859A CN115220859A CN202110425773.4A CN202110425773A CN115220859A CN 115220859 A CN115220859 A CN 115220859A CN 202110425773 A CN202110425773 A CN 202110425773A CN 115220859 A CN115220859 A CN 115220859A
- Authority
- CN
- China
- Prior art keywords
- function
- data
- input
- virtual key
- window
- 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
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45575—Starting, stopping, suspending or resuming virtual machine instances
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45583—Memory management, e.g. access or allocation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45591—Monitoring or debugging support
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
The embodiment of the application discloses a method and a device for monitoring a data input mode, electronic equipment and a storage medium; the method and the device can monitor the data input mode of the system when the system starting process is detected; in the monitoring process, acquiring a current running process and a current input focus of the system, determining a process to be protected from the current running process, and detecting whether the current input focus is positioned in a window area of the process to be protected; analyzing an execution link of the simulation sending function in the system, and determining an execution path of the simulation sending function on the execution link; acquiring a virtual key code of system input data, and detecting a trigger mode of the input data according to the virtual key code; and determining whether the data input mode of the system has an abnormality or not based on at least one of the position of the current input focus relative to the window area, the execution path and the trigger mode. The scheme effectively improves the safety of the system.
Description
Technical Field
The present application relates to the field of computer technologies, and in particular, to a method and an apparatus for monitoring a data input mode, an electronic device, and a storage medium.
Background
The keyboard is a widely used instruction and data physical input device, and a malicious tool can simulate the keyboard to input instructions or data in a software mode to achieve the effects of violently cracking passwords, automatically operating software and the like without manual intervention, so that the safety of the software and games is greatly threatened. Therefore, it is necessary to detect the data input mode in the system and determine whether the input path of the data is reliable. However, in the prior art, the scheme for detecting the data input mode in the system has a poor detection effect.
Disclosure of Invention
The embodiment of the application provides a method and a device for monitoring a data input mode, electronic equipment and a storage medium, and can effectively improve the safety of a system.
The embodiment of the application provides a method for monitoring a data input mode, which comprises the following steps:
when detecting a system starting process, monitoring a data input mode of the system;
in the monitoring process, acquiring a current running process and a current input focus of a system, determining a process to be protected from the current running process, and detecting whether the current input focus is positioned in a window area of the process to be protected;
analyzing an execution link of an analog sending function in a system, and determining an execution path of the analog sending function on the execution link;
acquiring a virtual key code of system input data, and detecting a trigger mode of the input data according to the virtual key code;
and determining whether the data input mode of the system has an abnormality or not based on at least one of the position of the current input focus relative to the window area, the execution path and the trigger mode.
Correspondingly, the embodiment of the present application further provides a monitoring device for a data input method, including:
the monitoring unit is used for monitoring the data input mode of the system when detecting the starting process of the system;
the system comprises a first detection unit, a second detection unit and a third detection unit, wherein the first detection unit is used for acquiring a current running process and a current input focus of a system in a monitoring process, determining a process to be protected from the current running process, and detecting whether the current input focus is positioned in a window area of the process to be protected;
the second detection unit is used for analyzing an execution link of an analog sending function in the system and determining an execution path of the analog sending function on the execution link;
the third detection unit is used for acquiring a virtual key code of system input data and detecting a trigger mode of the input data according to the virtual key code;
and the determining unit is used for determining whether the data input mode of the system has an abnormality or not based on at least one of the position of the current input focus relative to the window area, the execution path and the trigger mode.
Optionally, in some embodiments, the first detection unit may include an acquisition subunit and a detection subunit, as follows:
the acquisition subunit is configured to start a detection processing thread, and search a current running process of the system using the detection processing thread; acquiring a target process positioned at the top layer of the current desktop of the system from the current running process, and determining the target process as a process to be protected; monitoring the current running process in real time, and acquiring a current input focus of the system when input data is monitored;
the detection subunit is configured to acquire a focus window handle corresponding to the current input focus; comparing the focus window handle with the target window handle, and determining whether the focus window handle is equal to the target window handle according to a comparison result; if the focus window handle is equal to the target window handle, determining that the current input focus is located in a window area of the process to be protected; and if the focus window handle is not equal to the target window handle, determining that the current input focus is not located in a window area of the process to be protected.
Optionally, in some embodiments, the obtaining subunit is specifically configured to obtain, by using the detection processing thread, a target window handle of the program to be protected; reverse searching is carried out based on the target window handle, and the memory address of the window processing function where the target window handle is located is obtained; analyzing a subclass window processing function in the window processing function based on the memory address, and determining all window class data in the subclass window processing function; monitoring target data in all window class data by using a preset window message processing function, wherein the target data is data input through input equipment; and when the target data is monitored, acquiring the current input focus of the system.
Optionally, in some embodiments, the second detecting unit may be specifically configured to perform hooking processing on the simulated message sending function through a preset hooking function; stack backtracking is carried out on the simulated message sending function to obtain a father function address of the simulated message sending function; determining a target running process corresponding to the parent function address from a current running process of the system; and acquiring an execution path of a function calling the target running process, and acquiring the execution path of the simulation sending function on an execution link.
Optionally, in some embodiments, the second detection unit may be specifically configured to acquire a register value of the simulated transmission message function; acquiring an instruction execution address returned by a calling function according to the register value, wherein the calling function is a function for calling the message simulating and sending function; determining an instruction machine code based on the instruction execution address, and calculating a call instruction address based on the instruction machine code; and determining a calling machine code based on the calling instruction address, and calculating based on the calling machine code to obtain a parent function address of the simulated message sending function.
Optionally, in some embodiments, the second detecting unit may be specifically configured to continue to execute the simulated message sending function if the execution path meets a preset rule; and if the execution path does not accord with the preset rule, punishing the simulation message sending function.
Optionally, in some embodiments, the third detecting unit may include a hooking subunit, a storing subunit, a searching subunit, and an analyzing subunit, as follows:
the hook subunit is used for hooking the message sending function and the message receiving function in the system through a preset hook function;
the storage subunit is configured to acquire the virtual key code and the boot millisecond number of the transmission data from the message transmission function, and store the virtual key code and the boot millisecond number of the transmission data in a preset array list;
the searching subunit is configured to obtain the virtual key code and the boot millisecond number of the received input data from the message receiving function, traverse the numerical value list, and search the virtual key code of the input data in the numerical value list;
the analysis subunit is configured to, if the virtual key code of the input data exists in the numerical value list, analyze the boot millisecond number of the input data, and determine whether the input data is triggered by a virtual key of the system according to an analysis result.
Optionally, in some embodiments, the storage subunit may be specifically configured to, when the message sending function receives data, obtain all sending data from the message sending function; if the sending data is data input through input equipment, acquiring a virtual key code and a starting-up millisecond number corresponding to the sending data from the message sending function; and combining the virtual key code corresponding to the sending data and the starting millisecond array into a sending array item, storing the sending array item into a preset array list, and continuously executing the message sending function.
Optionally, in some embodiments, the searching subunit may be specifically configured to, when the message receiving function receives data, obtain all input data from the message receiving function; if the input data are data input through input equipment, acquiring a virtual key code and a starting-up millisecond number corresponding to the input data from the message receiving function; combining the virtual key code corresponding to the input data and the starting millisecond array into a receiving array item; traversing the numerical value list, and searching the received array items in the numerical value list, if the virtual key of the input data exists in the numerical value list, the method includes: if the received array entries exist in the numerical list.
Optionally, in some embodiments, the analyzing subunit is specifically configured to, if the received array item exists in the array list, analyze the number of milliseconds of starting up in the received array item, and determine, according to an analysis result, whether the received array item is called by an internal analog virtual key of the system; if the received array item is the internal simulation virtual key call of the system, determining the triggering mode of the input data as the virtual key triggering of the system, and continuing to execute the message receiving function; and if the received array item is not called by the internal simulation virtual key of the system, determining that the triggering mode of the input data is not triggered by the virtual key of the system, punishing the input data, and continuously executing the message receiving function.
In addition, a computer-readable storage medium is provided, where multiple instructions are stored, and the instructions are suitable for being loaded by a processor to perform the steps in the monitoring method for any data input method provided in the embodiments of the present application.
In addition, an electronic device is further provided in an embodiment of the present application, and includes a memory, a processor, and a computer program stored on the memory and executable on the processor, where the processor executes the computer program to implement the steps in the monitoring method according to any one of the data input methods provided in the embodiment of the present application.
According to an aspect of the present application, there is provided a computer program product or computer program comprising computer instructions stored in a computer-readable storage medium, the computer instructions being read by a processor of a computer device from the computer-readable storage medium, the computer instructions being executable by the processor to cause the computer device to perform the method provided in the various alternative implementations of the monitoring aspect of the data input approach described above.
The embodiment can monitor the data input mode of the system when detecting the starting process of the system; in the monitoring process, acquiring a current running process and a current input focus of a system, determining a process to be protected from the current running process, and detecting whether the current input focus is positioned in a window area of the process to be protected; analyzing an execution link of a simulation sending function in a system, and determining an execution path of the simulation sending function on the execution link; acquiring a virtual key code of system input data, and detecting a trigger mode of the input data according to the virtual key code; and determining whether the data input mode of the system has an abnormality or not based on at least one of the position of the current input focus relative to the window area, the execution path and the trigger mode. The scheme can effectively improve the safety of the system.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.
Fig. 1a is a schematic view of a scene of a monitoring method for a data input mode according to an embodiment of the present application;
FIG. 1b is a first flowchart of a method for monitoring data input mode provided by an embodiment of the present application;
FIG. 2a is a second flowchart of a method for monitoring data input provided by an embodiment of the present application;
FIG. 2b is a third flowchart of a method for monitoring data input mode provided by the embodiment of the present application;
FIG. 2c is a fourth flowchart of a method for monitoring data input manner according to an embodiment of the present disclosure;
fig. 2d is a fifth flowchart of a monitoring method of a data input mode according to an embodiment of the present application;
FIG. 3 is a schematic structural diagram of a monitoring device for data input 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 clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments obtained by a person skilled in the art based on the embodiments in the present application without making any creative effort belong to the protection scope of the present application.
The principles of the present application are illustrated as being implemented in a suitable computing environment. In the description that follows, specific embodiments of the present application will be described with reference to steps and symbols executed by one or more computers, unless otherwise indicated. Accordingly, these steps and operations will be referred to, several times, as being performed by a computer, the computer performing operations involving a processing unit of the computer in electronic signals representing data in a structured form. This operation transforms the data or maintains it at locations in the computer's memory system, which may be reconfigured or otherwise altered in a manner well known to those skilled in the art. The data maintains a data structure that is a physical location of the memory that has particular characteristics defined by the data format. However, while the principles of the application have been described in language specific to above, it is not intended to be limited to the specific form set forth herein, and it will be recognized by those of ordinary skill in the art that various of the steps and operations described below may be implemented in hardware.
The term "unit" as used herein may be considered a software object executing on the computing system. The various components, units, engines, and services described herein may be considered as objects implemented on the computing system. The apparatus and method described herein may be implemented in software, or may be implemented in hardware, and are within the scope of the present application.
The terms "first", "second", and "third", etc. in this application are used to distinguish between different objects and not to describe a particular order. Furthermore, the terms "include" and "have," as well as any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, article, or apparatus that comprises a list of steps or elements is not limited to only those steps or elements recited, but rather, some embodiments include additional steps or elements not recited, or other steps or elements inherent to such process, method, article, or apparatus.
Reference herein to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the application. The appearances of the phrase in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. It is explicitly and implicitly understood by one skilled in the art that the embodiments described herein can be combined with other embodiments.
The embodiment of the application provides a method and a device for monitoring a data input mode, electronic equipment and a storage medium. The monitoring device of the data input mode can be integrated in electronic equipment, and the electronic equipment can be a server or a terminal and the like.
For example, as shown in fig. 1a, first, the electronic device integrated with the monitoring apparatus for data input mode may monitor the data input mode of the system when detecting a system start process; in the monitoring process, acquiring a current running process and a current input focus of a system, determining a process to be protected from the current running process, and detecting whether the current input focus is positioned in a window area of the process to be protected; analyzing an execution link of an analog sending function in a system, and determining an execution path of the analog sending function on the execution link; acquiring a virtual key code of system input data, and detecting a trigger mode of the input data according to the virtual key code; and determining whether the data input mode of the system has an abnormality or not based on at least one of the position of the current input focus relative to the window region, the execution path and the trigger mode. According to the scheme, whether the current input focus is located in a window area of the process to be protected or not can be detected, the execution path of the simulation sending function on the execution link is analyzed, and the triggering mode of the input data is determined according to the virtual key code, so that the global process of the system is accurately and effectively detected, the detection effect is greatly enhanced, the reliability of the data input path is ensured, the safety of the system is improved, and the safety of system software is better protected. The scheme simplifies the detection of the data input mode of the system, saves resources and effectively reduces the running pressure of a Central Processing Unit (CPU).
The following are detailed below. It should be noted that the following description of the embodiments is not intended to limit the preferred order of the embodiments.
In this embodiment, a data input mode monitoring device is described, where the data input mode monitoring device may be specifically integrated in an electronic device, and the electronic device may be a server or a terminal; the terminal may include a mobile phone, a tablet Computer, a notebook Computer, and a Personal Computer (PC).
A method for monitoring a data input mode comprises the following steps: when detecting a system starting process, monitoring a data input mode of the system; in the monitoring process, acquiring a current running process and a current input focus of a system, determining a process to be protected from the current running process, and detecting whether the current input focus is positioned in a window area of the process to be protected; analyzing an execution link of an analog sending function in a system, and determining an execution path of the analog sending function on the execution link; acquiring a virtual key code of system input data, and detecting a trigger mode of the input data according to the virtual key code; and determining whether the data input mode of the system has an abnormality or not based on at least one of the position of the current input focus relative to the window area, the execution path and the trigger mode.
As shown in fig. 1b, the specific process of the monitoring method of the data input mode may be as follows:
101. and when detecting the system starting process, monitoring the data input mode of the system.
The system may refer to an operating system of the electronic device, among others. An Operating System (OS) of an electronic device is a computer program that manages computer hardware and software resources. The operating system needs to handle basic transactions such as managing and configuring memory, prioritizing system resources, controlling input devices and output devices, operating networks, and managing file systems. The operating system may provide an operator interface for a user to interact with the system. The data input mode may include keyboard input, simulated keyboard input, and/or non-physical keyboard input, etc.
For example, in the field of computer-related technologies, especially in the field of software clients, some known ways to simulate a physical keyboard by software are as follows:
1. the malicious tool issues an input message input by the keyboard to a specific input window of target software through a message distribution API of an operating system, such as PostMessage and SendMessage of Windows, and the target input window does not need to be positioned at the top layer of a visible desktop (in an actual normal operating environment, the target input window needs to be positioned at the top layer of the desktop to respond and process the input from the physical keyboard);
2. the malicious tool finally performs keyboard input simulation by calling NtUserSendInput through DLL injection, API hijacking, DLL hijacking and other modes, and sends data and instructions to a specific window, but requires a target input window to be arranged on the top layer of a desktop before the instructions are sent;
the DLL is a Dynamic Link Library and is an abbreviation of Dynamic Link Library. A DLL is a library that contains code and data that can be used by multiple programs simultaneously. The NtUserSendInput is a bottom-layer function of Windows and can simulate and send keyboard messages to the inside of an operating system;
3. and performing keyboard input simulation at a driving level through a driver of a virtual keyboard such as WINIO (Windows input) and the like, wherein the target input window does not need to be positioned at the top layer of the visible desktop.
For the above simulated keyboard input mode, the detection and penalty can be performed through the following specific steps.
102. In the monitoring process, the current running process and the current input focus of the system are obtained, the process to be protected is determined from the current running process, and whether the current input focus is located in a window area of the process to be protected is detected.
Where entering focus may refer to passively waiting for user information in a message-oriented system. For example, in the Windows system, the application program can only passively wait for the message of the user pressing the key, and cannot actively read the state of the keyboard, that is, each time a key on the keyboard is pressed, the system sends a key message to the window to tell it that a certain key is pressed, and as long as the mouse moves, the system also sends a corresponding message and transmits the coordinate information of the mouse to the window. Among them, a Process (Process) is a running activity of a program in a computer on a certain data set, is a basic unit for a system to perform resource allocation and scheduling, and is the basis of an operating system structure. A currently running process may refer to an application that is currently running in the system. An application program may also be referred to as a program for short. The process to be protected may refer to a main program running in the system, i.e., a process located on the top layer of the current desktop, and the process to be protected may include one or more processes, i.e., the top layer of the current desktop may display one or more applications.
Wherein a window may refer to a basic unit that an application sets in a graphical user interface for using data. Applications and data can be integrated within a window. In the window, the user can operate the application program in the window to manage, generate and edit data. Usually, a menu and an icon are arranged around the window, and data is placed in the center. The window interface may refer to a window form for displaying a computer operation user interface, and may also be referred to as a window area. The window area of the process to be protected may also refer to an area in which the process to be protected is displayed in the form of a window.
To prevent system processes from being aborted during the performance of the detection, the detection may be performed by additional low-level threads. For example, a detection processing thread may be specifically started, the detection processing thread is used to search for a current running process of the system, an object process located on the top layer of a current desktop of the system is obtained from the current running process, the object process is determined as a process to be protected, the current running process is monitored in real time, when input data is monitored, a current input focus of the system is obtained, and whether the current input focus is located in a window area of the process to be protected is detected. By adding a thread of a low level (i.e. a detection processing thread), the thread can be effectively prevented from being abnormally terminated when the detection is performed.
Optionally, in an embodiment, the current running process is monitored in real time, when input data is monitored, a current input focus of a system is obtained, specifically, the detection processing thread may be used to obtain a target window handle of the program to be protected, reverse lookup is performed based on the target window handle to obtain a memory address of a window processing function where the target window handle is located, a subclass window processing function in the window processing function is analyzed based on the memory address, and all window class data in the subclass window processing function is determined; and monitoring target data in all window class data by using a preset window message processing function, wherein the target data is input through input equipment, and acquiring the current input focus of the system when the target data is monitored.
The Handle (Handle) is an identifier for identifying an object or an item, and may be used to describe a form, a file, or the like, but the Handle cannot be a constant. For example, setting up a handle in the Windows operating system basically results from a problem of the memory management mechanism, i.e., a virtual address. That is, the address of the data needs to be changed, and the change needs to be recorded and managed by someone after the change. In programming, a handle is a special smart pointer, which is used when an application references a memory block or object managed by another system (e.g., a database, an operating system). Similar in other systems. For example, a handle may be a 32-bit number representing an object, a program may obtain the handle by calling a Windows function in which the handle is referenced to reference the object it represents, the actual value of the handle is irrelevant to the program, but the Windows module knows how to use it to reference the corresponding object. A window handle may refer to an identifier of the window.
For example, in Windows, a handle is a reference to a data structure within the system. For example, when you manipulate a window, or a Delphi form, the system gives you a handle to the window and the system informs you: you are operating window 142, at which point your application can ask the system to do an operation on window 142 — move the window, change the window size, minimize the window, and so on. In fact, many Windows API functions have a handle as its first parameter, such as a GDI (graphics device interface) handle, a menu handle, an instance handle, a bitmap handle, etc., and are not limited to window functions. That is, a handle is an internal code through which special elements under the control of the system can be referenced, such as windows, bitmaps, icons, memory blocks, cursors, fonts, menus, etc.
The preset window message processing function may refer to a function preset in the system for processing window messages, for example, one window message processing function may be predefined to take over all window-class messages.
Optionally, in an embodiment, the detecting whether the current input focus is located in a window region of a process to be protected may specifically obtain a focus window handle corresponding to the current input focus; comparing the focus window handle with the target window handle, and determining whether the focus window handle is equal to the target window handle according to a comparison result; if the focus window handle is equal to the target window handle, determining that the current input focus is located in a window area of the process to be protected; and if the focus window handle is not equal to the target window handle, determining that the current input focus is not located in a window area of the process to be protected.
103. And analyzing an execution link of the simulation sending function in the system, and determining an execution path of the simulation sending function on the execution link.
For example, the simulated message sending function may be hooked specifically by a preset hooking function; stack backtracking is carried out on the simulated message sending function to obtain a father function address of the simulated message sending function; determining a target running process corresponding to the parent function address from a current running process of the system; and acquiring an execution path of a function calling the target running process, and acquiring the execution path of the simulation sending function on an execution link.
The hooking may also be referred to as hanging, hooking, and the hooking process may refer to temporary non-execution, for example, hooking (hook dropping) a simulated sending message function through a preset hooking function may refer to temporary non-execution of logic of the simulated sending message function, where the preset hooking function may specifically include an inline hook (inline hook) function, and the inline hook function mainly refers to "touching" an entry point of a function to be modified (i.e., the simulated sending message function) through hook and temporarily does not execute the simulated sending message function.
Optionally, a current running process of the system is obtained, specifically, a process snapshot may be performed on the operating system, so as to obtain the current running process of the operating system; and traversing the current running process, and determining a target running process corresponding to the parent function address. The process snapshot may refer to a function that establishes a snapshot by acquiring process information as a specified process, a HEAP [ HEAP ] used by the process, a MODULE [ MODULE ], and a thread, that is, may acquire process information and thread information that are running in the system, and the like.
Wherein, the simulated sending message function may refer to a function that simulates sending an input device message into the operating system. An input device (InputDevice) may refer to a device that inputs data and information to a computer, which is the bridge between the computer and a user or other device. An input device is one of the primary means by which information is exchanged between a user and a computer system. For example, a keyboard, a mouse, a camera, a scanner, a light pen, a handwriting input board, a joystick, a voice input device, and the like all belong to the input devices. An input device is a device that a person or the outside interacts with a computer for inputting raw data and programs for processing these numbers into the computer. The computer can receive various data, such as numerical data or various non-numerical data, and the graphics, images, sounds, etc. can be input into the computer through different types of input devices for storage, processing and output. For example, the function of simulating sending a message in the Windows operating system may refer to a function of simulating sending a keyboard message to the inside of the Windows operating system, such as an ntuser sendinput function.
The stack backtracking is a backtracking method and is a search algorithm with systematicness and jumping. In the solution space tree containing all solutions of the problem, the solution space tree is searched from a root node according to a depth-first strategy. When the algorithm searches any node of the solution space tree, whether the node definitely does not contain the solution of the problem is always judged firstly. If the node does not contain the node, skipping the systematic search of the subtree taking the node as the root, and tracing back to the ancestor node layer by layer. Otherwise, entering the subtree and continuing to search according to the depth-first strategy. The backtracking method is used to find all solutions to the problem, and it is only completed after all subtrees of the root node are searched. When the backtracking method is used for solving any solution of the problem, the backtracking method can be ended only by searching one solution of the problem. This algorithm, which systematically searches for solutions to problems in a depth-first manner, is called backtracking, and is suitable for solving some problems with a large number of combinations.
For example, the parent function address can be obtained by performing stack backtracking on the simulated message sending function and performing disassembly analysis on the stack backtracking by using a disassembly engine, wherein stack spoofing check can be performed during analysis to prevent the obtained function address from being wrong, so that the accuracy of data input mode detection is improved.
Optionally, in an embodiment, the stack backtracking is performed on the simulated message sending function to obtain a parent function address of the simulated message sending function, and specifically an Extended Base Pointer (EBP) value of the simulated message sending function may be obtained; acquiring an instruction execution address returned by a calling function according to the register value, wherein the calling function is a function for calling the message simulating and sending function; determining an instruction machine code based on the instruction execution address, and calculating a call instruction address based on the instruction machine code; and determining a calling machine code based on the calling instruction address, and calculating based on the calling machine code to obtain a parent function address of the simulated message sending function.
Optionally, after obtaining an execution path of a function calling the target running process, that is, after determining an execution path of the simulated sending function on an execution link, it may also be determined whether the execution path meets a preset rule, and if the execution path meets the preset rule, the simulated sending message function continues to be executed; if the execution path does not meet the preset rule, punishing the simulation message sending function, for example, filtering the execution path that does not meet the preset rule, and the like.
The preset rule may be set in various ways, for example, the preset rule may be flexibly set according to the requirements of the actual application, or may be preset and stored in the electronic device. In addition, the preset rule may be built in the electronic device, or may be saved in the memory and transmitted to the electronic device, and so on.
104. And acquiring a virtual key code of system input data, and detecting a trigger mode of the input data according to the virtual key code.
For example, a message sending function and a message receiving function in the system may be hooked specifically by a preset hooking function; acquiring a virtual key code and a startup millisecond number of sending data from the message sending function, and storing the virtual key code and the startup millisecond number of the sending data into a preset array list; acquiring the virtual key code and the starting-up millisecond number of the received input data from the message receiving function, traversing the numerical value list, and searching the virtual key code of the input data in the numerical value list; if the virtual key code of the input data exists in the numerical value list, analyzing the starting-up millisecond number of the input data, and determining whether the input data is triggered by the virtual key of the system or not according to the analysis result.
The message sending function, i.e. the message distributing function, may refer to a function responsible for issuing a keyboard message. The message reception function, i.e., the message management function, may refer to a function that manages the keyboard message re-decision process.
The virtual key code is a mapping from a keyboard scan to the virtual key code, which is established to solve the problem that different keyboard manufacturers produce keyboards in different arrangement or scan modes (namely, the conversion from the keyboard scan to the virtual key code is realized). Related functions are used in the simulated keyboard program, and some steps are to convert normal ASCII or other characters into virtual keys. VkKeyScan is used to convert characters into virtual key codes. Windows developers can process the keyboard in a device independent manner through the defined virtual key codes. Most of the names of virtual keys are defined in the winuser.h header file as beginning with VK _ and the numeric and alphabetic virtual keys are ASCII codes. The virtual key may be stored in the wParam parameter of the WM _ KEYDOWN, WM _ KEYUP, WM _ SYSKEYDOWN, and WM _ syskeyou messages. This code identifies the key that is pressed or released. For example, the partial corresponding keys of the virtual key code may be as shown in the following table one:
watch 1
Where the number of milliseconds of booting may refer to the number of milliseconds the system begins with booting. The acquisition and storage of the time can be used for verifying and judging whether the input data is input by a real input device, such as a keyboard and mouse input. The storage and acquisition of the time can be used for verifying and judging whether the real keyboard and mouse input exists, for example, the time difference between two times of normal human normal keyboard operation is at least 50 milliseconds, if the input is not normal human input, 1 millisecond can be sent for several times, and thus whether the input is normal input is judged.
Optionally, in an embodiment, the virtual key and the boot millisecond of the sending data are obtained from the message sending function, and the virtual key and the boot millisecond of the sending data are stored in a preset array list, and specifically, when the message sending function receives data (that is, when the message sending function is called by receiving data transfer), all the sending data are obtained from the message sending function; if the sending data is data input through input equipment, acquiring a virtual key code and a starting-up millisecond number corresponding to the sending data from the message sending function; and combining the virtual key code corresponding to the sending data and the startup millisecond array into a sending array item, storing the sending array item into a preset array list, and continuously executing the message sending function.
Optionally, in an embodiment, the virtual key and the boot millisecond number of the received input data are obtained from the message receiving function, and the value list is traversed to search for the virtual key of the input data in the value list, and specifically, when the message receiving function receives data (i.e., when the received data is transferred to call the message receiving function), all the input data are obtained from the message receiving function; if the input data are data input through input equipment, acquiring a virtual key code and a starting-up millisecond number corresponding to the input data from the message receiving function; combining the virtual key code corresponding to the input data and the starting millisecond array into a receiving array item; and traversing the numerical value list, and searching the receiving array items in the numerical value list.
Optionally, in an embodiment, if the virtual key code of the input data exists in the numerical value list, analyzing the startup millisecond number of the input data, and determining whether the input data is triggered by a virtual key of a system according to an analysis result, specifically, if the array list has the received array item, analyzing the startup millisecond number of the received array item, and determining whether the received array item is called by an internal simulation virtual key of the system according to the analysis result; if the received array item is called by a simulated virtual key in the system, determining that the triggering mode of the input data is triggered by the virtual key of the system, and continuing to execute the message receiving function; and if the received array item is not called by the internal simulation virtual key of the system, determining that the triggering mode of the input data is not triggered by the virtual key of the system, punishing the input data, and continuously executing the message receiving function.
105. And determining whether the data input mode of the system has an abnormality or not based on at least one of the position of the current input focus relative to the window area, the execution path and the trigger mode.
For example, if the current input focus is not located in a window area of the process to be protected, and/or the execution path does not conform to a preset rule, and/or the triggering mode is not triggered by a virtual key of the system, it is determined that the data input mode of the system is abnormal.
For example, it may be specifically determined that the data input mode of the system is abnormal and corresponding penalty is executed, for example, exiting the process to be protected and the like, if it is detected that the current input focus is not located in the window area of the process to be protected. If the acquired execution path does not accord with the preset rule, it is determined that the data input mode of the system is abnormal, a module where the API is called and a full path of the executable program can be reported, and a delay analysis penalty is reported to a server background, for example, the execution path is filtered. And if the triggering mode is not triggered by the virtual key of the system, determining that the data input mode of the system is abnormal, and determining whether to perform penalty according to specific rules by combining the former two conditions.
In the above three detection data input modes, as long as one or more of the detection data input modes detect an abnormality, which indicates that the current data input mode of the system is abnormal, a penalty may be applied to the process corresponding to the abnormal data input mode, for example, the abnormal process exits, or the abnormal process is prevented from being executed, and so on.
In specific implementation, the three manners (i.e. 102, 103, and 104) for detecting whether the data input manner is abnormal are not specifically limited in sequence, and may be performed simultaneously, sequentially, or any one of the manners may be performed first, and the like, and are not limited herein.
Therefore, the data input mode of the system can be monitored when the system starting process is detected; in the monitoring process, acquiring a current running process and a current input focus of a system, determining a process to be protected from the current running process, and detecting whether the current input focus is positioned in a window area of the process to be protected; analyzing an execution link of a simulation sending function in a system, and determining an execution path of the simulation sending function on the execution link; acquiring a virtual key code of system input data, and detecting a trigger mode of the input data according to the virtual key code; and determining whether the data input mode of the system has an abnormality or not based on at least one of the position of the current input focus relative to the window region, the execution path and the trigger mode. According to the scheme, whether the current input focus is located in a window area of the process to be protected or not can be detected, the execution path of the simulation sending function on the execution link is analyzed, and the triggering mode of the input data is determined according to the virtual key code, so that the global process of the system is accurately and effectively detected, the detection effect is greatly enhanced, the reliability of the data input path is ensured, the safety of the system is improved, and the safety of system software is better protected. The scheme simplifies the detection of the data input mode of the system, saves resources and effectively reduces the operating pressure of the central processing unit.
The method described in the previous embodiment is further detailed by way of example.
In this embodiment, the monitoring apparatus of the data input method is specifically integrated in an electronic device, and the electronic device may be a computer of a Windows operating system.
As shown in fig. 2a, a specific process of a monitoring method for data input mode may be as follows:
201. and when detecting the system starting process, the electronic equipment monitors the data input mode of the system.
For example, the electronic device may specifically monitor the input modes of all data input to the operating system of the electronic device after being started (e.g., powered on).
202. In the monitoring process, the electronic equipment acquires the current running process and the current input focus of the system, and determines a process to be protected from the current running process.
For example, the electronic device may specifically start a detection processing thread, search a current running process of the system using the detection processing thread, obtain a target process located at a top layer of a current desktop of the system from the current running process, determine the target process as a process to be protected, and obtain a target window handle of the program to be protected using the detection processing thread, for example, the system may maintain a low-level thread, periodically enumerate and search windows and windows of all programs of the current desktop through a timer, and store a handle of a Root window of the process to be protected (which may be a target application program to be protected). Then, reverse lookup is performed based on the target window handle to obtain the memory address of the window processing function where the target window handle is located, for example, according to the obtained Root window handle, the memory address of the window processing function where the target window handle of the process to be protected is located is obtained through handle reverse lookup. Then, analyzing a subclass window processing function in the window processing function based on the memory address, and determining all window class data in the subclass window processing function; monitoring target data in all window class data by using a preset window message processing function, wherein the target data is data input through an input device, acquiring a current input focus of a system when the target data is monitored, for example, processing the subclass window processing function, taking over all window class messages by using a self-defined window message processing function, processing window messages related to a keyboard in the self-defined window message processing function, and acquiring a focus window handle of the current input focus in real time.
Root is a super administrator user account in the Linux system, and the account has the highest authority of the whole system and can conveniently delete or change components of the system.
203. And the electronic equipment detects whether the current input focus is positioned in a window area of the process to be protected or not, and if the current input focus is not positioned in the window area of the process to be protected, the data input mode of the system is determined to be abnormal.
For example, the electronic device may specifically obtain a focus window handle corresponding to the current input focus; comparing the focus window handle with the target window handle, determining whether the focus window handle is equal to the target window handle according to the comparison result, if so, determining that the current input focus is located in the window area of the process to be protected, and if not, determining that the current input focus is not located in the window area of the process to be protected. For example, if the handle of the window or the window where the current input focus is located is not equal to the Root window handle of the target application program to be protected, it is determined that the current input mode is abnormal, data recording is performed, and a corresponding penalty (for example, exit from the target program or the like) is executed, and a specific flow may be as shown in fig. 2 b.
For example, as shown in fig. 2b, a subclassing window process, for example, may start a low-level thread, traverse all windows of the desktop, obtain a target window handle (i.e., a window handle of a process to be protected), and then obtain a target window process function, so as to implement a subclassing window process. After the process of subclassing the window is realized, the message input into the window in real time can be detected. B. A new window process, when a message is transmitted into the system, all messages of a target (namely all window messages) can be obtained, then whether all messages of the target are key and mouse messages (namely messages input by input equipment such as a keyboard and a mouse) is judged, if all messages of the target are key and mouse messages, a focus window handle is obtained, whether the focus window handle is equal to the target window handle is judged, if the focus window handle is not equal to the target window handle, the system is reported for punishing, and if the focus window handle is equal to the target window handle, a native window process is executed; and if all the messages of the target are not the keyboard and mouse messages, executing a native window process.
204. The electronic equipment analyzes an execution link of the analog sending function in the system and determines an execution path of the analog sending function on the execution link.
For example, the electronic device may specifically perform hooking processing on the simulated message sending function through a preset hooking function; stack backtracking is carried out on the simulated message sending function to obtain a father function address of the simulated message sending function; performing process snapshot on the operating system to obtain a current running process of the operating system; traversing the current running process, and determining a target running process corresponding to the parent function address; and acquiring an execution path of a function calling the target running process to obtain the execution path of the simulation sending function on an execution link. For example, the electronic device performs inline hook processing on the ntussendseinput function, then performs stack backtracking on an original address of the ntussendsendinput, performs disassembly analysis on the stack backtracking by using a disassembly engine, and acquires a parent function address, where stack spoofing check is performed during analysis to prevent an acquired function address from being wrong. And carrying out process snapshot on the system once, enumerating the current running process of the system, traversing all the current running processes, obtaining the module name and the module full path of the calling function address of the previous time, and reporting the module name and the module full path to a server background for analysis.
Optionally, in an embodiment, the electronic device may specifically obtain a register value of the simulated sending message function; acquiring an instruction execution address returned by a calling function according to the register value, wherein the calling function is a function for calling the message simulating and sending function; determining an instruction machine code based on the instruction execution address, and calculating a call instruction address based on the instruction machine code; and determining a calling machine code based on the calling instruction address, and calculating based on the calling machine code to obtain a parent function address of the simulated message sending function.
205. And the electronic equipment detects whether the execution path accords with a preset rule, and if the execution path does not accord with the preset rule, the data input mode of the system is determined to be abnormal.
For example, a filtering operation is performed in a preset hook function according to an analysis result, and then whether to perform an original NtUserSendInput function is determined according to the result. According to the method, through hook processing and stack backtracking of the NtUserSendInput, the module where the API is located and the full path of the executable program are called, and the delay analysis penalty of the background of the server is reported.
For example, if the module name and the module full path corresponding to the execution path meet a preset rule, the simulation message sending function is continuously executed; if the module name and the module full path corresponding to the execution path do not meet the preset rule, filtering the simulation message sending function, and the specific flow may be as shown in fig. 2 c.
The preset rule may be set in various ways, for example, the preset rule may be flexibly set according to the requirements of the actual application, or may be preset and stored in the electronic device. In addition, the preset rule may be built in the electronic device, or may be saved in the memory and transmitted to the electronic device, and so on. For example, the execution path may be set to c: \11111\2222.Dll is rejected, the primitive function is not executed, and c: \33333\4444.Dll is released, the primitive function is executed.
For example, as shown in fig. 2c, a notusersendsendinput function may be hooked, an EBP is introduced, an asm stack backtracking procedure is performed to obtain a previous function call address, all processes are traversed, whether the previous function call address is in the current process is determined, if the previous function call address is in the current process, a module name/path of the previous function call address is obtained, the module name/path is reported to a server background for analysis, a filtering action is performed in a preset hook function according to an analysis result, and then whether an original notusersendsendinput function is performed is determined according to the result.
206. The electronic device obtains a virtual key code of system input data.
For example, the electronic device may specifically perform hooking processing on a message sending function and a message receiving function in the system through a preset hooking function. For example, the electronic device may perform hook processing on a message distribution function and a message management function known to the system, generate a hash table (HashTable) T (i.e., create a preset array list), and store a value [ vkKey, boot millisecond number ], in units of columns, and map the corresponding memory as a key.
When the message sending function receives data, all the sending data are obtained from the message sending function; if the sending data is data input through input equipment, acquiring a virtual key code and a starting-up millisecond number corresponding to the sending data from the message sending function; and combining the virtual key code corresponding to the sending data and the startup millisecond array into a sending array item, storing the sending array item into a preset array list, and continuously executing the message sending function. For example, the following processing can be implemented in tramcoline of the hook message distribution function: (1) Acquiring a keyboard virtual key (vkKey) obtained from a message distribution function; (2) And storing the key value of the memory address of the value [ vkKey, starting millisecond number ] in a table T.
Among other things, trampoline may provide a Web console to start, stop, and monitor applications. TrampolineHook is actually a central redirection framework. It may be a framework for replacing/intercepting all wanted functions by one function. Trampoline is usually associated with a jump, and may be a specific address pointing to a specific function, and after the function is executed, the Trampoline jumps out of the Trampoline and returns to a normal execution path.
When the message receiving function receives data, all input data are obtained from the message receiving function; if the input data is data input through input equipment, acquiring a virtual key code and a starting-up millisecond number corresponding to the input data from the message receiving function; combining the virtual key code corresponding to the input data and the starting millisecond array into a receiving array item; and traversing the numerical value list, and searching the receiving array items in the numerical value list. For example, the following processing can be implemented in Trampoline accepted by hook's message: (1) Obtaining a keyboard virtual key (vkKey) from a message management function (2) recursively checking data in the T-table for the presence of the virtual key.
207. And the electronic equipment detects the triggering mode of the input data according to the virtual key code, and if the triggering mode is not triggered by the virtual key of the system, the data input mode of the system is determined to be abnormal.
For example, the electronic device may specifically analyze the number of boot milliseconds in the received array items if the received array items exist in the array list, and determine whether the received array items are called by the internal simulated virtual key of the system according to an analysis result; if the received array item is called by a simulated virtual key in the system, determining that the triggering mode of the input data is triggered by the virtual key of the system, and continuing to execute the message receiving function; if the received array item is not called by the internal simulated virtual key of the system, determining that the triggering mode of the input data is not triggered by the virtual key of the system, punishing the input data, continuing to execute the message receiving function, for example, if the input data exists, indicating that the keyboard content comes from the process to be protected, and determining whether to punish according to specific rules by combining steps 202, 203, 204 and 205. The specific process may be as shown in fig. 2 d.
For example, as shown in fig. 2d, a sending module may hook all message sending functions first, obtain all messages of a target (i.e., all sent messages) when the message sending functions receive a message incoming, then determine whether all messages of the target are keymouse messages (i.e., messages input through an input device such as a keyboard and a mouse), obtain a virtual key code (virtual vkKey) of the keyboard if all messages of the target are keymouse messages, obtain a current time, combine the virtual vkKey and the current time to obtain a combined data item, traverse an array list, insert the combined data item into the array list to update the array list (e.g., automatically update the botttom and top according to the current time and insert a new item into the top), execute a native message sending function (i.e., a message sending function that all messages of the target originally need to be executed), and execute the native message sending function if all messages of the target are not keymouse messages.
B. A receiving module, which can hook all message receiving functions first, and when the message receiving functions receive messages and transmit messages, obtain all messages of a target (i.e. all received messages), then judge whether all messages of the target are keyboard and mouse messages (i.e. messages input by input devices such as a keyboard and a mouse), if all messages of the target are keyboard and mouse messages, obtain a virtual key code (virtual vkKey) of the keyboard, obtain a current time, combine the virtual vkKey and the current time to obtain a combined data item, then traverse an array list, query whether the combined data item exists in the array list, i.e. whether the virtual vkKey is in an effective area (e.g. whether the virtual vkKey exists in the effective area according to the current time), and if the virtual vkKey is in the effective area, confirm that the combined data item is called by an internal simulation key, and execute a native message receiving function (i.e. a message receiving function that all messages of the target originally need to be executed); and if all the messages of the target are not the keyboard and mouse messages, executing a native message receiving function.
For example, the array list may be a 256 array list, the valid area may be 10s data, and the steel core array list may be inserted cyclically.
In a specific implementation, the detection performed in the above steps is not limited to be performed in a specific order, and may be performed simultaneously, sequentially, or any one of the steps may be performed first, and the like, which is not limited herein.
It should be noted that the scheme can be applied to any client product, and is used for detecting whether the client receives input from the non-physical keyboard in the password input box, whether other input boxes receive input from the non-physical keyboard, and whether the client is in a state of automatically executing input operation in a circulating manner, and user interaction is not needed in the using process.
By the scheme, the related hook processing detection and punishment can be performed in the executable file, and the system global process is correspondingly scanned. When the scheme is applied, the codes are only required to be statically or dynamically linked into a required product, and the code can be used by simply inserting the codes into the original product logic and modifying the logic.
Therefore, the data input mode of the system can be monitored when the system starting process is detected; in the monitoring process, acquiring a current running process and a current input focus of a system, determining a process to be protected from the current running process, and detecting whether the current input focus is positioned in a window area of the process to be protected; analyzing an execution link of a simulation sending function in a system, and determining an execution path of the simulation sending function on the execution link; acquiring a virtual key code of system input data, and detecting a trigger mode of the input data according to the virtual key code; and determining whether the data input mode of the system has an abnormality or not based on at least one of the position of the current input focus relative to the window region, the execution path and the trigger mode. According to the scheme, the message distribution function and the message processing function of the process in the system can be hooked, the function call stack is analyzed, whether the function call stack is abnormal or not is checked, whether the process to be protected has the function and the mode input by the non-physical keyboard or not is detected, misjudgment is avoided, the safety of instructions and input is improved, and the program password is prevented from being cracked violently or being automatically completed by actions needing to be executed manually. A series of detection, identification and destruction are carried out in a mode of inputting the software simulation keyboard, so that the detection effect is greatly enhanced, the reliability of a data input path is ensured, the safety of a system is improved, and the safety of system software is better protected. The scheme realizes detection through a real input mode of information so as to discover and punish illegal input, simplifies detection of a data input mode of a system, saves resources, and effectively reduces the operating pressure of the central processing unit.
In order to better implement the method, correspondingly, an embodiment of the present application further provides a monitoring device for a data input method, where the monitoring device for a data input method may be specifically integrated in an electronic device, and the electronic device may be a server or a terminal.
For example, as shown in fig. 3, the monitoring device of the data input mode may include a monitoring unit 301, a first detection unit 302, a second detection unit 303, a third detection unit 304, and a determination unit 305, as follows:
the monitoring unit 301 is configured to monitor a data input mode of the system when detecting a system start process;
a first detecting unit 302, configured to obtain a current running process and a current input focus of a system in a monitoring process, determine a process to be protected from the current running process, and detect whether the current input focus is located in a window region of the process to be protected;
a second detecting unit 303, configured to analyze an execution link of an analog sending function in the system, and determine an execution path of the analog sending function on the execution link;
a third detecting unit 304, configured to obtain a virtual key of system input data, and detect a trigger mode of the input data according to the virtual key;
a determining unit 305, configured to determine whether there is an abnormality in a data input manner of the system based on at least one of a position of the current input focus with respect to the window region, the execution path, and the trigger manner.
Optionally, in some embodiments, the first detection unit 302 may include an acquisition subunit and a detection subunit, as follows:
the acquiring subunit is configured to start a detection processing thread, and search a current running process of the system by using the detection processing thread; acquiring a target process positioned at the top layer of the current desktop of the system from the current running process, and determining the target process as a process to be protected; monitoring the current running process in real time, and acquiring a current input focus of the system when input data is monitored;
the detection subunit is configured to acquire a focus window handle corresponding to the current input focus; comparing the focus window handle with the target window handle, and determining whether the focus window handle is equal to the target window handle according to a comparison result; if the focus window handle is equal to the target window handle, determining that the current input focus is located in a window area of the process to be protected; and if the focus window handle is not equal to the target window handle, determining that the current input focus is not located in a window area of the process to be protected.
Optionally, in some embodiments, the obtaining subunit is specifically configured to obtain, by using the detection processing thread, a target window handle of the program to be protected; reverse searching is carried out based on the target window handle to obtain a memory address of a window processing function where the target window handle is located; analyzing a subclass window processing function in the window processing function based on the memory address, and determining all window class data in the subclass window processing function; monitoring target data in all window class data by using a preset window message processing function, wherein the target data is data input through input equipment; and when the target data is monitored, acquiring the current input focus of the system.
Optionally, in some embodiments, the second detecting unit 303 may be specifically configured to perform hooking processing on the simulated message sending function through a preset hooking function; stack backtracking is carried out on the simulated message sending function to obtain a father function address of the simulated message sending function; determining a target running process corresponding to the parent function address from a current running process of the system; and acquiring an execution path of a function calling the target running process, and acquiring the execution path of the simulation sending function on an execution link.
Optionally, in some embodiments, the second detecting unit 303 may be specifically configured to acquire a register value of the simulated sending message function; according to the register value, acquiring an instruction execution address returned by a calling function, wherein the calling function is a function for calling the message sending simulation function; determining an instruction machine code based on the instruction execution address, and calculating a call instruction address based on the instruction machine code; and determining a calling machine code based on the calling instruction address, and calculating based on the calling machine code to obtain a parent function address of the simulated message sending function.
Optionally, in some embodiments, the second detecting unit 303 may be specifically configured to continue to execute the simulated message sending function if the execution path meets a preset rule; and if the execution path does not accord with the preset rule, punishing the simulation message sending function.
Optionally, in some embodiments, the third detecting unit 304 may include a hooking subunit, a storing subunit, a searching subunit, and an analyzing subunit, as follows:
the hooking subunit is used for hooking the message sending function and the message receiving function in the system through a preset hooking function;
the storage subunit is configured to acquire the virtual key code and the boot millisecond number of the transmission data from the message sending function, and store the virtual key code and the boot millisecond number of the transmission data in a preset array list;
the searching subunit is configured to obtain the virtual key code and the boot millisecond number of the received input data from the message receiving function, traverse the numerical value list, and search the virtual key code of the input data in the numerical value list;
the analysis subunit is configured to, if the virtual key code of the input data exists in the numerical value list, analyze the boot millisecond number of the input data, and determine whether the input data is triggered by a virtual key of the system according to an analysis result.
Optionally, in some embodiments, the storage subunit may be specifically configured to, when the message sending function receives data, obtain all sending data from the message sending function; if the sending data is data input through input equipment, acquiring a virtual key code and a starting-up millisecond number corresponding to the sending data from the message sending function; and combining the virtual key code corresponding to the sending data and the starting millisecond array into a sending array item, storing the sending array item into a preset array list, and continuously executing the message sending function.
Optionally, in some embodiments, the searching subunit may be specifically configured to, when the message receiving function receives data, obtain all input data from the message receiving function; if the input data are data input through input equipment, acquiring a virtual key code and a starting-up millisecond number corresponding to the input data from the message receiving function; combining the virtual key code corresponding to the input data and the starting millisecond array into a receiving array item; traversing the numerical value list, and searching the received array items in the numerical value list, if the virtual key of the input data exists in the numerical value list, the method includes: if the received array entries exist in the numerical list.
Optionally, in some embodiments, the analyzing subunit is specifically configured to, if the received array item exists in the array list, analyze the number of milliseconds of starting up in the received array item, and determine, according to an analysis result, whether the received array item is called by an internal analog virtual key of the system; if the received array item is called by a simulated virtual key in the system, determining that the triggering mode of the input data is triggered by the virtual key of the system, and continuing to execute the message receiving function; and if the received array item is not called by a simulated virtual key in the system, determining that the triggering mode of the input data is not triggered by the virtual key of the system, punishing the input data, and continuously executing the message receiving function.
In a specific implementation, the above units may be implemented as independent entities, or may be combined arbitrarily to be implemented as the same or several entities, and the specific implementation of the above units may refer to the foregoing method embodiments, which are not described herein again.
As can be seen from the above, in this embodiment, the monitoring unit 301 may monitor the data input mode of the system when detecting the system start process; in the monitoring process, a first detection unit 302 acquires a current running process and a current input focus of a system, determines a process to be protected from the current running process, and detects whether the current input focus is located in a window area of the process to be protected; analyzing an execution link of an analog sending function in the system by a second detection unit 303, and determining an execution path of the analog sending function on the execution link; a third detection unit 304 acquires a virtual key code of system input data, and detects a trigger mode of the input data according to the virtual key code; determining, by the determining unit 305, whether there is an abnormality in a data input manner of the system based on at least one of a position of the current input focus with respect to the window region, the execution path, and the trigger manner. According to the scheme, whether the current input focus is located in a window area of the process to be protected or not can be detected, the execution path of the simulation sending function on the execution link is analyzed, and the triggering mode of the input data is determined according to the virtual key code, so that the global process of the system is accurately and effectively detected, the detection effect is greatly enhanced, the reliability of the data input path is ensured, the safety of the system is improved, and the safety of system software is better protected. The scheme simplifies the detection of the data input mode of the system, saves resources and effectively reduces the operating pressure of the central processing unit.
In addition, an electronic device according to an embodiment of the present application is further provided, as shown in fig. 4, which shows a schematic structural diagram of the electronic device according to an embodiment of the present application, and specifically:
the electronic device may include components such as a processor 401 of one or more processing cores, memory 402 of one or more computer-readable storage media, a power supply 403, and an input unit 404. Those skilled in the art will appreciate that the electronic device configuration shown in fig. 4 does not constitute a limitation of the electronic device and may include more or fewer components than shown, or some components may be combined, or a different arrangement of components. Wherein:
the processor 401 is a control center of the electronic device, connects various parts of the whole electronic device by various interfaces and lines, performs various functions of the electronic device and processes data by running or executing software programs and/or modules stored in the memory 402 and calling data stored in the memory 402, thereby performing overall monitoring of the electronic device. Alternatively, processor 401 may include one or more processing cores; preferably, the processor 401 may integrate an application processor, which mainly handles operating systems, user interfaces, application programs, etc., and a modem processor, which mainly handles wireless communications. It will be appreciated that the modem processor described above may not be integrated into the processor 401.
The memory 402 may be used to store software programs and modules, and the processor 401 executes various functional applications and data processing by operating the software programs and modules stored in the memory 402. The memory 402 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application program required by at least one function (such as a sound playing function, an image playing function, etc.), and the like; the storage data area may store data created according to use of the electronic device, and the like. Further, the memory 402 may include high speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid state storage device. Accordingly, the memory 402 may also include a memory controller to provide the processor 401 access to the memory 402.
The electronic device further comprises a power supply 403 for supplying power to the various components, and preferably, the power supply 403 is logically connected to the processor 401 through a power management system, so that functions of managing charging, discharging, and power consumption are realized through the power management system. The power supply 403 may also include any component of one or more dc or ac power sources, recharging systems, power failure detection circuitry, power converters or inverters, power status indicators, and the like.
The electronic device may further include an input unit 404, and the input unit 404 may be used to receive input numeric or character information and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.
Although not shown, the electronic device may further include a display unit and the like, which are not described in detail herein. Specifically, in this embodiment, the processor 401 in the electronic device loads the executable file corresponding to the process of one or more application programs into the memory 402 according to the following instructions, and the processor 401 runs the application programs stored in the memory 402, thereby implementing various functions as follows:
when a system starting process is detected, monitoring a data input mode of the system; in the monitoring process, acquiring a current running process and a current input focus of a system, determining a process to be protected from the current running process, and detecting whether the current input focus is positioned in a window area of the process to be protected; analyzing an execution link of an analog sending function in a system, and determining an execution path of the analog sending function on the execution link; acquiring a virtual key code of system input data, and detecting a trigger mode of the input data according to the virtual key code; and determining whether the data input mode of the system has an abnormality or not based on at least one of the position of the current input focus relative to the window area, the execution path and the trigger mode.
The above operations can be implemented in the foregoing embodiments, and are not described in detail herein.
Therefore, the data input mode of the system can be monitored when the system starting process is detected; in the monitoring process, acquiring a current running process and a current input focus of a system, determining a process to be protected from the current running process, and detecting whether the current input focus is positioned in a window area of the process to be protected; analyzing an execution link of a simulation sending function in a system, and determining an execution path of the simulation sending function on the execution link; acquiring a virtual key code of system input data, and detecting a trigger mode of the input data according to the virtual key code; and determining whether the data input mode of the system has an abnormality or not based on at least one of the position of the current input focus relative to the window region, the execution path and the trigger mode. According to the scheme, whether the current input focus is located in a window area of the process to be protected or not can be detected, the execution path of the simulation sending function on the execution link is analyzed, and the triggering mode of the input data is determined according to the virtual key code, so that the global process of the system is accurately and effectively detected, the detection effect is greatly enhanced, the reliability of the data input path is ensured, the safety of the system is improved, and the safety of system software is better protected. The scheme simplifies the detection of the data input mode of the system, saves resources and effectively reduces the operating pressure of the central processing unit.
It will be understood by those skilled in the art that all or part of the steps of the methods of the above embodiments may be performed by instructions, or by instructions controlling associated hardware, which may be stored in a computer-readable storage medium and loaded and executed by a processor.
To this end, embodiments of the present application further provide a storage medium, where multiple instructions are stored, and the instructions can be loaded by a processor to perform steps in any one of the monitoring methods for data input methods provided in the embodiments of the present application. For example, the instructions may perform the steps of:
when detecting a system starting process, monitoring a data input mode of the system; in the monitoring process, acquiring a current running process and a current input focus of a system, determining a process to be protected from the current running process, and detecting whether the current input focus is positioned in a window area of the process to be protected; analyzing an execution link of a simulation sending function in a system, and determining an execution path of the simulation sending function on the execution link; acquiring a virtual key code of system input data, and detecting a trigger mode of the input data according to the virtual key code; and determining whether the data input mode of the system has an abnormality or not based on at least one of the position of the current input focus relative to the window region, the execution path and the trigger mode.
The above operations can be implemented in the foregoing embodiments, and are not described in detail herein.
Wherein the storage medium may include: read Only Memory (ROM), random Access Memory (RAM), magnetic or optical disks, and the like.
Since the instructions stored in the storage medium can execute the steps in the monitoring method for any data input method provided in the embodiment of the present application, the beneficial effects that can be achieved by the monitoring method for any data input method provided in the embodiment of the present application can be achieved, which are detailed in the foregoing embodiments and will not be described again here.
The foregoing describes in detail a method, an apparatus, an electronic device, and a storage medium for monitoring a data input mode provided in an embodiment of the present application, and a specific example is applied in the present application to explain principles and embodiments of the present application, and the description of the foregoing embodiments is only used to help understand a method and a core idea of the present application; meanwhile, for those skilled in the art, according to the idea of the present application, the specific implementation manner and the application scope may be changed, and in summary, the content of the present specification should not be construed as a limitation to the present application.
Claims (14)
1. A method for monitoring a data input mode is characterized by comprising the following steps:
when a system starting process is detected, monitoring a data input mode of the system;
in the monitoring process, acquiring a current running process and a current input focus of a system, determining a process to be protected from the current running process, and detecting whether the current input focus is positioned in a window area of the process to be protected;
analyzing an execution link of a simulation sending function in a system, and determining an execution path of the simulation sending function on the execution link;
acquiring a virtual key code of system input data, and detecting a trigger mode of the input data according to the virtual key code;
and determining whether the data input mode of the system has an abnormality or not based on at least one of the position of the current input focus relative to the window area, the execution path and the trigger mode.
2. The method of claim 1, wherein the obtaining a current running process and a current input focus of a system, and determining a process to be protected from the current running process comprises:
starting a detection processing thread, and searching a current running process of the system by using the detection processing thread;
acquiring a target process positioned at the top layer of the current desktop of the system from the current running process, and determining the target process as a process to be protected;
and monitoring the current running process in real time, and acquiring the current input focus of the system when input data is monitored.
3. The method of claim 2, wherein the monitoring the currently running process in real time, and when input data is monitored, obtaining a current input focus of a system comprises:
acquiring a target window handle of the program to be protected by using the detection processing thread;
reverse searching is carried out based on the target window handle, and the memory address of the window processing function where the target window handle is located is obtained;
analyzing a subclass window processing function in the window processing function based on the memory address, and determining all window class data in the subclass window processing function;
monitoring target data in all window class data by using a preset window message processing function, wherein the target data is data input through input equipment;
and when the target data is monitored, acquiring the current input focus of the system.
4. The method of claim 3, wherein the detecting whether the current input focus is located in a window region of a process to be protected comprises:
acquiring a focus window handle corresponding to the current input focus;
comparing the focus window handle with the target window handle, and determining whether the focus window handle is equal to the target window handle according to a comparison result;
if the focus window handle is equal to the target window handle, determining that the current input focus is located in a window area of the process to be protected;
and if the focus window handle is not equal to the target window handle, determining that the current input focus is not located in a window area of the process to be protected.
5. The method of claim 1, wherein analyzing the execution chain of the simulated transmission function in the system and determining the execution path of the simulated transmission function on the execution chain comprises:
hooking the simulation message sending function through a preset hooking function;
stack backtracking is carried out on the simulated message sending function to obtain a father function address of the simulated message sending function;
determining a target running process corresponding to the parent function address from a current running process of the system;
and acquiring an execution path of a function calling the target running process to obtain the execution path of the simulation sending function on an execution link.
6. The method of claim 5, wherein the stack tracing back the emulated send message function to obtain the parent function address of the emulated send message function comprises:
acquiring a register value of the message sending simulation function;
acquiring an instruction execution address returned by a calling function according to the register value, wherein the calling function is a function for calling the message simulating and sending function;
determining an instruction machine code based on the instruction execution address, and calculating a call instruction address based on the instruction machine code;
and determining a calling machine code based on the calling instruction address, and calculating based on the calling machine code to obtain a parent function address of the simulated message sending function.
7. The method of claim 5, wherein after obtaining the execution path of the function that calls the target running process, further comprising:
if the execution path meets a preset rule, continuing to execute the message simulation sending function;
and if the execution path does not accord with the preset rule, punishing the simulation message sending function.
8. The method of claim 1, wherein the obtaining of the virtual key of the system input data and the detecting of the triggering manner of the input data according to the virtual key comprise:
hooking a message sending function and a message receiving function in the system through a preset hooking function;
acquiring a virtual key code and a starting-up millisecond number of sending data from the message sending function, and storing the virtual key code and the starting-up millisecond number of the sending data into a preset array list;
acquiring the virtual key code and the boot millisecond number of the received input data from the message receiving function, traversing the numerical value list, and searching the virtual key code of the input data in the numerical value list;
if the virtual key code of the input data exists in the numerical value list, analyzing the starting-up millisecond number of the input data, and determining whether the input data is triggered by the virtual key of the system or not according to the analysis result.
9. The method of claim 8, wherein the obtaining the virtual key and the number of start-up milliseconds of the transmission data from the message sending function and storing the virtual key and the number of start-up milliseconds of the transmission data in a preset array list comprises:
when the message sending function receives data, all sending data are obtained from the message sending function;
if the sending data is data input through input equipment, acquiring a virtual key code and a starting-up millisecond number corresponding to the sending data from the message sending function;
and combining the virtual key code corresponding to the sending data and the startup millisecond array into a sending array item, storing the sending array item into a preset array list, and continuously executing the message sending function.
10. The method of claim 9, wherein obtaining the received virtual key and the number of boot milliseconds of the input data from the message receiving function and traversing the value list to find the virtual key of the input data in the value list comprises:
when the message receiving function receives data, all input data are obtained from the message receiving function;
if the input data is data input through input equipment, acquiring a virtual key code and a starting-up millisecond number corresponding to the input data from the message receiving function;
combining the virtual key code corresponding to the input data and the starting millisecond array into a receiving array item;
and traversing the numerical value list, and searching the receiving array items in the numerical value list.
If the virtual key code of the input data exists in the numerical value list, the method includes: if the received array entries exist in the numerical list.
11. The method of claim 10, wherein if the virtual key of the input data exists in the value list, analyzing the boot millisecond of the input data, and determining whether the input data is a virtual key trigger of a system according to the analysis result comprises:
if the array list has the received array items, analyzing the starting-up millisecond number in the received array items, and determining whether the received array items are called by the internal simulation virtual keys of the system or not according to the analysis result;
if the received array item is called by a simulated virtual key in the system, determining that the triggering mode of the input data is triggered by the virtual key of the system, and continuing to execute the message receiving function;
and if the received array item is not called by a simulated virtual key in the system, determining that the triggering mode of the input data is not triggered by the virtual key of the system, punishing the input data, and continuously executing the message receiving function.
12. A data input mode monitoring device is characterized by comprising:
the monitoring unit is used for monitoring the data input mode of the system when detecting the starting process of the system;
the system comprises a first detection unit, a second detection unit and a third detection unit, wherein the first detection unit is used for acquiring a current running process and a current input focus of a system in a monitoring process, determining a process to be protected from the current running process, and detecting whether the current input focus is positioned in a window area of the process to be protected;
the second detection unit is used for analyzing an execution link of an analog sending function in the system and determining an execution path of the analog sending function on the execution link;
the third detection unit is used for acquiring a virtual key code of system input data and detecting a trigger mode of the input data according to the virtual key code;
and the determining unit is used for determining whether the data input mode of the system has an abnormality or not based on at least one of the position of the current input focus relative to the window area, the execution path and the trigger mode.
13. A computer-readable storage medium storing instructions adapted to be loaded by a processor to perform the steps of the method for monitoring data input manner according to any one of claims 1 to 11.
14. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the steps of the method according to any of claims 1 to 11 are implemented when the program is executed by the processor.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110425773.4A CN115220859A (en) | 2021-04-20 | 2021-04-20 | Data input mode monitoring method and device, electronic equipment and storage medium |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110425773.4A CN115220859A (en) | 2021-04-20 | 2021-04-20 | Data input mode monitoring method and device, electronic equipment and storage medium |
Publications (1)
Publication Number | Publication Date |
---|---|
CN115220859A true CN115220859A (en) | 2022-10-21 |
Family
ID=83605628
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202110425773.4A Pending CN115220859A (en) | 2021-04-20 | 2021-04-20 | Data input mode monitoring method and device, electronic equipment and storage medium |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN115220859A (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN115495057A (en) * | 2022-11-16 | 2022-12-20 | 江苏智云天工科技有限公司 | Method and system for realizing windows and HDFS communication |
-
2021
- 2021-04-20 CN CN202110425773.4A patent/CN115220859A/en active Pending
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN115495057A (en) * | 2022-11-16 | 2022-12-20 | 江苏智云天工科技有限公司 | Method and system for realizing windows and HDFS communication |
CN115495057B (en) * | 2022-11-16 | 2023-02-28 | 江苏智云天工科技有限公司 | Method and system for realizing windows and HDFS communication |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7398469B2 (en) | Automated test system for testing an application running in a windows-based environment and related methods | |
US6931540B1 (en) | System, method and computer program product for selecting virus detection actions based on a process by which files are being accessed | |
KR100221374B1 (en) | Method and system for managing events | |
EP0636985A1 (en) | Process monitoring in a multiprocessing server | |
US6584487B1 (en) | Method, system, and apparatus for managing tasks | |
CN110765464A (en) | Vulnerability detection method, device, equipment and computer storage medium | |
CN114254304A (en) | Container security intrusion detection method and device, computer equipment and storage medium | |
CN111597553A (en) | Process processing method, device, equipment and storage medium in virus searching and killing | |
CN115220859A (en) | Data input mode monitoring method and device, electronic equipment and storage medium | |
CN114741695A (en) | Malicious code monitoring method and device, electronic equipment and storage medium | |
CN113849356A (en) | Equipment testing method and device, electronic equipment and storage medium | |
CN112947907B (en) | Method for creating code branches | |
JPH09171473A (en) | Method for management of error and data-processing system | |
CN112631949B (en) | Debugging method and device, computer equipment and storage medium | |
CN115794583A (en) | Kernel analysis method and device | |
CN115951947A (en) | Information interaction method and device and storage medium | |
CN112491799B (en) | Remote repair method and device for communication module, computer equipment and storage medium | |
CN111443907A (en) | Method and device for calling SDK function | |
CN109408336B (en) | Startup item monitoring method and device, terminal and computer readable medium | |
CN113064601B (en) | Method, device, terminal and storage medium for determining dynamic loading file | |
CN113656378A (en) | Server management method, device and medium | |
CN114124835A (en) | Interface-based data transmission method, device, equipment and medium | |
JP2001092687A (en) | Integral operating system for computer and server system | |
CN112463626A (en) | Memory leak positioning method and device, computer equipment and storage medium | |
CN111274507A (en) | Method, device and equipment for browsing webpage content and storage medium |
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 |