Methodological position

Una captura de memoria no es más que una serie de bytes que, sin la información adecuada, sería imposible interpretar. Muchos de estos bytes no habrán sido utilizados y contendrán un valor aleatorio debido a las propiedades de la memoria volátil, mientras que otros corresponderán a estructuras del núcleo y de los procesos que se ejecutan en el sistema. La estructura de la memoria, desde el primer byte hasta el último, depende exclusivamente de cómo el núcleo la gestiona, controlando la memoria ocupada por cada proceso e implementando mecanismos como la memoria virtual, la caché o el mapeo de ficheros en memoria para mejorar el acceso a los mismos por parte de los diferentes procesos. En última instancia, el núcleo debe mantener una imagen clara de los contenidos de la memoria y saber qué datos existen en cada parte de la misma. Para ello, el núcleo mantiene un gran número de estructuras de datos que describen el mapa de memoria del sistema en cada momento. Cuando Volatility analiza una imagen de memoria para extraer de ella datos como los procesos que se encontraban en ejecución o los ficheros a los que estos tenían acceso a través de la caché, el procedimiento que se lleva a cabo es muy similar al que realiza el núcleo para llevar a cabo las tareas relacionadas con la gestión de la memoria del sistema. En esencia, Volatility recupera de la captura de memoria los valores de las estructuras de control del núcleo y las recorre para determinar qué se estaba ejecutando y dónde se encuentra cada uno de los datos útiles para el sistema en el momento en que la imagen fue adquirida.

El lugar que ocupan las estructuras de datos del núcleo es determinista, obviamente, pero cada núcleo (e incluso compilaciones diferentes del mismo núcleo) las sitúa en un lugar diferente.

Anexo A

178

Afortunadamente, el núcleo cuenta con un mapa de símbolos, que indica en qué posición se encuentran dentro de la memoria todas y cada una de las variables, llamadas al sistema y estructuras de control necesarias para el correcto funcionamiento del núcleo. La Figura 53 muestra un fragmento del fichero System.map que contiene el mapa de símbolos correspondiente al núcleo compilado anteriormente.

Figura 53. Fragmento del fichero System.map obtenido al compilar el núcleo

En el fragmento se observan las direcciones virtuales de diversas estructuras del núcleo relativas a la gestión de la memoria, incluida la del array mem_map, que contiene información sobre el contenido de todas las áreas de la memoria.

Además del fichero System.map, un perfil de Volatility contiene también información de símbolos de depuración en formato DWARF, obtenida al aplicar la herramienta dwarfdump sobre un módulo del núcleo creado específicamente para que simplemente haga referencia a aquellas estructuras de control que resultan relevantes para el análisis forense de las muestras de memoria. Por tanto, para crear el perfil es necesario compilar este módulo y obtener los símbolos de depuración del mismo. Volatility incluye tanto el código del módulo como un Makefile que ejecuta los comandos necesarios, pero es necesario editarlo en primer lugar para adaptarlo a las características del sistema para el que se crea el perfil. La Figura 54 muestra el aspecto del fichero Makefile utilizado para generar los símbolos de depuración del perfil utilizado en el entorno de demostración y validación.

Figura 54. Fichero Makefile para la obtención de símbolos de depuración

Todos los ficheros necesarios para crear el perfil se encuentran en el directorio tools/linux, en el directorio raíz de Volatility. Por tanto, los comandos necesarios para producir la información de depuración son los siguientes:

$ cd ~/volatility/tools/linux $ vim Makefile

Instalación y configuración de un entorno de adquisición y análisis de memoria física

179 Para obtener el perfil bastará con combinar el fichero System.map con el recién producido module.dwarf en un fichero ZIP:

$ zip Goldfish-3.4_vbox.zip ~/kernel_goldfish/System.map module.dwarf

Finalmente, para una mayor comodidad a la hora de trabajar, se copiará el perfil a la carpeta por defecto de la herramienta, de forma que no haya que especificar la ruta completa al mismo cuando desee utilizarse en el posterior proceso de análisis:

181

Anexo B

Procedimiento de evaluación en

entorno de validación

El entorno de demostración y validación implementa un REE y un TEE mediante la utilización de diferentes herramientas, tratando de asemejarse en la medida de lo posible a un dispositivo teórico cuyos recursos hardware son particionados de tal forma que sobre ellos conviven dos entornos de ejecución diferenciados y aislados, siendo este aislamiento asimétrico en tanto en cuanto se trata de evitar que un REE comprometido pueda acceder al TEE y suponer una amenaza pare el mismo, pero al mismo tiempo se proporciona acceso sin restricciones al TEE sobre el REE para que éste pueda ejercer un control total del mismo y aplicar las políticas más severas en caso de incumplimiento.

Este Anexo describe cómo las herramientas que conforman el entorno de demostración y validación descrito anteriormente pueden ser utilizadas para llevar a cabo el procedimiento de evaluación que propone este trabajo, detallando la forma en que cada una de estas herramientas puede ser utilizada para cubrir la funcionalidad requerida en cada una de las fases del procedimiento que, a modo de recordatorio, se indican aquí de nuevo mediante la Figura 55.

Anexo B

182

Figura 55. Fases sucesivas del proceso de evaluación

De la misma forma que el entorno de demostración y validación supone una particularización de los conceptos teóricos que caracterizan el dispositivo desde un punto de vista genérico, la utilización de las herramientas recogida en este Anexo es una particularización, hecha con fines demostrativos, de cómo puede implementarse el procedimiento de evaluación en el caso concreto de las tecnologías desplegadas en el entorno de demostración y validación. Por tanto, los detalles específicos sobre los que se fundamenta la demostración presentada corresponden a los propios del núcleo de Android, pero las indicaciones aquí recogidas son extrapolables a cualquier sistema, puesto que los conceptos de base son idénticos e independientes de los detalles concretos de implementación de éste.