Evidência autodestrutiva: o impacto forense do TRIM e garbage collection em SSDs

O cenário é familiar para qualquer investigador de resposta a incidentes: um servidor comprometido, uma desconexão abrupta da rede e a apreensão física do hardware para análise. Em uma era dominada por discos rígidos magnéticos (HDDs), o tempo estava ao nosso lado. Os dados deletados permaneciam nos pratos magnéticos, aguardando pacientemente a recuperação via escultura de dados (file carving). No entanto, a onipresença da tecnologia flash NAND e o protocolo NVMe alteraram fundamentalmente essa dinâmica.

Hoje, o dispositivo de armazenamento não é mais um repositório passivo; é um sistema computacional ativo que trabalha contra a preservação da evidência. O firmware do SSD, em sua busca incessante por performance e longevidade das células, atua como um cúmplice involuntário do atacante, destruindo artefatos forenses minutos — ou até segundos — após um comando de exclusão.

Resumo em 30 segundos

O comando TRIM é o gatilho: Ele informa ao controlador do SSD quais blocos de dados não são mais necessários pelo sistema operacional, marcando-os para exclusão física.

Garbage Collection é o executor: Processos de fundo do firmware reorganizam dados e apagam fisicamente as células marcadas pelo TRIM, tornando a recuperação impossível via software.

A imagem forense tradicional falha: Técnicas de clonagem bit-a-bit podem resultar em apenas zeros onde antes havia evidências, devido à funcionalidade "Deterministic Read Zero after TRIM".

A mecânica do extermínio: TRIM e UNMAP

Para entender a perda de evidências, precisamos dissecar como a memória flash opera. Diferente dos HDDs, onde a gravação pode sobrescrever dados antigos diretamente, a memória NAND exige que uma célula seja apagada antes de ser reescrita. O processo de apagar é lento e ocorre em blocos grandes, enquanto a escrita ocorre em páginas menores.

Para evitar a degradação de performance de escrita (write amplification), os sistemas operacionais modernos utilizam o comando TRIM (em interfaces SATA) ou UNMAP (em interfaces SCSI/SAS) e Deallocate (em NVMe).

Quando um atacante apaga seus logs de acesso ou ferramentas de exploração (rm -rf /var/log/auth.log), o sistema de arquivos envia um comando TRIM ao controlador do SSD. A partir desse milissegundo, o controlador sabe que aqueles dados são inválidos.

Figura: Fluxo lógico da destruição de dados: do comando do SO à limpeza física pelo controlador.

O engano do controlador: Deterministic Read Zero after TRIM (RZAT)

Aqui reside o pesadelo forense. A maioria dos SSDs modernos implementa uma funcionalidade chamada Deterministic Read Zero after TRIM (RZAT).

Assim que o comando TRIM é processado, o controlador altera a tabela de tradução lógica-para-física (FTL). Se uma ferramenta forense tentar ler aqueles setores — mesmo antes de o Garbage Collection ter apagado fisicamente os elétrons das células NAND — o controlador interceptará a leitura e retornará uma sequência de zeros.

⚠️ Perigo: Uma imagem forense bit-a-bit realizada após o TRIM pode conter gigabytes de zeros onde os dados ainda residem fisicamente, mas estão logicamente inacessíveis pela interface padrão.

Garbage collection: a limpeza da cena do crime

Enquanto o TRIM é o comando administrativo, o Garbage Collection (GC) é a equipe de limpeza física. O GC é uma função autônoma do firmware do drive. Ele acorda durante períodos de ociosidade (idle time) ou quando o espaço livre atinge níveis críticos.

O processo envolve:

Ler as páginas válidas de um bloco misto (dados válidos + dados inválidos).
Copiar as páginas válidas para um novo bloco limpo.
Apagar eletricamente o bloco original inteiro.

Uma vez que o passo 3 ocorre, a recuperação de dados torna-se impossível, mesmo com técnicas avançadas de chip-off (remoção dos chips de memória para leitura direta em leitores especializados), pois a carga elétrica que representava os bits foi resetada.

Comparativo: persistência de dados HDD vs. SSD

A diferença na volatilidade da evidência entre as tecnologias de armazenamento é brutal.

Característica	HDD (Magnético)	SSD (Flash NAND)
Ação ao Deletar	Marca entrada na MFT/FAT como livre. Dados permanecem.	Envia TRIM. Controlador marca páginas como inválidas.
Recuperabilidade	Alta. Dados persistem até serem sobrescritos por novos arquivos.	Baixa a Nula. Depende da janela de tempo do Garbage Collection.
Resposta à Leitura	Retorna os dados antigos (se não sobrescritos).	Retorna Zeros (RZAT) ou dados antigos (Non-Deterministic), dependendo do firmware.
Interferência do Hardware	Passiva. O disco não altera dados sozinho.	Ativa. O firmware move e apaga dados sem intervenção do host.

O dilema da aquisição: desligar ou não desligar?

Em investigações tradicionais, o "pull the plug" (puxar o cabo de energia) era frequentemente debatido contra o desligamento suave (graceful shutdown). No contexto de SSDs e NVMe, essa decisão é crítica.

Um desligamento suave via sistema operacional dispara rotinas de limpeza. O SO desmonta os sistemas de arquivos, realiza o flush de caches e, crucialmente, pode enviar uma rajada final de comandos TRIM para setores pendentes.

💡 Dica Pro: Em cenários envolvendo SSDs, a interrupção abrupta de energia (hard power-off) é geralmente preferível para impedir que o controlador execute rotinas finais de manutenção e GC. No entanto, isso carrega o risco de corrupção da tabela de tradução (FTL), o que pode "brickar" o SSD, exigindo reparo especializado antes da extração.

Bloqueadores de escrita e a autonomia do drive

Mesmo após a remoção do drive, o perigo persiste. Ao conectar o SSD a um bloqueador de escrita (write blocker) forense para a criação da imagem, nós fornecemos energia ao dispositivo.

Se o bloqueador de escrita apenas impede comandos de escrita vindos do computador forense, ele não impede que o firmware do próprio SSD execute o Garbage Collection internamente. Se o drive foi desligado abruptamente com tarefas de GC pendentes, ao receber energia novamente, ele pode retomar a destruição de dados "inválidos" antes que a imagem seja concluída.

Figura: Arquitetura interna do controlador gerenciando a área de Over-provisioning durante o processo de limpeza.

Enterprise vs. Client: a agressividade do firmware

Nem todos os SSDs se comportam da mesma maneira. A classe do dispositivo dita a agressividade da limpeza.

SSDs de Consumidor (Client): Tendem a realizar o GC durante períodos de ociosidade para não impactar a experiência do usuário. Existe uma chance maior de recuperação se o computador foi desligado logo após o incidente.
SSDs Enterprise (Datacenter): Priorizam a performance de escrita sustentada. Para garantir que sempre haja blocos livres para novas gravações rápidas, o GC é extremamente agressivo e contínuo. A área de Over-provisioning (espaço reservado) é maior, facilitando a rotação e eliminação rápida de dados marcados.

Em um ambiente de servidor com SSDs Enterprise, a janela de recuperação de um arquivo deletado pode ser de apenas alguns segundos.

O futuro: Zoned Namespaces (ZNS) e complexidade

A evolução do armazenamento traz novos desafios. A tecnologia Zoned Namespaces (ZNS), padronizada pela organização NVM Express, altera a responsabilidade do gerenciamento de dados.

No ZNS, o software (host) e o SSD colaboram na alocação de dados em zonas sequenciais. Isso reduz a necessidade de Over-provisioning massivo e GC interno excessivo, pois o host escreve sequencialmente e reseta zonas inteiras.

Para a forense, isso significa que a análise de "espaço não alocado" muda drasticamente. Não estamos mais procurando por fragmentos espalhados aleatoriamente por um algoritmo de wear leveling opaco, mas sim analisando o estado de zonas inteiras gerenciadas pelo sistema de arquivos ou aplicação.

Figura: Comparação estrutural: Zoned Namespaces (ZNS) versus mapeamento de blocos convencional.

Estratégia de defesa

A volatilidade inerente aos SSDs modernos exige uma mudança de paradigma na resposta a incidentes. A confiança na recuperação de dados pós-incidente ("vamos recuperar os logs deletados do disco") é uma estratégia falha e obsoleta.

A única defesa viável contra a evidência autodestrutiva é a exportação de logs em tempo real. Arquiteturas de segurança devem priorizar o envio de logs de auditoria, sistema e aplicações para um servidor syslog remoto, SIEM ou armazenamento imutável (WORM) instantaneamente.

Se você está dependendo da análise física de um SSD NVMe para entender o que aconteceu ontem, o firmware do dispositivo provavelmente já garantiu que você não encontre nada além de zeros.

Referências & Leitura Complementar

NVM Express Base Specification, Revision 2.0 (2021). Seção sobre o comando Dataset Management e Deallocate.
NIST SP 800-88 Rev. 1, Guidelines for Media Sanitization. Detalha os métodos de purga e destruição para mídia flash.
SCSI Block Commands - 4 (SBC-4). Define o comando UNMAP para dispositivos de armazenamento enterprise.
Gubanov, Y. (2023). SSD Forensics: The TRIM/UNMAP Problem. Belkasoft Research.

É possível recuperar dados de um SSD após o comando TRIM?

Na grande maioria dos casos, não. Uma vez que o comando TRIM é executado e o controlador processa o Garbage Collection, as células de memória são fisicamente apagadas (resetadas para 1s), tornando a recuperação via software impossível. Apenas técnicas avançadas de chip-off podem ter sucesso marginal se o GC ainda não tiver ocorrido, mas o recurso RZAT (Read Zero After TRIM) impedirá a leitura via interface padrão.

Como o Garbage Collection difere entre SSDs Enterprise e de Consumidor?

SSDs Enterprise (Datacenter) possuem controladores mais agressivos e maior área de Over-provisioning para manter a performance de escrita constante, o que significa que a destruição de dados deletados ocorre muito mais rapidamente do que em drives de consumidor, que podem adiar o processo para momentos de ociosidade do sistema.

O que fazer ao identificar um incidente em um servidor com SSD?

Evite o desligamento suave (shutdown) do sistema operacional, pois isso dispara comandos de limpeza e flush de cache. A recomendação forense atual tende para o corte abrupto de energia (hard power-off) para impedir que o controlador execute rotinas finais de manutenção, seguido de clonagem via bloqueadores de escrita de hardware, ciente de que a simples alimentação do drive pode retomar o GC interno.