La instrumentación se realiza a través de un compilador JIT. Pin compila el código de la aplicación desde una ISA directamente a la misma sin pasar por una representación intermedia. Las unidades de traducción son trazas, por lo que se compila una traza cada vez, que consisten en una secuencia lineal de instrucciones que termina en: (1) una transferencia de control incondicional, (2) un número predefinido de transferencias de control condicionales, o (3) un número predefinido de instrucciones en una misma traza. El único código que se ejecuta es el generado por Pin, utilizando el original solamente como referencia, por lo que cada vez que el compilador JIT obtiene código, la Pintool (que es como se llaman las herramientas que utilizan Pin) tiene la oportunidad de instrumentarlo antes de ser traducido para su ejecución, guardando el código generado y el de instrumentación en una caché de código.

Todo el software necesario se puede descargar desde la web oficial. Una vez descomprimido, un buen punto de partida es echar un vistazo a los ejemplos disponibles en source/tools/ManualExamples entre los que se encuentra por ejemplo un contador de instrucciones: inscount0.cpp. Si nos fijamos en la función main, además de otras llamadas a funciones, la que más nos interesa en este caso es INS_AddInstrumentFunction, que recibe como parámetros un callback de instrumentación a llamar por cada instrucción y sus respectivos parámetros.

En la implementación de la función Instruction, a través de INS_InsertCall se añade una llamada a la función docount() que simplemente incrementa en 1 una variable global que almacena el número total de instrucciones.

El segundo parámetro de la llamada (IPOINT_BEFORE) resulta interesante puesto que nos permite especificar cuando insertar la llamada a docount(), siendo las alternativas IPOINT_AFTER y IPOINT_TAKEN_BRANCH, aunque en este caso IPOINT_BEFORE es la mejor opción porque solo estamos contando instrucciones. Este es el ejemplo más simple dentro de todos los que nos proporciona Intel, por lo que antes de empezar a desarrollar nuestra Pintool es recomendable examinar el resto de ejemplos.

The post Instrumentación dinámica de binarios appeared first on S3lab.

Por lo tanto, instrumentación se refiere a la técnica que consiste en añadir código extra a un programa, normalmente con el objetivo de recoger información sobre su comportamiento durante la ejecución y enviarla a rutinas de análisis que se encargan de manipular dicha información para llevar a cabo tareas que van desde profiling, detección de errores o debugging, hasta análisis de malware.

La instrumentación se puede llevar a cabo desde distintos niveles: directamente en el código fuente, en una representación intermedia como bytecode o LLVM IR, o a nivel de binario. Como curiosidad, en los últimos años se han desarrollado varias herramientas de detección de errores como MemorySanitizer que implementan una fase de instrumentación sobre la representación intermedia en tiempo de compilación.

Por otra parte, también es importante mencionar que la instrumentación puede ser estática o dinámica. En una situación en la que solo se dispone de un binario, se puede instrumentar de forma estática mediante binary rewriting como lo hacen herramientas como PEBIL, se puede hacer de forma dinámica sobrescribiendo instrucciones en memoria por trampolines que saltan al código de instrumentación, o siguiendo el concepto de Dynamic Binary Translation (de una ISA a la misma) como lo hace Intel Pin, por ejemplo. Cada uno de los métodos tiene sus ventajas e inconvenientes dependiendo de la tarea que se quiera llevar a cabo (analizar malware tiene requisitos de transparencia que algunas soluciones no pueden cumplir) y de lo recursos disponibles (no vamos a instrumentar el código fuente si no está disponible).

The post Opciones de instrumentación de programas appeared first on S3lab.

La idea principal detrás de la ejecución simbólica reside en ejecutar el programa objetivo de forma simbólica, es decir, los valores de entrada y las variables se representan como valores simbólicos en lugar de valores concretos. Estos valores se usan para generar condiciones de ruta, que son fórmulas lógicas que representan el estado del programa y las transformaciones entre estados del programa.

Para implementar la ejecución simbólica es necesario un dominio simbólico. Este dominio consiste en un estado simbólico que asigna variables a expresiones simbólicas y una condición de ruta (PC) para cada camino. Inicialmente, el estado simbólico es un mapa vacío y la ejecución simbólica solo mantiene una condición de ruta configurada como verdadero. La ejecución de sentencias condicionales actualizan la fórmula de condición de ruta, mientras que las asignaciones actualizan el estado simbólico. Cuando se alcanza un punto de bifurcación (producido por una sentencia condicional como un if), conceptualmente el intérprete bifurca guardando la condición de ruta sobre la rama que se ha seguido y la inversa como la condición de ruta para la rama que no se ha seguido.

Uno de los principales desafíos a los que se enfrenta la ejecución simbólica es la selección de ruta, puesto que cuando se encuentra una bifurcación debe elegir que camino seguir primero. Esta elección es importante porque los bucles con condiciones simbólicas pueden provocar árboles de profundidad infinita y puede que no terminen nunca. Por lo tanto, el manejo de bucles es un componente integral en la estrategia de selección de ruta. Existen varios enfoques, como por ejemplo:

• Rutas aleatorias: Seleccionar estados aleatoriamente recorriendo el árbol de estados desde el principio.
• Búsqueda en profundidad: Aplicar el algoritmo de búsqueda DFS  sobre el árbol de estados.
• Búsqueda en amplitud: Aplicar el algoritmo de búsqueda BFS sobre el árbol de estados.
• Heurísticas: Útiles para objetivos específicos, como por ejemplo calcular un peso para los estados en base a como de lejos está la instrucción más cercana descubierta y seleccionar estados en función de ese peso para maximizar la cobertura de código.

Las técnicas de ejecución simbólica tienen una escalabilidad limitada debido al problema conocido como path explosion: como se crean nuevas rutas en cada rama, el número de rutas en un programa aumenta exponencialmente con el número de sentencias condicionales en cada camino, lo que deriva en un número exponencial de fórmulas con un tamaño exponencial al número de ramas y un tiempo de ejecución exponencial al número de rutas en el programa. Para poder sobrevivir a este fenómeno se deben implementar distintas compensaciones.

Por otra parte, a diferencia del fuzzing, la ejecución simbólica tiene una visión semántica extremadamente alta, es decir, puede razonar sobre cómo desencadenar estados específicos del programa utilizando las condiciones de ruta acumuladas para producir una entrada adecuada a la aplicación cuando una de las rutas ejecutadas ha desencadenado una condición en la que el análisis está interesado.

The post La idea detrás de la ejecución simbólica appeared first on S3lab.