0

While reverse engineering a windows executable I found the DeviceIoControl function, and i'm trying to figure out the correct inputs so it does not return a zero, it get's the [ebp+hDevice] from the return of the CreateFileA function, the [ebp+buffer] address stores a value that was read earlier from the input, it's the only variable that I have control over enter image description here

can anyone explain what the DeviceIoControl function works, and how can I get it to return something eles than 0, thank you!!

4
  • It would be a lot better to post the text form here. Images still can't be indexed the same as plain text by search engines.
    – 0xC0000022L
    May 28, 2018 at 7:44
  • Just a guess, since this is a free-form IOCTL code. 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.
    – 0xC0000022L
    May 28, 2018 at 14:21
  • @Biswapriyo what i'm trying to know is what are the possible inputs so that the DeviceIoControl function does not return a null value May 28, 2018 at 23:47
  • thank's for the additional informations @0xC0000022L , if this might help; the binary is a CTF challenge that loads a kernel driver and uses it to check if the flag is correct or not, and the only variable that goes to this function and I have control over is [ebp+buffer] May 28, 2018 at 23:53

1 Answer 1

3

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:

  1. OSR IOCTL decoder
  2. !ioctldecode in WinDbg
  3. IOCTL reference list (your particular code isn't here, so apparently it's not a standard one)

The first one yields this:OSR IOCTL decoder in action for code 0x224CDC

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.

2
  • The website 'OSR IOCTL decoder' uses a JavaScript to decode. Sometimes WDK has not the undocumented IOCTL values. So how can I decode that?
    – Biswapriyo
    Jul 6, 2018 at 9:01
  • 1
    Actually I think you may be misunderstanding. The WDK does usually carry all the relevant IOCTLs for Windows components you interact with from another driver or user mode. However, as any third-party can define their own IOCTLs, these will not be contained. You can decode them exactly as pointed out above (there's no difference), however you won't be able to give that IOCTL a meaningful name without deducing its meaning from analyzing the target disassembly, for example.
    – 0xC0000022L
    Jul 6, 2018 at 9:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.