flat assembler
Message board for the users of flat assembler.

Index > Windows > Debug Stepping (x64dbg) - kiuserexceptiondispatcher

Author
Thread Post new topic Reply to topic
Jeff20one



Joined: 19 Nov 2023
Posts: 2
Jeff20one 19 Nov 2023, 11:01
Im watching the flat assembler introduction to x86, the issue is, he can debug step by step, but when i use step into or step over in the debugger, it goes back to the int3


Description: For me, it takes me to kiuserexceptiondispatcher and then back to the int3 at the start
Filesize: 297.15 KB
Viewed: 1970 Time(s)

myimage.png


Description: In the video, he can step over each instruction that he wrote.
Filesize: 483.29 KB
Viewed: 1970 Time(s)

image.png


Post 19 Nov 2023, 11:01
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8346
Location: Kraków, Poland
Tomasz Grysztar 19 Nov 2023, 11:30
I have this issue discussed in the video of how to use fasm with x64bdg, around 03:08 time:
https://youtu.be/7GSp-ZIMqxc?t=184
Post 19 Nov 2023, 11:30
View user's profile Send private message Visit poster's website Reply with quote
Jeff20one



Joined: 19 Nov 2023
Posts: 2
Jeff20one 19 Nov 2023, 11:36
ah thank you
Post 19 Nov 2023, 11:36
View user's profile Send private message Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 509
Location: Czech republic, Slovak republic
Feryno 19 Nov 2023, 14:28
There is the int3 instruction incompiled into the code to be debugged.
When you run such code (that is executing run as shown in the video), the exception #BP is triggered after the int3 is executed (because #BP is trap type of exception) so RIP is pointing after the int3 instruction. At that moment the debugger knows that #BP happened and then the debugger usually looks at RIP-1 and finds there int3 (hexa 0CCh) and subtracts 1 from RIP so RIP is adjusted to point to the beginning of the int3 instruction. Debugger also looks into its internal data whether the int3 wasn't written there by the debugger itself (if not it leaves the int3 there which is the case in the video and if yes it restores the original byte there but this is not the case in the video).
When you execute debug exception (#DB) over int3 instruction (#BP) by setting rflags.TF=1 and then the code is run, #DB is generated because it has higher priority than #BP. It is also possible to avoid generating #DB for 1 instruction by setting rflags.RF (resume flag) and the processor clears the RF after the one instruction execution is successfully completed (except for IRET that sets the RF, except for JMP, CALL, INTn through a task gate).
The degugger could be improved to pass this situation. Something like this:
[0] lookup whether the int3 was written there by the debugger itself (e.g. because using a software breakpoint there)
[1] if yes then point RIP at the beginning of the int3 instruction (subtract 1 from RIP) and restore there the original byte (this is not the case in video as there the int3 was incompiled in the code)
[2] if not (that means the int3 was incompiled in the code) then do not decrease RIP and let the RIP to point after the int3 instruction.
Post 19 Nov 2023, 14:28
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20212
Location: In your JS exploiting you and your system
revolution 19 Nov 2023, 22:34
That is a bug in X64dbg. It is very silly to expect the user to manually skip past INT3. Placing NOP there means you can't break again later if the INT3 is in a loop. The debugger should handle this stuff seamlessly without bothering the user.

Having the JIT window not show the INT3 upon startup,, and expecting the user to press buttons to show it, is also a bug.

Ollydbg always showed the faulting address immediately. And Olly would not get stuck on INT3.


Last edited by revolution on 29 Dec 2023, 19:19; edited 1 time in total
Post 19 Nov 2023, 22:34
View user's profile Send private message Visit poster's website Reply with quote
DenimJeans



Joined: 29 Dec 2023
Posts: 11
DenimJeans 29 Dec 2023, 19:06
what about INT 4 ?
there you can (for me at least ) continue with F7/F8. It jump briefly into another section, but then continues...
Or what I use often is, i place the EIP to the next instruction (CTRL+*), then F8 to continue.
NOPing the INT instrcution and placing a BP to next instrcution is a good idea, though.[/b]
Post 29 Dec 2023, 19:06
View user's profile Send private message Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 509
Location: Czech republic, Slovak republic
Feryno 31 Dec 2023, 17:01
INT 4 in 64 bit mode

AMD
24593.pdf
Table 2-3. Invalid Instructions in 64-Bit Mode
INTO, opcode (hex) CE, Interrupt to Overflow Vector

Intel
325383.pdf
INT n/INTO/INT3/INT1—Call to Interrupt Procedure
Opcode CE, Instruction INTO, 64-Bit Mode Invalid
Post 31 Dec 2023, 17:01
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.