int3 problems

[PELock]

1. Put int3 (CC) in your code
2. Load it into x64dbg
3. F9
4. Exception is catched at int3 (int3 stepping disabled in options)
5. Move current EIP right after the int3 ("CTRL + * star" keyboard shortcut)
6. Press F8 or F7 to run instruction right next to int3
7. BUG -> x64dbg returns to the int3 instruction, EIP is restored back to int3 even if it was manually changed to the instruction next to it

[mrexodia]

This is the default behavior for first chance exceptions. You can do it by either running again so you get a second chance exception, use the "skip next instruction" option, use the "con" command after setting eip or finally change the default exception handling behavior in settings, which is built for manual breakpoint instructions you want to use as breakpoints.

…

On Thu, 8 Jun 2017 at 23:49, Bartosz Wójcik ***@***.***> wrote: 1. Put int3 (CC) in your code 2. Load it into x64dbg 3. F9 4. Exception is catched at int3 (int3 stepping disabled in options) 5. Move current EIP right after the int3 ("CTRL + * star" keyboard shortcut) 6. Press F8 or F7 to run instruction right next to int3 7. BUG -> x64dbg returns to the int3 instruction, EIP is restored back to int3 even if it was manually changed to the instruction next to it — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1614>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACWCmYU2dfvfH03Ly7dMJ28U_Auv2VS7ks5sCGxvgaJpZM4N0qln> .

[PELock]

It's just annoying and looks like a bug, because I have manually changed the EIP to other, safe instruction, so why the hell would it come back at the exception EIP? Where's the logic in that? OllyDbg 1 & 2 respects that behaviour. x64dbg should follow my steps, not otherwise.

PS. I really miss "d" command to navigate into the dump window, it's the most common used command in my experience and writing "dump address" is just way slower than "d address" 👎

[mrexodia]

The logic is that olly swallows the exception and thus behaves incorrectly with regards to the exception handlers it calls and then exposing anti debug tricks. I cannot control what windows does with eip after I set the context. If you want this behavior it can be turned on in settings. You can also register an exception breakpoint on 80000003 and call the "con" command if you want it for a specific application. As for the "d" command, just write a plugin that registers your command. Or just set the hotkey "d" to replace ctrl+g and use the goto dialog where every expression is supported correctly.

…

On Fri, 9 Jun 2017 at 00:02, Bartosz Wójcik ***@***.***> wrote: It's just annoying and looks like a bug, because I have manually changed the EIP to other, safe instruction, so why the hell would it come back at the exception EIP? Where's the logic in that? OllyDbg 1 & 2 respects that behaviour. x64dbg should follow my steps, not otherwise. PS. I really miss "d" command to navigate into the dump window, it's the most common used command in my experience and writing "dump address" is just way slower than "d address" 👎 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1614 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACWCmeS83B3qPUqq_K_FjIBvodlraSg0ks5sCG94gaJpZM4N0qln> .

[PELock]

In my eyes it's clearly a bug in x64dbg, because it ignores my actions and behaves unnatural like I don't have control over EIP. If it's not a bug, but a "feature" like you put it, than allowing to change EIP on int3 exception is a bug, isn't it?

[mrexodia]

Like I said if you want incorrect behavior you can choose so in the preferences. Any first chance int3 exception will then be swallowed and never thrown in the executable. And I never said it was a feature. It's Windows resetting EIP to the location of the int3 to where the first chance exception happened.

…

On Fri, 9 Jun 2017 at 00:26, Bartosz Wójcik ***@***.***> wrote: In my eyes it's clearly a bug in x64dbg, because it ignores my actions and behaves unnatural like I don't have control over EIP. If it's not a bug, but a "feature" like you put it, than allowing to change EIP on int3 exception is a bug, isn't it? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1614 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACWCmV2oNgLa7AupEroVHeSMJlBszsOgks5sCHTxgaJpZM4N0qln> .

[Mattiwatti]

It's easy to change the default behaviour for this if you want to. But if the default was to ignore exceptions after changing EIP, programs would behave differently when being debugged than when not being debugged. This would lead to other bug reports due to unexpected breakages (much more vague ones than this, because the different behaviour would likely only manifest in some other place). And second it would expose an easy anti-debug weakness as @mrexodia said.

[mrexodia]

I think it would be possible to make a special case out of where you chance CIP on a first chance exception. It should be pretty easy to just pop up a message box that explains the situation and asks you if you wish to swallow the exception and change CIP.