Além do LBA máximo: caçando namespaces ocultos em SSDs NVMe via análise forense

Você conecta um SSD NVMe de "1TB" em sua estação forense. O rótulo físico diz 1TB. O firmware diz 1TB. Mas o sistema operacional e o lsblk insistem que existem apenas 512GB de espaço endereçável. Não há partições ocultas, não há HPA (Host Protected Area) configurado via comandos ATA legados. Onde estão os outros 512GB?

Se você está procurando apenas por partições deletadas ou slack space, você já perdeu o jogo. Bem-vindo à era da virtualização de armazenamento baseada em controladora.

Resumo em 30 segundos

A Ilusão do Bloco: Ferramentas tradicionais (dd, fdisk) operam na camada de bloco do SO e são cegas para namespaces NVMe criados mas não anexados (detached).

O Esconderijo Perfeito: Um namespace não anexado reside na memória flash, possui um ID único (NSID), mas a controladora recusa operações de I/O até que um comando administrativo específico o ative.

A Arma Forense: Apenas a interação direta com a controladora via comandos administrativos NVMe (Admin Queue) pode revelar e expor essas áreas de dados ocultas.

A Anatomia da Ocultação: Namespaces vs. Partições

Para entender como dados desaparecem sem deixar rastros na tabela de partição, precisamos dissecar a arquitetura da NVM Express (NVMe). Diferente dos discos rígidos antigos que expunham uma única superfície linear de LBAs (Logical Block Addresses), um SSD NVMe moderno funciona como um Storage Array em miniatura.

A especificação NVMe permite que a capacidade bruta da memória NAND (NVM Set) seja fatiada em múltiplos contêineres lógicos chamados Namespaces.

O ponto crítico que muitos analistas ignoram: a existência de um namespace e a sua visibilidade para o host são estados independentes.

Figura: Diagrama lógico da arquitetura NVMe: A distinção crítica entre Namespaces anexados (visíveis ao SO) e não anexados (invisíveis, mas contendo dados).

Um namespace pode estar em um de dois estados principais em relação a uma controladora:

Attached (Anexado): Mapeado para um caminho de I/O. O SO vê isso como /dev/nvme0n1.
Detached (Desanexado): O namespace existe, consome capacidade da flash, preserva dados, mas não tem caminho de I/O. O SO não cria um device node para ele.

Por que o `dd` é inútil aqui

A ferramenta dd e suas variantes forenses (dcfldd, dc3dd) operam enviando chamadas de sistema read() para um descritor de arquivo de dispositivo. Se o kernel do Linux não enumerou o dispositivo, não há descritor de arquivo.

Se um atacante ou um firmware malicioso cria um namespace de 10GB, grava dados exfiltrados nele e depois envia o comando detach, esses dados tornam-se fantasmas. Eles estão fisicamente nos chips NAND, mas logicamente inacessíveis via comandos de leitura padrão (Read LBA). Tentar fazer uma imagem bit a bit de /dev/nvme0n1 copiará apenas o namespace visível. O namespace oculto (digamos, NSID 2) está fora do alcance do endereçamento do NSID 1.

Investigação Fase 1: O Interrogatório da Controladora

A análise forense de NVMe exige que deixemos de lado as ferramentas de sistema de arquivos e falemos a língua da controladora. A ferramenta padrão da indústria para isso é o nvme-cli.

O primeiro passo é verificar a capacidade arquitetural do dispositivo. Não confie no que está montado; pergunte à controladora o que ela pode fazer.

Execute o comando de identificação da controladora:

nvme id-ctrl /dev/nvme0 -H | grep "nn "

O campo nn (Number of Namespaces) indica o número máximo de namespaces suportados.

Cenário Comum: nn : 1. O disco é simples. O que você vê é o que existe.
Cenário Suspeito: nn : 128 (ou qualquer valor > 1). Isso não prova a existência de dados ocultos, mas confirma a capacidade de ocultação.

💡 Dica Pro: Em SSDs Enterprise (Datacenter), múltiplos namespaces são comuns para isolamento de tenants. Em SSDs Client (Consumer), encontrar múltiplos namespaces ativos é extremamente raro e deve ser tratado como uma anomalia crítica.

Investigação Fase 2: Listagem de Fantasmas

O comando padrão nvme list é enganoso para forense. Ele lista apenas namespaces que o sistema operacional já reconheceu e anexou. Para ver o invisível, precisamos consultar a lista de todos os namespaces alocados na controladora, independentemente do estado de anexo.

O comando correto é:

nvme list-ns /dev/nvme0 --all

Análise de Saída: Se o seu sistema operacional mostra apenas /dev/nvme0n1, mas a saída acima retorna:

[   0]:0x1
[   1]:0x2

Você encontrou uma discrepância. O ID 0x1 corresponde ao seu volume visível. O ID 0x2 é um namespace fantasma: alocado, ocupando espaço, mas invisível ao kernel.

Figura: Evidência da discrepância: O comando lsblk (topo) mostra a visão do SO, enquanto a interrogação direta à controladora (fundo) revela o Namespace ID 2 oculto.

Investigação Fase 3: Extração e Reanexação Forçada

Uma vez identificado o NSID (Namespace ID) oculto, a extração requer uma alteração no estado do sistema. Diferente da análise de disco morto onde usamos bloqueadores de escrita, aqui precisamos enviar um comando para a controladora para tornar os dados acessíveis.

⚠️ Perigo: O procedimento a seguir altera o estado da controladora NVMe. Em um cenário jurídico rigoroso, isso deve ser documentado como uma intervenção necessária para coleta de evidência, pois não é possível ler os dados sem anexar o namespace.

O comando para trazer o fantasma à vida é attach-ns. Você precisará do ID da controladora (geralmente 0 ou 1, verifique com id-ctrl) e do NSID descoberto (no nosso exemplo, 2).

nvme attach-ns /dev/nvme0 -n 2 -c 0

Após o comando, force o kernel a re-escanear o barramento PCIe ou simplesmente execute nvme list novamente. Você deverá ver um novo dispositivo de bloco, por exemplo, /dev/nvme0n2.

Agora, e somente agora, as ferramentas tradicionais funcionam. Você pode executar o hash e a imagem:

dcfldd if=/dev/nvme0n2 of=evidence_ns2.img hash=sha256

Tabela Comparativa: Ocultação de Dados em Armazenamento

Para situar essa técnica no panorama forense, comparamos com métodos tradicionais.

Característica	Partição Deletada	HPA (Host Protected Area)	Namespace NVMe Desanexado
Localização	Tabela de Partição (MBR/GPT)	Configuração de Firmware (ATA)	Configuração de Controladora (NVMe)
Visibilidade do LBA	Visível (LBA existe, mas não alocado)	Invisível (LBA truncado no final do disco)	Inexistente (LBA isolado em outro mapa)
Detecção via `dd`	Sim (se copiar o disco inteiro)	Não (requer desbloqueio HPA)	Não (requer comando `attach`)
Complexidade	Baixa	Média	Alta
Uso Legítimo	Reinstalação de SO	Recuperação de Sistema OEM	Over-provisioning, Multi-tenant

Cenários Reais e Implicações

Não estamos falando apenas de hackers sofisticados. A "perda" de capacidade em SSDs muitas vezes ocorre por:

Provisionamento OEM: Fabricantes de laptops criam namespaces de hibernação ou recuperação e os desanexam para evitar que o usuário os formate acidentalmente.
Malware de Firmware: MoonBounce e outros implantes de nível UEFI/Firmware podem usar namespaces ocultos para armazenar payloads que sobrevivem à formatação do namespace principal (o famoso "format c:").
Erro de Configuração: Em ambientes de servidor, um administrador pode ter particionado um SSD NVMe para uso com SR-IOV (Single Root I/O Virtualization) e esquecido de liberar os namespaces não utilizados.

Figura: Fluxo de trabalho forense para NVMe: Da identificação da capacidade à extração da imagem do namespace oculto.

Veredito Operacional

A análise forense de armazenamento não pode mais tratar o dispositivo como uma "caixa preta" passiva de blocos. Com a ascensão do NVMe, ZNS (Zoned Namespaces) e futuramente CXL (Compute Express Link), o armazenamento tornou-se um sistema computacional complexo.

Se você encontrar uma discrepância de capacidade em um SSD NVMe e não auditar a lista de namespaces via comandos administrativos, sua investigação está incompleta. A ausência de evidência no /dev/nvme0n1 não é evidência de ausência no chip NAND. Adapte seus playbooks: interrogue a controladora antes de confiar no sistema operacional.

Referências & Leitura Complementar

NVM Express Base Specification 2.0: Seção sobre Namespace Management e Namespace Attachment.
SNIA (Storage Networking Industry Association): Whitepapers sobre Solid State Storage Performance Test Specification (para entender como o over-provisioning afeta a visibilidade).
Manpages: man nvme-id-ctrl, man nvme-attach-ns.

FAQ: Perguntas Frequentes sobre Forense NVMe

O que diferencia um namespace oculto de uma partição deletada?

Uma partição deletada reside em um LBA visível mas não alocado pelo sistema de arquivos; ferramentas de disco completo leem esses dados facilmente. Um namespace oculto (não anexado) é invisível para a camada de bloco do SO, pois a controladora NVMe não o expõe e rejeita qualquer I/O direcionado a ele até receber um comando de anexação específico.

O comando 'dd' consegue copiar dados de um namespace não anexado?

Não. O 'dd' opera na camada de dispositivo de bloco do kernel (/dev/nvme0n1). Se o namespace não estiver anexado à controladora e registrado no SO, não existe um caminho de arquivo para o 'dd' ler, tornando esses endereços lógicos inacessíveis por métodos convencionais.

Como identificar se um SSD suporta múltiplos namespaces?

Utilizando o comando 'nvme id-ctrl /dev/nvmeX', verifique o campo 'nn' (Number of Namespaces). Se o valor for maior que 1, o dispositivo tem capacidade arquitetural para segmentação lógica, o que justifica uma investigação mais profunda com 'nvme list-ns --all'.