Algún decompilador de archivos.exe?

[Shiro Naomi]

Hola
fue muy útil esta herramienta > https://foro.elhacker.net/ingenieria_inversa/innoextractor_novedosa_aplicacion_para_desempaquetar_instaladores_de_inno_setup-t390878.10.html <
Pero hay algún programa para extraer cualquier archivo de cualquier .exe?
Ya que los que he visto son para instaladores
Cuando abro un .exe con 7z me aparece esto



o esto



o esto



Digamos que en un .exe es un programa donde tiene imagenes, audio y dlls
Pero en vez de que se abra con los respectivos archivos del .exe
Solo me lo abre así



Algún super decompilador de archivos .exe?

[Geovane]

"Digamos que en un .exe es un programa donde tiene imagenes, audio y dlls
Pero en vez de que se abra con los respectivos archivos del .exe"

Sólo con el editor de Resources.


Decompiler, para .net.
No hay código fuente, pero ayuda en Delphi e VB.

Convertir linguagem C, programas de 32 bits, Retdec.

Saludos

[Serapis]

Cualquier desemsamblador es un decompilador...

Ahora bien si lo que requieres del decompilador es obtener el código fuente original, es imposible. Hay varias razones...
La primera un programa así, debería determinar en qué lenguaje fue escrito, a veces hay seguridad en las pistas otras no tanto y en otras ocasiones las pistas inducen a error, así que la primera complejidad versaría de hacer infalible esta parte.
La segunda... a la hora de compilar 3 temas importantes:
- A: Se traduce a código intermedio, antes d ela compilación final. En este caso, se pierde de nuevo el lenguaje de origen (por ejemplo en NET no se sabría si fue programado en Vb, en C#, etc... se podría sacar alguna dedución (en alguna ocasión) en base a ver alguna posibilidad que no se da en un determinado lenguaje y que por tanto lo excluye (por supuesto habría que determinar la exactitud de tal cosa, si no es así, no valdría de nada).
- B: El compilador finalmente realiza optimizaciones que lo alejan aún más del lenguaje en el que fue escrito. De alguna manera viene a decirse que incluso sería probable que las instrucciones en ensamblador resultante no estén disponibles en la forma del lenguaje de origen...
- C: A menudo algo se escribió en un lenguaje en un determinado equipo (pongamos C++ y windows) y el destino luego es otra plataforma distinta (se compiló por ejemplo para un Mac)... esto retuerce todavía más el asunto, porque podría darse que en dicha plataforma incluso no estuviera disponible el lenguaje original con el que se escribió, o sí y uno insistiese en traducrilo a un C++ existente en Mac 8por poner algo).
A ver, un ejemplo... supongamos que yo creo mi propio lenguaje y mi propio compilador... Ea.. genero 3 ejecutables de un programa X, uno para windows, otro para Mac y otro para Linux... quién podrá devolverlo al lenguaje de origen si ni siquiera 'mi lenguaje' es de dominio público?... entonces se hace preciso determinar a qué lenguaje decompilarlo?. Tendrá el lenguaje destino la estructuras y metodologías precisas para que su código fuente pueda ser resultante... esto es, quizás genere líneas que son error en el lenguaje destino, que no se permiten, etc... después de todo cada lenguaje tiene su  sintaxis de lo que permite y no. Tratar cada caso específicamente sería tortuoso (no imposible, por supuesto).

Se puede hacer algo, y es crear un programa que partiendo del desemsamblado de un ejecutable reescriba lo que hace en tal o cual lenguaje... Aquí un obstáculo puede ser aquello que se haya utilizado para ofuscarlo... Resulta complejo regresar a empaquetar en funciones, clases y otros módulos aquello que luego se ve 'desmenuzado', es como querer partiendo de los granos de arena disponer de nuevo de la roca de donde procede con la misma forma y tamaño. Así una operación a la derecha será complicada pero factible, a la izquierda puede ser inasumible. Otra dificultad es que es fácil confundir lo que hace con lo que se espera que se haga, en muchos casos un programa así debería 'interpretar' que prentedía hacer el autor original' y no tanto que es lo que se ve reflejado en el código', sin ello es fácil introducir errores que en origen no posee, en base a malinterpretar la especificación de lo que hace...

El mayor obstáculo es que hacer algo así, quién tiene beneficio por ello?. Ninguna empresa comercializaría un producto así, ya que de entrada estaría contra la propiedad intelectual y ya se sabe que una empresa si no va a obtener beneficios ni se mete en ello... no quita que no los haya, pero seguro que en empresas privadas y gobiernos,
Técnicamente sería si cabe más complicado que crear tu propio lenguaje y su compilador, ya que aunque ambos lenguajes ya existen (ensamblador y el lenguaje x de destino), estás traduciendo de un lenguaje de bajo nivel a uno de alto nivel... donde resultaría complicado definir direcciones de memoria en ciertas situaciones, si tal o cual lenguaje de alto nivel, en su sintaxis no admiten dicho trato de direcciones... siempre se podrá añadir código auxiliar (que no aparece en origen) para resolver tales temas, pero como afecta eso luego a la legibilidad del programa o bien en su alcance... ya que ese código auxiliar deberá queda ligado o no, posteriores procesos podrían quedar alterados, o no tener el acceso necesario por quedar ahí apartado...

En fin me parece interesante, pero entraña muchos problemas que llevan su tiempo decidir sobre cada uno de los aspectos que pudieran presentarse y cuando uno creyere tenerlos resultos siempre aparecerían más y más programas con más y más excepciones a considerar...

Ahora para algunos lenguajes interpretados, si que sería bastante asumible...

[Shiro Naomi]

Cualquier desemsamblador es un decompilador...

Ahora bien si lo que requieres del decompilador es obtener el código fuente original, es imposible. Hay varias razones...
La primera un programa así, debería determinar en qué lenguaje fue escrito, a veces hay seguridad en las pistas otras no tanto y en otras ocasiones las pistas inducen a error, así que la primera complejidad versaría de hacer infalible esta parte.
La segunda... a la hora de compilar 3 temas importantes:
- A: Se traduce a código intermedio, antes d ela compilación final. En este caso, se pierde de nuevo el lenguaje de origen (por ejemplo en NET no se sabría si fue programado en Vb, en C#, etc... se podría sacar alguna dedución (en alguna ocasión) en base a ver alguna posibilidad que no se da en un determinado lenguaje y que por tanto lo excluye (por supuesto habría que determinar la exactitud de tal cosa, si no es así, no valdría de nada).
- B: El compilador finalmente realiza optimizaciones que lo alejan aún más del lenguaje en el que fue escrito. De alguna manera viene a decirse que incluso sería probable que las instrucciones en ensamblador resultante no estén disponibles en la forma del lenguaje de origen...
- C: A menudo algo se escribió en un lenguaje en un determinado equipo (pongamos C++ y windows) y el destino luego es otra plataforma distinta (se compiló por ejemplo para un Mac)... esto retuerce todavía más el asunto, porque podría darse que en dicha plataforma incluso no estuviera disponible el lenguaje original con el que se escribió, o sí y uno insistiese en traducrilo a un C++ existente en Mac 8por poner algo).
A ver, un ejemplo... supongamos que yo creo mi propio lenguaje y mi propio compilador... Ea.. genero 3 ejecutables de un programa X, uno para windows, otro para Mac y otro para Linux... quién podrá devolverlo al lenguaje de origen si ni siquiera 'mi lenguaje' es de dominio público?... entonces se hace preciso determinar a qué lenguaje decompilarlo?. Tendrá el lenguaje destino la estructuras y metodologías precisas para que su código fuente pueda ser resultante... esto es, quizás genere líneas que son error en el lenguaje destino, que no se permiten, etc... después de todo cada lenguaje tiene su  sintaxis de lo que permite y no. Tratar cada caso específicamente sería tortuoso (no imposible, por supuesto).

Se puede hacer algo, y es crear un programa que partiendo del desemsamblado de un ejecutable reescriba lo que hace en tal o cual lenguaje... Aquí un obstáculo puede ser aquello que se haya utilizado para ofuscarlo... Resulta complejo regresar a empaquetar en funciones, clases y otros módulos aquello que luego se ve 'desmenuzado', es como querer partiendo de los granos de arena disponer de nuevo de la roca de donde procede con la misma forma y tamaño. Así una operación a la derecha será complicada pero factible, a la izquierda puede ser inasumible. Otra dificultad es que es fácil confundir lo que hace con lo que se espera que se haga, en muchos casos un programa así debería 'interpretar' que prentedía hacer el autor original' y no tanto que es lo que se ve reflejado en el código', sin ello es fácil introducir errores que en origen no posee, en base a malinterpretar la especificación de lo que hace...

El mayor obstáculo es que hacer algo así, quién tiene beneficio por ello?. Ninguna empresa comercializaría un producto así, ya que de entrada estaría contra la propiedad intelectual y ya se sabe que una empresa si no va a obtener beneficios ni se mete en ello... no quita que no los haya, pero seguro que en empresas privadas y gobiernos,
Técnicamente sería si cabe más complicado que crear tu propio lenguaje y su compilador, ya que aunque ambos lenguajes ya existen (ensamblador y el lenguaje x de destino), estás traduciendo de un lenguaje de bajo nivel a uno de alto nivel... donde resultaría complicado definir direcciones de memoria en ciertas situaciones, si tal o cual lenguaje de alto nivel, en su sintaxis no admiten dicho trato de direcciones... siempre se podrá añadir código auxiliar (que no aparece en origen) para resolver tales temas, pero como afecta eso luego a la legibilidad del programa o bien en su alcance... ya que ese código auxiliar deberá queda ligado o no, posteriores procesos podrían quedar alterados, o no tener el acceso necesario por quedar ahí apartado...

En fin me parece interesante, pero entraña muchos problemas que llevan su tiempo decidir sobre cada uno de los aspectos que pudieran presentarse y cuando uno creyere tenerlos resultos siempre aparecerían más y más programas con más y más excepciones a considerar...

Ahora para algunos lenguajes interpretados, si que sería bastante asumible...

Exelente testamento
Si lo leí todo
Pero no me interesa el lenguaje y/o el código fuente de x .exe
Solo quiero extraer los archivos de un .exe
Como texto, .mp3, imagenes, etc..
Algunos ejecutables al abrirlos con 7z muestra todos los archivos "sin ser ensamblados por algún comprimidor como Rar"
Pero en algunos .exe que me interesa entraer archivos me sale así:

[tincopasan]

Como texto, .mp3, imagenes, etc..
Algunos ejecutables al abrirlos con 7z muestra todos los archivos "sin ser ensamblados por algún comprimidor como Rar"

para hacerla corta, no existe!!! simplemente porque no todos los .exe tienen la misma arquitectura.

[Shiro Naomi]

para hacerla corta, no existe!!! simplemente porque no todos los .exe tienen la misma arquitectura.

Oh, que lastima
Bueno, gracias.

[bolota]

Hi maybe it help you http://angusj.com/resourcehacker/

[Shiro Naomi]

Hi maybe it help you http://angusj.com/resourcehacker/

Thanks, but that program is to see the source of a .exe, not to see the files.

[MCKSys Argentina]

Loa ejecutables que abres con 7zip y en los que puedes ver "archivos", son ejecutables autoextraibles. Dichos ejecutables los puedes crear con winzip, winrar, 7zip, etc.

Ahora, los ejecutables "comunes", en general, si incluyen archivos dentro de los mismos,lo hacen en la sección de recursos (por eso es que te recomiendan los editores de recursos).

Cuando abres estos ultimos con 7zip, lo que vez no son "archivos", son las secciones del binario (ya que 7zip parsea el header del exe).

Por lo tanto, la pregunta es: de que programa quieres extraer "archivos"? Se puede saber el nombre?

Saludos!

[Shiro Naomi]

Loa ejecutables que abres con 7zip y en los que puedes ver "archivos", son ejecutables autoextraibles. Dichos ejecutables los puedes crear con winzip, winrar, 7zip, etc.

Ahora, los ejecutables "comunes", en general, si incluyen archivos dentro de los mismos,lo hacen en la sección de recursos (por eso es que te recomiendan los editores de recursos).

Cuando abres estos ultimos con 7zip, lo que vez no son "archivos", son las secciones del binario (ya que 7zip parsea el header del exe).

Por lo tanto, la pregunta es: de que programa quieres extraer "archivos"? Se puede saber el nombre?

Saludos!

Un .exe como un crack que tiene un archivo de audio, o un .exe que tenga imagenes que quiero extraer, etc
Ya que si los abro con 7zip, "lo que vez no son "archivos, son las secciones del binario (ya que 7zip parsea el header del exe)."