Proteger a memoria do vosso programa

[Guest plop]

Como sabem ou se não sabem passam a saber existem editores de memória, ou decompiladores, que pegam no vosso lindo .exe e vêm o source todo e lá se foi a vossa obra.... Para tentarem evitar esses ataques, nunca é possivel estar 100% seguro, usem este código para C++

#define DATA_SIZE
BOOL function()
{
   char pszData = NULL;
  
   //Allocate memory
   pszData = new char [DATA_SIZE];
   if(pszData == NULL){
      return(FALSE);
   }

   //Reset the memory Initially
   memset(pszData, 0, sizeof(char) *  DATA_SIZE);

   .... //Use the memory and free it before the return()    statement

  //The below part is Important to protect the data
  memset(pszData, 0, sizeof(char) *  DATA_SIZE);
  delete [] pszData;
  
  return(TRUE);
}

Eu não percebo nada de c++, mas Encontrei isto enquanto navegava na net, e achei importante.

como sabem eu sou fanatico por estas cenas...

Ωmega

[saramgsilva]

ou seja danificam o exe? nao é?? e isto vai proteger o exe desses ataques?  :dontgetit:

[vbmaster]

Não há nada como testar, mas eu também não conheço desses programas que mostram o osurce a partir do .exe

[Guest plop]

ou seja danificam o exe? nao é?? e isto vai proteger o exe desses ataques?  :dontgetit:

sim podem, podem danificar mudando o source ou copiá-lo para usar noutro programa....

Não há nada como testar, mas eu também não conheço desses programas que mostram o osurce a partir do .exe

Eu conheço alguns... eu consigo por exemplo ver o source do windows messenger só não consigo editá-lo porque a microsoft é boa demais pra mim...  ?

[saramgsilva]

ou seja danificam o exe? nao é?? e isto vai proteger o exe desses ataques?  :dontgetit:

sim podem, podem danificar mudando o source ou copiá-lo para usar noutro programa....

Não há nada como testar, mas eu também não conheço desses programas que mostram o osurce a partir do .exe

Eu conheço alguns... eu consigo por exemplo ver o source do windows messenger só não consigo editá-lo porque a microsoft é boa demais pra mim...  ?

fogo desta nao sabia...  ? tipo pq eu pensava que ao compilar ele criava o exe, mas "nao levaria codigo atras.."  bem.... uiui

entao eu no meu jogo do galo, dou o exe a outro grupo (nao dei...), e se eles souberem disto , conseguem ver o codigo que fiz ???  ? huummmmm  ? 

[Guest plop]

Pois é, olha por exemplo com os SWF's é a mesma coisa... basta sacar um decompilador e tens as imagens código do actionscript todo... transforma o swf em fla.

É claro qe existem muitas maneiras de tentar evitar estes atques mas muita gente não sabe...

[melSpeedl.ine]

existem "artimanhas" q conseguem descompliar em parte já os ficheiros compilados... - ou como acham q sao feitos a grande parte dos cracks??

agora esse d compilar.. e levar codigo atrás... humm nao acredito nessa...

simplesmente o q esses programas fazem - acho eu - é perceber o q o programa faz.. e escrever novamente numa linguagem q preencha os requisitos..

agora acho q isso nao é 100% viavel

[theproject]

Nop, o codigo nao vai atras. no entanto se o programa for compilado em modo debug fika com uma tabela no principio em k associa os enderecos aos nomes originais das funcoes e portanto é possivel ao fazer o decompile reconstruir o codigo de forma a k fike kuase 100% legivel. Sem o modo debug, a unika coisa que sabemos sao as funcoes de sistema pois o Decompiler consegue perceber que funcao é que tamos a chamar pelo seu endereco (k é de facto o k está no exe) . quanto às chamadas das nossas funcoes o melhor que ele pode fazer é inventar nomes para as funcoes.... No entanto fazer decompile de código makina de novo para uma linguagem de alto nível é na practica inviável porque o código mesmo que apareca nessa linguagem de altonivel vai ser muito diferente do original, especialmente se os programas forem compilados com modos de optimizacao (que sao qs todos)

Um pekeno exemplo disto é a tipica multiplicacao por um multiplo de 2. tipo na nossa source podemos ter tipo a=a*2;

O compilador se tiver a tentar optimizar vai olhar para akilo e em vez de fazer uma operacao de multiplicacao no cpu, o k ele faz tipicamente é um shift Left, k na practica dá o mm resultado, mas é em kuase todas as arkitecturas mais rapido, portanto o nosso exe vai ter uma operacao de shift left.

Agora se tentarmos descompilar o exe. o k vamos ver é kk coisa como a = a<<1;  que mesmo parecendo obvio k é o mesmo que multiplicar por 2, fazer este tipo de optimizacoes e outras muito mais obscuras torna o codigo practicamente ilegivel para um ser humano, especialmente kuando em vez de verem coisas como insereLista( xpto) ; vao ver um nome aleatorio tipo abdeas( sdf); LOL...

Se kerem uma razao matemática para isto é porque o processo de compilar é uma traducao de uma linguagem para outra, e para um dado compilador, se lhe derem uma source ele so consegue gerar um unico codigo makina que faz exactamente akilo que escreveram, no entanto o contrario nao é valido pois para um dado codigo máquina existem infinitos codigos fonte que se fossem compilados gerariam exactamente o código makina que nós temos no exe. Intuitivamente é facil de perceber isto porque ao compilar de linguagem de alto nivel para uma de baixo nivel se perde informacao(nomeadamente nomes de funcoes, nomes de vares, algumas instrucoes podem ser inuteis e nem seker aparecem no exe etc etc etc...)

A unica traducao em k nao se perde informacao quase nenhuma é de assembly para codigo makina e vice-versa porque existe uma correspondencia univoca entre cada instrucao assembly e cada instrucao k o cpu vai fazer, agora passar de assembly para C(por exemplo) já existem infinitas maneiras de gerar um codigo C que ao ser assemblado gera exactamente akele assembly.

No entanto o reverse engineering, é o suficiente para se perceber algoritmos e isso pode ser perigoso especialmente se akele algoritmo k voces inventaram é ultra eficiente e inteligente ou whatever e voces o kerem proteger. É tambem assim que se crackam a maior parte dos programas. Basta imaginar que a maneira mais simples de todas de um programa testar pa ver se a key é valida é pagar na key fazer uma conta e ver se dá um dado valor. Se nao der o prog nao corre, se der OK. Mas se fizerem o decompile, basta identificar este IF, retiralo e XARAM! o programa já nao liga nenhuma à key k lhe metem. Mais uma vez isto é um exemplo porque na práctica usam-se técnicas ultra sofisticadas de proteger um exe, como por exemplo encriptar parte do código do programa e depois em runtime o programa desencripta o seu próprio código e só depois é k o executa, tentar fazer o decompile cego de um exe deste tipo é como tentar ler xines (se nao souberem xines) e o proprio decompiler nao vai perceber nada, mas tb para isto pode-se dar a volta.

fikem bem []

[Destineo]

Boas,

O que o código inicial faz é limpar a memória onde vocês tiveram, não impede de modo algum que o mesmo exe seja descompilado etc. Torna mais dificil saber o conteudo da memória, pois terá que se apanhar o conteudo enquanto se estiver na função em questão, senão olhamos para a memória e só vemos 0's ... É uma ideia fixe, e parece-me excelente para programas que necessitam de mais protecção em relação aos dados que se encontram em memória, mas é muito dificil de controlar se usarem variáveis globais, ou outros módulos não controlados por nós.

Cool idea!!!

[ponto]

Como sabem ou se não sabem passam a saber existem editores de memória, ou decompiladores, que pegam no vosso lindo .exe e vêm o source todo e lá se foi a vossa obra..

não percebi esta parte.. e lá se foi a nossa obra? como é isso? porquê é que foi? ah?

[TheDark]

Tenham lá calma e não andem com medos infundados.

entao eu no meu jogo do galo, dou o exe a outro grupo (nao dei...), e se eles souberem disto , conseguem ver o codigo que fiz

Não é bem assim. A menos que o jogo tenha sido feito em assembly, é muito dificil chegar ao código fonte original a partir do código máquina. Isto é, suponho que têm que apresentar o código original :🙂

simplesmente o q esses programas fazem - acho eu - é perceber o q o programa faz.. e escrever noamente numa linguagem q preencha os requesitos..

É preciso estudar o código, ver o que está a ser feito, e tentar reproduzir na linguagem original. É preciso entender muito bem tanto a linguagem original, como a linguagem máquina.

Já li em qualquer lado sobre programas que fazem isto, mas tinham resultados muito limitados. É complicado de fazer manualmente, mas é muito mais difícil de fazer automaticamente, porque um troço de código (por exemplo) em C++ pode ser traduzido para linguagem máquina de diversas formas, dependendo do compilador e da optimização.

Vou tentar criar um exemplo com gcc-cygwin e o insight. Não me censurem se ficar confuso :🙂

o código (em c++) original

int main() {
int x=10;

x+=18;

int y=x+4;
++y;
return y;
}

depois de compilado pelo gcc sem optimização:

	16	int main() {
-	0x401050	<main>:		push   %ebp
-	0x401051	<main+1>:		mov    %esp,%ebp
-	0x401053	<main+3>:		sub    $0x18,%esp
-	0x401056	<main+6>:		and    $0xfffffff0,%esp
-	0x401059	<main+9>:		mov    $0x0,%eax
-	0x40105e	<main+14>:		add    $0xf,%eax
-	0x401061	<main+17>:		add    $0xf,%eax
-	0x401064	<main+20>:		shr    $0x4,%eax
-	0x401067	<main+23>:		shl    $0x4,%eax
-	0x40106a	<main+26>:		mov    %eax,0xfffffff4(%ebp)
-	0x40106d	<main+29>:		mov    0xfffffff4(%ebp),%eax
-	0x401070	<main+32>:		call   0x4010a0 <_alloca>
-	0x401075	<main+37>:		call   0x401130 <__main>
17		int x=10;
-	0x40107a	<main+42>:		movl   $0xa,0xfffffffc(%ebp)
18	
19		x+=18;
-	0x401081	<main+49>:		lea    0xfffffffc(%ebp),%eax
-	0x401084	<main+52>:		addl   $0x12,(%eax)
20	
21		int y=x+4;
-	0x401087	<main+55>:		mov    0xfffffffc(%ebp),%eax
-	0x40108a	<main+58>:		add    $0x4,%eax
-	0x40108d	<main+61>:		mov    %eax,0xfffffff8(%ebp)
22		++y;
-	0x401090	<main+64>:		lea    0xfffffff8(%ebp),%eax
-	0x401093	<main+67>:		incl   (%eax)
23		return y;
-	0x401095	<main+69>:		mov    0xfffffff8(%ebp),%eax
-	0x401098	<main+72>:		leave  
-	0x401099	<main+73>:		ret    

com optimização de nível 1 (o compilador vê que o resultado é sempre o mesmo e simplesmente retorna o valor depois de inicializar o programa):

	16	int main() {
-	0x401050	<main>:		push   %ebp
-	0x401051	<main+1>:		mov    %esp,%ebp
-	0x401053	<main+3>:		sub    $0x8,%esp
-	0x401056	<main+6>:		and    $0xfffffff0,%esp
-	0x401059	<main+9>:		mov    $0x10,%eax
-	0x40105e	<main+14>:		call   0x401070 <_alloca>
-	0x401063	<main+19>:		call   0x401100 <__main>
-	0x401068	<main+24>:		mov    $0x21,%eax
-	0x40106d	<main+29>:		leave  
-	0x40106e	<main+30>:		ret    

e os restantes níveis de optimização são iguais ao nível 1, devido à simplicidade do programa.

Mas por aqui se vê que mesmo um programa tão simples tem já 2 maneiras completamente diferentes (embora façam exactamente o mesmo, que é retornar o valor 33, ou 0x21) de ser compilado pelo mesmo compilador. Imaginem a complicação que seria conseguir um descompilador para todos os produtos existentes por aí.

[Mythos]

Boas!

Penso que já está tudo dito, mas acho que é importante salientar uns pontos que acho serem importantes.

Esta técnica, na melhor das hipoteses apenas vai dar um pouco mais de trabalho a um cracker. Com w32dasm ou com o softice é fácil determinar o conteudo da memória e etc. Acho que não é algo com que se devam preocupar porque não existe nenhum software 100% seguro. É claro que há formas de complicar a vida ao cracker (programação obscura e tal) e até mesmo compressores de exe. Mas como disse, tudo é "crackavel", desde que haja paciência.

My 2 cents 😄

[Elektron]

Como ja foi dito, sem informações do debuger, o codigo gerado pelo decompilador é indecifravel.

[undercover]

para isso existem os obfuscator's, de certeza que ninguem vai perceber porra nenhuma se fizer disassemble de um Exe depois de se utilizar um obfuscator  😕

mm compilando o código em release a algoritmia está lá implicita

[IceBrain]

Mas nenhum cracker vai utilizar um decompilador, normalmente têm um conhecimento razoável de assembly.

Já agora, o código é facilmente ultrapassável pondo um breakpoint na execução da função e executando as intruções passo-a-passo. É absurdo analisar a memória de um programa com ele em execução.

[ic]

É absurdo analisar a memória de um programa com ele em execução.

É absurdo porquê? As próprias instruções do determinado programa tão na memória, para não falar nas variáveis.

É claro que também podes usar um disassembler para analisá-lo sem executar o programa, mas se por exemplo o programa foi encriptado, torna-se mais fácil utilizar um debugger para encontrar o ponto onde começam as instruções principais do programa (depois de ter sido decriptado).

Inté

[WhoAmI]

Registei-me especificamente para responder a este topic,

para começar o code apresentado como apenas um user ate agora referiu apenas coloca a memoria a zeros depois de a mesma ser alocada poucas vantagens traz e nada tem a ver com proteger um exe evitar k se veja o source etc

O outro tema que se gerou apenas por confusoes relativas ao tema original é possivel ver o source caso o exe contenha debug information caso contrario apenas se ve o assembler claro que com muita paciencia pode-se compreender o code todo e recriar em qualquer linguagem de programacao exige muitos conhecimentos e paciencia, e isso só é perigoso em caso de ser o code de um algoritmo que se quer manter secreto.

cumprimentos