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!!

  • 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 '18 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 '18 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 – MJanaTii May 28 '18 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] – MJanaTii May 28 '18 at 23:53
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.

| improve this answer | |
  • 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 '18 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 '18 at 9:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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