Cześć
Kilka doprecyzowań / wyjaśnień
1. Metody o których mówisz nie wykrywają debuggera w dosłownym znaczeniu, tylko umożliwiają wykrycie pewnego rodzaju zachowań debuggera, a konkretniej trybu krokowego, oraz breakpointów sprzętowych (ale to ostatnie tylko w teorii ;>)
2. Na 16 bicie jest flaga RF, Resume Flag, która jest używana do wyłączenia (ważne) hardware exceptions na czas jednej instrukcji.
Czyli, teoretycznie masz rację - można by wykryć czy w danym miejscu (mówimy tutaj o rozdzielczości typu jedna instrukcja, więc jest to mało użyteczne) został ztriggerowany hardware exception, a następnie debugger powrócił. Teoretycznie można by taką pułapkę przygotować instrukcją PUSHFD, która wrzuci wszystkie flagi na stos, a potem byśmy mogli sprawdzić czy na stosie jest zapalony bit 16.
Albo lepiej! Teoretycznie moglibyśmy w miarę często ustawiać za pomocą POPFD flagę RF, tak aby hardware breakpointy nie działały!
Ale niestety, jak to zwykle bywa, diabeł tkwi w szczegółach.
Cytat z manuala Intela (tom 2B):
[quote="Intel o PUSHFD"]When copying the entire EFLAGS register to the stack, the VM and RF flags (bits 16 and 17) are not copied; instead, the values for these flags are cleared in the EFLAGS