CreateFileA failes on an existing file

[0xcpu]

x64dbg failes to open an existing file using CreateFileA

The system error code is 0x20(ERROR_SHARING_VIOLATION), the file isn't opened by any other program.

The annoying thing is that OllyDbg succeeds opening it.

Tried opening with x64dbg running as ADMIN and as normal user.

Any ideas what is the problem?

[mrexodia]

No and it is unlikely to be related to x64dbg unless there is some anti-debug at play or the application is opening a file that is exclusively opened by x64dbg...

[0xcpu]

There is no anti-debugging in the file. If it's not related to x64dbg, why OllyDbg succeeds?

[mrexodia]

Who knows... You could check the handles tab before CreateFile and see if it's already opened.

…

On Mon, 12 Dec 2016 at 10:56, Cornel Punga ***@***.***> wrote: There is no anti-debugging in the file. If it's not related to x64dbg, why OllyDbg succeeds? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#1364 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACWCmf-uWtHXp5-v8DD1Hu7MJqYdQbjiks5rHRo_gaJpZM4LKW65> .

[0xcpu]

In x64dbg there are no handles, but it should, at least a mutex was opened, while OllyDbg identifies opened handles. So I'm not totally convinced there is no problem in x64dbg.

[mrexodia]

Okay but you are the one who should convince me that it's a bug, not the other way around 😀 Also check with other tools like ProcessHacker to see if a handle is already open to the file.

…

On Mon, 12 Dec 2016 at 11:05, Cornel Punga ***@***.***> wrote: In x64dbg there are no handles, but it should, at least a mutex was opened, while OllyDbg identifies opened handles. So I'm not totally convinced there is no problem in x64dbg. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#1364 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACWCmXPJWQz8gurh1FbIe_gbu-QJTdixks5rHRx2gaJpZM4LKW65> .

[0xcpu]

I didn't say that this is a bug in x64dbg. This issue was opened because another debugger succeeds in doing the same operation, on the same system. So, I thought it is helpful to question this situation, also question why x64dbg doesn't show the (other) opened handles.

[mrexodia]

It is hard for me to do anything with exact reproduction steps including the file and os configuration etc. It is possible that x64dbg has a handle open to the file in question but there is no way for me to verify that without more details.

…

On Mon, 12 Dec 2016 at 11:16, Cornel Punga ***@***.***> wrote: I didn't say that this is a bug in x64dbg. This issue was opened because another debugger succeeds in doing the same operation, on the same system. So, I thought it is helpful to question this situation, also question why x64dbg doesn't show the (other) opened handles. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#1364 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACWCmcx3Ti29Uhp57x2uTz7pghuXF1H4ks5rHR7vgaJpZM4LKW65> .

[Gbps]

I experienced this same trick. It involves opening the currently executing file in x32dbg with CreateFile. In this case it's an anti-debug/packer trick, which fails for x32dbg due to a request for exclusive access to the file. CreateFileA will fail with LastError of ERROR_SHARING_VIOLATION. OllyDbg does not appear to have this issue.

The issue can be resolved by changing the dwShareMode access requested by CreateFile at runtime from 0 (exclusive) to 7 (FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE)