¿Por qué este código me permite detectar un depurador?

Question

¿Por qué el siguiente código de ensamblado es una herramienta anti-depuración?

l1: 
call l3 
l2: 
;some code 
l3: 
mov al, 0c3h 
mov edi, offset l3 
or ecx, -1 
rep stosb 

sé que es C3hRETN y sé que stobs escribe el valor en al como código de operación de acuerdo con el desplazamiento en edi y está hecho para ecx veces a causa de rep.

También soy consciente del hecho de que stobs y se ejecutarán si se tomaron de antemano en la arquitectura de Intel como su formato original.

Si ejecutamos el programa en modo depurado, la precarga es irrelevante y la etiqueta l2 se ejecutará (porque es de un solo paso); de lo contrario, si no hay un depurador, será ping-pong entre l1 y l3 a.m. ¿derecho?

Answer 1

Cuando se depura el programa (es decir, un solo paso) la cola de captación previa se vacía en cada paso (cuando se produce una interrupción). Sin embargo, cuando se ejecuta normalmente eso no sucederá a rep stosb. Los procesadores antiguos no lo lavaron incluso cuando había memoria de escritura en el área de la memoria caché, para admitir el código de modificación automática que se modificó excepto rep movs y rep stosb. (IIRC finalmente se fija en los procesadores i7.)

Es por eso que si hay una (solo paso) depurador de código se ejecutará correctamente y cuando rep stosb se sustituye por retl2 será ejecutado. Cuando no hay un depurador rep stosb continuará, ya que ecx es el más grande posible eventualmente escribirá en algún lugar donde no se supone que escriba y se producirá una excepción.

Esta técnica anti-depuración se describe en this paper.

Answer 2

Lo único que hace un depurador aquí es agregar retraso. Esa puede ser la clave de cómo funciona esto. El manual de Intel (y supongo que el AMD) explícitamente dice que el código de auto modificación no está garantizado "para funcionar" a menos que el programa indique a la CPU que la línea de caché que contiene la instrucción modificada ha cambiado. Esto es para hacer que la lógica de captación previa sea barata; los diseñadores de chips no quieren tener hardware que compruebe continuamente que cada byte de una línea de caché de instrucciones sigue siendo válido.

así que supongo que lo que sucede con los depuradores son las llamadas L1 L3, que almacena un retorno después de la STOSB representante, y el retorno es ejecutado becaued de grandes retrasos inducidos por el depurador en la ejecución paso a paso, obligando al cachecline containng L3 para ser reetiquetado después de cambiado.

Sin el depurador, supongo que las instrucciones (no se muestran) después de que se ejecuta el stosb. Si fuera un salto a "sin depurador", el éxito del salto demostraría que no se estaba utilizando ningún depurador de paso único.

Si encuentro este código en una aplicación, me niego a ejecutarlo.