¿Cómo abrir un .exe?

[[Caral]]

Hola
Por eso digo:
No se si se podrá ver el código, pero, ¿como se puede ver un dato especifico dentro de un EXE,? saber cual es?, donde esta?.
Te aseguro amigo, lo hicimos como un juego y uno de los maestros lo hizo en minutos.
De que se puede extraer información, verla y comprenderla, se puede, no me queda la menor duda.
Casualmente el tema de mi duda en aquel entonces fue: ¿Que tan seguro es un EXE?.
Saludos

[[Delphius]]

Hola nuevamente.

Yo no tengo las respuestas a esas preguntas... por ahora.
Y bueno, ese maestro sabe lo que hacía amigo... yo (no puedo hablar por los demás) sólo iba a ciegas esperando ver un rastro que nos ayudase.

La respuesta a tu última pregunta... cuán seguro... pues, para serte sincero no hay sistema que sea inviolable. Todos tienen una falla. A veces es fácil detectarla, a veces no... No hay sistema que sea 100% seguro, sin error, ni que no pueda ser violado.

El punto es que alguien con los medios, conocimiento, tiempo y la constancia e interés necesarios tarde o temprano lo derribará.
Podrán implementarse mecanismos que le hagan más difícil la tarea, pero eso no es garantía de que el sistema sea seguro.

Saludos,

[[Caral]]

Hola
Casualmente ese era mi punto en aquel experimento, ¿que tan seguro es? y la respuesta es la que acabas de dar:

Empezado por Delphius

.......
El punto es que alguien con los medios, conocimiento, tiempo y la constancia e interés necesarios tarde o temprano lo derribará.......

Entonces no se si se podrá ver el código o no, lo que si se es que se podrá sacar alguna información de el.
A esta pregunta:

Empezado por delphi

..... lo que necesito es visualizar el código, ya que hay varios parámetros que me interesan, ........

Yo digo: Si se puede, yo no se como, pero si se puede ver.
Saludos

[[Delphius]]

Yo más bien diría un puede a medias.
No cualquiera le puede sacar información. Aquí entra la diferencia entre dato e información... lo que podrá saber y recibirá delphi si examinara el exe en cuestión será datos. Más no información.

El dato pasará a ser información en el momento en que para alguien le es de valor, de utilidad. Para ello delphi deberá contar con una preparación y conocimientos da avanzada, y por lo visto... este no es el caso. Entonces podrá ver, más no entender... por tanto no le será útil... sólo una pérdida de tiempo.
Además, cualquier "información" que hubiera... estará dispersa... y deberá armarla. También existe la posibilidad que ese tipo de información que busca sea de la que no se puede extraer, ni armar.

Saludos,

[mcs]

Empezado por Caral

Hola
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.
Lo digo por que ya se ha hecho y debo decir que muy fácilmente por un Maestro de todos conocido.
Saludos

Esto puede ser relativamente fácil de hacer.

Si la clave no está encriptada, hay aplicaciones para buscar cadenas dentro de un fichero, sea este un ejecutable, una base de datos o un fichero de texto. Para Linux mismo hay una herramienta del sistema que se llama "strings", para Windows seguro que hay alguna versión.

Por otra parte, se puede usar un debugger externo. Buscar cuando se llama a una determinada función (si la función es en una DLL se sabe el nombre), esperar a que el ejecutable tenga los símbolos de depuración, etc. Hay mil y una formas de alterar u observar lo que hace un ejecutable.

Tened en cuenta que no hay NINGÚN sistema para evitar el pirateo del soft (a excepción de dejar parte del ejecutable en un servidor remoto y que algunas funciones se ejecuten remotamente), y si no hay ningún sistema es justamente porqué siempre puedes saber qué se está ejecutando en tu ordenador, poner un debugger (ya sea por soft o por hard), etc...

[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é?

[Ñuño Martínez]

¿Ven? Ya me lo han espantado. Si es que no se os puede dejar solos...

[Casimiro Notevi]

Bueno, iba a explicar básicamente lo que ha dicho Neftalí, tan sólo que él lo ha explicado muchísimo mejor de lo que habría dicho yo.
Resumiendo: el código fuente no se puede recuperar.
Aunque se puede extraer muchísima información, eso sí. He contado alguna vez que en un trabajo que tuve se decidió hacer un sistema de números de serie y claves bastante "seguro", se invirtió tiempo y dinero, y estuvimos mis compañeros y yo dedicado exclusivamente a ese tema durante 9 meses (fue un parto dificil ), incluso nos asignaron un presupuesto para equipos, utilidades, libros, contactamos con algunos expertos "crackeadores" de programas, y finalmente llegamos a la conclusión de que no valía la pena tanta inversión y esfuerzo, lo principal era despistar al posible intruso, marearlo dando vueltas de un lado a otro del programa, usar truquitos como los que ha comentado Neftalí y conseguir que sea tan aburrido, monótono, pesado, enrevesado, ... que el "cracker" se aburra y lo deje, simplemente por no perder más tiempo con el dichoso algoritmo.
Por cierto, el sistema de protección lo desactivó un ruso en apenas una semana y publicó un programita keygen que daba las claves igual que nuestro programa generador de claves.

[marcoszorrilla]

Para abrir un EXE necesitas cualquier programa desemsablador que hay muchos y te permite ver las instrucciones de código máquina.

Código PHP:

Mov Ah, 09
Int 21............... 


Etc.

También puedes ejecutarlo paso a paso, otra cosa es que se conozca ensamblador y por lo tanto se entienda o no lo que se vea.

Un Saludo.

[[Delphius]]

Vaya Neftali,
si que aportaste varios consejos a tener en cuenta.
Eso de las claves seguramente da para hablar un montón... recuerdo que en otra ocasión dabas consejos de como tratar y generar las claves. Básicamente tu idea se centraba en tratar y evaluar la clave por partes y no como un todo. Además de añadir un tanto de ofuscación de código tanto en la comprobación como en el paso de datos.

El ejemplo que comentas de la evaluación si bien es simple y es a modo de ejemplo, supongo que haces a referencia a la matemática entera porque en punto flotante puede haber ciertos problemas.

Lo que me llama la atención es que comentan que puede extraerse mucha información... no lo discuto que sea posible... pero el punto es que la información estará si el sujeto realmente la entiende. No es por ser malo ni tirar problemas pero dudo que quien inició el hilo tenga los conocimientos para extraerle la información, de saber no hubiera iniciado este hilo ¿no creen?. De nada sirven las herramientas si alguien no sabe utilizarla. Por tanto, en este caso hay que ser coherentes: no puede. No le será útil lo que verá porque no sabe lo que es y como utilizarlo. Al menos, no ahora.

Deberíamos decir que podrá extraer muchos datos, de allí a la información es un paso diferente.

Si yo decompilo... dudo que pueda sacarle demasiado información, alguna que otra cosa... quizá para otros y verdaderos maestros si sea válida dicha información.

A lo que yo apunto es que no se debería pretender que por tener las herramientas van a ser unos crackers o mal llamados hackers. Por favor... no "alienten" esa idea, que como he dicho... hay frases que cualquiera sacar de contexto e interpretarla a su gusto.

Para delphi el leer lo que comentan podría llevarlo a pensar algo como "¿En serio? Entonces podré ver lo que hay adentro" y que le resultará fácil.

Encuadremos en el debido contexto el término "muchísima información".

Saludos,

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

Empezado por Delphius

...recuerdo que en otra ocasión dabas consejos de como tratar y generar las claves. Básicamente tu idea se centraba en tratar y evaluar la clave por partes y no como un todo. Además de añadir un tanto de ofuscación de código tanto en la comprobación como en el paso de datos.

Sí a eso me refería (en parte) cuando comentaba esto:

Empezado por Neftali

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

Aunque tal vez no lo he especificado bien.
Se da por supuesto que en el programa no estará la lista de serials correctos (¡Ojo! que no es el primer programa que los lleva ), sinó más bien quería decir que si se puede evitar que, en algun momento esté el número completo almacenado en memoria, mejor.
Por ejemplo, si el número es 23FD-DF23, intentar no guardarlo todo en una variable, sino hacerlo en dos partes y utilizando dos variables separadas. Parecen (y son) cosas sencillas de hacer, que a posteriori añaden complicación a quien está revisando esas sentancias.

Empezado por Delphius

El ejemplo que comentas de la evaluación si bien es simple y es a modo de ejemplo, supongo que haces a referencia a la matemática entera porque en punto flotante puede haber ciertos problemas.

Correcto. Era más bien a modo de ejemplo, para que se entendiera el concepto. Se trata de no hacer un:

Código Delphi [-]
if SerialOK = SerialCalculado then

Porque eso se "salta" con cambiar un JZ por JNZ.

Empezado por Delphius

Lo que me llama la atención es que comentan que puede extraerse mucha información... no lo discuto que sea posible... pero el punto es que la información estará si el sujeto realmente la entiende...

De nada sirven las herramientas si alguien no sabe utilizarla.

A lo que yo apunto es que no se debería pretender que por tener las herramientas van a ser unos crackers o mal llamados hackers.

Por favor... no "alienten" esa idea, que como he dicho... hay frases que cualquiera sacar de contexto e interpretarla a su gusto.

Estoy de acuerdo en todo lo que dices Delphius. Que las cosas se puedan hacer no quiere decir que sean fáciles. Es más, si hace una sencilla prueba lo entenderá.

Por otro lado, no es mi intención alentar a nadie con mis palabras ni con mis comentarios a que se meta a "hacker", sabes que no.
Se pueden tener las herramientas, los conocimientos (en nuestro caso como programadores creo que los deberíamos tener) y no dedicarse a "crackear" programitas.

[[Caral]]

Hola
Creo que precisamente como programadores tenéis que tener el conocimiento de como se hace para que los que quieran Hackear vuestros programas les cueste por lo menos mas.
Por que de que lo intentaran lo intentaran, mas si en verdad les interesa.
Coincido con Neftali, no se trata de incentivar a los hacker, se trata mas bien de defenderse de ellos.
Sinceramente no creo que sea el caso del amigo delphi que genero este hilo ya que si supiera de programación sabría como hacerlo y que herramientas usar, para mi que es una inocente pregunta de un novato inquieto.
Saludos

[Casimiro Notevi]

Empezado por Delphius

[..] De nada sirven las herramientas si alguien no sabe utilizarla.[..]

Evidentemente, sonará a chino si no se tiene ni idea de ensamblador, pero sin "demasiados" esfuerzos es posible seguir la traza a cualquier programa aunque no se tenga el código fuente. Eso sí, es laborioso, lleva mucho tiempo y requiere conocimientos profundos.

[[Delphius]]

Empezado por Casimiro Notevi

Evidentemente, sonará a chino si no se tiene ni idea de ensamblador, pero sin "demasiados" esfuerzos es posible seguir la traza a cualquier programa aunque no se tenga el código fuente. Eso sí, es laborioso, lleva mucho tiempo y requiere conocimientos profundos.

En mi caso tu texto debería ser:

Empezado por Casimiro Notevi

Evidentemente, sonará a chino si no se tiene ni idea de ensamblador, pero con demasiados esfuerzos es posible seguir la traza a cualquier programa aun teniendo el código fuente. Eso sí, es laborioso, lleva tiempo y requiere de tirones de orejas.

Y allí obtienes el motivo y explicación de porqué y como logre pasar el reto delphi.

El ASM y yo no nos llevamos bien. No se hasta que punto es realmente necesario saberlo... después de todo mi cabeza trabaja en otro nivel y estoy cómodo en ese sentido.

Saludos,

[Casimiro Notevi]

ja, ja, ja... tienes razón, había olvidado ese reto

Empezado por Delphius

El ASM y yo no nos llevamos bien. No se hasta que punto es realmente necesario saberlo... después de todo mi cabeza trabaja en otro nivel y estoy cómodo en ese sentido.

Hubo una época en la que era bastante necesario conocerlo, hoy en día es casi innecesario, salvo para juegos y rutinas básicas para funciones de bibliotecas que interactuan a muy bajo nivel con el sistema.