engenharia reversa dongle software protegido
eu era jovem, a internet só começou e poderíamos obter toneladas de software de graça. Era grátis porque alguém lá fora era “gentil” o suficiente para quebrar/consertar o.arquivo exe.
eu coloquei “tipo” entre aspas, porque essa era a visão que eu tinha quando era criança. Agora sou engenheiro de software e sei quanto esforço é preciso para construir software. Então, por favor, não baixe o software rachado. Apoie o desenvolvedor e compre uma licença!
aplicando tal rachadura, remendando o exe, eu sempre quis saber como fazer tal coisa. Acontece que você precisa entender o assembler, uma linguagem de máquina que apenas sua CPU entende (e alguns outros nerds por aí). Como era muito difícil, nunca consegui aprender. Até recentemente (como 20 anos depois 😊).
há um ano, comprei software (com licença!) que precisa de um dongle USB para funcionar. É realmente complicado ter esse dongle com você o tempo todo. Especialmente quando você está na estrada. Então eu procurei maneiras de contornar isso. A primeira coisa que encontrei foi este emulador de chave chamado MultiKey. Ele despeja a memória do seu dongle para o seu registro e, em seguida, emula o seu dongle lendo a partir do seu registro. Isso funcionou bem, até que eu queria executá-lo no Windows 10. Aparentemente, a Microsoft não é um grande fã do MultiKey. Na realidade, não é um grande fã de drivers não assinados e o MultiKey usa um driver não assinado. Então eu precisava de outra solução. Hora de mergulhar nessa coisa chamada assembly code!
eu sempre soube que havia uma ferramenta lá fora para engenharia reversa, chamada IDA. É capaz de descompilar o seu .arquivo exe e mostrar o que está acontecendo. Infelizmente, a interface é realmente difícil de entender. Eu também sabia sobre OllyDbg. É um depurador. Um depurador permite que você passo através do código assembler enquanto o programa está em execução! Ou seja, por exemplo, se você depurar o aplicativo da calculadora, poderá realmente vê-lo lidando com um pressionamento de botão, fazendo o cálculo e mostrando o resultado na tela. Inferno, você pode até pauze e mudar sua memória fazendo com que a calculadora retorne 5 ao perguntar o que é 2 + 2!
mas não estou aqui para alterar o cálculo (embora isso seja legal). Eu quero estar livre do dongle. Então eu abri meu aplicativo com OllyDbg.
Que foi realmente avassaladora. Eu não tinha ideia do que todos esses códigos significavam. Muito menos saber por onde começar. Então voltei para a prancheta. Acontece que há algo chamado RetDec, um descompilador que tenta fazer o código C sair do Código da máquina. Levei algum tempo para configurá-lo e executar a descompilação, mas o esforço pago. O resultado foi enorme .arquivo c, mais de 2 milhões de linhas de código com código semi-legível.
Na verdade eu poderia encontrar a leitura de código de bytes do dongle bastante fácil:
com essas informações, voltei ao meu depurador. Nesse meio tempo, descobri que OllyDbg é realmente antigo (a partir do ano 2000) e não é atualizado desde 2013. Então eu encontrei este novo depurador melhorado, chamado x64dbg. É de código aberto e tem uma grande comunidade de desenvolvedores trabalhando nisso.
linguagem da Máquina de leitura
em linguagem de máquina cada instrução tem um endereço de memória. Assim, com os endereços encontrados no RetDec código, eu me virei para x64dbg e eis que o código que lê o dongle:
no código assembly, os argumentos da função são carregados na memória usando o ponteiro da pilha esp. Em nosso código, isso acontece pouco antes da chamada para a função. (as instruções 3 mov indicam que a chamada leva 3 argumentos). Após a chamada, nosso ponteiro de pilha é redefinido e uma verificação (teste) é feita se a chamada para a função foi bem-sucedida. Se não, vemos o código fazendo um salto (jne). Este salto aponta para um pedaço de código indicando que o dongle não está presente.
como você pode ver, há uma chamada para uma função específica para ler o dongle. Procurei o Guia de referência para descobrir o que essa função faz:
A função lê a 2 bytes de memória (word) a partir do dongle. Como adivinhado, a função leva 3 argumentos em que o último argumento é um ponteiro para 2 bytes que conterão alguns dados do dongle.
no código de montagem, os argumentos são carregados na ordem inversa. Passar no último argumento é este:
O último argumento aponta para o rse de significado os dados do dongle vai ser armazenado no endereço de memória de rse está apontando para.
de Fato, quando a pausa de apenas depois que a chamada foi feita, podemos ver o resultado na memória:
0x74. Isso é o que é lido do dongle e armazenado na memória do programa principal.
para pular esta chamada, só preciso escrever 0x74 na memória para onde o esi está apontando. Isso é tão simples como a substituição das 7 linhas acima com:
Como você pode ver, eu também nop-ed o resto das instruções assembler, incluindo o teste, se a chamada à função era válido. Isso significa que o salto não será levado e o programa continuará a funcionar sem a verificação.
depois de corrigir todas as chamadas envolvendo o dongle, salvei o novo .exe. Eu puxei o dongle, corri o meu costume .exe e para meu próprio espanto funcionou! Eu tinha rachado com sucesso um pedaço de software.
outra coisa que cruzo da minha lista de desejos Ps
Ps: a maioria das Coisas foi ofuscada, como 0x74 e o nome do aplicativo. Isso não é para prejudicar os desenvolvedores que trabalham duro que criaram este software de forma alguma. Também tive muita sorte que o dongle só retornou bytes e não fez nenhuma criptografia por conta própria.