Well, seguindo o embalo do meu amigo de trabalho, a.k.a. Vandeco, tambem tentarei mostrar aqui uma tecnica antidebugging, so que em um S.O. diferente… no nosso caso vamos fazer o teste no linux e vamos verificar que int 3 e usual, sim… nao tenho duvidas, porem nao basta para livrar o nosso codigo do debugging alheio…

Tentarei demonstrar de forma resumida um exemplo de como burlar o debug do gdb

Primeiro exemplo de codigo, introduzir um breakpoint falso

#include <signal.h>

void handler (int signo) {
}

int main() {

signal(handler, SIGTRAP);
__asm__(”int3″);
printf(”Ola!!”);
}

[jumpi@painkiller testes]$ gcc -g debug-teste.c
[jumpi@painkiller testes]$

[jumpi@painkiller testes]$ gdb
GNU gdb Red Hat Linux (6.5-15.fc6rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type “show copying” to see the conditions.
There is absolutely no warranty for GDB. Type “show warranty” for details.
This GDB was configured as “i386-redhat-linux-gnu”.
(gdb) file a.out
Reading symbols from /home/jumpi/testes/a.out…done.
Using host libthread_db library “/lib/libthread_db.so.1″.
(gdb) run
Starting program: /home/jumpi/testes/a.out

Program received signal SIGTRAP, Trace/breakpoint trap.
main () at debug-teste.c:11
11 printf(”Ola!!”);
(gdb) c
Continuing.
Ola!!
Program exited with code 05.
(gdb) quit

Ou seja, com isso forçamos um int 3 no codigo como se fosse um breakpoint e com o SIGTRAP capturamos o sinal, que faz com que ele pense que havia um breakpoint onde na verdade nao havia, simples e interessante…

Enfim, existem diversas outras tecnicas de debugging e antidebugging, como fazer controle da ptrace(), usando file descriptor ou ate mesmo por identificacao de processos. Porem fica para uma proxima ocasiao…

No play: Arsis - United in Regret - 04: I Speak Through Shadows