Navegadores Chromium: histórico, downloads, cookies e sessões

A maioria dos computadores Windows que você examina executa pelo menos um navegador baseado no Chromium, e é muitas vezes no navegador que a intenção se torna visível: o que o usuário pesquisou, qual página abriu, qual arquivo baixou e de onde. Esta aula aborda o perfil do Chromium: onde ele fica, quais arquivos SQLite e JSON contém, como ler visitas, transições e downloads com horários UTC exatos, o que a criptografia de cookies e senhas significa para um perito e como coletar os bancos de dados para que registros recentes e excluídos não sejam perdidos. O cache e a navegação privada são abordados na Aula 4.3.

Um formato de perfil, muitos navegadores

Google Chrome, Microsoft Edge, Brave, Opera e Vivaldi compartilham o formato de perfil do Chromium, portanto os mesmos arquivos, tabelas e analisadores se aplicam a todos eles. Cada navegador mantém uma pasta User Data e, dentro dela, uma pasta por perfil: Default para o primeiro perfil, depois Profile 1, Profile 2 e assim por diante.

%LOCALAPPDATA% corresponde a C:\Users\<user>\AppData\Local, portanto o próprio caminho vincula o perfil a uma conta do Windows. Verifique todas as pastas de perfil, não apenas Default: um segundo perfil é um local comum para atividades que o usuário queria manter separadas.

Local State, um nível acima, em User Data, é um arquivo JSON de todo o navegador. Em profile.info_cache, ele lista cada pasta de perfil com seu name de exibição e, para um perfil conectado, o e-mail da conta em user_name. Em os_crypt.encrypted_key, armazena a chave codificada em Base64 que protege cookies e senhas salvas. Depois de decodificado, esse valor começa com o texto ASCII DPAPI, seguido de um blob protegido pela API de Proteção de Dados do Windows (DPAPI) desse usuário.

O banco de dados History

History é um banco de dados SQLite. O Chromium armazena seus horários como tempo WebKit: microssegundos desde 1601-01-01 UTC (Aula 3.1). O Chrome exclui visitas com mais de aproximadamente 90 dias, portanto um período inicial vazio pode ser resultado da expiração, não de inatividade.

urls e visits

A tabela urls tem uma linha por URL distinto: id, url, title, visit_count, typed_count (quantas vezes o URL foi digitado na omnibox, a barra combinada de endereço e pesquisa) e last_visit_time. Ela é um resumo. A tabela visits tem uma linha por visita, que é o que uma linha do tempo precisa:

• url: o urls.id da página visitada (uma chave estrangeira, não texto);
• visit_time: quando a visita começou (tempo WebKit);
• from_visit: o visits.id da visita de origem, permitindo reconstruir cadeias de navegação;
• transition: como o usuário chegou à página;
• visit_duration: por quanto tempo a página permaneceu carregada em sua aba, em microssegundos, até a aba navegar para outra página ou ser fechada.

Valores de transição

O byte menos significativo de transition (transition & 0xFF) é o tipo básico; os bits mais significativos são qualificadores.

Os bits qualificadores incluem 0x01000000 (avançar/voltar), 0x02000000 (a partir da barra de endereço), 0x10000000 e 0x20000000 (início e fim de uma cadeia de redirecionamento), 0x40000000 (redirecionamento do cliente) e 0x80000000 (redirecionamento do servidor). Assim, 805.306.368 = 0x30000000 é um LINK que iniciou e encerrou uma cadeia, e 838.860.805 = 0x32000005 é GENERATED a partir da barra de endereço. Algumas ferramentas exibem valores com o bit mais significativo ativado como inteiros negativos; a máscara fornece o mesmo tipo básico em ambos os casos. Uma visita TYPED é uma evidência mais forte da intenção do usuário do que uma visita LINK, que pode ser acionada por uma página ou um script.

downloads e downloads_url_chains

A tabela downloads tem uma linha por download: target_path (caminho final), current_path (caminho durante o download, normalmente igual a target_path quando concluído), start_time, end_time, received_bytes, total_bytes, state (1 concluído, 2 cancelado, 4 interrompido), danger_type (0 significa que nenhum aviso foi exibido), tab_url e referrer (a página de onde o download foi iniciado), mime_type, opened (1 se aberto pela interface de downloads do navegador) e last_access_time. downloads_url_chains se vincula a ela por id e contém uma linha por chain_index; o índice mais alto é o URL de onde o arquivo realmente veio, e os índices mais baixos mostram os redirecionamentos que levaram até lá. O arquivo em disco frequentemente tem um fluxo Zone.Identifier cujo HostUrl deve corresponder a esse URL final (Aula 1.4).

keyword_search_terms

keyword_search_terms armazena os termos de pesquisa digitados na omnibox (term e normalized_term em letras minúsculas), com url_id apontando para a linha de urls da página de resultados. Sua junção com visits fornece o horário de cada pesquisa.

Outros arquivos do perfil

Nem todo horário do Chromium é tempo WebKit: date_created e date_last_used na tabela autofill são segundos Unix. Verifique a ordem de grandeza de cada valor antes de convertê-lo.

Sessões

Versões recentes mantêm os arquivos Session_<n> e Tabs_<n> na pasta Sessions, em que <n> é um timestamp WebKit; versões mais antigas usavam Current Session, Last Session, Current Tabs e Last Tabs na pasta do perfil. São arquivos SNSS: a assinatura SNSS, uma versão de 32 bits e, em seguida, uma série de comandos que registram janelas, abas e as entradas de navegação de cada aba com URLs e títulos. Eles podem mostrar páginas que estavam abertas quando o navegador foi fechado, incluindo algumas que já não constam em History.

Cookies e criptografia

Desde o Chrome 96, o banco de dados de cookies é Network\Cookies (anteriormente, Cookies na pasta do perfil). A tabela cookies contém creation_utc, host_key, name, path, expires_utc, last_access_utc e o valor em encrypted_value, com todos os horários no formato WebKit. Desde o Chrome 80, os valores têm o prefixo v10 e são criptografados com AES-256-GCM usando a chave de Local State, que, por sua vez, é protegida por DPAPI. Portanto, descriptografá-los offline exige a chave mestra DPAPI do usuário, normalmente recuperada com a senha do usuário. Desde o Chrome 127 no Windows, a criptografia vinculada ao aplicativo protege novos cookies (prefixo v20) com uma chave adicional que apenas um serviço do Chrome executado como SYSTEM libera, e somente para o aplicativo Chrome. A descriptografia offline de valores v20 a partir de uma coleta de triagem é muito mais difícil e frequentemente inviável. Raramente você precisa dos valores dos cookies: o host, o nome e os três timestamps geralmente mostram que uma conta visitou ou se conectou a um serviço, e quando. As senhas salvas em Login Data também são criptografadas; o URL, o nome de usuário e as datas estão em texto claro.

Coleta e análise com segurança

Colete cada banco de dados junto com seus arquivos auxiliares. Um journal de reversão (History-journal) contém cópias de páginas anteriores a uma alteração e pode conter registros que foram sobrescritos desde então. Um banco de dados no modo de log de gravação antecipada tem arquivos -wal e -shm; o WAL contém alterações recentes ainda não gravadas no arquivo principal. Colete tudo o que existir e trabalhe em cópias: abrir um banco de dados WAL pode incorporar o log a ele e alterar a evidência. O Chromium compila o SQLite com a exclusão segura ativada, portanto as linhas excluídas normalmente são sobrescritas com zeros no arquivo principal; cópias mais antigas podem sobreviver no journal ou no WAL, em Cópias de Sombra de Volume ou no espaço não alocado, e recuperá-las por carving exige uma ferramenta de recuperação SQLite e verificação em hexadecimal.

O DB Browser for SQLite (aberto em modo somente leitura) é suficiente para consultas manuais. O Hindsight (obsidianforensics) analisa um perfil inteiro do Chromium e o transforma em uma única linha do tempo, o BrowsingHistoryView da NirSoft lê vários navegadores de uma vez, e o Plaso tem plugins do Chrome, como chrome_27_history (Aula 3.3). Verifique qualquer valor extraído em relação à tabela bruta.

Exemplo resolvido: visitas de ana e um download

A coleta de triagem contém C:\Users\ana\AppData\Local\Google\Chrome\User Data\Default\History e History-journal. Em Local State, profile.info_cache lista apenas Default, com um endereço de e-mail em user_name. A consulta é SELECT v.id, u.url, datetime(v.visit_time/1000000 - 11644473600, 'unixepoch') AS utc, v.transition & 0xFF AS core, v.from_visit, v.visit_duration FROM visits v JOIN urls u ON v.url = u.id ORDER BY v.visit_time;. A divisão inteira descarta os microssegundos; escreva o resultado como ISO 8601 com T e Z.

Confira manualmente a linha principal. visit_time é 13.417.970.987.412.563. Dividido por 1.000.000: 13.417.970.987 s desde 1601. Menos 11.644.473.600: Unix 1.773.497.387. Como 1.773.446.400 corresponde a 2026-03-14T00:00:00Z, os 50.987 s restantes = 14 h (50.400) + 9 min (540) + 47 s, resultando em 2026-03-14T14:09:47Z. A duração, 1.275.384.220 µs, é de 1.275 s ou 21 min 15 s, portanto a página permaneceu carregada até aproximadamente 14:31:02Z, o que é compatível com o intervalo do SRUM que termina em 14:31:09Z (Aulas 2.8 e 3.4). keyword_search_terms contém send large files free com url_id igual ao urls.id da visita 4180.

A tabela downloads tem uma linha com target_path C:\Users\ana\Downloads\xfer.exe, start_time 13.417.892.317.250.948 e end_time 13.417.892.320.031.776, received_bytes e total_bytes ambos iguais a 1.482.752, state 1 e danger_type 0. Início: 13.417.892.317 − 11.644.473.600 = 1.773.418.717; menos 1.773.360.000 (2026-03-13T00:00:00Z) restam 58.717 s = 16 h (57.600) + 18 min (1.080) + 37 s, portanto 2026-03-13T16:18:37Z. Fim: 3 s depois, 2026-03-13T16:18:40Z. downloads_url_chains fornece o índice 0 https://files.example.net/get/xfer-latest e o índice 1 https://cdn.files.example.net/b/7f3a/xfer.exe, a origem do arquivo. O horário de término corresponde ao horário de modificação de $SI e ao horário do Shimcache de xfer.exe (Aula 2.3), o tamanho corresponde ao Amcache, e a primeira execução, às 16:20:02Z, ocorreu 82 segundos depois. A constatação: o perfil do Chrome da conta de ana baixou xfer.exe de cdn.files.example.net entre 16:18:37Z e 16:18:40Z.

Foco no exame: Prepare-se para converter tempos WebKit de visits, downloads ou cookies para ISO 8601 UTC, unir visits.url a urls.id para encontrar a página por trás de uma visita e ler o URL final em downloads_url_chains. Conheça os tipos básicos de transição após aplicar a máscara 0xFF, saiba que visit_duration é expresso em microssegundos e qual arquivo responde a qual pergunta, incluindo Local State para perfis e contas. Lembre-se de que os horários de autofill são segundos Unix, não tempo WebKit.

Pontos principais

• Chrome, Edge, Brave, Opera e Vivaldi compartilham um único formato de perfil em User Data\<Profile>; Local State lista os perfis e contém a chave protegida por DPAPI.
• History: urls resume cada URL; visits registra cada visita com visit_time, from_visit, transition (tipo básico = byte menos significativo) e visit_duration em microssegundos.
• downloads fornece caminhos, horários, tamanhos e estado; downloads_url_chains fornece os redirecionamentos, com o maior chain_index como URL final do arquivo.
• Os valores dos cookies são criptografados (v10 com a chave protegida por DPAPI, v20 vinculado ao aplicativo desde o Chrome 127), mas hosts, nomes e horários estão em texto claro e geralmente são suficientes.
• Colete os arquivos -journal, -wal e -shm junto com cada banco de dados e trabalhe em cópias; a exclusão segura preenche as linhas excluídas com zeros, portanto procure cópias mais antigas em journals, arquivos WAL e cópias de sombra.