Resultados 1 al 8 de 8
  1. #1
    Moderador Global

    Fecha de ingreso
    10 sep, 08
    Ubicación
    Barcelona
    Mensajes
    681
    Gracias
    102
    Agradecido 695 veces en 185 Mensajes

    Predeterminado Taller Forensic II. NTFS

    Servicios de Seguridad Informática

    Empezamos.....

    ¿Qué ocurre cuando formateamos una partición en NTFS?

    Un volumen formateado en NTFS NO TIENE áreas diferenciadas tal y como lo estudiamos en FAT (recuerda las famosas áreas de FAT1, FAT2, Root Directory, etc..), en su lugar, todo se almacena en FICHEROS.

    Por defecto el tamaño del cluster es de 512 bytes, pero esto puede variar, claro...

    Distingamos dos “conceptos
    • LCNs que son los Logical Cluster Numbers (número de sectores lógicos) que son todos aquellos que componen un volumen, el primer cluster lógico es el cluster cero.

      VCNs que hace referencia a los datos, esto es, el número de clusters que ocupa un archivo en este sistema y como antes, el primer VCNs es el cero.


    NTFS utiliza 64 bits para “numerar” cada cluster y para acceder al contenido de cada fichero utiliza lo que se llama DATA RUN’s, un Data Run es un puntero que indica el inicio del primer VCN’s de un archivo o bien, “el trozo” siguiente.

    El tamaño máximo de un archivo en NTFS es de 2^64 bytes, una barbaridad de número... 18.446.744.073.709.551.616 con lo que podríamos decir que ilimitado.

    NTFS incorpora además numerosas mejoras y “añadidos” con respecto a FAT, en esta tabla veremos alguna de ellas:



    Como ves NTFS parece “mas completo” que FAT, incorpora muchas mejoras en el sistema de archivos, en las propiedades de cada fichero (atributos), en el tamaño, etc. eso sin hablar del rendimiento, de la tolerancia a errores o de una mejor asignación del espacio en disco, en todos esos casos podríamos decir que NTFS es mejor que FAT.

    No te preocupes ahora si no comprendes bien que son términos como ADS, Sparse File, Reparse Points, etc... ya lo iremos descubriendo...

    Pero volvamos a lo nuestro... como ya dijimos TODO en NTFS son ficheros... ficheros que a su vez está compuesto de atributos.

    Si tuviésemos que hacer una analogía con las áreas o regiones que usa NTFS tal y como hicimos con FATxx sería mas o menos así:



    Sin embargo NO TE CONFUNDAS, esas áreas aunque están separadas físicamente (ocupan posiciones físicas diferentes en el disco) no tienen una posición definida como ocurría en FAT, excepto para el Boot Sector que sigue estando en las primeras posiciones del disco, el resto se puede repartir a lo largo y ancho del espacio que dispongamos.

    El Boot Sector sigue prácticamente la misma estructura que en FATxx, lo dejaremos para mas adelante, ahora vamos a fijarnos en los archivos que formarán el Sistema NTFS, vamos a seguir la explicación con un ejemplo...

    Descargad esta imagen Evidence File de Encase desde:

    MEGAUPLOAD - The leading online storage and file delivery service

    Esta imagen es de una partición NTFS tan sólo de 1GB (no... no es 1GB la descarga, apenas ocupa unos 15Mbytes) nos servirá de ejemplo para esta ocasión.

    Una vez descargada y ejecutada, al abrir Encase tendremos esto:



    Concretamente fijaremos nuestra atención en la zona derecha...



    Tenemos dos carpetas de usuario:

    * Canciones y Vídeos.

    Varios archivos de datos

    * MySims.jpg, Zelda.jpg, docu1.txt que son las entradas numeradas: 2-4-18-19-20, el resto son los ficheros que componen el Sistema de Archivos NTFS

    Exceptuando los Unallocated Clusters (cluster sin asignación) y algún otro que pueda existir como Volume Slack (no es nuestro caso) o la carpeta System Volume Information, el resto de ellos son ficheros propios del sistema de archivos y comienzan por el signo dólar ($)

    Cada cual tiene su misión y se ocupa de informar al sistema de archivos, por el momento, a este conjunto de ficheros se les suele llamar Metadatos.

    El Sistema Operativo no incorpora órdenes o comandos para que podamos acceder a esta información, la orden dir no mostrará esa información... Sólo con herramientas del tipo Encase u otras proporcionadas expresamente podremos verlas...

    Microsoft suministra una serie de “utilidades” con las que podríamos echar un vistazo a parte de esta información, podéis descargaros las OEM Tools desde:

    http://download.microsoft.com/downlo...us/oem3sr2.zip

    Nos interesa especialmente aquél que dice $MFT y su copia que es $MFTMirr y para ello este conjunto de utilidades viene con una que se llama nfi.exe



    Arriba se muestra una salida parcial de la orden nfi.exe r:, no te preocupes de todas “las cosas extrañas” que aparecen las iremos viendo en seguidita... pero ataquemos la MFT.

    Master File Table (MFT)

    Cada fichero o carpeta en NTFS está representado con una entrada especial dentro del archivo llamado MFT.

    La Master File Table no es otra cosa que una tabla que contiene todos y cada uno de los archivos que componen un volumen, cuando el Sistema Operativo quiere alcanzar el contenido de un archivo, consulta a la MFT para obtener información del mismo, su tamaño, propiedades, atributos, localización, etc... por tanto la MFT es como una base de datos que almacena todo lo que se necesita a la hora de acceder a un archivo o carpeta.

    Y como es muy importante, existe una “copia” llamada $MFTMirr, haciendo una mala comparación sería como FAT1 y FAT2 en el sistema de archivos FATxx

    Las diferencias principales son que no es un área concreta de disco sino un fichero y además ese fichero MFT puede estar en diferentes zonas del disco (este sería un caso de MFT fragmentada)

    La MFT suele situarse en la parte central de disco y por cada entrada (por cada archivo o carpeta) crea un registro de 1Kbyte, 1024 bytes.

    La primera entrada de la MFT es precisamente la propia MFT!!!!! De hecho los primeros 16 registros de la MFT está reservados (realmente son 24, aunque sólo se utilizan los primeros 16).

    Una tabla mejor:


    Por tanto, los archivos y carpetas de usuario se registrarán en la MFT a partir del registro número 25 (o el 24 si contamos desde el cero que es como debería de contarse)

    Por cada unidad existe sólo una MFT junto con su copia y el resto de metadatos, como ves son 16 y no todos tienen importancia para el análisis forense, hablaremos de ellos mas tarde, lo que nos interesa ahora es la consabida MFT.

    De momento, para ver un poco mejor esto en EnCase, vamos a configurar un Estilo de texto de tamaño 1024 bytes (que es el tamaño de cada una de las entradas de la MFT)

    Por si no recuerdas como se hacía, te lo pongo pantalla por pantalla (sin comentar nada que esto ya se debería conocer)











    Y así cuando volvamos a la vista de Case y seleccionemos la ficha Text veremos una “línea” (entrada) de 1024 bytes por cada entrada de la MFT



    Si cuentas desde la primera entrada verás que los primeros 16 son aquellos que hablamos de los metadatos, del 17 al 24 están reservados y la posición 25 la ocupa el primero de nuestros archivos de datos.

    Si desplazamos un poquito a la derecha el deslizador de la parte inferior veremos que se “intuyen” los nombres de nuestras carpetas y/o archivos:



    Pero esta no es la forma apropiada de entender y estudiar la MFT, lo adecuado sería analizar los 1024 bytes de cada una de ellas... jajaja, nooooo, no sufras, no vamos a ponernos a ver byte por byte... sólo lo haremos para aquellos que resulten mas interesantes.

    La MFT es sencilla de entender aunque un poco pesada, lo reconozco, pero es necesario para cuando toquen cuestiones mas “trascendentales

    Como ya hemos dicho el tamaño de la MFT puede variar (normalmente es fija y sólo si es preciso se habilitará mas espacio y tendríamos una MFT fragmentada) lo que sí es siempre son 1024 bytes por cada entrada, esto es muy parecido a los i-node de Linux que ya entraremos en ellos... y lo que sí es importante también, cada uno de esos registros de la MFT son contiguos.

    La MFT tiene “partes” diferenciadas, cada uno de los registros, cada uno de esos conjuntos de 1024bytes de cada entrada tiene una cabecera y unos atributos...



    La cabecera de la MFT se corresponden con los primeros 56bytes si estamos usando Windows XP/2003 o de los primeros 48 bytes si usamos Windows 2000

    En estos ejemplos estamos usando XP/2003 por tanto aplicaremos la regla de los primeros 56bytes en la cabecera... recuerda que si usas W2000 has de contar sólo los 48bytes primeros.

    Para el análisis forense de todos estos 56 bytes sólo nos van a interesar los bytes 22 y 23 de la cabecera (por el momento), éstos indicarán:



    A raíz de esto mismo, desprendemos que cuando se borra un archivo o directorio, lo que realmente se hace es marcar con los valores 00 00 ó 02 00 la entrada correspondiente de la MFT, nada mas... por eso luego podremos recuperar esa información borrada con facilidad, cuando llegue la recuperación de datos en NTFS profundizaremos es ello.

    Veámoslo con EnCase, para ello vamos a tomar como “conejillo de indias” un archivo de música que está situado en la posición 33, mejor dicho sería la 32 puesto que se ha de contar desde la posición cero de nuestra MFT.



    Si ahora seleccionamos la ficha Hex y resaltamos los 1024 bytes tendremos la entrada completa de ese archivo en la MFT



    Como lo que nos interesa es sólo la cabecera, vamos a hacer lo mismo pero sólo para los primeros 56 bytes de esta entrada:



    He recuadrado también (en rojo) los bytes 22 y 23, que contienen el valor 01 00 esto es, se trata de un fichero actual (vamos, que no está borrado)

    Después de la cabecera (Header) vienen el/los atributos... son muchos y de diverso interés, por el momento nos conformaremos con saber cuales son y su estructura:



    Aquí tienes una lista de todos los atributos junto con sus códigos que los identifican que pueden existir en una entrada de la MFT:



    Cada atributo tiene un identificador único de 4 bytes (como se muestra en la tabla), es lo que se llama cabecera o header de atributo:



    Y también por cada atributo e inmediatamente después de la cabecera del mismo se indica el tamaño del mismo, así:



    Es decir, tras el identificador del atributo tenemos otros 4 bytes que indican su tamaño, y como bien muestra el ejemplo, una longitud de 60 00 00 00 no significa el atributo $Volume_NAME sino que determinado atributo tiene una longitud de 00 00 00 60 (recuerda lo del Little Endian) o sea, de 96 bytes.

    Realmente cada atributo tiene una cabecera, un tamaño y los datos de ese atributo:



    Y para hacerlo “mas complicado”, el attribute Stream contiene los datos de o puede incluso contener un atributo de datos, esto es debido a que cada entrada en la MFT es fija, los 1024bytes famosos, qué ocurriría si un determinado archivo requiere atributos de mayor longitud?? Pues que no “entraría” en la MFT, por eso se puede disponer de atributos “externos”

    Para que no te lies mucho, suponte que un atributo es un puntero que “apunta” a determinada información o característica de un archivo, pues un atributo de datos nos es otra cosa que un puntero a otro puntero.

    Cada atributo de cada entrada de la MFT son secuenciales, es decir, el atributo X comienza por su identificador, le sigue su tamaño y luego sus datos, tras ello, comienza con el identificador del atributo Y, con su respectivo tamaño, su stream de datos y el siguiente será el identificador del atributo Z... y sucesivos.

    En una entrada MFT no tienen por qué estar presentes todos los atributos, de hecho nunca es así, hay algunos que sí que están casi en todas las ocasiones, los mas importantes son:



    De ellos nos ocuparemos en la siguiente parte del documento, ahora vamos a volver a nuestro ejemplo de EnCase y nos vamos a conformar con “identificar” y seguir la pista a cada uno de los atributos del archivo de ejemplo:

    Primero nos desplazamos hasta el offset 32768 y tomamos los 1024bytes de esa entrada, todo esto se corresponde con la cabecera y atributos del archivo que hemos elegido como ejemplo:



    La cabecera del archivo son los primeros 56bytes:



    Observa que después del resalte en azul correspondiente a la cabecera he remarcado en rojo los siguientes 8 bytes, que son:
    • 10 00 00 00 ------ >Identificador del atributo $STANDARD_INFORMATION
      60 00 00 00 ------ >Tamaño del atributo 00 00 00 60 (little endian) 96 bytes


    Esto significa que desde el comienzo de la STANDARD_INFORMATION debemos contar 96 bytes para encontrar el siguiente atributo y su identificador, como verás en la siguiente pantalla resalté en azul 96 bytes desde el inicio del identificador (recuadro en amarillo) y recuadrado en rojo aparece el siguiente atributo:



    Los 8 bytes que siguen a la STANDARD_INFORMATION son 30 00 00 00 78 00 00 00 (recuerda la tabla de mas arriba que relaciona los identificadores y atributos)

    Esto significa que el siguiente atributo es $FILE_NAME (30 00 00 00) y que el tamaño de este atributo es 00 00 00 78 (en little endian) que son 120 bytes.

    Es decir, que si aplicamos lo mismo de antes y resaltamos los siguientes 120 bytes desde el inicio de este atributo (30 00 00 00 ) correspondiente a $FILE_NAME obtendremos el siguiente identificador de atributo:



    Como antes, recuadrado en amarillo está el atributo anterior y su tamaño, resaltado en azul el contenido del mismo y resaltado en rojo el inicio del siguiente atributo junto con su tamaño.

    Curiosamente el siguiente atributo vuelve a ser 30 00 00 00 ($FILE_NAME) y el mismo tamaño (78 00 00 00 ) No siempre puede ser así pero no debe extrañarte puesto que un archivo en NTFS puede tener “varios” nombres. El caso es que si realizamos la misma operación llegaremos al siguiente atributo:



    En esta ocasión nos encontramos que el siguiente atributo (recuadrado en amarillo) es 80 00 00 00 ($DATA) con un tamaño de 48 00 00 00 (que en little endian es 00 00 00 48 ) de 72 bytes.

    De nuevo repetiremos la operación... 72 bytes desde el inicio del atributo $DATA



    Y encontramos que el siguiente atributo es FF FF FF FF o mejor dicho... ya no hay mas atributos por lo que entendemos que el resto de la información de esta entrada en la MFT ha concluido.

    Es monótono como ya te adelanté, no hemos analizado nada de los contenidos ni de lo qué puedan significar éstos... eso llegará en la próxima entrega.

    También podríamos haber recurrido a la utilidad nfi.exe que comentaba anteriormente, si buscamos el contenido de la entrada 33 (32 contando desde cero) también averiguaremos esto mismo de forma “mas automatizada”



    Bien, pues paramos aquí... no es mucho, pero sí de mucha utilidad para las siguientes prácticas y ejemplos, en la próxima nos ocuparemos de entender y analizar mas detenidamente otros atributos de la MFT.

    ATRIBUTOS DE MFT

    Sólo por recordar.... esta tabla se corresponde con los identificadores de los atributos de la Master File Table:



    Los atributos pueden ser residentes y no residentes, esto es, si toda la información correspondiente al atributo se encuentra en la MFT (esto es residente) o por el contrario, los valores del atributo son tan extensos que residen fuera de la MFT (atributo no residente)

    Este concepto de residente y no residente se aplica no sólo a los atributos, ya veremos mas adelante en ejemplos que hasta los datos de un archivo pueden ser residentes o no residentes, de momento nos quedamos con la idea:

    • * “algo” residente es aquello que está por completo en la MFT
      * “algo” no residente tiene una entrada en la MFT que apunta a un espacio que no pertenece a la MFT.

    Vamos a tratar de explicar:
    Código:
    $STANDARD_INFORMATION 10 00 00 00
    $FILE_NAME 30 00 00 00
    $DATA 80 00 00 00

    $STANDARD_INFORMATION

    El identificador de este atributo es 10 00 00 00

    Informa de diversas marcas de tiempo como las horas y fechas de creación del archivo, modificación y/o accesos al archivo, también informa de los permisos de acceso, si es de sólo lectura, oculto, sistema, etc...

    Como veremos gran parte de la información de este atributo se repite en otro, en $FILE_NAME.

    De entre toda la información que nos puede ofrecer la STANDARD_INFORMATION resaltaremos dos:

    • * Una marca de tiempo “especial” llamada Entry Modified o MFT Changed.
      * Los permisos del archivo.

    Te pongo la tabla completa de los valores mas representativos de este atributo:

    Los desplazamientos (offset) de la tabla anterior corresponden al comienzo de los valores del atributo, entre ellos y el inicio existen otros valores, como el indicador, el tamaño, el flag de non-resident, otras flags propias del atributo, etc...

    En un ejemplo con EnCase lo veremos mejor, tomemos el archivo que ocupa la posición 32 en nuestra MFT el mismo que nos sirvió de ejemplo en el post anterior... la cancioncita de “Lola Flores



    Resaltado en azul oscuro está la cabecera de la entrada MFT y en azul clarito el primero de los atributos de ese archivo (recuerda que la cabecera de una entrada MFT son siempre los primeros 56 bytes para XP/2003)

    El atributo comienza por 10 00 00 00 --- > $STANDARD_INFORMATION

    Le sigue: 60 00 00 00 ---> Tamaño total del atributo (00 00 00 60 que son 96 bytes) el tamaño puede variar, no siempre serán 96 bytes.

    Después le sigue 00 ---- > Que es el flag de non-resident, como es un cero indica que el atributo es RESIDENTE.

    Luego 00 00 00 00 00 00 --- > que son diversas flags que no interesan

    A continuación: 48 00 00 00 -> que es el tamaño del atributo (00 00 00 48 que son 72bytes)

    Sigue 18 00 00 00 -> Desplazamiento para encontrar los datos... (00 00 00 18 que son 24 bytes)

    ALTO!!!!

    Primera duda... pero el tamaño no lo marcaban los bytes 60 00 00 00????

    Segunda duda.... ese desplazamiento 18 00 00 00???? Contados desde????

    Si, cierto!!! Ese nuevo valor, 48 00 00 00 es el tamaño del atributo desde el inicio de sus datos y no desde el inicio del identificador y el desplazamiento es el offset que tenemos que contar desde el inicio del atributo... menudo lío, que no???

    Aclarémoslo:

    Contamos 24 bytes (que es el desplazamiento) desde el inicio del atributo y desde allí los siguientes 72 bytes serán los datos del atributo.

    Si te fijas: 24+72 = 96 que son los bytes TOTALES del atributo, 24 de desplazamiento y 72 de datos.

    O sea, que desde la posición 24 (sin contar el 24, vamos desde el 25) hasta la 72 inclusive encontramos los datos del atributo que estamos estudiando y es desde esos últimos 72 bytes desde donde tendremos que aplicar la tabla que se puso anteriormente.

    Los primeros 4 valores para la fecha/hora de creación, los siguientes 4 para la fecha/hora de modificación y a sí sucesivamente.

    Por ejemplo, en nuestro caso serían:



    Bien, las marcas de tiempo fecha/hora se calculan como lo aprendimos en FAT, no vamos a incidir mas en ello, sin embargo, como ya te adelanté la entrada Fecha/Hora de modificación en la MFT (lo que se llama Entry Modified) puede ser significativa en el análisis forense.

    EnCase ya nos calcula las fechas y demás zarandajas, para ello basta que selecciones un archivo cualquiera y luego pinchad en la ficha Report



    El valor de la Entry Modified marca la fecha y la hora de cuando se produjo un cambio en la MFT correspondiente al archivo y/o directorio, es decir, almacena el valor de cuando se creó esa entrada o cuando se modifico la entrada en la MFT o cuando se eliminó....

    Esta fecha no se visualiza desde el sistema operativo, necesitamos herramientas forenses o anti-forenses para ver/modificarla y no existe en volúmenes FAT (si en Linux, EXT2, EXT3, etc..)

    PRÁCTICA 1. Comprendiendo la Entry Modified

    Y para qué puede servir? para qué se utiliza la Entry Modified?

    Como veremos cuando llegue el análisis forense “de verdad” (digo de verdad porque hasta ahora sólo estamos entendiendo cómo funcionan los diferentes sistemas de archivos) podemos seguir el flujo de fechas de uno o mas ficheros, lo que se llama el TimeLine y descubrir archivos modificados, creados, borrados, accedidos, etc en determinada fecha o rango de fechas, esto nos da una “línea de actividad” si se tratase de un ataque a un servidor o similar, podemos ver de un golpe todo aquello que hizo en el sistema de archivos.

    Pongamos un ejemplito fácil...

    Imaginemos que existe un archivo llamado Zelda.jpg que tiene “información valiosa” y al que sólo tiene acceso el usuario pp



    Y si intentamos verlo sin ser pp pues, eso.... no podemos....



    Vamos a seguir imaginando.... de “algún modo” conseguimos iniciar sesión como el administrador del sistema (robo de contraseñas, exploits, ingenieria social, vamos como sea) pero como no somos pp seguiremos sin poder acceder a ese archivo como muestra la pantalla anterior sólo System y pp pueden hacerlo.

    Bien, antes de ello, haremos un cronograma...

    No queremos dejar rastros de fechas de acceso, etc... y como el usuario pp es muy “meticuloso” lo primero que haremos es ver la fecha de último acceso, esto lo podemos hacer mostrando las propiedades de ese archivo, pero puede existir un problema....

    • Si lo hacemos asé es probable que al pinchar sobre el archivo y mostrar sus propiedades la fecha de último acceso ya nos haya cambiado a la que tengamos actualmente...

    así que, por si acaso, abrimos una consola de comandos y hacemos esto:



    la orden dir nos mostrará el directorio como ya conocemos y la opción /TA mostrará la fecha/hora de último acceso a los archivos... como vemos en la pantalla anterior, tenemos:

    • * que la fecha actual es el 19-06-2008
      * que la hora actual es 0:20:20
      * que el archivo Zelda.jpg se accedió por última vez: el día 16-06-2008 a las 10:24 de la mañana.

    Así que como hemos ganado acceso al sistema con privilegios de administrador, se nos ocurre lo siguiente para que “pp” no se mosquee....

    • 1.- Cambiamos la fecha y la hora del sistema y ponemos: Día 16-06-2008 y hora 10:24
      2.- Agregamos el grupo de Todos en la ficha de seguridad del archivo para poder verlo
      3.- Comprobamos que las fechas y horas se han cambiado



    Ahora, cambiamos los permisos de archivo, incluimos al grupo de Todos para poder abrirlo...



    y miramos....



    Vale, ya lo hemos visto... pero claro, tenemos que eliminar el grupo de Todos para que no se mosquee y además volver a cambiar la fecha / hora por las actuales...



    Si vemos las fechas del archivo de nuevo...



    Pues bien, todo está como al principio... no???

    Abrimos Encase y a ver que pasa....



    Efectivamente el último acceso es “correcto” pero resulta que la fecha de Entry Modified es también muy parecida... es mas... es posterior (en 4 segundos) eso significa que a ese archivo se le cambiaron los atributos (lectura, escritura, acceso, permisos, etc..) después de verlo... y si no fue el “propietario” del mismo es un indicio claro de que “alguien” lo llegó a ver aunque no haya tocado un bit del mismo.

    En fin, este ejemplo ilustra lo que podrá llegar a hacer EnCase de forma “automática” mostrando una cronología de accesos, modificaciones o cambios... y seguir la pista de esos cambios.

    Recuerda que el sistema operativo “por sí mismo” no muestra el contenido de la Entry Modified, y algo MUY IMPORTANTE... si tenemos permisos sobre un archivo, con tan sólo “pinchar" en él (aunque no lo abramos) puede cambiar la fecha de último acceso... repito... si tenemos permisos... porque si no los tenemos como el ejemplo que se ha puesto, no ocurrirá nada, no modificará la fecha de último acceso... aun así, es mejor lo de la consola para ver las fechas en lugar de las propiedades del fichero (por si acaso)

    Antes de terminar con la STANDARD_INFORMATION hay que hablar de los permisos del archivo, cuando puse la tabla de valores de este atributo, en el offset 32 se describen los permisos del archivo... en nuestro ejemplo era 20 00 00 00

    Bien, pues los valores pueden ser:



    Ejemplos:



    Quizás llame la atención los dos últimos tipos de archivos, Sparse y Reparse, aclaremos que es esto aunque mas que para el análisis forense iría mejor en otros ámbitos como la de recuperación de datos, fragmentación, etc.. pero viene bien saberlo.

    Un Sparse File es un fichero (o puede ser) muy grande...

    Según la Wikipedia, es un tipo de archivo para el cual se asigna un espacio determinado, pero no se llena en su totalidad con ceros aún estando vacío, sino que se crea de una forma en la que las partes vacías no cuentan como espacio ocupado.

    Mejor dicho, el espacio se le “pre-asigna” puesto que aunque “reservemos” 6GB (por ejemplo) para ese archivo, el sistema operativo resta ese espacio de la capacidad del volumen, y a medida que ese sparse va creciendo, el sistema va rellenando los “huecos” por tanto, podríamos traducir los Sparse File como “Ficheros Dispersos”

    Las implicaciones que tiene este tipo de archivos y el impacto en el sistema puede ser “delicada” sobretodo cuando crece, crece, crece... y desgraciadamente como no se reserva el espacio “de ante mano” puede estar muy fragmentado.

    Cuando esto ocurre el acceso al mismo es lentísimo y las utilidades convencionales de desfragmentación no son capaces de “arreglar” (de unificar) las partes de este archivo.

    El caso típico de esto es la virtualización, las máquinas virtuales suelen crearse en uno o varios archivos del tipo sparse file y si ese archivo se fragmenta demasiado, la ejecución es torpe y lenta, otros usos de los ficheros dispersos son las imágenes de un disco, o sencillamente una base de datos.

    Microsoft distribuye una utilidad específica para poder desfragmentar estos archivos, se llama Contig y lo podéis descargar de:

    Contig v1.54(en-us).aspx

    También podemos encontrar otras herramientas con interface gráfico que son capaces de desfragmentar los sparse file, como el Power Defragmenter que lo podéis bajar de:

    http://freeweb.siol.net/razor256/dow...gmenterGUI.zip

    Un Reparse Point (podríamos traducirlo como punto de montaje o punto de re-análisis) es un tipo de archivos especial también, el caso típico es cuando creamos una partición (primaria o extendida) y en lugar de montarla en un volumen, en una unidad, lo hacemos en una carpeta... al mas puro estilo unix :P

    Los sistemas *.nix utilizan el sistema de archivos, todo cuelga” de un único directorio raíz y para lo que a Windows es una unidad de disco, para Linux, Unix, y similares es una carpeta o directorio... Eso es un Reparse Point.

    El Kit de Recursos de Windows dispone de herramientas específicas para manejarlos, por ejemplo delrp y linkd

    Desde NTFS versión 5, tenemos una “especie” de enlaces simbólicos al estilo Unix, con la excepción que esos enlaces simbólicos no pueden aplicarse a ficheros en Windows, solo a carpetas.

    Con los Junctions en NTFS podemos “unir” varias carpetas, por ejemplo, podríamos hacer un “Junction” de c:\videos\ y de D:\datos\personal\películas\ y se creará un punto de montaje de esa unión.

    Como ya dije, la herramienta del Kit de recursos Linkd permite hacer este tipo de operaciones, podéis revisar este artículo para comprender el uso de los junction, puntos de montaje, etc...

    How to create and manipulate NTFS junction points

    $FILE_NAME

    Este atributo de la MFT guarda información específica del archivo, su nombre, también sus marcas de tiempo (por eso decía antes que gran parte de la STANDARD_INFORMATION se repite en $FILE_NAME)

    Y en nuestro ejemplo:



    Observa que en este ejemplo el archivo tiene dos entradas para FILE_NAME (resaltadas en azul claro la primera y azul oscuro la segunda)

    Este atributo es siempre RESIDENTE y los valores del mismo comienzan contados 24 bytes desde el identificador de atributo (30 00 00 00 que es el usado por $FILE_NAME)

    Es muy común que las marcas de tiempo sean idénticas (es nuestro caso) recuerda que los valores “exactos” de los mismos residen en la STANDARD_INFORMATION, de este atributo nos interesa especialmente la longitud (el tamaño del archivo y el tamaño que ocupa en disco) los permisos (idénticos a los de la STANDARD_INFORMATION) la longitud del nombre y el espacio al que pertenecen.



    El tamaño se expresa en Little endian, es decir, en nuestro caso: 00 CE 29 00 00 00 00 00, que en decimal es: 2.739.712 y si miramos en las propiedades del archivo:



    Recuerda aquello de los cluster y los tamaños de archivos que hablábamos en FAT... dependiendo del número de bytes por cluster, estos valores pueden ser muy diferentes, por ejemplo, si tenemos un tamaño de cluster de 32KB y un archivo de texto que contiene “Hola”, el tamaño en disco será de 32KB mientras que el tamaño del archivo serán 4 bytes.

    En cuanto al tamaño en caracteres del archivo, pues eso... los caracteres que tiene incluyendo la extensión (caracteres en UNICODE)

    para saber mas acerca de la codificación UNICODE:

    [ame=http://es.wikipedia.org/wiki/Unicode]Unicode - Wikipedia, la enciclopedia libre[/ame]

    El espacio de nombres pueden ser valores 0,1,2 y 3,

    • Posix -> valor cero (00), es el espacio de nombres mas largo posible y se diferencian mayúsculas y minúsculas. Se permite cualquier valos Unicote excepto null y el la barra de división (slash, “/”). El máximo número de caracteres es de 255 y en el caso de Windows algunos caracteres especiales como los dos puntos ( : ) no los dejará usar.

      Win32 -> Valor uno (01), parecido a Posix excepto que no diferencia entre mayúsculas y minúsculas, y no se pueden usar caracteres del tipo: '"' '*' '/' ':' '<' '>' '?' '\' '|', tampoco pueden terminar los nombres en punto (.)

      DOS > Valor dos (02), Como Win 32 excepto que la longitud del nombre no será superior a 8 caracteres y tres para la extensión, esto es lo que todos conocemos como el espacio 8:3 o nombre corto.

      Win32 & DOS -> valor tres (03), Significa que el archivo es idéntico para los espacios de nombres DOS y Win32.

    Para convertir un nombre POSIX o Win32 al espacio DOS se siguen estos pasos;


    • 1.- Se Eliminan todos los posibles caracteres UNICODE

      2.- eliminan todos los puntos (.) excepto el último siempre y cuando no sea el primer carácter

      3.- Se convierte todo a mayúsculas

      4.- Se eliminan los caracteres prohibidos

      5.- Se eliminan todos los caracteres anteriores al punto (si lo hay) que excedan de la sexta posición

      6- Se eliminan todos los caracteres que excedan de tres después del punto.

      7.- Si el nombre ya existe se coloca la cadena "~1" y se va incrementando el número según el número de ocurrencias.

    Por ejemplo, el archivo Lola Flores.cancion.mp3

    Código: 1.- LolaFlores.cancion.mp3
    2.- LolaFlorescancion.mp3
    3.- LOLAFLORESCANCION.MP3
    4.- LOLAFLORESCANCION.MP3
    5.- LOLAFL.MP3
    6.- LOLAFL~1.MP3

    Atributo $DATA

    Este atributo comienza con el indicador 80 00 00 00 y almacena la información de la/las posiciones que ocupa el archivo en disco en VCNs. (Número Virtual Cluster)

    El contenido de un archivo puede ser residente o no residente, dependiendo si se almacena dentro de la MFT o no.

    Un archivo residente es aquél que TODO su contenido junto con TODOS sus atributos se almacenan en la MFT.

    Como cada entrada de la MFT tiene como máximo 1024bytes, sólo podrán ser archivos residentes aquellos que no sean muy grandes.











    El identificador de $DATA es 80 00 00 00 y a continuación como ya es conocido viene su longitud, después de ello un byte que indica si es residente o no residente:







    PRÁCTICA 2. NTFS. ARCHIVO NO RESIDENTE SIN FRAGMENTAR

    Lo primero que tenemos que hacer es localizar el atributo $DATA, para ello vamos a seguir los siguientes pasos:

    Seleccionamos el archivo del que queremos obtener esa información, elegimos la entrada número 32 de la MFT que la “cancioncita” de Lola Flores y resaltamos los primeros 56 bytes que corresponden a la cabecera:



    Sabemos que tras la cabecera comienza el primer atributo es la STANDARD_INFORMATION (10 00 00 00) con una longitud de 96 bytes (60 00 00 00).

    Por tanto, Resaltamos los 96 bytes siguientes desde el inicio de la Standard_Information:



    Como vemos en el recuadro en magenta aparece el siguiente atributo, que es 30 00 00 00 seguido de su tamaño, esto es, FILE_NAME con longitud de 78 00 00 00 que es 120 bytes.

    De nuevo nos desplazamos esos 120 bytes desde el inicio del atributo y nos encontramos con otro atributo FILE_NAME tal y como vimos en otra ocasión, este nuevo atributo nombre es “el nombre largo” o nombre Win32 del espacio de nombres que vimos.



    El nuevo atributo de nombre también tiene una longitud de 120 caracteres, hacemos lo mismo, desplazamos 120 desde su inicio y nos encontraremos por fin con el atributo $DATA.



    En rosa tenemos el atributo y su longitud:

    80 00 00 00 (identificador)
    48 00 00 00 (72 bytes de longitud)


    Recuadrado en verde tenemos:

    01 Lo que significa que es NO RESIDENTE

    Recuadrado en amarillo tenemos (desplazamiento de 64bytes desde el inicio de DATA):

    • 32 E7 14 FE ED 02 que es el primer DATA RUN (o RUN LIST)
      00 00 que significa que ya no hay mas DATA RUN
      FF FF FF FF que significa que ya no hay mas atributos.

    Vale, pues sólo nos queda aprender que es eso del DATA RUN....

    32 Significa que la información ocupará 5 bytes (3 + 2 = 5) es decir, los siguientes 5 bytes pertenecen a este DATA RUN (E7 14 FE ED 02)

    Realmente este valor 32 indica “mas cosas”, lo tenemos que “desmembrar”:

    • 3 -> es lo que se llama Localización (los tres últimos)
      2 -> Es la longitud en clusters del DATA RUN (los dos primeros)

    De los siguientes 5 bytes los dos primeros nos darán la longitud en clusters del contenido del archivo:

    • E7 14 -> en Little endian son: 5351 clusters contíguos ocupan el primer DATA Run (en este caso solo hay uno pero podría haber mas)

      FE ED 02 -> En little Endian es 191.998 que es la localización del archivo.

    O sea que si nos desplazamos a la posición 191.998 y desde allí contamos 5351 clusters tendremos todo el archivo.

    Para ello pinchamos en la Ficha Disk, una vez hecho eso, botón derecho del ratón y elegimos Goto, por último escribimos en la casilla Other el valor que deseamos alcanzar:



    Y Tras pulsar en Ok nos llevará allí:



    Si contásemos 5351 clusters desde el inicio tendríamos el total del archivo.

    Vamos a “recuperar” parte del archivo... (podría ser todo pero nos conformaremos con una parte del mismo)

    Pinchamos en la ficha de Hex, luego botón derecho del ratón seleccionamos Export



    Y ponemos estos valores:



    Cuando reproduzcamos el archivo c:\cancion.mp3 escucharemos “una parte” del mismo, algo similar a lo que ya se hizo en el Taller Forensic de FAT con imágenes.

    Claro, esto ha sido fácil porque el archivo no estaba fragmentado...

    ¿qué pasaría si en lugar de ocupar clusters contiguos no hubiese sido así?

    Pues que en lugar de un únicO Data Run tendríamos varios...

    PRÁCTICA 3. NTFS. ARCHIVO NO RESIDENTE FRAGMENTADO

    Veamos un ejemplo genérico, supongamos el siguiente Data Run:



    Si lo analizamos obtendremos 6 data run’s.... vamos a ir calculando uno a uno...

    Primero:

    Los valores son: 31 01 2C 2B 02

    Y si aplicamos lo dicho anteriormente, obtendremos que el archivo comienza en el cluster 142.124 con una longitud de uno.



    Segundo:

    Valor: 31 1F 7D 60 17 lo que significa que son 31 cluster (1F) contados desde:

    7D 60 17 que en Little Endian son: 1.532.029

    PERO!!!!

    Hay que sumarle el desplazamiento anterior, es decir, el segundo fragmento de nuestro archivo se encentra en:

    Código: 1.532.029 + 142.124 = 1.674.153

    Lo vemos gráficamente...



    Y así sucesivamente con los otros cuatro restantes, de esta forma:

    Tercero:



    Cuarto:



    Quinto:


    Y así hasta el final....

    PERO!!!!!

    Pero esto está bien si todos los fragmentos están “hacia delante” desde el anterior.... PERO!!!! No siempre es así... en muchas ocasiones ocurrirá que el siguiente fragmento está posicionado ANTES del actual, es decir, que en lugar de “saltar adelante” habrá que saltar “hacia atrás

    Dicho de otro modo, ¿Cuándo se considera que hay que restar en lugar de sumar?

    La respuesta es cuando el siguiente Data run sea negativo.


    PRÁCTICA 4. NTFS. ARCHIVO NO RESIDENTE FRAGMENTADO CON SALTOS NEGATIVOS

    Imaginemos estos datos:



    Observa que los dos valores que están recuadrados en rojo son saltos negativos....
    El data run del archivo podría ser asi:

    • Primer data run:...........31 11 7E 66 46
      Segundo data run................21 1E 4E 03
      Tercer data run:..................21 46 4D F3
      Cuarto data run:.................21 7F 6B C6
      Quinto data run:..................32 8E 0F 2F 82
      No hay mas darta run:.........00 00 FF FF FF FF

    Analizamos el primero:

    31 11 7E 66 46

    Longitud: 11 que en decimal es 17
    Localización: 7E 66 46 lo pasamos a little endian 00 46 66 7E que es: 4.613.758

    Puedes comprobar con la imagen que los cálculos son correctos (primera línea)



    Analizamos el segundo:

    21 1E 4E 03

    Longitud: 1E que en decimal es 30
    Localización: 4E 03 que en Little endian es 03 4E, en decimal: 846

    Y le sumamos la localización anterior:

    Código: 4.613.758 + 846 = 4.614.604

    Puedes comprobar con la imagen que los cálculos son correctos (segunda línea)



    Y ahora el tercero:

    21 46 4D F3

    Longitud: 46 que son 70 en decimal
    Localización: 4D F3 que en little endian: F3 4D

    Si lo convirtiéramos sin mas, sería un salto hacia a delante, pero es que este es un número negativo!!!!

    ¿Cómo son los números negativos?

    Pues los valores que comiencen con valores comprendidos entre 00 y 7F se consideran positivos

    Los valores que comiencen con valores comprendidos entre 80 y FF se consideran negativos.

    Luego si nuestra localización es 4D F3 se trata de un número negativo (F3 4D....recuerda....)

    Y cuanto vale eso??

    Para los que no sepan como hacerlo (eso del complemento a1 y complemanto a2) vamos a realizarlo (con una vez vale)

    Cálculo de números negativos:

    • * Poner el valor en Little Endian
      * Comprobar que comienza por un valor mayor a 7F
      * Convertir el número a binario
      * Cambiar unos por ceros y ceros por unos
      * Sumar uno
      * El resultado es lo que se busca

    En el ejemplo:

    F3 4D en binario es

    Código: F: 1111
    3: 0011
    4: 0100
    D: 1101
    cambiamos unos por ceros y viceversa:

    Código: 0000 1100 1011 0010

    Le sumamos 1

    Código: 0000 1100 1011 0010
    +1
    ===================
    0000 1100 1011 0011

    El resultado es: 0C B3 en hexadecimal que en decimal es 3.251 NEGATIVO!!!!

    Luego al resultado que llevábamos le restamos este número

    Código: 4.614.604 - 3.251 = 4.611.353



    Puedes comprobar con la imagen que los cálculos son correctos (tercera línea)

    Está claro, no?

    También podemos hacerlo con la calculadora de Windows de una forma mas sencilla:

    Ponemos en hexadecimal el valor, y pulsamos en el botón que pone Xor (recuadrado en azul)



    Tras pulsar Xor escribimos FFFF


    Cuando pulsemos el signo igual nos dará el resultado...



    Bueno, faltaría sumarle 1 pero eso ya lo sabes hacer verdad? Jajajaja....

    Dejo de tu parte el cálculo del cuarto data run y siguientes...

    Bueno pues resumiendo, para calcular el/los data run de una entrada de la MFT

    • 1.- Buscamos el inicio con indicador 80 00 00 00
      2.- Los cuatro siguientes bytes serán el tamaño de $DATA
      3.- El siguiente byte si es uno (01) indica un Data run no residente
      4.- Nos desplazamos 64 bytes desde el inicio (desde el 80 00 00 00)
      5.- Y todo lo que encontremos hasta el primer 00 00 FF FF FF FF serán el/los data run de ese archivo
      6.- Una vez obtenidos se obtiene la longitud y la localización de cada uno de ellos
      7.- Si hay mas de un data run, tendremos que sumar (o restar) el valor de la localización anterior
      8.- Se resta si la localización comienza por un valor mayor a 7F (hex)
      9.- Se suma si la localización es un valor menor que 80 (hex)
      10.- Para calcular un número negativo se convierte el valor en little endian, se cambian ceros por unos y viceversa, y a ese nuevo valor se le suma 1. Lo que se obtiene se resta del valor de la localización del data run anterior.

    Fuente
    e-crime analyst
    Twitter: @seifreed
    http://seifreed.com

  2. Los siguientes 12 usuarios dan las gracias a Seifreed por este mensaje:

    Anay (26/06/2009), angeljm40 (30/07/2012), daedo80 (13/01/2011), Dharman (03/07/2009), DragoN (03/07/2009), Egho (18/09/2009), kikujiro (18/02/2010), kobra (10/09/2009), lifeisabox (11/03/2011), rickytx (22/06/2009), talap0 (29/03/2013), tutuca89 (09/04/2013)

  3. #2
    Dragonauta

    Fecha de ingreso
    01 sep, 08
    Ubicación
    España
    Mensajes
    182
    Gracias
    80
    Agradecido 143 veces en 31 Mensajes

    Predeterminado

    Me he dado el lujo en este tambien de pasarlo a pdf, si no quieres que lo haga solo dimelo es por tenerlo en mas formatos.
    Excelentes tutos por cierto
    4shared.com - online file sharing and storage - download Forense_NTFS.docx

  4. Los siguientes 3 usuarios dan las gracias a Anay por este mensaje:

    Dharman (03/07/2009), MrSharky (26/05/2013), talap0 (29/03/2013)

  5. #3
    Recien Nacido

    Fecha de ingreso
    24 feb, 09
    Ubicación
    Medellin
    Mensajes
    43
    Gracias
    35
    Agradecido 3 veces en 3 Mensajes

    Predeterminado

    Hermano gracias nuevamente.

    PDA: Muy bueno tu sitio web.
    -----------------------------------------------
    No pretendamos que las cosas cambien si siempre hacemos lo mismo. Albert Einstein

  6. #4
    Recien Nacido

    Fecha de ingreso
    13 jun, 09
    Mensajes
    5
    Gracias
    1
    Agradecido 0 veces en 0 Mensajes

    Predeterminado

    Muy bueno el tutorial, espero se sigan haciendo mas de estos, por mis lares el tema de Informatica Forense empeiza a cobrar fuerza.

    Saludos!

  7. #5
    Recien Nacido

    Fecha de ingreso
    19 jul, 09
    Ubicación
    En Valparaíso, Chile
    Mensajes
    3
    Gracias
    0
    Agradecido 1 vez en 1 Mensaje

    Talking

    Excelente tutorial amigo al igual que el otro, saludos cordiales


  8. Los siguientes usuarios le agradecieron a pato_arancibia por este mensaje:

    alexcal (31/05/2011)

  9. #6
    Recien Nacido

    Fecha de ingreso
    16 sep, 11
    Ubicación
    Santo Domingo
    Mensajes
    2
    Gracias
    2
    Agradecido 0 veces en 0 Mensajes

    Predeterminado

    Muy buen aporte gracias por el materia

  10. #7
    Recien Nacido

    Fecha de ingreso
    29 mar, 13
    Ubicación
    El Salvador
    Mensajes
    3
    Gracias
    3
    Agradecido 5 veces en 1 Mensaje

    Predeterminado

    Gracias esa informacion es de mucha utilidad

  11. #8
    pmp
    pmp está desconectado
    Recien Nacido

    Fecha de ingreso
    30 ene, 14
    Mensajes
    1
    Gracias
    0
    Agradecido 0 veces en 0 Mensajes

    Predeterminado

    Esta muy bueno y completo este tutorial....
    Salu2s

Información de tema

Usuarios viendo este tema

Actualmente hay 1 usuarios viendo este tema. (0 miembros y 1 visitantes)

Visitantes encuentran esta página buscando por:

estructura ntfs

master file table

comunidad.dragonjar.org taller-forensic-ii-ntfs-7688

que es MftMirr

los husos horarios una tabla respecto a la hora colombia gmt 5

unallocated clusters

editar MFT ntfs win 7

calculadora hexadecimal de xp

mft ntfs

unallocated cluster

ii. Forensics

atributos de MFT

forensic rastros inicio de sesion tuentimaleta encaseespacio de nombres contiguoencase forensic dragonjarentradas master file tablemaster file table overviewtaller ntfs dragonjarntfs mftorganizacion logica sistema de archivos windows ntfsque se ignifica dragonjaranalizando imagen ntfslos husos horarios una tabla respecto a la hora colombiaencase cuanto cuesta

Etiquetas para este tema

Permisos de publicación

  • No puedes crear nuevos temas
  • No puedes responder temas
  • No puedes subir archivos adjuntos
  • No puedes editar tus mensajes
  •  

Iniciar sesión

Iniciar sesión