mirror of
https://github.com/carlospolop/hacktricks.git
synced 2023-12-14 19:12:55 +01:00
GitBook: [master] 4 pages modified
This commit is contained in:
CPol
gitbook-bot
parent
187ef3bb0b
commit
e3d70ee2c9
|
|
@ -424,6 +424,8 @@
|
|||
* [Wireshark tricks](forensics/pcaps-analysis/wireshark-tricks.md)
|
||||
* [Volatility - CheatSheet](forensics/volatility-examples.md)
|
||||
* [Basic Forensics \(ESP\)](forensics/basic-forensics-esp/README.md)
|
||||
* [Partitions/File Systems/Carving](forensics/basic-forensics-esp/partitions-file-systems-carving/README.md)
|
||||
* [NTFS](forensics/basic-forensics-esp/partitions-file-systems-carving/ntfs.md)
|
||||
* [Windows Forensics](forensics/basic-forensics-esp/windows-forensics/README.md)
|
||||
* [Interesting Windows Registry Keys](forensics/basic-forensics-esp/windows-forensics/interesting-windows-registry-keys.md)
|
||||
* [Anti-Forensic Techniques](forensics/basic-forensics-esp/anti-forensic-techniques.md)
|
||||
|
|
|
|||
|
|
@ -1,12 +1,6 @@
|
|||
# Basic Forensics \(ESP\)
|
||||
|
||||
* **Collect**
|
||||
* **Preserve**
|
||||
* **Analyze**
|
||||
* **Present**
|
||||
|
||||
Cuando hagas reboot a una máquina afectada hay que iniciarla desde nuestro propio USB booteado. Pues usar el SO de la maquina modificara metadata de algunos archivos \(como access time\) y las herramientas de dicha máquina no son confiables.
|
||||
|
||||
*
|
||||
**Linux/Unix**
|
||||
|
||||
En linux cualquier cosa es un archivo. Por ejemplo la RAM es un archivo llamado **/dev/mem**
|
||||
|
|
@ -36,39 +30,7 @@ En linux cualquier cosa es un archivo. Por ejemplo la RAM es un archivo llamado
|
|||
|
||||
Toda la info obtenida de la máquina infectada NO debe ser guardada en la máquina sino enviada a otra con **netcat**
|
||||
|
||||
### **MemoryDump**
|
||||
|
||||
#### **memdmp**
|
||||
|
||||
**Linux Memory Extractor \(LiME\)** —> Kernel module —> Descargar de git y hacer make —> **insmod ./lime-3.13.0-44-generic.ko "path=/home/sansforensics/Desktop/mem\_dump.bin format=padded"** —> Inserta el modulo en el kernel el cual puede ser visto con **lsmod** —> **rmmod lime** —> Para eliminarlo
|
||||
**strings -n 8 mem\_dump.bin** —> Da todas las strings de tamaño igual o superior a 8
|
||||
**Fmem** —> Kernel Module
|
||||
live response from **E-FENSE** —> Insertar un USB y vas seleccionando los datos que quieres
|
||||
**F-Response** —> Remotely
|
||||
|
||||
### **Copy Hard Drive**
|
||||
|
||||
**DD —>** Coge bloques de memoria, les aplica el cambio que necesita y los coloca en su sitio. Por defecto bloques de 512B
|
||||
|
||||
**dd if=INPUT\_FILE of=OUTPUT\_FILE bs=Nk \(N es el numero de Kilobytes\)** —> Un bs mayor de 8KB puede hacer que vaya más lento
|
||||
**count=s** —> s es el numero de bloques a copiar
|
||||
**skip=n** —> n es el numero de bloques de los que pasar
|
||||
**seek=n** —> n es el número de de bloques del outputfile
|
||||
|
||||
Un problema con DD es que no da feedback y si encuentra un error se queda parado sin que tu lo sepas \(una seccion no puede leerla y se para\) para eso se puede usar:
|
||||
|
||||
**conv=noerror,sync** —> Pasa de los errores y sigue y rellena con 0s lo que no pudo copiar
|
||||
**dd if=/dev/zero of=/dev/hdb** —> Lo pone a cero \(3-7 veces para dejarlo limpio\)
|
||||
**dd if=/dev/zero of/path/file count=1** —> Si no ponemos un count nunca parará de copiar 0s
|
||||
**dd if=/dev/hdb of=/dev/hda** —> Hay que tener cuidado pues lo que sobre del disco serán 0s y esto hará que el hash sea distinto. Hay que averiguar el número de bloques para calcular el hash solo de ese número de bloques
|
||||
**dd if=/dev/hda of=/cas1/evidence.dd**
|
||||
**ssh** [**pi@10.10.10.48**](mailto:pi@10.10.10.48) **“sudo dcfldd if=/dev/sbd \| gzip -1 -” \| dcfldd of=pi.dd.gz**
|
||||
**Forensic listen: nc -l -p 8888 > /dev/hdg**
|
||||
**Infected device: dd if/dev/hda \| nc IPADDR 8888 -w 3** —> La opción w le dice que si no se envía nada en 3 segundo, se desconecta
|
||||
DD no checkea hashes, hay que hacerlo de forma manual
|
||||
**sdd** —> DD para forensia, da más datos y puede ser un poco más rápido
|
||||
|
||||
[http://malwarefieldguide.com/LinuxChapter1.html](http://malwarefieldguide.com/LinuxChapter1.html)
|
||||
### \*\*\*\*
|
||||
|
||||
### **BOOT LINUX**
|
||||
|
||||
|
|
@ -155,247 +117,7 @@ Un Soft link tendrá distinto INODE y solo guardará la información de a qué a
|
|||
| /usr | Programs, libraries, documentation etc. for all user-related programs. |
|
||||
| /var | Storage for all variable files and temporary files created by users, such as log files, the mail queue, the print spooler area, space for temporary storage of files downloaded from the Internet, or to keep an image of a CD before burning it. |
|
||||
|
||||
**Sleuthkit y Autopsy**
|
||||
|
||||
Lo primero que tenemos que hacer es encontrar el inicio de la partición. Para eso podemos usar **fdisk** o **mmls**. **mmls PATH\_IMAGEN** \(mmls da la info en base a bloques de 512B y fdisk da la info en base a cilindros, se suele usar mmls porque te interesan los Bytes para sleuthkit\)
|
||||
|
||||
De esta forma encontramos el offset en la que comienza el SO. Conociendo en offset con el que empieza podemos empezar a usar Sleuthkit.
|
||||
|
||||
Con **fsstat** podemos encontrar el tipo de partición que es. **fsstat -o OFFSET IMAGEN**
|
||||
|
||||
**fls -o OFFSET -f FS\_TYPE -m “/“ -r PATH\_IMAGEN > flsBody** —> Da todos los archivos encontrados que aun tienen el nombre puesto desde / en formato MACTIME
|
||||
|
||||
**ils -o OFFSET -f FS\_TYPE -m PATH\_IMAGEM > ilsBody** —> Da todos los INODES que encuentra en formato MACTIME
|
||||
|
||||
Autopsy es la GUI de Sleuth Kit.
|
||||
|
||||
Los SDD complican el rescatar información.
|
||||
|
||||
File system layer tools start with **FS**
|
||||
|
||||
File name layer tools starts with **F**
|
||||
|
||||
Metadata layer tools strat with **I**
|
||||
|
||||
Data layer tools start with **BLK**
|
||||
|
||||
Todos los comandos necesitan por lo menos el nombre de la imagen:
|
||||
|
||||
**-f <fs\_type>** —> EXT2,3 FAT12,16,32…
|
||||
|
||||
**-o imgoffset** —> Sector offset where the file system starts in the image
|
||||
|
||||
**BLK —>Block**
|
||||
|
||||
**blkstat** —> Muestra información del bloque \(como si está allocated\)
|
||||
|
||||
**blkstat -f ext2 myImage.img 300** —> Muestra info del bloque 300
|
||||
|
||||
**blkls** —> Muestra toda la Unallocated Data \(útil para recuperar info\)
|
||||
|
||||
**-e** —> Lista todos los datos
|
||||
|
||||
**-s** —> liste the slack \(ntfs o fat\)
|
||||
|
||||
**blkcat** —> Muestra el contenido de un bloque
|
||||
|
||||
**-h** -> Para mostrarlo en hexadecimal
|
||||
|
||||
**blkcat -f ext2 myImage.img 200** —> Muestra lo que hay en el bloque 200
|
||||
|
||||
I **—> INODE\(Meta data\)**
|
||||
|
||||
**istat** —> Info de un INODE: INODE number, mac time, permission, file size, allocation status o allocated data blocks number, number of links…
|
||||
|
||||
**istat -f ext2 myImage.img INODENUMBER**
|
||||
|
||||
**ifind** —> De un block number a un INODE number. Si encuentras un bloque interesante así puedes encontrar los demás.
|
||||
|
||||
**ifind -f ext2 -d DATABLOCKNUMBER myImage.img**
|
||||
|
||||
**ils** —> List all inodes and info. Included deleted files and unlinked but opened files
|
||||
|
||||
Por defecto solo muestra los de archivos borrados
|
||||
|
||||
**-e** —> Muestra todos
|
||||
|
||||
**-m** —> crea un archivo para MACTIME —> Organiza el resultado y presenta un timeline de actividades. Pone un 127 al INODE si ela rchivo ha sido borrado.
|
||||
|
||||
**-o** —> Open but no filename
|
||||
|
||||
**-z** —> INODE with zero status time change \(never used\)
|
||||
|
||||
**icat** —> Dada la imagen sospechosa y el INODE, saca el contenido, puede recuperar archivos perdidos. Debemos encontrar el INODE number con ils.
|
||||
|
||||
**icat -f ext2 /image 20**
|
||||
|
||||
**F —> File name**
|
||||
|
||||
**fls** —> Lista los nombres y subdirs de un directorio. Por defecto los del root. Deleted files have a \* before them. Si el nombre fue sobreescrito, no lo encontrará, pero ILS sí.
|
||||
|
||||
**-a** —> Display all
|
||||
|
||||
**-d** —> Deleted only
|
||||
|
||||
**-u** —> undeleted
|
||||
|
||||
**-D** —> Directories
|
||||
|
||||
**-F** —> File entries only
|
||||
|
||||
**-r** —> Recursive on subdirs
|
||||
|
||||
**-p** —> Full path
|
||||
|
||||
**-m output** —> TIMELINE format
|
||||
|
||||
**-l** —> Long version information
|
||||
|
||||
**-s** —> Skew in seconds combined with -l and/or -m
|
||||
|
||||
**fls -r image 12**
|
||||
|
||||
**fls -f ext3 -m “/” -r imaes/root.dd**
|
||||
|
||||
**fls -o 2048 -f ext2 -m "/" -r '/home/sansforensics/Desktop/LinuxFinancialCase.001' > flsBody**
|
||||
|
||||
**ffind** —> Filename de un INODE. Busca por todas partes hasta encontrar a qué filename apunta el INODE
|
||||
|
||||
**-a** —> Coge todos los nombres que apuntan al INODE
|
||||
|
||||
**ffind -f ext2 myImage.img INODENUMBER**
|
||||
|
||||
**Mount -o ro,loop /my\_hda1.dd /mnt/hacked** —> Siempre se debe montar con ro \(read only\), loop es por si lo que montas no es un disco sino un archivo \(una imagen por ejemplo\)
|
||||
|
||||
**MACTIME:**
|
||||
|
||||
**M** —> Last time files data block changed \(Modification\)
|
||||
|
||||
**A** —> Last time files data block accessed \(Access\)
|
||||
|
||||
**C** —> Last time inodes content changed \(in windows, this is creation time\) \(Change time\)
|
||||
|
||||
**mactime -b FLSbodymac -d > MACtimeFLS.csv**
|
||||
|
||||
En linux usar **touch** modifica los 2 primeros. En windows hay un programa que modifica los 3 \(todo se modifica muy facilmente\).
|
||||
|
||||
**touch -a -d ‘2017-01-03 08:46:23’ FILE** —> Modifica el access según la hora dada
|
||||
|
||||
Comando **stat** da los tres valores MAC del archivo.
|
||||
|
||||
Conseguir el archivo en formato MACTIME
|
||||
|
||||
**fls -f ext3 -m “/“ -r images/root.dd > data/body**
|
||||
|
||||
**ils -f openbsd -m images/root.dd > data/body**
|
||||
|
||||
Binary files modified in 1 day: **find /directory\_path -type f -a=x -mtime -1 -print**
|
||||
|
||||
Files created in 1 day: **find /directory\_path -type f -a=x -bmin -24 -print**
|
||||
|
||||
Se pueden guardar todo el raw data unallocated de la imagen usando dls myImage > unallocated \(el contenido de estos datos puede ser cualquier cosa: .jpeg, .pdf …\)
|
||||
|
||||
Se puede saber qué datos son usando programas de data carving \(se basan en headers, footers para saber que tipo de archivo es, dónde empieza y dónde acaba\).
|
||||
|
||||
Data carving tools: **Foremost, Scalpel, Magic Rescue, Photorec, TestDisk, etc**
|
||||
|
||||
**Foremost**
|
||||
|
||||
Para user Foremost tenemos que ir a su archivo de configuración \(find / -name foremost.comf\) y descomentar las líneas de los tipos de archivo que nos interesen.
|
||||
|
||||
**foremost -c fremost.conf -T -i FILE** \(La T es para que vaya asginando nombres unicos\)
|
||||
|
||||
**BOOTABLES**
|
||||
|
||||
CAINE
|
||||
|
||||
HELIXS/HELIX3 PRO
|
||||
|
||||
KALI
|
||||
|
||||
PENGUIN SLEUTH
|
||||
|
||||
F.I.R.E
|
||||
|
||||
SNARL
|
||||
|
||||
**BUILT-IN FUNCTIONALITIES**
|
||||
|
||||
Deleted file recovery
|
||||
|
||||
Keyword search
|
||||
|
||||
Hash Analysis
|
||||
|
||||
Data carving
|
||||
|
||||
Graphic view
|
||||
|
||||
Email view
|
||||
|
||||
**Analysis procedure**
|
||||
|
||||
Create a case
|
||||
|
||||
Add evidence to a case
|
||||
|
||||
Perform throrough analysis
|
||||
|
||||
Obtain basic analysis data
|
||||
|
||||
Export files
|
||||
|
||||
Generate report
|
||||
|
||||
**WINDOWS**
|
||||
|
||||
**Volatile Information**
|
||||
|
||||
System Information
|
||||
|
||||
Processes information
|
||||
|
||||
Network information
|
||||
|
||||
Logged on users
|
||||
|
||||
Clipboard contents
|
||||
|
||||
Command history - doskey/history
|
||||
|
||||
MACTime
|
||||
|
||||
Comandos para obtener esta info:
|
||||
|
||||
date /T; time /T
|
||||
|
||||
uptime
|
||||
|
||||
ipconfig
|
||||
|
||||
tasklist /svc
|
||||
|
||||
openfiles
|
||||
|
||||
netstat
|
||||
|
||||
**Helix:**
|
||||
|
||||
Primer apartado: Info del sistema
|
||||
|
||||
Procesos corriendo
|
||||
|
||||
Segundo apartado: Permite crear copias del disco y memoria, primero usando **dd** \(mejor usar os otros\)
|
||||
|
||||
En la segunda página usando **FTK imager**
|
||||
|
||||
Es la tercera página, RAM usando **Winen** o **MDD**
|
||||
|
||||
Tercer apartado: Incident response
|
||||
|
||||
Cuarto apartado: Navegación por el disco, no usar mucho porque cambian los tiempos de acceso
|
||||
|
||||
Quinto apartado: Saca todas las imagenes
|
||||
\*\*\*\*
|
||||
|
||||
**Cold Boot Attack:**
|
||||
|
||||
|
|
@ -411,13 +133,7 @@ El ataque cold boot consiste en que la memoria RAM no se elimina en cuanto se ap
|
|||
|
||||
3\) El USB ha copiado la memoria
|
||||
|
||||
**High speed forensics imagers**
|
||||
|
||||
Logicube’s Forensic Falcon —> 30GB por minuto
|
||||
|
||||
Mediaclone’s Superimager —> de 29 a 31 GB por minuto
|
||||
|
||||
En Windows un Block es llamado Cluster. En este sistema operativo cuando un cluster no se llena el espacio vacio se queda sin usar, lo cual es util pues puede contener datos eliminados. En linux la parte que no se llena de un block se rellena con ceros.
|
||||
\*\*\*\*
|
||||
|
||||
|
||||
|
||||
|
|
@ -433,405 +149,5 @@ recuperacion de datos: [https://github.com/Claudio-C/awesome-datarecovery](https
|
|||
|
||||
|
||||
|
||||
## Partitions
|
||||
|
||||
A hard drive or a **SSD disk can contain different partitions** with the goal of separating data physically.
|
||||
The **minimum** unit of a disk is the **sector** \(normally composed by 512B\). So, each partition size needs to be multiple of that size.
|
||||
|
||||
### MBR \(master Boot Record\)
|
||||
|
||||
It's allocated in the **first sector of the disk after the 446B of the boot code**. It contains the **partitions** table \(there can be up to **4 primary partitions**\). The **final byte** of this first sector is the boot record signature **0x55AA**. Only one partition can be marked as active.
|
||||
MBR allows **max 2.2TB**.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
From the **bytes 440 to the 443** of the MBR you can find the **Windows Disk Signature** \(if Windows is used\). The logical drive letters of the hard disk depend on the Windows Disk Signature. Changing this signature could prevent Windows from booting.
|
||||
|
||||
|
||||
|
||||
#### LBA \(Logical block addressing\)
|
||||
|
||||
**Logical block addressing** \(**LBA**\) is a common scheme used for **specifying the location of blocks** of data stored on computer storage devices, generally secondary storage systems such as hard disk drives. LBA is a particularly simple linear addressing scheme; **blocks are located by an integer index**, with the first block being LBA 0, the second LBA 1, and so on.
|
||||
|
||||
### GPT \(GUID Partition Table\)
|
||||
|
||||
It’s called GUID Partition Table because every partition on your drive has a **globally unique identifier**.
|
||||
|
||||
Just like MBR it starts in the **sector 0**. The MBR occupies 32bits while **GPT** uses **64bits**.
|
||||
GPT **allows up to 128 partitions** in Windows and up to **9.4ZB**.
|
||||
Also, partitions can have a 36 character Unicode name.
|
||||
|
||||
On an MBR disk, the partitioning and boot data is stored in one place. If this data is overwritten or corrupted, you’re in trouble. In contrast, **GPT stores multiple copies of this data across the disk**, so it’s much more robust and can recover if the data is corrupted.
|
||||
|
||||
GPT also stores **cyclic redundancy check \(CRC\)** values to check that its data is intact. If the data is corrupted, GPT can notice the problem and **attempt to recover the damaged data** from another location on the disk.
|
||||
|
||||
#### Protective MBR \(LBA0\)
|
||||
|
||||
For limited backward compatibility, the space of the legacy MBR is still reserved in the GPT specification, but it is now used in a **way that prevents MBR-based disk utilities from misrecognizing and possibly overwriting GPT disks**. This is referred to as a protective MBR.
|
||||
|
||||
|
||||
|
||||
#### Hybrid MBR \(LBA 0 + GPT\)
|
||||
|
||||
In operating systems that support **GPT-based boot through BIOS** services rather than EFI, the first sector may also still be used to store the first stage of the **bootloader** code, but **modified** to recognize **GPT** **partitions**. The bootloader in the MBR must not assume a sector size of 512 bytes.
|
||||
|
||||
#### Partition table header \(LBA 1\)
|
||||
|
||||
The partition table header defines the usable blocks on the disk. It also defines the number and size of the partition entries that make up the partition table \(offsets 80 and 84 in the table\).
|
||||
|
||||
| Offset | Length | Contents |
|
||||
| :--- | :--- | :--- |
|
||||
| 0 \(0x00\) | 8 bytes | Signature \("EFI PART", 45h 46h 49h 20h 50h 41h 52h 54h or 0x5452415020494645ULL[ ](https://en.wikipedia.org/wiki/GUID_Partition_Table#cite_note-8)on little-endian machines\) |
|
||||
| 8 \(0x08\) | 4 bytes | Revision 1.0 \(00h 00h 01h 00h\) for UEFI 2.8 |
|
||||
| 12 \(0x0C\) | 4 bytes | Header size in little endian \(in bytes, usually 5Ch 00h 00h 00h or 92 bytes\) |
|
||||
| 16 \(0x10\) | 4 bytes | [CRC32](https://en.wikipedia.org/wiki/CRC32) of header \(offset +0 up to header size\) in little endian, with this field zeroed during calculation |
|
||||
| 20 \(0x14\) | 4 bytes | Reserved; must be zero |
|
||||
| 24 \(0x18\) | 8 bytes | Current LBA \(location of this header copy\) |
|
||||
| 32 \(0x20\) | 8 bytes | Backup LBA \(location of the other header copy\) |
|
||||
| 40 \(0x28\) | 8 bytes | First usable LBA for partitions \(primary partition table last LBA + 1\) |
|
||||
| 48 \(0x30\) | 8 bytes | Last usable LBA \(secondary partition table first LBA − 1\) |
|
||||
| 56 \(0x38\) | 16 bytes | Disk GUID in mixed endian |
|
||||
| 72 \(0x48\) | 8 bytes | Starting LBA of array of partition entries \(always 2 in primary copy\) |
|
||||
| 80 \(0x50\) | 4 bytes | Number of partition entries in array |
|
||||
| 84 \(0x54\) | 4 bytes | Size of a single partition entry \(usually 80h or 128\) |
|
||||
| 88 \(0x58\) | 4 bytes | CRC32 of partition entries array in little endian |
|
||||
| 92 \(0x5C\) | \* | Reserved; must be zeroes for the rest of the block \(420 bytes for a sector size of 512 bytes; but can be more with larger sector sizes\) |
|
||||
|
||||
#### Partition entries \(LBA 2–33\)
|
||||
|
||||
| GUID partition entry format | | |
|
||||
| :--- | :--- | :--- |
|
||||
| Offset | Length | Contents |
|
||||
| 0 \(0x00\) | 16 bytes | [Partition type GUID](https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs) \(mixed endian\) |
|
||||
| 16 \(0x10\) | 16 bytes | Unique partition GUID \(mixed endian\) |
|
||||
| 32 \(0x20\) | 8 bytes | First LBA \([little endian](https://en.wikipedia.org/wiki/Little_endian)\) |
|
||||
| 40 \(0x28\) | 8 bytes | Last LBA \(inclusive, usually odd\) |
|
||||
| 48 \(0x30\) | 8 bytes | Attribute flags \(e.g. bit 60 denotes read-only\) |
|
||||
| 56 \(0x38\) | 72 bytes | Partition name \(36 [UTF-16](https://en.wikipedia.org/wiki/UTF-16)LE code units\) |
|
||||
|
||||
#### Partitions Types
|
||||
|
||||
|
||||
|
||||
More partition types in [https://en.wikipedia.org/wiki/GUID\_Partition\_Table](https://en.wikipedia.org/wiki/GUID_Partition_Table)
|
||||
|
||||
### Inspecting
|
||||
|
||||
After mounting the forensics image with [**ArsenalImageMounter**](https://arsenalrecon.com/downloads/), you can inspect the first sector using the Windows tool [**Active Disk Editor**](https://www.disk-editor.org/index.html)**.** In the following image a **MBR** was detected on the **sector 0** and interpreted:
|
||||
|
||||
|
||||
|
||||
If it was a **GPT table instead of a MBR** it should appear the signature _EFI PART_ in the **sector 1** \(which in the previous image is empty\).
|
||||
|
||||
## File-Systems
|
||||
|
||||
### Windows file-systems list
|
||||
|
||||
* **FAT12/16**: MSDOS, WIN95/98/NT/200
|
||||
* **FAT32**: 95/2000/XP/2003/VISTA/7/8/10
|
||||
* **ExFAT**: 2008/2012/2016/VISTA/7/8/10
|
||||
* **NTFS**: XP/2003/2008/2012/VISTA/7/8/10
|
||||
* **ReFS**: 2012/2016
|
||||
|
||||
### FAT
|
||||
|
||||
The **FAT \(File Allocation Table\)** file system is named for its method of organization, the file allocation table, which resides at the beginning of the volume. To protect the volume, **two copies** of the table are kept, in case one becomes damaged. In addition, the file allocation tables and the root folder must be stored in a **fixed location** so that the files needed to start the system can be correctly located.
|
||||
|
||||
|
||||
|
||||
The minimum space unit used by this file-system is a **cluster, typically 512B** \(which is composed by a number of sectors\).
|
||||
|
||||
The earlier **FAT12** had a **cluster addresses to 12-bit** values with up to **4078** **clusters**; it allowed up to 4084 clusters with UNIX. The more efficient **FAT16** increased to **16-bit** cluster address allowing up to **65,517 clusters** per volume. FAT32 uses 32-bit cluster address allowing up to **268,435,456 clusters** per volume
|
||||
|
||||
The **maximum file-size allowed by FAT is 4GB** \(minus one byte\) because the file system uses a 32-bit field to store the file size in bytes, and 2^32 bytes = 4 GiB. This happens for FAT12, FAT16 and FAT32.
|
||||
|
||||
The **root directory** occupies a **specific position** for both FAT12 and FAT16 \(in FAT32 it occupies a position like any other folder\). Each file/folder entry contains this information:
|
||||
|
||||
* Name of the file/folder \(8 chars max\)
|
||||
* Attributes
|
||||
* Date of creation
|
||||
* Date of modification
|
||||
* Date of last access
|
||||
* Address of the FAT table where the first cluster of the file starts
|
||||
* Size
|
||||
|
||||
When a file is "deleted" using a FAT file system, the directory entry remains almost **unchanged** except for the **first character of the file name** \(modified to ****0xE5\), preserving most of the "deleted" file's name, along with its time stamp, file length and — most importantly — its physical location on the disk. The list of disk clusters occupied by the file will, however, be erased from the File Allocation Table, marking those sectors available for use by other files created or modified thereafter. In case of FAT32, it is additionally erased field responsible for upper 16 bits of file start cluster value.
|
||||
|
||||
### **NTFS**
|
||||
|
||||
**NTFS** \(**New Technology File System**\) is a proprietary journaling file system developed by Microsoft.
|
||||
|
||||
The cluster is the minimum size unit of NTFS and the size of the cluster depends on the size of a partition.
|
||||
|
||||
| Partition size | Sectors per cluster | Cluster size |
|
||||
| :--- | :--- | :--- |
|
||||
| 512MB or less | 1 | 512 bytes |
|
||||
| 513MB-1024MB \(1GB\) | 2 | 1KB |
|
||||
| 1025MB-2048MB \(2GB\) | 4 | 2KB |
|
||||
| 2049MB-4096MB \(4GB\) | 8 | 4KB |
|
||||
| 4097MB-8192MB \(8GB\) | 16 | 8KB |
|
||||
| 8193MB-16,384MB \(16GB\) | 32 | 16KB |
|
||||
| 16,385MB-32,768MB \(32GB\) | 64 | 32KB |
|
||||
| Greater than 32,768MB | 128 | 64KB |
|
||||
|
||||
#### **Slack-Space**
|
||||
|
||||
As the **minimum** size unit of NTFS is a **cluster**. Each file will be occupying a number of complete clusters. Then, it's highly probable that **each file occupies more space than necessary**. These **unused** **spaces** **booked** by a file which is called **slacking** **space**. And people could take advantage of this technique to **hide** **information**.
|
||||
|
||||
|
||||
|
||||
#### **NTFS boot sector**
|
||||
|
||||
When you format an NTFS volume, the format program allocates the first 16 sectors for the $Boot metadata file. First sector, in fact, is a boot sector with a "bootstrap" code and the following 15 sectors are the boot sector's IPL \(initial program loader\). To increase file system reliability the very last sector an NTFS partition contains a spare copy of the boot sector.
|
||||
|
||||
#### **Master File Table o $MFT**
|
||||
|
||||
The NTFS file system contains a file called the _master file table_, or MFT. There is at least **one entry in the MFT for every file on an NTFS file system** volume, including the MFT itself. All information about a file, including its **size, time and date stamps, permissions, and data content**, is stored either in MFT entries, or in space outside the MFT that is described by MFT entries.
|
||||
|
||||
As **files are added** to an NTFS file system volume, more entries are added to the MFT and the **MFT increases in size**. When **files** are **deleted** from an NTFS file system volume, their **MFT entries are marked as free** and may be reused. However, disk space that has been allocated for these entries is not reallocated, and the size of the MFT does not decrease.
|
||||
|
||||
The NTFS file system **reserves space for the MFT to keep the MFT as contiguous as possible** as it grows. The space reserved by the NTFS file system for the MFT in each volume is called the **MFT zone**. Space for file and directories are also allocated from this space, but only after all of the volume space outside of the MFT zone has been allocated.
|
||||
|
||||
Depending on the average file size and other variables, **either the reserved MFT zone or the unreserved space on the disk may be allocated first as the disk fills to capacity**. Volumes with a small number of relatively large files will allocate the unreserved space first, while volumes with a large number of relatively small files allocate the MFT zone first. In either case, fragmentation of the MFT starts to take place when one region or the other becomes fully allocated. If the unreserved space is completely allocated, space for user files and directories will be allocated from the MFT zone. If the MFT zone is completely allocated, space for new MFT entries will be allocated from the unreserved space.
|
||||
|
||||
NTFS file systems also generate a **$MFTMirror**. This is a **copy** of the **first 4 entries** of the MFT: $MFT, $MFT Mirror, $Log, $Volume.
|
||||
|
||||
NTFS reserves the first 16 records of the table for special information:
|
||||
|
||||
| System File | File Name | MFT Record | Purpose of the File |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| Master file table | $Mft | 0 | Contains one base file record for each file and folder on an NTFS volume. If the allocation information for a file or folder is too large to fit within a single record, other file records are allocated as well. |
|
||||
| Master file table 2 | $MftMirr | 1 | A duplicate image of the first four records of the MFT. This file guarantees access to the MFT in case of a single-sector failure. |
|
||||
| Log file | $LogFile | 2 | Contains a list of transaction steps used for NTFS recoverability. Log file size depends on the volume size and can be as large as 4 MB. It is used by Windows NT/2000 to restore consistency to NTFS after a system failure. |
|
||||
| Volume | $Volume | 3 | Contains information about the volume, such as the volume label and the volume version. |
|
||||
| Attribute definitions | $AttrDef | 4 | A table of attribute names, numbers, and descriptions. |
|
||||
| Root file name index | $ | 5 | The root folder. |
|
||||
| Cluster bitmap | $Bitmap | 6 | A representation of the volume showing which clusters are in use. |
|
||||
| Boot sector | $Boot | 7 | Includes the BPB used to mount the volume and additional bootstrap loader code used if the volume is bootable. |
|
||||
| Bad cluster file | $BadClus | 8 | Contains bad clusters for the volume. |
|
||||
| Security file | $Secure | 9 | Contains unique security descriptors for all files within a volume. |
|
||||
| Upcase table | $Upcase | 10 | Converts lowercase characters to matching Unicode uppercase characters. |
|
||||
| NTFS extension file | $Extend | 11 | Used for various optional extensions such as quotas, reparse point data, and object identifiers. |
|
||||
| | | 12-15 | Reserved for future use. |
|
||||
| Quota management file | $Quota | 24 | Contains user assigned quota limits on the volume space. |
|
||||
| Object Id file | $ObjId | 25 | Contains file object IDs. |
|
||||
| Reparse point file | $Reparse | 26 | This file contains information about files and folders on the volume include reparse point data. |
|
||||
|
||||
#### Each entry of the MFT looks like the following:
|
||||
|
||||
|
||||
|
||||
Note how each entry starts with "FILE". Each entry occupies 1024 bits. So after 1024 bit from the start of a MFT entry you will find the next one.
|
||||
|
||||
Using the [**Active Disk Editor**](https://www.disk-editor.org/index.html) it's very easy to inspect the entry of a file in the MFT. Just right click on the file and then click "Inspect File Record"
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Checking the **"In use**" flag it's very easy to know if a file was deleted \(a value of **0x0 means deleted**\).
|
||||
|
||||
|
||||
|
||||
It's also possible to recover deleted files using FTKImager:
|
||||
|
||||
|
||||
|
||||
#### MFT Attributes
|
||||
|
||||
Each MFT entry has several attributes as the following image indicates:
|
||||
|
||||
|
||||
|
||||
Each attribute indicates some entry information identified by the type:
|
||||
|
||||
| Type Identifier | Name | Description |
|
||||
| :--- | :--- | :--- |
|
||||
| 16 | $STANDARD\_INFORMATION | General information, such as flags; the last accessed, written, and created times; and the owner and security ID. |
|
||||
| 32 | $ATTRIBUTE\_LIST | List where other attributes for file can be found. |
|
||||
| 48 | $FILE\_NAME | File name, in Unicode, and the last accessed, written, and created times. |
|
||||
| 64 | $VOLUME\_VERSION | Volume information. Exists only in version 1.2 \(Windows NT\). |
|
||||
| 64 | $OBJECT\_ID | A 16-byte unique identifier for the file or directory. Exists only in versions 3.0+ and after \(Windows 2000+\). |
|
||||
| 80 | $SECURITY\_ DESCRIPTOR | The access control and security properties of the file. |
|
||||
| 96 | $VOLUME\_NAME | Volume name. |
|
||||
| 112 | $VOLUME\_ INFORMATION | File system version and other flags. |
|
||||
| 128 | $DATA | File contents. |
|
||||
| 144 | $INDEX\_ROOT | Root node of an index tree. |
|
||||
| 160 | $INDEX\_ALLOCATION | Nodes of an index tree rooted in $INDEX\_ROOT attribute. |
|
||||
| 176 | $BITMAP | A bitmap for the $MFT file and for indexes. |
|
||||
| 192 | $SYMBOLIC\_LINK | Soft link information. Exists only in version 1.2 \(Windows NT\). |
|
||||
| 192 | $REPARSE\_POINT | Contains data about a reparse point, which is used as a soft link in version 3.0+ \(Windows 2000+\). |
|
||||
| 208 | $EA\_INFORMATION | Used for backward compatibility with OS/2 applications \(HPFS\). |
|
||||
| 224 | $EA | Used for backward compatibility with OS/2 applications \(HPFS\). |
|
||||
| 256 | $LOGGED\_UTILITY\_STREAM | Contains keys and information about encrypted attributes in version 3.0+ \(Windows 2000+\). |
|
||||
|
||||
For example the **type 48 \(0x30\)** identifies the **file name**:
|
||||
|
||||
|
||||
|
||||
It is also useful to understand that **these attributes can be resident** \(meaning, they exist within a given MFT record\) or **nonresident** \(meaning, they exist outside a given MFT record, elsewhere on the disk, and are simply referenced within the record\). For example, if the attribute **$Data is resident**, these means that the **whole file is saved in the MFT**, if it's nonresident, then the content of the file is in other part of the file system.
|
||||
|
||||
Some interesting attributes:
|
||||
|
||||
* [$STANDARD\_INFORMATION](https://flatcap.org/linux-ntfs/ntfs/attributes/standard_information.html) \(among others\):
|
||||
* Creation date
|
||||
* Modification date
|
||||
* Access date
|
||||
* MFT update date
|
||||
* DOS File permissions
|
||||
* [$FILE\_NAME](https://flatcap.org/linux-ntfs/ntfs/attributes/file_name.html) \(among others\):
|
||||
* File name
|
||||
* Creation date
|
||||
* Modification date
|
||||
* Access date
|
||||
* MFT update date
|
||||
* Allocated size
|
||||
* Real size
|
||||
* [File reference](https://flatcap.org/linux-ntfs/ntfs/concepts/file_reference.html) to the parent directory.
|
||||
* [$Data](https://flatcap.org/linux-ntfs/ntfs/attributes/data.html) \(among others\):
|
||||
* Contains the file's data or the indication of the sectors where the data resides. In the following example the attribute data is not resident so the attribute gives information about the sectors where the data resides.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
#### NTFS timestamps
|
||||
|
||||
|
||||
|
||||
Another useful tool to analyze the MFT is [**MFT2csv**](https://github.com/jschicht/Mft2Csv).
|
||||
This program will extract all the MFT data and present it in CSV format. It can also be used to dump the files.
|
||||
|
||||
|
||||
|
||||
#### $LOGFILE
|
||||
|
||||
The file **`$LOGFILE`** contains **logs** about the **actions** that have been **performed** **to** **files**. It also **saves** the **action** it would need to perform in case of a **redo** and the action needed to **go back** to the **previous** **state**.
|
||||
These logs are useful for the MFT to rebuild the file system in case some kind of error happened.
|
||||
|
||||
The maximum file size of this file is **65536KB**.
|
||||
|
||||
In order to inspect the `$LOGFILE` you need to extract it and inspect the `$MFT` previously with [**MFT2csv**](https://github.com/jschicht/Mft2Csv).
|
||||
Then run [**LogFileParser**](https://github.com/jschicht/LogFileParser) against this file and selecting the exported `$LOGFILE` file and the CVS of the inspection of the `$MFT` you will obtain a csv file with the logs of the file system activity recorded by the `$LOGFILE` log.
|
||||
|
||||
|
||||
|
||||
Filtering by filenames you can see **all the actions performed against a file**:
|
||||
|
||||
|
||||
|
||||
#### $USNJnrl
|
||||
|
||||
The file `$EXTEND/$USNJnrl/$J` is and alternate data stream of the file `$EXTEND$USNJnrl` . This artifact contains a **registry of changes produced inside the NTFS volume with more detail than `$LOGFILE`**.
|
||||
|
||||
To inspect this file you can use the tool [**UsnJrnl2csv**](https://github.com/jschicht/UsnJrnl2Csv).
|
||||
|
||||
Filtering by the filename it's possible to see **all the actions performed against a file**. Also you can find the `MFTReference` of the parent folder. Then, looking for that `MFTReference` you can find i**nformation of the parent folder.**
|
||||
|
||||
|
||||
|
||||
#### $I30
|
||||
|
||||
Every **directory** in the file system contains an **`$I30`** **attribute** that must be maintained whenever there are changes to the directory's contents. When files or folders are removed from the directory, the **`$I30`** index records are re-arranged accordingly. However, **re-arranging of the index records may leave remnants of the deleted file/folder entry within the slack space**. This can be useful in forensics analysis for identifying files that may have existed on the drive.
|
||||
|
||||
You can get the `$I30` file of a directory from the **FTK Imager** and inspect it with the tool [Indx2Csv](https://github.com/jschicht/Indx2Csv).
|
||||
|
||||
|
||||
|
||||
With this data you can find **information about the file changes performed inside the folder** but note that the deletion time of a file isn't saved inside this logs. However, you can see that **last modified date** of the **`$I30` file**, and if the **last action performed** over the directory is the **deletion** of a file, the times may be the same.
|
||||
|
||||
#### $Bitmap
|
||||
|
||||
The **`$BitMap`** is a special file within the NTFS file system. This file keeps **track of all of the used and unused clusters** on an NTFS volume. When a file takes up space on the NTFS volume the location is uses is marked out in the `$BitMap`.
|
||||
|
||||
|
||||
|
||||
#### ADS \(Alternate Data Stream\)
|
||||
|
||||
Alternate data streams allow files to contain more than one stream of data. Every file has at least one data stream. In Windows, this default data stream is called `:$DATA`.
|
||||
In this [page you can see different ways to create/access/discover alternate data streams](../../windows/basic-cmd-for-pentesters.md#alternate-data-streams-cheatsheet-ads-alternate-data-stream) from the console. In the past this cause a vulnerability in IIS as people was able to access the source code of a page by accessing the `:$DATA` stream like `http://www.alternate-data-streams.com/default.asp::$DATA`.
|
||||
|
||||
Using the tool [**AlternateStreamView**](https://www.nirsoft.net/utils/alternate_data_streams.html) you can search and export all the files with some ADS.
|
||||
|
||||
|
||||
|
||||
Using the FTK imager and double clicking in a file with ADS you can **access the ADS data**:
|
||||
|
||||
|
||||
|
||||
If you find an ADS called **`Zone.Identifier`** \(see previous image\) this usually contains **information about how was the file downloaded**. There would be a "ZoneId" field with the following info:
|
||||
|
||||
* Zone ID = 0 -> Mycomputer
|
||||
* Zone ID = 1 -> Intranet
|
||||
* Zone ID = 2 -> Trusted
|
||||
* Zone ID = 3 -> Internet
|
||||
* Zone ID = 4 -> Unstrusted
|
||||
|
||||
Moreover, different software may store additional information:
|
||||
|
||||
| Software | Info |
|
||||
| :--- | :--- |
|
||||
| Google Chrome, Opera, Vivaldi, | ZoneId=3, ReferrerUrl, HostUrl |
|
||||
| Microsoft Edge | ZoneId=3, LastWriterPackageFamilyName=Microsoft.MicrosoftEdge\_8wekyb3d8bbwe |
|
||||
| Firefox, Tor browser, Outlook2016, Thunderbird, Windows Mail, Skype | ZoneId=3 |
|
||||
| μTorrent | ZoneId=3, HostUrl=about:internet |
|
||||
|
||||
## **Metadata**
|
||||
|
||||
Some files contains metadata. This is information about the content of the file which sometimes might be interesting for the analyst as depending on the file-type it might have information like:
|
||||
|
||||
* Title
|
||||
* MS Office Version used
|
||||
* Author
|
||||
* Dates of creation and last modification
|
||||
* Model of the camera
|
||||
* GPS coordinates
|
||||
* Image information
|
||||
|
||||
You can use tools like [**exiftool**](https://exiftool.org/) and [**Metadiver**](https://www.easymetadata.com/metadiver-2/) to get the metadata of a file.
|
||||
|
||||
## **Deleted Files Recovery**
|
||||
|
||||
### Logged Deleted Files
|
||||
|
||||
As it was seen before there are several places where the file is still saved after it was "deleted". This is because usually the deletion of a file from a file-system just mark it as deleted but the data isn't touched. Then, it's possible to inspect the registries of the files \(like the MFT\) and find the deleted files.
|
||||
|
||||
Also, the OS usually saves a lot of information about file system changes and backups, so it's possible to try to use them to recover the file or as much information as possible.
|
||||
|
||||
### **File Carving**
|
||||
|
||||
**File carving** is a technique that tries to **find files in a bulk of data**. There are 3 main ways tools like this works: **Based on file types headers and footers**, based on file types **structures** and based on the **content** itself.
|
||||
|
||||
Note that this technique **doesn't work to retrieve fragmented files**. If a file **isn't stored in contiguous sectors**, then this technique won't be able to find it or at least part of it.
|
||||
|
||||
There are several tools that you can use for file Carving indicating them the file-types you want search for like:
|
||||
|
||||
* \*\*\*\*[**PhotoRec**](https://www.cgsecurity.org/wiki/TestDisk_Download)\*\*\*\*
|
||||
* \*\*\*\*[**Binwalk**](https://github.com/ReFirmLabs/binwalk)\*\*\*\*
|
||||
* \*\*\*\*[**Foremost**](https://github.com/jonstewart/foremost)\*\*\*\*
|
||||
* \*\*\*\*[**Bulk Extractor**](https://github.com/simsong/bulk_extractor)\*\*\*\*
|
||||
|
||||
**There are also other tools to find more specific file-types like:**
|
||||
|
||||
* \*\*\*\*[**vss\_carver**](https://github.com/mnrkbys/vss_carver): Use it to search for delete Volume shadow Copies
|
||||
|
||||
### Data Stream **C**arving
|
||||
|
||||
Data Stream Carving is similar to File Carving but i**nstead of looking for complete files, it looks for interesting fragments** of information.
|
||||
For example, instead of looking for a complete file containing logged URLs, this technique will search for URLs.
|
||||
|
||||
The following tools can be used to find specific interesting information inside a bulk of data:
|
||||
|
||||
* \*\*\*\*[**Bulk Extractor**](https://github.com/simsong/bulk_extractor)\*\*\*\*
|
||||
|
||||
### Secure Deletion
|
||||
|
||||
Obviously, there are ways to **"securely" delete files and part of logs about them**. For example, it's possible to **overwrite the content** of a file with junk data several times, and then **remove** the **logs** from the **$MFT** and **$LOGFILE** about the file, and **remove the Volume Shadow Copies**.
|
||||
You may notice that even performing that action there might be **other parts where the existence of the file is still logged**, and that's true and part of the forensics professional job is to find them.
|
||||
|
||||
## References
|
||||
|
||||
* [https://en.wikipedia.org/wiki/GUID\_Partition\_Table](https://en.wikipedia.org/wiki/GUID_Partition_Table)
|
||||
##
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,193 @@
|
|||
# Partitions/File Systems/Carving
|
||||
|
||||
## Partitions
|
||||
|
||||
A hard drive or a **SSD disk can contain different partitions** with the goal of separating data physically.
|
||||
The **minimum** unit of a disk is the **sector** \(normally composed by 512B\). So, each partition size needs to be multiple of that size.
|
||||
|
||||
### MBR \(master Boot Record\)
|
||||
|
||||
It's allocated in the **first sector of the disk after the 446B of the boot code**. It contains the **partitions** table \(there can be up to **4 primary partitions**\). The **final byte** of this first sector is the boot record signature **0x55AA**. Only one partition can be marked as active.
|
||||
MBR allows **max 2.2TB**.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
From the **bytes 440 to the 443** of the MBR you can find the **Windows Disk Signature** \(if Windows is used\). The logical drive letters of the hard disk depend on the Windows Disk Signature. Changing this signature could prevent Windows from booting \(tool: [**Active Disk Editor**](https://www.disk-editor.org/index.html)**\)**.
|
||||
|
||||
|
||||
|
||||
#### LBA \(Logical block addressing\)
|
||||
|
||||
**Logical block addressing** \(**LBA**\) is a common scheme used for **specifying the location of blocks** of data stored on computer storage devices, generally secondary storage systems such as hard disk drives. LBA is a particularly simple linear addressing scheme; **blocks are located by an integer index**, with the first block being LBA 0, the second LBA 1, and so on.
|
||||
|
||||
### GPT \(GUID Partition Table\)
|
||||
|
||||
It’s called GUID Partition Table because every partition on your drive has a **globally unique identifier**.
|
||||
|
||||
Just like MBR it starts in the **sector 0**. The MBR occupies 32bits while **GPT** uses **64bits**.
|
||||
GPT **allows up to 128 partitions** in Windows and up to **9.4ZB**.
|
||||
Also, partitions can have a 36 character Unicode name.
|
||||
|
||||
On an MBR disk, the partitioning and boot data is stored in one place. If this data is overwritten or corrupted, you’re in trouble. In contrast, **GPT stores multiple copies of this data across the disk**, so it’s much more robust and can recover if the data is corrupted.
|
||||
|
||||
GPT also stores **cyclic redundancy check \(CRC\)** values to check that its data is intact. If the data is corrupted, GPT can notice the problem and **attempt to recover the damaged data** from another location on the disk.
|
||||
|
||||
#### Protective MBR \(LBA0\)
|
||||
|
||||
For limited backward compatibility, the space of the legacy MBR is still reserved in the GPT specification, but it is now used in a **way that prevents MBR-based disk utilities from misrecognizing and possibly overwriting GPT disks**. This is referred to as a protective MBR.
|
||||
|
||||
|
||||
|
||||
#### Hybrid MBR \(LBA 0 + GPT\)
|
||||
|
||||
In operating systems that support **GPT-based boot through BIOS** services rather than EFI, the first sector may also still be used to store the first stage of the **bootloader** code, but **modified** to recognize **GPT** **partitions**. The bootloader in the MBR must not assume a sector size of 512 bytes.
|
||||
|
||||
#### Partition table header \(LBA 1\)
|
||||
|
||||
The partition table header defines the usable blocks on the disk. It also defines the number and size of the partition entries that make up the partition table \(offsets 80 and 84 in the table\).
|
||||
|
||||
| Offset | Length | Contents |
|
||||
| :--- | :--- | :--- |
|
||||
| 0 \(0x00\) | 8 bytes | Signature \("EFI PART", 45h 46h 49h 20h 50h 41h 52h 54h or 0x5452415020494645ULL[ ](https://en.wikipedia.org/wiki/GUID_Partition_Table#cite_note-8)on little-endian machines\) |
|
||||
| 8 \(0x08\) | 4 bytes | Revision 1.0 \(00h 00h 01h 00h\) for UEFI 2.8 |
|
||||
| 12 \(0x0C\) | 4 bytes | Header size in little endian \(in bytes, usually 5Ch 00h 00h 00h or 92 bytes\) |
|
||||
| 16 \(0x10\) | 4 bytes | [CRC32](https://en.wikipedia.org/wiki/CRC32) of header \(offset +0 up to header size\) in little endian, with this field zeroed during calculation |
|
||||
| 20 \(0x14\) | 4 bytes | Reserved; must be zero |
|
||||
| 24 \(0x18\) | 8 bytes | Current LBA \(location of this header copy\) |
|
||||
| 32 \(0x20\) | 8 bytes | Backup LBA \(location of the other header copy\) |
|
||||
| 40 \(0x28\) | 8 bytes | First usable LBA for partitions \(primary partition table last LBA + 1\) |
|
||||
| 48 \(0x30\) | 8 bytes | Last usable LBA \(secondary partition table first LBA − 1\) |
|
||||
| 56 \(0x38\) | 16 bytes | Disk GUID in mixed endian |
|
||||
| 72 \(0x48\) | 8 bytes | Starting LBA of array of partition entries \(always 2 in primary copy\) |
|
||||
| 80 \(0x50\) | 4 bytes | Number of partition entries in array |
|
||||
| 84 \(0x54\) | 4 bytes | Size of a single partition entry \(usually 80h or 128\) |
|
||||
| 88 \(0x58\) | 4 bytes | CRC32 of partition entries array in little endian |
|
||||
| 92 \(0x5C\) | \* | Reserved; must be zeroes for the rest of the block \(420 bytes for a sector size of 512 bytes; but can be more with larger sector sizes\) |
|
||||
|
||||
#### Partition entries \(LBA 2–33\)
|
||||
|
||||
| GUID partition entry format | | |
|
||||
| :--- | :--- | :--- |
|
||||
| Offset | Length | Contents |
|
||||
| 0 \(0x00\) | 16 bytes | [Partition type GUID](https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs) \(mixed endian\) |
|
||||
| 16 \(0x10\) | 16 bytes | Unique partition GUID \(mixed endian\) |
|
||||
| 32 \(0x20\) | 8 bytes | First LBA \([little endian](https://en.wikipedia.org/wiki/Little_endian)\) |
|
||||
| 40 \(0x28\) | 8 bytes | Last LBA \(inclusive, usually odd\) |
|
||||
| 48 \(0x30\) | 8 bytes | Attribute flags \(e.g. bit 60 denotes read-only\) |
|
||||
| 56 \(0x38\) | 72 bytes | Partition name \(36 [UTF-16](https://en.wikipedia.org/wiki/UTF-16)LE code units\) |
|
||||
|
||||
#### Partitions Types
|
||||
|
||||
|
||||
|
||||
More partition types in [https://en.wikipedia.org/wiki/GUID\_Partition\_Table](https://en.wikipedia.org/wiki/GUID_Partition_Table)
|
||||
|
||||
### Inspecting
|
||||
|
||||
After mounting the forensics image with [**ArsenalImageMounter**](https://arsenalrecon.com/downloads/), you can inspect the first sector using the Windows tool [**Active Disk Editor**](https://www.disk-editor.org/index.html)**.** In the following image a **MBR** was detected on the **sector 0** and interpreted:
|
||||
|
||||
|
||||
|
||||
If it was a **GPT table instead of a MBR** it should appear the signature _EFI PART_ in the **sector 1** \(which in the previous image is empty\).
|
||||
|
||||
## File-Systems
|
||||
|
||||
### Windows file-systems list
|
||||
|
||||
* **FAT12/16**: MSDOS, WIN95/98/NT/200
|
||||
* **FAT32**: 95/2000/XP/2003/VISTA/7/8/10
|
||||
* **ExFAT**: 2008/2012/2016/VISTA/7/8/10
|
||||
* **NTFS**: XP/2003/2008/2012/VISTA/7/8/10
|
||||
* **ReFS**: 2012/2016
|
||||
|
||||
### FAT
|
||||
|
||||
The **FAT \(File Allocation Table\)** file system is named for its method of organization, the file allocation table, which resides at the beginning of the volume. To protect the volume, **two copies** of the table are kept, in case one becomes damaged. In addition, the file allocation tables and the root folder must be stored in a **fixed location** so that the files needed to start the system can be correctly located.
|
||||
|
||||
|
||||
|
||||
The minimum space unit used by this file-system is a **cluster, typically 512B** \(which is composed by a number of sectors\).
|
||||
|
||||
The earlier **FAT12** had a **cluster addresses to 12-bit** values with up to **4078** **clusters**; it allowed up to 4084 clusters with UNIX. The more efficient **FAT16** increased to **16-bit** cluster address allowing up to **65,517 clusters** per volume. FAT32 uses 32-bit cluster address allowing up to **268,435,456 clusters** per volume
|
||||
|
||||
The **maximum file-size allowed by FAT is 4GB** \(minus one byte\) because the file system uses a 32-bit field to store the file size in bytes, and 2^32 bytes = 4 GiB. This happens for FAT12, FAT16 and FAT32.
|
||||
|
||||
The **root directory** occupies a **specific position** for both FAT12 and FAT16 \(in FAT32 it occupies a position like any other folder\). Each file/folder entry contains this information:
|
||||
|
||||
* Name of the file/folder \(8 chars max\)
|
||||
* Attributes
|
||||
* Date of creation
|
||||
* Date of modification
|
||||
* Date of last access
|
||||
* Address of the FAT table where the first cluster of the file starts
|
||||
* Size
|
||||
|
||||
When a file is "deleted" using a FAT file system, the directory entry remains almost **unchanged** except for the **first character of the file name** \(modified to ****0xE5\), preserving most of the "deleted" file's name, along with its time stamp, file length and — most importantly — its physical location on the disk. The list of disk clusters occupied by the file will, however, be erased from the File Allocation Table, marking those sectors available for use by other files created or modified thereafter. In case of FAT32, it is additionally erased field responsible for upper 16 bits of file start cluster value.
|
||||
|
||||
### **NTFS**
|
||||
|
||||
{% page-ref page="ntfs.md" %}
|
||||
|
||||
## **Metadata**
|
||||
|
||||
Some files contains metadata. This is information about the content of the file which sometimes might be interesting for the analyst as depending on the file-type it might have information like:
|
||||
|
||||
* Title
|
||||
* MS Office Version used
|
||||
* Author
|
||||
* Dates of creation and last modification
|
||||
* Model of the camera
|
||||
* GPS coordinates
|
||||
* Image information
|
||||
|
||||
You can use tools like [**exiftool**](https://exiftool.org/) and [**Metadiver**](https://www.easymetadata.com/metadiver-2/) to get the metadata of a file.
|
||||
|
||||
## **Deleted Files Recovery**
|
||||
|
||||
### Logged Deleted Files
|
||||
|
||||
As it was seen before there are several places where the file is still saved after it was "deleted". This is because usually the deletion of a file from a file-system just mark it as deleted but the data isn't touched. Then, it's possible to inspect the registries of the files \(like the MFT\) and find the deleted files.
|
||||
|
||||
Also, the OS usually saves a lot of information about file system changes and backups, so it's possible to try to use them to recover the file or as much information as possible.
|
||||
|
||||
### **File Carving**
|
||||
|
||||
**File carving** is a technique that tries to **find files in a bulk of data**. There are 3 main ways tools like this works: **Based on file types headers and footers**, based on file types **structures** and based on the **content** itself.
|
||||
|
||||
Note that this technique **doesn't work to retrieve fragmented files**. If a file **isn't stored in contiguous sectors**, then this technique won't be able to find it or at least part of it.
|
||||
|
||||
There are several tools that you can use for file Carving indicating them the file-types you want search for like:
|
||||
|
||||
* \*\*\*\*[**PhotoRec**](https://www.cgsecurity.org/wiki/TestDisk_Download)\*\*\*\*
|
||||
* \*\*\*\*[**Binwalk**](https://github.com/ReFirmLabs/binwalk)\*\*\*\*
|
||||
* \*\*\*\*[**Foremost**](https://github.com/jonstewart/foremost)\*\*\*\*
|
||||
* \*\*\*\*[**Bulk Extractor**](https://github.com/simsong/bulk_extractor)\*\*\*\*
|
||||
|
||||
**There are also other tools to find more specific file-types like:**
|
||||
|
||||
* \*\*\*\*[**vss\_carver**](https://github.com/mnrkbys/vss_carver): Use it to search for delete Volume shadow Copies
|
||||
|
||||
### Data Stream **C**arving
|
||||
|
||||
Data Stream Carving is similar to File Carving but i**nstead of looking for complete files, it looks for interesting fragments** of information.
|
||||
For example, instead of looking for a complete file containing logged URLs, this technique will search for URLs.
|
||||
|
||||
The following tools can be used to find specific interesting information inside a bulk of data:
|
||||
|
||||
* \*\*\*\*[**Bulk Extractor**](https://github.com/simsong/bulk_extractor)\*\*\*\*
|
||||
|
||||
### Secure Deletion
|
||||
|
||||
Obviously, there are ways to **"securely" delete files and part of logs about them**. For example, it's possible to **overwrite the content** of a file with junk data several times, and then **remove** the **logs** from the **$MFT** and **$LOGFILE** about the file, and **remove the Volume Shadow Copies**.
|
||||
You may notice that even performing that action there might be **other parts where the existence of the file is still logged**, and that's true and part of the forensics professional job is to find them.
|
||||
|
||||
## References
|
||||
|
||||
* [https://en.wikipedia.org/wiki/GUID\_Partition\_Table](https://en.wikipedia.org/wiki/GUID_Partition_Table)
|
||||
* [http://ntfs.com/ntfs-permissions.htm](http://ntfs.com/ntfs-permissions.htm)
|
||||
* [https://www.osforensics.com/faqs-and-tutorials/how-to-scan-ntfs-i30-entries-deleted-files.html](https://www.osforensics.com/faqs-and-tutorials/how-to-scan-ntfs-i30-entries-deleted-files.html)
|
||||
* [https://docs.microsoft.com/en-us/windows-server/storage/file-server/volume-shadow-copy-service](https://docs.microsoft.com/en-us/windows-server/storage/file-server/volume-shadow-copy-service)
|
||||
* **iHackLabs Certified Digital Forensics Windows**
|
||||
|
||||
|
|
@ -0,0 +1,221 @@
|
|||
# NTFS
|
||||
|
||||
## **NTFS**
|
||||
|
||||
**NTFS** \(**New Technology File System**\) is a proprietary journaling file system developed by Microsoft.
|
||||
|
||||
The cluster is the minimum size unit of NTFS and the size of the cluster depends on the size of a partition.
|
||||
|
||||
| Partition size | Sectors per cluster | Cluster size |
|
||||
| :--- | :--- | :--- |
|
||||
| 512MB or less | 1 | 512 bytes |
|
||||
| 513MB-1024MB \(1GB\) | 2 | 1KB |
|
||||
| 1025MB-2048MB \(2GB\) | 4 | 2KB |
|
||||
| 2049MB-4096MB \(4GB\) | 8 | 4KB |
|
||||
| 4097MB-8192MB \(8GB\) | 16 | 8KB |
|
||||
| 8193MB-16,384MB \(16GB\) | 32 | 16KB |
|
||||
| 16,385MB-32,768MB \(32GB\) | 64 | 32KB |
|
||||
| Greater than 32,768MB | 128 | 64KB |
|
||||
|
||||
### **Slack-Space**
|
||||
|
||||
As the **minimum** size unit of NTFS is a **cluster**. Each file will be occupying a number of complete clusters. Then, it's highly probable that **each file occupies more space than necessary**. These **unused** **spaces** **booked** by a file which is called **slacking** **space**. And people could take advantage of this technique to **hide** **information**.
|
||||
|
||||
|
||||
|
||||
### **NTFS boot sector**
|
||||
|
||||
When you format an NTFS volume, the format program allocates the first 16 sectors for the $Boot metadata file. First sector, in fact, is a boot sector with a "bootstrap" code and the following 15 sectors are the boot sector's IPL \(initial program loader\). To increase file system reliability the very last sector an NTFS partition contains a spare copy of the boot sector.
|
||||
|
||||
### **Master File Table o $MFT**
|
||||
|
||||
The NTFS file system contains a file called the _master file table_, or MFT. There is at least **one entry in the MFT for every file on an NTFS file system** volume, including the MFT itself. All information about a file, including its **size, time and date stamps, permissions, and data content**, is stored either in MFT entries, or in space outside the MFT that is described by MFT entries.
|
||||
|
||||
As **files are added** to an NTFS file system volume, more entries are added to the MFT and the **MFT increases in size**. When **files** are **deleted** from an NTFS file system volume, their **MFT entries are marked as free** and may be reused. However, disk space that has been allocated for these entries is not reallocated, and the size of the MFT does not decrease.
|
||||
|
||||
The NTFS file system **reserves space for the MFT to keep the MFT as contiguous as possible** as it grows. The space reserved by the NTFS file system for the MFT in each volume is called the **MFT zone**. Space for file and directories are also allocated from this space, but only after all of the volume space outside of the MFT zone has been allocated.
|
||||
|
||||
Depending on the average file size and other variables, **either the reserved MFT zone or the unreserved space on the disk may be allocated first as the disk fills to capacity**. Volumes with a small number of relatively large files will allocate the unreserved space first, while volumes with a large number of relatively small files allocate the MFT zone first. In either case, fragmentation of the MFT starts to take place when one region or the other becomes fully allocated. If the unreserved space is completely allocated, space for user files and directories will be allocated from the MFT zone. If the MFT zone is completely allocated, space for new MFT entries will be allocated from the unreserved space.
|
||||
|
||||
NTFS file systems also generate a **$MFTMirror**. This is a **copy** of the **first 4 entries** of the MFT: $MFT, $MFT Mirror, $Log, $Volume.
|
||||
|
||||
NTFS reserves the first 16 records of the table for special information:
|
||||
|
||||
| System File | File Name | MFT Record | Purpose of the File |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| Master file table | $Mft | 0 | Contains one base file record for each file and folder on an NTFS volume. If the allocation information for a file or folder is too large to fit within a single record, other file records are allocated as well. |
|
||||
| Master file table 2 | $MftMirr | 1 | A duplicate image of the first four records of the MFT. This file guarantees access to the MFT in case of a single-sector failure. |
|
||||
| Log file | $LogFile | 2 | Contains a list of transaction steps used for NTFS recoverability. Log file size depends on the volume size and can be as large as 4 MB. It is used by Windows NT/2000 to restore consistency to NTFS after a system failure. |
|
||||
| Volume | $Volume | 3 | Contains information about the volume, such as the volume label and the volume version. |
|
||||
| Attribute definitions | $AttrDef | 4 | A table of attribute names, numbers, and descriptions. |
|
||||
| Root file name index | $ | 5 | The root folder. |
|
||||
| Cluster bitmap | $Bitmap | 6 | A representation of the volume showing which clusters are in use. |
|
||||
| Boot sector | $Boot | 7 | Includes the BPB used to mount the volume and additional bootstrap loader code used if the volume is bootable. |
|
||||
| Bad cluster file | $BadClus | 8 | Contains bad clusters for the volume. |
|
||||
| Security file | $Secure | 9 | Contains unique security descriptors for all files within a volume. |
|
||||
| Upcase table | $Upcase | 10 | Converts lowercase characters to matching Unicode uppercase characters. |
|
||||
| NTFS extension file | $Extend | 11 | Used for various optional extensions such as quotas, reparse point data, and object identifiers. |
|
||||
| | | 12-15 | Reserved for future use. |
|
||||
| Quota management file | $Quota | 24 | Contains user assigned quota limits on the volume space. |
|
||||
| Object Id file | $ObjId | 25 | Contains file object IDs. |
|
||||
| Reparse point file | $Reparse | 26 | This file contains information about files and folders on the volume include reparse point data. |
|
||||
|
||||
### Each entry of the MFT looks like the following:
|
||||
|
||||
|
||||
|
||||
Note how each entry starts with "FILE". Each entry occupies 1024 bits. So after 1024 bit from the start of a MFT entry you will find the next one.
|
||||
|
||||
Using the [**Active Disk Editor**](https://www.disk-editor.org/index.html) it's very easy to inspect the entry of a file in the MFT. Just right click on the file and then click "Inspect File Record"
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Checking the **"In use**" flag it's very easy to know if a file was deleted \(a value of **0x0 means deleted**\).
|
||||
|
||||
|
||||
|
||||
It's also possible to recover deleted files using FTKImager:
|
||||
|
||||
|
||||
|
||||
### MFT Attributes
|
||||
|
||||
Each MFT entry has several attributes as the following image indicates:
|
||||
|
||||
|
||||
|
||||
Each attribute indicates some entry information identified by the type:
|
||||
|
||||
| Type Identifier | Name | Description |
|
||||
| :--- | :--- | :--- |
|
||||
| 16 | $STANDARD\_INFORMATION | General information, such as flags; the last accessed, written, and created times; and the owner and security ID. |
|
||||
| 32 | $ATTRIBUTE\_LIST | List where other attributes for file can be found. |
|
||||
| 48 | $FILE\_NAME | File name, in Unicode, and the last accessed, written, and created times. |
|
||||
| 64 | $VOLUME\_VERSION | Volume information. Exists only in version 1.2 \(Windows NT\). |
|
||||
| 64 | $OBJECT\_ID | A 16-byte unique identifier for the file or directory. Exists only in versions 3.0+ and after \(Windows 2000+\). |
|
||||
| 80 | $SECURITY\_ DESCRIPTOR | The access control and security properties of the file. |
|
||||
| 96 | $VOLUME\_NAME | Volume name. |
|
||||
| 112 | $VOLUME\_ INFORMATION | File system version and other flags. |
|
||||
| 128 | $DATA | File contents. |
|
||||
| 144 | $INDEX\_ROOT | Root node of an index tree. |
|
||||
| 160 | $INDEX\_ALLOCATION | Nodes of an index tree rooted in $INDEX\_ROOT attribute. |
|
||||
| 176 | $BITMAP | A bitmap for the $MFT file and for indexes. |
|
||||
| 192 | $SYMBOLIC\_LINK | Soft link information. Exists only in version 1.2 \(Windows NT\). |
|
||||
| 192 | $REPARSE\_POINT | Contains data about a reparse point, which is used as a soft link in version 3.0+ \(Windows 2000+\). |
|
||||
| 208 | $EA\_INFORMATION | Used for backward compatibility with OS/2 applications \(HPFS\). |
|
||||
| 224 | $EA | Used for backward compatibility with OS/2 applications \(HPFS\). |
|
||||
| 256 | $LOGGED\_UTILITY\_STREAM | Contains keys and information about encrypted attributes in version 3.0+ \(Windows 2000+\). |
|
||||
|
||||
For example the **type 48 \(0x30\)** identifies the **file name**:
|
||||
|
||||
|
||||
|
||||
It is also useful to understand that **these attributes can be resident** \(meaning, they exist within a given MFT record\) or **nonresident** \(meaning, they exist outside a given MFT record, elsewhere on the disk, and are simply referenced within the record\). For example, if the attribute **$Data is resident**, these means that the **whole file is saved in the MFT**, if it's nonresident, then the content of the file is in other part of the file system.
|
||||
|
||||
Some interesting attributes:
|
||||
|
||||
* [$STANDARD\_INFORMATION](https://flatcap.org/linux-ntfs/ntfs/attributes/standard_information.html) \(among others\):
|
||||
* Creation date
|
||||
* Modification date
|
||||
* Access date
|
||||
* MFT update date
|
||||
* DOS File permissions
|
||||
* [$FILE\_NAME](https://flatcap.org/linux-ntfs/ntfs/attributes/file_name.html) \(among others\):
|
||||
* File name
|
||||
* Creation date
|
||||
* Modification date
|
||||
* Access date
|
||||
* MFT update date
|
||||
* Allocated size
|
||||
* Real size
|
||||
* [File reference](https://flatcap.org/linux-ntfs/ntfs/concepts/file_reference.html) to the parent directory.
|
||||
* [$Data](https://flatcap.org/linux-ntfs/ntfs/attributes/data.html) \(among others\):
|
||||
* Contains the file's data or the indication of the sectors where the data resides. In the following example the attribute data is not resident so the attribute gives information about the sectors where the data resides.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### NTFS timestamps
|
||||
|
||||
|
||||
|
||||
Another useful tool to analyze the MFT is [**MFT2csv**](https://github.com/jschicht/Mft2Csv).
|
||||
This program will extract all the MFT data and present it in CSV format. It can also be used to dump the files.
|
||||
|
||||
|
||||
|
||||
### $LOGFILE
|
||||
|
||||
The file **`$LOGFILE`** contains **logs** about the **actions** that have been **performed** **to** **files**. It also **saves** the **action** it would need to perform in case of a **redo** and the action needed to **go back** to the **previous** **state**.
|
||||
These logs are useful for the MFT to rebuild the file system in case some kind of error happened.
|
||||
|
||||
The maximum file size of this file is **65536KB**.
|
||||
|
||||
In order to inspect the `$LOGFILE` you need to extract it and inspect the `$MFT` previously with [**MFT2csv**](https://github.com/jschicht/Mft2Csv).
|
||||
Then run [**LogFileParser**](https://github.com/jschicht/LogFileParser) against this file and selecting the exported `$LOGFILE` file and the CVS of the inspection of the `$MFT` you will obtain a csv file with the logs of the file system activity recorded by the `$LOGFILE` log.
|
||||
|
||||
|
||||
|
||||
Filtering by filenames you can see **all the actions performed against a file**:
|
||||
|
||||
|
||||
|
||||
### $USNJnrl
|
||||
|
||||
The file `$EXTEND/$USNJnrl/$J` is and alternate data stream of the file `$EXTEND$USNJnrl` . This artifact contains a **registry of changes produced inside the NTFS volume with more detail than `$LOGFILE`**.
|
||||
|
||||
To inspect this file you can use the tool [**UsnJrnl2csv**](https://github.com/jschicht/UsnJrnl2Csv).
|
||||
|
||||
Filtering by the filename it's possible to see **all the actions performed against a file**. Also you can find the `MFTReference` of the parent folder. Then, looking for that `MFTReference` you can find i**nformation of the parent folder.**
|
||||
|
||||
|
||||
|
||||
### $I30
|
||||
|
||||
Every **directory** in the file system contains an **`$I30`** **attribute** that must be maintained whenever there are changes to the directory's contents. When files or folders are removed from the directory, the **`$I30`** index records are re-arranged accordingly. However, **re-arranging of the index records may leave remnants of the deleted file/folder entry within the slack space**. This can be useful in forensics analysis for identifying files that may have existed on the drive.
|
||||
|
||||
You can get the `$I30` file of a directory from the **FTK Imager** and inspect it with the tool [Indx2Csv](https://github.com/jschicht/Indx2Csv).
|
||||
|
||||
|
||||
|
||||
With this data you can find **information about the file changes performed inside the folder** but note that the deletion time of a file isn't saved inside this logs. However, you can see that **last modified date** of the **`$I30` file**, and if the **last action performed** over the directory is the **deletion** of a file, the times may be the same.
|
||||
|
||||
### $Bitmap
|
||||
|
||||
The **`$BitMap`** is a special file within the NTFS file system. This file keeps **track of all of the used and unused clusters** on an NTFS volume. When a file takes up space on the NTFS volume the location is uses is marked out in the `$BitMap`.
|
||||
|
||||
|
||||
|
||||
### ADS \(Alternate Data Stream\)
|
||||
|
||||
Alternate data streams allow files to contain more than one stream of data. Every file has at least one data stream. In Windows, this default data stream is called `:$DATA`.
|
||||
In this [page you can see different ways to create/access/discover alternate data streams](../../../windows/basic-cmd-for-pentesters.md#alternate-data-streams-cheatsheet-ads-alternate-data-stream) from the console. In the past this cause a vulnerability in IIS as people was able to access the source code of a page by accessing the `:$DATA` stream like `http://www.alternate-data-streams.com/default.asp::$DATA`.
|
||||
|
||||
Using the tool [**AlternateStreamView**](https://www.nirsoft.net/utils/alternate_data_streams.html) you can search and export all the files with some ADS.
|
||||
|
||||
|
||||
|
||||
Using the FTK imager and double clicking in a file with ADS you can **access the ADS data**:
|
||||
|
||||
|
||||
|
||||
If you find an ADS called **`Zone.Identifier`** \(see previous image\) this usually contains **information about how was the file downloaded**. There would be a "ZoneId" field with the following info:
|
||||
|
||||
* Zone ID = 0 -> Mycomputer
|
||||
* Zone ID = 1 -> Intranet
|
||||
* Zone ID = 2 -> Trusted
|
||||
* Zone ID = 3 -> Internet
|
||||
* Zone ID = 4 -> Unstrusted
|
||||
|
||||
Moreover, different software may store additional information:
|
||||
|
||||
| Software | Info |
|
||||
| :--- | :--- |
|
||||
| Google Chrome, Opera, Vivaldi, | ZoneId=3, ReferrerUrl, HostUrl |
|
||||
| Microsoft Edge | ZoneId=3, LastWriterPackageFamilyName=Microsoft.MicrosoftEdge\_8wekyb3d8bbwe |
|
||||
| Firefox, Tor browser, Outlook2016, Thunderbird, Windows Mail, Skype | ZoneId=3 |
|
||||
| μTorrent | ZoneId=3, HostUrl=about:internet |
|
||||
|
||||
Loading…
Reference in a new issue