Apesar das técnicas utilizadas para a proteção, o dongle pôde ser facilmente emulado. De posse de um dongle legítimo, os parâmetros de comunicação foram arquivados para uma posterior reprodução pelo emulador.

Ao se substituir a biblioteca responsável pela interface software <> dongle, o C50032.DLL, o programa principal não é executado corretamente. Abrindo-o pelo Windows Explorer, nada acontece. Ao executá-lo no debugger com o tratamento de exceções ativados, pode se notar a tentativa de execução de um endereço inválido.

Após estudos sobre o acontecimento, foi encontrado um vínculo de IPC entre a biblioteca e o envelope do programa principal. O DLL fornecia uma “pequena assinatura” e uma chave que seria usada posteriormente em uma função de encriptação no dongle.

Na ausência destas informações, um trecho de hash do envelope falhava, resultando em um endereço-resultado inválido.

É utilizado o IPC tipo File Mapping. O DLL cria um mapeamento de arquivo, com um nome baseado no seguinte critério:

“DrSym%08X%08X” “DrSym” + Cálculo sobre o ID do Processo atual + Hash do caminho do DLL

Uma vez este mapeamento foi criado pelo DLL, ele o preenche com a assinatura e a chave. O código envelope posteriormente gera o mesmo nome, baseado no critério citado acima, e tenta abrí-lo. Após sua abertura, copia os dados fornecidos pelo DLL para uma posição da memória, limpa o arquivo mapeado, e dá continuidade a decriptação do software.

Uma vez fornecida a senha inicial, a string criptografada da chave, e posteriores checagens (7 conjuntos de bytes), o dongle estará completamente emulado. Porém, uma vez utilizado as funções de abrir ou salvar (Shell do Windows), o software passava a consumir 100% de CPU, até a hora que fosse encerrado. Com uma breve análise, foi descoberta “coisas sujas” que o DLL andava fazendo, como fazendo hook em funções do Windows, como GetTickCount e até mesmo funções nativas como ZwSetInformationThread. Uh oh?!

Checagens temporizadas eram feitas, utilizando-se a API SetTimer, com um callback locado no espaço de memória residido pelo envelope ainda em tempo de execução. Verificações eram realizadas por este trecho análise pendente. Uma condição não satisfeita, resultaria em uma rotina de erro, cujo flag para indicar o fato, é a DWORD “0x00BABACA”. Éramos esperados? 😉

Um passo além seria a remoção do “Envelope” (wrapper) do executável, resultando no software limpo de checagens e verificações.

Encontrando o OEP do executável (escrito em Delphi), o “combo” Dump + Reparo da IAT (removido vínculo com C50032.DLL) resultou em um executável funcional. O último passo foi remover as chamadas para as funções “C500″, responsáveis pela comunicação software (envelope) <> C50032.DLL.

Edit: não faço emuladores por preço algum, não adianta perguntar. O texto acima é somente para pesquisas e nada que viabilize cópia ou pirataria. Caso queira pesquisar sobre, certifique-se que tenha conhecimento sobre engenharia reversa de software, saiba assembly e como utilizar um depurador.