Anti-Descompilador (X)Harbour

[Maligno]

Também imagino que pode não haver motivo para tanta preocupação. São necessários dois fatores para a tranqüilidade ir embora: viabilidade e motivação. A viabilidade só virá depois que vier a ferramenta pra descompilar. Ninguém sabe ao certo se já existe. E se existe ou vier a existir, ainda é necessária a motivação. Para que alguém se disponha ao trabalho (talvez não tão trivial, pois depende da qualidade da ferramenta) de descompilar, o alvo precisa realmente ser muito compensador. Ninguém vai se dispor a perder tempo com algo que não dê retorno. É como fazer crack. Ninguém faz crack pra programa sem importância. É preciso haver um bom motivo para que a ganância aflore.

[carlos_dornelas]

vagucs escreveu:
E a pior noticia, mesmo programas encriptados tanto no windows como no DOS, na sua hora de execução não pode estar encriptado na memória, com o DClip 3.3 já usamos uma ferramenta anexa que "chupa" o PCODE da memória, já testamos com xHarbour com programas super encriptados e protegidos, durante a execução fica tudo na memória e pode-se facilmente ler o seu conteúdo e descompilar

Vagucs ou Maligno, vocês podem indicar algum aplicativo que consegue mostrar o EXE descompactado na memória. Fiquei curioso para ver o meu aplicativo que contém algumas strings caracteres que servem, as vezes, de senha...

Abraços

Antonio Carlos

[Maligno]

Nào conheço nada específico pra isso. Mas um debugger Assembly ajuda bastante a bisbilhotar. Mas se quer saber se suas senhas estariam visíveis e desprotegidas, pode ter certeza disso. Quem quiser (e puder) ir atrás, conseguirá. É melhor encriptá-las. Não é prudente deixá-las "in natura" dentro do EXE.

[yugi386]

Não é possível descompilar (recuperar o fonte de) um programa em C. Pode-se desmontá-lo para recuperar seus códigos mnemônicos Assembly. Ainda assim, é uma tarefa muito difícil, pois existem outras tantas dificuldades técnicas. Recuperar os fontes (descompilar) só mesmo para programas interpretados, que possuem opCodes, como Clipper e XHarbour.

Se não é possível descompilar (somente recuperar códigos assembly) de um código em C, talvez fosse útil criar uma ferramenta que traduza código clipper/harbour para C. A exemplo de alguns language translator de antigamente. Este código seria compilado em harbour mas como uma função C. Logo não teria OPCODES e naturalmente obrigaria o atacante a "desassemblar" o codigo na unha, o que seria bastante trabalhoso.
Algumas instruções podem facilmente ser facilmente transcritas como estrutura do while e comandos básicos. Sei, entretanto, que as funções de manipulação de DBF teriam que ser escritas em C de modo que elas se comportem exatamente como se estivessem escritas em clipper. Naturalmente as rotinas que somente são apresentadas na tela, como @ say e funções de bibliotecas gráficas ficariam "in natura".

Será que existe algum software que faz este trabalho?
Em caso negativo, será que é viável construir tal ferramenta?

[vailton]

Usa-se a opção /go3 (senão me engano) nas versões mais recentes do xHarbour e do Harbour para obter-se código em C e não PCodes do source original escrito em xBase.

[Maligno]

Não adianta. O XHarbour vai gerar o código C para empilhamento e execução dos opCodes do mesmo jeito. Aliás, fica um lixo, de onde sai até GOTO.

O que eu entendi do que o colega sugeriu é trocar funções e comandos nativos do Clipper por funções e comandos equivalentes em C. Nada de opCodes. Há muito tempo ouvi falar de um programa (acho que era CodeBase o nome) que diziam fazer essa conversão. Nunca testei pra confirmar. Mas é perfeitamente possível.

[mhackervix]

Até que exista um Decopilador real se torna infundado um teste de eficiência de um sistema de proteção contra decopilação.
Proteger de quem !?!?!

att.

[Maligno]

Mas é como dizem: o prevenido vale por dois.

De qualquer forma, o colega Yugi, na primeira mensagem do tópico comentou que conseguiu um programa que protege. Se alguém fez uma proteção, é de se imaginar que pode existir um descompilador. E se há para o Clipper, nada improvável que exista para o XHarbour. A preocupação com a proteção, portanto, procede. Mas não é o fim do mundo também.