paulosgf

Introdução Olá pessoal! Este é mais um artigo da série onde falo sobre técnicas de anti-engenharia reversa. Neles compartilho um pouco dos tutoriais práticos que desenvolvi ao longo das minhas pesquisas e estudos. No primeiro artigo, falei sobre a categoria de anti-debugging TLS Callback. Agora vou falar um pouco sobre as técnicas da categoria que utilizam flags de depuração do próprio processo para detectar o debugger. Antes de mais nada, vale entender o que são essas flags. O que são flags de depuração? Estas flags são valores presentes dentro do espaço de endereço do processo, permanecendo na memória até o encerramento deste programa. A presença e/ou determinado valor destes bits podem indicar que o processo está em um ambiente de depurador. Como estas técnicas são válidas apenas para o ambiente Windows, seu significado e valores são definidos na documentação oficial do SO (WinAPI) [1], entretanto algumas flags podem não ser documentadas e, neste caso, somente se encontra informação em livros como o Windows Internals [2]. A primeira que vamos analisar é a NtGlobalFlag, desenvolvida na época do antigo Windows NT. Esta flag é definida no cabeçalho do Process Environment Block (PEB) de todos processos no sistema e é usada especificamente para indicar se o processo está executando ou não em depurador. Antes de aprofundar nas particularidades desta flag, precisamos entender o que é a PEB, que foi citada anteriormente. De forma resumida, é uma estrutura que existe em cada processo do Windows e é apontada por outra estrutura chamada TEB (Thread Environment Block), que por sua vez contém informações em relação às threads do processo. O código da PEB é composto por uma struct e sua versão para 32 bits no header windows.h ou winternl.h é a seguinte: typedef struct _PEB { BYTE Reserved1[2]; BYTE BeingDebugged; BYTE Reserved2[1]; PVOID Reserved3[2]; PPEB_LDR_DATA Ldr; PRTL_USER_PROCESS_PARAMETERS ProcessParameters; PVOID Reserved4[3]; PVOID AtlThunkSListPtr; PVOID Reserved5; ULONG Reserved6; PVOID Reserved7; ULONG Reserved8; ULONG AtlThunkSListPtr32; PVOID Reserved9[45]; BYTE Reserved10[96]; PPS_POST_PROCESS_INIT_ROUTINE PostProcessInitRoutine; BYTE Reserved11[128]; PVOID Reserved12[1]; ULONG SessionId; } PEB, *PPEB; *O 3º byte desta estrutura é o campo BeingDebugged e este é definido pelo Windows para todo binário que está sendo executado, sendo 0 (padrão) para indicar que o processo não está sendo depurado e 1 para depurado. Este byte é avaliado na técnica abordada no Curso de Engenharia Reversa Online (CERO) através da função IsDebuggerPresent() e por conta disto esta técnica não será abordada neste artigo. A Aula 24 - Anti-debug, do CERO, aborda a PEB de forma prática. Uma referência completa sobre a PEB também pode ser acessada em [3]. NtGlobalFlag Esta flag também é um campo da PEB e se encontra no offset 0x68 em ambientes 32 bits, ou offset 0xBC em 64 bits, contados a partir do seu início. Esta flag é usada para rastreamento e depuração de programas. Seu valor é 0 por padrão, indicando que não há depurador no ambiente. Caso se inicie o programa primeiro e depois de já iniciado, se analise seu processo no depurador, os campos da NtGlobalFlag não são alterados, deixando esta abordagem sem efeito. No entanto, caso se execute o programa diretamente em um depurador, as seguintes flags serão definidas: FLG_HEAP_ENABLE_TAIL_CHECK (0x10) FLG_HEAP_ENABLE_FREE_CHECK (0x20) FLG_HEAP_VALIDATE_PARAMETERS (0x40) A presença de um depurador no ambiente é confirmada ao se verificar o valor 0x70 resultante da operação OR entre estas flags. Disassemble de processo 32 Bits: mov eax, fs:[30h] // acessa a PEB no registrador de segmento mov al, [eax+68h] // a partir da PEB acessa a flag NtGlobalFlag and al, 70h // soma as flags FLG_HEAP_* cmp al, 70h // verifica se o valor da soma é 0x70 call being_debugged // caso positivo, avisa sobre depuração Disassemble de processo 64 Bits: mov rax, gs:[60h] // acessa a PEB no registrador de segmento mov al, [rax+BCh] // a partir da PEB acessa a flag NtGlobalFlag and al, 70h cmp al, 70h call being_debugged Disassemble de processo WOW64 (64 Bits que aceita também 32 bits): mov eax, fs:[30h] // acessa a PEB no registrador de segmento mov al, [eax+10BCh] // a partir da PEB acessa a flag NtGlobalFlag and al, 70h cmp al, 70h call being_debugged Código de exemplo: #include <windows.h> #include <iostream> using namespace std; // define o valor das flags #define FLG_HEAP_ENABLE_TAIL_CHECK 0x10 #define FLG_HEAP_ENABLE_FREE_CHECK 0x20 #define FLG_HEAP_VALIDATE_PARAMETERS 0x40 // executa a operação OR entre o valor de todas as flags #define NT_GLOBAL_FLAG_DEBUGGED (FLG_HEAP_ENABLE_TAIL_CHECK | FLG_HEAP_ENABLE_FREE_CHECK | FLG_HEAP_VALIDATE_PARAMETERS) // se não for 64 bits #ifndef _WIN64 PVOID pPeb = (PVOID)__readfsdword(0x30); // PEB DWORD dwNtGlobalFlag = *(PDWORD)((PBYTE) pPeb + 0x68); // flag #else // o mesmo procedimento para 64 bits PVOID pPeb = (PVOID)__readgsqword(0x60); DWORD dwNtGlobalFlag = *(PDWORD)((PBYTE)pPeb + 0xBC); #endif // _WIN64 // função que acusa depurador e sai void being_debugged() { std::cout << "Stop debugging program!" << std::endl; exit(-1); } int main() { // se em ambiente de depurador chama função de saída if (dwNtGlobalFlag & NT_GLOBAL_FLAG_DEBUGGED) being_debugged(); eles // senão segue normalmente std::cout << "Hello World!\n"; return 0; } Desabilitando a Técnica Para desviar desta verificação, basta definir o campo NtGlobalFlag da estrutura PEB com 0 antes que este valor seja verificado pela proteção anti-depuração. Abaixo são alguns exemplos de como zerar esta flag: No x64dgb com o plugin ScyllaHide: Plugins → ScyllaHide → Options -> NtGlobalFlag [x] Manualmente no x64dbg: 1. Ctrl+G → peb()+0x68 (32 bits) ou Ctrl+G → peb()+0xBC (64 bits) 2. Trocar o valor do byte de 0x70 para zero No OllyDbg com o plugin Command Line: 1. Plugins → Command Line → Command Line 2. dump fs:[30]+0x68 (32 bits) ou dump gs:[60]+0xBC (64 bits) 3. No painel dump de memória selecionar o 1º byte → Binary → Fill with 00's *Também é possível usar o plugin Olly-Advanced Bom, iniciei aqui uma nova categoria de técnicas Anti-Debug, a das flags de depuração, iniciando com a flag NtGlobalFlag. No próximo artigo vou falar sobre uma técnica que usa 2 flags em conjunto, a Heap Flags e a ForceFlags. Espero que tenham gostado. Forte abraço & até o próximo! Referências: [1] https://docs.microsoft.com/en-us/windows/win32/apiindex/windows-api-list [2] https://docs.microsoft.com/en-us/sysinternals/resources/windows-internals [3] https://www.geoffchappell.com/studies/windows/km/ntoskrnl/inc/api/pebteb/peb/index.htm

Introdução Reunir informações sobre técnica de "Anti- Engenharia Reversa" é a proposta dessa série de artigos que serão publicados aqui no Mente Binária. É um tema em que tenho pesquisado e criado pequenos tutoriais práticos para mim mesmo durante o último ano, e resolvi compartilhá-los. Em cada um deles darei uma passada nas principais técnicas encontradas em todas as classes de defesa dos criadores de malware, além de mostrar como desabilitá-las. Tudo com exemplos de código para se entender na prática mesmo. *Para a implementação estarei utilizando o Visual Studio Community, pois este tem o suporte ao ambiente C Runtime (CRT) necessário. A grande maioria das técnicas que serão apresentadas é para o ambiente Windows. Alguns poucos casos, que serão informados, são para Linux. Como pré-requisito, é necessário algum conhecimento de linguagem C\C++, um pouco de Assembly e principalmente Engenharia Reversa. Todos estes tópicos são abordados nos cursos gratuitos no canal do Mente Binária no Youtube. *No caso, não apresentarei a técnica mais simples/comum que utiliza a função IsDebuggerPresent(), pois esta técnica é explicada na última aula do curso do CERO aqui do Mente Binária. Classes de Anti-Engenharia Reversa Essas classes são uma forma de categorizar os métodos de "Anti-Engenharia Reversa", agrupando métodos de evasão semelhantes num mesmo grupo ou “classe”. Como não existe uma classificação oficial, estas classes estão baseadas na divisão apresentada nesta referência, com algumas adaptações. TLS Callback Windows: A Thread Local Storage (TLS) é um recurso do Windows para definir objetos (variáveis) na memória que possam ter valores diferentes para cada thread criada por um processo. Por exemplo, ao imprimir um documento, uma thread se encarrega de mostrar o documento na tela, enquanto outra acessa esta mesma informação simultaneamente para lidar com a impressão. A thread de impressão pode ter uma variável que armazena a quantidade de páginas impressas, porém, esta variável não se faz necessária na thread que apresenta o documento na tela. Esta informação é armazenada (daí o nome "Thread Local Storage") numa região definida no cabeçalho dos binários PE (Portable Executable), e o acesso só é permitido para sua respectiva thread. As funções TLS Callback executam antes do binário alcançar seu "ponto de início", chamando e inicializando estes objetos TLS através de métodos construtores e os removendo da memória por métodos destrutores após seu uso. Com isso em mente, as TLS Callbacks também podem ser utilizadas pelos desenvolvedores de malware para permitir que se execute código antes que o binário chegue à região tradicional de início do programa, conhecido como Entrypoint, que irá levar em seguida à função main(). Isto cria diversas oportunidades como por exemplo executar código malicioso antes que o depurador possa detectá-lo (levar o malware a encerrar o processo antes mesmo de executar as rotinas maliciosas ao perceber que está sendo depurado, por exemplo). Alguns exemplos de malwares que empregam TLS Callbacks no Windows são: Nadnadzzz botnet de 2009; Grum botnet de 2008, através do Grum rootkit; Ursnif (mais recente); Implementação A biblioteca C Runtime (CRT) do Visual Studio provê suporte para fácil criação de TLS Callbacks (como comentado aqui) graças ao código em “C:\Program Files (x86)\Microsoft Visual Studio xx.0\VC\crt\src\tlssup.c”, que cria um diretório de dados TLS baseado na seguinte estrutura: typedef struct _IMAGE_TLS_DIRECTORY32 { DWORD StartAddressOfRawData; /* Início da seção TLS AddressOfRawData*/ DWORD EndAddressOfRawData; /* Endereço final na seção TLS */ DWORD AddressOfIndex; /* Índice da seção TLS */ DWORD AddressOfCallBacks; /* Ponteiro para o array de funções callback */ DWORD SizeOfZeroFill; DWORD Characteristics; } __tls_used; Para criarmos a nossa própria callback precisamos primeiro defini-la no seguinte formato: VOID WINAPI tls_callback1( PVOID DllHandle, DWORD Reason, PVOID Reserved) { codigo_funcao; } As constantes para DWORD Reason podem ser: DLL_PROCESS_DETACH = 0 DLL_PROCESS_ATTACH = 1 DLL_THREAD_ATTACH = 2 DLL_THREAD_DETACH = 3 Depois a callback precisa ser alocada da seguinte forma: PIMAGE_TLS_CALLBACK ponteiro_tls_callback = tls_callback1; Após esta contextualização do mecanismo de funcionamento, segue um exemplo de código onde a função de callback detecta o ambiente de depuração através da função IsDebuggerPresent() e sai informando que o mesmo foi descoberto. Caso contrário, informa que o programa está executando normalmente: #include <iostream> #include <windows.h> using namespace std; // Declara uma variável global requerida para a chamada TLS Callback static int v1 = 0; // Declara a callback VOID WINAPI tls_callback1( PVOID DllHandle, DWORD Reason, PVOID Reserved) { if (Reason == DLL_PROCESS_ATTACH) { v1 = 1; // dentro da Callback altera o valor da variável if (IsDebuggerPresent()) { cout << "Stop debugging program!" << endl; TerminateProcess(GetCurrentProcess(), 0x1); exit(1); } } } // Cria objeto conforme a arquitetura através de #pragmas, que são instruções específicas do compilador #ifdef _M_AMD64 // para arquitetura x86_64 #pragma comment (linker, "/INCLUDE:__tls_used") // instrui linker usar o diretório TLS #pragma comment (linker, "/INCLUDE:p_tls_callback1") // instrui linker usar ponteiro do mesmo tipo da callback tls_callback1 declarada antes #pragma const_seg(push) // carrega o ponteiro na stack do compilador para uso da callback no segmento de dados const (.rdata) #pragma const_seg(".CRT$XLA") // cria nova seção TLS EXTERN_C const PIMAGE_TLS_CALLBACK p_tls_callback1 = tls_callback1; // atribui tls_callback1 ao ponteiro p_tls_callback1 #pragma const_seg(pop) // remove o ponteiro da stack após o uso #endif // fim deste bloco #ifdef _M_IX86 // para a arquitetura x86. as instruções tem as mesmas finalidades do bloco anterior #pragma comment (linker, "/INCLUDE:__tls_used") #pragma comment (linker, "/INCLUDE:_p_tls_callback1") #pragma data_seg(push) #pragma data_seg(".CRT$XLA") EXTERN_C PIMAGE_TLS_CALLBACK p_tls_callback1 = tls_callback1; #pragma data_seg(pop) #endif // main() só será executada depois, quando um depurador não for detectado int main(int argc, char* argv[]) { cout << "Normal execution!" << endl; printf("test value from tls callback is: tls = %d\n", v1); return 0; } Abaixo estão algumas dicas de como lidar com TLS Callbacks em diversas ferramentas: x64dbg: Options → Preferencias → Eventos → TLS Callbacks OllyDbg: Options -> Debug Options -> Events -> Make first pause at -> System breakpoint (para em TLS Callbacks) OllyDbg: Plugin Olly Advanced → Break on TLS Callback IDA Pro: Ctrl+E → Choose an entry point IDA Pro (Debugger): Debugger -> Debugger options -> Events -> Stop on (marcar todas as opções) Linux: O Linux também suporta o Thread Local Storage (TLS), conforme descrito nestes 2 excelentes artigos: https://maskray.me/blog/2021-02-14-all-about-thread-local-storage https://chao-tic.github.io/blog/2018/12/25/tls No entanto, o recurso de TLS no Linux aparentemente só permite a inicialização de variáveis ou objetos, e não chamada de função (como é o caso no Windows). Isto somente seria possível de dentro da main(), como nesse pequeno exemplo que usa o recurso de suporte a threads da Glibc: #include <stdio.h> // TLS que define e inicializa a variável __thread int main_tls_var = 2; int main() { printf("%d\n", main_tls_var); return 0; } $ ./tls 2 No entanto, ainda é possível executar funções antes ou depois da main() no Linux através das funções construtoras e destrutoras devido ao suporte do GCC. Observem que uma função construtora em C++ instancia uma variável, definindo seu valor, enquanto que a destrutora a remove da memória após a conclusão da execução (normalmente em retorno de funções): #include<stdio.h> /* atributo construtor em myStartupFun() para executar antes de main() */ void myStartupFun (void) __attribute__ ((constructor)); /* atributo destrutor em myCleanupFun() para executar depois de main() */ void myCleanupFun (void) __attribute__ ((destructor)); /* implementacao de myStartupFun */ void myStartupFun (void) { printf ("startup code before main()\n"); } /* implementacao de myCleanupFun */ void myCleanupFun (void) { printf ("cleanup code after main()\n"); } int main (void) { printf ("hello\n"); return 0; } *Por padrão a __libc_start_main(*main(), argc, **argv, __libc_csu_init(), __libc_csu_fini()) é a função da glibc que chama a main(), onde __libc_csu_init é o construtor e __libc_csu_fini é o destrutor. No Linux também é possível evadir o depurador através da função ptrace, mas isso é um assunto que abordarei mais para frente, inclusive com exemplo prático. Por hora convido vocês a continuarem sintonizados, pois no próximo artigo começarei a tratar de técnicas da classe que utiliza flags de depuração para detectar o debugger. Forte abraço & até lá! Referências: https://www.codeproject.com/Articles/1090943/Anti-Debug-Protection-Techniques-Implementation-an https://anti-debug.checkpoint.com/ https://rayanfam.com/topics/defeating-malware-anti-vm-techniques-cpuid-based-instructions/ https://evasions.checkpoint.com/ https://anti-reversing.com/Downloads/Anti-Reversing/The_Ultimate_Anti-Reversing_Reference.pdf