Desvendando a Criptoequação: Resolvendo a Validação de Licença Não Linear e Contornando Armadilhas de Obfuscação

Alguns desenvolvedores de software implementam algoritmos de verificação de licença customizados e complexos. Entender os princípios por trás desses algoritmos pode ser um desafio. Neste artigo, vamos analisar o código desobfuscado de um desses algoritmos, resolver uma criptoequação não linear, filtrar dependências falsas e criar um gerador de chaves (keygen) funcional. Durante a engenharia reversa, utilizaremos inteligência artificial (IA) como assistente, avaliando suas capacidades analíticas nesta área.

Aviso: Este artigo tem fins informativos e educacionais. O autor e a editora não se responsabilizam por quaisquer danos causados pelo uso das informações aqui apresentadas.

Já exploramos algoritmos de criptografia padrão ou suas modificações em artigos anteriores. No entanto, em algumas situações, um algoritmo customizado pode ser um bom exercício mental, mesmo que implementado em um Basic .NET comum. No meu artigo "A Chave Dourada: Analisando o Princípio da Criação de Keygens com um Exemplo", discuti como os desenvolvedores protegem programas gerando chaves de licença e como criar esses geradores.

Analisamos um caso simples e uma modificação mal concebida de um algoritmo de criptografia padrão. Recentemente, encontrei uma implementação engenhosa de verificação de código de produto que não utiliza algoritmos padrão.

O desafio é o seguinte: temos um programa que requer um código para ativação, dependente do nome do usuário. Se o código correto for inserido, a ativação do programa avança para a próxima etapa; caso contrário, é interrompida.

O programa é bastante comum, escrito em VB.NET, e não utiliza proteções complexas. Todo o código está visível, embora o fluxo de controle esteja levemente obfuscado, provavelmente por um obfuscação simples e customizado:

PE32
Operation
system:
Windows(
95)[
I386,
32-
bit,
GUI]
Linker:
Microsoft
Linker
Compiler:
VB.
NET
Language:
VB.
NET
Library:.
NET
Framework(
CLR
4.0.30319)
Tool:
Microsoft
Visual
Studio
(
Heur)
Protection:
Anti analysis[
Anti-
debug]
(
Heur)
Debug data:
Contains[
Absolute
PDB
path]
_debug_data.
5.sg:
PE/
_debug_data.
5.sg:
10:
TypeError:
Result
of
expression
'PE.
getNumberOfDebugDataRecords' [
undefined]
is
not
a
function.

Portanto, os primeiros passos são simples: o programa é facilmente carregado no depurador dnSpy e permite a depuração, o que nos permite encontrar rapidamente o local de validação do código do produto com base no nome do usuário.

Seria ótimo se a expressão destacada fosse uma igualdade do tipo f(Name) == ProductKey. Nesse caso, simplesmente reverteríamos a função e obteríamos um algoritmo pronto para transformar o nome em uma chave. Mas não é tão simples: se observarmos atentamente o código, obtemos uma criptoequação complexa de forma simplificada:

Lenstr("Unregistered7777766666", "11111-22222-33333-44444-55555") == Cval("11111-22222-33333-44444-55555")

A principal dificuldade é que os primeiros cinco grupos do ProductCode entram em ambos os lados da equação, o que significa que teremos que resolvê-la. Para piorar a situação, os resultados das funções à direita e à esquerda são strings longas de dígitos decimais, com comprimentos diferentes. O código dessas funções parece assustador sob obfuscação, especialmente a função Lenstr, que, após uma inspeção mais detalhada, parece envolver o tempo atual de alguma forma.

[Conteúdo restante bloqueado]