Why would you want to reverse engineer a well-documented function? The underlying mechanism, IOCTLs, are explained as part of the documentation for device drivers. Even the native function underlying the Win32 function DeviceIoControl
is documented.
To find out what a particular IOCTL code means (the 224CDCh
in your case), use one of the following methods:
- OSR IOCTL decoder
!ioctldecode
in WinDbg
- IOCTL reference list (your particular code isn't here, so apparently it's not a standard one)
The first one yields this:
Now, frankly, you provide waaaay too litte information to provide more help. But it stands to reason that in order to find out what valid inputs the underlying device driver expects, you should find out the driver to which the device object (the one you opened with CreateFileA
) belongs and then reverse engineer that. To find out, you can use a tool such as WinObj or similar. Because that driver is the place where the IRP (I/O Request Packet), which will be built internally by ZwDeviceIoControlFile
, ends up.
Edit: I just wanted to add the suggestion to have a look at the very latest WDK headers at all times. The tools mentioned above may not always be up-to-date. But in this particular case, from experience, I'd say it's a custom IOCTL.
cDc
in the hexadecimal representation of the code kinda makes me wonder if it's a reference to Cult of the Dead Cow. But without further knowledge of your target binary that's just a comment I wanted to squeeze in.DeviceIoControl
function does not return a null value[ebp+buffer]