Hi All,
We are writing a driver that will be used to retrieve MBR of a disk. But we have to by-pass any hooks (SSDT, IRP etc) that tamper the data or deny access to MBR.
According to my analysis I come to conclusion that I have to roll my own IRPs. But I have following doubts…
- On which device object I have to roll the IRPs?
- What IOCTLs I can use for that? Is there any internal IOCTL provided by disk drivers to retrieve MBR?
- Is there any other way to do it?
Thanks & Regards,
Amit.
What are you going to do with the MBR? There are a number of calls that
get portions of it, so explain what you are doing and there may be a
better way.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@yahoo.com” wrote in
message news:xxxxx@ntfsd:
> Hi All,
>
> We are writing a driver that will be used to retrieve MBR of a disk. But we have to by-pass any hooks (SSDT, IRP etc) that tamper the data or deny access to MBR.
>
> According to my analysis I come to conclusion that I have to roll my own IRPs. But I have following doubts…
>
> 1. On which device object I have to roll the IRPs?
> 2. What IOCTLs I can use for that? Is there any internal IOCTL provided by disk drivers to retrieve MBR?
> 3. Is there any other way to do it?
>
> Thanks & Regards,
> Amit.
I am interested in Boot code. Actually I am checking system integrity for that I require MBR of the disk.
You can use HalExamineMBR to get the MBR, but of course any smart
malware that infects the MBR will have set a hook in the disk path to
return a clean MBR to you.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@yahoo.com” wrote in
message news:xxxxx@ntfsd:
> I am interested in Boot code. Actually I am checking system integrity for that I require MBR of the disk.
> 1. On which device object I have to roll the IRPs?
On disk device object (\.\PhysicalDrive%d or enumerate the Disk class GUID)
- What IOCTLs I can use for that? Is there any internal IOCTL provided by disk drivers to retrieve MBR?
IOCTL_DISK_GET_DRIVE_LAYOUT(_EX)
- Is there any other way to do it?
Read sector 0 and parse yourself.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
In general, there is no way to bypass kernel mode hooks that control reading MBR. The lowest known to me is Win32/Alureon (TDL3, TDL4 or whatever its called by various AVs), who installs its device object to the lowest possible place, which is atapi.sys or scsi.sys.
Hi Ladislav Zezula,
But the latest gmer & tdsskiller detect TDL3, TDL4 and that means it is possible to bypass them also.
The fact that you can detect a rootkit, doesn’t mean that you can bypass it.
Of course, you could kill the system thread that is watching TDL’s DRIVER_OBJECT, then unhook the DriverStartIo address in the TDL’s fake DRIVER_OBJECT that is on the bottom of the disk stack, and if your OS still haven’t bugchecked for some reason, you can then fire the SCSI IOCTL in order to read the MBR. But I wouldn’t bet much on stability of such product.
@OSR_Community_User said:
The fact that you can detect a rootkit, doesn’t mean that you can bypass it.
Of course, you could kill the system thread that is watching TDL analyzer DRIVER_OBJECT, then unhook the DriverStartIo address in the TDL’s fake DRIVER_OBJECT that is on the bottom of the disk stack, and if your OS still haven’t bugchecked for some reason, you can then fire the SCSI IOCTL in order to read the MBR. But I wouldn’t bet much on stability of such product.
That sounds very close to what I’ve experienced, too.