¿Por qué no podemos entender el contenido de un archivo binario después de compilado?

Hasta donde sé, cada programa consiste en un paquete de instrucciones del procesador con algunas variables de datos específicas (float, int, char ...) para trabajar en los registros del procesador .

Entonces, lo primero que pensé al respecto (hace mucho tiempo) es que si sabes que el valor ASCII de %¨#$¨#(solo un ejemplo aleatorio) podría interpretarse como la dirección del registro del puntero de la pila (solo ejemplificando) de un x86 procesador. Si esto es cierto, cada vez que encuentre este valor "ilegible" al leer el contenido de un archivo binario, podría interpretar que el registro del puntero de la pila se está utilizando para administrar alguna variable de datos.

Lamentablemente esto no sucede. A continuación, hay un ejemplo del contenido del ping.exeprograma de Windows abierto con notepad.exe:

Es un archivo binario y sus datos son incomprensibles para nosotros los humanos (es comprensible para las máquinas). No tiene ningún sentido para nadie, incluso si conocen el código ensamblador (el nivel más bajo de lenguaje de máquina).

Entonces, si he entendido todo correctamente, ¿podría alguien explicarme?

1. ¿Por qué un código binario no puede volver al código de la Asamblea en la medida en que son, en el fondo, la misma cosa?
2. Si uno puede entender el código de ensamblaje, ¿por qué el binario compilado resultante de este código ya no es "legible"?

Primero, los registros no tienen direcciones. Cada instrucción en cualquier lenguaje ensamblador se traduce en un código de operación. Los códigos de operación en x86 pueden ser uno, dos, tres o incluso más bytes (en algunos otros procesadores son de "ancho fijo"). Por lo general, el código de operación identifica la instrucción, el modo de direccionamiento y los registros involucrados. El "modo de direccionamiento" determina si la CPU necesita más que el código de operación, es decir, el modo de direccionamiento "inmediato" significa que hay datos adicionales justo después (o "inmediatamente después") de la instrucción para esa instrucción - los modos de direccionamiento "absoluto" significa que un la dirección de memoria sigue las instrucciones y es utilizada por esa instrucción.

Puede encontrar el código de operación de algo similar MOV AL,SPo similar y luego buscarlo. x86 tiene muchas instrucciones que operan en el puntero de la pila.

Pero, por favor, deje de usar el Bloc de notas y use un editor hexadecimal. Recomendaría HxD, aunque hay muchos otros.

Y @David Schwartz es correcto. Un desensamblador iterará a través de un archivo y traducirá los códigos de operación nuevamente en texto legible. Lo que quieres hacer es totalmente posible.

Sin embargo, debe saber en qué parte del archivo comienzan las instrucciones porque si comienza en la dirección incorrecta, algunos datos que deberían ser los "operandos" de los códigos de operación (como las instrucciones que toman una dirección para un operando o "argumento") podrían ser malinterpretado como códigos de operación. Saber esto requiere conocer el formato en el que se encuentra el ejecutable, que es para Windows el "Ejecutable portátil" o el formato PE (y a menudo es ELF para sistemas Linux). Estoy seguro de que hay desensambladores que entienden la educación física, etc., pero no conozco ninguna casualidad.

Entonces, si he entendido todo correctamente

No exactamente.

Es un archivo binario y sus datos son incomprensibles para nosotros los humanos.

Por lo general, un archivo binario es incomprensible para humanos y máquinas, especialmente cuando se desconoce el propósito del archivo. Tenga en cuenta que no todos los archivos binarios son archivos ejecutables. Muchos archivos binarios son archivos de datos que no contienen instrucciones de la máquina. Es por eso que las extensiones de archivo se usan al nombrar archivos (en algunos sistemas operativos). Los . La extensión com fue utilizada por CP / M para denotar un archivo ejecutable. Los . MS-DOS agregó la extensión exe para indicar otro formato de archivo ejecutable. * nixes usa el atributo execute para denotar qué archivos se pueden ejecutar, aunque podría ser script y código.

Como ya mencionaron otros, los archivos binarios, que contienen números, deben ser vistos por un programa de volcado hexadecimal o un editor hexadecimal y no por un visor de texto.

hay un ejemplo del contenido del programa ping.exe

Ese archivo es en realidad un programa reubicable, y no todos los datos en ese archivo representan el código de la máquina. Hay información sobre el programa, como qué bibliotecas dinámicas necesita, qué rutinas deben vincularse, los requisitos para la pila y la memoria de programa y datos, y el punto de entrada del programa. Los operandos de dirección en el archivo pueden ser valores relativos que deben calcularse a valores absolutos o referencias que deben resolverse.

El "archivo de programa" en el que probablemente esté pensando se llama un archivo de imagen binario o un volcado de memoria de programa. Dicho archivo contendría solo código y datos de la máquina, con todas las referencias de dirección configuradas correctamente para la ejecución.

incluso si conocen el código de ensamblaje (el nivel más bajo de lenguaje de máquina).

El lenguaje ensamblador no es lo mismo que el lenguaje máquina . La CPU típica (como para excluir computadoras de lenguaje de alto nivel) acepta el código de máquina como entrada, una instrucción a la vez. Los operandos son registros o direcciones de memoria numérica. El lenguaje ensamblador es un lenguaje de nivel superior que puede usar etiquetas simbólicas para ubicaciones y variables de instrucciones, así como también para reemplazar los códigos de operación numéricos con mnemónicos. Un programa de lenguaje ensamblador tiene que convertirse a lenguaje / código de máquina antes de que pueda ejecutarse realmente (generalmente por utilidades llamadas ensamblador, enlazador y cargador).

La operación inversa, desensamblaje, se puede realizar en archivos de programa con cierto éxito y pérdida de información simbólica. El desmontaje de un archivo de volcado de memoria o imagen de programa es más prueba y error, ya que las ubicaciones de código y datos deben identificarse manualmente.

Por cierto, hay personas que pueden leer y codificar el código de máquina (numérico). Por supuesto, esto es mucho más fácil en una CPU o microcontrolador de 8 bits que en un procesador CISC de 32 bits con una docena de modos de dirección de memoria.

No puede ver la codificación adecuada e intencionada de un archivo binario a través del Bloc de notas. Por favor revise esto para referencia futura. La mayoría de los programas de edición de texto no analizan formatos de codificación binarios, y se espera que analicen el formato de código de caracteres ASCII.

Por lo tanto, abrir un archivo binario en un editor de texto producirá caracteres ASCII equivalentes que no tienen ningún sentido del formato original de los datos binarios analizados por el editor de texto. Como se mencionó, los editores hexadecimales, y algunos tienen características binarias, para ver el contenido en formato binario puro.

Es incorrecto que el contenido de un archivo binario no se pueda entender. Si bien serán difíciles, y en las arquitecturas informáticas modernas, es extremadamente difícil desmontar a mano de binario solo en instrucciones adecuadas reconocidas por la CPU para la ejecución (o CPU emulada / virtual), etc., se puede hacer.

¿Cómo crees que están programados los emuladores? El desarrollador necesitaría conocer códigos de operación para poder programar el sistema ficticio para reconocer y comportarse como lo haría el hardware real de alguna manera. Las documentaciones explican muchas arquitecturas de CPU, e incluso las GPU las tienen (aunque más reservadas).

Otra cosa a tener en cuenta es que en el nivel más bajo, aunque correlativo, los "datos binarios" no son realmente un montón de ceros y unos, sino voltajes altos y bajos amplificados / conmutados a través de un circuito eléctrico como corriente.

Binario generalmente es 1: 1 con esto, por lo que tiene mucho sentido usar el sistema numérico para ello.