¿Cómo abrir un .exe?

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

Empezado por Caral

Ahora me pregunto?:
Si no se puede abrir un EXE creado en delphi, como es posible ver por ejemplo una clave oculta dentro de el.

Hola Carlos.
Bueno, nadie ha dicho que no se pueda "abrir" un EXE; Lo que hemos dicho es que no se puede extraer el código delphi de él, pero sí se pueden hacer otras muchas cosas...

Ya hemos comentador otra veces en estos foros que hay varios "decompiladores", que nos permiten extraer información como cadenas, iconos, formularios,... e incluso los procedimientos con el código máquina de cada uno de ellos.

Piensa que en un programa (que no esté encriptado), aunque las instrucciones sean en código máquina, hay muchas otras cosas que siguen estando como cadenas; Sin ir más lejos las llamadas a los procedimientos, los eventos,...

Empezado por Delphius

...como dijo Neftali el código no se puede saber y extraer pero si se podría llegar a saber el código máquina, las verdaderas instrucciones que se ejecutarán.

Pues básicamente así es como se hace. Se "ejecuta" el programa en cuestión y se revisa lo que va haciendo; A la vez que lo ejecutas "paso a paso" puedes estar viendo el estado de la pila, el estado de la memoria, las llamadas a procedimientos que se van haciendo...

En su día tuve que implementar un sistema de seguridad para un programa comercial y me "empapé" un poco de todo esto. La idea final, era poner a prueba el propio sistema que estaba desarrollando.
Por ejempo, mi primera prueba fue bastante "decepcionante" (para mi), pues después de haber implementado el sistema "complejo" de obtener el número de serie, probé a ejecutar el programa utilizando un Debugger (los programas que se utilizan para esto).

Mi sorpresa fue que bastaba grande cuando bastó con:

(1) Revisar los procedimientos del programa para haber que allí había un IsCorrectSerial() -que había hecho yo, por supuesto-
(2) Mandar ejecutar el programa hasta llegar a ese procedimiento.
(3) Cuando el programa pedía el "Serial" escribías uno incorrecto: 22222222
(4) Y llegasdos al procedimiento en cuestión donde el debugger se detenía, aparecía la comparación en memoria del número incorrecto 222222222 con mi número de serie correcto XXXXXXXX, que aparecía almacenado en memoria.

No me malentendáis, digo esto no para que todo el mundo se ponga ahora a crackear programas, sino porque considero que como programadores debemos tener unos mínimos conocimientos de este tema también, para evitar hacer tonterías como las que hice yo en mi primer intento.
Léase, dedicarle muchas horas a calcular un número de serie complejo y luego llamarle al procedimiento IsCorrectSerial().

Lo primero que extraje de estas pruebas fueros unos sencillos "truquillos" que uno debe utilizar si está desarrollando algo así:

* Prohibido llamar a a los procedimientos y rutinas con nombre explícitos; IsCorrectSerial pasó a llamarse OnClickButton3, y al igual con el resto de variables implicadas en el procedo de validación.

* No almacenar cadenas "importantes" tal cual; Basta con aplicarles un XOR para que no sean "legibles"; Por ejemplo, los mensajes de error de las validaciones, tipo "Serial incorrecto"; Estas cadenas son otro punto de partida para buscar por dónde acceder al lugar correcto.

* No almacenar los números de validación correctos, si es posible.

* Evitar comparaciones directas; Por ejemplo (sirva sólo como muestra para enterderlo), en lugar de hacer:
IF x = 18
se puede hacer
IF ((X /3)-2)=4

* Una vez que el código está terminado y testado, añadir a los procedimientos de validación unos cuantos "saltos basura"; Es decir, llamadas a procedimientos que no hacen nada. llamar a A(), desde A() llamar a B() y desde B() llamar a C() con alguna operación "innecesaria" dentro; Si a estas llamadas les pasas algun parámetro para almacenar en la pila mejor.

* Los Timers no se llevan bien con los debuggers ni las "esperas" tampoco; Si intercalas en los procedimientos de validación algun sleep() o wait() pequeño y por ahí en medio hay un Timer haciendo "tonterías" tampoco le va a gustar a quien esté debuggando tu programa. ;-)

* Puedes aplicar algun compresor/encriptador a tu pograma, pero salvo que sea de última generación, la mayoría de los conociodos cuentan con sus respectivos "inversos"; A veces sale más a cuenta utilizar uno poco conocido que algunos de los comerciales "muy buenos".

* A tener en cuenta que no siempre las "soluciones comerciales" son las mejores; Para algunas de estas, ya hay manuales y herramientas que ayudan en el proceso. En cambio una protección "manual", aunque sea más simple obliga a realizar todo el trabajo de "investigación" desde cero, y eso puede ser más o menos tiempo y puede eliminar a muchos "principiantes"

* ...

Así podríamos seguir con algunas más, pero tomando estas pocas medidas, aunque parezca mentira, el proceso se complica bastante.
Es un tema importante, porque a veces leo en los foros o la gente me pregunta cosas (en relación al componente THardDiskInfo) para realizar un sistema de protección muy fuerte o generar un número muy complejo. No todo está ahí, si luego caemos en errores tontos como el mío.

Empezado por Caral

¿como se puede ver un dato especifico dentro de un EXE,? saber cual es?, donde esta?.

Pues creo que esa ya está contestada.

Empezado por Caral

Casualmente el tema de mi duda en aquel entonces fue: ¿Que tan seguro es
un EXE?.

¿A qué te refieres con seguro? ¿Seguro para qué?