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

      Bruno Albuquerque 7 min de leitura
      Investigação forense em NVMe: extraindo dados de múltiplos namespaces ocultos

      Guia técnico para peritos: como identificar, mapear e adquirir namespaces secundários em SSDs NVMe usando nvme-cli e evitando a perda de evidências ocultas.

      Compartilhar:

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

      02:14 da manhã. O hash da imagem forense não bate com a capacidade declarada no rótulo do SSD NVMe apreendido. O rótulo diz 4TB. A imagem raw obtida via dd tem apenas 2TB. O investigador júnior sugere que o disco está defeituoso ou que é uma falsificação de firmware. Eu abro o terminal. Não é defeito. É arquitetura. O suspeito usou Namespaces NVMe para segmentar o hardware no nível da controladora, criando "discos fantasmas" que ferramentas de imagem padrão ignoram completamente se você não souber onde olhar.

      Resumo em 30 segundos

      • O Problema: Dispositivos NVMe podem ser divididos em múltiplos Namespaces (NSIDs) isolados pela controladora. O sistema operacional os vê como discos físicos distintos (ex: /dev/nvme0n1, /dev/nvme0n2).
      • O Risco: Ferramentas de clonagem tradicionais focadas em /dev/sda ou /dev/nvme0n1 capturam apenas o primeiro namespace, deixando terabytes de evidências para trás em namespaces secundários ou desconectados.
      • A Solução: É obrigatório interrogar a controladora com nvme-cli para mapear todos os NSIDs ativos e inativos antes de iniciar a aquisição de dados.

      A anatomia do engano: Controladora vs. Namespace

      Para entender onde os dados se escondem, precisamos dissecar a topologia do NVMe. No mundo SATA legado, tínhamos uma relação 1:1 simples. Um disco físico equivalia a um dispositivo de bloco lógico. No NVMe, essa abstração morre.

      O dispositivo físico que você segura na mão é a Controladora NVMe (identificada no Linux como /dev/nvme0). Ela gerencia a memória NAND e, crucialmente, como essa memória é apresentada ao Host. A controladora pode dividir o armazenamento bruto em múltiplos Namespaces (NSIDs).

      Cada Namespace é uma quantidade de memória não volátil lógica formatada para blocos lógicos. Para o Kernel do Linux ou Windows, cada Namespace aparece como um dispositivo de bloco totalmente independente. Se um SSD de 4TB for dividido em dois namespaces de 2TB, o sistema verá dois "discos" separados. Se você clonar apenas o primeiro, perdeu metade da evidência.

      Diagrama arquitetural ilustrando como uma única Controladora NVMe gerencia múltiplos Namespaces isolados, apresentando-os como dispositivos lógicos distintos ao sistema operacional. Figura: Diagrama arquitetural ilustrando como uma única Controladora NVMe gerencia múltiplos Namespaces isolados, apresentando-os como dispositivos lógicos distintos ao sistema operacional.

      O isolamento lógico via NSID

      A especificação NVM Express permite que uma controladora suporte milhares de namespaces. Embora em cenários de consumo (Client SSDs) seja comum ver apenas um (n1), em ambientes Enterprise e em configurações de ocultação de dados, múltiplos namespaces são a norma.

      A diferença crítica entre particionamento de software (MBR/GPT) e Namespaces é o nível de abstração:

      Característica Partição de Disco (MBR/GPT) Namespace NVMe
      Nível de Criação Software (OS/Filesystem) Firmware/Controladora
      Visibilidade Visível na tabela de partição do disco Visível apenas consultando a Controladora
      Isolamento Lógico (mesmo LBA range global) Físico/Lógico (LBA ranges independentes)
      Formatação Compartilha geometria do disco Pode ter tamanhos de setor (LBA) diferentes
      Risco Forense Baixo (fácil detecção) Crítico (invisível se não sondado)

      💡 Dica Pro: Um Namespace pode ser formatado com LBA de 4096 bytes para performance de banco de dados, enquanto outro no mesmo SSD usa 512 bytes para boot legacy. Essa heterogeneidade quebra ferramentas de clonagem que assumem geometria única.

      Interrogatório cirúrgico com nvme-cli

      Não confie no lsblk ou fdisk para a triagem inicial. Eles mostram apenas o que a controladora já apresentou e o que o Kernel já anexou. Para ver a verdade, precisamos falar a língua do protocolo NVMe. A ferramenta padrão da indústria é o nvme-cli.

      1. Identificando a capacidade real da Controladora

      O primeiro passo é perguntar à controladora quantos namespaces ela suporta e qual a capacidade total bruta, ignorando o que está montado.

      Execute o comando:

      nvme id-ctrl /dev/nvme0 | grep -E "tnvmcap|nn"
      

      A saída revelará:

      • nn (Number of Namespaces): O número máximo de namespaces suportados.

      • tnvmcap (Total NVM Capacity): A capacidade total bruta em bytes.

      Se tnvmcap for 4TB e o seu dispositivo visível /dev/nvme0n1 tiver apenas 1TB, você tem 3TB de dados não contabilizados.

      2. Mapeando Namespaces Ocultos e "Detached"

      Aqui reside a armadilha. Um namespace pode ser criado, conter dados, mas estar em estado Detached (desanexado) da controladora. Nesse estado, ele não aparece em /dev/, mas os dados persistem na NAND.

      Para listar todos os namespaces, incluindo os inativos:

      nvme list-ns /dev/nvme0 --all
      

      Se você rodar apenas nvme list, verá apenas os ativos. O flag --all é a diferença entre um caso resolvido e um arquivamento por falta de provas.

      Comparação de saída de terminal: ferramentas padrão mostrando apenas um disco versus o comando nvme-cli revelando múltiplos namespaces ocultos na mesma controladora. Figura: Comparação de saída de terminal: ferramentas padrão mostrando apenas um disco versus o comando nvme-cli revelando múltiplos namespaces ocultos na mesma controladora.

      Procedimento de extração e prova matemática

      Uma vez identificados os NSIDs (ex: 1, 2 e 3), a aquisição deve ser feita individualmente. Não existe "clonar a controladora inteira" em um fluxo de bits contínuo de forma simples, pois os namespaces são entidades lógicas distintas.

      O fluxo de aquisição:

      1. Anexar Namespaces Órfãos: Se o NSID 2 aparecer na lista --all mas não em /dev/, você deve anexá-lo manualmente:

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

        Nota: Isso requer um reset da controladora ou rescan do barramento PCI em alguns casos (echo 1 > /sys/bus/pci/rescan).

      2. Imagem Forense Individual: Utilize dcfldd ou dc3dd para cada dispositivo de bloco gerado:

        dcfldd if=/dev/nvme0n1 of=caso_123_ns1.img hash=sha256
        dcfldd if=/dev/nvme0n2 of=caso_123_ns2.img hash=sha256
        
      3. Validação Matemática: A soma da capacidade de todos os namespaces extraídos deve convergir para o valor de tnvmcap (subtraindo a área de overprovisioning reservada pelo fabricante).

      ⚠️ Perigo: Jamais tente montar (mount) os namespaces durante a investigação. O comando attach-ns apenas disponibiliza o dispositivo de bloco (/dev/nvme0n2). A montagem altera metadados de acesso e destrói a integridade da prova.

      O futuro: Zoned Namespaces (ZNS) e complexidade crescente

      A indústria de armazenamento não está parada. A introdução de Zoned Namespaces (ZNS) no padrão NVMe 2.0 complica ainda mais a forense. Em ZNS, o espaço de endereçamento não é plano; ele é dividido em zonas que devem ser escritas sequencialmente.

      Ferramentas forenses atuais que tentam ler linearmente todo o LBA podem falhar ou causar erros de I/O em zonas não escritas ou offline. Investigadores precisarão em breve validar não apenas a existência de namespaces, mas o tipo de comando que cada namespace aceita (Block I/O vs. Zoned I/O vs. Key-Value).

      A era de "plugar e clonar" acabou. Se você não entende a especificação NVMe, você não está vendo os dados. Você está vendo apenas o que o firmware quer que você veja.

      Representação visual abstrata de Zoned Namespaces (ZNS), destacando a complexidade de zonas sequenciais e o desafio de acesso a áreas bloqueadas ou não escritas. Figura: Representação visual abstrata de Zoned Namespaces (ZNS), destacando a complexidade de zonas sequenciais e o desafio de acesso a áreas bloqueadas ou não escritas.

      Referências & Leitura Complementar

      • NVM Express Base Specification 2.0: Seção sobre Namespace Management e Identification.

      • RFC 4122: Para compreensão de UUIDs e identificadores únicos em volumes lógicos.

      • SNIA (Storage Networking Industry Association): Whitepapers sobre Zoned Storage e implicações de arquitetura.

      • Manpages: man nvme-id-ctrl, man nvme-attach-ns.


      O que é um Namespace NVMe e por que ele importa na forense? Um Namespace é uma partição lógica isolada no nível da controller NVMe. Diferente de partições de software (MBR/GPT), o sistema operacional vê cada Namespace como um disco físico separado (ex: /dev/nvme0n1, /dev/nvme0n2). Ignorar namespaces secundários resulta em aquisição incompleta da evidência.
      Como identificar namespaces ocultos ou inativos? Utilize o comando nvme id-ctrl para verificar o campo 'nn' (Number of Namespaces) e compare com os dispositivos listados. O comando nvme list-ns /dev/nvme0 --all revela namespaces que podem estar criados mas não anexados (detached) ao host.
      O comando dd convencional funciona para múltiplos namespaces? Não diretamente. O 'dd' ou 'dcfldd' atua sobre um dispositivo de bloco específico (ex: /dev/nvme0n1). Se o disco tiver múltiplos namespaces, você deve executar uma aquisição separada para cada identificador (n1, n2, etc.) para garantir a cópia total.
      #computação forense #nvme namespaces #recuperação de dados #nvme-cli #ssd enterprise #análise de storage
      Bruno Albuquerque
      Assinatura Técnica

      Bruno Albuquerque

      Investigador Forense de Sistemas

      "Não aceito 'falha aleatória'. Com precisão cirúrgica, mergulho em logs e timestamps para expor a causa raiz de qualquer incidente. Se deixou rastro digital, eu encontro."