Investigação forense em NVMe: extraindo dados de namespaces ocultos

Você recebe um SSD NVMe de 2 TB apreendido em uma operação de fraude corporativa. O rótulo físico indica claramente "2048 GB". Você conecta o drive ao seu duplicador forense ou estação de análise, executa um fdisk -l ou olha no gerenciador de discos, e o sistema operacional reporta apenas um dispositivo de bloco de 512 GB. Não há partições ocultas, não há HPA (Host Protected Area) visível via comandos ATA legados. Onde estão os outros 1.5 TB?

Se você apenas fizer uma imagem bit-a-bit do /dev/nvme0n1 que apareceu, você acabou de perder 75% da evidência.

A maioria dos investigadores trata SSDs NVMe como se fossem discos SATA rápidos. Isso é um erro metodológico grave. O protocolo NVMe (Non-Volatile Memory Express) introduziu abstrações lógicas — especificamente os Namespaces — que permitem que dados residam no mesmo chip NAND físico, mas permaneçam completamente invisíveis ao sistema operacional e às ferramentas de imagem padrão se não forem explicitamente enumerados e anexados pelo controlador.

Resumo em 30 segundos

A Ilusão do Dispositivo Único: Ao contrário de discos rígidos que expõem toda a geometria LBA (Logical Block Addressing) de uma vez, controladores NVMe podem gerenciar múltiplos "discos lógicos" (Namespaces) isolados.

Cegueira das Ferramentas: Ferramentas de imagem tradicionais (dd, dc3dd) e muitos bloqueadores de escrita de hardware enxergam apenas namespaces ativos e anexados.

A Chave é o Controlador: A investigação deve começar interrogando o controlador NVMe (identify-controller) para revelar a capacidade total real versus a capacidade alocada.

A arquitetura do silêncio: Controlador vs. Namespaces

Para entender onde os dados se escondem, precisamos dissecar como o NVMe organiza o armazenamento. Em discos legados (HDD/SATA SSD), tínhamos uma relação linear: o disco físico expunha um intervalo contínuo de setores. Partições eram apenas divisões de software escritas na tabela MBR ou GPT.

No NVMe, a divisão ocorre no firmware do controlador.

Subsistema NVMe: A entidade física completa (o cartão M.2 ou drive U.2).
Controlador: O cérebro que gerencia a E/S (Entrada e Saída).
Namespaces (NS): Quantidades de memória não volátil formatadas em blocos lógicos.

Um único controlador pode gerenciar até 1024 namespaces (embora a maioria dos drives de consumo suporte menos). O ponto crítico é: um namespace pode existir, conter dados, mas não estar anexado a nenhum controlador. Nesse estado, ele é um "fantasma". O OS não cria um /dev/nvme0n2, e ferramentas de varredura de disco nem sabem que ele existe.

Figura: Arquitetura lógica de um SSD NVMe: enquanto o Namespace 1 é visível ao OS, os Namespaces 2 e 3 permanecem ocultos e inacessíveis sem comandos administrativos específicos.

O mito do HPA em NVMe

Em discos SATA, suspeitos usavam o HPA (Host Protected Area) ou DCO (Device Configuration Overlay) para cortar o final do disco e esconder dados. Ferramentas como hdparm resolviam isso facilmente.

No NVMe, o conceito de HPA não existe na especificação. A ocultação é feita através do gerenciamento de namespaces (Namespace Management). Um usuário mal-intencionado pode criar um namespace, gravar dados incriminatórios, e então enviar um comando para "desanexar" (detach) esse namespace do controlador. Os dados persistem na NAND, mas o caminho de acesso desaparece.

Detecção de anomalias: Onde os números não batem

A primeira etapa de qualquer análise forense em NVMe não é a imagem, é o reconhecimento via comandos de administração (Admin Commands). Você precisa conversar diretamente com o controlador, ignorando a camada de bloco do OS.

A ferramenta padrão-ouro para isso é o nvme-cli em ambiente Linux.

1. Interrogando o Controlador

O comando nvme id-ctrl /dev/nvme0 retorna a estrutura de dados de identificação do controlador. O campo que procuramos obsessivamente é o tnvmcap (Total NVM Capacity).

# Exemplo de saída truncada de uma investigação real
root@forensics:~# nvme id-ctrl /dev/nvme0
...
sn        : S465NF0M123456
mn        : Samsung SSD 970 EVO Plus 2TB
fr        : 2B2QEXM7
...
tnvmcap   : 2048408248320  <-- CAPACIDADE TOTAL FÍSICA (bytes)
unvmcap   : 0              <-- CAPACIDADE NÃO UTILIZADA
...

Se o tnvmcap reporta 2TB (aprox. 2.048 x 10^12 bytes), mas o seu sistema operacional vê apenas um namespace de 500GB, você tem 1.5TB de "matéria escura" unaccounted for.

💡 Dica Pro: O valor de tnvmcap é em bytes brutos. Converta sempre para GiB/TiB para comparar com o que o OS reporta. Se tnvmcap > soma das capacidades dos namespaces visíveis, existe armazenamento oculto ou over-provisioning excessivo.

2. Listagem de Namespaces: Ativos vs. Alocados

Aqui reside a pegadinha que derruba muitos peritos. O comando nvme list mostra apenas namespaces ativos e anexados. Para ver namespaces ocultos, você deve listar todos os alocados.

O comando correto é: nvme list-ns /dev/nvme0 --all

Se o resultado mostrar IDs que não aparecem no /dev/, como [ 2 ] ou [ 0x10 ], você encontrou o esconderijo.

Tabela Comparativa: Ocultação SATA vs. NVMe

Para situar a evolução da técnica de anti-forense, veja como o cenário mudou:

Característica	SATA (Legacy)	NVMe (Moderno)
Método de Ocultação	HPA (Host Protected Area) / DCO	Namespaces Desanexados ou Inativos
Visibilidade no OS	Disco parece menor (LBA truncado)	Dispositivo extra não aparece (NSID ausente)
Persistência	Configuração no firmware do disco	Configuração na tabela de namespaces do controlador
Detecção	Comparar `Max LBA` vs `Native Max LBA`	Comparar `tnvmcap` vs Namespaces Ativos
Comando de Recuperação	`hdparm -N` (Set Max Address)	`nvme attach-ns` (Namespace Attachment)
Risco Forense	Baixo (ferramentas automatizadas detectam)	Alto (requer intervenção manual e hardware compatível)

Procedimento de Extração: Cirurgia em Linha de Comando

Uma vez identificado um namespace oculto (digamos, NSID 2), o objetivo é extrair os dados sem alterar a integridade da prova.

⚠️ Perigo: A maioria dos bloqueadores de escrita (write blockers) USB convencionais NÃO permite o envio de comandos de administração NVMe necessários para anexar um namespace. Você precisará de um bloqueador que suporte "NVMe Passthrough" ou realizar a operação em um ambiente controlado de "Live Forensics" com bloqueio de software validado, ciente dos riscos.

Passo 1: Anexar o Namespace

Se o namespace existe mas está desanexado, precisamos associá-lo ao controlador para que o OS possa criar o dispositivo de bloco.

# Sintaxe: nvme attach-ns <dispositivo> --namespace-id=<nsid> --controllers=<ctrl_id>
root@forensics:~# nvme attach-ns /dev/nvme0 -n 2 -c 0
attach-ns: Success, nsid:2

Imediatamente após esse comando, o kernel do Linux deve registrar o evento e criar /dev/nvme0n2. Verifique o dmesg para confirmar o timestamp exato da detecção.

Passo 2: Validação de Geometria

Antes de gerar a imagem, valide o tamanho e o formato LBA do novo namespace:

nvme id-ns /dev/nvme0 -n 2

Verifique o LBA Format. Alguns namespaces ocultos podem estar formatados com tamanhos de setor exóticos (ex: 4096 + metadata bytes) para dificultar a leitura por ferramentas padrão que esperam 512 bytes.

Figura: Terminal Linux demonstrando a detecção de um namespace oculto (NSID 2) que não aparecia na listagem padrão, revelando a discrepância forense.

Passo 3: Aquisição da Imagem

Com o dispositivo /dev/nvme0n2 visível, proceda com a aquisição forense padrão, mas prefira ferramentas que lidem bem com erros de I/O, pois namespaces ocultos podem ter sido criados em áreas degradadas da NAND.

dc3dd if=/dev/nvme0n2 of=/caso/evidencia_ns2.img hash=sha256 log=/caso/log_ns2.txt

O futuro da ofuscação: NVM Sets e Zoned Namespaces

A especificação NVMe 1.4 e 2.0 trouxe conceitos que complicam ainda mais a análise: NVM Sets e Endurance Groups.

Essas estruturas permitem isolar fisicamente os dados. Um NVM Set pode ser configurado para usar canais específicos do controlador e dies de flash dedicados. Isso significa que um namespace pode estar fisicamente segregado de outro.

Para o investigador, isso é crucial porque afeta a performance e a recuperação de dados. Se um chip de memória específico falhar, você pode perder apenas o NVM Set A (Namespace 1), enquanto o NVM Set B (Namespace 2 oculto) permanece intacto.

Ainda mais complexo é o advento dos Zoned Namespaces (ZNS). Diferente do armazenamento de bloco convencional, o ZNS exige que as gravações sejam sequenciais dentro de zonas. Se você encontrar um drive ZNS, a imagem linear tradicional (dd) funcionará, mas a interpretação dos dados (file system analysis) exigirá suporte a sistemas de arquivos compatíveis com ZNS (como F2FS ou Btrfs com suporte a zonas), caso contrário, você verá apenas estruturas que parecem corrompidas.

Figura: Visualização de NVM Sets: caminhos de dados isolados fisicamente dentro do SSD, onde diferentes namespaces ocupam chips de memória distintos.

Veredito e Recomendação Operacional

A era de conectar um disco e apertar "Start" no software forense acabou. Com a proliferação de SSDs NVMe em laptops corporativos e servidores, a ocultação de dados via manipulação de namespaces deixou de ser teórica para se tornar uma capacidade nativa do hardware, acessível via comandos simples.

Minha recomendação para sua próxima aquisição:

Abandone a confiança cega no OS: O que o Windows ou Linux montam automaticamente é apenas o que o controlador quer que eles vejam.
Adote o nvme-cli no triage: Incorpore a verificação de tnvmcap e list-ns --all no seu checklist padrão de pré-imagem.
Atualize seu Hardware: Verifique se seus bloqueadores de escrita suportam a enumeração de múltiplos namespaces. Se não suportam, você está validando cegamente uma evidência incompleta.

A negligência em verificar a geometria lógica completa de um dispositivo NVMe não é apenas um erro técnico; é uma falha na cadeia de custódia da verdade.

Referências & Leitura Complementar

NVM Express Base Specification 2.0: Seções sobre Namespace Management e Identify Controller Data Structure. Disponível em nvmexpress.org.
SNIA (Storage Networking Industry Association): Whitepapers sobre NVM Sets e Endurance Groups.
Man Pages: man nvme-id-ctrl, man nvme-attach-ns.

FAQ: Perguntas Frequentes sobre Forense em NVMe

O que diferencia um Namespace NVMe de uma partição comum?

Partições são estruturas lógicas de software (tabelas MBR/GPT) escritas nos primeiros setores de um disco. Namespaces são divisões definidas no nível do hardware/firmware pelo controlador NVMe. Para o sistema operacional, cada namespace é apresentado como um disco físico totalmente independente (ex: /dev/nvme0n1, /dev/nvme0n2), com sua própria geometria LBA.

O HPA (Host Protected Area) existe em discos NVMe?

Não da mesma forma que existia no padrão SATA. O conceito de ocultar capacidade no final do disco foi substituído pela arquitetura de Namespaces. Em NVMe, a ocultação é realizada criando Namespaces que são mantidos inativos ou desanexados do controlador, tornando-os invisíveis ao OS até que um comando de administração específico reverta esse estado.

Bloqueadores de escrita (Write Blockers) detectam namespaces ocultos?

A maioria dos bloqueadores de escrita comerciais mais antigos ou básicos enumera apenas o primeiro namespace ativo (NSID 1). Para detectar e adquirir namespaces ocultos, é necessário hardware forense avançado que suporte a enumeração completa da especificação NVMe ou a validação manual cuidadosa utilizando comandos de "admin passthrough" em ambiente Linux controlado.