CN117785563A - Method for mounting backup mirror image into Windows volume - Google Patents

Abstract

The invention discloses a method for mounting a backup mirror image into a Wi windows volume, which comprises the following steps: step S1, initializing a driver: creating a device of the type disk; s2, calling an object E; step S3, initializing a linked list object L, step S4, creating a working thread for the disk device, and step S5, designating a distribution function of a drive unloading routine for a driver; s6, inserting the IRP containing the user layer input parameters into a linked list L; in step S7, the event object E triggers a worker thread. By the method, after the backup mirror image is mounted as the Wi-windows volume, a user can directly access the volume in the resource manager, and the backup mirror image is not different from a common local disk volume. Thus, the data and the program in the mirror image can be conveniently browsed, copied, edited and run, and the convenience of operation is improved.

Description

Method for mounting backup mirror image into Windows volume

Technical Field

The invention belongs to the technical field of data security, and particularly relates to a method for mounting a backup image into a Windows volume.

Background

Because most backup software in the market adopts a backup mode that data to be backed up is pressurized and encrypted, if a user wants to browse the content in an image file, the user needs to restore the image file once and then can see the data in the image file, even if only a small amount of data is needed, the user needs to restore the image file once, the user is very complex, and the user does not have spare disks to restore the image file, the invention provides a method capable of directly mounting the image file backed up by a disk, a partition and a system as a virtual volume and supporting reading, so that the user can conveniently check the data in the backup source volume, copy number from the image file, directly open the file of the image file and run programs in the image file.

Disclosure of Invention

The invention aims to provide a method for mounting a backup mirror image into a Windows volume, which solves the problems that in the prior art, users want to obtain partial data from a backed-up mirror image file, the users cannot view the data in the mirror image file and run programs in the mirror image file, and the traditional method needs to restore the whole mirror image file to find the required file.

In order to solve the technical problems, the invention adopts the following technical scheme:

a method of mounting a backup image as a Windows volume, comprising the steps of:

step S1, initializing a driver: firstly, creating a temporary directory F under a Windows NT object manager namespace; then creating a device with the type of a disk through the IoCreateDeviceSecure under the temporary directory F;

step S2, after the equipment is successfully created, calling a KeInitializeEvent to initialize an event object E in the device_EXTENSION;

specifically, E refers to an Event object, which is a kernel object of Windows and is used for representing an Event;

s3, calling an InitialistHead to initialize a linked list object L, wherein the linked list object L is used for storing IRP requests; the extension parameters of the device comprise a handle V of a volume object in the mirror image, a file handle H, a device number N, a drive letter D and a mirror image file reading object;

step S4, creating a working thread for the disk device by calling PsCreateSystemThread, wherein the working thread is used for receiving the notification of the event object E;

step S5, assigning dispatch functions of three events, namely IRP_MJ_CREATE, IRP_MJ_CLOSE, IRP_MJ_READ, IRP_MJ_WRITE, IRP_MJ_DEVICE_CONTROL, and dispatch functions of a drive unloading routine to the drive program;

step S6, when the IRP_MJ_DEVICE_CONTROL routine of the driver receives the information of the mounted volume from the user layer, the IRP containing the parameters of the user layer is inserted into the linked list L, and KeSetEven is called to trigger the event object E of the corresponding DEVICE;

step S7, triggering a working thread by the event object E, and enabling the working thread to enter a working state;

step S701, firstly, an IRP request is acquired from a linked list L, if the acquired IRP request is a request for mounting an image file, the corresponding image file is opened according to the path and version information of the image file transmitted by a user layer, a corresponding version is found from a version chain of the image file, and then an object of a corresponding volume is acquired from the corresponding version through an image file module;

step S702, if the image file is successfully opened, storing the handle of the volume object into the handle V of the volume object of the extension information of the device object; if the image file is opened, returning an error code of a reason of failure to a user layer and ending the current IRP;

step 703, the driver program creates a drive for the device according to the drive parameter transmitted from the user layer, if the drive is created successfully, the drive returns success to the user layer and ends the IRP, if the drive fails to create, the open mirror file needs to be closed and the failed error code information is returned to the user layer;

after the above steps are completed, there is a disk character designated by the user layer in the Wi windows resource manager, so that the user can directly access the volume, copy the data therein and run the program therein.

According to the above technical solution, in step S1, the security descriptor string "D: P (a; GA; SY; a; GA; BA; GA; BU; (a; GA; AU; GA; I U)" needs to be specified when invoking I oCreateDevi ceSecure, and the created device is set to the read-only state.

According to the above technical solution, in step S701, if the lrp request obtained from the linked list L is a read request, the volume data is read by the following steps:

step A1, obtaining an IRP request from a linked list L of equipment, and obtaining a starting position and a total byte number to be read from parameters of the IRP request;

a2, converting the initial byte and the total byte into sectors, wherein the initial sector is equal to the initial byte divided by the byte number of each sector, and the total sector is equal to the total byte number to be read divided by the byte number of each sector;

step A3, according to the total byte number transmitted by the IRP request, a temporary cache memory space with the type PagePool is distributed through the ExAllocatePool,

step A3, if V in the device_EXTENSION is not null, reading the data of the starting sector plus the total sector corresponding to the starting sector into a cache by calling a read interface of the mirror module;

specifically, V refers to a volume object, and reading data in a certain volume is achieved through the volume object, because the data of incremental backup may exist in multiple image files, and correct data is fetched from which image file is processed through the volume object;

step A4, if V in the extension information is empty and the file handle H is not empty, the user layer needs to read the file data of the volume; reading data to a buffer area through ZwReadFile and using a handle H of the file;

and step A5, if the data is successfully read into the buffer area, copying the data in the buffer area into the buffer area imported by the R3, informing the user layer that the reading is successful, if the data fails, returning an error code of a failure reason corresponding to the user layer, and finally releasing the temporary memory buffer and setting the IRP into a finished state.

According to the above technical solution, in step S701, the IRP request obtained from the linked list L is a WRITE request, and the message of the WRITE failure is directly returned in the irp_mj_write routine.

According to the above technical solution, in step S701, the request for obtaining the IRP from the linked list L is a request from the upper layer for obtaining the volume size, and is returned to the Windows resource manager according to the size information transmitted from R3 during mounting.

According to the above technical solution, in step S701, if the request for obtaining the IRP from the linked list L is an uninstall signal of the user layer application, the V object in the extension parameter in the corresponding device object is closed, and the drive letter of the corresponding device is deleted.

According to the above technical solution, in step S701, the request for obtaining the IRP from the linked list L is irp_mj_device_control from the upper layer and is a request for opening the file;

the driver will first use the security attributes entered at the user level to simulate the access rights of the current thread of the driver as having the access rights at the user level,

then, the file is opened by calling ZwCreateFile, if the opening is successful, the name and handle information of the file are stored in the extension attribute of the device object, and the access authority of the file needs to be designated as shared reading when the opening is performed,

and finally, obtaining the size of the file and the alignment condition of the buffer area at the bottom layer of the file through the ZwQueryInformationFile, storing the obtained size and the alignment condition into an expansion structure of the file equipment information, and returning a successful notification to a user layer.

According to the above technical solution, in step S701, the request for obtaining the IRP from the linked list L is an irp_mj_device_control request from an upper layer, and the request type is an operation for closing the file;

the driver will close the H handle in the extension information of the device object and turn over the resources related to the release file and the related parameters restore the initial value and set the completion status of the IRP.

Compared with the prior art, the invention has the following beneficial effects:

by the method of the invention, after the backup mirror image is mounted as the Windows volume, the user can directly access the volume in the resource manager, and the backup mirror image is not different from the common local disk volume. Thus, the data and the program in the mirror image can be conveniently browsed, copied, edited and run, and the convenience of operation is improved.

By mounting the backup image as a Wi-windows volume, lost or corrupted data can be recovered directly from the image. Meanwhile, new data can be backed up to the mirror image, so that safe storage and backup of the data are realized. After the backup image is mounted as a Wi windows volume, it can be used as a basis for a virtualized environment or a test environment. For example, images may be mounted into virtual machines to run and test applications in isolated environments, thereby reducing dependencies on actual hardware and systems.

Drawings

FIG. 1 is a main service logic flow diagram of R0 of the present invention;

FIG. 2 is a flow chart of business logic of a worker thread for R0 according to the present invention;

FIG. 3 is a logic flow diagram of R3 of the present invention.

Detailed Description

The following description of the embodiments of the present invention will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.

Example 1

As shown in fig. 1 and 2, a method for mounting a backup image into a Wi windows volume includes the following steps:

step S1, initializing a driver: firstly, creating a temporary directory F under a Windows NT object manager namespace; then creating a device with the type of a disk through the IoCreateDeviceSecure under the temporary directory F;

step S2, after the equipment is successfully created, calling a KeInitializeEvent to initialize an event object E in the device_EXTENSION;

e refers to an Event object, which is a kernel object of Windows and is used for representing an Event;

s3, calling an InitialistHead to initialize a linked list object L, wherein the linked list object L is used for storing IRP requests; the extension parameters of the device comprise a handle V of a volume object in the mirror image, a file handle H, a device number N, a drive letter D and a mirror image file reading object;

step S4, creating a working thread for the disk device by calling PsCreateSystemThread, wherein the working thread is used for receiving the notification of the event object E;

step S5, assigning dispatch functions (the dispatch functions are actually pointers of one function) of three events, namely IRP_MJ_CREATE, IRP_MJ_CLOSE, IRP_MJ_READ, IRP_MJ_WRITE, IRP_MJ_DEVICE_CONTROL, and a dispatch function of a drive unloading routine to the drive program;

step S6, when the IRP_MJ_DEVICE_CONTROL routine of the driver receives the information of the mounted volume from the user layer, the IRP containing the parameters of the user layer is inserted into the linked list L, and KeSetEven is called to trigger the event object E of the corresponding DEVICE;

step S7, triggering a working thread by the event object E, and enabling the working thread to enter a working state;

step S701, firstly, an IRP request is acquired from a linked list L, if the acquired IRP request is a request for mounting an image file, the corresponding image file is opened according to the path and version information of the image file transmitted by a user layer, a corresponding version is found from a version chain of the image file, and then an object of a corresponding volume is acquired from the corresponding version through an image file module;

since more than one image file is not complete, some image files need to be added to the previous image files to read the version of data, so that the single image file is useless, an open version mode is needed, and if the version is open, the image management module can automatically associate the needed image files.

Step S702, if the image file is successfully opened, storing the handle of the volume object into the handle V of the volume object of the extension information of the device object; if the image file is opened, returning an error code of a reason of failure to a user layer and ending the current IRP;

since it is not useful to open only a single image, the user's data is a chain store, and the data in version N may be in versions N-1, N-2.

Step 703, the driver program creates a drive for the device according to the drive parameter transmitted from the user layer, if the drive is created successfully, the drive returns success to the user layer and ends the IRP, if the drive fails to create, the open mirror file needs to be closed and the failed error code information is returned to the user layer;

after the above steps are completed, there is a disk character designated by the user layer in the Wi windows resource manager, so that the user can directly access the volume, copy the data therein and run the program therein.

By the method, after the backup mirror image is mounted as the Wi-windows volume, a user can directly access the volume in the resource manager, and the backup mirror image is not different from a common local disk volume. Thus, the data and the program in the mirror image can be conveniently browsed, copied, edited and run, and the convenience of operation is improved.

By mounting the backup image as a Windows volume, lost or corrupted data can be recovered directly from the image. Meanwhile, new data can be backed up to the mirror image, so that safe storage and backup of the data are realized. After the backup image is mounted as a Windows volume, it can be used as the basis for a virtualized environment or test environment. For example, images may be mounted into virtual machines to run and test applications in isolated environments, thereby reducing dependencies on actual hardware and systems.

Example two

This embodiment is a further refinement of embodiment one.

In step S1, the security descriptor string "D: P (a; GA;; SY; (a;) GA; (BA; (a;) GA; (b;) BU; (a; (GA;) GA; (AU; (a; (GA;)") needs to be specified when the IoCreateDeviceSecure is invoked, and the created device is set to a read-only state.

In step S701, if the IRP request acquired from the linked list L is a read request, the volume data is read by:

step A1, obtaining an IRP request from a linked list L of equipment, and obtaining a starting position and a total byte number to be read from parameters of the IRP request;

a2, converting the initial byte and the total byte into sectors, wherein the initial sector is equal to the initial byte divided by the byte number of each sector, and the total sector is equal to the total byte number to be read divided by the byte number of each sector;

step A3, according to the total byte number transmitted by the IRP request, a temporary cache memory space with the type PagePool is distributed through the ExAllocatePool,

step A3, if V in the DEVICE_EXTENSION is not null, reading the data of the starting sector plus the total sector, which corresponds to the starting sector, into a cache by calling a read interface of the mirror module;

step A4, if V in the extension information is empty and the file handle H is not empty, the user layer needs to read the file data of the volume; reading data to a buffer area through ZwReadFile and using a handle H of the file;

and step A5, if the data is successfully read into the buffer area, copying the data in the buffer area into the buffer area imported by the R3, informing the user layer that the reading is successful, if the data fails, returning an error code of a failure reason corresponding to the user layer, and finally releasing the temporary memory buffer and setting the IRP into a finished state.

In step S701, the IRP request is obtained from the linked list L as a WRITE request, and a message of WRITE failure is directly returned in the irp_mj_write routine.

In step S701, the request for obtaining the IRP from the linked list L is a request from the upper layer for obtaining the volume size, and is returned to the Windows resource manager according to the size information transferred from R3 during mounting.

In step S701, if the request for obtaining the IRP from the linked list L is an uninstall signal of the user layer application, the V object in the extension parameter in the corresponding device object is closed, and the drive letter of the corresponding device is deleted.

In step S701, the request for obtaining the IRP from the linked list L is irp_mj_device_control from the upper layer, and is a request for opening the file;

the driver will first use the security attributes entered at the user level to simulate the access rights of the current thread of the driver as having the access rights at the user level,

then, the file is opened by calling ZwCreateFile, if the opening is successful, the name and handle information of the file are stored in the extension attribute of the device object, and the access authority of the file needs to be designated as shared reading when the opening is performed,

and finally, obtaining the size of the file and the alignment condition of the buffer area at the bottom layer of the file through the ZwQueryInformationFile, storing the obtained size and the alignment condition into an expansion structure of the file equipment information, and returning a successful notification to a user layer.

In step S701, the request for obtaining the IRP from the linked list L is an irp_mj_device_control request from an upper layer, and the request type is an operation for closing the file;

the driver will close the H handle in the extension information of the device object and turn over the resources related to the release file and the related parameters restore the initial value and set the completion status of the IRP.

Example III

The invention is characterized in that:

the R0 driver needs to handle things and steps:

the driver will first create a temporary directory F under Windows NT object manager namespace at initialization, then create 26 devices of disk type under F by IoCreateDeviceSecure, call IoCreateDeviceSecure, need to specify the security descriptor string "D: P (A; GA; SY) (A; GA; BA) (A; GA; BU) (A; GA; AU) (A; GA; IU)", and set the created devices to read-only state. After each DEVICE is successfully created, the event object E in the device_EXTENSION needs to be called, and the event object E is used for notifying the working thread that the event trigger exists, so that the working thread enters a working state. And meanwhile, an InitialistHead needs to be called to initialize a linked list object L, wherein the linked list object is used for storing IRP requests, and the expansion parameters of the device comprise a handle V of a volume object in the mirror image, a file handle H, a device number N, a disk drive D, a mirror image file reading object and the like.

When the disk devices are created, the PsCreateSystemThread is called simultaneously to create a working thread for each disk device, and the initial state of each working thread waits for the triggering of each event object created in the step 1.

The driver is assigned the distribution functions of irp_mj_create, irp_mj_close, irp_mj_read, irp_mj_write, irp_mj_device_control, and drive unload routines until the driver's preparation is completed.

When the irp_mj_device_control routine of the driver receives a message from the user layer's mounted volume, the IRP containing the user layer's incoming parameters is inserted into the linked list L created in step 1 and KeSetEvent is invoked to trigger the event object E of the corresponding DEVICE created in step 1.

After the corresponding event object in the thread created in the step 1 is triggered in the step 4, the working thread enters a working state, firstly, an IRP request is acquired from a linked list L created in the step 1, if the IRP request is a request for mounting an image file, the corresponding image file is opened through an image file module according to the path and version information of the image file which is input by the R3, a corresponding version is found out from a version chain of the image file, an object of a corresponding volume is acquired from the corresponding version through the image file module, if the object is successful, a handle of the volume to the object is stored in a volume object handle of the extension information of the device object, if the object fails, an error code of a reason of the failure is returned to a user layer and the current IRP is ended, after the current IRP is successful, a driver can create a disk for the device according to the disk character parameters which are input by the user layer, so that the disk can be directly seen in a Windows resource manager, and the disk character is the data in the accessed image file, if the disk character creation is successful, the user layer returns success and ends the IRP to the user layer, if the creation of the disk character is successful, if the image file is required to be closed, and if the creation fails, the error code of the opened file is returned to the user layer. If the execution is successful, then there will be one more disk character designated by R3 in the Windows resource manager, and the user can open the volume, copy the data and run the programs inside as if accessing a normal Windows disk.

If the driver receives the read message, the read message is posted to the corresponding link L created by the corresponding device in step 1, and the event object device in the corresponding device object extension parameter is set to be in a trigger state.

And (3) after receiving the event triggered by the event object in the step (6) in the working thread of the corresponding equipment, obtaining an IRP request from a linked list L of the corresponding equipment, judging whether the operation is a read operation, if the operation is the read operation, obtaining a starting position and the total byte number which need to be read from parameters of the IRP, converting the starting byte and the total byte into sectors, wherein the starting sector is equal to the starting byte divided by the byte number of each sector, and the total sector is equal to the total byte number which needs to be read divided by the byte number of each sector. And distributing a temporary cache memory space with the type PagePool through an ExallocatePool according to the total byte number transmitted by the IRP, if V in the extension information is not null, reading the data of the total sector of the initial sector caused by the corresponding initial sector into a cache through a read interface of a calling mirror module, if V in the extension information is null and a file handle H is not null, judging that the user layer needs to read file data of a volume, reading the data into a buffer area through ZwReadFile and using the handle H of the file, if the data is successful, copying the data in the cache into the buffer area transmitted by R3, notifying the user layer of successful reading, if the data is failed, returning an error code of a failure reason corresponding to the user layer, finally releasing the temporary memory cache and setting the IRP into a finished state.

If a WRITE request is received in the driver, a message of a WRITE failure is returned directly in the irp_mj_write routine, because the image file is usually only readable and cannot be written.

If the driver receives a message from the upper layer to acquire the volume size, the driver returns the size information transmitted from R3 to the Windows resource manager according to the size information during mounting.

If the driver receives a request from the upper layer to get a volume writable, the driver returns a status_media_write_processed message directly indicating that the volume is not writable.

If the driver receives a message from an upper layer updating partition, the driver returns a status_media_write_processed message indicating that the volume is not writable, so no update operation can be performed on the volume.

If the uninstalling signal of the user layer application program is received, the V object in the expansion parameter in the corresponding equipment object is closed, and the drive letter of the corresponding equipment is deleted, so that the virtual drive letter in the Windows resource manager can be deleted.

If an IRP_MJ_DEVICE_CONTROL request from an upper layer is received, and a request for opening a file is firstly simulated by using a security attribute transmitted by a user layer, the access right of a current thread of the driver is simulated to have the access right of the user layer, then the file is opened by calling ZwCreateFile, if the opening is successful, the name and handle information of the file are stored in an extended attribute of the DEVICE object, and the access right of the file is required to be designated as shared reading when the opening is successful, because the file in the mirror file is not allowed to be modified, finally the size of the file and the alignment condition of a buffer area at the bottom of the file are obtained through ZwQueryInformationFile and are stored in an extended structure of the DEVICE information of the file, and then a successful notification is returned to the user layer.

If an IRP_MJ_DEVICE_CONTROL request is received from the upper layer and the request type is the operation of closing the file, the driver closes the H handle in the extension information of the DEVICE object, turns over the resources related to the release file and the related parameters to restore the initial values, and sets the completion state of the IRP.

The step of the user layer application:

the user obtains a version list of the image file according to the task or the path of the image file, the program displays the obtained version list to the user, the user selects a version to be mounted according to the version list displayed by the program, the program displays the volume information in the image file to the user according to the version selected by the user, the application program displays the free disk symbol information of the current Windows system to the user, the user selects the volume to be mounted, and an idle disk symbol is designated for the volume to be displayed.

The application program transmits the information such as the path of the mirror image file selected by the user, the version to be mounted, the size of the volume, the ID of the volume, the password, the task name, the GUID of the task and the like to a device object created by R0 in a control code mode, the device object receives the information of mounting the volume after being called, the driver program executes the mounting logic, if the driver program successfully sees a disk character designated by the user in the Windows resource manager, the user can access the data of the mirror image file like accessing the Windows local disk.

Interpretation of technical terms:

in the invention, the following components are added: ioCreateDeviceSecure, keInitializeEvent, initializeListHead, psCreateSystemThread, keSetEvent and ZwQueryInformationFile are APIs in the operating system.

In the present invention, device_EXTENSION is a data structure in an operating system.

In the present invention, IRP_MJ_CREATE, IRP_MJ_CLOSE, IRP_MJ_READ, IRP_MJ_WRITE, IRP_MJ_DEVICE_CONTROL are all a value defined in the operating system.

IRP: IRP (I/orrequest Packet) in Windows is a data structure for representing an input/output (I/O) operation request. For managing and tracking I/O requests for various device drivers. When an application or system needs to interact with a device (e.g., read a file, send data to a network device, etc.), the operating system creates an IRP to describe the request, which is then passed to the appropriate device driver to perform the requested operation.

And (3) coiling: the highest level of organization in the file system is volume. The file system resides on a volume. The volume contains at least one partition, which is a logical division of the physical disk. Volumes containing data that exist on one partition are referred to as simple volumes, volumes containing data that exist on multiple partitions are referred to as multi-partition volumes.

Event object: (Kernel Event) is a mechanism in an operating system for handling asynchronous Event notifications and synchronization. It is primarily used to provide efficient I/O event notification and handling so that applications can more efficiently perform asynchronous operations and event handling.

Handle: handle is a term commonly used in computer science to generally refer to a reference or identification of a resource or object. Such as memory, files, graphical interface elements, etc. A handle may be viewed as an abstract identifier that is used to uniquely identify a particular resource.

Linked list: linked lists (lists) are a common data structure in computer science for storing a series of elements, each of which is called a Node (Node).

It is noted that relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus.

Finally, it should be noted that: the foregoing description is only a preferred embodiment of the present invention, and the present invention is not limited thereto, but it is to be understood that modifications and equivalents of some of the technical features described in the foregoing embodiments may be made by those skilled in the art, although the present invention has been described in detail with reference to the foregoing embodiments. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims (8)

1. A method for mounting a backup image into a Windows volume is characterized in that: the method comprises the following steps:

step S1, initializing a driver: firstly, creating a temporary directory F under a Windows NT object manager namespace; then creating a device with the type of a disk through the IoCreateDeviceSecure under the temporary directory F;

step S2, after the equipment is successfully created, calling a KeInitializeEvent to initialize an event object E in the device_EXT ENSION;

s3, calling an InitialistHead to initialize a linked list object L, wherein the linked list object L is used for storing IRP requests; the extension parameters of the device comprise a handle V of a volume object in the mirror image, a file handle H, a device number N, a drive letter D and a mirror image file reading object;

step S4, creating a working thread for the disk device by calling PsCreateSystemThread, wherein the working thread is used for receiving the notification of the event object E;

step S5, assigning dispatch functions of three events, namely IRP_MJ_CREATE, IRP_MJ_CLOSE, IRP_MJ_READ, IRP_MJ_WRITE, IRP_MJ_DEVICE_CONTROL, and dispatch functions of a drive unloading routine to the drive program;

step S6, when the IRP_MJ_DEVICE_CONTROL routine of the driver receives the information of the mounted volume from the user layer, the IRP containing the parameters of the user layer is inserted into the linked list L, and KeSetEven is called to trigger the event object E of the corresponding DEVICE;

step S7, triggering a working thread by the event object E, and enabling the working thread to enter a working state;

step S701, firstly, an IRP request is acquired from a linked list L, if the acquired IRP request is a request for mounting an image file, the corresponding image file is opened according to the path and version information of the image file transmitted by a user layer, a corresponding version is found from a version chain of the image file, and then an object of a corresponding volume is acquired from the corresponding version through an image file module;

step S702, if the image file is successfully opened, storing the handle of the volume object into the handle V of the volume object of the extension information of the device object; if the image file is opened, returning an error code of a reason of failure to a user layer and ending the current IRP;

step 703, the driver program creates a drive for the device according to the drive parameter transmitted from the user layer, if the drive is created successfully, the drive returns success to the user layer and ends the IRP, if the drive is created failed, the open image file needs to be closed and the failed error code information is returned to the user layer;

after the above steps are completed, there is a disk character designated by the user layer in the resource manager of Windows, and the user can directly access the volume, copy the data therein and run the program therein.

2. The method of mounting a backup image as claimed in claim 1, wherein: in step S1, the security descriptor string "D: P (a; GA;; SY; (a;) GA; (BA; (a;) GA; (b;) BU; (a; (GA;) GA; (AU; (a; (GA;)") needs to be specified when the IoCreateDeviceSecure is invoked, and the created device is set to a read-only state.

3. The method of mounting a backup image as claimed in claim 1, wherein: in step S701, if the IRP request acquired from the linked list L is a read request, the volume data is read by:

step A1, obtaining an IRP request from a linked list L of equipment, and obtaining a starting position and a total byte number to be read from parameters of the IRP request;

a2, converting the initial byte and the total byte into sectors, wherein the initial sector is equal to the initial byte divided by the byte number of each sector, and the total sector is equal to the total byte number to be read divided by the byte number of each sector;

step A3, according to the total byte number transmitted by the IRP request, a temporary cache memory space with the type PagePool is distributed through the ExAl location pool,

step A3, if V in the device_EXTENSION is not null, reading the data of the starting sector plus the total sector corresponding to the starting sector into a cache by calling a read interface of the mirror module;

step A4, if V in the extension information is empty and the file handle H is not empty, the user layer needs to read the file data of the volume; reading data to a buffer area through ZwReadFile and using a handle H of the file;

and step A5, if the data is successfully read into the buffer area, copying the data in the buffer area into the buffer area imported by the R3, informing the user layer that the reading is successful, if the data fails, returning an error code of a failure reason corresponding to the user layer, and finally releasing the temporary memory buffer and setting the IRP into a finished state.

4. The method of mounting a backup image as claimed in claim 1, wherein: in step S701, the IRP request is obtained from the linked list L as a WRITE request, and a message of WRITE failure is directly returned in the irp_mj_write routine.

5. The method of mounting a backup image as claimed in claim 1, wherein: in step S701, the request for obtaining the IRP from the linked list L is a request from the upper layer for obtaining the volume size, and is returned to the Windows resource manager according to the size information transferred from R3 during mounting.

6. The method of mounting a backup image as claimed in claim 1, wherein: in step S701, if the request for obtaining the IRP from the linked list L is an uninstall signal of the user layer application, the V object in the extension parameter in the corresponding device object is closed, and the drive letter of the corresponding device is deleted.

7. The method of mounting a backup image as claimed in claim 1, wherein: in step S701, the request for obtaining the IRP from the linked list L is irp_mj_device_control from the upper layer, and is a request for opening the file;

the driver will first use the security attributes entered at the user level to simulate the access rights of the current thread of the driver as having the access rights at the user level,

then, the file is opened by calling ZwCreateFile, if the opening is successful, the name and handle information of the file are stored in the extension attribute of the device object, and the access authority of the file needs to be designated as shared reading when the opening is performed,

and finally, obtaining the size of the file and the alignment condition of the buffer area at the bottom layer of the file through the ZwQueryInformationFile, storing the obtained size and the alignment condition into an expansion structure of the file equipment information, and returning a successful notification to a user layer.

8. The method of mounting a backup image as claimed in claim 1, wherein: in step S701, the request for obtaining the IRP from the linked list L is an irp_mj_device_control request from an upper layer, and the request type is an operation for closing the file;

the driver will close the H handle in the extension information of the device object and turn over the resources related to the release file and the related parameters restore the initial value and set the completion status of the IRP.