understanding IOCTL

[electroRF]

hi,
I'd like to understand better how a process that runs on windows system approaches a physical driver using an IOCTL request to the kernel.

I'd like practicing the code which issues an IOCTL request to the driver.

Could you please share information on it?

It'd be very helpful to me.

Thank you very much.

 

[Ian Rogers]

Wouldn't we all.... Windows has tried very hard to hide io control as much as it can... Windows drivers have become a bit of an art form...

Can you expand on which IO you are particularly interested in.... Most issues are on the parallel or serial port...

 

[nsaspook]

hi,
I'd like to understand better how a process that runs on windows system approaches a physical driver using an IOCTL request to the kernel.

I'd like practicing the code which issues an IOCTL request to the driver.

Could you please share information on it?

It'd be very helpful to me.

Thank you very much.

Have you looked at the MSDN links? https://msdn.microsoft.com/en-us/library/windows/hardware/ff557560(v=vs.85).aspx

 

[electroRF]

Hi guys,
Thank you.

NSA, thanks I'm looking into it!

I'm looking for a job now, and I got "invitation" for a long test where they ask the following (among many other sections):

' you are given a code that is supposed to interface a windows driver by using a IOCTL.
You need to write somewhere in the code, your 'appeal' to the driver.
In the 'appeal' you send a password and should get back an ID.

You have an idea what it is about and how to practice it?

Thank you.

 

[MrAl]

Hi,

I/O control allows doing low level things with devices in the system.

In the Win API you could call "DeviceIoControl" which is located in the kernel dll. You need a handle to the device so you call CreateFile first, then you need the IoControlCode which you find in the SDK include files (or just the tag if your compiler already has found the constant defined in a Windows include file) and that tells the device what it is you want to do. The rest of the parameters for DeviceIoControl are for your allocated buffers for this functions input and output and to tell the function how large these buffers really are, and how many bytes were really returned, and if you are using an Overlapped structure.

There is more to it than that once you know what IoControlCode you want to use, but you can find out more about this by doing a search for "DeviceIoControl" and that should turn up an MS dev network link which will take you right to the MS site where the information on how to use this will be found.

It just so happens that i used this just the other day, just to write a quick USB Flash Drive Ejector program so i did not have to click "Safely Remove Hardware" anymore because i found i had to do that too often and sometimes it would fail and i'd have to do it again. I found that it would often fail the first time for almost no reason so it got to be a pain. With the program (very short program really) it tries to dismount several times before it reports an error, so if it fails then another program is definitely using the drive so i dont really want to dismount yet.
As an example of one of the control codes i had to use, to lock the volume i had to use:
FSCTL_LOCK_VOLUME

as the control parameter to DeviceIoControl, and if the function fails then something else in the system is still using the drive so i try several more times and if it fails all those times then i dont dismount it yet.

Here's a quick excerpt from the old WinHelp API help file:

BOOL DeviceIoControl(
HANDLE hDevice, // handle to device of interest
DWORD dwIoControlCode, // control code of operation to perform
LPVOID lpInBuffer, // pointer to buffer to supply input data
DWORD nInBufferSize, // size of input buffer
LPVOID lpOutBuffer, // pointer to buffer to receive output data
DWORD nOutBufferSize, // size of output buffer
LPDWORD lpBytesReturned, // pointer to variable to receive output byte count
LPOVERLAPPED lpOverlapped // pointer to overlapped structure for asynchronous operation
);