TgWitness / Documentazione

Cosa è stato testato →

Riferimento / Configurazione

TgWitness: Telegram Export, OSINT & Verification

Installare con un solo comando o eseguire l’acquisizione su GitHub Actions. Comprendere le opzioni di indagine, la scala pubblicata e ciò che un archivio verifica.

TgWitness è un esportatore open source per Telegram e un ambiente di lavoro per le indagini. Installarlo con un solo comando, collegare un account, scegliere le chat ed esportare un archivio firmato. Supporta inoltre la raccolta temporanea su GitHub Actions e il proseguimento delle indagini con modifiche salvate, osservazioni sulle cancellazioni, ricerche e report.

Inizia dall’attività che hai a disposizione#

Il tuo compito Percorso più breve Cosa riceverai
Salvare una conversazione o un account Installare, collegare un account, selezionare l’ambito di esportazione Un archivio firmato contenente la cronologia selezionata, i risultati della raccolta e il materiale di verifica
Raccogliere su un runner temporaneo Utilizzare GitHub Actions per acquisire i dati, autorizzare una nuova sessione e selezionare l’ambito Un archivio crittografato con provenienza del flusso di lavoro su GitHub
Seguire le modifiche nel tempo Mantenere attiva l’osservazione per le chat selezionate Versioni salvate, avvisi di cancellazione, allegati e copertura registrata
Analizzare e condividere i risultati Effettuare ricerche nell’archivio, utilizzare la bacheca dei casi e configurare un report o una copia da condividere Risultati collegati alle fonti e un trasferimento verificabile adatto al destinatario

Installazione con un solo comando#

Il programma di installazione include Python e le dipendenze. Il checkout del codice sorgente, Docker, un provider di IA e un testimone indipendente sono opzioni facoltative, non prerequisiti per l’installazione.

Linux / macOS:

curl -fsSL https://get.destroy.tools/install.sh | bash

Windows, in PowerShell o nel Prompt dei comandi:

powershell.exe -NoProfile -ExecutionPolicy Bypass -Command "irm https://get.destroy.tools/install.ps1 | iex"

Apri il pannello, collega il tuo account Telegram e seleziona l’ambito di raccolta. L’installazione non avvia automaticamente la raccolta. La guida all’installazione spiega l’accesso locale, i server, gli aggiornamenti e la verifica della build scaricata.

Per un'esecuzione temporanea, seguire la procedura GitHub Actions capture . Tale flusso di lavoro richiede un fork su GitHub, l'autorizzazione e una password per l'archivio. La pagina capture spiega tali passaggi e il tempo a disposizione per la sessione prima dell'esecuzione. Scaricare e conservare l'archivio risultante e il relativo materiale di verifica.

Ulteriori impostazioni qualora l’attività lo richieda#

L’esportazione di una singola chat richiede un account e un ambito selezionato. L’osservazione continua, gli account multipli, i proxy, le politiche sugli allegati, la progettazione dei report, l’accesso dei revisori, i timestamp esterni e l’archiviazione fuori sede soddisfano diversi requisiti di indagine e di trasferimento dei dati. Configurare tali funzionalità quando sono rilevanti.

Ambito di applicazione, autorizzazioni e copie di condivisione ridotte al minimo aiutano gli operatori a scegliere cosa raccogliere e divulgare. Le linee guida sulla giurisdizione e le impostazioni dei report supportano tale decisione; la selezione di un profilo non garantisce di per sé la conformità legale o l’ ammissibilità. Vedere esportazione account, accesso e configurazione report.

L’applicazione viene eseguita sul computer o sul server prescelto. La raccolta di base non richiede una GPU né un LLM. Le funzionalità opzionali di OCR, trascrizione e analisi AI hanno i propri requisiti di risorse. Dimensionare l’implementazione in base alla frequenza dei messaggi, agli allegati, alla cronologia conservata e agli account simultanei; la facilità di installazione non garantisce un ingombro di memoria fisso per ogni carico di lavoro.

Mantenere la documentazione, a chiunque possa essere d’aiuto#

Lo scopo è preservare il materiale osservato, il contesto e le modifiche indipendentemente dalla posizione che sostengono. Le prove potrebbero mettere in discussione la versione degli eventi fornita dallo stesso collettore. Mantenere identificabili le osservazioni di origine, le lacune nella copertura e le conclusioni analitiche in modo che un’altra persona possa valutare lo stesso materiale.

La logica è la seguente: osservazione visibile sull’account → registro firmato → esportazione → verifica da parte del destinatario. Le modifiche salvate aggiungono nuove versioni. Le osservazioni relative alle cancellazioni conservano i contenuti precedentemente acquisiti. I registri di copertura evidenziano le interruzioni note. I rapporti e le analisi basate sull’intelligenza artificiale fanno riferimento alle fonti salvate; un’interpretazione non diventa un’osservazione di origine semplicemente perché compare in un rapporto firmato.

Controllo di verifica Cosa può stabilire un destinatario
Hash dei file, firme e catena di journal I record e i file forniti corrispondono alla chiave prevista e ai limiti del journal
Un checkpoint o witness conservato separatamente L’archivio corrisponde a uno stato del journal precedentemente conservato
Un timestamp esterno verificato I byte a cui si fa riferimento esistevano al momento del timestamp in base ai presupposti di affidabilità indicati
Attestato di acquisizione su GitHub L’archivio corrisponde al flusso di lavoro approvato, alla revisione del collettore e al digest registrato

Questi controlli supportano la verifica dell’integrità e della provenienza. Non trasformano il contenuto di un messaggio in un’affermazione vera né ricostruiscono messaggi cancellati non visualizzati. Utilizzare un’impronta digitale della chiave ottenuta in modo indipendente e seguire i passaggi di verifica descritti in (la guida alla fiducia) e (formato delle prove).

Scala pubblicata e prestazioni misurate#

I risultati riportati di seguito descrivono diversi carichi di lavoro e date. I conteggi non sono intercambiabili: un evento di log non corrisponde necessariamente a un singolo messaggio di Telegram.

Data Carico di lavoro Risultato pubblicato Cosa è stato misurato
1 novembre 2026 Server in esecuzione, dieci database dell’area di lavoro 1,610,818: registrazioni del journal; 900,232: eventi relativi a nuovi messaggi, 80,683: eventi di modifica e 400,536: eventi di cancellazione Inventario in sola lettura; non si tratta di un test di throughput né di una nuova verifica dell’intera catena
5 novembre 2026 Effettuare ricerche tra i messaggi sintetici 1,000,000 nelle chat 200 Indice creato in 71 secondi; tempi medi di ricerca per query compresi tra 9 e 190 ms Benchmark di ricerca locale; non consegna in tempo reale su Telegram
6 novembre 2026 Due nuove esportazioni reali da Telegram Messaggi 27,030 e 29,299; 56,329 in entrambe le esecuzioni Due account per ogni esecuzione tramite WARP, testo e metadati, nessun download di allegati
6 novembre 2026 Le stesse due esportazioni, comprese la preparazione e il packaging 127.713 e 141.781 messaggi al secondo Tassi di esportazione completa misurati; entrambi gli archivi sono stati verificati rispetto alle chiavi fissate

Il record di verifica fornisce l’inventario del server, i controlli in tempo reale sulla raccolta e le misurazioni delle ricerche. Le prestazioni di esportazione pubblicano le due esecuzioni effettive, l’hardware, le durate, gli hash degli archivi e i file di misurazione firmati. Essi stabiliscono i risultati per le revisioni e le condizioni registrate, non un tasso universale o un limite massimo di capacità.

Cronologia e durata dei test#

Il responsabile del progetto riferisce di oltre sei mesi di test a partire dal 6 novembre 2026. Questo descrive la cronologia dei test del progetto. Le misurazioni pubbliche datate sopra riportate documentano singole esecuzioni; esse non costituiscono una raccolta verificata in modo indipendente e ininterrotta per sei mesi. Anche l’età dei messaggi esportati è diversa dal tempo in cui il collettore è rimasto in esecuzione.

Leggere con precisione lo stato delle funzionalità#

Valutare ogni flusso di lavoro rispetto alla sua implementazione, alla build pubblicata e ai test registrati. Il codice sorgente è attualmente contrassegnato come anteprima. Tale etichetta di rilascio coesiste con la raccolta funzionante, le esportazioni, la verifica indipendente e le misurazioni di scala pubblicate. Una funzionalità in anteprima e un flusso di lavoro convalidato possono coesistere nella stessa applicazione; descrivere la funzionalità specifica e le prove alla base di una valutazione.

Utilizzare capacità attuali, funzionalità e limiti, verifica e il log delle modifiche insieme. Registrare la revisione testata quando si cita un risultato. La 6 L’istantanea di misurazione di novembre conserva anche i test falliti e saltati; questi non sono considerati superati.

Leggibile sia da persone che da strumenti di intelligenza artificiale#

Il sito web fornisce una versione concisa (llms.txt), un manuale completo in inglese nelle sezioni llms-full.txt e llms-full.md, nonché edizioni in Markdown delle sue pagine. Si tratta di formati di documentazione, non di un requisito dell’IA per l’esecuzione di TgWitness.

L'accesso opzionale da riga di comando MCP e consente agli strumenti autorizzati di leggere i record salvati selezionati. Il contenuto dei messaggi rimane un input non attendibile. I riassunti devono citare le fonti, distinguere i fatti osservati dalle inferenze e mantenere l'incertezza. La ricerca full-text, l'OCR e l'output dell'IA non modificano le osservazioni originali firmate.