DOS ain't dead

Confusing DEBUG (Miscellaneous)

posted by ecm  , Düsseldorf, Germany, 19.08.2010, 11:00

> I saw - and still see - some differences, but this is probably off-topic.

Feel free to wander. (If it's about the discrepancy that your DEBUG doesn't really check CS:EIP to see if it matches one of G's breakpoint, yeah, I noticed that later.)

> However, what's on-topic is that I'm unable to see why DEBUG is supposed to
> be "confused". I also don't agree that it "incorrectly decrements (E)IP".
> If the conditions described above are met then (E)IP has to be decremented,
> it doesn't matter if the INT 3 was truly executed or if it was "faked".

r ds 0
r bx C
a 100
pushf
push cs
push word 10C
push word [bx+2]
push word [bx]
retf
db A9
jmp 110
int 3
nop
int 3

g 10B
r ip 100
g

Executing this script (in your DEBUG) with the G breakpoint set at 10B ends up at the "test ax, 02EB" instruction (db A9). With no breakpoint at 10B (or outside DEBUG assuming a simple "iret" Int03 handler) the code doesn't execute the test instruction but the contained short jump instead.

The problem with that is that the byte which was set to a breakpoint doesn't have to be a valid instruction; therefore decrementing EIP to point there is incorrect. With a non-faked breakpoint, DEBUG knows it's a valid instruction because the CCh byte was executed. Not so if the Int03 call really came from elsewhere; the breakpoint might have been inside another instruction then. (Though setting breakpoints inside instructions is always just asking for problems.)

Of course, there is no use for this exploit. It's no issue with DEBUG either because no program ever fakes interrupt 03h calls. But I told you it's useless. I just found this to be interesting.

---
l

Complete thread:

• Confusing DEBUG - ecm, 16.08.2010, 04:11 (Miscellaneous)
  • Confusing DEBUG - Japheth, 19.08.2010, 00:52
    • Confusing DEBUG - EDIT - ecm, 19.08.2010, 01:19
      • Confusing DEBUG - EDIT - Japheth, 19.08.2010, 10:17
        • Confusing DEBUG - ecm, 19.08.2010, 11:00