1

I searched all places in IDA that call the imported WriteFile function and put a breakpoint on them.

But while debugging I saw with ProcMon that my exe wrote to the file but even though it did not stop on the breakpoint. I also saw that file was written to.

Why is that?

Improve this question
5
  • it might be accessing a lower level write api such as NtWriteFile, maybe try breaking on it instead? also, by hitting ctrl+x you can see where a function is being used. (cross reference)
    – user22970
    Jul 31, 2018 at 15:55
  • @Amirag: ... or higher-level such as those from the C runtime (fwrite, fprintf and other members of that family). Because if the application isn't statically linked these imports would be imports of the C runtime DLLs rather than of the application itself.
    – 0xC0000022L ♦
    Jul 31, 2018 at 16:22
  • For your use case, you could use an API monitor to see precisely which functions are being called, as well as trigger a breakpoint for a debugger to attach and handle.
    – NirIzr
    Jul 31, 2018 at 18:03
  • @NirIzr I never understand how to work with ApiMonitor ,all the time I tried to monitor process, thos process are close/ stack because of ApiMonitor
    – Keystone
    Jul 31, 2018 at 21:20
  • @0xC0000022L import tab show only the function that compiled as static ? How can I see dynamic compiled functions like fwrite
    – Keystone
    Jul 31, 2018 at 21:22

1 Answer 1

Reset to default
1

A few possibilities come to mind:

  1. The application did not use WriteFile but some other API to write.

  2. one of the other APIs or one of the DLLs used by the program called WriteFile indirectly. You can try to catch the this situation by putting a breakpoint on the final API in kernel32 (kernel32_WriteFile).

  3. As mentined by Amirag, the program could be calling the native API NtWriteFile in ntdll.dll directly, or even invoke the syscall instruction manually (though this is very rare and tricky to pull off).

  4. the write was performed on the process' behalf by the kernel or a kernel-mode driver. This situation can't be caught by a user-mode debugger.

To determine the real cause, double-click the event in Process Monitor and check the Stack tab. If you configure the symbols properly, you should see the actual path through the process and the kernel and determine what exact location in the process triggered the write and inspect the code there.

Improve this answer

Your Answer

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

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