IDA Free
The symbolic link provides a handle to the driver, and major functions define the driver's supported operations. We can use the I/O Control codes to uncover potential vulnerabilities.
Last updated
The symbolic link provides a handle to the driver, and major functions define the driver's supported operations. We can use the I/O Control codes to uncover potential vulnerabilities.
Last updated
Upon installing the MSI Ambient Link Driver locate the MSIO64.sys file, this can be found in the C:\Program Files (x86)\MSI\AmbientLink\Ambient_Link folder. Take a copy of the file and move it to your debugging host.
Open the file in IDA Free. We do not have a symbol file for the driver, this is fine.
Upon analyzing the MSIO64.sys file in IDA, we can identify the DriverEntry function in the functions window, but the Symbolic Link is not found within it. Instead, we encounter a jmp instruction that directs us to another function (sub_116C0).
Within this function, there is a reference to the Symbolic Link, denoted as \\Device\\MsIO, which serves as a means to obtain a handle to the driver:
We have a Symbolic Link, next we will discover how we can communicate with the driver from user mode.
If we look at sub_113F0 we can see that the IRP_MJ_DEVICE_CONTROL major function is being implemented based upon the DbgPrint call:
As mentioned in previous sections, the IRP_MJ_DEVICE_CONTROL major function is invoked from user mode through the use of the DeviceIoControl Win32 function. To successfully utilise this function, we must provide it with the appropriate I/O Control Code. In the following steps, we will enumerate all the available codes.
If we follow the assembly instructions from where we left off we can see that four values are being compared to the r11d register:
Each of these leads to a different code branch, and helpfully have an associated DbgPrint call, describing the I/O Control Code.
These codes are:
We have all the information we need to start looking for potential vulnerabilities. We could reverse engineer the code, and this is often neccessary. On this occassion we will fuzz the driver to see if we can cause the driver to crash; this also gives us an insight in to communicating with the driver through exploit code.
