DOS ain't dead

Confusing DEBUG - EDIT (Miscellaneous)

posted by ecm  , Düsseldorf, Germany, 19.08.2010, 01:19

> It's more complicated.

Only a little.

> - read the byte at CS:E/IP-1
> - restore its BPs
> - if the byte it has read is 0CCh AND entry into Debug was through
> interrupt 3, then it again reads the byte at CS:E/IP-1.

Fits my description up to here.

> If its value is NO
> LONGER 0CCh, then Debug assumes one of its BPs were hit and decrements
> E/IP.

This additional check, however, doesn't avoid my exploit. Whether you include that check in DEBUG really depends on your preference: let's say there was a CCh byte anyway - which byte did cause the interrupt, the one we wrote there or the one that was there anyway? I go with the first answer.

With the second answer, you display the message about "unexpected breakpoint interrupt" and don't decrement IP. I think you should rather not display the message but point to the int3 instruction in the disassembly.

EDIT: The MS DEBUG that I just tested chose the first answer just like me

---
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