Principles of virtual optical drive-user layer

I have always been curious about the implementation of the virtual optical drive and want to try it. However, I have not found any useful information on the Internet. So it has never been implemented. I feel the lack of such materials. So I am going to study this technology.
In the absence of any information, the best way to study certain technologies is reverse. Select the software as the reverse target. It must not be too large. Or commercial software. So I chose the minicd software. This software is compressed with UPX. After compression, there are only several hundred kb. However, the author does some processing on the UPX compressed software, and the UPX-D cannot be decompressed. All of them have to be removed. The variation of UPX shell handoffs is almost a matter of seconds. Load with OD. One entry is a pushad pull down to see a popad and then a great jump. The jump address is OEP. After shelling, we found that it was written using Delphi. Written in Delphi. The best auxiliary cracking tool is Dede. However, after loading with Dede, you cannot see the form information, and an error is returned when you use exists to open the resource. This is the sequela of UPX compression after decompression. You can view the form information using rescope. There is also button information. You can find the event handling process by clicking the insert button. Then you can start the analysis. Of course, this article describes the implementation principle of the virtual Optical Drive. Attack Process and analysis process. No further explanation is provided here. An additional article will be published to describe the analysis process. The cracking process will not be discussed. You can find it everywhere on the Internet. Here. Only the analysis results are described.
Minicd implements virtual Optical Drive. Two files are completed together. A user-level exefile (minicd.exe ). A driver file (minicd.syslogs) is created by minicd.exe when the device fails to be created and no minicd.sysfile is found in the system32/Drivers/directory. This file is embedded in the minicd.exe directory)
Minicd.exe is used to send messages to the driver file to make the driver File work. The driver file virtualizes a device. Minicd.exe is also responsible for installing and starting the driver when the driver is not installed.
Therefore, we will introduce the implementation principles of the virtual optical drive in two articles. This article only describes what is done at the user level in minicd.exe. Minicd. sys is what is done in the driver file. In the next article.
We have to make some preparations to implement the functions. First, the next "Mini virtual disc" version on the internet is 1.0. I added a special pilu version. Run it. The purpose of this operation is to allow minicd to release the minicd. sys. Maps an ISO. After successful. You will find that a minicd. SYS file is added to the system32/DRIVERS directory. This is the driver file. He also installed the driver for you. Therefore, we can directly access it. To achieve the goal of virtualizing an optical drive. Next, let's talk about how to use a program to communicate with minicd.systo create a virtual optical drive (this is what minicd.exe has done ). As for how to install the driver without installing the driver, I am going to talk about how to install the driver after talking about the communication. This is because the driver has been installed by your downloaded minicd.exe.
Minicd. sys is a typical NT driver file, so it is necessary to implement communication with it, that is, the basic steps for communication with the NT driver. Of course, this is also done in minicd.exe. When the driver has been installed and started, you only need to take two simple steps.
Device = createfile ("//. // minicd ".......); // Use createfile to create a device (device name: //. // minicd). Unnecessary parameters are not listed here to describe the process.
Deviceiocontrol (device ,... Inbuffer,..., outbuffer ,.....); // Use deviceiocontrol to communicate with the device. You only need to use outbuffer here through inbuffer and outbuffer.
After knowing the steps, combine the following. The actual example of minicd.exe describes these two processes in detail.
Step 1:
Handle device = createfile ("//. // minicd ",
Generic_read,
File_pai_read,
0,
Open_existing,
0,
0 );
Createfile is an API function with 10 thousand performance. Many things can be done. Create files and pipelines. You can also create a driver. His prototype is as follows:
Handle createfile (
Lptstr lpfilename, // if the file is the file name, if the device is of course the device name
DWORD dwdesiredaccess, // access permission for the created object generic_read generic_write
DWORD dw1_mode, // share mode
Lpsecurity_attributes lpsecurityattributes, // Security Attribute. Generally, null is passed by default.
DWORD dwcreationdisposition, // object Creation Method
DWORD dwflagsandattributes, // you can set some other attributes or flag defaults.
Handle htemplatefile // default
);

I have discussed the functions of each parameter in the annotations. Here we will only make some necessary supplements.
The lpfilename here uses //. // minicd, which is the symbol name of the device. It is created using iocreatesymboliclink in the driver. Is used for user-Layer Program access driver name and device name is different. Of course, it doesn't matter if you don't understand it here. You only need to know how to use it here.
The access permission for dwdesiredaccess can be generic_read (read-only) generic_write (write-only)
Or generic_read | generic_write
The shared mode is used only when other programs use this object. File_1__read set here. That is, other processes can still read the data.
You can use the lpsecurityattributes flag by default. Used to set permissions. This is used by many APIs. For example, to implement shutdown, you must set the Security Attribute of your current process to allow shutdown. Otherwise, the security permissions of common user-layer processes cannot use the exitwindows function.
Dwcreationdisposition: Specifies the creation method, such as creating a file or returning an error, if the file does not exist. Of course, if you create a device, these problems do not exist. Set it to open_existing. If the driver is not installed, an error is returned.
You can use the other two default settings for additional attributes and flag settings. To create a file, you can set additional attributes or labels such as read-only. The difference from dwdesiredaccess is that dwdesiredaccess has the runtime permission. Here, the permissions of the file are set. Of course, these two attributes are not required for devices. Pass 0

After the device is created, it will communicate with the device. To communicate with the device (that is, to communicate with the driver), use deviceiocontrol to call this parameter in minicd.exe.

Wchar outbuffer [501] = l "MF: // developetool // sql2000sp4. ISO ";
DWORD buffersize = 0x3ea;

Deviceiocontrol (
Device,
0x22008,
Null,
0,
Outbuffer,
Sizeof (outbuffer ),
& Buffersize,
Null)

Prototype of this function
Bool deviceiocontrol (
Handle hdevice, // The device handle, that is, the return value of createfile.
DWORD dwiocontrolcode, // The control code driver can receive
Lpvoid lpinbuffer, // input buffer
DWORD ninbuffersize, // input buffer size
Lpvoid lpoutbuffer, // output buffer
DWORD noutbuffersize, // output buffer size
Lpdword lpbytesreturned, // This is a returned value and returns the size of the data stored in the output buffer by the driver.
Lpoverlapped // set null to keep it for use.
);
The hdevice annotation is clear.
The user-level instruction code (sent to irp_mj_device_control routine) sent to the driver at the dwiocontrolcode layer, which can be customized. The driver performs corresponding operations based on the passed instruction code. In minicd.exe, this script is obtained through shift and or operation. It is actually the ctl_code macro. You don't need to worry so much here. Just pass 0x22008 directly.
Lpinbuffer lpoutbuffer is used to exchange data with the driver. Here we only use lpoutbuffer. lpoutbuffer to point to an lpvoid. You must upload a unicode string. The string is as follows (listed above)
Wchar outbuffer [501] = l "MF: // developetool // sql2000sp4. ISO ";
The first character is M. It is the currently available drive letter you have obtained. That is, the drive letter you want to map. Of course, this is something you need to do on your own. It cannot be written here. I just used it for testing. There is a lot of information in this area. You can check it online. Followed by the full path of the ISO file to be mapped. In fact, such input should be placed in lpinbuffer, but it is not very nice to put it in lpoutbuffer. But it does not affect, because both inbuffer and outbuffer are treated equally in the driver. Both of them can be written or read in the buffer zone.

If the execution is successful. The optical drive has been virtualized out.

Analyze minicd. sys and find that the instruction code received in irp_mj_device_control is 0x22008. What we do is actually very simple.

1. Use iocreatedevice to create a device named minicd + drive index. For example, if it is an M disk, a device named minicd12 is created, where 12 is the value of (M-A. The device type is file_device_unknown. Generally, this type is used for Virtual Devices.

2. Use iocreatesymboliclink to create a symbolic link and associate it with the device. The Symbolic Link name is the drive letter you want to create.

To create an M disk, the symbol is M. When you use this function, if the symbolic name is a A-Z, the system automatically notifies the resource manager to create the corresponding disc.

Of course, this function is used at the driver layer. There is a function similar to it on the user layer, and the same function can be implemented. Yes

Definedosdevice (
_ In DWORDDwflags,
_ In lpctstrLpdevicename,
_ In lpctstrLptargetpath
);

The second parameter is the symbol name (if the symbol is a A-Z, the same system will automatically notify the resource manager to create the corresponding disc)

The third parameter is the device name.
Go through the above two steps. The corresponding drive letter has been created, and the system will send all operation commands (such as reading data and writing data) of this drive letter to the associated device. That is, the devices such as minicd12 mentioned earlier. Sending a device is actually sending it to the driver that creates the device (one driver can create multiple devices ). Therefore, the system will send all the operations on the newly created drive letter to the drive object corresponding to minicd. sys. And accurately distributed to various driver routines. Therefore, you only need to simulate the operation commands sent in the minicd. sys routines. And return the corresponding data as required to achieve virtual. For example. When you double-click the drive letter to view the drive letter, the system will actually package the operation into an IRP. It is concurrently sent to the irp_mj_read routine in minicd. sys. In this way, you only need to analyze the commands in IRP in this routine, operate the ISO file, and return the results to the operating system.

 

Now, the virtual work has been done. However, to work properly, you must use
Broadcastsystemmessage broadcasts messages to the System
The actual call in minicd.exe is like this.
Dev_broadcast_volume minicd;
Minicd. dbcv_size = 0x00000012;
Minicd. dbcv_devicetype = 0x00000002;
Minicd. dbcv_reserved = 0x00000001;
Minicd. dbcv_unitmask = 0x00001000;
Minicd. dbcv_flags = 0x0002;
Pdev_broadcast_volume pminicd = & minicd;
Broadcastsystemmessage (
Bsf_ignorecurrenttask,
Bsm_allcomponents,
Wm_devicechange,
0x8000, // dbt_devicearrival
(Lparam) pminicd );

Prototype of this function
Long broadcastsystemmessage (

DWORD dwflags, // flag value, used to set some broadcast methods
Lpdword lpdwrecipients, // specify the Message Receiver
Uint uimessage, // message number (Message Type)
Wparam, // extended message information
Lparam // It is generally different from wparam
);

This function is actually nothing to mention. It is no different from the commonly used sendmessage and other message processing functions. Here, only the actual parameters are described.
When this function is used in minicd.exe
Dwflags transmits bsf_ignorecurrenttask, that is, messages are not sent to themselves.
Lpdwrecipients is bsm_allcomponents, which broadcasts messages to all components, mainly to Windows Resource Manager.
Uimessage is wm_devicechange, which means that the message type is a device change message. This message is an internal message of the system.
Wparam is 0x8000. You can also directly write dbt_devicearrival. However, to reference the DBT. h header file, it means that the device has arrived.
Lparam is a pointer of the dev_broadcast_volume type. The dev_broadcast_volume type is an extension of dev_broadcast_hdr. The definition is as follows:
Typedef struct _ dev_broadcast_volume {
DWORD dbcv_size;
DWORD dbcv_devicetype;
DWORD dbcv_reserved;
DWORD dbcv_unitmask;
Word dbcv_flags;
} Dev_broadcast_volume,
* Pdev_broadcast_volume;
 
The definition of dev_broadcast_hdr is as follows:
Typedef struct _ dev_broadcast_hdr {
DWORD dbch_size;
DWORD dbch_devicetype;
DWORD dbch_reserved;
} Dev_broadcast_hdr,
* Pdev_broadcast_hdr;

Dbch_size indicates the size of the structure. If it is used in an extended structure, it is actually the sum of the size of this structure plus the size of other parts of the extended structure, that is, the size of the extended structure. For example
Dev_broadcast_volume minicd;
Minicd. dbch_size = 0x00000012; it is 0x12, that is, 18 bytes. This is obviously the size of dev_broadcast_volume.
Dbch_devicetype refers to the device type. What is the extended structure device type used. Here we use dev_broadcast_volume, so we use dbt_devtyp_volume (0x2)
Dbch_reserved is retained. Set it to 0x1.

This is an introduction to the structure of dev_broadcast_hdr. The first item of all extensions must be dev_broadcast_hdr. So we can see that the first three items defined by dev_broadcast_volume are the same as those defined by dev_broadcast_hdr. The name is different.
Next we will introduce it again. Dev_broadcast_volume extends two attributes. Check the fourth item of dev_broadcast_volume.
Dbcv_unitmask is very important. The specific meaning is hard to explain. It should be similar to the mask in the network. This is an integer value. That is to say, there are 32 bits. From right to left. Each digit is mapped to a drive letter. If the first digit on the right is 0
Disk. And so on. The second is disk B.
Do you still remember this sentence?
Wchar outbuffer [501] = l "MF: // developetool // sql2000sp4. ISO ";
From the previous introduction, we know that the drive letter to be mapped is M Disk. So naturally it should be in M minus the bit of A is 1. Then actually is 1 <(M-A) is 2 (M-A) power. So in order to test, no formula was used at the time. I just hardcoded A minicd. dbcv_unitmask = 0x00001000. Obviously 0x1000 is 2 (M-A) = 12 power.
The last dbcv_flags item can have two options.
Dbtf_media
Zero X 0001
Dbtf_net
Zero X 0002

Select dbtf_net to directly write 0x0002. If you want to write dbtf_net, reference DBT. h.

Okay. Here. Check whether the M Disk has been mapped out. Of course, if your M Disk is occupied. You have to change the disk for testing. If you change the disk. I know how to change it. The above is already clear. You only need to change the first character of the Unicode string in the lpoutbuffer of deviceiocontrol to the corresponding disc name. Of course, remember to re-calculate the dbcv_unitmask of the broadcastsystemmessage parameter lparam dev_broadcast_volume structure. Otherwise, the ing fails.
Through their introduction to the actually passed parameters. In fact, the role of Shu here is already obvious. It is to broadcast a message to all programs, drivers, and all objects except yourself in the system. That is to say, there is a device change (wm_devicechange). What is the change. The specified device has arrived (dbt_devicearrival. It is the M disk, which is a dbt_net network drive (in the dev_broadcast_volume structure ). In this way, Windows resource manager will receive such a message. He will create a drive letter in my computer.
Okay. By now, you can create a virtual optical drive when the driver (minicd. sys) has been installed and started.
Although a little sense of accomplishment, there is still a lot of work to do. For example. If the driver is not running minicd. EXE on a new machine, the driver is neither installed nor started. In this way, we cannot communicate with the device. Of course, do not be afraid. Next, let's continue. In the case of no driver. Install and start the driver (minicd. sys) dynamically ).
In addition to installing and starting the driver, there is also a problem of how to remove the ing after ing. Now it's faster. You have to go to bed early. Work is important. Otherwise, you will have no energy tomorrow.
Declaration: This article is only used to communicate with the technology of the virtual Optical Drive. All consequences caused by the original author of minicd. I am not responsible

 

At the same time, check out the problems mentioned by brotherbamboo in the reply below. Do not debug and use them in win7. minicd. sys is an NT driver. It may not be able to run normally in win7, and it is very troublesome to drive this thing once an error occurs. thank you for choosing brotherbamboo ..........