Capítulo 8 — Arquitetura de computadores
Mapa da aula
Aula 08 publicada. Mapa, exemplo, EX022.
flowchart TD
N0["8.1 Bytes e palavras"]
N1["8.2 FILETIME"]
N2["Laboratório — decodificando um FILETIME"]
N3["8.3 Lendo o resultado"]
N4["8.4 Hierarquia de memória"]
N5["8.5 A CPU e a evidência"]
N6["8.6 Fusos horários"]
N7["Outras épocas"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX022"]
Desenho lógico
flowchart LR
N0["8.1 Bytes e palavras"]
N1["8.2 FILETIME"]
N2["Laboratório — decodificando um FILETIME"]
N3["8.3 Lendo o resultado"]
N4["8.4 Hierarquia de memória"]
N5["8.5 A CPU e a evidência"]
N6["8.6 Fusos horários"]
N7["Outras épocas"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX022"]
[8.1 Bytes e palavras]
|
v
[8.2 FILETIME]
|
v
[Laboratório — decodificando um FILETIME]
|
v
[8.3 Lendo o resultado]
|
v
[8.4 Hierarquia de memória]
|
v
[8.5 A CPU e a evidência]
|
v
[8.6 Fusos horários]
|
v
[Outras épocas]
|
v
[Exemplo resolvido] --> [Exercício EX022]
Objetivos de aprendizagem
Você vai (1) explicar a ordem dos bytes; (2) decodificar um FILETIME do Windows; (3) relacionar a hierarquia de memória com a volatilidade; (4) reconhecer erros causados por interpretação errada dos dados.
8.1 Bytes e palavras
Os computadores armazenam números de vários bytes numa ordem de bytes. O x86 e a maioria dos sistemas ARM de uso comum são little-endian: o byte menos significativo vem primeiro. As ferramentas forenses precisam conhecer a ordem para ler as estruturas corretamente. O valor de 32 bits 0x12345678 é armazenado como 78 56 34 12 numa máquina little-endian e como 12 34 56 78 numa big-endian. Os protocolos de rede tradicionalmente usam big-endian, de modo que uma única investigação pode envolver as duas ordens. O interpretador de Priya recebe a ordem dos bytes como argumento explícito em vez de presumir uma, e seus testes incluem uma estrutura cujo valor difere visivelmente nas duas leituras.
8.2 FILETIME
O Windows registra muitos carimbos de tempo como uma contagem de 64 bits de intervalos de 100 nanossegundos desde 1º de janeiro de 1601 UTC, armazenada em little-endian. Carrier (2005) descreve como as estruturas do sistema de arquivos armazenam esses valores no disco. A época incomum vem do ciclo do calendário gregoriano usado quando o formato foi projetado. Converter significa dividir por dez milhões para obter segundos e depois somar o resultado a 1601-01-01. Como a contagem é em unidades de 100 nanossegundos, alguns sistemas de arquivos armazenam mais precisão do que a exibição mostra, e algumas ferramentas a truncam. Priya mantém o inteiro bruto em suas notas ao lado da data convertida.
Laboratório — decodificando um FILETIME
"""Decode a little-endian Windows FILETIME from synthetic bytes."""
import struct, datetime
raw = bytes.fromhex("00e0c9a3c4d3d901")
ticks = struct.unpack("<Q", raw)[0]
dt = datetime.datetime(1601, 1, 1, tzinfo=datetime.timezone.utc) + datetime.timedelta(microseconds=ticks // 10)
print("raw bytes:", raw.hex())
print("ticks (100 ns):", ticks)
print("UTC:", dt.isoformat())
big = struct.unpack(">Q", raw)[0]
print("misread as big-endian ticks:", big)
Execute com python3 lab_filetime.py. Saída verificada:
raw bytes: 00e0c9a3c4d3d901
ticks (100 ns): 133370505499107328
UTC: 2023-08-21T00:15:49.910732+00:00
misread as big-endian ticks: 63272100002257153
8.3 Lendo o resultado
Os oito bytes sintéticos decodificam, em little-endian, para 133.370.505.499.107.328 ticks, o que corresponde a 2023-08-21 00:15:49.910732 UTC. Lidos em big-endian, os mesmos bytes dão um número sem sentido. Errar a ordem dos bytes produz datas que são lixo de aparência plausível ou absurdas, por isso as ferramentas são validadas com valores conhecidos. Um bom conjunto de validação cobre vários tipos de valor: uma data recente conhecida, a própria época (zero ticks), uma data anterior a 1970 para pegar ferramentas que presumem tempo Unix e o maior valor plausível. Cada um tem uma saída esperada anotada antecipadamente. Se uma ferramenta mostra o valor zero como 1970 em vez de 1601, ela aplicou a época errada, e todas as datas que relata estão deslocadas em 369 anos.
8.4 Hierarquia de memória
Registradores, cache, RAM e armazenamento diferem em velocidade e persistência. As camadas mais rápidas são menores e mais voláteis, e é por isso que a RFC 3227 as lista primeiro na ordem de coleta. Velocidades aproximadas deixam isso claro: a leitura de um registrador leva menos de um nanossegundo, o cache alguns nanossegundos, a RAM cerca de cem e um SSD dezenas de microssegundos. A capacidade segue o caminho inverso. Tudo o que existe apenas nas camadas mais rápidas e menores desaparece instantes depois da perda de energia, e é por isso que o planejamento da coleta começa pelo topo da hierarquia.
8.5 A CPU e a evidência
Processos em execução, conexões de rede abertas e chaves de criptografia podem existir apenas na RAM. A aquisição da memória deve ser planejada antes das decisões de desligamento. A memória pode conter o conteúdo decifrado de volumes criptografados, código injetado que nunca tocou o disco e conexões de rede que foram fechadas mas ainda não foram limpas. Capturá-la altera ligeiramente o sistema, porque a própria ferramenta de captura precisa ser executada. O plano registra qual ferramenta foi usada, onde sua saída foi gravada e quais mudanças eram esperadas, para que os efeitos da coleta possam ser distinguidos da evidência.
8.6 Fusos horários
Os valores FILETIME estão em UTC; as ferramentas de exibição podem convertê-los para a hora local. Os relatórios devem declarar qual foi usado. Nem todo carimbo de tempo está em UTC. Alguns sistemas de arquivos FAT armazenam a hora local sem fuso, e alguns logs de aplicações usam a configuração local do dispositivo. O relatório de Priya inclui uma pequena tabela que lista cada fonte, como ela armazena o tempo e o deslocamento aplicado. Quando o horário de verão muda durante o período de interesse, ela aponta explicitamente a hora ambígua em vez de deixar que a conversão escolha uma leitura em silêncio.
Outras épocas
Os sistemas Unix contam segundos desde 1º de janeiro de 1970 UTC; alguns formatos usam outras origens ou unidades, como milissegundos. Priya mantém uma tabela de referência de épocas e unidades e confere cada novo artefato com um valor que ela mesma define numa máquina de teste antes de confiar na saída de qualquer decodificador numa linha do tempo.
Exemplo resolvido
O script de um colega mostra um arquivo criado no ano 30.000. Priya verifica: o script leu os bytes em big-endian. Corrigida, a data é plausível e coincide com a de uma segunda ferramenta.
Caso sintético. Os bytes são sintéticos.
Erros e limites
Um carimbo de tempo decodificado corretamente mostra o que o sistema registrou, não necessariamente a hora verdadeira; os relógios podem estar errados ou ter sido alterados.
Exercícios
- EX022 — Hora decodificada. Que hora UTC o laboratório decodifica? Rubrica: 3 = 2023-08-21 00:15:49.91 UTC; 2 = só a data; 1 = errada; 0 = nada.
- EX023 — Ano 30.000. O que causou a data absurda e como isso foi verificado? Rubrica: 3 = leitura big-endian; corrigida e comparada com uma segunda ferramenta; 2 = um dos dois; 1 = vago; 0 = nada.
- EX024 — Registrada versus verdadeira. Por que uma decodificação correta ainda pode não dar a hora verdadeira? Rubrica: 3 = relógio do sistema errado ou alterado; 2 = parcial; 1 = sempre dá; 0 = nada.
Síntese
A ordem dos bytes e as épocas devem ser conhecidas com exatidão; a decodificação validada e os fusos horários declarados mantêm as linhas do tempo corretas.
Continue estudando — capítulo 08 de 50
← Capítulo 07 (rascunho) · Índice de capítulos do curso · Capítulo 09 (rascunho) →