Caçando bytes fantasmas: análise forense de namespaces ocultos em NVMe

03:14 da manhã. O sistema de monitoramento dispara um alerta de capacidade em um servidor de banco de dados crítico recém-provisionado. O datasheet do fabricante do SSD NVMe promete 3.84 TB de capacidade bruta. O sistema operacional, no entanto, insiste que existem apenas 3.2 TB disponíveis.

A primeira reação do administrador júnior é culpar a conversão de decimal para binário (GB vs GiB) ou o overhead do sistema de arquivos. Matemática básica refuta isso: a conta não fecha. Faltam 600 GB. Eles não estão em partições não alocadas. Eles não estão em áreas reservadas pelo sistema de arquivos.

Para o kernel do Linux, esses gigabytes simplesmente não existem. Mas a física do NAND Flash não mente. Se os chips estão lá, os dados podem estar lá. Bem-vindo ao mundo dos Namespaces NVMe, onde a arquitetura de armazenamento moderna permite esconder terabytes de dados sob o nariz do seu sistema operacional.

Resumo em 30 segundos

O problema: Ferramentas padrão como fdisk e lsblk enxergam apenas namespaces anexados. Um SSD pode ter múltiplos namespaces ocultos na controladora.

A causa: A especificação NVMe permite segmentar o armazenamento físico em volumes lógicos isolados (Namespaces) que podem estar "desanexados" do host, tornando-os invisíveis ao OS.

A solução: É necessário interagir diretamente com a controladora via nvme-cli para auditar a alocação real de LBAs e forçar a anexação desses volumes fantasmas.

A ilusão do dispositivo de bloco único

Durante décadas, fomos condicionados a tratar discos rígidos como uma única extensão linear de setores (LBA 0 até LBA N). O protocolo SATA reforçava essa visão simplista. Com a chegada do NVMe (Non-Volatile Memory Express), a abstração mudou radicalmente.

Um SSD NVMe não é apenas um "disco". É um subsistema de armazenamento complexo, composto por uma Controladora (o cérebro) e o NVM Media (o armazenamento físico). A controladora expõe o armazenamento através de Namespaces.

Quando você vê /dev/nvme0n1 no Linux, você não está vendo o disco inteiro. Você está vendo o Namespace 1 (n1) da Controladora 0 (nvme0). Se o fabricante, ou um atacante sofisticado, criou um Namespace 2 e não o anexou à controladora, ele é, para todos os fins práticos do kernel, um fantasma. Ele consome energia, ocupa células de flash, mas não responde a comandos de leitura/escrita padrão.

Figura: A arquitetura NVMe permite que a controladora gerencie múltiplos namespaces, onde apenas os anexados são visíveis ao Host.

Auditoria profunda com nvme-cli

Esqueça o parted. Para ver o que a controladora está escondendo, precisamos falar a língua dela. A ferramenta padrão da indústria para isso é o nvme-cli.

O primeiro passo em uma investigação forense de armazenamento é interrogar a controladora sobre suas capacidades, não sobre o que ela está apresentando no momento.

O comando crucial é:

sudo nvme id-ctrl /dev/nvme0 | grep nn

O campo nn (Number of Namespaces) indica quantos namespaces a controladora suporta. Se este número for maior que 1, sua suspeita deve aumentar. No entanto, suporte não significa uso. Para verificar a alocação real, usamos um comando que lista todos os namespaces, inclusive os inativos:

sudo nvme list-ns /dev/nvme0 --all

Se a saída retornar [ 1, 2 ] mas o seu lsblk mostrar apenas nvme0n1, você acabou de encontrar o local do crime. O namespace ID 2 existe, está alocado, mas está invisível.

💡 Dica Pro: Em SSDs Enterprise (Datacenter), é comum encontrar namespaces ocultos usados para Over-provisioning dinâmico ou áreas de log de depuração do fabricante. Em cenários de segurança, isso é um vetor perfeito para exfiltração de dados ou persistência de malware.

Tabela Comparativa: Partição vs. Namespace

Para dissipar a confusão comum entre particionamento lógico (software) e segmentação de namespace (firmware), analise as diferenças estruturais:

Característica	Partição (GPT/MBR)	Namespace NVMe
Camada de Atuação	Sistema Operacional / Kernel	Controladora do SSD / Firmware
Visibilidade	Visível em editores de partição	Invisível se não anexado (Detached)
Isolamento	Lógico (mesma fila de I/O)	Físico/Lógico (Filas de submissão dedicadas)
Persistência	Apagada com `wipefs`	Sobrevive a formatação padrão do OS
Segurança	Criptografia por volume de software	Pode ter chaves de criptografia de hardware distintas

Materializando o fantasma

Uma vez identificado o NSID (Namespace ID) oculto, o próximo passo forense é anexá-lo para análise. Isso força a controladora a mapear aquele intervalo de LBAs para o host.

O comando para anexar o namespace 2 à controladora 0 seria:

sudo nvme attach-ns /dev/nvme0 --namespace-id=2 --controllers=0

Imediatamente após esse comando, o dmesg do kernel deve registrar um evento de hotplug, detectando um "novo" dispositivo de bloco, geralmente /dev/nvme0n2.

Agora que o dispositivo é visível, a aquisição forense padrão se aplica. Não tente montar o sistema de arquivos imediatamente, pois isso pode alterar metadados de acesso. A abordagem correta é criar uma imagem bit a bit ou realizar uma análise hexadecimal direta para identificar assinaturas de arquivos.

sudo hexdump -C -n 512 /dev/nvme0n2

Figura: O momento da verdade: anexando o namespace oculto e revelando dados brutos que escapavam à detecção do sistema operacional.

Se você encontrar zeros, pode ser apenas espaço reservado. Mas se encontrar entropia alta (dados criptografados) ou cabeçalhos de sistema de arquivos, você provou que o dispositivo continha dados ocultos que sobreviveriam a uma formatação convencional do namespace principal (n1).

O perigo da sanitização incompleta

Este cenário expõe uma falha crítica nos processos de decommissioning (descarte) de servidores. A maioria das ferramentas de "Secure Erase" antigas opera no nível do dispositivo de bloco visível. Rodar um dd if=/dev/zero ou shred no /dev/nvme0n1 não toca nos dados armazenados no /dev/nvme0n2.

Para garantir que um SSD NVMe esteja realmente limpo, você deve usar os comandos de sanitização nativos da especificação NVMe, que instruem o firmware a limpar todas as células de memória, independentemente da alocação de namespaces.

O comando nvme sanitize é a única garantia real. Ele possui modos distintos:

Block Erase: Apaga eletricamente os blocos (lento, mas seguro).
Crypto Erase: Troca a chave de encriptação interna da mídia (instantâneo, torna os dados irrecuperáveis).
Overwrite: Sobrescreve com padrão de dados (menos comum em SSDs modernos devido ao desgaste).

⚠️ Perigo: O comando nvme format é diferente de nvme sanitize. O format pode ser aplicado por namespace. Se você formatar apenas o NSID 1, o NSID 2 permanece intacto. O sanitize é uma operação global da controladora.

Figura: A diferença crítica entre limpar o mapa e limpar o território: Sanitização atua no nível físico global.

O veredito

A complexidade dos dispositivos de armazenamento modernos transformou a análise forense e a segurança de dados. Não estamos mais lidando com discos magnéticos passivos, mas com computadores especializados rodando sistemas operacionais proprietários (firmware) que gerenciam a alocação de dados de forma opaca.

Ignorar a existência de múltiplos namespaces em auditorias de segurança ou processos de limpeza de dados é um convite ao desastre. Os bytes fantasmas são reais, e a única ferramenta capaz de caçá-los é o conhecimento profundo da especificação que os rege. Na próxima vez que a capacidade do disco não bater, não culpe a matemática. Culpe a controladora.

Referências & Leitura Complementar

NVM Express Base Specification 2.0: Seção sobre Namespace Management e Sanitize Operations.
SNIA (Storage Networking Industry Association): Whitepapers sobre Data Sanitization.
RFC 4086: Randomness Requirements for Security (relevante para análise de entropia em namespaces criptografados).
Manuais do nvme-cli: Documentação oficial da ferramenta de userspace NVMe para Linux.

Perguntas Frequentes (FAQ)

O que diferencia um Namespace oculto de uma partição não alocada?

Uma partição não alocada é visível na tabela de partições (GPT/MBR) do sistema operacional e pode ser manipulada por ferramentas comuns. Um Namespace oculto (não anexado) reside na camada da controladora NVMe e é totalmente invisível para o kernel do OS até que seja explicitamente anexado via comandos administrativos NVMe, operando em um nível lógico inferior ao das partições.

É possível esconder malware em áreas de Over-provisioning?

Sim. Pesquisas de segurança demonstram que firmwares modificados ou comprometidos podem utilizar áreas de reserva (Over-provisioning) ou namespaces não mapeados para garantir a persistência de código malicioso. Esses dados escapam de detecções tradicionais de antivírus e EDRs, pois estas ferramentas escaneiam apenas volumes montados e visíveis ao sistema de arquivos.

O comando 'Secure Erase' padrão limpa todos os namespaces?

Depende da implementação e do comando utilizado. O comando `Format NVM` pode ser aplicado a um namespace específico, deixando outros intactos. Para garantia forense absoluta, deve-se usar o comando `Sanitize` (se suportado pela controladora), que instrui o dispositivo a limpar globalmente todos os caches, namespaces, áreas de reserva e chaves de criptografia de uma só vez.