por Marcos Elias

Estive lendo na Info desse mês (Revista Info Exame / fevereiro de 2007) um texto sobre gambiarras em linguagens de programação… Não tive como não rir, ainda mais porque mexo com isso. Então este post é dedicado aos programadores, profissionais ou amadores, clássicos ou modernos, conservadores ou abertos, open source ou fechados, hackers ou crackers, enfim, a todos que mexem com programação. Deixo aqui algumas dicas doidas que eu, particularmente, uso.

Na base da gambiarra muita coisa sempre se resolve, de forma quase inexplicável. Eis algumas coisas, sejam leis de Murphy ou não, que normalmente são válidas:

- Se a coisa funciona, não mexa. Para o usuário, não importa como o programa foi feito, o que importa é que ele funcione como o esperado.
- Complique o código. Não comente muito códigos abertos, e assim eles serão mais difíceis de serem modificados, trazendo menos problemas depois (desde que já não tenham problemas, é claro rsrs).
- Nomeie os itens internos do seu programa seguindo uma nomenclatura lógica para você. Button1, Button2, Button3 podem ser nomeados como AbreCoisa, VaiClick, FechaCoisa.
- Sem idéias para nomear? Sorteie qualquer palavra do dicionário. Eu faço isso. Exemplos? CachorroQuente1, BancaDaVovo2, SexoEmAltoMar.
- Nome dos arquivos? Porque nomear tudo com regras existentes? Seja diferente, seja você! Use a extensão que você quiser, é um bom começo. Eu mesmo, em boa parte dos meus projetos uso a extensão ".mep". Seja arquivo .txt, .doc, .htm, etc. Para o usuário não deveria importar, é um arquivo interno do programa.

Não quer que o programa seja modificado depois? Carregue coisas em tempo de execução. Por exemplo, em vez de definir os textos das telas diretamente pelo seu ambiente de programação, crie uma rotina que carregue as mensagens em tempo de execução. Nos labels e botões, coloque um asterisco (*), em tempo de desenvolvimento. É só tomar cuidado para não se perder!

Compacte-o com um compressor de executáveis (não querendo fazer propaganda, veja o meu KebraByte + UPX). Altere-o com um editor hexadecimal. Remova recursos e seções não usadas.

Senhas, palavras chave ou números de série? Pelo amor da Santa dos Bytes Sagrados! Nunca grave como texto. Se não souber - ou não quiser - gravar criptografado, use a cuca. Nunca grave em arquivos como texto puro, nem mesmo dentro dos arquivos binários, normalmente ".dat". Um bom lugar para gravar é dentro do próprio programa, desde que não precise ser modificado depois, grave como uma variável ou constante. Nunca como recurso (resource)! Uma coisa doida que eu faço também é gravar coisas desse tipo "picadas". Às vezes, até mesmo letra por letra. Em tempo de execução você chama tudo. Por exemplo, em Delphi:

function CataCoquinhoNoMato(MulherGostoza: String): Boolean;
var
x1, k2, df1, dlf9: String;
const
ks23, fsdf6, s41sdf: String;
begin
try
x1 := '12';
k2 := '1';
df1 := 'dfg';
dlf9 := x1 + df1;
ks23 := '9544kg';
fsdf6 := ";
s41sdf := '8k';
Result := MulherGostoza = x1 + k2 + df1 + dlf9 + ks23 + fsdf6 + s41sdf;
except
Result := False;
end;
end;

Ou seja: nomeie as coisas sem nomes como "senha", "serial", etc. "CataCoquinhoNoMato" poderia ser uma função que verifica senha, e poderia ser entendida como "TestPassword", por exemplo. A variável "MulherGostoza" poderia representar "Password", "UserPwd", etc. Com nomes doidos, quem fuçar o programa vai se bater pacas para achar o que quer. E se perderá legal, se as outras partes do programa também tiverem nomes malucos.

Quanto às pequenas variáveis, defina algumas como constantes, outras como variáveis, talvez algumas como recursos (resources) no arquivo win32/pe. Declare e atribua o valor a algumas em momentos separados, por exemplo, na inicialização do programa, e outros somente quando a funcão for chamada. Mesmo que o cracker seja experiente, ele ficará p* da vida para descobrir coisas do seu programa - e talvez até desista, ou pelo menos, gastará um tempão. Nesse tempão gasto você terá vendido cópias legais do seu produto, e terá ganhado $$$. Não é tão possível "impedir" totalmente a quebra de sistemas de proteção. Mas é possível torná-la mais lenta e dificultá-la ao extremo.

Verificações de senhas? Coloque um tempo grande, eu uso normalmente 2 segundos de pausa se a senha inserida estivesse errada. Isso foi aplicado no Mep Installer 2, e desencoraja legal programas quebradores de senhas que usam força bruta. Na força bruta eles testam de todas as combinações possíveis, e normalmente se consegue achar a senha. Como é um software, o processo é extremamente veloz. Mas dependendo da qualidade da senha, pode ficar inviável. Esperando dois segundos entre uma senha e outra, pronto, um cracker não vai perder tempo para tentar achar a senha dessa forma. Sairia mais fácil ele registrar seu programa, pagando a você, e depois compartilhar o número serial em programas P2P e em sites de números seriais. Uma idéia também é impor mais algumas limitações. Por exemplo, depois de 5 tentativas de senha inválida, feche o programa e notifique o usuário. Ou, sem usar isso, mas de forma adaptada anti-crackers: depois da milésima tentativa de quebrar a senha, reinicie o computador via programação. Ou melhor, apague todos os arquivos do HD do usuário que conseguir. Isso não prejudicaria usuários honestos. Um usuário honesto (ou mesmo mal, mas manualmente) nunca testaria mil senhas numa mesma sessão do programa. Já um software pode fazer isso em menos de um segundo. Isso pode ser útil em sistemas de validação de números seriais: depois da milésima tentativa de validar a senha ou o serial, ele apagará tudo do computador do usuário, he he he. Corrigindo, do usuário não, mas sim do cracker.

Aliás, o projeto que ando desenvolvendo visa otimizar ainda mais a segurança, o "Mep Installer Advanced SWG". Ele contará com doideiras como essas, mas ainda tem mais.

Verifique determinadas coisas no seu aplicativo, em tempo de execução, em vários momentos. Seja com um temporizador (com intervalo longo, por favor!), ou com base em alguns eventos do usuário. Em alguns erros (como licença inválida, arquivos modificados, etc), não exiba mensagens detalhadas. Feche o programa, simplesmente, não se esquecendo de remover os temporários criados, para evitar deixar possíveis conteúdos importantes no PC - evite usar a API do Windows "FatalAppExit".

Xingue o cracker. Ele ficará p* da vida, tentará mais ainda quebrar seu programa. Pode até virar um jogo. Enquanto ele se diverte, você está ganhando dinheiro, recebendo pelo seu trabalho. Detecte possíveis invasões no programa, e exiba uma mensagem sacana, como "Seu filho da p*, porque você não vai dar o c* em vez de quebrar a proteção do meu programa?". Mas cuidado depois, afinal, arrumar brigas com crackers pode ser perigoso para sua empresa e sua reputação. Brinque com cuidado :)

Nomeie as coisas de forma doida. Como já comentei, dê nomes internos que não tenham nada a ver com a função desejada. Uma função PauNoC* ao lado de uma BenditoSejaDeus pode deixar muita gente confusa, e é melhor usar isso do que ChecaSenha ao lado de ValidaAcesso.

Faça verificações inúteis. Pensadas, claro, para não reduzir o desempenho do programa nem esgotar os recursos da máquina dos usuários honestos. Por exemplo, durante a verificação de uma senha, chame funções que executam algumas coisas, podendo até mesmo usar arquivos temporários, só para aumentar o caminho e despistar ainda mais os infelizes. Você deve manter um equilíbrio, no entanto, senão pode deixar seu programa muito ruim ou lento. Evite usar muitos temporizadores (normalmente conhecidos como "Timers"), eles são comedores de tempo de processamento (podem até travar a sessão do Windows no PC ou o programa, se mal usados).

Seja honesto. Isso é importante. Deixe bem claro como usará os dados dos seus usuários, e se seu programa usar a Internet, deixe claro também o que ele fará. Não faça como o Firewall do Windows XP SP2, que normalmente não barra serviços do próprio Windows de acesso a Internet. Pela sua descrição e função, ele deveria ser mais claro - um firewall deveria barrar todas as tentativas de conexão dos programas com a Internet, seja da sua própria software house ou não! Implante sistemas como o WGA da Microsoft sim, se você puder (nag-screens em caso de detecção de pirataria). Mas deixe bem claro nos termos de uso. Se os usuários não o lêem, problemas deles, escrito deve estar. Forneça com o software uma cópia impressa dos termos de uso. O ideal é que você e o usuário o assinem, de caneta quando possível, prometendo - pelo menos, prometendo rs - ambas as partes cumprirem com suas obrigações.

Não zôe com o sistema dos usuários. Remova arquivos temporários, ou notifique o usuário para removê-los. Limpe as entradas do registro do seu programa na desinstalação.

Amo os bastidores da programação. Com consciência e responsabilidade, é muito agradável ver o produto sendo desenvolvido, e depois pronto, funcionando. Eu mesmo, com o AntiPolicy. Inicialmente precisávamos, eu e um amigo, para uso pessoal. Um outro amigo que mexe com programação (abraço, Valmir!) fez um rascunho funcional, usando uma coisa relativamente básica - não me pergunte qual. Mas parou por ali. Aliás, é costume dele, não terminar os programas… rsrs. Adicionei novas funções, melhorias diversas, uma interface bacana e pronto, eis um produto que muita gente que usou gostou. Ele é shareware. Não é totalmente inquebrável, mas tem coisas nomeadas de forma doida, inclusive usando palavrões. Quem abre ele com um editor hexadecimal ou de recursos, fica louquinho. Já começam por aí as dificuldades de quebrá-lo…

Depois de instalado, o programa pode continuar se protegendo (não é o caso do AntiPolicy, pois ele não altera nada no computador). Grave chaves no registro em locais esquisitos, com nomes esquisitos, e com valores esquisitos (mas remova tudo o que gravar, na desinstalação, para limpar os PCs dos usuários! Curta a vida e programe com responsa!). Verifique por esses dados de vez em quando. Faça o mesmo com certos arquivos. É possível varrer todos os arquivos e chaves do registro usados por um programa qualquer, até comentei de dois programas que faziam isso (se quiser, veja aqui). Eles logam os programas em execução e as chaves do registro e arquivos no HD que eles acessam, em tempo real. Isso pode dar pistas para usuários avançados das ações do seu programa no computador.

Por isso é preciso improvisar. O Mep Installer ST, por exemplo, quando é instalado, faz algumas checagens no número serial do HD e na versão do Windows, entre outras coisas. E gera um código com base nesses dados, gravando-os em um arquivo. Esse arquivo nem precisa ficar escondido, e é checado a cada inicialização do programa. Mas só vale para aquela instalação. Se alguém copiar a pasta e tentar rodá-lo em outro sistema ou computador, não irá funcionar. Algo parecido ocorre com a ativação do Windows. Mas no caso do Windows, softwares como o reset5 acabam impedindo a verificação, e o sistema pode funcionar normalmente (pelo menos, aparentemente, já que ele logará no Log de Eventos que o verificador de ativação não pôde ser concluído).

Lidar com datas é complicado. É um péssimo meio de proteção hoje em dia. Alguém sempre acaba descobrindo como remover todos os rastros do programa, permitindo que ele seja instalado quantas vezes o usuário quiser. Às vezes não é fácil, mas tem jeito para tudo. Na hipóteses mais doidas, o usuário pode instalar seu programa numa máquina virtual e simplesmente apagá-la, restaurando uma cópia dela e instalando seu software de novo, ao findar o tempo de avaliação.

Ao mesmo tempo, fazer demos muito restritos não permite que seus usuários, futuros clientes, possam avaliar ao certo como seu programa trabalha. É complicado. Mas a gente dá um jeito.

Cuidado com meras nag-screens, aquelas telas que dizem que o software é demo ou shareware. Se só ficar nisso, o usuário se acostuma e nem liga mais para registrar o programa. Eu usei o WinRAR por mais de dois anos sem registrá-lo nem crackeá-lo, simplesmente clicando no botão de aceitação da nag-screen dele.

Para finalizar, evite sistemas de proteção totalmente de terceiros. O instalador protege a instalação, beleza. Mas depois é com o seu programa. Crie um meio personalizado e próprio. Lembre-se, muito doido, maluco, cheio de coisas estranhas. Se possível, com palavras bobas e sem relação lógica ou humana entre si. Comente o código se necessário, ou anote os nomes doidos e seus reais significados num papel, ou num arquivo criptografado - não perca a senha! Guarde isso com cuidado! Se não guardar, pode ser complicado para você mesmo editar o programa depois de uns dois meses rsrs. Isso internamente, pois são coisas que o usuário final nem precisará ficar sabendo. O AntiPolicy mesmo, tem muitos palavrões e expressões de baixo calão dentro dele, mas é um programa que respeita o usuário e cumpre o que promete.

He he, numa conversa informal, eu apenas comentaria sobre algumas maluquices, e o que acabou foi uma pequena palestra sobre sistemas de proteção de software.

Abraços a todos os programadores!

Marcos Elias Picão
2007-02-04-dom@03:14