10 comandos ADB Shell a conocer...

Una de las muchas razones por la que una gran cantidad de usuarios elegimos Android es por la facilidad de uso y las muchas cosas que podemos hacer cuando conectamos nuestro dispositivo al ordenador. Muchas veces, al actualizar el teléfono o tablet a una nueva versión, ponerle una ROM cocinada o conseguir permisos de superusuario (root), necesitamos tener más contacto con el aparato que el que nos da el programa que usemos en ese instante (Odín en los Samsung, por ejemplo). El ADB (Android Debug Bridge) es un programa para ordenador que nos servirá de puente para conectar nuestros androides a la computadora y poder así interaccionar con ellos de una forma más “avanzada” y completa. Vamos a ver cómo se hace y algunos comandos básicos.

Para los usuarios de Linux o Mac, necesitarán instalar el SDK de Android tal y como se explica en el sitio web oficial. No es difícil si se siguen las pautas señaladas.

Para los que usan Windows es tan sencillo como descargar este archivo, abrir el zip y descomprimir en algún lugar la carpeta “android-tools“. Si no tenemos los drivers de nuestro teléfono instalado, deberemos buscarlos e instalarlos. Luego de instalar el archivo ADB.exe, podemos continuar.

Es importante tener la “Depuración USB” activada en nuestro androide para que todo funcione perfectamente

1. Comando adb device

Este comando es el más importante de todos, ya que es el que nos dirá si nuestro dispositivo Android se comunica bien con el equipo. Después de tener todos los archivos en la misma carpeta (la que sacamos antes del zip), simplemente debemos arrancar la consola de terminal (ADB) y escribir “adb devices” (sin las comillas). Si nos sale un número de serie, es que todo está correcto. Si por el contrario, no sale nada, tendremos que asegurarnos de que lo tenemos todo bien (drivers, depuración USB…).

2. Comando adb push

Con adb push moveremos un archivo directamente de nuestro ordenador a nuestro dispositivo Android.  Este comando viene bien cuando queremos mover archivos a directorios del sistema o cuando no tenemos ganas de hacer un drag & drop y queremos practicar un poco de uso de consola. Para mover un archivo es necesario conocer la ruta del teléfono en la que lo queremos depositar. Si, por ejemplo, queremos mover un archivo de vídeo cualquiera, deberemos colocar éste en la carpeta android-tools que hablábamos antes. Luego, escribiremos en la consola: adb push superfreak.mp4 /sdcard/Movies/; y ya estará en nuestro terminal en la carpeta movies.

3. Comando adb pull

Todo lo contrario a lo anterior. Si queremos coger un archivo de nuestro androide y llevarlo al ordenador, simplemente deberemos utilizar el comando “adb pull“. Es casi lo mismo que hicimos antes. Si queremos extraer el archivo del teléfono, por ejemplo, el que pasamos en el ejemplo anterior, la cosa sería tal que: adb pull superfreak.mp4 /sdcard/Movies/; y el archivo irá a parar de sdcard/Movies/ a nuestra carpeta tools en el ordenador. Si queremos moverlo a un directorio en particular escribiremos, después del comando adb pull y el directorio de recogida, la ruta en nuestro ordenador a la que deseamos mover el archivo: C:\Users\Aitor\Desktop; para moverlo al escritorio, por ejemplo.

4. Comando adb reboot

Hace simplemente lo que dice. Reinicia el dispositivo mediante la consola. Es una manera sencilla de reiniciar el teléfono si lo necesitamos en algún momento cuando estemos usando ADB. Sólo hay que escribir “adb reboot” y ya está. Reiniciando…

5. Comandos adb reboot-bootloader y reboot recovery

No sólo podemos reiniciar el dispositivo, sino también acceder al bootloader. Esta es una de las herramientas más ventajosas de este modo, a veces las combinaciones de botones se vuelven tediosas y queremos hacer las cosas de una manera más sencilla. Acceder al bootloader nos puede servir para muchas cosas (root, cambiar ROM…). Únicamente deberemos teclear “adb reboot-bootloader” y ya estaremos dentro.

En el caso del “reboot recovery” nos servirá para entrar en modo recovery. Muchas ROMs traen por defecto un cuadro de diálogo que nos posibilita el reiniciar en este modo, pero siempre viene bien tener una manera más de acceder en la recámara.

6. Comando fastboot devices

Cuando estamos en el bootloader, los comandos de ADB ya no funcionan. Esto es porque no estamos aún en Android, el sistema operativo del teléfono no ha arrancado del todo aún. En este caso, usamos el comando fastboot.

Puede que este sea uno de los comandos más potentes de los que hay disponibles. Hay que tener en cuenta que muchos dispositivos no lo tienen habilitado y si así, necesitaremos estar seguros de que ambos equipos se están comunicando (PC y Android). Si queremos saber si disponemos de fastboot, únicamente deberemos escribir “fastboot devices” y debería salirnos un número de serie (al igual que en adb devices).

Si el comando no funciona y estamos en Windows, tocará revisar los drivers y recorrer los foros especializados en busca de ayuda.

7. Comando fastboot oem unlock

El santo grial de los comandos de ADB para Android. Éste hace una cosa y sólo una, desbloquea los Nexus (o HTC mediante su herramienta oficial). Si tenemos un teléfono de un fabricante distinto, tendremos un método distinto en cada caso (Odín para Samsung, por ejemplo). En este último caso, este comando no nos sirve de nada. Se incluye aquí porque, aún sin necesitarlo, es una parte importante del sistema de código abierto de Android.

A Google le da lo mismo lo que hagamos con nuestros dispositivos, y nos provee de esta herramienta para desbloquear el teléfono. Esto es algo que en otras compañías no se ve, y es una de las razones por las que muchos eligen Android.

Usarlo es sencillo. Una vez habiendo usado el fastboot para saber que todo está bien comunicado, sólo debemos escribir “fastboot oem unlock“ y darle a intro. Luego toca mirar el terminal, leer cuidadosamente y elegir las opciones sabiamente.

¡¡Cuidado!!: Utilizando “fastboot oem unlock”, se borrará todo el contenido del dispositivo

8. Comando adb shell

El comando adb shell es uno de los que más confusiones crea. Hay dos maneras de usarlo: uno donde se envía un comando al dispositivo para ejecutar en su propio shell la línea de comandos, y otra donde estaremos verdaderamente dentro del shell de comandos desde el terminal. En la imagen de arriba, el usuario está dentro del shell del dispositivo, viendo los archivos y las carpetas. Llegar ahí es muy fácil, sólo tienes que escribir “adb shell“. Una vez dentro, podemos ser root si lo creemos necesario. A menos que estemos familiarizados con la ejecución de acciones por comandos, no deberemos tocar nada. Es necesario tener mucho cuidado en este nivel. Las cosas pueden volverse difíciles si no se tiene cuidado.

Normalmente se usa para tareas más avanzadas como cambiar los permisos de los archivos o carpetas, o ejecutar una secuencia de comandos. Simplemente hay que escribir “adb shell <comando>“. Un ejemplo sería cambiar los permisos de un archivo, así: “adb shell chmod 666 / data / archivo“. Mucho cuidado al usar este método.

9. Comando adb install

Este es un comando sencillo. Nos servirá para instalar aplicaciones en nuestro androide. Y al igual que los comandos pull y push, deberemos especificar la ruta en la que queremos posicionar el archivo a instalar. Un ejemplo sería mover un apk a la carpeta android-tools y luego poner en la consola “adb install Aplicacion.apk“. También podemos usar un comando para actualizar una aplicación específica. Esto se consigue añadiendo el sufijo “-r“ a la sentencia anterior. Por lo que quedaría: “adb install -r Aplicacion.apk“.

Y tal como instalamos, también podemos desinstalar. Hay un comando que nos sirve para desinstalar aplicaciones, este sería: “adb uninstall Aplicacion.apk“. Si añadimos un sufijo “-k” nos dejará los datos de la aplicación y caché en la memoria.

10. Comando adb logcat

El comando adb logcat es uno de los más útiles para algunos usuarios. Sobre todo si son cocineros o desarrolladores de aplicaciones. Cuando lo escribimos, nos devuelve una ingente cantidad de eventos escritos en diversos registros sobre el funcionamiento del sistema. Proporciona información muy valiosa para el desarrollador, ya que de aquí puede deducir qué fallo tiene su aplicación.

Para ver el registro en la pantalla del ordenador, sólo tienes que escribir “Logcat adb“ y pulsar enter. Puede que todo vaya bastante rápido y es posible que no encontremos lo que andamos buscando. Hay dos maneras de solucionar esto: los filtros y la salida de texto.

El filtro se usa cuando un desarrollador puso una etiqueta en un sitio del programa y quiere ver qué pasa justo ahí. Si es necesario, el creador nos dará la sentencia necesaria a poner en la consola. Por el contrario, la salida de texto es más fácil. Nos dará toda la información del logcat, contenido en un archivo de texto (.txt). Para ejecutarlo, sólo deberemos poner “adb Logcat> archivo.txt” y dejar que todo fluya como el viento entre los campos de maíz. Al terminar, cerraremos con CTRL+C. Encontraremos el archivo de registro completo guardado en el directorio en el que estemos trabajando (posiblemente android-tools). Ese archivo es el que debemos enviar al desarrollador.

Es importante tener en cuenta que el informe puede llevar información confidencial. Deberemos asegurarnos de borrar todo lo que no queramos que el desarrollador sepa sobre nosotros, abriendo el editor de texto (bloc de notas) y borrando lo que creamos oportuno.

Fuente: http://blog.underc0de.org/

Leer más...

Requisitos para ser perito en Argentina.

La doctrina señala tres requisitos que debe reunir un perito para actuar:

- Capacidad: es el conjunto de condiciones subjetivas que le confieren aptitud para intervenir en un número indeterminado de procesos.  Existe capacidad cuando se cumplimentan personalidad física y habilidad testifical subjetiva.

La índole esencial de la función del perito consiste en una transmisión de conocimiento, por eso sólo pueden desempeñarse como perito las personas físicas.

Si bien es cierto que en el curso del proceso pueden efectuarse consultas a determinadas personas jurídicas (academias o universidades) sus informes carecen del valor jurídico de dictamen pericial (pruebas informativas).

Respecto de la habilidad subjetiva, no podrán actuar como peritos quienes carezcan de aptitud física moral o mental para decir la verdad:

Menores de 18 años.

Procesados por algún delito.

Condenados por falso testimonio.

Los que no tengan habilidad conocida.

Los que tengan impedimentos para expresar sus ideas de palabra o por escrito.

- Legitimidad: implica la existencia de tres condiciones:

a) Competencia técnica: se prueba con el título universitario habilitante.  Se cumple cuando la especialidad del perito coincide con el conocimiento  que es necesario incorporar al proceso.

b) Impersonalidad procesal: implica que el perito tiene que ser una persona distinta de los sujetos procesales.  No pueden ser peritos: el juez, las partes, el fiscal.

c) Habilidad objetiva: el perito debe actuar con independencia de criterio.

No pueden ser peritos, en relación con el objeto procesal, las personas que se hallen en las siguientes condiciones:

Parentesco o tutela.

Secreto profesional

Demás relaciones objetivas.               

                                                                          

- Constitución: es el reconocimiento de la capacidad que lo coloque al perito en condiciones de realizar validamente todos los actos procesales correspondientes al rol asignado.  En el caso de los peritos oficiales, por ser funcionarios de la justicia, basta con la designación.  En cambio, en el caso de los peritos de oficio y de parte además de la designación es necesaria la aceptación del cargo.

Fuente: Auxiliaresdlajusticia.net

Leer más...

Backdoors en iOS

A continuación pego un link sobre los distintos servicios "no declarados" en iOS, los cuales son utilizados por muchos programas de forense bastante costosos.

https://pentest.com/ios_backdoors_attack_points_surveillance_mechanisms.pdf

Leer más...

Sitio Legal - Forense USA

Sitio de referencia con temas legales USA.

http://oregonlawpracticemanagement.com/

Leer más...

VMware ESXi, máquinas virtuales y obtención de evidencias virtualizadas

Interesante artículo:

Debido al auge de la virtualización es altamente probable que tarde o temprano una investigación forense tenga como sujeto objeto de análisis un sistema virtualizado. Y dado que actualmenteVMware se lleva la palma en cuanto a implantación en el mercado empresarial es más que posible que el sistema virtualizado se ejecute sobre un hipervisor de dicha compañía. Pues bién, lo que viene a continuación son mis experiencias ante una situación hipotética como la que planteo: la adquisición de evidencias procedentes de máquinas virtuales ejecutándose en servidores ESXi. A lo largo de las siguientes líneas desarrollaré la configuración del escenario y todas las pruebas/aciertos/errores por los que he pasado hasta que, a mi juicio como lego en la materia, he dado con una metodología personal que considero bastante aceptable.

Sobra decir que no me hago responsable de los problemas que pueda ocasionar aceptar todo lo que detallo sin probar siquiera antes en un laboratorio las características concretas de cada escenario. Nótese, por otra parte, que el artículo no contempla la utilización de mapeo de discos físicos para ser utilizados por las máquinas virtuales como espacio de almacenamiento. Una vez establecida mi exención de responsabilidades y antes de continuar, al cesar lo que es del cesar, y por ello incluyo aquí las dos principales fuentes que he utilizado como referencia:

Ghost in the Machine - Forensic Evidence Collection in the Virtual Environment
How To - Digital Forensics Copying A VMware VMDK

Puedes simplemente leerlas y descartar el resto del artículo, o seguir leyendo y entretenerte tanto como me he divertido yo con la preparación del mismo, además de encontrar algunas alternativas que no se incluyen en ninguno de los enlaces anteriores y que creo pueden facilitarnos mucho la vida. Voy a intentar describir paso a paso todo el proceso, aunque en ocasiones esta descripción no sea muy exhaustiva; no obstante si tienes alguna duda y te interesa reproducirlo no tienes más que indicármelo y trataré de echarte una mano. Ahora, sin más preámbulos, vamos al lío :-)

VMware vSphere

Seguro que todos conocemos y/o hemos utilizado en alguna ocasión los hipervisores de nivel 2 o de "andar por casa". Estos no son más, ni tampoco menos, que aplicaciones que se ejecutan sobre el sistema operativo permitiendo correr diferentes maquinas virtuales. Algunos ejemplos: VMware Player, VMware Workstation, Oracle VM VirtualBox, qemu, etc.

Luego están los hipervisores "más serios", los de nivel 1, que son aquellos que se ejecutan directamente "sobre el metal", compuesto por el hardware del equipo, y que ofrecen mayores prestaciones como para ser tenidos en cuenta en entornos empresariales. El buque insignia de VMware es vSphere, cuyo hipervisor en versión free es totalmente funcional, solo que no ofrece muchas de las características más avanzadas. Pues bién, esta última es la versión que he utilizado para las pruebas, montado sobre un equipo con una única tarjeta de red debido a las restricciones en cuanto a compatibilidad de hardware de la criatura.

Una vez instalado ESXi 5.1.0 (vídeo detallado del proceso), configurados los parámetros de red (dirección IP estática 192.168.1.3) e introducida la licencia gratuita con la correspondiente merma de características respecto de la versión trial viene la configuración básica, entendiendo por tal: 

1. Instalación del cliente vSphere en el equipo del analista (o sea, mi equipo).
2. Configuración de la sincronización horaria en el ESXi mediante el cliente vSphere (detalle del proceso).
3. Habilitar el acceso remoto mediante SSH (detalle del proceso).

Ahora llegaría el momento de instalar la máquina virtual (en mi caso un Windows XP SP3) que supuestamente habría sido comprometida y por tanto sería objeto de análisis. No detallaré el proceso, tampoco he encontrado ningún enlace adecuado, pero básicamente bastaría con seleccionar el servidor ESXi en el cliente vSphere y seguir el asistente iniciado mediante la opción "Create a new virtual machine". 

Congelando el estado del sistema 

Una vez preparado el entorno de pruebas llega el momento de obtener las evidencias del sistema comprometido. El escenario más simple sería como el de mi laboratorio, donde sólo tenemos una máquina virtual ejecutándose sobre un servidor ESXi con un storage local. Pero desde luego ésto dista mucho de la realidad, donde lo normal sería encontrarnos decenas e incluso cientos de sistemas ejecutándose sobre el mismo hipervisor o un cluster de hipervisores con un almacenamiento gigantesco en una o varias SANs y con unas necesidades de alta disponibilidad críticas. ¿Qué hacer en estos casos? 

Si nos olvidamos de que se trata de máquinas virtuales sabemos que tendremos que obtener al menos una copia del disco duro y otra de la memoria RAM del sistema comprometido, y para incidir lo menos posible en la ejecución del sistema objetivo y recordando nuevamente que se trata de máquinas virtuales, tenemos la opción de generar un snapshot. Un snapshot es básicamente una imagen estática del sistema objetivo en el momento de su generación. Ésto implica que el fichero que compone el disco duro del sistema virtual deja de recibir modificaciones, las cuales a partir de ese momento comenzarán a almacenarse en un fichero delta, permititiendo de esa forma en cualquier momento posterior revertir el estado del sistema al momento del snapshot. Nótese que el contenido de la memoria RAM también se congela, generándose un nuevo fichero inmutable mediante un dump de la misma para contener su estado. Más información sobre snapshots: 

Understanding virtual machine snapshots in VMware ESXi and ESX 
VMware Knowledge Base 1009402: Working with snapshots 
How VMware snapshots work 

Habitualmente antes de lanzar un snapshot tendríamos el fichero asociado al disco virtual nombremaquina-flat.vmdk con sus características definidas en nombremaquina.vmdk, siendo este último un fichero de texto. El nombre y ubicación del fichero correspondiente al disco se incluirían en el fichero de configuración de la máquina virtual. Para confirmar esta afirmación y desde una shell en el servidor ESXi obtenida mediante SSH primero obtendremos la ubicación de las máquinas virtuales:

# esxcfg-info -s | grep -i "volume name"

       |----Volume Name...........................................datastore1

Otro comando para obtener el nombre del datastore bajo el cual se ejecutaría cada máquina virtual: 

# vim-cmd vmsvc/getallvms

Ahora que conocemos la ubicación ya podemos consultar los ficheros de configuración: 

# grep -i "filename.*vmdk" "/vmfs/volumes/datastore1/Windows XP/Windows XP.vmx"

ide0:0.fileName = "Windows XP.vmdk"

# grep "vmdk" "/vmfs/volumes/datastore1/Windows XP/Windows XP.vmdk"

RW 41943040 VMFS "Windows XP-flat.vmdk"

Una vez lanzado un snapshot seguiríamos teniendo los dos anteriores. Además, y para evitar su modificación, se crearán dos nuevos ficheros: nombremaquina-000001-delta.vmdk como nuevo disco virtual para almacenar los cambios desde el snapshot y nombremaquina-000001.vmdk, y se modificará el fichero de configuración de la máquina virtual para reflejar la nueva situación: 

# grep -i "fileName.*vmdk" "/vmfs/volumes/datastore1/Windows XP/Windows XP.vmx"

ide0:0.fileName = "Windows XP-000001.vmdk"

# grep "vmdk" "/vmfs/volumes/datastore1/Windows XP/Windows XP-000001.vmdk"

parentFileNameHint="Windows XP.vmdk"

RW 41943040 VMFSSPARSE "Windows XP-000001-delta.vmdk"

Por último, y en cuanto a lo que nos atañe, también se volcará el espacio de direcciones de la memoria RAM asignado a la máquina virtual en el fichero nombremaquina-Snapshot1.vmsn 

Así que como primer paso tendríamos que generar un snapshot y la forma más fácil de hacerlo es a través del cliente vSphere seleccionando la máquina virtual adecuada y pulsando el botón derecho del ratón Snapshot, Take snapshot. Es importante recalcar que para seguir el proceso desarrollado en este artículo es imprescindible no disponer previamente de ningún snapshot; en el caso de existir uno o varios tendríamos que eliminarlos o consolidarlos. 

Como queremos incidir lo menos posible en el estado del sistema para obtener una evidencia lo más fidedigna posible deberemos asegurarnos de dejar las opciones por defecto, además de lanzarlo en un momento en que no haya mucha carga sobre la máquina virtual. 

ESXi y los tipos de discos virtuales 

Llega el momento de obtener una copia de las evidencias previamente generadas mediante el snapshot, pero antes nos detendremos en el concepto de discos thin y thick provisioned. 

Cuando generamos una máquina virtual en un servidor ESXi tenemos la posibilidad de elegir entre discos thin o thick. La diferencia entre ambos es que el primero se crea sólo con el tamaño inicial estrictamente necesario y va creciendo conforme se van almacenando datos en él hasta alcanzar, como máximo, el espacio establecido al crearlo. Esta característica permite sobreutilizar el espacio de almacenamiento disponible en lugar de tener que reservarlo de antemano y constituye una de las principales ventajas de trabajar con máquinas virtuales. Cuando se hace una petición de lectura para un bloque no utilizado el sistema de ficheros VMFS se encarga de devolver ceros. 

Por el contrario los discos thick precisan disponer del total del espacio cuando son creados, de forma que éste queda reservado. A su vez dentro de los discos thick tenemos dos subtipos más: 

• LazyZeroedThick: este es el tipo por defecto y, a pesar de precisar del espacio total disponible en el dispositivo de almacenamiento dicho espacio no queda ocupado hasta que no resulta necesario.


• EagerZeroedThick: en este tipo de discos el espacio total queda reservado y sobreescrito con ceros, de forma que el proceso de creación es más lento pero la velocidad de escritura de datos es mayor.

Nótese que el disco virtual siempre se creará como EagerZeroedThick independientemente de las opciones especificadas durante su creación si no se elige el formateo rápido del sistema de ficheros durante el particionado del disco al instalar una máquina virtual con un sistema operativo Microsoft. 

Using thin provisioned disks with virtual machines 
Thin Provisioning – What’s the scoop? 

El disco de la máquina virtual generado para el ejemplo es thin provisioned. Nótese la diferencia entre el resultado de la ejecución de los siguientes comandos: 

# ls -l "Windows XP-flat.vmdk"

-rw-------    1 root     root     21474836480 Nov  8 11:21 Windows XP-flat.vmdk




# du "Windows XP-flat.vmdk"

1873920 Windows XP-flat.vmdk

Y para los servidores ESXi disponemos del comando stat: 

# stat "Windows XP-flat.vmdk"

  File: Windows XP-flat.vmdk

  Size: 21474836480     Blocks: 3747840    IO Block: 131072 regular file

Device: f7b4079747314280h/17848899569491985024d Inode: 16796484    Links: 1

Access: (0600/-rw-------)  Uid: (    0/    root)   Gid: (    0/    root)

Access: 2012-11-08 11:13:25.000000000

Modify: 2012-11-08 11:21:15.000000000

Change: 2012-11-08 11:07:43.000000000

El campo size nos indica el tamaño máximo del disco en bytes; el campo blocks nos indica el número de bloques utilizados hasta el momento. De esta forma, y suponiendo que habitualmente el tamaño de bloque es igual a 512 habríamos ocupado 3747840 * 512 = 1918894080 bytes de los 21474836480 disponibles: 

# echo "Max: $((`stat -c "%s"  "Windows XP-flat.vmdk"` / 1024))K \

 - Size: $((`stat -c "%b * %B" "Windows XP-flat.vmdk"` / 1024))K"

Max: 20971520K - Size: 1873920K

Esta distinción en cuanto a los tipos de discos existentes es muy importante a la hora de adquirir las evidencias, dado que puede ser una ventaja si el disco se ha creado como thin permitiéndonos ahorrar espacio en el destino así como acelerar el proceso de copia al tener que trabajar con muchos menos datos. Pero para poder aprovecharnos de dicha característica, y esto es imprescindible, el sistema de ficheros del dispositivo de destino debe ser VMFS. En caso contrario obtendremos un disco con el tamaño total cuyos bloques no ocupados contendrán ceros. 

Podemos comprobarlo utilizando Veeam FastSCP (actualmente integrado dentro de Veeam Backup) o directamente mediante la interfaz de exploración del datastore del cliente vSphere: seleccionado el servidor ESXi, pestaña Configuration, Storage, seleccionar datastore adecuado, botón derecho Browse Datastore y allí seleccionar fichero correspondiente al disco virtual, botón derecho Download. Una vez descargado el fichero utilizado para el ejemplo comprobaremos como su suma md5 coincidirá con la calculada en el servidor tras crear el snapshot pero su tamaño será el espacio total indicado durante la creación de la máquina virtual. 

Por lo tanto en nuestro caso, para realizar el proceso de adquisición, crearemos un ISCSi target que conectaremos al ESXi para generar un nuevo datastore y poder copiar allí la evidencias, incluyendo el disco virtual thin provisioned. 

Instalando y configurando un ISCSI target en Ubuntu 

En lugar de exponer un disco fisico como almacenamiento voy a utilizar un fichero generado utilizando dd cuyo tamaño voy a preubicar, algo así como EagerZeroedThick :-) 

# dd if=/dev/zero of=/mnt/casos/vmfs.img bs=1024k count=8000

8000+0 registros leídos

8000+0 registros escritos

8388608000 bytes (8,4 GB) copiados, 217,871 s, 38,5 MB/s

La instalación del ISCSi target en Ubuntu 12.04 me ha dado algún que otro problema de dependencias, pero al final los he resuelto realizando los siguientes pasos en el orden exacto en que los indico: 

# apt-get update

# apt-get install -y linux-source build-essential

# cd /usr/src/

# ln -s linux-source-3.2.0 linux

# apt-get install -y linux-headers-`uname -r`

# apt-get -y install iscsitarget-dkms

# apt-get -y install iscsitarget

Ahora llega el momento de configurar los paquetes. Para el ejemplo no se ha configurado autentificación usuario/contraseña para la conexión del iscsitarget aunque sería lo más recomendable. 

Lo primero habilitar el iscsitarget: 

# sed -i "s/false/true/" /etc/default/iscsitarget

y definir la LUN compartida, en mi caso el fichero creado previamente con dd, tras lo que reiniciaremos el servicio para aplicar la nueva configuración: 

# echo "Target iqn.2012-11.local.collector:storage.lun1" >> /etc/iet/ietd.conf

# echo "   Lun 0 Path=/mnt/casos/vmfs.img,Type=fileio" >> /etc/iet/ietd.conf

# echo "   Alias LUN1" >> /etc/iet/ietd.conf

# service iscsitarget restart

Tambien podemos modificar las opciones del fichero /etc/iet/initiators.allow para indicar exáctamente qué equipos/redes tienen permitido el acceso al iscsitarget; por defecto se permite la conexión a todos (ALL : ALL). 

Para comprobar que funciona correctamente: 

# apt-get install open-iscsi

# iscsiadm -m discovery -t st -p 192.168.1.9

192.168.1.9:3260,1 iqn.2012-11.local.collector:storage.lun1

Ahora llega el momento de establecer la conexión desde el servidor ESXi al iscsitarget. La configuración de red para las pruebas que he realizado es la más sencilla de las posibles: 

En este escenario dentro del ESXi sólo hay definido un vSwitch sobre una única tarjeta de red que se utiliza tanto para dotar de conectividad a las máquinas virtuales como para permitir las administración del servidor y, a partir de este momento, conectar mediante ISCSI con el nuevo storage para almacenar las evidencias. Para configuraciones más complejas o simplemente con el fín de aprender más recomiendo consultar la guía "vSphere Networking". 

Para no alargar innecesariamente el artículo he generado un PDF con capturas de pantalla de los pasos a dar para agregar un nuevo adaptador iSCSI, conectarlo al target configurado en la máquina Ubuntu y generar un datastore para poder almacenar allí los ficheros necesarios. 

Copiando las evidencias 

Clonaremos ahora el disco thin provisioned obtenido como resultado del snapshot del sistema comprometido en el nuevo datastore desde una sesión SSH en el servidor ESXi: 

# vmkfstools -i "/vmfs/volumes/datastore1/Windows XP/Windows XP.vmdk" \

 -d thin "/vmfs/volumes/evidencias/Windows XP.vmdk"

Destination disk format: VMFS thin-provisioned

Cloning disk '/vmfs/volumes/datastore1/Windows XP/Windows XP.vmdk'...

Clone: 100% done.

Una vez finalizado el proceso comprobaremos que ambos ficheros tienen el mismo tamaño y generaremos la suma MD5 para confirmar que son idénticos: 

# du "/vmfs/volumes/datastore1/Windows XP/Windows XP-flat.vmdk"

1873920 /vmfs/volumes/datastore1/Windows XP/Windows XP-flat.vmdk

# du "/vmfs/volumes/evidencias/Windows XP-flat.vmdk"

1873920 /vmfs/volumes/evidencias/Windows XP-flat.vmdk


# openssl dgst -md5 "/vmfs/volumes/datastore1/Windows XP/Windows XP-flat.vmdk"

MD5(/vmfs/volumes/datastore1/Windows XP/Windows XP-flat.vmdk)= 72af25242d8abf5ae8183d8fbab22925

# openssl dgst -md5 "/vmfs/volumes/evidencias/Windows XP-flat.vmdk"

MD5(/vmfs/volumes/evidencias/Windows XP-flat.vmdk)= 72af25242d8abf5ae8183d8fbab22925

En este caso he utilizado md5, lo cual no es lo más recomendable a día de hoy. Para conocer los algoritmos de resumen soportados por openssl así como todas las opciones puede consultarse lamanpage del comando. 

Sólo restaría hacer una copia del estado de la memoria en el momento del snapshot y generar las sumas de comprobación: 

# cp "/vmfs/volumes/datastore1/Windows XP/Windows\ XP-Snapshot1.vmsn" /vmfs/volumes/evidencias/

# openssl dgst -md5 "/vmfs/volumes/datastore1/Windows XP/Windows XP-Snapshot1.vmsn"

MD5(/vmfs/volumes/datastore1/Windows XP/Windows XP-Snapshot1.vmsn)= bc91023b458d5103aa97bf3b265572cc

# openssl dgst -md5 "/vmfs/volumes/evidencias/Windows XP-Snapshot1.vmsn"

MD5(/vmfs/volumes/evidencias/Windows XP-Snapshot1.vmsn)= bc91023b458d5103aa97bf3b265572cc

En último lugar habría que desmontar el datastore y desconectar el iscsitarget para dejarlo todo como estaba. Incluyo aquí un PDF con el proceso detallado mediante capturas de pantalla. También detendremos y deshabilitaremos el servicio iscsitarget en Ubuntu: 

# service iscsitarget stop

# sed -i "s/true/false/" /etc/default/iscsitarget

Ahora ya tenemos los ficheros en nuestra máquina pero, ¿como accedemos a un sistema de ficheros VMFS para analizar el contenido? 

Accediendo a vmfs desde Ubuntu 

La respuesta viene de la mano de Mike Hommey y las vmfs-tools, un set de herramientas que permite el acceso al sistema de ficheros VMFS apoyándose en el módulo de FUSE. El paquete está disponible desde los repositorios de Ubuntu, pero para garantizar la disponibilidad de las últimas funcionalidades, entre las que se encuentra el soporte de VMFS-5, descargaremos las fuentes desde el repositorio git: 

# apt-get -y install git

# cd /usr/local

# git clone https://github.com/glandium/vmfs-tools.git

Ahora compilamos e instalamos, satisfaciendo en primer lugar todas las dependencias: 

# cd vmfs-tools/

# apt-get -y install uuid-dev pkg-config libfuse-dev asciidoc xsltproc docbook

# ./configure

# make

# make install

Una vez correctamente finalizado el proceso anterior llega el momento de acceder a las evidencias montando el "disco" en formato vmfs. Para ello he seguido los pasos indicados en el comentario final del siguiente enlace, Announcing vmfs-tools version 0.1.0. Básicamente los pasos serían: 

# apt-get -y install kpartx

# losetup -r /dev/loop0 /mnt/casos/vmfs.img

# kpartx -a -v /dev/loop0

add map loop0p1 (252:0): 0 16368187 linear /dev/loop0 2048

# mkdir /mnt/temp

# vmfs-fuse /dev/mapper/loop0p1 /mnt/temp

VMFS: Warning: Lun ID mismatch on /dev/mapper/loop0p1

ioctl: Invalid argument

ioctl: Invalid argument

# mount | grep temp

/dev/fuse on /mnt/temp type fuse (rw,nosuid,nodev,default_permissions)

# ls -l /mnt/temp/

total 2404544

-rw------- 1 root root 21474836480 nov 10 14:26 Windows XP-flat.vmdk

-rw------- 1 root root   542290920 nov 10 15:01 Windows XP-Snapshot1.vmsn

# du -h /mnt/temp/*

1,8G    /mnt/temp/Windows XP-flat.vmdk

518M    /mnt/temp/Windows XP-Snapshot1.vmsn

Y podemos volver a comprobar las sumas md5 para confirmar que no han sido modificadas durante el proceso: 

# md5sum /mnt/temp/*-flat.vmdk /mnt/temp/*.vmsn

72af25242d8abf5ae8183d8fbab22925  /mnt/temp/Windows XP-flat.vmdk

bc91023b458d5103aa97bf3b265572cc  /mnt/temp/Windows XP-Snapshot1.vmsn

Cuando terminemos de trabajar con el sistema de ficheros VMFS y para dejarlo todo como estaba: 

# umount /mnt/temp

# kpartx -d -v /dev/loop0

del devmap : loop0p1

# losetup -d /dev/loop0

Para analizar el disco vmdk podemos utilizar las herramientas del sleuthkit directamente sobre el sistema de ficheros montado. Importante recalcar que éstas deben haberse compilado con soporte para ficheros en formato afflib, pero esto lo dejaremos para otra ocasión :-) 

Recalcar de nuevo que si copiamos el disco vmdk thin provisioned a cualquier sistema de ficheros distinto de vmfs nos ocupará el tamaño máximo establecido. 

Despedida y cierre 

Seguro que por desconocimiento he cometido algún error. Si éste fuera el caso agradecería vuestros comentarios o sugerencias para subsanarlos. Por último, y si habéis llegado hasta aquí, os agradezco la deferencia y espero os hayáis entretenido tanto como lo he hecho yo durante la configuración del escenario y todas las pruebas necesarias para escribir estas líneas. 

Enlaces de interés 

VMware vSphere 5.1 Documentation Center 
A handful of ESXi tips and tricks 
Configuring advanced options for ESX/ESXi 
VMDK virtual disk type 
vSphere Command-Line Interface Reference 
VMware ESXi SSH CLI commands 
Linux / UNIX: Create Large 1GB Binary Image File With dd Command 
Ubuntu 12.04 with iSCSI target for VMware ESXi 4.1 
iSCSI target on Ubuntu 
Regular vmdks 
Snapshots or Redologs 
vmfs 
Virtual Machine Files Essential to Forensic Investigations 
Howto read VMFS 3 with a Linux LiveCD 

En breve más, y mejor, espero ;-)

Fuente: Neosysforensics

Leer más...