The name now is mftf.exe. I'm not using any more the FSCTL_ENUM_USN_DATA method. Now I only parse the $MFT file.
Some changes to the program and some bugs fixed.
https://github.com/ignacioj/mftf
The options now are:
Options:
-d drive_letter............................Search/copy files from this logical unit.
-h........................................This help.
-f "string1[|string2 with spaces|string3?...]".....Find file/directory/ADS names with any of the strings.
-f "d:\folder\string" .....The path will limit the results to the subfolders.
The match is always case insensitive.
" as delimiters for the whole group of strings.
| is the boundary between strings.
? al the end of the string specifies an exact coincidence.
-ff file.txt....................The strings to search for are in file.txt.
One string per line, no separator, use ? as needed.
-fr string......................Find the string doing a raw search in the 1024 bytes of the MFT record.
It will report coincidences in the unallocated space of the MFT record.
-fads...........................Find all the ADSs in the logical unit.
>Can be used with any of the previous find options:
-fx..................................Save the results in a file in order to use the option -c.
-ft..................................Show the results in timeline format.
-i full_path_to_file/directory.......Show information about the path.
-i record_number.....................Show information of the MFT record.
-w record_number.....................Write on screen the 1024 bytes of the MFT record.
-c "reference1[|reference2...]"......Copy the file/s referenced to this folder.
| is the separator.
-c list.txt..........................Copy all the files referenced in the file list.txt.
Each line MUST start with: reference + [TAB].
-cr record_number....................Copy the 1024 bytes of the MFT record to this folder.
Examples:
> MFT-fileoper.exe -d e: -f "svchost|mvui.dll|string with spaces|exact match?"
> MFT-fileoper.exe -d e -fx -f "c:\folder\temp.dll|snbclog.exe"
> MFT-fileoper.exe -d e -c "33:128-1|5623:128-4"
Showing posts with label NTFS. Show all posts
Showing posts with label NTFS. Show all posts
29 Jan 2015
13 Jan 2015
Another MFT parser and copy restricted files program
I've been working on a command line program that allows me to do quick searches directly accessing the MFT and copy files avoiding the limitations of the OS. There are already some programs that do it but:
- Some have ceased to be free.
- Some are very large in size and slow.
- I want to learn seriously the architecture of the MFT.
- I want to learn c#.
- Just for fun.
The method I have used to speed things up is to create a dictionary using the enumeration of the MFT with FSCTL_ENUM_USN_DATA and including the offset of the MFT records in it.
This process, in an old system with a partition of 400 Gb with 300k objects, takes 5 seconds on average. This initial process is necessary because the MFT is often fragmented and when I process an ATTRIBUTE_LIST I find references to MFT entries that have not yet been examined but to which access is required to extract names and dates from ATTRIBUTE_FILE_NAME.
Finally I have also added the option to copy files avoiding the restrictions of the OS, which is very convenient because you can copy restricted or protected files like MFT or UsnJrnl.
The methods used are obtained from KERNEL32.DLL library: GetVolumeInformationByHandleW, ReadFile, CreateFile, SetFilePointerEx, GetFileInformationByHandle, DeviceIoControl.
- Some have ceased to be free.
- Some are very large in size and slow.
- I want to learn seriously the architecture of the MFT.
- I want to learn c#.
- Just for fun.
The method I have used to speed things up is to create a dictionary using the enumeration of the MFT with FSCTL_ENUM_USN_DATA and including the offset of the MFT records in it.
This process, in an old system with a partition of 400 Gb with 300k objects, takes 5 seconds on average. This initial process is necessary because the MFT is often fragmented and when I process an ATTRIBUTE_LIST I find references to MFT entries that have not yet been examined but to which access is required to extract names and dates from ATTRIBUTE_FILE_NAME.
Finally I have also added the option to copy files avoiding the restrictions of the OS, which is very convenient because you can copy restricted or protected files like MFT or UsnJrnl.
The methods used are obtained from KERNEL32.DLL library: GetVolumeInformationByHandleW, ReadFile, CreateFile, SetFilePointerEx, GetFileInformationByHandle, DeviceIoControl.
7 Nov 2012
Esta entrada va a ser un repaso del funcionamiento del LastAccessUpdate de los archivos a cuenta de que me lo he encontrado al revisar un registro. El valor en concreto es el que establece si debe actualizarse el atributo Last Access Time del sistema de archivos.
La descripción de la clave y valor del registro la he encontrado en:
http://msdn.microsoft.com/en-us/library/ee377058%28v=bts.10%29.aspx
NTFSDisableLastAccessUpdate
Me parece muy importante destacar que el valor por defecto es 0 en XP pero 1 en Vista/7.
Parece que este valor ha generado mucha discusión en los foros ya que se afirma en muchos de ellos que el S.O. no actualiza el valor de LastAccessUpdate como debiera.
Creo que la confusión puede deberse en muchos casos al hecho de que ese valor no se actualiza de forma instantanea siempre que se accede a un archivo o directorio: la actualización depende de si el acceso es de solo lectura o no. Si es éste el caso no se actualiza de forma inmediata precisamente para evitar que todas las operaciones se conviertan en accesos de escritura, degradando el rendimiento del sistema.
Donde sí se actualiza es en memoria y se vuelca ese valor si se modifica otro atributo del archivo o si desaparece la referencia de la memoria. El retraso máximo que el sistema acepta para actualizar el valor es de una hora por lo que si leemos un archivo a las 14:00 y de nuevo a las 14:50 el sistema no lo actualiza. Si volvemos a leerlo a las 15:01 sí se actualiza el valor en disco para reflejar las 15:01.
El otro lugar donde se almacena el LastAccessUpdate de un archivo es en el índice del directorio. En este caso el sistema solo actualiza el valor cuando detecta que la diferencia entre el valor en el índice y el almacenado en memoria difieren en más de una hora, lo que ocurre cuando se elimina la referencia al mismo. También cuando se modifica otro de los atributos del archivo se actualiza el LastAccessUpdate con el valor que estaba en memoria. (Fuente: http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/fsutil_behavior.mspx?mfr=true)
Como digo puede que se deba a esto pero no lo he comprobado personalmente.
Un ejemplo de malware que modifica este valor:
W32/Virut.n.gen!D4F31486AF8E
(http://www.mcafee.com/threat-intelligence/malware/default.aspx?id=317086)
La descripción de la clave y valor del registro la he encontrado en:
http://msdn.microsoft.com/en-us/library/ee377058%28v=bts.10%29.aspx
NTFSDisableLastAccessUpdate
| Key: | HKLM\SYSTEM\CurrentControlSet\Control\FileSystem |
| Value: | NTFSDisableLastAccessUpdate |
| Data Type: | REG_DWORD |
| Range: | 0 – 1 |
| Default value: | 0 |
| Recommended value: | 1 |
| Value exists by default? | No, needs to be added. |
Me parece muy importante destacar que el valor por defecto es 0 en XP pero 1 en Vista/7.
Parece que este valor ha generado mucha discusión en los foros ya que se afirma en muchos de ellos que el S.O. no actualiza el valor de LastAccessUpdate como debiera.
Creo que la confusión puede deberse en muchos casos al hecho de que ese valor no se actualiza de forma instantanea siempre que se accede a un archivo o directorio: la actualización depende de si el acceso es de solo lectura o no. Si es éste el caso no se actualiza de forma inmediata precisamente para evitar que todas las operaciones se conviertan en accesos de escritura, degradando el rendimiento del sistema.
Donde sí se actualiza es en memoria y se vuelca ese valor si se modifica otro atributo del archivo o si desaparece la referencia de la memoria. El retraso máximo que el sistema acepta para actualizar el valor es de una hora por lo que si leemos un archivo a las 14:00 y de nuevo a las 14:50 el sistema no lo actualiza. Si volvemos a leerlo a las 15:01 sí se actualiza el valor en disco para reflejar las 15:01.
El otro lugar donde se almacena el LastAccessUpdate de un archivo es en el índice del directorio. En este caso el sistema solo actualiza el valor cuando detecta que la diferencia entre el valor en el índice y el almacenado en memoria difieren en más de una hora, lo que ocurre cuando se elimina la referencia al mismo. También cuando se modifica otro de los atributos del archivo se actualiza el LastAccessUpdate con el valor que estaba en memoria. (Fuente: http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/fsutil_behavior.mspx?mfr=true)
Como digo puede que se deba a esto pero no lo he comprobado personalmente.
Un ejemplo de malware que modifica este valor:
W32/Virut.n.gen!D4F31486AF8E
(http://www.mcafee.com/threat-intelligence/malware/default.aspx?id=317086)
21 Oct 2012
NTFS $MFT slack
Hal Pomeranz ha publicado en SANS Computer Forensics un artículo muy interesante sobre la posibilidad de recuperar datos del slack de las entradas de la MFT.
Se trata de la información que queda residente en la entrada de la MFT en el atributo $DATA cuando ésta pasa de ser residente a no residente.
Para la comprobación se sugiere en el artículo probar con una extensión de datos del archivo inferior a 700 bytes de forma que sea residente y posteriormente ampliar su tamaño para comprobar los datos residuales que quedan en la entrada de la MFT.
Referencia: Resident $DATA Residue in NTFS MFT Entries
Se trata de la información que queda residente en la entrada de la MFT en el atributo $DATA cuando ésta pasa de ser residente a no residente.
Para la comprobación se sugiere en el artículo probar con una extensión de datos del archivo inferior a 700 bytes de forma que sea residente y posteriormente ampliar su tamaño para comprobar los datos residuales que quedan en la entrada de la MFT.
Referencia: Resident $DATA Residue in NTFS MFT Entries
NTFS INDX Buffers
Acaban de publicar en el blog de Mandiant la cuarta entrega dedicada a los NTFS Index Buffers:
The Internal Structures of an INDX Attribute.
Se trata de una descripción de la estructura y comportamiento de los B+Tree que ayuda a entender este concepto. Es un buen complemento para entender el follón de ese tipo de estructura que se añade a las lecturas:
The Internal Structures of an INDX Attribute.
Se trata de una descripción de la estructura y comportamiento de los B+Tree que ayuda a entender este concepto. Es un buen complemento para entender el follón de ese tipo de estructura que se añade a las lecturas:
- El libro de Brian Carrier: File System Forensic Analysis
- La herramienta INDXparse de Willi Ballenthin: INDXparse.
- Del blog de SANS Computer Forensics el artículo de Chad Tilbury: NTFS $I30 Index Attributes: Evidence of Deleted and Overwritten Files
- La herramienta wisp de TZWorks.
Subscribe to:
Posts (Atom)