Cómo ocultar información para que no se vea en un ejecutable

[look]

No sera mejor indagar en temas de ofuscacion?, o sera algo asi como que exe tambien se va en debug y no release?

Saludos!

[mamcx]

En tal caso, la opcion mas recomendada es poner los datos en una ubicacion aparte y leerlo de forma dinamica. Puede ser un archivo que se le aplique los permisos adecuados, o usar mucho mejor el api:

https://msdn.microsoft.com/en-us/library/ms995355.aspx

Y esto en delphi:
https://stackoverflow.com/questions/...ord-in-windows

Esto entonces plantea como alimentar la primera vez esa info. La idea es que puedes por ejemplo pasarlo en un archivo, guardarlo de forma segura en el keylocker y borrar el archivo.

[Neftali [Germán.Estévez]]

Yo habitualmente para temas de password, los añado al código (no al DFM) con una encriptación sencilla o en algún fichero de configuración con técnica similar.
Y en tiempo de ejecución se asignan esos parámetros.

[pacopenin]

Una posible solución de efectos inmediatos podría ser cargar los valores que se desean ocultar llamando a funciones que devuelvan esos valores.

Hace tiempo nos piratearon un programa mediante un debugger. Generábamos la clave de registro y era almacenaba en una variable, luego la comparaba con la que tenía asignada la instalación del programa. Al asignarla a una variable, dicha clave se veía mediante el debuger. Cambiamos a devolverla mediante una función y ya no aparecía en toda la traza. Es algo sencillo y funciona.

[Neftali [Germán.Estévez]]

Empezado por pacopenin

Hace tiempo nos piratearon un programa mediante un debugger. Generábamos la clave de registro y era almacenaba en una variable, luego la comparaba con la que tenía asignada la instalación del programa. Al asignarla a una variable, dicha clave se veía mediante el debuger. Cambiamos a devolverla mediante una función y ya no aparecía en toda la traza. Es algo sencillo y funciona.

Si se entra en temas de debuggers (OllyDbg es el más utilizado) la cosa se complica y hay que entrar "en otro nivel".
Hay que tener en cuenta mensajes de error, mensajes al usuario, nombre que se definen en las funciones, nombres que se definen a las constantes/variables, y bastantes cosas más.
Normalmente lo primero que se hace es atacar al valor de una variable o constante (como comenta pacopenin), pero también al momento de la comparación. Es decir, que por muy complicada que sea la forma de almacenar la clave o de calcularla, al final lo normal es hacer un... "si este valor es igual a este" o "si son diferentes" dejo ejecutar o no (el registro es correcto o no).
Y a ese punto es al que se ataca. Modificando un JZ por un JNZ o JE por JNE, lo que se consigue es "negar" la comparación, por lo tanto, cualquier clave incorrecta pasa a devolver correcta (excepto la buena ).

Es un ejemplo, pero si alguien que sepa utilizar un debugger está pirateando nuestro programa, las técnicas y las estrategias para protegerlo o al menos para ponérselo más difícil son diferentes.

[Ñuño Martínez]

Siempre puedes usar una codificación por XOR, de forma que sólo funcionará con la clave correcta y con ninguna otra. Incluso aunque usen depuración les costará.

[[escafandra]]

Empezado por Ñuño Martínez

Siempre puedes usar una codificación por XOR, de forma que sólo funcionará con la clave correcta y con ninguna otra. Incluso aunque usen depuración les costará.

Ese truco he usado en numerosas ocasiones con éxito. Codifico las cadenas en una app externa y luego las pego en el código. Antes de usarlas las descifro. La rutina que he usado es tipo Xor, y por tanto simétrica con la misma clave.

Expongo un ejemplo de esa rutina en delphi, esta función se ejecuta en la app externa y en la aplicación que esconde cadenas u otro tipo de dato:

Código Delphi [-]
// Rutina de encriptación Xor.
// La misma rutina encripta y desencripta.
// Source: un puntero al buffer que contiene la fuente a encriptar.
// Size: Tamaño del buffer a encriptar
// Password: clave en modo texto que se tratará como de 8 caracteres, 64 bits
// _Mod: es el módulo restante para encriptaciones parciales
// Si se encripta un buffer por partes, Mod es Size_encriptado%8
// donde Size_encriptado es el tamaño total de lo encriptado hasta ese momento.
// Mod corrige el punto de comienzo del nuevo bloque a encriptar.

procedure Crypt(Source: Pointer; Size: Cardinal; Password: PCHAR; _Mod: integer);
var
  S: PCHAR;
  len, n: integer;
begin
   S:= Source;
   len:= lstrlen(Password);
   for n:=0 to Size-1 do
   begin
     S[n]:= CHAR(integer(S[n]) xor integer(Password[_Mod mod len]));
     inc(_Mod);
   end;
end;

Saludos.

[[escafandra]]

Empezado por Neftali

Si se entra en temas de debuggers (OllyDbg es el más utilizado) la cosa se complica y hay que entrar "en otro nivel".
Hay que tener en cuenta mensajes de error, mensajes al usuario, nombre que se definen en las funciones, nombres que se definen a las constantes/variables, y bastantes cosas más.
Normalmente lo primero que se hace es atacar al valor de una variable o constante (como comenta pacopenin), pero también al momento de la comparación. Es decir, que por muy complicada que sea la forma de almacenar la clave o de calcularla, al final lo normal es hacer un... "si este valor es igual a este" o "si son diferentes" dejo ejecutar o no (el registro es correcto o no).
Y a ese punto es al que se ataca. Modificando un JZ por un JNZ o JE por JNE, lo que se consigue es "negar" la comparación, por lo tanto, cualquier clave incorrecta pasa a devolver correcta (excepto la buena ).

Es un ejemplo, pero si alguien que sepa utilizar un debugger está pirateando nuestro programa, las técnicas y las estrategias para protegerlo o al menos para ponérselo más difícil son diferentes.

Es más eficaz sustituir el salto condicional relativo por dos instrucciones asm nop. Para evitar tan sencillo crack, la verificación debe estar en varios puntos distintos de código, nunca en una misma subrutina y aislarla de código cercano de mensajes de error. También es conveniente verificaciones por internet y en cada actualización. Pero ninguna protección es infalible, sólo dificultas y con suerte aburres.

Saludos.

[Reasen]

Haz que las condiciones vayan por llamadas dinámicas de tal manera que si no coinciden el programa no funcione, (esto es para reemplazar condiciones del mismo)
tambien añade un manejador de excepciones para evitar errores cuando la llamada sea incorrecta,
Luego para ofuscar las strings, si se trata de un password te recomiendo que uses MD5 para conocerlas por colisión.