Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
thermoptic — Un proxy HTTP stealth di nuova generazione che maschera perfettamente le richieste come browser Chrome su tutti i livelli dello stack. | Kitploit
Strumenti/GitHubGitHub/mandatoryprogrammer/thermoptic
Proxy Web e IntercettazioneStrumenti di ImpersonificazioneRaccolta InformazioniBypass WAFCrawlerAnti-BotSpoofing dell'Impronta DigitaleBypass CAPTCHA
GitHubmandatoryprogrammer/thermoptic

thermoptic

Un proxy HTTP stealth di nuova generazione che maschera perfettamente le richieste come browser Chrome su tutti i livelli dello stack.

Vedi Repository
1.0k664 mesi faRevisionato da Kitploit

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

thermoptic

"Non ci credo, camuffamento thermoptic!"

Cos'è?

Questo è un proxy HTTP progettato per bypassare i servizi che utilizzano tecniche di fingerprinting come JA4+ per bloccare determinati client HTTP. Utilizzando questo proxy, puoi usare i tuoi client HTTP preferiti come curl e avere comunque impronte digitali magicamente indistinguibili da quelle di un vero browser web (Chrome/Chromium). thermoptic include anche alcune funzionalità divertenti per mitigare il fingerprinting basato su JavaScript. Inoltre, semplifica lo scraping ibrido, usando insieme sia un browser web che client HTTP di basso livello.

Anche se non hai familiarità con il fingerprinting JA4+, se hai mai fatto scraping probabilmente sei già stato bloccato da questo sistema. Servizi popolari come Cloudflare usano queste tecniche (e altri trucchi) per rilevare l'uso di client HTTP "non umani" e bloccare le richieste. Questi servizi possono anche usare questo fingerprinting per rilevare se avvii una sessione con un browser reale e poi passi a un client di basso livello come curl. risolve tutti questi problemi presentando un'impronta digitale unificata di browser "reale" per tutte le richieste di scraping.

thermoptic

Esempio

Ecco un esempio di impronta JA4H (HTTP) di curl senza il proxy:``` $ curl https://ja4db.com/id/ja4h/ ge11nn090000_b6a016211e8a_000000000000_e3b0c44298fc

root@kitploit:~
Questo è piuttosto diverso dall'impronta digitale che Chrome produce quando visiti l'URL direttamente:```
ge11cn19enus_f2808f0d04cf_9a10d4221160_7068f58def6e

Tuttavia, quando usiamo il proxy per effettuare la richiesta, la nostra impronta JA4H è magicamente identica:``` $ curl --proxy http://thermoptic:1234 https://ja4db.com/id/ja4h/ ge11cn19enus_f2808f0d04cf_9a10d4221160_7068f58def6e

root@kitploit:~
(Idem per il nostro fingerprint TLS JA4, ecc.).

## Setup

Per avviare un proxy `thermoptic` che maschera il tuo traffico tramite un'istanza Chrome containerizzata su Ubuntu 22.04:

Configurazione Docker standard (funziona su host senza runtime GPU):```
docker compose up --build

Ecco fatto, ora puoi inoltrare il traffico attraverso di esso:``` curl --proxy http://127.0.0.1:1234 --insecure https://ja4db.com/id/ja4h/

root@kitploit:~
Note importanti:
* Di default il proxy viene eseguito senza autenticazione. Se hai intenzione di esporre il proxy esternamente, assicurati di impostare l'autenticazione con le variabili d'ambiente `PROXY_USERNAME` e `PROXY_PASSWORD`.
* Se non vuoi usare `---insecure`, devi usare il file CA generato situato in `./ssl/rootCA.crt`. Questo viene generato la prima volta che esegui `thermoptic`.
* Puoi connettere `thermoptic` a qualsiasi istanza di Chrome/Chromium avviata con il flag `--remote-debugging-port`. Questo è essenziale perché vorrai impostare e usare il proxy attraverso ambienti più comuni per mantenere il tuo fingerprint il più possibile sotto traccia (ad es. Chrome su Windows).
* L'override compose per la GPU è pensato per host NVIDIA che hanno già installato il runtime/toolkit NVIDIA di Docker. Riserva il dispositivo GPU, monta `/dev/dri` e consente al container Chrome incluso di passare al percorso di rendering NVIDIA/Vulkan. Per usarlo, esegui `docker compose -f docker-compose.yml -f docker-compose.gpu.yml up --build`.

## Caratteristiche

- 🕵️ [Proxy con parità di browser](#how-does-this-cloaking-work-exactly) che riproduce le richieste tramite una sessione Chrome reale per corrispondere ai fingerprint JA4 byte per byte.
- 🤝 Serve poco o nessun codice personalizzato per integrare il tuo client HTTP (ad es. `curl`, `requests`, ecc.) con `thermoptic`: basta [impostare il proxy](#setup) e ai tuoi fingerprint ci pensiamo noi.
- 🪝 [Framework di hook](#handling-browser-javascript-fingerprinting-with-thermoptic-hooks) per automazione before-request/after-request/on-start, così puoi pilotare l'intero browser per risolvere sfide o catturare artefatti.
  - 📘 Un esempio di hook per la risoluzione di Cloudflare Turnstile è disponibile in [`./hooks/onstart.js`](https://github.com/mandatoryprogrammer/thermoptic/blob/main/hooks/onstart.js).
- 🖥️ [Interfaccia di controllo del browser web](#control-the-dockerized-chrome-browser-via-web-ui-xpra) (su `http://127.0.0.1:14111`) per controllare la finestra del browser Chrome in Docker. Utile per accedere manualmente ai siti e poi usare senza soluzione di continuità il proxy per effettuare richieste come la tua sessione autenticata (e per il debug).
- 🔌 Imposta un URI proxy HTTP o SOCKS upstream tramite la variabile d'ambiente `UPSTREAM_PROXY` in `docker-compose.yml`.
- 🛡️ Health check integrati e ciclo di controllo del riavvio per rilevare browser bloccati e recuperare automaticamente senza bisogno della supervisione di un operatore.
- ⚡ Supporta HTTP/1.1 e HTTP/2, consentendo di instradare il traffico tramite l'uno o l'altro protocollo. (_Nota: puoi parlare HTTP/1.1 con il proxy, e il Chrome pilotato può negoziare con il sito di destinazione su un protocollo diverso._)

## Come funziona esattamente questo cloaking?

![Esempio di diagramma visivo](https://assets.kitploit.com/production/public/readmes/49068/f95c08eccfdbfce1b14513f2a5ad2a33a9b0fb0bd6851a2d005aedf4ff196338.png)

* Una richiesta HTTP viene effettuata usando un client HTTP come `curl` con `thermoptic` impostato come proxy.
* `thermoptic` analizza la richiesta per determinare al meglio quale tipo di richiesta browser *dovrebbe* essere (ad es. visita manuale di un URL? Invio di un modulo? Una richiesta `fetch()`?).
* `thermoptic` usa il [Chrome Debugging Protocol (CDP)](https://chromedevtools.github.io/devtools-protocol/) per controllare il browser e predisporre una pagina che simula la richiesta esattamente come avverrebbe normalmente in un browser web reale.
* `thermoptic` innesca la richiesta tramite il contesto simulato e cattura la risposta HTTP.
* `thermoptic` invia la risposta HTTP al client.

Poiché il browser effettua realmente la richiesta usando l'intero stack, i fingerprint JA4 risultanti sono identici.

NOTA: Poiché molti WAF usano fingerprinting a livello JavaScript dei browser web, `thermoptic` espone anche hook per utilizzare il browser nei passaggi chiave del processo di scraping. Vedi [questa sezione](#handling-browser-javascript-fingerprinting-with-thermoptic-hooks) per maggiori informazioni.

## Perché *questo* approccio rispetto ad altre soluzioni?

Per dirla chiaramente: altri approcci hanno difetti fondamentali che impediscono loro di essere una soluzione pratica a lungo termine al problema del fingerprinting del browser.

Molti altri tentativi di "battere" il fingerprinting JA4+ del browser lo fanno reimplementando i vari livelli dello stack del browser. Questo approccio presenta una serie di seri svantaggi, come:

* Richiedere grande attenzione per corrispondere perfettamente al comportamento dell'implementazione "reale" del browser. Di conseguenza, *qualsiasi* stranezza o discrepanza può essere usata per distinguere questi client dall'implementazione "reale" del browser.
* Tentare di risolvere il problema solo a un livello dello stack. Chrome utilizza più protocolli per fornire un'esperienza di navigazione web. Di conseguenza, anche se hai creato un livello TLS perfettamente corrispondente, il livello HTTP potrebbe tradirti se non è perfetto byte per byte.
* Poiché i browser "reali" cambiano regolarmente il loro comportamento, i loro fingerprint cambiano e di conseguenza questi strumenti richiedono costantemente un lavoro di sviluppo più intensivo per compensare.

Al contrario, poiché `thermoptic` utilizza il browser stesso per effettuare le richieste HTTP:
* Ogni livello dello stack come TCP, TLS, HTTP è indistinguibile dal browser reale, perché la richiesta viene effettuata *usando* un browser reale nel modo in cui avverrebbe *normalmente*.
* I cambiamenti nel comportamento del browser ai vari livelli sono minimamente dirompenti: il browser controllato da `thermoptic` deve solo essere aggiornato per corrispondere all'ultimo set di fingerprint.

Ovviamente, nessuna soluzione è priva di svantaggi. Consulta la documentazione in `DOWNSIDES.md` per un elenco dettagliato degli svantaggi dell'approccio `thermoptic`.

## FAQ

### Perché il nome `thermoptic`?

"Thermoptic" (abbreviazione di "thermoptic camouflage", camuffamento termottico) è un riferimento al camuffamento fittizio [usato dalla Major nell'anime Ghost in the Shell (1995)](https://ghostintheshell.fandom.com/wiki/Thermoptic_camouflage). Nel film, questo camuffamento è in grado di nascondere chi lo indossa su più spettri di rilevamento, inclusi sia la luce visibile sia la radiazione termica. Analogamente, questo strumento cerca di nascondere l'utente dal fingerprinting su più canali (HTTP, TLS, ecc.).

### JA4+ è una **suite** di fingerprint! Quali spoofa?

Questo strumento spoofa i seguenti fingerprint JA4 per farli essere esattamente come il browser Chrome/Chromium a cui sei connesso:
* JA4 (fingerprint TLS)
* JA4H (fingerprint HTTP)
* JA4X (fingerprint del certificato TLS X509)
* JA4T (fingerprint TCP)

### E se volessi usare un altro proxy HTTP/SOCKS upstream con questo?

Ora `thermoptic` instrada l'istanza Chrome controllata attraverso un servizio interno `proxyrouter`, così puoi puntare Chrome a proxy HTTP o SOCKS upstream (inclusi quelli che richiedono credenziali). Imposta l'URI del proxy upstream modificando il valore `UPSTREAM_PROXY` in `docker-compose.yml` sotto il servizio `proxyrouter`. Se lo lasci vuoto, Chrome parla direttamente con Internet attraverso il proxy non autenticato del cluster.

Esempio di impostazione di un proxy SOCKS upstream:```yaml
  proxyrouter:
    environment:
      UPSTREAM_PROXY: "socks5://username:[email protected]:1080"

Tieni presente che alcuni proxy a monte possono modificare le fingerprint di basso livello (ad esempio, i metadati TCP) che possono ridurre la parità con un browser residenziale.

E i cookie?

thermoptic caricherà il browser con i cookie che il tuo client specifica nell'header Cookie. La richiesta includerà quindi questi cookie una volta eseguita nel contesto del browser. Questo viene fatto per garantire che il server non possa rilevare l'ordine dei cookie o altri trucchi economici del genere.

NOTA: questi cookie rimarranno anche dopo la richiesta. Se desideri implementare una logica di pulizia per i cookie, scrivi un hook thermoptic.

OK, ma serve un browser web completo per cliccare sul prompt X per superare la verifica umana!

Sì, thermoptic supporta un uso ibrido come questo, vedi questa sezione per maggiori informazioni.

La mia fingerprint per la richiesta X non corrisponde alla fingerprint del browser!

Devi assicurarti di impostare correttamente header come X-Fetch-*, Origin e Referer. Se non segnali questi header a thermoptic, non sarà in grado di eseguire la richiesta nel modo stealth appropriato.

Senza impostare header contestuali, thermoptic imposterà valori predefiniti che potrebbero non riflettere esattamente ciò che il tuo sito di destinazione si aspetta. Ad esempio, se non imposti un header Origin, imposterà un Origin di null; se non imposti un header Referer, semplicemente non invierà alcun Referer.

È nel tuo interesse includere questi header contestuali così che la tua richiesta sia il più stealth possibile! thermoptic non può leggere nella tua mente, può solo leggere la tua richiesta :).

Il Chrome Debugging Protocol stesso è fingerprintabile!

In generale, questo si applicherebbe solo nel caso degli hook thermoptic che utilizzano temporaneamente il browser web completo per superare i controlli a livello di JavaScript/browser. Quando usi temporaneamente questi hook e la modalità browser completo, devi fare attenzione a non essere fingerprintato come bot (ad esempio, evita insidie come Runtime.enable).

Perché rilasciare questo strumento? Non ti importa degli attori malintenzionati che stai abilitando?!

Le considerazioni etiche e la complessa teoria dei giochi in gioco qui sono più di quanto si possa rispondere in un README. Sentiti libero di contestare uno qualsiasi di questi punti eccessivamente semplificati quando mi attacchi via email/Twitter/Github, però:

  • Non credo che lo scraping sia intrinsecamente non etico. Al contrario, il libero flusso di informazioni sotto forma di scraping è fondamentale per come molti incredibili progetti hanno trovato nuova vita.
  • A causa degli incentivi in gioco, il web scraping e la prevenzione dei bot web sono ormai diventati un noioso gioco di bruciatura di capitale. Vuoi prevenire lo scraping? Paga un servizio che faccia ciò per te. Vuoi bypassare questi stessi servizi? Paga un servizio che faccia ciò per te. Lo scraping è fin troppo importante per essere lasciato solo a chi può permetterselo, rilascio questo progetto open source come un gesto della mia convinzione in tal senso.
  • L'attuale paradigma dei framework anti-bot è estremamente invasivo a causa della sua attenzione al fingerprinting. Gli script avanzati di fingerprinting del browser sono difficilmente distinguibili, per funzionalità, dai browser exploit kit. Spero, ma non mi aspetto, un aumento a gradino sul lato dello scraping per aiutare a sovvertire questo ciclo di feedback e incoraggiare approcci alternativi.

Per ulteriori chiacchiere sulla corsa agli armamenti dello scraping, ti chiedo almeno di offrirmi prima una birra. A essere onesto, odio scrivere questi noiosi saggi etici nei miei README, quindi sentiti libero di immaginarmi semplicemente come un nerd malvagio che vuole renderti la vita più difficile.

Gestire il fingerprinting JavaScript del browser con gli hook thermoptic

thermoptic ti permette di configurare script personalizzati per eseguire azioni del browser quando:

  • Il browser viene avviato per la prima volta (variabile d'ambiente ON_START_HOOK_FILE_PATH)
  • Una richiesta sta per essere inoltrata tramite proxy (variabile d'ambiente BEFORE_REQUEST_HOOK_FILE_PATH)
  • Una richiesta ha appena terminato di essere inoltrata tramite proxy (variabile d'ambiente AFTER_REQUEST_HOOK_FILE_PATH)

Questo ti permette di usare il Chrome Debugging Protocol per cliccare e impostare i cookie appropriati per i siti che richiedono un vero browser web per un passaggio di verifica. Puoi quindi usare il proxy thermoptic per continuare la tua sessione mimetizzato attraverso lo stesso browser.

Per fare ciò, modifica il file JavaScript di hook appropriato con il tuo codice personalizzato per orchestrare il browser in modo appropriato tramite l'interfaccia chrome-remote-interface fornita:``` // cdp is an instance of a connected browser, use it to run your browser actions export async function hook(cdp) { console.log([STATUS] Browser start hook called successfully!); }

root@kitploit:~
Per un'implementazione di esempio, vedi il file [`./hooks/onstart.js`](https://github.com/mandatoryprogrammer/thermoptic/blob/main/hooks/onstart.js) che [bypassa il CAPTCHA Turnstile di Cloudflare](https://github.com/mandatoryprogrammer/thermoptic/blob/main/tutorials/turnstile/cloudflare-turnstile-bypass.md) (e altri controlli anti-bot di Cloudflare).

## Controlla il browser Chrome dockerizzato tramite Web UI (Xpra)

`thermoptic` include una Web UI Xpra disponibile all'indirizzo `http://127.0.0.1:14111`. Questo ti permette di controllare manualmente il browser Chrome dockerizzato con facilità:

<img src="https://assets.kitploit.com/production/public/readmes/49068/0fa1b187f46405dda2b0db5d461619daa6a7bdad2c385cb51994e870d9054d10.png" width="100%">

È utile per cose come:
* Accedere al tuo account così da poter effettuare richieste autenticate tramite `thermoptic` usando il tuo client HTTP preferito come `curl`.
  * Ad esempio, se accedi a `reddit.com` con il browser, tutte le richieste che invii a Reddit tramite `thermoptic` saranno automaticamente autenticate con il tuo account Reddit!
* Eseguire il debug dei tuoi hook personalizzati di `thermoptic` e verificare eventuali problemi con i siti web.

## Configurazione

Queste variabili d'ambiente specificano come `thermoptic` deve essere configurato quando viene eseguito.

`HTTP_PROXY_PORT`: La porta su cui il proxy `thermoptic` deve mettersi in ascolto. Se stai eseguendo `thermoptic` in Docker dovrai anche modificare di conseguenza il campo di mappatura `ports`.

`CHROME_DEBUGGING_PORT`: La porta su cui viene esposto il Chrome Debugging Protocol. Questa porta viene specificata quando si avvia Chrome/Chromium con il flag `--remote-debugging-port` impostato su un valore come `9222`.

`CHROME_DEBUGGING_HOST`: L'host su cui viene esposto il Chrome Debugging Protocol. Spesso è `127.0.0.1` se il browser viene avviato localmente e `thermoptic` non è in esecuzione in Docker. Se invece è in esecuzione in Docker potresti dover usare `host.docker.internal`; vedi la [documentazione Docker](https://docs.docker.com/desktop/features/networking/#i-want-to-connect-from-a-container-to-a-service-on-the-host) per maggiori informazioni.

`PORT`: La porta CDP che il container Chrome pubblica verso il resto dello stack. Tienila allineata con `CHROME_DEBUGGING_PORT` così che il bridge `socat` continui a funzionare come previsto.

`CHROME_CONTROL_PORT`: La porta del servizio di controllo di Chrome che thermoptic usa per gestire il browser (ad esempio, per inviare richieste di riavvio).

`CHROME_CONTROL_COOLDOWN_MS`: Tempo minimo in millisecondi tra i tentativi di riavvio di Chrome. Usalo per evitare rapidi loop di riavvio quando si verificano più errori in rapida successione.

`ENABLE_GUI_CONTROL`: Impostalo su `true` per avviare il pannello web xpra così puoi guidare il Chrome containerizzato visitando `http://127.0.0.1:14111`. Disabilitalo per esecuzioni solo headless.

`CHROME_SCREEN_WIDTH` / `CHROME_SCREEN_HEIGHT`: Le dimensioni in pixel del display Chrome headful dockerizzato.

`CHROME_ENABLE_GPU`: Controlla se il container Chrome incluso deve tentare di usare l'accelerazione GPU dell'host. `auto` (predefinito) abilita il percorso NVIDIA/Vulkan quando sono presenti il runtime e i device node richiesti; in caso contrario ripiega sul rendering software. Impostalo su `false` per forzare il vecchio comportamento solo software.

`CHROME_PROFILE_RECOVERY`: Quando è `true` (predefinito), il launcher di Chrome incluso effettuerà un tentativo di recupero se Chrome muore immediatamente con lo stesso codice di uscita da crash-loop osservato in un profilo danneggiato (`133`). I contenuti del profilo corrotto vengono spostati in `/tmp/chrome-profile-recovery/` all'interno del container prima di riprovare con un profilo pulito.

`PROXY_USERNAME`: Lo username usato per autenticarti al proxy; il valore predefinito è `changeme`. Se non impostato, il proxy viene eseguito senza richiedere autenticazione.

`PROXY_PASSWORD`: La password usata per autenticarti al proxy; il valore predefinito è `changeme`. Se non impostata, il proxy viene eseguito senza richiedere autenticazione.

`THERMOPTIC_CONTAINER_RUNTIME`: Indica che thermoptic è in esecuzione all'interno del container incluso. Lascialo impostato su `true`; controlla comportamenti come i health check integrati che hanno senso solo nella configurazione Docker completa.

`HEALTHCHECK_ENDPOINT_PORT`: La porta su cui thermoptic espone il proprio endpoint web di health check. Il worker di salute lo chiama tramite il proxy; se smette di rispondere, Chrome viene riavviato automaticamente per sbloccare le sessioni congelate.

`HEALTHCHECK_ENDPOINT_PATH`: Il percorso HTTP servito dall'endpoint di health check descritto sopra. Modificalo se ti serve un URL diverso.

`ON_START_HOOK_FILE_PATH`: Codice Node personalizzato da eseguire all'avvio del proxy. Il proxy non inizierà ad ascoltare finché questo hook non sarà completato; vedi l'esempio in `./hooks/`. L'esempio mostra come usare il browser per superare il controllo JavaScript di Cloudflare prima di avviare il proxy.

`BEFORE_REQUEST_HOOK_FILE_PATH`: Codice Node personalizzato da eseguire prima che una richiesta venga inoltrata tramite proxy. È utile se hai bisogno che il browser superi qualche controllo prima che venga effettuata una richiesta HTTP a un sito.

`AFTER_REQUEST_HOOK_FILE_PATH`: Codice Node personalizzato da eseguire dopo che una richiesta è stata inoltrata tramite proxy. Spesso è utile per operazioni come pulire i cookie impostati dal client tramite l'header `Cookie`.

`DEBUG`: Impostalo su `true` quando incontri un bug così thermoptic stampa diagnostica dettagliata prima che tu apra una segnalazione; lascialo su `false` durante il normale funzionamento.

## Sicurezza

Nota che al momento `thermoptic` è pensato per essere usato solo con client HTTP di cui ti fidi esplicitamente. *Non* è pensato per essere esposto a utenti non fidati.

Per qualsiasi vulnerabilità di sicurezza invia una segnalazione a `mandatory@` Gmail.
Scarica lo strumento