FLAMEEE

O edge te lê antes do payload

Tue, 03 Nov 2026 00:00:00 GMT

A cena se repete. O request funciona no browser, falha no curl. Você confere o header, o token, o body, todos idênticos, e conclui que o alvo “detecta ferramenta”. Aí você melhora o User-Agent, adiciona os headers do Chrome, e continua tomando 403.

O que eu demorei para internalizar é que, nesse ponto, o servidor provavelmente ainda não leu nada do que você mandou. A decisão já foi tomada no handshake, com base em como o seu cliente se apresentou — antes de existir HTTP, antes de existir header, antes de existir payload. Existe uma camada inteira de identidade que eu passei anos tratando como “detalhe de rede” e que, na prática, decide se o meu teste começa ou não.

Este post é sobre essa camada. Vou abrir o ClientHello campo por campo, mostrar por que cada biblioteca TLS produz uma assinatura estável, explicar o JA3 e por que ele morreu para browsers em 2023, decodificar o JA4 inteiro, e fechar com as camadas que não são TLS mas contam igual. Tudo com número medido, não com “dizem que”.

Anatomia de um ClientHello

Antes de qualquer fingerprint, o objeto. A norma vigente é a RFC 9846 (julho de 2026), que obsoleta a RFC 8446. Sim, o TLS 1.3 foi republicado, e quase todo texto que você vai ler ainda cita a 8446. A estrutura do ClientHello, no entanto, é a mesma:

TEXT

struct {
    ProtocolVersion legacy_version = 0x0303;
    Random random;
    opaque legacy_session_id<0..32>;
    CipherSuite cipher_suites<2..2^16-2>;
    opaque legacy_compression_methods<1..2^8-1>;
    Extension extensions<8..2^16-1>;
} ClientHello;

Seis campos. Vou passar por cada um pensando em uma pergunta só: isso é sinal ou é ruído?

Campo	Bytes	O que é	Vira fingerprint?
`legacy_version`	2	Fixado em `0x0303` no TLS 1.3	Quase não: todo mundo manda igual
`random`	32	Sorteado a cada conexão	Nunca. Se aparecer num hash, o hash está errado
`legacy_session_id`	0–32	Em modo compatibilidade, 32 bytes aleatórios	Sim: presença e tamanho separam clientes
`cipher_suites`	variável	Lista de suítes, em ordem de preferência	Muito: conjunto e ordem
`legacy_compression_methods`	1	Exatamente `00` no TLS 1.3	Hoje é constante
`extensions`	variável	Conjunto, ordem e conteúdo	O campo mais rico de todos

Três coisas aqui merecem atenção, porque são onde o modelo mental costuma quebrar.

O legacy_version é mentira por design. O TLS 1.3 não diz a versão ali; ele diz 0x0303 (TLS 1.2) e informa a versão real numa extensão, supported_versions. O motivo é histórico: middlebox velha rejeitava hello com número de versão alto, então o campo legado foi congelado para atravessar equipamento idiota. Consequência direta para fingerprint: o JA3 lê o campo legado e por isso não distingue 1.2 de 1.3.

O session id de 32 bytes é o “modo compatibilidade” (Apêndice E.4 da RFC 9846). Para o handshake 1.3 parecer uma retomada 1.2, o cliente manda um session id não vazio e um change_cipher_spec falso. Na minha medição, todas as conexões TLS 1.3 dos 10 stacks mandaram 32 bytes, e todos os clientes restritos a TLS 1.2 mandaram vazio, com uma exceção (o Go, que manda 32 bytes nos dois casos). Ou seja: session id vazio num hello 1.3 é um sinal forte de “não sou browser”.

O random não conta. Em duas execuções do Python requests, os bytes brutos do ClientHello são diferentes (0adf02f5c7e64d31… contra 60bebb560e3f784a…) e o JA3/JA4 são idênticos. Isso é a definição de um fingerprint que funciona: os bytes mudam, a estrutura não.

As extensões são a assinatura

Se você só puder decorar uma tabela neste post, é esta. As extensões são o que separa um cliente do outro, e são identificadas por um número de 16 bits. Estes são os codepoints que aparecem de verdade, conferidos no registro da IANA:

hex	Nome	O que faz	Onde entra
`0x0000`	server_name	SNI: o domínio que você quer	`d`/`i` no JA4
`0x0005`	status_request	pede OCSP stapling	conjunto
`0x000a`	supported_groups	curvas/grupos aceitos	JA3 (campo 4), fora do JA4
`0x000b`	ec_point_formats	formato de ponto EC	JA3 (campo 5)
`0x000d`	signature_algorithms	algoritmos de assinatura	JA4, na ordem
`0x0010`	ALPN	`h2`, `http/1.1`…	`h2`/`h1` no JA4
`0x0012`	signed_certificate_timestamp	SCT (CT)	conjunto
`0x0015`	padding	padding do hello	conjunto
`0x0017`	extended_master_secret	herança do 1.2	conjunto
`0x001b`	compress_certificate	compressão de cert	conjunto
`0x0023`	session_ticket	retomada	conjunto
`0x002b`	supported_versions	a versão real	`13`/`12` no JA4
`0x002d`	psk_key_exchange_modes	modos PSK	conjunto
`0x0033`	key_share	material público da troca	contagem, conteúdo nunca
`0xff01`	renegotiation_info	anti-renegociação	conjunto
`0xfe0d`	encrypted_client_hello	ECH	conjunto
`0x44cd`	application_settings (ALPS)	settings de aplicação	conjunto

Duas linhas dessa tabela merecem parágrafo próprio, porque são as que eu mais vi descritas de forma errada.

0xfe0d no Chrome é ECH GREASE, não ECH de verdade. O Chrome liga SSL_set_enable_ech_grease(ssl, 1) no caminho oportunista, e o BoringSSL documenta que isso “sends a GREASE ECH extension when no supported ECHConfig is available”. Como localhost não tem ECHConfig em DNS, o que sai é um ECH falso: 218 bytes na conexão que eu inspecionei, com payload aleatório, e tamanho que varia. Ou seja: a extensão existe, mas não está escondendo nada, é ruído de extensibilidade.

0x44cd é ALPS de verdade, e não está registrada. O payload que eu capturei é 00 03 02 68 32: um comprimento de lista, um comprimento de protocolo e as letras h2. É literalmente “minhas settings de aplicação são para h2”. Confirmação cruzada: no Chrome rodando com --disable-http2, essa extensão desaparece e o hello cai de 17 para 16 extensões. O BoringSSL chama essa família de “ALPS (draft-vvv-tls-alps)” e mantém dois codepoints (antigo e novo, selecionados por alps_use_new_codepoint), enquanto o draft deixa o valor da IANA como TBD. Por isso o número que você vê no fio é experimental e some do registro.

GREASE: ruído de propósito

A RFC 8701 reserva valores para serem anunciados ao acaso: 0x0A0A até 0xFAFA para extensões, grupos, algoritmos de assinatura e versões; {0x0A,0x0A} até {0xFA,0xFA} para cipher suites e ALPN. A ideia é obrigar a outra ponta a ignorar o que não conhece, para que o ecossistema não “enferruje” e trave quando um valor novo aparecer.

Para fingerprint, GREASE é ruído injetado de propósito, e um anti-fingerprint acidental: o cliente muda o hello sem mudar de software. Na medição, só o Chrome (e o curl_cffi, que copia o Chrome) manda GREASE: uma cipher, duas extensões, um grupo, uma entrada em supported_versions e um algoritmo de assinatura, com valores re-aleatorizados a cada conexão. Todos os outros nove stacks não mandam nenhum.

TLS 1.2 e 1.3 não se parecem no fio

Vale colocar lado a lado, porque é a diferença mais fácil de perder:

	TLS 1.2	TLS 1.3
versão	`legacy_version` e pronto	`legacy_version` fixo + `supported_versions`
troca de chave	grupos e formatos de ponto	`key_share` com material no hello
compressão	lista real	exatamente `00`
session id	retomada real	32 bytes aleatórios (compat)
resumption	session id / ticket	PSK + `psk_key_exchange_modes`

O efeito no fingerprint é direto e meio cruel: como o JA3 lê a versão legada, o campo de versão dele é o mesmo (771) em 1.2 e em 1.3. O que separa os dois hellos é o resto da lista, não a versão. O JA4 lê supported_versions e marca t12 contra t13 na primeira parte. E como 1.3 obriga key_share e psk_key_exchange_modes, a contagem de extensões muda junto.

Cada stack escreve o próprio hello

Aqui está o insight estrutural que faz tudo o resto fazer sentido: o ClientHello não é negociado, é escrito. Ele é o resultado de uma tabela compilada no binário.

Na BoringSSL, ssl/extensions.cc tem uma tabela kExtensions[] e o builder percorre essa tabela chamando o add_clienthello de cada entrada. Na prática, a ordem das extensões é uma constante de compilação, exceto quando é embaralhada. E vamos chegar lá. A lista de ciphers também é uma tabela: kCiphers[], em ssl_cipher.cc, com os três suites TLS 1.3 em ordem fixa.

Só que “tabela compilada” não significa “igual entre stacks”. Medindo, o mesmo pedido por ferramentas diferentes:

Cliente medido	Ciphers / extensões (sem GREASE)	JA4
curl do macOS 8.7.1 (LibreSSL 3.3.6)	49 / 7	`t13d4907h2_0d8feac7bc37_7395dae3b2f3`
curl Homebrew 8.21.0 (OpenSSL 3.6.4)	30 / 12	`t13d3012h2_1d37bd780c83_882d495ac381`
Python 3.15 (requests e httpx, OpenSSL)	17 / 12	`t13d1712h1_ab0a1bf427ad_0d46a1bf4a7c`
Go 1.25 `net/http`	13 / 12	`t13d1312h2_f57a46bbacb6_ab7e3b40a677`
Java 21.0.8 `java.net.http`	37 / 13	`t13d3713h2_db35923f8641_7c76daad20ec`
Node 26.8.2 (undici)	52 / 12	`t13d5212h1_b262b3658495_8e6e362c5eac`
Chrome 156	15 / 17	`t13d1517h2_8daaf6152771_cb7bf5808d99`

Repare nas duas primeiras linhas. São os dois curl da mesma máquina: um é o do sistema, o outro é o do Homebrew. Mesmo comando, mesmo nome, fingerprint diferente, porque o do macOS usa LibreSSL e o do Homebrew usa OpenSSL. Se você copiou um tutorial do Linux e rodou no Mac, você está anunciando outra stack.

A linguagem também não é o sinal. O Python e o Node usam OpenSSL por baixo; o Python dá 17 ciphers e o Node dá 52. O que conta é a biblioteca e a versão dela, não a linguagem.

JA3: uma linha, um MD5 e um problema

O JA3 (Salesforce, 2017) é a ideia mais simples possível: pegue cinco campos do hello, junte em texto, hasheie.

TEXT

SSLVersion,Cipher,SSLExtension,EllipticCurve,EllipticCurvePointFormat

Valores em decimal, , entre campos, - dentro do campo, e MD5 no fim. O exemplo do README oficial, que eu recalculei:

TEXT

769,47-53-5-10-49161-49162-49171-49172-50-56-19-4,0-10-11,23-24-25,0
  → ada70206e40642a3e4461f35503241d5

Funcionou em 2017 porque era barato de calcular e suficientemente discriminante. E funciona até hoje para o que ele é: um jeito de dizer “esses bytes apareceram nesta ordem”.

Só que “nesta ordem” é a parte frágil, e a lista de fraquezas é curta e honesta: ordem importa; não há conteúdo de extensão (só os números); 1.2 e 1.3 se confundem; o MD5 é identificador, não autenticador; e a divergência entre implementações que a Fastly mediu. Nenhuma dessas fraquezas é fatal isoladamente. Juntas, elas deixaram o JA3 pronto para ser morto.

E em 2023 alguém o matou de propósito.

2023: o Chrome quebrou o JA3 de propósito

No código do Chromium, net/socket/ssl_client_socket_impl.cc, existe uma linha incondicional no caminho de conexão TLS:

CPP

SSL_set_permute_extensions(ssl_.get(), 1);

Do outro lado, na BoringSSL, ssl_setup_extension_permutation() faz um Fisher-Yates com RAND_bytes sobre os índices de kExtensions — e o laço de emissão percorre a permutação em vez da ordem natural. Resultado: o Chrome embaralha a ordem das extensões do ClientHello a cada conexão.

O motivo é anti-ossificação, e é um motivo bom: se servidores se acostumam com uma ordem fixa, qualquer mudança futura no Chrome quebra a internet. Embaralhar força o ecossistema a tratar a ordem como irrelevante. A consequência colateral é que o JA3, que depende exatamente dessa ordem, virou ruído.

A Fastly mediu o estrago na época: a partir de 20 de janeiro de 2023, o JA3 mais comum de Chrome na rede deles caiu; e como o número de permutações é “quase 15 fatorial (cerca de 10¹²)”, na prática cada conexão gera um JA3 único. A Cloudflare foi direta: aquilo tornou “older TLS fingerprints almost useless for identifying the latest version of Chrome”.

Agora o número que eu medi, porque é aqui que a teoria vira obviedade. Três conexões novas do mesmo binário do Chrome 156:

TEXT

conexão 1  →  JA3 0e250605ce1f2c793bb1a2269dd30e01
conexão 2  →  JA3 47e376a38884e22f8a6bb4661daa71a9
conexão 3  →  JA3 5c34099f1b500a60c0deacb3f8d31187
       todas →  JA4 t13d1517h2_8daaf6152771_cb7bf5808d99

Três JA3 diferentes. Um JA4. Se você construiu uma regra de WAF em cima de JA3 de browser, ela já não vale há três anos.

JA4: como ler o fingerprint inteiro

O JA4 (FoxIO, 2023) resolve isso com duas decisões: ordenar o que é arbitrário, e colocar informação legível na frente do hash. O formato é a_b_c:

TEXT

t13d1516h2_8daaf6152771_e5627efa2ab1

Vou decodificar esse exemplo da especificação por inteiro, porque ele é o melhor material de estudo que existe, e porque eu recalculei cada hash.

Parte	Valor	Significado
`t`	t	TLS sobre TCP (`q` = QUIC, `d` = DTLS)
`13`	13	TLS 1.3, lido de `supported_versions`
`d`	d	tem SNI (`i` = sem SNI, foi para um IP)
`15`	15	15 cipher suites, sem contar GREASE
`16`	16	16 extensões, sem contar GREASE
`h2`	h2	primeiro e último caractere do primeiro ALPN
`8daaf6152771`	hash	sha256 das ciphers ordenadas, truncado em 12
`e5627efa2ab1`	hash	sha256 das extensões ordenadas (menos SNI e ALPN) + sigalgs na ordem

As 15 ciphers, nomeadas pelo registro da IANA: 002f e 0035 (RSA CBC), 009c e 009d (RSA GCM), 1301/1302/1303 (os três suites TLS 1.3), c013/c014 (ECDHE_RSA CBC), c02b/c02c (ECDHE_ECDSA GCM), c02f/c030 (ECDHE_RSA GCM) e cca8/cca9 (ECDHE ChaCha20). É a mistura clássica de um cliente moderno: os 130x para 1.3 e uma cesta de 1.2 para conversar com servidor velho.

As 16 extensões: 001b compress_certificate, 0000 SNI, 0033 key_share, 0010 ALPN, 4469 ALPS (o codepoint antigo), 0017 extended_master_secret, 002d psk_key_exchange_modes, 000d sigalgs, 0005 status_request, 0023 session_ticket, 0012 SCT, 002b supported_versions, ff01 renegotiation_info, 000b ec_point_formats, 000a supported_groups, 0015 padding.

Recalculando com sha256sum:

TEXT

sha256("002f,0035,009c,009d,1301,1302,1303,c013,c014,c02b,c02c,c02f,c030,cca8,cca9")[:12]
  = 8daaf6152771

sha256("0005,000a,000b,000d,0012,0015,0017,001b,0023,002b,002d,0033,4469,ff01_0403,0804,0401,0503,0805,0501,0806,0601")[:12]
  = e5627efa2ab1

Dois detalhes que valem mais que decorar as regras. Primeiro: SNI e ALPN são excluídos do c de propósito, porque já estão no a. Assim, o mesmo cliente dá o mesmo c indo para um domínio ou para um IP. Segundo: os sigalgs entram na ordem de aparição, sem ordenar, e são colados depois de um _. Se você ordenar, o hash muda; eu vi essa implementação errada nascer num laboratório e o FoxIO publica o vetor que denuncia o erro (0403,0804,0401,…, não ordenado).

Agora o pulo do gato, comparando o exemplo da especificação com o meu Chrome 156 medido:

TEXT

spec       t13d1516h2_8daaf6152771_e5627efa2ab1
Chrome 156 t13d1517h2_8daaf6152771_cb7bf5808d99

O b é idêntico. A lista de ciphers do Chrome não mudou entre esses builds. O que mudou foram as extensões: uma a mais (17 contra 16), e o c mudou junto. Isso prova que o algoritmo está fazendo o trabalho certo: a parte estável ficou estável, a parte que mudou mudou.

Ordenar é uma decisão de projeto

O que eu acho mais elegante no JA4 não é o formato, é a escolha de onde ordenar. Eu construí o caso mínimo: o mesmo conjunto de extensões, em duas ordens.

TEXT

ordem A: 10-11-13-16-23-35-43-51  →  JA3 692aefc05b6b8a9afca0d6486e3b15e4
ordem B: 51-43-35-23-16-13-11-10  →  JA3 79e887fad94c5bfc974a532532781ec3
                                     JA4_c 8ccb6ff8ed2a (igual nos dois)

mesma lista, duas ordens, dois JA3 e um JA4

Dois JA3, um JA4. E a regra por trás não é “ordem não importa”: é que se ordena o que é semanticamente irrelevante e ativamente randomizado. Extensões TLS se encaixam nas duas coisas. Já a ordem de headers HTTP não é randomizada por ninguém e carrega informação — e o JA4H, o fingerprint de cliente HTTP da mesma família, não ordena os headers. O JA4S, que olha a resposta do servidor, preserva até a ordem original de propósito.

Três decisões, uma régua só. É isso que separa um formato que envelhece bem de um que precisa ser substituído em cinco anos.

O que o JA4 escolhe não ver

Nenhum fingerprint vê tudo, e vale ser explícito sobre o que fica de fora, porque é aí que ficam as decisões erradas de diagnóstico.

O que não entra no JA4	Por quê	Consequência prática
`random`, session id, bytes do `key_share`	são aleatórios	o hash é estável; os bytes nunca são
`supported_groups`	fora do `c` de propósito	dois clientes que só diferem em grupo pós-quântico dão o mesmo JA4
o nome do SNI	só “tem ou não tem”	o hostname não está no hash
ordem das extensões	ordenadas	invisível ao JA4, visível ao JA3
ordem das ciphers	ordenadas	você ganha estabilidade, perde a preferência
ALPN além do primeiro/último char	só 2 caracteres	`http/1.1` e `http/1.1,h2` ficam idênticos

Esse último é o mais traiçoeiro, e está nos meus registros: httpx em modo HTTP/2 oferece http/1.1, h2, na ordem invertida, e produz exatamente o mesmo JA4 (t13d1712h1_…) que o requests, que só oferece http/1.1. O campo a pega o primeiro e o último caractere do primeiro valor, então http/1.1 vira h1 e o h2 que veio depois desaparece. Um sensor que só olha JA3/JA4 não consegue saber que aquele cliente pediu HTTP/2.

E o pós-quântico merece uma nota: Chrome, Go, Node e OpenSSL 4 oferecem X25519MLKEM768 (0x11ec, definido na RFC 10024); Java 21 e o curl do macOS não oferecem. Como o JA4 não hasheia grupos nem o conteúdo do key_share (o Chrome manda um share de 1216 bytes, diferente a cada conexão), o mesmo cliente antes e depois do PQ mantém o JA4. A instabilidade dessa mudança fica toda no JA3, que hasheia supported_groups.

Não é só TLS

Se você chegou até aqui achando que o problema é TLS, a má notícia é que existem mais três camadas. E uma quarta que não é camada, é histórico.

cada camada tem um dono · nem todas aceitam disfarce

HTTP/2. A gramática veio de uma white paper da Akamai de 2017 e é a que todo mundo ainda implementa: o fingerprint é montado com os frames que o cliente manda antes de qualquer request útil. A notação é S[;]|WU|P[,]#|PS[,]: parâmetros de SETTINGS com seus valores, na ordem em que aparecem; o incremento do WINDOW_UPDATE; as tuplas de prioridade; e a ordem dos pseudo-headers, codificada como m, p, a, s. O paper mediu mais de 10 milhões de conexões e, em 2017, publicou a ordem de cada browser: Chrome m,a,s,p, Firefox m,p,a,s, Safari m,s,p,a.

Correção de premissa, porque eu mesmo já repeti o erro: o formato da Akamai não inclui flags de HEADER frame. Os três fluxos são SETTINGS, WINDOW_UPDATE e PRIORITY, mais a ordem dos pseudo-headers. Se você vir alguém atribuindo flags de HEADER à Akamai, a fonte não existe.

Mas 2017 é 2017. Medi os clientes desta máquina agora, com ALPN negociando h2 em todas as conexões para nada degradar em silêncio. Dois deles, no formato acima:

TEXT

Chrome 156   1:65536;2:0;4:6291456;6:262144|15663105|0|m,a,s,p
Java 21      1:16384;2:0;3:0;4:16777216;5:16384;6:393216|33488897|0|a,m,p,s

O PS do Chrome continua m,a,s,p: a linha de 2017 sobreviveu. O Go continua a,m,p,s, batendo com o paper. E o curl mudou: era m,p,s,a na 7.54 e virou m,s,a,p na 8.x. É a razão para colar a versão ao lado de cada fingerprint numa tabela; sem isso, a tabela envelhece sem avisar.

O campo P está morto. Em doze conexões, zero frames PRIORITY: P=0 em todas. O P do paper nasceu das prioridades de stream reservado do Firefox 53; o Chrome de hoje manda o bloco de prioridade (já deprecado) dentro do HEADERS e um header priority do RFC 9218, e a gramática não codifica nenhum dos dois. Então P=0 significa “não houve frame PRIORITY”, não “não há prioridade”. É uma medida honesta do que um formato de 2017 perde em 2026.

E a lição da seção de TLS se repete uma camada acima: os dois curl desta máquina mandam o mesmo WINDOW_UPDATE (1048510465) e a mesma ordem de SETTINGS (3;4;2), mas o Homebrew manda INITIAL_WINDOW_SIZE=65536 e o do macOS manda 10485760. Mesma ferramenta, build diferente, string diferente.

Isso importa porque um proxy que termina a conexão (e o Burp termina) monta os SETTINGS dele, não os do browser. E o curl_cffi mostra o limite de tudo isso: ele empata com o Chrome no TLS (JA4 idêntico) e no h2 (string idêntica), e ainda assim é pego uma camada acima: o Chrome 156 da medição manda HeadlessChrome/156 com 17 headers, o curl_cffi manda Chrome/152 no Windows com 18, incluindo cache-control. Um impersonator precisa acertar em todas as camadas, e as camadas têm ordem.

Headers HTTP. Ordem, capitalização e defaults. O JA4H cobre isso hasheando os nomes na ordem de aparição. A higiene que quase todo mundo esquece é esta: se você forja o User-Agent para “Chrome 131” mas deixa o sec-ch-ua dizendo outra versão, você não ficou mais parecido com um browser. Ficou inconsistente, o que é pior que o original.

TCP/IP. TTL, janela, MSS e a ordem das opções vêm do kernel, não do seu cliente. O p0f faz isso com um SYN desde sempre, e o equivalente moderno é o JA4T, no formato janela_opções_mss_wscale (o exemplo do FoxIO: 64240_2-1-3-1-1-4_1460_8). É a camada que você não corrige com flag de cliente — e é por isso que mimetizar TLS saindo de um VPS continua contando uma história diferente.

Fingerprint é chave, não veredito

O erro conceitual mais comum é achar que o edge decide olhando um hash. Ele não decide assim, e a Cloudflare documenta o contrário: junto do JA4 ela calcula o que chama de JA4 Signals: estatística agregada da última hora, global. Os nomes são explícitos: browser_ratio_1h, h2h3_ratio_1h, reqs_quantile_1h, uas_rank_1h, paths_rank_1h, cache_ratio_1h, ips_rank_1h, entre outros.

O JA4 é a chave. O que pesa é a distribuição dela. Um JA4 raríssimo que se declara Chrome, com browser_ratio_1h baixo e volume alto, é um caso perdido, e nenhum ajuste de cipher conserta isso. Pior: essas signals são de analytics, não de regra (“They cannot be used as filter fields in WAF custom rule expressions”), então você não consegue nem simular a decisão olhando só o hash.

E existe uma confusão que custa horas: bloqueio e desafio não são a mesma coisa. Um desafio volta como HTML, com o header cf-mitigated: challenge, e existe para rodar JavaScript no seu browser. Um cf_clearance obtido ali é amarrado ao dispositivo que resolveu, e resolver de um IP e usar de outro invalida o solve. Se o seu caso é esse, o problema não é TLS nenhum, e nenhum impersonator vai resolver.

Quem calcula isso hoje

Não é nicho de pesquisa. É campo de regra em produção:

Onde	O quê	Desde
Cloudflare	JA4 na Bot Management (Enterprise), campo `cf.bot_management.ja4`	JA4+Signals anunciados em ago/2024
AWS WAF	JA3	set/2023
AWS WAF	JA4, inclusive como chave de rate-based rule	mar/2025
Google Cloud Armor	`origin.tls_ja4_fingerprint` e `origin.tls_ja3_fingerprint`	documentado hoje
Akamai	JA4 (beta, via header injetado)	2026
Fastly	variável VCL `tls.client.ja4` e NGWAF	fev/2025

Nas 38 conexões, os 10 stacks produziram 24 JA4 distintos, e três clientes diferentes colapsaram no mesmo (requests, httpx em h1 e em h2). Isso resume o estado da arte: o JA4 é bom em dizer “que tipo de software é isso”, e insuficiente para dizer “qual ferramenta exatamente”. Para isso você precisa da próxima camada.

O que eu levo disso

Quatro coisas, e nenhuma delas é “use ferramenta X”.

O bloqueio acontece antes do payload. Se o seu encoding, o seu header e o seu token estão certos e ainda dá 403, a resposta provavelmente foi tomada no handshake. Olhar o body nesse momento é olhar para o lugar errado.

A stack é o sinal, não a linguagem. Dois curl na mesma máquina, fingerprints diferentes. Um upgrade de biblioteca muda a sua identidade na rede, e ninguém te avisa.

JA3 de browser morreu em 2023, e foi de propósito. Não é bug, não é falta de manutenção: é uma decisão de engenharia do Chrome que a Fastly mediu e a Cloudflare comentou. Quem ainda constrói detecção em cima de JA3 de browser está detectando um alvo que se move a cada conexão.

E o fingerprint nunca é a história inteira. Ele é uma chave numa decisão que também olha prevalência, ASN, rate, cookie e comportamento. Confundir “meu TLS está errado” com “meu IP está queimado” é o jeito mais rápido de passar a tarde inteira ajustando cipher sem mudar nada.

No próximo post eu faço o caminho inverso: pego o Burp, mostro em três camadas por que ele anuncia que é uma ferramenta Java, e o que dá para fazer a respeito — incluindo o que não dá, e por quê.

omp: do zero ao /vibe

Thu, 22 Oct 2026 00:00:00 GMT

Primeiro post de verdade aqui, e é o tutorial que eu queria ter tido: sair do zero e chegar no meu setup do omp (oh-my-pi), bonito e configurado, passo a passo. Tudo foi conferido contra a documentação e o CLI do omp (18.12.5 aqui; o caminho Linux foi testado num container Ubuntu 24.04 limpo, que instalou a 18.12.6).

Passo	macOS	Linux (Debian/Ubuntu)	Windows
Gerenciador de pacotes	Homebrew	apt	winget
Terminal	Warp (o meu)	Warp ou qualquer um com Nerd Font	Windows Terminal (ou Warp)
Nerd Font	`brew install --cask`	zip em `~/.local/share/fonts` + `fc-cache`	zip → Instalar
Tema do shell	Oh My Zsh + p10k	Oh My Zsh + p10k	só dentro do WSL2
omp	`brew install can1357/tap/omp`	`curl -fsSL https://omp.sh/install \| sh`	`irm https://omp.sh/install.ps1 \| iex`

O que é um harness

Se você só usou LLM pela janela de chat, a peça que falta é esta. O modelo, sozinho, é texto entra, texto sai. Ele não lê seu repositório, não roda comando, não lembra da semana passada. O harness é o programa em volta dele que o transforma num agente:

O loop do agente. O modelo pede uma chamada de ferramenta, o harness executa e devolve o resultado, e isso se repete até a tarefa acabar.
As ferramentas. Ler e editar arquivo, shell, busca, browser, servidores MCP.
O que entra no contexto. System prompt, regras do projeto (AGENTS.md), skills, memória, conteúdo de arquivos, e a compactação quando o contexto enche.
Permissões e aprovações. O que roda sozinho e o que precisa do seu “ok”.
Sessões e histórico. Retomar de onde parou.
Subagentes e orquestração. Dividir o trabalho entre vários agentes (no omp, isso inclui o /vibe).
Roteamento de modelos. Um modelo forte para pensar, um barato para o braçal.

Pensa num console: o modelo é a CPU; o harness é todo o resto, controle, memory card e leitor de disco.

Na prática, o agente age em vez de sugerir: roda o comando e lê a saída, sem você copiar e colar. Ele segura estado numa tarefa longa. E regras, skills e contexto de projeto fazem o agente seguir o seu método toda vez, sem você colar as mesmas instruções em cada conversa. Trabalho em paralelo vira subagente ou worker. Pela minha experiência, o mesmo modelo parece outro dependendo das ferramentas e de como o harness cuida do contexto.

O que ele não faz: não substitui julgamento e não transforma modelo ruim em modelo bom.

Aspecto	Chat	Harness
Roda comandos	não	sim, com aprovação configurável
Edita arquivos	você copia e cola	direto no disco
Regras do projeto	você cola toda vez	carregadas sozinhas
Agentes em paralelo	não	subagentes e workers
Escolha de modelo	o que o app oferece	qualquer provedor, um por tarefa

Exemplos da categoria: Claude Code, Codex CLI, opencode, Aider, o agente do Cursor e o omp.

Por que o omp

Pra mim, o omp ganha por juntar tudo isso num lugar só: dezenas de provedores (por variável de ambiente, login OAuth ou qualquer gateway compatível), modelos locais detectados sozinhos, papéis de modelo com nível de thinking por papel, subagentes customizáveis em markdown, o /vibe, skills, memória entre sessões, MCP, modos de aprovação, ofuscação de segredos, perfis isolados e sessões que dá para retomar. E ainda é bonito no terminal, que é metade deste post.

1. Pré-requisitos e terminal

O omp não precisa de runtime: o Homebrew e os scripts oficiais entregam um binário pronto. O Bun (≥ 1.3.14, segundo o README) só entra se você preferir instalar com bun install -g @oh-my-pi/pi-coding-agent.

O terminal precisa aceitar uma fonte customizada. No macOS eu uso o Warp, que também tem versão para Linux e Windows. No Windows, o padrão sensato é o Windows Terminal.

macOS (Homebrew, comando oficial do brew.sh, e o Warp)

BASH

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
brew install --cask warp

Linux (o básico que os próximos passos usam; terminal: Warp pelo site ou o que você já usa)

BASH

sudo apt update && sudo apt install -y curl git unzip fontconfig

Windows (PowerShell; o Windows Terminal também vem da Microsoft Store)

POWERSHELL

winget install --id Microsoft.WindowsTerminal -e

2. Nerd Font

Uma Nerd Font é uma fonte de programação com milhares de ícones extras embutidos: logo do git, pasta, setas powerline, spinners. O omp usa esses ícones quando você liga symbolPreset: nerd, o status line tem um preset nerd, e o Powerlevel10k do passo 3 também depende deles. Sem a fonte, os ícones viram quadradinhos.

Eu uso a JetBrains Mono Nerd Font, na variante NL (sem ligaduras), cujo nome de família é JetBrainsMonoNL Nerd Font.

macOS

BASH

brew install --cask font-jetbrains-mono-nerd-font

Linux (método manual do projeto nerd-fonts; fc-list confirma)

BASH

mkdir -p ~/.local/share/fonts
curl -fsSLo /tmp/JetBrainsMono.zip \
  https://github.com/ryanoasis/nerd-fonts/releases/latest/download/JetBrainsMono.zip
unzip -oq /tmp/JetBrainsMono.zip -d ~/.local/share/fonts/JetBrainsMono
fc-cache -fv
fc-list | grep -i "JetBrainsMonoNL Nerd Font"

No Arch, o pacote oficial é sudo pacman -S ttf-jetbrains-mono-nerd.

Windows (baixe JetBrainsMono.zip em github.com/ryanoasis/nerd-fonts/releases/latest, extraia, selecione os .ttf e clique com o botão direito → Instalar). Depois, no settings.json do Windows Terminal (Configurações com Shift pressionado), a fonte vale para todos os perfis em profiles.defaults:

JSON

{
  "profiles": {
    "defaults": {
      "font": { "face": "JetBrainsMonoNL Nerd Font", "size": 13 }
    }
  }
}

Se você usa WSL2, a fonte é instalada no Windows: quem desenha os ícones é o Windows Terminal, não o Linux.

Selecionar no terminal. No Warp (qualquer sistema), escolha JetBrainsMonoNL Nerd Font nas configurações de aparência. No macOS o meu ~/.warp/settings.toml fica assim:

TOML

[appearance.text]
font_family = "JetBrainsMonoNL Nerd Font"
font_size = 13.0

[appearance.themes]
theme = "dark"

[appearance.cursor]
cursor_display_type = "bar"

Em outro terminal (iTerm2, Ghostty, Kitty, GNOME Terminal…), o princípio é o mesmo: a fonte do terminal tem que ser uma Nerd Font.

3. A cara do shell (opcional)

Eu uso Oh My Zsh com o tema Powerlevel10k. Não é necessário para o omp, mas faz parte da cara do meu terminal. Zsh, Oh My Zsh e p10k são coisa de shell Unix: no Windows eles funcionam dentro do WSL2, não no PowerShell.

macOS: o zsh já é o shell padrão; nada a instalar.

Linux (e Windows dentro do WSL2: instale com wsl --install num PowerShell de administrador, reinicie, abra o Ubuntu e siga daqui)

BASH

sudo apt install -y zsh git curl
chsh -s "$(which zsh)"   # vale no próximo login

macOS, Linux e WSL2: a partir daqui é igual. Oh My Zsh e Powerlevel10k como tema dele, com os comandos dos READMEs oficiais:

BASH

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"
git clone --depth=1 https://github.com/romkatv/powerlevel10k.git \
  "${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes/powerlevel10k"

No ~/.zshrc, troque o tema (eu deixo só o plugin git):

BASH

ZSH_THEME="powerlevel10k/powerlevel10k"
plugins=(git)

Abra um terminal novo; o wizard começa sozinho. Se não começar, rode p10k configure. As minhas escolhas foram: nerdfont-v3 + powerline, ícones pequenos, estilo rainbow, relógio 24h, separadores angulares, duas linhas, transient prompt e instant prompt. O wizard grava tudo em ~/.p10k.zsh. No Warp, o prompt do p10k só aparece com honor_ps1 = true em [terminal.input].

4. Instalando o omp

macOS (é como eu instalo)

BASH

brew install can1357/tap/omp

Linux (script oficial; instala em ~/.local/bin, que precisa estar no PATH)

BASH

curl -fsSL https://omp.sh/install | sh
export PATH="$HOME/.local/bin:$PATH"   # coloque no ~/.zshrc ou ~/.bashrc

Windows (PowerShell, script oficial; dentro do WSL2, use o comando do Linux)

POWERSHELL

irm https://omp.sh/install.ps1 | iex

Em qualquer sistema, confira com omp --version. omp setup roda o wizard de onboarding; depois é só omp dentro de um projeto. Tudo do usuário mora em ~/.omp/agent/ (omp config path mostra onde): config.yml, models.yml, mcp.json, .env, skills/, agents/.

Um provedor. OAuth (assinatura) é igual em todo sistema: omp login e escolha na lista (dentro da sessão, /login). Para API key, deixe a chave fora do histórico do shell:

macOS e Linux (funciona em zsh e bash)

BASH

printf 'API key: ' && read -rs K && printf '\nANTHROPIC_API_KEY=%s\n' "$K" >> ~/.omp/agent/.env && unset K
chmod 600 ~/.omp/agent/.env
omp models   # o que ficou disponível, agrupado por provedor

Windows (PowerShell 7.1+; grava uma variável de ambiente do usuário, que vale nos próximos terminais)

POWERSHELL

$k = Read-Host 'API key' -MaskInput
[Environment]::SetEnvironmentVariable('ANTHROPIC_API_KEY', $k, 'User')
Remove-Variable k

O omp lê OPENAI_API_KEY, GEMINI_API_KEY, OPENROUTER_API_KEY, DEEPSEEK_API_KEY e várias outras; omp --help lista as principais.

5. Deixando o omp bonito

Daqui até o fim, tudo é igual nos três sistemas: é config do omp, não do SO. O visual fica em ~/.omp/agent/config.yml. Estes são os valores que eu mudei do padrão:

YAML

# ~/.omp/agent/config.yml — aparência
theme:
  dark: dark-dracula # tema embutido (padrão: titanium)
symbolPreset: nerd # ícones da Nerd Font (padrão: unicode)
statusLine:
  preset: nerd # ícones no status line (padrão: default)
  contextLine: annotated # uso de contexto anotado
composer:
  shape: box # editor numa caixa (padrão: band)
display:
  showTokenUsage: true # tokens por resposta
  showTurnTime: true # tempo total de cada turno, ferramentas incluídas

Ou pelo CLI, uma chave por vez (o nome precisa bater exatamente com o schema):

BASH

omp config set theme.dark dark-dracula
omp config set symbolPreset nerd
omp config set statusLine.preset nerd
omp config set statusLine.contextLine annotated
omp config set composer.shape box
omp config set display.showTokenUsage true
omp config set display.showTurnTime true

Tudo isso também está em /settings, dentro da sessão, se você preferir menu. Outras opções de statusLine.preset: default, minimal, compact, full, ascii, custom. O separador fica em statusLine.separator (powerline, powerline-thin, slash, pipe, block, none, ascii). Temas próprios são arquivos JSON em ~/.omp/agent/themes/.

Resultado esperado: ao abrir omp, o editor aparece numa caixa, o status line mostra modelo, pasta e git com ícones, e as cores são as do Dracula. Se aparecerem quadradinhos, a fonte do passo 2 não está selecionada.

6. Configs que valem a pena além do visual

As minhas, todas fora do padrão:

Chave	Valor	O que faz
`defaultThinkingLevel`	`max`	profundidade de raciocínio padrão (padrão: `high`)
`temperature`	`0.7`	temperatura de amostragem (padrão: a do provedor)
`memory.backend`	`local`	extrai lições das sessões e injeta um resumo na próxima (padrão: `off`)
`autolearn.enabled`	`true`	deixa o agente criar e atualizar skills gerenciadas
`autolearn.autoContinue`	`true`	roda um turno privado de captura de lições ao parar; gasta token
`model.loopGuard.enabled`	`false`	desliga o detector automático de loop no raciocínio e no texto
`model.toolCallLoopGuard.threshold`	`20`	chamadas idênticas seguidas antes de intervir (padrão: `5`)
`bash.allowCompoundCommands`	`true`	avalia cada comando de uma cadeia `&&` separadamente
`browser.headless`	`false`	mostra a janela quando o agente usa o browser
`computer.enabled`	`true`	libera o controle do desktop (screenshots, input)

Duas que eu recomendo para todo mundo, mesmo não estando na minha lista:

secrets.enabled: true (padrão false): env vars com cara de credencial e padrões conhecidos (JWT, Bearer, chaves de cloud) viram placeholders no texto enviado ao provedor e voltam ao normal na hora de executar a ferramenta. Não pega valor curto nem o prompt estático.
tools.approvalMode: o padrão é yolo (roda tudo). Se você está começando, write aprova leitura e escrita e pergunta antes de executar. Subagentes sempre rodam em yolo; a aprovação que conta é a do pai.

7. Provedores e modelos

O omp trabalha com papéis, configurados em modelRoles no config.yml:

Papel	Para quê
`default`	a conversa principal
`smol`	tarefas leves; workers `fast` do `/vibe`
`slow`	raciocínio pesado
`plan`	o plan mode (`/plan`)
`task`	subagentes e workers `good` do `/vibe`
`vision`	analisar imagens
`commit`	`omp commit`
`tiny` / `memory`	títulos de sessão e pipeline de memória

O sufixo :nível define o thinking por papel (off, minimal, low, medium, high, xhigh, max, auto): default: deepseek/deepseek-v4-flash:max. smol e slow sem valor herdam o default. Para trocar: /model abre o hub, Ctrl+P alterna entre os modelos dos papéis, Shift+Tab alterna o thinking, e omp --model opus aceita busca aproximada.

Gateway próprio (qualquer endpoint compatível com OpenAI ou Anthropic) vai em ~/.omp/agent/models.yml:

YAML

providers:
  my-gateway:
    baseUrl: https://gateway.example/v1
    api: openai-completions # ou anthropic-messages, openai-responses…
    apiKey: MY_GATEWAY_API_KEY # nome da env var; o omp usa o valor dela
    authHeader: true # Authorization: Bearer <chave>
    models:
      - id: vendor/big-model # o id que o endpoint espera
        name: Big Model
        reasoning: true
        thinking: { mode: effort, efforts: [low, high, max], defaultLevel: high }
        input: [text, image]
        contextWindow: 1048576
        maxTokens: 131072

apiKey é “nome de env var ou literal”: se bater com uma variável preenchida, vale o valor dela. Um erro de YAML faz o omp ignorar o arquivo inteiro, então sempre confira com omp models my-gateway. E antes de declarar um provedor, rode omp models <nome>: se ele já vem embutido, só falta a credencial.

O que eu uso:

Papel default: deepseek/deepseek-v4-flash:max, pelo provedor DeepSeek embutido. Tudo que herda o default (os workers fast, por exemplo) roda nele.
Sessão principal e diretor do /vibe: Claude Opus (anthropic/claude-opus-5-5). O omp permite trocar o modelo só da sessão sem mexer no papel default: Alt+P escolhe um modelo temporário para a sessão, e omp --model opus faz o mesmo na linha de comando.
Gateway no models.yml com DeepSeek V4.1 Flash, Nemotron 3.5 Super VL 120B e GLM-5.3 Flash, todos com 1M de contexto, a escada de effort declarada e custo preenchido para o omp contabilizar.

8. /vibe

/vibe transforma a sessão num diretor. O diretor fica só com read, um todo opcional e cinco ferramentas de controle; quem busca, edita e roda são workers persistentes em background, cada um com a própria transcrição.

O diretor lê e decide; os workers fazem.

TEXT

/vibe                       # entra no modo
/vibe migra o parser        # entra e já manda a primeira diretiva
/vibe                       # sai (encerra os workers)

Tier	Agente	Papel	Uso
fast	sonic	@smol	execução mecânica, volume, rascunho
good	task	@task	julgamento, design, revisar o `fast`

O diretor usa vibe_spawn (cria um worker com brief e tier), vibe_send (corrige o rumo ou manda o próximo passo), vibe_wait, vibe_kill e vibe_list. Você só fala com ele em linguagem natural.

Para escolher os modelos dos tiers, a documentação sugere aliases:

YAML

task:
  agentModelOverrides:
    sonic: '@fast_worker'
    task: '@good_worker'
modelRoles:
  fast_worker: my-gateway/vendor/fast-model
  good_worker: my-gateway/vendor/big-model:high

Esse override vale para todo subagente sonic e task, não só para o /vibe. No meu caso não configurei nada: o fast herda o default (DeepSeek V4 Flash) e o good cai no modelo ativo do diretor (Opus). Braçal barato, julgamento caro.

Como brifar. O worker não vê a conversa do diretor. Dê arquivos, restrições e um critério de aceite que dê para checar:

TEXT

Objetivo: paginação por cursor em GET /api/orders.
Arquivos: src/api/orders.ts, tests/orders.test.ts. Não mexa em outros.
Aceite: `npm test -- orders` passa, com um teste novo para a última página.
Entregue: arquivos tocados e a saída do teste.

Como verificar. O próprio doc diz: worker que terminou significa que o turno acabou, não que ele acertou. O diretor lê os arquivos tocados e a saída completa em agent://<id>. Um worker por frente de trabalho, fast e good em paralelo, e o good revisando o fast quando importa.

Armadilhas: sair do /vibe encerra todos os workers; não combina com plan mode nem goal mode; com ele ativo, não dá para criar, apagar, forkar ou mover a sessão. Este post, inclusive, foi rascunhado por um worker do omp numa sessão de diretor.

9. Skills, MCP e AGENTS.md

AGENTS.md: o omp carrega ~/.omp/agent/AGENTS.md, .omp/AGENTS.md e um AGENTS.md solto, procurado do diretório atual até a raiz do repo (lê CLAUDE.md também). Mantenha curto: regras duras e onde está o resto.
Skills: um diretório com SKILL.md (name e description no frontmatter). Só nome e descrição vão para o prompt; o corpo carrega sob demanda (skill://<nome>). As suas ficam em ~/.omp/agent/skills/; com autolearn, o agente escreve as dele em ~/.omp/agent/managed-skills/. Eu tenho umas 30 minhas (classes de vulnerabilidade, metodologia, triagem, escrita de relatório) e dezenas de gerenciadas.
MCP: ~/.omp/agent/mcp.json, com ${VAR} expandido. Eu uso o Burp Suite, pela extensão oficial MCP Server da PortSwigger (SSE local, por padrão em http://127.0.0.1:9876), e uma base de conhecimento privada, um servidor MCP em Python sobre as minhas anotações:

JSON

{
  "mcpServers": {
    "burp": { "type": "sse", "url": "http://127.0.0.1:9876" },
    "kb": {
      "type": "stdio",
      "command": "${HOME}/kb/.venv/bin/python",
      "args": ["${HOME}/kb/server.py"],
      "env": { "KB_PATH": "${HOME}/kb/data" }
    }
  }
}

10. Um gostinho: bug bounty

Para programa grande eu abro vários terminais com omp, cada um com um papel, e eles conversam só pelo filesystem. Eu chamo isso de matilha: um orch cuida do escopo e da fila, atacantes a1..aN pegam um host por vez, e um triage valida os candidatos. Toda escrita compartilhada passa por um script bash, o bin/hb:

TEXT

~/hunting/
├── PROTOCOL.md            # o contrato: papéis, lease, rate, prova
├── bin/hb                 # o barramento
├── scope/<program>/       # eligible.txt, deny.txt
└── state/
    ├── queue.jsonl        # fila append-only
    ├── claims/<host>/     # lease por mkdir atômico (dono + epoch)
    ├── findings.jsonl     # tudo nasce "candidate"
    ├── dead-ends.md       # negativos verificados + controle usado
    ├── intel.md           # padrão reutilizável: "[tag] fato → ação"
    └── loot/F-0001/       # request.txt, response.txt

O loop de um atacante:

BASH

HOST=$(bin/hb next a1) || exit 0     # lease atômico do próximo host
bin/hb inscope "$HOST" || { bin/hb release "$HOST" a1; exit 3; }
grep -i "$HOST" state/dead-ends.md state/intel.md   # não repetir teste morto
ffuf -u "https://$HOST/FUZZ" -w wordlists/base.txt -ac -rate 20 -t 10 -o "recon/$HOST/ffuf.json"
bin/hb finding a1 "$HOST" idor "https://$HOST/api/orders?id=2" "BOLA em /orders" "200 com pedido da conta B"
bin/hb done "$HOST" a1 findings "1 candidate"

Os guardrails são executáveis, não promessas do modelo:

Escopo: hb inscope devolve exit 0, 2 ou 3; deny vence allow; host não listado não é tocado.
Rate: cap explícito por ferramenta, request manual a 1/s por host, e 403/429 em rajada pausa o host por 10 minutos.
Prova antes de alegação: sem request e response em state/loot/, é só candidato. A triagem reproduz do zero com controle negativo, num modelo de outra família.
Revisão humana: o agente pode rascunhar o relatório, mas a reprodução manual, a revisão e o envio são meus.

Isso rende um post só para ele. Fica para o próximo.

Fechando

O harness não pensa por você, mas faz o seu método rodar igual toda vez, e com um terminal que dá gosto de olhar. Recapitulando:

Um terminal com fonte customizável: Warp (macOS/Linux/Windows) ou Windows Terminal.
JetBrainsMono Nerd Font: brew install --cask no macOS, zip + fc-cache no Linux, zip → Instalar no Windows; selecionada no terminal.
(Opcional) zsh + Oh My Zsh + Powerlevel10k, p10k configure (no Windows, dentro do WSL2).
omp: brew install can1357/tap/omp, curl -fsSL https://omp.sh/install | sh ou irm https://omp.sh/install.ps1 | iex; depois omp setup e omp login ou uma API key.
Tema e ícones: theme.dark, symbolPreset, statusLine.preset, composer.shape.
Memória, segredos e aprovação.
Papéis de modelo e, se precisar, um gateway no models.yml.
/vibe quando o básico estiver chato de tão confiável.

FLAMEEE

O edge te lê antes do payload

Anatomia de um ClientHello#

As extensões são a assinatura#

GREASE: ruído de propósito#

TLS 1.2 e 1.3 não se parecem no fio#

Cada stack escreve o próprio hello#

JA3: uma linha, um MD5 e um problema#

2023: o Chrome quebrou o JA3 de propósito#

JA4: como ler o fingerprint inteiro#

Ordenar é uma decisão de projeto#

O que o JA4 escolhe não ver#

Não é só TLS#

Fingerprint é chave, não veredito#

Quem calcula isso hoje#

O que eu levo disso#

omp: do zero ao /vibe

O que é um harness#

Por que o omp#

1. Pré-requisitos e terminal#

2. Nerd Font#

3. A cara do shell (opcional)#

4. Instalando o omp#

5. Deixando o omp bonito#

6. Configs que valem a pena além do visual#

7. Provedores e modelos#

8. /vibe#

9. Skills, MCP e AGENTS.md#

10. Um gostinho: bug bounty#

Fechando#

Anatomia de um ClientHello

As extensões são a assinatura

GREASE: ruído de propósito

TLS 1.2 e 1.3 não se parecem no fio

Cada stack escreve o próprio hello

JA3: uma linha, um MD5 e um problema

2023: o Chrome quebrou o JA3 de propósito

JA4: como ler o fingerprint inteiro

Ordenar é uma decisão de projeto

O que o JA4 escolhe não ver

Não é só TLS

Fingerprint é chave, não veredito

Quem calcula isso hoje

O que eu levo disso

O que é um harness

Por que o omp

1. Pré-requisitos e terminal

2. Nerd Font

3. A cara do shell (opcional)

4. Instalando o omp

5. Deixando o omp bonito

6. Configs que valem a pena além do visual

7. Provedores e modelos

8. /vibe

9. Skills, MCP e AGENTS.md

10. Um gostinho: bug bounty

Fechando