Una de las maneras más rápidas de entrar en la investigación de vulnerabilidades, es a través de las pruebas de software. Las pruebas tradicionales de software de tipo caja negra, son interesantes desde la perspectiva de investigación de vulnerabilidades, porque no requieren una comprensión de los mecanismos internos del software. El único requerimiento para empezar a buscar por vulnerabilidades, es conocer cuales interfaces permiten la interacción con el software, y generar los datos pasados a través de estas interfaces.

Para auditar automáticamente un binario por potenciales vulnerabilidades, cualquier herramienta debe primero comprender el formato del archivo ejecutable utilizado por el binario, ser capaz de interpretar las instrucciones en lenguaje máquina contenidas dentro del binario, y finalmente determinar si el binario realiza algunas acciones probablemente explotables. Tales herramientas son mucho más especializadas comparadas con las herramientas para auditar el código fuente.

IDA es un desensamblador y depurador multi procesador para Windows, Linux o Mac OS X, el cual ofrece muchas características . IDA es un desensamblador interactivo, el cual permite a los usuarios tomar participación activa en el proceso de desensamblamiento. IDA no es un analizador automático de programas. IDA proporcionará sugerencias sobre instrucciones sospechosas, problemas no resueltos, etc. Es el trabajo del profesional informar a IDA como debe proceder. Todos los cambios hechos son guardados hacia el disco.

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.