Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
x64dbg two fatal bug #1960
On Fri, Jun 8, 2018, 12:13 AM number201724 ***@***.***> wrote: Bug 1: If the EXE EntryPoint is 0, Entry Breakpoint breaks to the PE Header's IMAGE_DOS_SIGNATURE Bug2: If you use ZwMapViewOfSection to load 2 copies of ntdll.dll (path is consistent) then the breakpoint on this module will be wrong. ZwOpenFile -> ZwCreateSection -> ZwMapViewOfSection — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1960>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AK20OEOa-ZuNBhY1h1bujmtIwc5Rq16lks5t6XRmgaJpZM4Ue63q> .
I don't really care about the 0 entry point thing, sorry.
I was more interested in the double mapped ntdll breakpoints misbehaving since a lot of protectors are remapping ntdll nowadays. So I rewrote your sample code a bit since I didn't understand the issue at first:
How to reproduce:
Both calls will work since as far as the kernel is concerned there is no difference between a DLL and a
...By walking the ntdll loader entry list out-of-process. See
I'm guessing the breakpoint identifiers are (at least partially) name-based (and/or with an RVA from the module) to prevent the breakpoints list from being wiped due to relocations? If so that makes sense and seems more important to me than fixing this.
The load order of an image is not very useful to distinguish between duplicate DLLs since this load order can be easily manipulated by the debuggee. The 'WinDbg way' is another not-so-hot option: WinDbg simply concatenates the base address to any duplicate module names. Of course, WinDbg doesn't actually bother saving breakpoints anyway...
I think, as a compromise, (since these 'double mapped' faux images are usually system DLL files) the
So, it is trivial to determine for a given section mapping whether it (1) has a known DLL name, and if so, (2) whether it has the canonical address of the DLL by comparing it to the
So possible proposal for at least fixing the POC behaviour: