Mientras la descompilación de un código compilado es una tarea extremadamente retadora, desensamblar el mismo código fuente no lo es. Para cualquier programa compilado se ejecute, este debe comunicar alguna información hacia el sistema operativo anfitrión. El sistema operativo necesitará conocer un punto de entada del programa (la primera instrucción la cual debe ser ejecutada cuando el programa sea iniciado); la disposición de memoria deseada del programa, incluyendo la ubicación del código y datos; y cuales librerías el programa necesitará acceder mientras se ejecuta.

La descompilación es quizá el santo grial de la auditoria binaria. Con una verdadera descompilación, la noción de un producto de fuente cerrada se desvanece, y la auditoría binaria revierte hacia el código fuente. Sin embargo, la verdadera descompilación es una tarea excepcionalmente difícil. Algunos lenguajes se prestan muy bien para la descompilación, mientras otros no. Los lenguajes ofreciendo mejor esta oportunidad, son por lo general lenguajes híbridos compilados / interpretados, como Java o Python.

Dos tipos de herramientas simplifican enormemente la tarea de realizar ingeniería inversa hacia una archivo, estos son los desensambladores y los descompiladores. El propósito de un desensamblador es generar lenguaje ensamblador desde un binario compilado, mientras el propósito de un descompilador es intentar generar código fuente desde un binario compilado. Cada tarea tiene sus propios desafíos, y ambos son de hecho difíciles, con la descompilación siendo la más difícil de las dos.

El análisis del código fuente no siempre es posible. Esto es particularmente cierto cuando se evalúan aplicaciones propietarias con código fuente cerrado. Esto de ninguna manera previene el profesional en ingeniería inversa examine la aplicación; simplemente hace el examen sea algo más difícil. La auditoría binaria requiere un conjunto de habilidades más amplio comparado con la auditoría del código fuente.

Si se tiene la fortuna de tener acceso hacia el código fuente de la aplicación, el trabajo para realizar ingeniería inversa a la aplicación será más fácil. Se seguirá un proceso laborioso y largo para entender exactamente como la aplicación realiza cada tarea, pero esto debería ser más fácil comparado con abordar el binario de la aplicación correspondiente. Existen una serie de herramientas las cuales intentan escanear el código fuente automáticamente, para detectar prácticas de programación deficientes. Estas herramientas pueden particularmente ser útiles para aplicaciones grandes.

Las vulnerabilidades existen en el software por un diverso número de razones. Algunas personas podrían decir, todas estas provienen de la incompetencia del programador. Aunque hay quienes nunca han visto un error en la compilación. En la actualidad las razones son mucho más variadas y pueden incluir:

• Falta de verificación para las condiciones de error
• Pobre comprensión sobre los comportamientos de las funciones
• Protocolos diseñados pobremente
• Inadecuadas pruebas para las condiciones de límites

Con todas las diversas técnicas ya conocidas sobre Hacking Ético y Pruebas de Penetración, la pregunta es ¿Porqué se querría recurrir a algo supuestamente tan tedioso como la ingeniería reversa?. Pues se debería estar interesado en la ingeniería inversa, si se requiere expandir las habilidades y conocimientos sobre evaluación de vulnerabilidades, más allá de únicamente utilizar las herramientas y trucos estándar. No hace falta tener muchas capacidades para ejecutar un escaner de vulnerabilidades y reportar sus resultados.

¿Dónde encaja la ingeniería inversa para el profesional en Hacking Ético y Pruebas de Penetración?. La ingeniería inversa es frecuentemente vista como el arte del “Cracker”, quien utiliza sus conocimientos y habilidades para eliminar la protección de copia desde un software o medio. Como resultado de esto, se podría dudar en emprender cualquier esfuerzo de ingeniería inversa. DMCA (Digital Millennium Copyright Act), se presenta frecuentemente cuando se discute la ingeniería inversa de software.

En los recientes años, los proveedores han adoptado algunos principios como parte de sus programas para recompensar el reporte de fallas. Microsoft por ejemplo, alguna vez mencionó el hecho de no demandar a los investigadores quienes envíen de manera responsable las potenciales vulnerabilidades de seguridad en los servicios en linea. Mozilla también tiene un programa para la recompensa de errores, por informes válidos o vulnerabilidades críticas. Google también ofrece recompensas en efectivo por las vulnerabilidades encontradas.

Aquellos quienes descubren vulnerabilidades usualmente están motivados para mejorar la protección de la industria. Esto realizado mediante la identificación y ayuda en la eliminación de software peligroso en los productos comerciales. Un poco de fama, admiración y derechos para jactarse son agradables también para aquellos con bastante ego. Los proveedores de otro lado, son motivados para mejorar sus productos, evitar problemas legales, no tener malas noticias en lo medios de comunicación, y mantener una imagen pública responsable.