File System Analysis.

By: nafcloud

9/12/2026, 6:08:28 PM

Status: Doing
User Name: Naftali da Costa

MBR and GPT Analysis
- Antes de analisarmos o Master Boot Record (MBR) precisamos entender como funciona o processo de inicialização de qualquer sistema operacional. O processo de incialização acorda todo sistema, envia sinais de energia para os componetes de hardware, inicia o sistema operacional na memoria e permite o usuario interagir com o sistema. Vamos cobrir o início do processo de inicialização antes de entender o papel do MBR/GPT. O objetivo é entender a inicialização básica de um sistema antes de mergulharmos na estrutura do MBR/GPT e explorarmos seu valor desse artefacto na forense computacional.
  O processo geral de inicialização de um sistema tem várias etapas, como pode ser visto no diagrama de fluxo abaixo:
- Power-On the System
  - O primeiro passo comeca quando voce pressiona o botão de energia (power button) que envia sinais eletricos para todos os compontes presentes no seu hardware. A CPU é o primeiro componte que recebe o sinal eletrico e precisa de algumas instruções para continuar o processo. A CPU busca e executa as instruções que estão localizadas no chipset da placa mãe. Os chipsets mais conhecidos são BIOS e UEFI, são eles que têm as instruções de como continuar com o processo de inicialização.
  - O BIOS (Basic Input/Output System) e UEFI (Unified Extensible Firmware Interface) são os responsaveis de verificar sempre que todos os componetes do hardware estão trabalhando de forma apropriada. A diferença entre eles está em suas capacidades e características.
    BIOS has been used for decades and is still used in some hardware. It runs in the basic 16-bit mode and supports only up to 2 terabytes of disks. The most important thing to note is that BIOS supports the MBR partitioning scheme, which we will discuss later in the task.
    UEFI came as a replacement for BIOS, offering 32-bit and 64-bit modes with up to 9 zettabytes of disks. UEFI offers a secure boot feature to ensure
    during the system boot process. It also offers redundancy, allowing us to recover from the backup even if the boot code is corrupted. UEFI uses a GPT partitioning scheme, unlike the MBR partitioning scheme used by BIOS.
  - Para identificar o firmware do seu computador no Microsoft Windows use o conjunto de teclas Windows + R e digite msinfo32. Na informações estará como na imagem abaixo se o firmware for BIOS Legacy.
  - Já em distribuições baseadas no Debian abra, o terminal, digite "sudo fdisk -l" e dê ENTER. A imagem abaixo mostra que o firmware gravado na UEFI (chipset) é GPT.
- Power-On-Self-Test (POST)
- O sistema é ligado, e a CPU passa a executar instruções a partir do firmware (BIOS/UEFI) instalado. Em seguida, a BIOS/UEFI inicia um Power-On-Self-Test (Autoteste de Inicialização) para garantir que todos os componentes de hardware do sistema estejam funcionando corretamente. Você pode ouvir um ou vários bipes durante esse processo no seu sistema; é assim que a BIOS/UEFI comunica eventuais falhas nos componentes de hardware e exibe a mensagem de erro na tela, por exemplo, teclado não encontrado.
- Locate the Bootable Device
- Analizando o MBR
- O diagrama acima represente o layout real de um disco, note que o MBR não pertence a nenhum cluster/block porque ele não pertence a nenhuma partição.
- Pense assim:
- "block/cluster" é um conceito do filesystem , não do disco
- Você só tem blocks/clusters depois que uma partição foi formatada com um filesystem (NTFS, ext4, etc.). O MBR fica fora de qualquer partição, logo, fora de qualquer filesystem, logo, o conceito de "block" simplesmente não se aplica a ele. O MBR é diferente do boot sector, o boot sector está associado a uma partição específica e ajuda o sistema a saber como essa partição está organizada e como iniciar o seu conteúdo e MBR fica no início do disco e contém a tabela de partições, tipo de sistema de arquivo de cada partição, Identificador (ID) do disco e o números de setores de cada partição.
- Estrutura interna do MBR
- Segundo, o ebook "Forensic Analysis of Master Boot Record" a imagem abaixo mostra a estrutura interna do MBR.
- Estrutura simplifica providenciada pelo o tryhackme:
- LBA significa Logical Block Address.
- O diagrama acima faz um zoom para dentro daquela primeira caixinha "MBR" do desenho anterior, mostrando do que ela é feita internamente. É um container único (os 512 bytes do MBR) dividido em quatro blocos lado a lado, com larguras proporcionais ao número de bytes que cada um ocupa:
- Bootstrap code — bytes 0–446, o código executável que a BIOS roda.
- Partition table — bytes 446–509, as 4 entradas de 16 bytes com os dados das partições. 4 x 16 = 64 bytes.
- Disk signature — bytes 510–511, o identificador único do disco.
- 55 AA bytes 510–511, a assinatura de boot que a BIOS verifica antes de executar qualquer coisa. Esses bytes tambem são conhecidos como magic e indicam o MBR terminou.
- Esse código do bootloader contém o bootloader inicial. Ele é a primeira coisa que executa a partir do MBR. A função primária desse código inicial é encontrar a partição bootável a partir da tabela de partição presente no MBR.
- Esse mecanismo, porém, é específico do boot legado via BIOS. A imagem abaixo mostra as 4 partições do meu disco (SSD). A partição /dev/sda1 é a partição de boot do meu disco, mas ela não é identificada por um boot flag como no MBR legado.
- Isso acontece porque o chipset da minha máquina usa UEFI, e a UEFI não lê o MBR para localizar a partição bootável, ela lê o GPT. Sendo assim, o mecanismo de boot flag simplesmente não existe no GPT. Em vez disso, o GPT já define um GUID específico para cada tipo de partição, e é esse GUID (no caso, o de EFI System Partition) que identifica /dev/sda1 como a partição de boot.
- A imagem abaixo vai te ajudar a enteder como funciona o processo de inicialização em uma maquina que usa o chipset UEFI.
- Repare que /dev/sda1 não contém o sistema operacional inteiro só contém os arquivos mínimos que a firmware UEFI consegue entender e ele só entende o FAT32, porque é o único filesystem que praticamente toda UEFI sabe ler nativamente. O resto do sistema (kernel, bibliotecas, seus arquivos, sessões de usuarioss) fica em /dev/sda2 (btrfs), que a UEFI não sabe ler diretamente só o GRUB, depois de já ter sido carregado, sabe como acessar esse filesystem mais complexo.
- note
- Mapa mental da estrutura interna do MBR.
- important
- Começa sempre pela a BIOS. A BIOS lê sempre o primeiro sector que é o sector 0 numerado pelo o LBA 0. Em um disco particionado com o esquema MBR tradicional, o Master Boot Record está localizado no LBA 0.
- O SO também consegue abrir o disco inteiro como um dispositivo bruto no Linux, isso é literalmente o arquivo /dev/sda; no Windows, \\.\PhysicalDrive0. Esse acesso ignora completamente a abstração de filesystem e block, você lê e escreve sector por sector, numerado por LBA, exatamente como a BIOS faz no boot. Por exemplo o setor 0 de 512B (MBR) tem um número LBA que aponta para o sector do MBR para o sistema operacional ler.
- Analogia para fixar
  Pense em dois mapas diferentes da mesma cidade:
- Mapa de bairros (blocks) só existe depois que a prefeitura (filesystem) organizou os lotes em quarteirões. Útil pra achar "a casa 42 do bairro X".
- Mapa de coordenadas GPS (sectors/LBA) existe independente de qualquer organização administrativa; toda a cidade tem coordenadas, inclusive terrenos que nem foram loteados ainda (como o MBR, que fica "fora dos bairros").
- O SO usa LBA (Logical Block Addressing) para ler o MBR porque, nesse momento do boot, ainda não existe nenhum filesystem/cluster montado. Depois que o filesystem é montado, o SO passa a pedir 'clusters' mas por baixo, cada cluster continua sendo traduzido em LBA antes de chegar ao disco.
  
  important
- O processo de leitura depende muito se o sistema vai ler um cluster completo ou se ele vai ler 4 setores de um único cluster. Antes de explicar, vamos entender como o sistema vê os cluster. O diagrama abaixo mostra como é a visão do sistema operacional e a visão real do disco.
- 6aa3ef97-011c-4720-895b-121d741634c9.png
- Analogia para fixar
  Pense numa carta que você recebe pelo correio (isso é o disco devolvendo o sector 0). Dentro dela, tem um post-it escrito "vá até a Rua X, número 2048" (isso são os 4 bytes). O correio não sabe que esse post-it é um endereço — ele só entregou uma carta com papel escrito dentro. Quem lê o post-it e decide "ok, agora vou até esse endereço" é você, o leitor não o correio.
- Para manter a compatibilidade com softwares que apenas entendem a estrutura do MBR foi se desenvolvido o Protective MBR. O Protective MBR é uma estrutura colocada no LBA 0 de um disco GPT para manter compatibilidade com software antigo que só entende MBR. Ele contém uma entrada de partição com o tipo 0xEE, que indica essencialmente: “este disco está protegido; existe algo/GPT aqui que um software MBR antigo não deve tentar sobrescrever”. A própria especificação UEFI diz que o PMBR precede o GPT para manter compatibilidade com ferramentas que não entendem GPT.
- Na imagem abaixo mostra estrutura real de um PMBR.
- UEFI não usa o código de boot do Protective MBR para inicializar o sistema. Para fixar entenda que um disco GPT contém um Protective MBR no LBA 0 por razões de compatibilidade com software legado. O firmware UEFI não utiliza o código de boot desse MBR em vez disso, utiliza as estruturas GPT para localizar a EFI System Partition e iniciar o bootloader**
- Agora vamos investigar um MBR real para poder identificar o tamanho de cada partição e os seus LBAs.
- Lembre que qualquer entrada na tabela de partição tem os campos abaixo:
- {:header [[["Plain" "Offset relativo"]] [["Plain" "Campo"]] [["Plain" "Tamanho"]]], :groups [[[[["Plain" "0"]] [["Plain" "BootIndicator"]] [["Plain" "1 byte"]]] [[["Plain" "1-3"]] [["Plain" "StartingCHS"]] [["Plain" "3 bytes"]]] [[["Plain" "4"]] [["Plain" "Partition Type"]] [["Plain" "1 byte"]]] [[["Plain" "5-7"]] [["Plain" "EndingCHS"]] [["Plain" "3 bytes"]]] [[["Plain" "8-11"]] [["Plain" "StartingLBA"]] [["Plain" "4 bytes"]]] [[["Plain" "12-15"]] [["Plain" "SizeInLBA"]] [["Plain" "4 bytes"]]]]], :col_groups [3]}
- Para calcular o começo de qualquer entrada/entry use a fórmula abaixo:
  446 + (número da entry × 16).
- Exemplo se você quer saber o começo da quarta entrada o calculo deve ser:
- 446 + (3 * 16) = 494 indica o valor em decimal onde a terceira entrada começa. Para encontrar o Start LBA da quarta partição precisamos somar 494 + 8 = 502 que indica o Start LBA
  É a quarta porque o a primeira entrada da tabela começa com o indeci 0.
  Entry 1: 446 + (0 × 16) = 446 Entry 2: 446 + (1 × 16) = 462 Entry 3: 446 + (2 × 16) = 478 Entry 4: 446 + (3 × 16) = 494
- Agora vamos pesquisar o começo da tabela usando o valor 494 na ferramenta HexD.
- Depois clicar no botão ENTER o ponteiro vai se mover para o valor em Hexadecimal onde a entra começa. A quarta partition entry possui SizeInLBA = 0, portanto ela não define uma partition válida e pode ser ignorada. Isso não quer dizer que exista uma “partição não alocada”; significa que não há uma quarta partição registrada na partition table. O espaço não alocado deve ser calculado observando o fim das partitions válidas e a capacidade total do disco. Como o artefato digital $MBR foi providenciado pela platforma tryhackme.com sem o disco real não temos como validar.
- A tabela abaixo mostra os campos representados por esses bytes:
- {:header [[["Plain" "Bytes Position"]] [["Plain" "Bytes Length"]] [["Plain" "Bytes"]] [["Plain" "Field Name"]]], :groups [[[[["Plain" "0"]] [["Plain" "1"]] [["Code" "80"]] [["Plain" "Boot Indicator"]]] [[["Plain" "1-3"]] [["Plain" "3"]] [["Code" "20 21 00"]] [["Plain" "Starting CHS Address"]]] [[["Plain" "4"]] [["Plain" "1"]] [["Code" "07"]] [["Plain" "Partition Type"]]] [[["Plain" "5-7"]] [["Plain" "3"]] [["Code" "FE FF FF"]] [["Plain" "Ending CHS Address"]]] [[["Plain" "8-11"]] [["Plain" "4"]] [["Code" "00 08 00 00"]] [["Plain" "Starting LBA Address"]]] [[["Plain" "12-15"]] [["Plain" "4"]] [["Code" "00 B0 23 03"]] [["Plain" "Number of Sectors"]]]]], :col_groups [4]}
- Cada campo informa algo sobre a partition. Abaixo está uma explicação de todos esses campos:
- Boot Indicator: Este byte informa se a partition é bootable ou não. Uma partition bootable contém os arquivos necessários para iniciar o sistema operacional. O boot indicator pode assumir apenas um dos dois valores: 80 ou 00. Se for 80, significa que a partition é bootable; se for 00, significa que a partition não é bootable. Em sistemas baseados em Windows, C: é normalmente a partition bootable. Quando visualizada na partition table, essa partition terá o boot indicator definido como 80.
- Starting CHS Address: CHS, ou Cylinder Head Sector, corresponde aos 3 bytes que indicam de onde essa partition começa no disco. Ele fornece o endereço físico inicial da partition, como o número do cylinder, head e sector. Esse campo não é tão importante atualmente, pois temos o endereço lógico simplificado da partition na forma do Starting LBA Address, explicado a seguir.
- Partition Type: Cada partition usa um filesystem, como NTFS ou FAT32. Esse byte indica o tipo da partition e, tradicionalmente, identifica o filesystem utilizado. A partition usada como referência neste exemplo possui o valor 07, que corresponde a uma partition NTFS.
- Cada filesystem possui seu próprio byte identificador. Os valores usados por outros filesystems podem ser consultados na referência indicada no material original.
- Ending CHS Address: Os últimos 3 bytes do endereço CHS indicam a localização física onde a partition termina no disco. Esse campo também não é tão importante atualmente, assim como o Starting CHS Address, porque normalmente usamos o endereço lógico, ou LBA, em vez do endereço físico CHS.
- Starting LBA Address: LBA, ou Logical Block Addressing, é o endereço lógico que indica o início da partition. O Starting CHS Address também fornece o endereço inicial, mas, como o CHS representa uma localização física, torna-se mais difícil localizar a partition. Já o Starting LBA Address fornece o endereço lógico da partition, permitindo encontrá-la facilmente no disco usando um hexadecimal editor. Ao localizar a partition no disco, também é possível realizar file carving de dados pertencentes a partitions ocultas ou excluídas.
- Na partition usada como referência, o valor do LBA é 00 08 00 00. Esse endereço lógico será usado posteriormente para localizar a partition no disco.
- Number of Sectors: Estes últimos 4 bytes da partition informam o número de sectors existentes na partition. O tamanho da partition será calculado posteriormente usando esse campo.
- Overview of Bootkits
  
  Bootkits are a sophisticated type of malware that infects a computer's boot process, allowing attackers to gain control before the operating system loads. This early access enables them to bypass traditional security measures, making detection and removal particularly challenging.
- Notable Case Studies
- TDL3 Bootkit
- Description: TDL3 is one of the most infamous bootkits, known for its ability to
  infect the Master Boot Record (MBR) and maintain persistence even after
  system reinstalls.
- Impact: It was capable of stealing sensitive information and installing additional malware, leading to significant data breaches.
- BlackLotus UEFI Bootkit
- Description: Detected in late 2022, BlackLotus targets UEFI firmware, allowing it to
  operate at a level that traditional antivirus solutions cannot reach.
- Techniques: It utilizes vulnerabilities in Secure Boot to execute its payload, demonstrating the evolving nature of bootkit threats.
- Bootkitty
- Description: A recent bootkit targeting Linux systems, Bootkitty was developed as
  part of a cybersecurity training program to raise awareness about
  bootkit risks.
- Significance: Although it was primarily a proof of concept, it highlights the
  potential for bootkits to evolve and be used by malicious actors.
- Key Characteristics of Bootkits
  
  | Feature | Description |
  | ---- | ---- | ---- |
  | Persistence | Remains on the system even after OS reinstalls or updates. |
  | Stealth | Operates below the OS level, evading detection by standard security tools. |
  | Control | Can hijack system controls, install backdoors, and manipulate kernel operations. |
- Conclusion
  
  Bootkits represent a significant threat to cybersecurity, with real-world cases illustrating their potential for damage. Understanding their mechanisms and impacts is crucial for developing effective defenses against these advanced forms of malware.
- O que é o GPT (GUID PARTITION TABLE)?
- Cabeçalho GPT
- O cabeçalho GPT começa exatamente no próximo byte (o início do setor 1), depois que o Protective MBR termina em 55 AA (o final do setor 0). Ele funciona como uma espécie de planta/estrutura das partições do disco. Todos os bytes presentes no cabeçalho GPT possuem um significado específico.
- A imagem abaixo mostra o cabeçalho GPT, com esses bytes destacados em cores diferentes. Ele ocupa todo o espaço de um setor de 512 bytes, mas utiliza efetivamente apenas os primeiros 92 bytes.
- Depois desses 92 bytes, haverá bytes 00 usados como preenchimento (padding) para completar os 512 bytes totais do setor.
- Portanto, para analisar o cabeçalho GPT primário (Primary GPT Header), você precisa se concentrar apenas nos primeiros 92 bytes, pois eles contêm as informações relevantes.
- Cada um desses 14 campos possui uma função e um significado específico. A seguir, está uma explicação de cada um deles. Antes de analisá-los, é importante observar que alguns campos representam Logical Block Addresses (LBA). Para obter o endereço exato a partir de um LBA, siga o mesmo procedimento utilizado para localizar uma partição na tarefa sobre MBR: primeiro, inverta a ordem dos bytes, pois os valores estão armazenados em little-endian; depois, converta o resultado para decimal e utilize esse valor no HxD para ir diretamente à posição correspondente.
- Signature (Assinatura): contém o valor 45 46 49 20 50 41 52 54, que identifica o setor como um cabeçalho GPT. Essa sequência aparece sempre no início do GPT Header.
- Revision (Revisão): ocupa 4 bytes e informa a versão utilizada pelo GPT. Na maioria dos casos, encontramos 00 00 01 00, que corresponde à versão 1.0.
- Header Size (Tamanho do cabeçalho): indica quantos bytes são utilizados pelo GPT Header. Normalmente apresenta 5C 00 00 00. Como os bytes estão em little-endian, invertendo a sequência e convertendo para decimal temos 92 bytes, que corresponde ao tamanho do cabeçalho.
- CRC32 of Header (CRC32 do cabeçalho): armazena o valor de verificação CRC32 referente ao GPT Header. Caso esse valor não corresponda ao conteúdo esperado, pode indicar que o cabeçalho foi alterado ou sofreu algum tipo de corrupção.
- Reserved (Reservado): são bytes separados para uso futuro. A ideia é permitir possíveis modificações ou extensões do formato GPT sem precisar alterar a estrutura existente.
- Current LBA (LBA atual): representa a posição do próprio GPT Header no disco. Sabemos que o cabeçalho primário está localizado no setor 1. Isso pode ser confirmado convertendo os 8 bytes 01 00 00 00 00 00 00 00 para decimal.
- Backup LBA (LBA de backup): o esquema GPT mantém uma cópia de segurança do GPT Header. Esse campo informa em qual LBA está localizado o cabeçalho GPT de backup, que será analisado posteriormente.
- First Usable LBA (Primeiro LBA utilizável): informa o primeiro endereço LBA a partir do qual uma partição pode começar a ocupar espaço no disco.
- Last Usable LBA (Último LBA utilizável): determina o último endereço LBA disponível para as partições. Portanto, nenhuma partição deve utilizar o espaço localizado depois desse limite.
- Disk GUID (GUID do disco): possui 16 bytes e identifica exclusivamente o disco por meio de um Globally Unique Identifier (GUID). Sua finalidade é diferenciar esse disco de outros dispositivos presentes no sistema. No exemplo apresentado, os bytes são 1D F1 B0 D6 43 BE 37 4E B1 E6 38 66 EC B1 73 89. Reorganizando-os para o formato convencional de GUID, temos 1DF1B0D6-43BE-374E-B1E6-3866ECB17389.
- Partition Entry Array LBA (LBA do conjunto de entradas de partição): indica o endereço LBA onde começa o Partition Entry Array, estrutura que contém as informações das partições e que será abordada na próxima parte.
- Number of Partition Entries (Número de entradas de partição): informa quantas entradas de partição podem existir. O GPT suporta 128 entradas, enquanto o MBR tradicional possui espaço para apenas 4 entradas primárias. No exemplo, o valor é 80 00 00 00, que corresponde a 128 em decimal.
- Size of Each Partition Entry (Tamanho de cada entrada de partição): informa quantos bytes são destinados a cada entrada dentro do Partition Entry Array. No exemplo, o valor 80 00 00 00 corresponde a 128 bytes. Isso não representa o tamanho da partição; trata-se apenas do espaço reservado para cada registro de partição.
- CRC32 of Partition Array (CRC32 do conjunto de partições): contém o checksum CRC32 calculado sobre todo o Partition Entry Array. Se o valor não corresponder ao conteúdo atual, isso pode indicar que a estrutura de entradas de partição foi modificada ou corrompida.
- Link como recursos:
  https://www.binaryhexconverter.com/hex-to-decimal-converter
  https://blog.davidvarghese.com/posts/tryhackme-mbr-and-gpt-analysis/
  https://uefi.org/specs/UEFI/2.10/05_GUID_Partition_Table_Format.html
  https://tryhackme.com/room/mbrandgptanalysis
  https://cham1ndux.github.io/posts/MBRAnlysing/
  https://www.dcode.fr/endianness-converter
  https://uuidstudio.com/uuid-converter/
FAT32 Analysis
- Ameaças baseado em FAT32
- {:header [[["Plain" "Technique"]] [["Plain" "Description"]]], :groups [[[[["Plain" "T1006"]] [["Plain" "Direct Volume Access"]]] [[["Plain" "T1564.001"]] [["Plain" "Hidden Files and Directories"]]] [[["Plain" "T1564.005"]] [["Plain" "Hide Artifacts: Hidden File System"]]] [[["Plain" "T1070.004"]] [["Plain" "Indicator Removal: File Deletion"]]] [[["Plain" "T1070.006"]] [["Plain" "Indicator Removal: Timestomp"]]] [[["Plain" "T1070.009"]] [["Plain" "Clear Persistence"]]] [[["Plain" "T1027.001"]] [["Plain" "Binary Padding"]]]]], :col_groups [2]}
- O T1006 (Direct Volume Access) pode ser aplicado quando um malware acessa diretamente o dispositivo ou estruturas do volume FAT32, contornando mecanismos normais de acesso a arquivos; o T1564.001 (Hidden Files and Directories) pode ser utilizado para ocultar arquivos maliciosos no USB por meio de atributos de ocultação, fazendo com que eles não sejam exibidos normalmente pelo sistema; o T1564.005 (Hide Artifacts: Hidden File System) pode estar relacionado à ocultação de artefatos em estruturas ou áreas do sistema de arquivos, embora sua aplicação ao FAT32 dependa do mecanismo específico utilizado; o T1070.004 (Indicator Removal: File Deletion) corresponde à exclusão de arquivos para remover evidências da atividade maliciosa no dispositivo; o T1070.006 (Timestomp) consiste na alteração dos timestamps dos arquivos para dificultar a reconstrução da sequência dos acontecimentos durante uma análise forense; o T1070.009 (Clear Persistence) pode ocorrer quando mecanismos de persistência associados ao USB ou ao sistema são removidos para eliminar vestígios ou impedir uma nova execução; e o T1027.001 (Binary Padding) pode ser empregado adicionando dados irrelevantes a um executável armazenado no USB, modificando seu tamanho e características sem alterar necessariamente sua funcionalidade, podendo dificultar determinadas formas de análise ou detecção.
- As informações do boot sector que eu usei para encontrar o começo do root directory no FAT estão na tabela abaixo.
- {:header [[["Plain" "Campo"]] [["Plain" "Offset"]] [["Plain" "Tamanho"]] [["Plain" "Para que serve"]]], :groups [[[[["Plain" "Bytes Per Sector (BPB_BytsPerSec)"]] [["Plain" "0x0B"]] [["Plain" "2 bytes"]] [["Plain" "Tamanho de cada setor"]]] [[["Plain" "Reserved Sector Count (BPB_RsvdSecCnt)"]] [["Plain" "0x0E"]] [["Plain" "2 bytes"]] [["Plain" "Quantidade de setores antes da primeira FAT"]]] [[["Plain" "Number of FATs (BPB_NumFATs)"]] [["Plain" "0x10"]] [["Plain" "1 byte"]] [["Plain" "Quantidade de FATs"]]] [[["Plain" "FAT Size 32 (BPB_FATSz32)"]] [["Plain" "0x24"]] [["Plain" "4 bytes"]] [["Plain" "Tamanho de cada FAT"]]] [[["Plain" "Root Cluster (BPB_RootClus)"]] [["Plain" "0x2C"]] [["Plain" "4 bytes"]] [["Plain" "Cluster inicial do Root Directory"]]] [[["Plain" "Sectors Per Cluster (BPB_SecPerClus)"]] [["Plain" "0x0D"]] [["Plain" "1 byte"]] [["Plain" "Quantos setores existem em cada cluster"]]]]], :col_groups [4]}
- Usando esses valores - Prática.
- {:header [[["Plain" "Campo"]] [["Plain" "Offset"]] [["Plain" "Tamanho dos bytes"]] [["Plain" "Valor (Hex)"]] [["Plain" "Valor interpretado"]] [["Plain" "Uso"]]], :groups [[[[["Plain" "Bytes Per Sector"]] [["Code" "0x0B"]] [["Plain" "2 bytes"]] [["Code" "00 02"]] [["Code" "512"]] [["Plain" "Tamanho de cada setor"]]] [[["Plain" "Reserved Sector Count"]] [["Code" "0x0E"]] [["Plain" "2 bytes"]] [["Code" "7E 18"]] [["Code" "6270"]] [["Plain" "Setores reservados antes das FATs"]]] [[["Plain" "Number of FATs"]] [["Code" "0x10"]] [["Plain" "1 byte"]] [["Code" "02"]] [["Code" "2"]] [["Plain" "Quantidade de FATs"]]] [[["Plain" "FAT Size 32"]] [["Code" "0x24"]] [["Plain" "4 bytes"]] [["Code" "C1 03 00 00"]] [["Code" "961"]] [["Plain" "Tamanho de cada FAT em setores"]]] [[["Plain" "First Data Sector"]] [["Plain" "—"]] [["Plain" "—"]] [["Plain" "—"]] [["Code" "8192"]] [["Plain" "Início da Data Area"]]] [[["Plain" "Data Area Offset"]] [["Plain" "—"]] [["Plain" "—"]] [["Plain" "—"]] [["Code" "0x400000"]] [["Plain" "Offset onde começa a Data Area"]]] [[["Plain" "Root Directory"]] [["Plain" "Cluster "] ["Code" "2"]] [["Plain" "—"]] [["Plain" "—"]] [["Code" "0x400000"]] [["Plain" "Início do Root Directory"]]]]], :col_groups [6]}
- Bytes Per Sector:
  00 02 → 0x0200 → 512
- Reserved Sector Count:
  7E 18 → 0x187E → 6270
- Number of FATs:
  02 → 2 (FAT 1 e FAT2)
- FAT Size 32:
  C1 03 00 00 Hex → 0x000003C1 (Hex invertido) → 961
- FirstDataSector:
  6270 + (2 × 961)= 8192 (Decimal)
- Data Area Offset:
  8192 × 512 = 4.194.304 (Decimal) = 0x400000 (Hex)
- Root Directory:
  Cluster 2 → começa na Data Area → Offset 0400000
- This is the beginning of the data region and the root directory (remember that the first 2 clusters are virtual and reserved for system use).
- Link como recurso:
  https://tzworks.com/prototype_page.php?proto_id=55 https://www.darkreading.com/cyberattacks-data-breaches/mustang-panda-worm-driven-usb-attack https://cloud.google.com/blog/topics/threat-intelligence/unc4990-evolution-usb-malware/ https://medium.com/@rohitaswal2108/fat32-filesystem-forensics-a-complete-dfir-walkthrough-6dcd07edd312