Tweet
Olá pessoal,
Nesse tópico pretendo falar um pouco sobre os Nanomites encontrados no Armadillo(proteção anti-cracking) e que atualmente estão sendo implantados em outros softwares de proteção também. Darei ênfase ao Armadillo por ser o "berço" dos Nanomites e por ser um software comercial de proteção anti-cracking muito poderoso.
Comecemos...
O Debug-Blocker
Não tem como falar sobre os Nanomites sem antes explicar o Debug-Blocker do Armadillo. Basicamente, como o próprio nome já diz, o Debug-Blocker serve para impedir que debuggers sejam usados para modificar o programa que está protegido.
O funcionamento é simples...quando o programa é executado, o DB(Debug-Blocker) cria 2 instâncias do programa (2 processos), um chamado pai e o outro filho. O processo pai é uma espécie de debugger, porém é um debugger que roda em nível de usuário; o que ele faz é monitorar o processo filho, que é quem faz todo o trabalho e, caso qualquer alteração "maliciosa" seja detectada no processo filho, o processo pai termina a execução do programa.
Mas é fácil burlar o Debug-Blocker, basta saber a hora e o lugar certo para fazer alterações e você consegue tirar o processo pai e colocar o seu debugger no lugar dele, podendo então fazer o seu reversing...
Exatamente por causa disso, os inteligentes programadores do Armadillo resolveram criar os Nanomites, uma solução muito inteligente, que para crackers iniciantes e intermediários é uma pedra no sapato.
Os Nanomites
Quando o programa protegido é executado, as partes do código selecionadas são escaneadas em busca de Jumps (JNZ,JNE,JMP...) e uma tabela é criada com a localização dos Jumps e seus tipos, isto é, uma tabela contendo o endereço em que o jump está, o tipo dele e o offset dele. No lugar de cada jump escaneado, é colocada uma instrução "INT 3" e então a tabela dos Jumps é entregue ao processo pai.
O funcionamento disso é o seguinte: quando o processo filho executa uma instrução INT 3, o processo pai toma o controle e decide qual é o jump que estava ali e que deve ser executado. Isso encontrado, ele diz ao processo filho para onde ir e "devolve" a execução a ele.
Isso aumenta muito a dificuldade para os crackers iniciantes e intermediários, pois qualquer alteração corrompe imediatamente e irreversivelmente o executável.
Mas pra dificultar um pouco mais, toda a informação necessária para restaurar o executável a um estado em que ele funcione está guardada a 7 chaves e criptografada várias vezes dentro daquela tabela, somente acessada por rotinas extremamente ofuscadas e com proteções contra debuggers.
Resumindo...crackear um programa protegido com nanomites exige uma certa experiência e muita paciência, senão você pode ficar eternamente tentando crackear e sempre tendo que reinstalar o programa e isso, na minha opinião, é impraticável. :cool:
"Legal, Black-Hat. Mas pra que você explicou tudo isso se você não vai dizer como lidar com isso?! :mad: "
Quem disse que não vou dizer como lidar com isso? :cool:
Pegando a preciosa tabela
Bom...o jeito que vou explicar aqui pode não ser o melhor, mas é o método que uso. Ele envolve programação, porém não vou ficar colocando códigos aqui, vou dar a idéia central e o programa fica por conta de cada um. Afinal, ficar copiando códigos não é legal
(Quem sabe mais pra frente eu coloque um código la na área de programação
)
O método consiste basicamente em monitorar o debugger, isto é, monitorar o processo pai.
Para isso, precisamos colocar 3 hooks nele:
WaitForDebugEvent: Com um hook nessa função podemos inventar e lançar "qualquer" exception e fazer com que o processo pai tente processá-la.
GetThreadContext: O processo pai chama essa função quando o processo filho pára em uma interrupção "INT 3". Sendo assim, com um hook aqui, podemos falsificar uma interrupção em qualquer endereço e fazer o processo pai pensar que é um endereço de Nanomite.
SetThreadContext: Depois de decidir qual o Nanomite (qual o Jump) em questão, o processo pai usa essa função para forçar a execução do processo filho de acordo com o Nanomite encontrado, isto é, para "aplicar" o Nanomite. Um hook aki e podemos obter informações sobre o Nanomite a ser aplicado.
O que temos que fazer é achar todas as interrupções INT 3 (0xCC) na seção de código (.code section) e , para cada uma, o programa deve lançar uma INT 3 e ver como o processo pai reage. Para determinar o tipo de Jump em questão, basta mudarmos as EFlags várias vezes para um mesmo Nanomite. Após todos os Jumps serem analisados, temos a preciosa tabela de Nanomites. 
Mas a vida é uma caixinha de surpresas...
:cool:
O problema dos falsos Nanomites:
Ahhh...tudo parecia estar indo tão bem...e agora você vem com mais problemas, Black-Hat?
Sim...mas é fácil (ou quase fácil) resolver esse
Bom...o que acontece é que os programadores do Armadillo são realmente muito inteligentes. Na tabela de Nanomites do processo pai, existem entradas falsas de Nanomites
Isso significa que uma CALL,por exemplo, pode gerar uma linha na tabela. Essa linha nunca será usada pelo processo pai, por motivos óbvios: a INT 3 vai estar no meio de uma instrução, o que significa que ela não pode lançar uma exceção.
O grande problema disso é que precisamos separar os falsos dos verdadeiros, quase todos os métodos são um tanto quanto ineficazes e acabam por deixar 1 ou mais linhas falsas na tabela ou então acabam por excluir linhas verdadeiras.
Mas existe um que nos "salvará dessa grande calamidade"... :confused:
VEH (vectored exception handler), Nosso Salvador :
O VEH é muito pouco utilizado, mas será nosso salvador nesse caso.
Com ele, podemos colocar um exception handler "global" no programa que não depende de SF(Stack-Frames)...
Mas por que ele irá nos salvar?
Simples...ele é chamado antes do SEH (Stack Exception Handler)...
"Mas, e daí ???"
Calma, vou explicar...vamos só fazer algumas suposições antes.
Daqui em diante vou supor que você já removeu todas as outras proteções presentes no programa, e que o programa roda SEM o processo pai até encontrar um Nanomite. Isto é, a única proteção que lhe resta arrancar são os Nanomites. Também supondo que o programa em questão não tem nenhum VEH próprio, é claro.
Bom...O seu programa estando na situação descrita acima, quando ele chegar em um Nanomite, uma exceção 0xCC (INT 3) vai ser lançada e tudo vai pro ar como um balão de chumbo cheio de hélio (sim...balões de chumbo voam! Por um acaso você não assiste Mythbusters?! Se não, devia assistir!).
É aí que entra o VEH, se um VEH estiver presente, através dele podemos assumir o controle quando uma exceção INT 3 for lançada e "aplicar" o Nanomite.
Assim sendo, basta colocarmos em algum lugar do executável a tabela de Nanomites(mesmo com as entradas falsas) junto com o código que cria o VEH e depois volta pro EP(entry point) original do programa.
Após colocarmos o código e a tabela, desviamos o EP para o nosso código. O código deve criar o VEH e retornar para o EP original do programa.
O nosso VEH deve apenas tratar exceções INT 3 e, quando uma desta for lançada, ele deve procurar na tabela e aplicar o Nanomite necessário.
E magicamente (ou não...) temos os Nanomites fora do nosso caminho!
Obs: Caso o programa já tenha um VEH próprio, você vai ter que colocar um hook na função RtlAddVectoredExceptionHandler e apagar o seu VEH antes de o programa instalar o dele e, após isso, você deve substituir pelo seu VEH. Meio complicado, mas possível
Conclusão:
Bom...certamente muitos desistiram de ler...uns por causa do tamanho do tópico e outros por causa da dificuldade.
Para crackers iniciantes e para a maioria dos intermediários, isso parece um tanto quanto estarrecedor, mas não tenham medo... "é só pegar o jeito".
Se você acha que ainda não é capaz de fazer isso, não tem problema, continue estudando e um dia você vai conseguir. O Armadillo é uma proteção extremamente complicada e muito "rebelde"...você tem que saber "adestrar" ele.
TODO o texto presente aqui é de autoria minha exclusiva para o GH.
Se você for copiar, coloque os créditos. (a não ser que você seja um lammer leecher lixo, daí não adianta falar, né?)
Enfim, Espero que gostem. =)
Flws
Nesse tópico pretendo falar um pouco sobre os Nanomites encontrados no Armadillo(proteção anti-cracking) e que atualmente estão sendo implantados em outros softwares de proteção também. Darei ênfase ao Armadillo por ser o "berço" dos Nanomites e por ser um software comercial de proteção anti-cracking muito poderoso.
Comecemos...
O Debug-Blocker
Não tem como falar sobre os Nanomites sem antes explicar o Debug-Blocker do Armadillo. Basicamente, como o próprio nome já diz, o Debug-Blocker serve para impedir que debuggers sejam usados para modificar o programa que está protegido.
O funcionamento é simples...quando o programa é executado, o DB(Debug-Blocker) cria 2 instâncias do programa (2 processos), um chamado pai e o outro filho. O processo pai é uma espécie de debugger, porém é um debugger que roda em nível de usuário; o que ele faz é monitorar o processo filho, que é quem faz todo o trabalho e, caso qualquer alteração "maliciosa" seja detectada no processo filho, o processo pai termina a execução do programa.
Mas é fácil burlar o Debug-Blocker, basta saber a hora e o lugar certo para fazer alterações e você consegue tirar o processo pai e colocar o seu debugger no lugar dele, podendo então fazer o seu reversing...
Exatamente por causa disso, os inteligentes programadores do Armadillo resolveram criar os Nanomites, uma solução muito inteligente, que para crackers iniciantes e intermediários é uma pedra no sapato.
Os Nanomites
Quando o programa protegido é executado, as partes do código selecionadas são escaneadas em busca de Jumps (JNZ,JNE,JMP...) e uma tabela é criada com a localização dos Jumps e seus tipos, isto é, uma tabela contendo o endereço em que o jump está, o tipo dele e o offset dele. No lugar de cada jump escaneado, é colocada uma instrução "INT 3" e então a tabela dos Jumps é entregue ao processo pai.
O funcionamento disso é o seguinte: quando o processo filho executa uma instrução INT 3, o processo pai toma o controle e decide qual é o jump que estava ali e que deve ser executado. Isso encontrado, ele diz ao processo filho para onde ir e "devolve" a execução a ele.
Isso aumenta muito a dificuldade para os crackers iniciantes e intermediários, pois qualquer alteração corrompe imediatamente e irreversivelmente o executável.
Mas pra dificultar um pouco mais, toda a informação necessária para restaurar o executável a um estado em que ele funcione está guardada a 7 chaves e criptografada várias vezes dentro daquela tabela, somente acessada por rotinas extremamente ofuscadas e com proteções contra debuggers.
Resumindo...crackear um programa protegido com nanomites exige uma certa experiência e muita paciência, senão você pode ficar eternamente tentando crackear e sempre tendo que reinstalar o programa e isso, na minha opinião, é impraticável. :cool:
"Legal, Black-Hat. Mas pra que você explicou tudo isso se você não vai dizer como lidar com isso?! :mad: "
Quem disse que não vou dizer como lidar com isso? :cool:
Pegando a preciosa tabela
Bom...o jeito que vou explicar aqui pode não ser o melhor, mas é o método que uso. Ele envolve programação, porém não vou ficar colocando códigos aqui, vou dar a idéia central e o programa fica por conta de cada um. Afinal, ficar copiando códigos não é legal
(Quem sabe mais pra frente eu coloque um código la na área de programação
)O método consiste basicamente em monitorar o debugger, isto é, monitorar o processo pai.
Para isso, precisamos colocar 3 hooks nele:
WaitForDebugEvent: Com um hook nessa função podemos inventar e lançar "qualquer" exception e fazer com que o processo pai tente processá-la.
GetThreadContext: O processo pai chama essa função quando o processo filho pára em uma interrupção "INT 3". Sendo assim, com um hook aqui, podemos falsificar uma interrupção em qualquer endereço e fazer o processo pai pensar que é um endereço de Nanomite.
SetThreadContext: Depois de decidir qual o Nanomite (qual o Jump) em questão, o processo pai usa essa função para forçar a execução do processo filho de acordo com o Nanomite encontrado, isto é, para "aplicar" o Nanomite. Um hook aki e podemos obter informações sobre o Nanomite a ser aplicado.
O que temos que fazer é achar todas as interrupções INT 3 (0xCC) na seção de código (.code section) e , para cada uma, o programa deve lançar uma INT 3 e ver como o processo pai reage. Para determinar o tipo de Jump em questão, basta mudarmos as EFlags várias vezes para um mesmo Nanomite. Após todos os Jumps serem analisados, temos a preciosa tabela de Nanomites.
Mas a vida é uma caixinha de surpresas...
:cool:O problema dos falsos Nanomites:
Ahhh...tudo parecia estar indo tão bem...e agora você vem com mais problemas, Black-Hat?
Sim...mas é fácil (ou quase fácil) resolver esse
Bom...o que acontece é que os programadores do Armadillo são realmente muito inteligentes. Na tabela de Nanomites do processo pai, existem entradas falsas de Nanomites
Isso significa que uma CALL,por exemplo, pode gerar uma linha na tabela. Essa linha nunca será usada pelo processo pai, por motivos óbvios: a INT 3 vai estar no meio de uma instrução, o que significa que ela não pode lançar uma exceção.
O grande problema disso é que precisamos separar os falsos dos verdadeiros, quase todos os métodos são um tanto quanto ineficazes e acabam por deixar 1 ou mais linhas falsas na tabela ou então acabam por excluir linhas verdadeiras.
Mas existe um que nos "salvará dessa grande calamidade"... :confused:
VEH (vectored exception handler), Nosso Salvador :
O VEH é muito pouco utilizado, mas será nosso salvador nesse caso.
Com ele, podemos colocar um exception handler "global" no programa que não depende de SF(Stack-Frames)...
Mas por que ele irá nos salvar?
Simples...ele é chamado antes do SEH (Stack Exception Handler)...
"Mas, e daí ???"
Calma, vou explicar...vamos só fazer algumas suposições antes.
Daqui em diante vou supor que você já removeu todas as outras proteções presentes no programa, e que o programa roda SEM o processo pai até encontrar um Nanomite. Isto é, a única proteção que lhe resta arrancar são os Nanomites. Também supondo que o programa em questão não tem nenhum VEH próprio, é claro.
Bom...O seu programa estando na situação descrita acima, quando ele chegar em um Nanomite, uma exceção 0xCC (INT 3) vai ser lançada e tudo vai pro ar como um balão de chumbo cheio de hélio (sim...balões de chumbo voam! Por um acaso você não assiste Mythbusters?! Se não, devia assistir!).
É aí que entra o VEH, se um VEH estiver presente, através dele podemos assumir o controle quando uma exceção INT 3 for lançada e "aplicar" o Nanomite.
Assim sendo, basta colocarmos em algum lugar do executável a tabela de Nanomites(mesmo com as entradas falsas) junto com o código que cria o VEH e depois volta pro EP(entry point) original do programa.
Após colocarmos o código e a tabela, desviamos o EP para o nosso código. O código deve criar o VEH e retornar para o EP original do programa.
O nosso VEH deve apenas tratar exceções INT 3 e, quando uma desta for lançada, ele deve procurar na tabela e aplicar o Nanomite necessário.
E magicamente (ou não...) temos os Nanomites fora do nosso caminho!
Obs: Caso o programa já tenha um VEH próprio, você vai ter que colocar um hook na função RtlAddVectoredExceptionHandler e apagar o seu VEH antes de o programa instalar o dele e, após isso, você deve substituir pelo seu VEH. Meio complicado, mas possível
Conclusão:
Bom...certamente muitos desistiram de ler...uns por causa do tamanho do tópico e outros por causa da dificuldade.
Para crackers iniciantes e para a maioria dos intermediários, isso parece um tanto quanto estarrecedor, mas não tenham medo... "é só pegar o jeito".
Se você acha que ainda não é capaz de fazer isso, não tem problema, continue estudando e um dia você vai conseguir. O Armadillo é uma proteção extremamente complicada e muito "rebelde"...você tem que saber "adestrar" ele.
TODO o texto presente aqui é de autoria minha exclusiva para o GH.
Se você for copiar, coloque os créditos. (a não ser que você seja um lammer leecher lixo, daí não adianta falar, né?)
Enfim, Espero que gostem. =)
Flws
Comment