WO2012152210A1

WO2012152210A1 - Method and device for executing file operation

Info

Publication number: WO2012152210A1
Application number: PCT/CN2012/075145
Authority: WO
Inventors: 王宇; 潘剑锋
Original assignee: 北京奇虎科技有限公司
Priority date: 2011-05-11
Filing date: 2012-05-07
Publication date: 2012-11-15
Also published as: CN102779244A; CN102779244B

Abstract

Provided in the present application is a method for executing a file operation, comprising: acquiring a file operation request, where the request comprises a caller input parameter, and the input parameter comprises a file path; searching for a file object parsing routine in an object manager on the basis of the file path; if a corresponding file object parsing routine is found, then generating an I/O request packet on the basis of the file object parsing routine, and transmitting to an original address of a preconfigured file system low-level device. The present application improves the resistive capability against offence and defense of driver-level malicious programs, and prevents the potential possibility of incompatibility between security software caused by interference from file operation.

Description

Method and device for executing file operation

Technical field

The present application relates to the technical field of file penetration, and in particular to a method of performing file operations and an apparatus for performing file operations. Background technique

In the face of complex problems, people often use books to divide and narrow the problem, and this is also the case in the design of the operating system. The Windows operating system solves complex problems with layered design ideas. This approach brings advantages such as portability and scalability. However, due to security flaws in design theory (such as the lack of an integrity check mechanism, etc.), the other aspect of high scalability also means that there is a large amount of tampering in the system. Taking the design of the file system as an example, the hierarchical structure of the file call stack determines the risk that the data stream is tampered with in the call chain. Because of this, ensuring the authenticity and credibility of its own file operations becomes an inevitable requirement of security software.

Refer to the schematic diagram of the operating system file operation execution flow shown in Figure 1. In the execution file operation, the following hierarchical call is used:

The caller 101 calls the kernel interface layer 102, the kernel interface layer 102 calls the kernel execution layer 103, the kernel execution layer 103 calls the file object parsing routine 104, the file object parsing routine 104 calls the filter driver al05, and the top-level filter driver calls layer by layer until the call To the underlying filter driver N106, the underlying filter driver N106 calls the file system lower layer device 107. The caller 101 and the kernel interface layer 102 belong to the operating system user state, and the kernel execution layer 103, the file object parsing routine 104, the top filter driver al05, the underlying filter driver N106, and the file system lower layer device 107 belong to the operating system kernel state.

From the perspective of the operating system, there are potential tampering points in the file operation execution flow:

1) User interface IAT Hook (Import Address Table Hook) / EAT Hook (Export Table Hook); 2) User mode Inline Hook of the kernel interface layer (inline hook);

3) Int 2E (interrupt) / SysEnter Hook when the kernel interface layer calls the kernel execution layer (user state enters kernel state hook);

4) Native API SSDT Hook (System Service Dispatch Table Hook) of the kernel execution layer;

5) Native API Inline Hook of the kernel execution layer;

6) Object Parse Routine Hook of the file object parsing routine;

7) The top filter driver of the top filter driver is acquired;

8) The underlying filter driver N gets the underlying filter driver.

Although traditional security software vendors realize the possibility of hijacking various file operation calls, most of the existing solutions only consider the hijacking risk of the operating system user state, and often show certain lack of capabilities in the attack and defense of the operating system kernel state. Driver-level malicious programs (rootkits) have weaker confrontational capabilities.

Therefore, a technical problem that needs to be solved urgently by those skilled in the art is as follows: A processing mechanism for file penetration operation is proposed, which not only provides attack and defense of the operating system user state, but also provides attack and defense of the operating system kernel state to enhance and drive. The ability of a malicious program to attack and defend, and to avoid the potential for incompatibility between security software due to file operation interference. Summary of the invention

One of the purposes of the present application is to provide a method of performing file operations to enhance the ability of attack and defense of malicious programs and to avoid the potential for incompatibility between security software due to file manipulation interference.

The present application also provides an apparatus for performing file operations to ensure the practical application and implementation of the above method.

In order to solve the above problem, the embodiment of the present application discloses a method for executing a file operation, including: Obtaining a file operation request, where the request includes a caller input parameter, where the input parameter includes a file path;

Searching for a corresponding file object parsing routine in the object manager according to the file path; if a corresponding file object parsing routine is found, generating an I/O request packet according to the file object parsing routine, and transmitting the The I/O request packet is addressed to the original address of the underlying device of the file system.

Preferably, the step of searching for a corresponding file object parsing routine in the object manager according to the file path specifically includes the following sub-steps;

Sub-step Sl, determining whether the file path has been disassembled, if not, executing sub-step S2; if yes, performing sub-step S4;

Sub-step S2, disassembling the next path segment to be disassembled in the file path according to the path separator;

Sub-step S3, using the currently disassembled path segment to search in the object manager, to determine whether there is a corresponding file object routine; if yes, return to sub-step S1; if not, then perform sub-step S5;

Sub-step S4: Obtain a file object parsing routine corresponding to the file path.

Sub-step S5, returning information that the corresponding file object parsing routine is not found.

Preferably, the caller input parameter has a user mode address; and before the file object parsing routine is searched, the method further includes:

Reconstructing the user state address to the kernel state memory space.

Preferably, the I/O request packet includes file operation information extracted from the file operation request, and after sending the I/O request packet to the original address of the preset file system lower device, the method further includes:

The corresponding file operation is continued by the lower layer device of the file system according to the file operation information.

Preferably, before acquiring the file operation request, the method further includes:

The caller initiates a file operation request, and invokes a corresponding file operation interface routine; wherein the request includes a caller input parameter, and the input parameter includes a file path; The kernel state structure parameter is constructed according to the type of the system platform, and a corresponding file operation control code is generated according to the kernel state structure parameter, and the file operation control code is sent to the operating system kernel state driver.

Preferably, before constructing the kernel state structure parameter, the method further includes:

The file manipulation interface routine converts the ANSI related parameters in the caller input parameters to the UNICODE type and calls the corresponding file manipulation interface wide character routine.

Preferably, the file operation interface routine includes a file creation routine FSCreateFile, and before continuing to perform the requested file operation by the file system lower layer device, the method further includes:

Insert the newly created file object into the object manager and get the returned file handle. Preferably, the method further includes:

The caller input parameter is verified according to the file operation request, and if the check passes, the step of finding the file object parsing routine is performed.

Preferably, the file operation interface routine is consistent with the WINDOWS standard API, and the file operation interface routine further comprises: a file read routine FSReadFile, a file write routine FSWriteFile, a file attribute setting routine FSSetFileAttributes, a file attribute Get routine FSGetFileAttributes, file pointer setting routine FSSetFilePointer, enhanced file pointer setting routine FSSetFilePointerEx, file size get routine FSGetFileSize, file delete routine FSDeleteFile, directory removal routine FSRemoveDirectory, handle close routine FSCloseHandle, first file Find routine FSFindFirstFile, next file lookup routine FSFindNextFile, file lookup close routine FSFindClose, add file property get routine FSGetFileAttributesEx, routine FSPathlsDirectory to determine if the path is a directory, routine FSPathFileExists to determine whether the target file exists, long path Get routine FSGetLongPathName, short path get routine FSGetShortPathName, path lookup routine FSSearchPath, enhanced file size get routine FSGetFi leSizeEx, file copy routine FSCopyFile, file move routine FSMoveFile, and/or enhanced file move routine FSMoveFileEx.

Preferably, the control code comprises: a file creation operation control code FILE 10 CREATE FILE, a file read operation control code FILE 10 READ FILE, File write operation control code FILE_ 10 — WRITE — FILE, file query operation control code FILE — 10 — QUERY — FILE, file setting operation control code FILE — 10 — SET — FILE and / or file close preparation operation control code FILE — 10— PREPARE—CLOSE. The embodiment of the present application further discloses an apparatus for executing file operations, including:

a kernel mode request obtaining module, configured to obtain a file operation request, where the request includes a caller input parameter, where the input parameter includes a file path;

The kernel state object parsing module is configured to search for a corresponding file object parsing routine in the object manager according to the file path; if the corresponding file object parsing routine is found, the kernel IRP is used to generate a sending module;

The kernel mode IRP generates a sending module, configured to generate an I/O request packet according to the file object parsing routine, and send the I/O request packet to a preset original address of a file system lower layer device.

Preferably, the kernel object parsing module specifically includes the following modules;

The file path disassembly module is configured to disassemble the path segment in the file path step by step according to the path separator;

The object manager search module is set to search the object manager with the currently disassembled path segment to find the corresponding file object routine.

Preferably, the caller input parameter has a user mode address; the device further includes: a kernel address reconstruction module, configured to reconstruct the user state address to a kernel state memory space. Preferably, the device further includes:

The user mode request sending module is configured to initiate a file operation request by the caller, and invoke the corresponding file operation interface routine; wherein the request includes a caller input parameter, and the input parameter includes a file path;

The user mode control code sending module is configured to construct a kernel state structure parameter according to the type of the system platform, generate a corresponding file operation control code according to the kernel state structure parameter, and send the file operation control code to the operating system kernel state driver.

Preferably, the device further includes: The wide character routine calls the module, which is set to convert the ANSI related parameters in the caller input parameters to the UNICODE type and call the corresponding file operation interface wide character routine.

Preferably, the file operation interface routine includes a file creation routine FSCreateFile, and the device further includes:

The handle acquisition module is set to insert the newly created file object into the object manager and get the returned file handle.

Preferably, the device further includes:

The kernel state parameter verification module is configured to check the caller input parameter according to the file operation request, and if the verification passes, the kernel object parsing module is called. The embodiment of the present application further discloses a computer readable recording medium on which a program for executing a file operation is recorded, wherein the method for executing the file operation includes:

Obtaining a file operation request, where the request includes a caller input parameter, where the input parameter includes a file path;

Searching for a corresponding file object parsing routine in the object manager according to the file path; if the corresponding file object parsing routine is found, generating an I/O request packet according to the file object parsing routine, and sending the pre-process The original address of the underlying device of the file system. Compared with the prior art, the present application has the following advantages:

The operating system user interface completely implements a set of file operation calling library, the caller initiates a file operation request, invokes a corresponding file operation interface routine, and the operating system kernel mode driver acquires and verifies the request from the user state, constructs a query. The data structure loops through the path of the incoming file, and finally finds the type of object maintained in the object manager. This process effectively counters the hidden state of the kernel state. Thereafter, the operating system kernel mode driver builds and populates the IRP request packet and sends it to the original address of the pre-determined file system lower device. At this point, the third-party filter driver on the file system call stack includes other security software and driver-level malicious. The program can be penetrated, so that it can effectively avoid the interference caused by file operation and other security soft. There is a potential for incompatibility between the pieces; it can also enhance and combat the ability of the level of malicious programs to attack and defend.

The file path parsing method used in the embodiment of the present application can also dynamically parse the target file path. For example, for a dynamically mapped network disk drive, the DOS-Style file path format, drive letter, and file can be dynamically obtained by searching the object manager. The corresponding processing relationship between the underlying device objects of the system, and thus the embodiment of the present application has the advantages of wide application range and many applicable scenarios. DRAWINGS

1 is a schematic diagram of an operating system file operation execution flow;

2 is a flow chart of the steps of Embodiment 1 of a file operation execution method of the present application; FIG. 3 is a flow chart showing steps of searching for a corresponding file object parsing routine in the object manager according to the file path in the present application;

4 is a first schematic diagram of a search in an object manager in a specific example of the present application;

Figure 5 is a second schematic diagram of a search in an object manager in a specific example of the present application;

6 is a third schematic diagram of a search in an object manager in a specific example of the present application;

Figure 7 is a fourth schematic diagram of a search in an object manager in another specific example of the present application;

Figure 8 is a fifth schematic diagram of a search in an object manager in another specific example of the present application;

Figure 9 is a sixth schematic diagram of a search in an object manager in another specific example of the present application;

10 is a flow chart of the steps of the second embodiment of the file operation method of the present application; FIG. 11 is a schematic diagram of a file operation execution flow implemented by applying the embodiment of the present application;

FIG. 12 is a structural block diagram of an embodiment of an apparatus for executing a file operation according to the present application. detailed description

The above described objects, features, and advantages of the present invention will become more apparent from the following detailed description.

One of the core concepts of the embodiment of the present application is that a set of file operation calling library is completely implemented in the operating system user state interface, the caller initiates a file operation request, invokes a corresponding file operation interface routine, and the operating system kernel state driver acquires and authenticates. The request from the user state is verified, the query data structure is constructed to cyclically parse the incoming file path, and finally the object type maintained in the object manager is found. This process effectively counters the kernel state's hijacking internal danger. Thereafter, the operating system kernel mode driver builds and populates the IRP request packet and sends it to the original address of the pre-determined file system lower device. At this time, the third-party filter driver on the file system call stack (other security software, driver-level malicious program) ) is penetrated (bypass, bypass). In short, this application effectively avoids the risk of the file execution path of the traditional operating system by establishing a new, trusted, and transparent file-driven execution path.

Referring to FIG. 2, a flow chart of the steps of Embodiment 1 of a file operation method of the present application is shown, which may specifically include the following steps:

Step 201: Acquire a file operation request, where the request includes a caller input parameter, where the input parameter includes a file path.

It should be noted that, in the embodiment of the present application, the file includes a file of a type supported by the WINDOWS operating system, where the file operation is a combination of an atomic operation or an atomic operation of the file, and the atomic operation includes: Create, File Read, File Write, File Property Settings, File Property Get, File Pointer Settings, File Size Get, File Delete, Directory Removal, Handle Close, First File Lookup, Next File Lookup, File Lookup Off Determine whether the path is a directory, determine whether the target file exists, long path acquisition, short path acquisition, path search, file copy, file move, and so on. For example, a file's anti-virus operations are a combination of atomic operations such as file reading, first file lookup, next file lookup, file lookup shutdown, file move, and so on.

Step 202, verifying the caller input parameter according to the file operation request, and if the verification passes, searching for a corresponding file object parsing routine in the object manager according to the file path; Referring to FIG. 3, in a preferred embodiment of the present application, the step of searching for a corresponding file object parsing routine in the object manager according to the file path may specifically include the following sub-steps;

Sub-step S3, using the currently disassembled path segment to search in the object manager, to determine whether there is a corresponding file object routine; if yes, return to sub-step S 1; if not, execute sub-step S5;

In the specific implementation, the OpenPacket structure of the object manager query may be pre-built, and the file path is re-disassembled based on the path separator "\". For example, the file path is: c:\a\b.txt, then the first disassembly The path segment that is generated is c:, and the path segment that is removed for the second time is: c:\a, and the path segment that is disassembled for the third time is: c:\a\b.txt, that is, in the embodiment of the present application , is to resolve the file path based on recursive calls.

The Object Manager (obj ect Manager) is a basic component of the Windows NT kernel. When designing Windows NT, "object-oriented, design ideas have become popular, and the resources scattered around the operating system are abstracted and encapsulated, thus providing a consistent access path for various internal services. Object Manager mainly Used to implement the following functions: (1) Provide a common, unified mechanism to use system resources; (2) Segregate object protection into a unified area of the operating system to achieve C2 security level; (3) Provide A mechanism to record the number of objects used by the process, which can impose restrictions on the use of system resources; (4) Establish a set of object naming schemes, which can more easily fuse existing objects. The object manager maintains dozens of objects. Object types (Windows 2000 is 27 object types; Windows XP is 29 object types), common such as: Symbolic Link, Process, Thread, Job, File ), event (Event), timer (Timer) and many more.

The object manager maintains a zippered object hash table, and searches for the object manager based on the path segment that is disassembled each time. If the corresponding object parsing routine ParseProcedure can be found, the next file path disassembly is continued, and Searching for the object manager based on the next split path segment and the previously disassembled path segment. If the current file path is completely disassembled after loop resolution, the file object parsing routine found by the search object manager Parse Routine is the file object parsing routine corresponding to the current file path.

It is well known that a routine is a collection of functional interfaces or services provided by a system externally. For example, the operating system's API, services, etc. are routines.

In order to enable the person skilled in the art to better understand the present application, the object manager search diagram shown in FIG. 4, FIG. 5, FIG. 6, FIG. 7, FIG. 8 and FIG. 9 is used to describe the application in detail by a specific example. The file path is searched for the operation of the object manager.

For example, the file path is: c:\test\test.txt , c: is a symbolic link ( SymbolicLink ), and the object manager search is essentially a symbolic link query process.

(1) Referring to Figure 4, the search starts from the "root" of the object manager (ie "\" );

(2) Find the GLOBAL?? directory under "V."

(3) Find the GLOBAL folder under "V," according to the GLOBAL?? directory;

After that, continue to look for C: in GLOBAL? (Note C: belongs to the figure

SymbolicLink )

(4) Referring to Figure 5, find C: from the GLOBAL?? folder;

(5) According to the type of C: (Type): SymbolicLink and Additional Information: \Device\HarddiskVolume 1 Find the Device folder; if necessary, continue to parse the \Device\harddiskVolumel symbolic link, etc. Can't be disassembled.

(6) Refer to Figure 6, find HarddiskVolumel from the Device folder.

As another example, the file path "SystemRoot\System32\Drivers\ntfs.sys SystemRoot" is also a symbolic link; (2) According to the type corresponding to SystemRoot (Type): SymbolicLink and Additional Information: \Device\HarddiskO\Partitionl\ WINDOWS Find the Device folder;

(3) Referring to Figure 8, find the \HarddiskO under the Device folder;

(4) Find Partitionl under \HarddiskO, according to the type (Type) of Partitionl: SymbolicLink and Additional Information:

\Device\HarddiskVolume 1 Find the Device folder;

(5) Referring to Figure 9, find the HarddiskVolumel in the Device folder. In this example, the path is based on the path separator "\". Every time a separator is found, it is considered to find a "factor" and then search. The object manager re-searches the object manager if necessary, and searches the object manager again. In this embodiment, the searched file object parsing routine is a function, and this function corresponds to a certain factor when registering, it knows How to deal with these factors correctly.

The file path parsing method used in the embodiment of the present application can dynamically parse the target file path. For example, for a dynamically mapped network disk drive, the DOS-Style file path format, drive letter, and file system can be dynamically obtained by searching the object manager. The corresponding processing relationship between the lower device objects, and thus the embodiment of the present application has the advantages of wide application range and many applicable scenarios.

Step 203: If a corresponding file object parsing routine is found, generating an I/O request packet according to the file object parsing routine, and sending the original address to the preset file system lower layer device.

In a concrete implementation, the implementation of file object parsing Parse Routine is similar to the soft IoParseDevice routine (analog implementation), which internally builds and populates the I/O Request Packet (IRP) and sends it to the lower layer of the file system. The original address of the device. In Microsoft's Windows operating system family, IRP is sent to communicate with the driver. The data structure used to encapsulate the IRP is not only used to describe the contents of the request itself for an I/O operation, but also to maintain state information about the request as it passes through a series of drivers. That is to say, IRP can be defined as: I/O system in order to process an I/O The place where the request is used to store the necessary information. When a thread invokes an I/O service, the I/O Manager constructs an IRP that is used to represent this request as the I/O system processes the request.

In a specific implementation, the original address of the file system lower layer device may be set when the system is initialized. After this step, the third-party filter driver (other security software, driver-level malicious programs) on the file system call stack will be penetrated, which can effectively avoid the possibility of incompatibility with other security software due to file operation interference. Sex; can also enhance and drive the ability of the level of malicious programs to attack and defend.

In practice, the I/O request packet includes file operation information extracted from a file operation request, and after the I/O request packet (IPR) is sent to the original address of the preset file system lower device, The file system lower layer device continues to perform the corresponding file operation according to the file operation information. Specifically, when the IRP is sent to the device object of the file system, until it is written to the hard disk, it goes through a series of complicated processing. Generally, this request is also subjected to a volume snapshot (Volsnap.sys), volume manager. (Ftdisk.sys), Partition Manager (Partmgr.sys), Disk Class Driver (disk.sys), Disk Port Driver (at the API system as atapi.sys), Small Port Driver (with Adaptec 1540 SCSI as an example) Ahal54x.sys ) is a series of passes, and the small port driver ultimately determines the corresponding offset to write to the disk or tape drive. Volume management (including snapshots) introduces a dynamic concept that allows windows to create multi-partition volumes (such as mirrored volume mirrors, striped volumes, RAID-5, etc.), which will target requests to the target volume based on actual conditions. Offset. The Partition Manager is responsible for notifying the Plug and Play Manager which partitions are currently in place, as well as their status (create, delete, etc.). The disk class driver implements functions common to all disks. For example, SCSI (Small Computer System Interface) Port is for disk characteristics on the SCSI bus. Finally, the small port driver is specific to certain vendors, and such drivers are often provided by the vendor itself. In general, each layer receives the request from the upper layer according to its own interface, finds a certain sector offset of the target device, and creates, writes, and deletes data by using the "view" that it sees. Referring to FIG. 10, a step of Embodiment 2 of a method for executing file operations of the present application is shown. The flow chart may specifically include:

Step 401: Load a file operation interface routine, and initialize an original address of a file system lower layer device;

As an example of a specific application, the file operation interface routine includes: a file creation routine FSCreateFile, a file read routine FSReadFile, a file write routine FSWriteFile, a file attribute setting routine FSSetFileAttributes, a file attribute acquisition routine FSGetFileAttributes , file pointer setting routine FSSetFilePointer, enhanced file pointer setting routine FSSetFilePointerEx, file size get routine FSGetFileSize, file delete routine FSDeleteFile, directory removal routine FSRemoveDirectory, handle close routine FSCloseHandle, first file lookup routine FSFindFirstFile Next file lookup routine FSFindNextFile, file lookup shutdown routine FSFindClose, add file property get routine FSGetFileAttributesEx, routine FSPathlsDirectory to determine if the path is a directory, routine FSPathFileExists to determine whether the target file exists, long path get routine FSGetLongPathName , short path get routine FSGetShortPathName, path lookup routine FSSearchPath, enhanced file size get routine FSGetFileSizeEx File copy routines FSCopyFile, file movement routines FSMoveFile and / or enhanced mobile document routine FSMoveFileEx. The settings of the file operation interface routine, such as calling conventions, calling parameters, and corresponding WINDOWS standard APIs. Each of the above routines includes a narrow character routine and a wide character routine, such as FSCreateFile, including the narrow character routine FSCreateFileA and the wide character routine FSCreateFileW.

Step 402: The caller initiates a file operation request, and invokes a corresponding file operation interface routine. The request includes a caller input parameter, where the input parameter includes a file path and a user state address.

For example, the caller process initiates a file creation request for FSCreateFileA.

Step 403: The user mode part of the file operation interface routine converts the ANSI related parameter in the caller input parameter into a UNICODE type, and invokes a corresponding file operation interface wide character routine;

It is well known that characters in ANSI use 8bit, while characters in UNICODE are used. 16bit. (For characters, ANSI stores English characters in single bytes, and Chinese characters in double bytes. In Unicode, English and Chinese characters are stored in double bytes).

Taking the file creation process as an example, to ensure platform applicability, FSCreateFileA converts the ANSI related parameters in the caller input parameters to UNICODE type and calls the corresponding file operation interface wide character routine FSCreateFileW.

Of course, if you are calling a wide-character routine directly in practice, you do not need to perform this step. Step 404: Construct a kernel state structure parameter according to the type of the system platform, generate a corresponding file operation control code according to the kernel state structure parameter, and send the file operation control code to the kernel mode driver of the operating system;

The types of system platforms include 32-bit, 64-bit, and 32-bit compatible modes. As an example of a specific application of the present application, the control code corresponding to the file operation interface routine includes: a file creation operation control code FILE-10 - CREATE_FILE, a file read operation control code FILE-10 - READ_FILE , file write operation control code FILE_ 10 — WRITE — FILE, file query operation control code FILE — 10 — QUERY — FILE, file setting operation control code FILE — 10 — SET — FILE and / or file close preparation operation control code FILE — 10— PREPARE—CLOSE. The control code defines a unified identifier when the operating system user state and the kernel mode drive communication.

Taking the file creation process as an example, FSCreateFileW constructs the structure parameters by judging the system platform type (32-bit, 64-bit or 32-bit compatibility mode), sends the control code FILE_10_CREATE_FILE and waits for a return.

In practice, FSCreateFileW can also handle malformed file names, file paths, and actually perform parameter conversion operations. The input and output buffers can be transmitted using the METHOD-BUFFERED mode when the operating system user mode and the kernel mode drive communication. METHOD—The BUFFERED method is: first allocate the buffer, and then copy the data from this buffer. The buffer size is the larger space between the input buffer and the output buffer. The read buffer is copied to the new buffer. Before returning, just copy the return value to the same buffer. The return value is placed in 10—STATUS—BLOCK, 10 manager copy data to the output buffer.

Step 405: The operating system kernel mode driver obtains a file operation request, and verifies the caller input. Parameters, and reconstruct (Captured) the user state address to the kernel state memory space;

Taking the file creation process as an example, the kernel part of the FSCreateFileW routine will execute the steps and process the corresponding caller input parameters in the kernel state memory space.

Step 406: If the input parameter verification is passed, searching for a corresponding file object parsing routine in the object manager according to the file path;

Step 407: If the corresponding file object parsing routine is found, the I/O request packet is generated according to the file object parsing routine, and sent to the original address of the preset file system lower layer device.

Taking the file creation process as an example, the kernel part of FSCreateFileW verifies the user-spaced parameters, builds the OpenPacket structure, loops through the file path format, and searches for the zippered object Hash table maintained by the object manager. Specifically, the path separator "V" can be used to disassemble the input file path, and the detached path part searches for the zippered object hash table maintained by the object manager to find the corresponding ParseProcedure. When the loop is parsed, it is found. The Parse Routine routine of the object. Parse Routine internally builds and populates the IRP request packet and sends it to the original address of the file system's underlying device to complete the file penetration creation process. At this point, the third-party filtering on the file system call stack The driver (other security software, driver-level malicious programs) is bypassed.

In the concrete implementation, the newly created object can also be inserted into the Hash structure of the object manager through the OblnsertObj ect routine, and the returned file handle is obtained. Moreover, the kernel can also synchronously call back the user state handle information and call the result. If the call fails, the user interface can set the corresponding error code so that the caller thread can get detailed error information through the GetLastError routine. The working principle of the file operation flow shown in FIG. 11 and the application of the embodiment of the present application is further illustrated.

The caller 111 invokes the driver interface layer 112 implemented in this embodiment instead of calling the kernel interface layer 113 of the prior art;

The driver interface layer 112 calls the simulated kernel execution layer check caller input parameter 114; After the caller input parameter verification is passed, executing the search object manager loop parsing the file path 115 to obtain the object parsing routine 116, and constructing an operation of sending the IRP to the file system lower layer device original address 117;

In this process, the file object parsing routine 118, the top filter driver al l9, and the underlying filter driver N120 in the prior art are penetrated.

After the IRP is sent to the file system lower layer device 121, the file system lower layer device 121 performs the operation requested by the IRP.

It should be noted that, for the method embodiment, for the sake of simple description, it is expressed as a series of action combinations, but those skilled in the art should understand that the present application is not limited by the described action sequence, because Application, some steps can be performed in other orders or at the same time. In addition, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present application. Referring to FIG. 12, a structural block diagram of an embodiment of a file operation execution apparatus of the present application is shown, which may specifically include the following modules:

The kernel state request obtaining module 121 is configured to obtain a file operation request, where the request includes a caller input parameter, where the input parameter includes a file path;

The kernel state parameter verification module 122 is configured to verify the caller input parameter according to the file operation request, and if the verification passes, call the kernel object parsing module 123;

The kernel state object parsing module 123 is configured to find a corresponding file object parsing routine in the object manager according to the file path; if the corresponding file object parsing routine is found, the kernel IRP generating sending module 124 is invoked;

The kernel state IRP generation sending module 124 is configured to generate an I/O request packet according to the file object parsing routine, and send the I/O request packet to a preset address of a preset file system lower layer device.

In a preferred embodiment of the present application, the kernel object parsing module 123 may specifically include the following modules; The file path disassembly module is configured to disassemble the path segment in the file path step by step according to the path separator;

In a specific implementation, the caller input parameter has a user mode address; the device may further include:

The kernel address reconstruction module is configured to reconstruct the user state address to the kernel state memory space. In a preferred embodiment of the present application, the following modules may also be included:

In a specific implementation, the following modules may also be included:

The wide-character routine calls the module, which is set to convert the ANSI-related parameters in the caller's input parameters to the UNICODE type, and call the corresponding file operation interface wide-character routine.

As an example of a specific application of the embodiment of the present application, the file operation interface routine may include a file creation routine FSCreateFile, and the device may further include the following module: a handle acquisition module, configured to insert a newly created file object to Object Manager, and get the returned file handle.

Since the device embodiment basically corresponds to the foregoing method embodiments shown in FIG. 1 , FIG. 2 and FIG. 3 , the description of the embodiment is not exhaustive, and reference may be made to the related description in the foregoing embodiment. I won't go into details.

The embodiment of the present application further discloses a computer readable recording medium on which a program for executing an execution method of a file operation is recorded, wherein the execution method of the file operation may include the following steps:

Obtaining a file operation request, where the request includes a caller input parameter, and the input parameter The number includes the file path;

Searching for a corresponding file object parsing routine in the object manager according to the file path; if the corresponding file object parsing routine is found, generating an I/O request packet according to the file object parsing routine, and sending the pre-process The original address of the underlying device of the file system.

The computer readable recording medium includes any mechanism for storing or transmitting information in a form readable by a computer (e.g., a computer). For example, a machine readable medium includes a read only memory

(ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash storage media, electrical, optical, acoustic or other forms of propagating signals (eg, carrier waves, infrared signals, digital signals, etc.). The application can be arranged in numerous general purpose or special purpose computing system environments or configurations. For example: personal computer, server computer, handheld or portable device, tablet device, multiprocessor system, microprocessor based system, set-top box, programmable consumer electronics device, network PC, small computer, mainframe computer, including A distributed computing environment of any of the above systems or devices, and the like.

The application can be described in the general context of computer-executable instructions executed by a computer, such as a program module. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform particular tasks or implement particular types of abstract data. The present application can also be practiced in a distributed computing environment where tasks are performed by remote processing devices that are connected through a communication network. In a distributed computing environment, program modules can be located in both local and remote computer storage media including storage devices.

The foregoing describes a method for executing a file operation and a device for executing a file operation provided by the present application. The specific examples are used herein to explain the principles and embodiments of the present application. The description of the above embodiment is only The method for understanding the present application and its core idea; at the same time, for those of ordinary skill in the art, according to the idea of the present application, there will be changes in specific embodiments and application scopes. The contents of the description should not be construed as limiting the application.

Claims

Claim

A method for executing a file operation, comprising:

2. The method according to claim 1, wherein the step of searching for a corresponding file object parsing routine in the object manager according to the file path comprises the following sub-steps; sub-step S1, determining whether the file path has been After the disassembly is completed, if not, sub-step S2 is performed; if yes, sub-step S4 is performed;

The method according to claim 1 or 2, wherein the caller input parameter has a user state address; before the file object parsing routine is searched, the method further comprises: reconstructing the user state Address to kernel mode memory space.

The method according to claim 1 or 2, wherein the I/O request packet includes file operation information extracted from a file operation request, and sends an I/O request packet to a preset file system. After the original address of the lower device, it also includes:

5. The method of claim 3, wherein the obtaining a file operation request Before, it also includes:

The caller initiates a file operation request, and invokes a corresponding file operation interface routine; wherein the request includes a caller input parameter, and the input parameter includes a file path;

The kernel state structure parameter is constructed according to the type of the system platform, and a corresponding file operation control code is generated according to the kernel state structure parameter, and the file operation control code is sent to the kernel mode driver of the operating system.

6. The method according to claim 5, further comprising: before constructing the kernel state structure parameter, further comprising:

The method of claim 6, wherein the file operation interface routine includes a file creation routine FSCreateFile, and before continuing to perform the requested file operation by the lower layer device of the file system, the method further includes:

Insert the newly created file object into the object manager and get the returned file handle.

8. The method of claim 1, further comprising:

9. The method according to claim 7, wherein the file operation interface routine and the WINDOWS standard API, the file operation interface routine further comprises: a file read routine FSReadFile, a file write example FSWriteFile, file property setting routine FSSetFileAttributes, file property get routine FSGetFileAttributes, file pointer setting routine FSSetFilePointer, enhanced file pointer setting routine FSSetFilePointerEx, file size get routine FSGetFileSize, file delete routine FSDeleteFile, directory removal routine FSRemoveDirectory, handle close routine FSCloseHandle, first file lookup routine FSFindFirstFile, next file lookup routine FSFindNextFile, file lookup close routine FSFindClose, add file property get routine FSGetFileAttributesEx, routine FSPathIsDirectory to determine whether the path is a directory, The routine FSPathFileExists, long path acquisition routine FSGetLongPathName, short path acquisition to determine whether the target file exists The routine FSGetShortPathName, the path lookup routine FSSearchPath, the enhanced file size get routine FSGetFileSizeEx, the file copy routine FSCopyFile, the file move routine FSMoveFile, and/or the enhanced file move routine FSMoveFileEx.

10. The method according to claim 9, wherein the control code comprises: a file creation operation control code FILE-10 - CREATE_FILE, a file read operation control code FILE-10 - READ_FILE, file write Input operation control code FILE_ 10 — WRITE — FILE, file query operation control code FILE — 10 — QUERY — FILE, file setting operation control code FILE — 10 — SET — FILE and / or file close preparation operation control code FILE — 10 — PREPARE—CLOSE.

11. An apparatus for performing file operations, comprising:

The apparatus according to claim 11, wherein the kernel object parsing module specifically includes:

The device according to claim 11 or 12, wherein the caller input parameter has a user mode address; the device further includes:

The kernel address reconstruction module is configured to reconstruct the user state address to the kernel state memory space.

14. The apparatus according to claim 13, further comprising: a user state request sending module, configured to initiate a file operation request by the caller, and invoke a corresponding file operation interface routine; wherein the request includes The caller inputs a parameter, and the input parameter includes a file path;

The device of claim 14, further comprising:

The device according to claim 15, wherein the file operation interface routine includes a file creation routine FSCreateFile, and the device further includes:

The device of claim 11, further comprising:

The kernel state parameter verification module is configured to check the caller input parameter according to the file operation request, and if the verification passes, the kernel object parsing module is called.

18. A computer readable recording medium having recorded thereon a program for executing the method of claim 1.