# TgWitness · Español > Documentation edition: Español. Project version: `0.9.1`. Source branch: `main`. This index links the Markdown editions of the public pages. The complete handbook is built from the same page content, including source URLs. Untranslated sections retain the English original; a language edition is not a claim that every section has been translated. - [Project context, installation, measured scale and verification limits](https://phishdestroy.github.io/TgWitness/docs/reference/overview/index.md) - [English project summary](https://phishdestroy.github.io/TgWitness/llms.txt) - [Complete handbook · Español](https://phishdestroy.github.io/TgWitness/es/llms-full.txt) - [Complete handbook as Markdown · Español](https://phishdestroy.github.io/TgWitness/es/llms-full.md) - [Source code and release history](https://github.com/phishdestroy/TgWitness) - [Collection modes and evidence levels](https://phishdestroy.github.io/TgWitness/es/guides/modes.md) - [Published checks and measurements](https://phishdestroy.github.io/TgWitness/docs/validation/index.md) ## Complete documentation map ### Guides - [Explorar el archivo](https://phishdestroy.github.io/TgWitness/es/docs/archive/index.md): Carga el historial, busca registros guardados, revisa las fuentes de IA y conecta tus herramientas. - [Captura de GitHub Actions](https://phishdestroy.github.io/TgWitness/es/docs/capture/index.md): Elige Takeout，exportación mediante la API normal o un diario de chat en un ejecutor temporal de GitHub． - [Cuenta dedicada](https://phishdestroy.github.io/TgWitness/es/docs/dedicated-account/index.md): Prepare una cuenta de Telegram independiente para la recopilación de datos. - [Empiece en cuestión de minutos](https://phishdestroy.github.io/TgWitness/es/docs/start/index.md): Instala con un comando, conecta una cuenta de Telegram y exporta un archivo verificable en Windows, Linux o macOS. - [Conecte una cuenta](https://phishdestroy.github.io/TgWitness/es/docs/accounts/index.md): Conecte su cuenta de Telegram mediante un código QR, un número de teléfono o la importación de una sesión. Seleccione las fuentes y compruebe que los nuevos mensajes se registran en su registro. - [Elija un proxy](https://phishdestroy.github.io/TgWitness/es/docs/proxies/index.md): Mantenga las rutas automáticas de MTProxy o utilice su propio proxy. Elija los modos de IP, las reglas de reserva y la ruta para las solicitudes externas. - [Exportar y verificar](https://phishdestroy.github.io/TgWitness/es/docs/exports/index.md): Exporte el historial de Telegram capturado, verifique las firmas y compare el registro con un punto de control conservado por un testigo independiente. - [Vea cómo funciona el registro de pruebas](https://phishdestroy.github.io/TgWitness/es/docs/concepts/index.md): Siga el recorrido de un mensaje desde su captura hasta el punto de control. Modifique un registro de ejemplo, vuelva a calcular su cadena SHA-256 y compruebe qué detecta un punto de control conservado. - [Investigue en todos los chats](https://phishdestroy.github.io/TgWitness/es/docs/cases/index.md): Lleve a cabo una investigación exhaustiva de Telegram en canales, grupos, chats privados y bots: captura completa de la cuenta, historial, contactos, enlaces, archivos, cronologías y pruebas verificadas. - [Crear un «Case Board»](https://phishdestroy.github.io/TgWitness/es/docs/case-board/index.md): Recopila las observaciones guardadas, los aspectos destacados exactos y los fragmentos de acción en un tablero privado, coméntalos con tu equipo y presenta una recopilación. - [Diseñar un informe](https://phishdestroy.github.io/TgWitness/es/docs/reports/index.md): Selecciona los datos del informe, uno de los ocho diseños y el contenido; a continuación, previsualiza y exporta el archivo en formato HTML, PDF firmado o un paquete completo de pruebas. - [Prepara una copia para compartir](https://phishdestroy.github.io/TgWitness/es/docs/handover/index.md): Selecciona los registros y campos que un destinatario puede recibir, revisa la copia final y verifica su manifiesto firmado y los límites del diario de origen. - [Gestionar un grupo de cuentas](https://phishdestroy.github.io/TgWitness/es/docs/groups/index.md): Compara los espacios de trabajo de grupo, busca una fuente, revisa los periodos de observación y aplica configuraciones compartidas con excepciones por cuenta. - [Mantenga la seguridad](https://phishdestroy.github.io/TgWitness/es/docs/security/index.md): Consulte dónde se almacenan las sesiones, las claves y las pruebas, qué datos salen de su equipo, qué protegen las medidas de seguridad y cómo reforzar la seguridad de una instalación. - [Compartir un caso](https://phishdestroy.github.io/TgWitness/es/docs/access/index.md): Proporcione a los revisores y analistas acceso a cuentas y chats seleccionados, con permisos diferenciados, límites de sesión y tokens revocables. - [Configurar un bot de TgWitness](https://phishdestroy.github.io/TgWitness/es/docs/witness/index.md): Publique puntos de control del registro firmado en su canal de Telegram con un testigo independiente, que cuente con su propia clave y acceso de solo lectura al recopilador. - [Manténgala en funcionamiento](https://phishdestroy.github.io/TgWitness/es/docs/server/index.md): Ejecute TgWitness en un servidor con almacenamiento persistente, acceso privado al panel de control, copias de seguridad y comprobaciones tras un reinicio. - [Averigüe qué ha fallado](https://phishdestroy.github.io/TgWitness/es/docs/troubleshooting/index.md): Compruebe el acceso al panel, la conexión a Telegram, los mensajes que faltan, FloodWait y el estado de Witness utilizando las señales adecuadas para cada problema. ### Reference - [Chats secretos: implementación y demostración](https://phishdestroy.github.io/TgWitness/es/docs/reference/secret-chats/index.md): Comprender la implementación independiente de Chat secreto, probar la interfaz ficticia y revisar los defectos pendientes. - [TgWitness: inicio, escala y pruebas](https://phishdestroy.github.io/TgWitness/es/docs/reference/overview/index.md): Instálala con un solo comando o capturala en GitHub Actions. Comprende las opciones de investigación, la escala publicada y lo que verifica un archivo. - [Cargar historial de fuentes](https://phishdestroy.github.io/TgWitness/es/docs/reference/history/index.md): Carga mensajes anteriores de fuentes habilitadas, pausa y reanuda, y verifica un informe de progreso firmado. - [Análisis de archivos](https://phishdestroy.github.io/TgWitness/es/docs/reference/analysis/index.md): Busca mensajes guardados, revisa las aportaciones de la IA y conserva informes analíticos con sus referencias de origen. - [Línea de comandos](https://phishdestroy.github.io/TgWitness/es/docs/reference/cli/index.md): Buscar, leer el contexto, contabilizar la actividad y exportar mensajes guardados desde scripts y agentes, con salida en formato --json, códigos de salida estables y tokens de solo lectura con ámbito limitado. - [Búsqueda de texto completo](https://phishdestroy.github.io/TgWitness/es/docs/reference/search/index.md): Busca mensajes guardados por formas de palabras, frases exactas, dominios y @nombres de usuario, mostrando primero los resultados más relevantes, con el índice vinculado al diario firmado. - [MCP de solo lectura](https://phishdestroy.github.io/TgWitness/es/docs/reference/mcp/index.md): Conecta un cliente MCP a espacios de trabajo y chats seleccionados con acceso temporal y revocable. - [OCR y transcripción locales](https://phishdestroy.github.io/TgWitness/es/docs/reference/media-analysis/index.md): Reconoce las imágenes y el audio capturados mediante un «worker» local; mantiene el texto derivado vinculado a su archivo de origen. - [Webhooks salientes](https://phishdestroy.github.io/TgWitness/es/docs/reference/webhooks/index.md): Envía eventos específicos a receptores HTTPS con firmas HMAC, reintentos y estado de entrega. - [Aviso de incompatibilidad con algunos operadores](https://phishdestroy.github.io/TgWitness/es/docs/reference/notice/index.md): Nuestra nota operativa sobre Taylor Wessing y su registro de fuentes. - [Aviso sobre incompatibilidades de licencia y arquitectura](https://phishdestroy.github.io/TgWitness/es/docs/reference/license/index.md): TgWitness cuenta con una licencia del MIT para todos, y por qué es arquitectónicamente incompatible con el flujo de trabajo de Taylor Wessing. - [Inicio rápido](https://phishdestroy.github.io/TgWitness/es/docs/reference/quickstart/index.md): Todas las formas de instalar y poner en marcha TgWitness: paquete para Windows, Python, Docker y la demostración sintética, con las primeras comprobaciones. - [Formatos de cuentas y sesiones](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/index.md): Inicie sesión mediante teléfono, código QR o clave de autenticación, importe sesiones de Telethon, Pyrogram o Telegram Desktop, y gestione varias cuentas. - [Acceso y permisos](https://phishdestroy.github.io/TgWitness/es/docs/reference/access/index.md): Configure el acceso a cuentas y chats, seleccione los permisos, limite las sesiones y las direcciones IP, y revoque el acceso. - [Conexión, servidores proxy y protección de datos](https://phishdestroy.github.io/TgWitness/es/docs/reference/connection/index.md): Autenticación, grupos de proxies automáticos, modos de IP, política de respaldo, solicitudes externas y almacenamiento de claves secretas. - [Implementación](https://phishdestroy.github.io/TgWitness/es/docs/reference/deployment/index.md): Ejecute TgWitness como servicio en Windows, Linux, macOS o Docker, a través de HTTPS, con copias de seguridad y actualizaciones. - [Cómo funciona la recopilación](https://phishdestroy.github.io/TgWitness/es/docs/reference/collection/index.md): Ámbito de observación, actualizaciones en tiempo real, verificaciones cruzadas, archivos adjuntos, acciones propias y qué significa una laguna, registro por registro. - [Flujos de trabajo y operaciones](https://phishdestroy.github.io/TgWitness/es/docs/reference/operations/index.md): Funcionamiento diario del panel: modos, categorías de supervisión, parámetros, notificaciones, exportaciones, copias de seguridad y capacidad. - [Modo de investigación](https://phishdestroy.github.io/TgWitness/es/docs/reference/investigation/index.md): Investigaciones de cuentas completas en canales, grupos, chats privados y bots, desde la definición del alcance hasta la elaboración de un expediente de caso verificado. - [Referencia de Case Board](https://phishdestroy.github.io/TgWitness/es/docs/reference/case-board/index.md): Marcadores, resaltados exactos, fragmentos de acción, debates, acceso restringido y el historial de anotaciones firmadas que utiliza Case Board. - [Configuración y verificación de informes](https://phishdestroy.github.io/TgWitness/es/docs/reference/case-reports/index.md): Filtros de informes, ocho diseños, plantillas de contenido, historiales de cambios guardados y la evaluación incluida en las exportaciones firmadas. - [Características y limitaciones](https://phishdestroy.github.io/TgWitness/es/docs/reference/features/index.md): El modelo de recopilación actual, los flujos de trabajo con varias cuentas, las exportaciones y los límites operativos de TgWitness. - [Cómo funciona el registro de pruebas](https://phishdestroy.github.io/TgWitness/es/docs/reference/how-it-works/index.md): Se explican la cadena de hash, las firmas, los puntos de control y los testigos con las fórmulas exactas que utiliza el verificador. - [Formato de las pruebas](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/index.md): Contenido del archivo ZIP firmado, tipos de registros, acuses de recibo, perfiles de usuarios, copias externas y verificación sin conexión. - [Testigo independiente](https://phishdestroy.github.io/TgWitness/es/docs/reference/witness/index.md): Ejecute un «witness» con su propia clave y bot, publique puntos de control firmados en un canal y compruebe las exportaciones comparándolas con ellos. - [Marcas de tiempo](https://phishdestroy.github.io/TgWitness/es/docs/reference/timestamp/index.md): Marcas de tiempo RFC 3161 para puntos de control firmados: qué se envía a la autoridad y cómo se verifica la respuesta. - [Seguridad y tratamiento de datos](https://phishdestroy.github.io/TgWitness/es/docs/reference/security/index.md): Modelo de amenazas, modelo de acceso, información confidencial en reposo, exposición de la red, importación de sesiones y cómo notificar una vulnerabilidad. - [Arquitectura](https://phishdestroy.github.io/TgWitness/es/docs/reference/architecture/index.md): Componentes del colector, el panel, el registro, los trabajadores y el testigo, y cómo se transfieren los datos entre ellos. - [Lo que se ha probado](https://phishdestroy.github.io/TgWitness/es/docs/reference/verification/index.md): La prueba en tiempo real de Telegram, las comprobaciones automatizadas, las comprobaciones en el navegador y lo que aún no se ha verificado. - [Registro de cambios](https://phishdestroy.github.io/TgWitness/es/docs/reference/changelog/index.md): Todos los cambios por versión, incluidos los que aún no se han publicado. - [Guía de paneles](https://phishdestroy.github.io/TgWitness/es/docs/reference/panel/index.md): Todas las pantallas del panel: chats, diario, fuentes, exportaciones, Extras, modos de protección y la comprobación de código. - [Primera configuración y ajustes](https://phishdestroy.github.io/TgWitness/es/docs/reference/settings/index.md): El asistente de configuración, los objetivos, los niveles de interfaz, las rutas de conexión y los ajustes compartidos por un grupo de cuentas. - [Instalación, verificación y actualización](https://phishdestroy.github.io/TgWitness/es/docs/reference/installation/index.md): Instálala con un solo comando, comprueba las firmas y los hash, actualízala y desinstálala. - [Almacenamiento y recuperación](https://phishdestroy.github.io/TgWitness/es/docs/reference/storage/index.md): Copias de seguridad, traslado de archivos antiguos a tu nube, copias bajo Object Lock y recuperación en un nuevo equipo. - [Exportación de cuentas](https://phishdestroy.github.io/TgWitness/es/docs/reference/account-export/index.md): Exporta lo que una cuenta puede leer en este momento: ámbito, tareas reanudables, un archivo firmado y copias compartidas minimizadas. - [Mostrador público](https://phishdestroy.github.io/TgWitness/es/docs/reference/showcase/index.md): Publica mensajes guardados de canales públicos seleccionados e instantáneas firmadas a través de enlaces caducables y revocables. - [Implementación de alta seguridad](https://phishdestroy.github.io/TgWitness/es/docs/reference/high-assurance/index.md): Un servidor sellado disponible las 24 horas del día, los 7 días de la semana, en Hetzner o Phala Cloud, un DNS de puerta de enlace y comprobaciones que un tercero puede repetir. --- # Telegram · Empiece en cuestión de minutos Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/start/ Instala con un comando, conecta una cuenta de Telegram y exporta un archivo verificable en Windows, Linux o macOS. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Instálala con un solo comando, conecta una cuenta de Telegram y elige qué quieres guardar. ## Instálalo en tu ordenador El instalador incluye Python y sus dependencias. Empieza con una exportación de chat; añade herramientas de observación e investigación cuando las necesites. ### Linux / macOS ``` curl -fsSL https://get.destroy.tools/install.sh | bash ``` ### Windows · PowerShell / CMD ``` powershell.exe -NoProfile -ExecutionPolicy Bypass -Command "irm https://get.destroy.tools/install.ps1 | iex" ``` Servidor Ubuntu: ejecútalo como root. Ordenador de sobremesa: ejecútalo como usuario normal. Abre la dirección del panel que muestra el instalador y utiliza su clave de acceso. A continuación, conecta tu cuenta de Telegram. La clave del panel y tu autorización de Telegram son independientes. [Instalación, firmas y actualizaciones:](https://phishdestroy.github.io/TgWitness/docs/reference/installation/) explica la versión descargada, el acceso local y las opciones de servidor. [Instrucciones sobre el código fuente y Docker:](https://phishdestroy.github.io/TgWitness/docs/reference/quickstart/) sigue disponible. ## Elige tu primera tarea 1. [Conecta una cuenta](https://phishdestroy.github.io/TgWitness/es/docs/accounts/) mediante teléfono, código QR o una importación de sesión compatible. 2. Elige el ámbito de los chats, la carpeta o la cuenta. 3. [Exportar el historial seleccionado](https://phishdestroy.github.io/TgWitness/docs/reference/account-export/) o iniciar la observación para conservar los cambios futuros. 4. [Verificar el archivo](https://phishdestroy.github.io/TgWitness/es/docs/exports/) con una huella digital de clave de confianza independiente. ## Utilizar un runner temporal de GitHub [Las acciones de GitHub](https://phishdestroy.github.io/TgWitness/docs/capture/) te guían a través del proceso de bifurcación, autorización, ámbito de aplicación y contraseña de archivo. Descarga el resultado cifrado y la procedencia del flujo de trabajo tras la ejecución. No se necesita ningún servidor recopilador permanente para este flujo de trabajo. ## Eche un vistazo sin necesidad de crear una cuenta [Abre la demostración del navegador](https://phishdestroy.github.io/TgWitness/demo/?lang=es) para explorar mensajes ficticios, comparar modificaciones e inspeccionar una exportación antes de instalar nada. ![Vista de conversación de TgWitness con mensajes de ejemplo](https://phishdestroy.github.io/TgWitness/assets/chats-dark.png) Un espacio de trabajo de ejemplo. Su propio registro se inicia por separado. ## Continuar con la investigación Para el trabajo en curso, añade las fuentes, las políticas de archivos, la búsqueda, los informes y los permisos de uso compartido que necesite tu caso. [Inicio, escala y pruebas.](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) explica las opciones y las mediciones publicadas. Para la instalación en un servidor, siga las instrucciones de [«Keep it running](https://phishdestroy.github.io/TgWitness/es/docs/server/)». --- # Utilice una cuenta independiente. Nunca utilice su cuenta principal. Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/dedicated-account/ Prepare una cuenta de Telegram independiente para la recopilación de datos. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Lea esto antes de vincular una cuenta Nuestro consejo de que no utilice su cuenta principal no es una broma. Es una realidad. Cuenta principal - Con su propio «app hash», el 99 % de las cuentas se desconectan - Son frecuentes las suspensiones de cuentas simplemente por un nivel bajo de confianza - Utilizar su cuenta principal es una idea verdaderamente estúpida Una cuenta adicional con pares de ID de API pública/hash de API - Se han registrado más de un millón de cuentas a través de estos pares de ID de API/hash de API - Estos pares de ID de API/hash de API llevan más de cinco años en funcionamiento - Nadie puede ver ninguno de sus datos a través de estos pares de API 01 ## Por qué no debe utilizar su cuenta principal Se trata de información precisa. Sabemos exactamente dónde residen las dificultades de estos problemas. 1. ### Con su propio «app hash», el 99 % de las cuentas se desconectan Si inicia sesión en my.telegram.org desde una cuenta a la que no tiene acceso para obtener un hash de la aplicación, y a continuación realiza cualquier solicitud a través de dicho hash, existe un 99 % de probabilidades de que la cuenta quede desconectada. Puede comprobarlo. 2. ### Son frecuentes las suspensiones de cuentas simplemente por un nivel bajo de confianza Las cuentas son bloqueadas simplemente porque Telegram no confía en ellas, y dichos bloqueos son frecuentes. También puede comprobarlo usted mismo. Utilizar su propia cuenta es una idea realmente estúpida. 3. ### Las claves de sesión copiadas pueden revocarse El uso simultáneo de una clave TData/de sesión importada en Telegram Desktop y TgWitness puede provocar el error `AUTH_KEY_DUPLICATED`. Telegram invalida dicha autorización, por lo que ambas copias necesitan un nuevo inicio de sesión. Disponer de una cuenta dedicada no evita que esto ocurra. Cierre completamente el cliente original y manténgalo cerrado mientras utiliza su sesión importada. Para un uso paralelo, inicie sesión en TgWitness mediante teléfono o código QR para crear una autorización independiente; los demás clientes con autorización independiente pueden permanecer conectados. [Lea la advertencia sobre la importación de sesiones](https://phishdestroy.github.io/TgWitness/demo/guide.html?lang=es#session-warning) Documentación de Telegram - [Errores al cerrar sesión: AUTH_KEY_UNREGISTERED, SESSION_REVOKED](https://core.telegram.org/api/errors) - [Creación de su propio hash de aplicación: obtención del api_id](https://core.telegram.org/api/obtaining_api_id) 02 ## Por qué TgWitness funciona mediante pares públicos de hash de aplicación e ID de aplicación Por ello hemos desarrollado TgWitness basándonos en pares públicos de hash de aplicación e ID de aplicación. Según nuestra lógica, con ellos es menos probable que se produzcan bloqueos: se han registrado más de un millón de cuentas de Telegram a través de estos pares, y muchos programas diferentes funcionan mediante ellos. Según nuestra lógica, esto es mejor que trabajar directamente con un hash de aplicación personal: estos pares llevan en funcionamiento más de cinco años con toda seguridad. ### Su propio par nuevo de ID de API/hash de API Creado en my.telegram.org desde la cuenta. - Alrededor del 99 % de estas cuentas se desconectan - Una nueva aplicación, una cuenta ### Pares de ID de API pública/hash de API del conjunto Se trata de los mismos pares de ID de API/hash de API que utilizan muchos programas. - Más de un millón de cuentas registradas - Numerosos programas diferentes - Estos pares de API llevan más de cinco años en funcionamiento. ### Por qué nadie puede ver ninguno de sus datos a través de estos pares de API - #### El par de la API es un nombre, no una clave Telegram solicita el ID de la API y el hash de la API cuando un programa se conecta y cuando solicita un código de inicio de sesión. Estos identifican la aplicación y no otorgan acceso a ninguna cuenta; la documentación de Telethon señala que un par de estos datos funciona con cualquier número de teléfono. - #### Su clave de sesión nunca sale de su servidor Al iniciar sesión se crea una clave de autorización mediante un intercambio Diffie-Hellman entre su TgWitness y Telegram; la clave en sí nunca se envía. Según la documentación de Telegram: tras la autorización, la clave queda asociada al usuario, y cada llamada realizada con esta clave se ejecuta en nombre de dicho usuario. Otros programas con el mismo par de claves disponen de sus propias claves y no pueden utilizar la suya. - #### El tráfico se cifra con su clave Cada solicitud y respuesta se cifra con la clave de autorización de la sesión, no con el hash de la API. Conocer el hash de la API no permite descifrar nada. - #### El propietario de un par de ID de API/hash de API no ve nada Telegram no dispone de ningún método que permita listar cuentas, sesiones o mensajes por ID de API. El propietario de un par solo puede ver la configuración de su aplicación en my.telegram.org. - #### Solo su cuenta puede ver de qué aplicación se trata En «Configuración» → «Dispositivos» de su propia cuenta se muestra una lista con el nombre de la aplicación y el ID de API de cada sesión, así como el dispositivo, la dirección IP y las fechas. Nadie más tiene acceso a esta lista. Documentación de Telegram - [Autorización del usuario: la clave queda vinculada al usuario](https://core.telegram.org/api/auth) - [auth.sendCode: api_id, api_hash](https://core.telegram.org/method/auth.sendCode) - [initConnection](https://core.telegram.org/method/initConnection) - [Creación de la clave de autorización MTProto](https://core.telegram.org/mtproto/auth_key) - [Cifrado MTProto](https://core.telegram.org/mtproto/description) - [account.getAuthorizations](https://core.telegram.org/method/account.getAuthorizations) - [Qué contiene una entrada de autorización (sesión) de Telegram](https://core.telegram.org/constructor/authorization) - [Obtención del api_id](https://core.telegram.org/api/obtaining_api_id) - [Código fuente de las aplicaciones de Telegram](https://telegram.org/apps#source-code) Bibliotecas y hilos de debate - [Telethon: iniciar sesión en Telegram](https://docs.telethon.dev/en/stable/basic/signing-in.html) - [opentele: credenciales de API de las aplicaciones oficiales](https://opentele.readthedocs.io/en/latest/documentation/authorization/api/) - [opentele: TelegramClient](https://opentele.readthedocs.io/en/latest/documentation/telethon/telegramclient/) - [Stack Overflow: ¿debería mantenerse en secreto el «api_hash»?](https://stackoverflow.com/questions/49490818/should-telegram-api-hash-be-kept-secret) ### Los mismos pares de ID de API/hash de API en otros programas 7 Los pares de ID de API/hash de API de las aplicaciones oficiales de Telegram son públicos y están integrados en numerosos programas y bibliotecas independientes: - [opentelePython · src/api.py](https://github.com/anmv/opentele/blob/4df17bd8c443d6452afc5a2d29ec7922fad1a5c3/src/api.py#L575) - Desktop 2040 - Android 6 - Telegram X 21724 - iOS 10840 - macOS 2834 - Web 2496 - [opentele2Rust · opentele2-core/src/api.rs](https://github.com/DedInc/opentele2/blob/7e973bc71cd7a714ad13ac703c0895a90d36a735/crates/opentele2-core/src/api.rs#L641) - Desktop 2040 - Android 6 - Telegram X 21724 - iOS 10840 - macOS 2834 - Web 2496 - [GrampoPython · Grampo/ut/api.py](https://github.com/abbas-bachari/Grampo/blob/00aa662d853c4ac2180432371c5e0d9444bbfe9e/Grampo/ut/api.py#L526) - Desktop 2040 - Android 6 - Telegram X 21724 - iOS 10840 - macOS 2834 - Web 2496 - [tgmanagePython · api/schemas/api_app.py](https://github.com/xdsnich/tgmanage/blob/f67c46be0ab234bd04526a8663d3936bd98a8597/api/schemas/api_app.py#L47) - Android 6 - iOS 8 - Desktop 2040 - macOS 2834 - Telegram X 21724 - Web K 2496 - [LyChatBotTDLib · helpers/tdlib/index.js](https://github.com/LyoSU/LyChatBot/blob/fac0ae5d5f2cddb8a26312014f51c0f6f40ec191/helpers/tdlib/index.js#L11) - macOS 2834 - [hsadasdPython · config.py](https://github.com/herobrinovaleksandr-png/hsadasd/blob/6842c74895038c16e219324fcd07dbe8153f37f0/config.py#L68) - Desktop 2040 - Desktop 17349 - Telegram X 21724 - macOS 2834 - iOS 10840 - Web 2496 - +4 - [blb.teamblb.team/threads/…294](https://blb.team/threads/app-hash-app-id-ofitsial-nykh-kliyentov.294/) - Android 4 · 5 · 6 - iOS 8 - Desktop 2040 - Desktop 17349 - macOS 2834 - Telegram X 21724 Una publicación en el foro en la que se enumeran los pares de ID de API y hash de API de las aplicaciones oficiales de Telegram, publicada con el fin de registrar cuentas 03 ## Formas de crear una cuenta adicional Una cuenta de Telegram requiere un número de teléfono en el que se reciba el código de inicio de sesión. Elija en función del tiempo que deba permanecer activa la cuenta. - La mejor opción ### SIM de prepago o eSIM ******** Cuánto tiempo dura Siempre y cuando mantenga su saldo al día Tenga en cuenta Lo más fiable: Telegram acepta mejor los números de móvil reales. Un número que la operadora retira se asigna a otra persona. - ### Una aplicación con números de teléfono virtuales ******** Cuánto tiempo dura Siempre que la aplicación conserve el número de teléfono Tenga en cuenta Telegram puede rechazar un número virtual, no enviar el código o limitar la nueva cuenta de inmediato; algunas aplicaciones recuperan los números que no se utilizan. - ### Alquiler de números de teléfono ******** Cuánto tiempo dura En cuanto al periodo de alquiler Tenga en cuenta Cuando finaliza, el número pasa al siguiente cliente. - ### Activación única ******** Cuánto tiempo dura Solo un código de inicio de sesión Tenga en cuenta El número vuelve al fondo común de inmediato, a menudo con un historial de propietarios anteriores. Configure la contraseña de la nube antes de nada. Quien obtenga el número de teléfono posteriormente podrá solicitar un código de inicio de sesión. Una contraseña en la nube (verificación en dos pasos) impide que esa persona inicie sesión; sin ella, la cuenta pasa a pertenecer al siguiente propietario del número. Documentación de Telegram - [Preguntas frecuentes sobre el spam: números virtuales y propietarios anteriores](https://telegram.org/faq_spam) - [Verificación en dos pasos](https://core.telegram.org/api/srp) ### Números +888 alquilados (Fragment) Algunos mercados y servicios ofrecen el alquiler temporal de los números oficiales +888 de Telegram a través de Fragment. Precio aproximado: 20 dólares estadounidenses al día. - Puede registrar una cuenta directamente en Telegram Web o en Telegram Desktop. - Puede eliminar cuentas del número y crear otras nuevas. - Estas cuentas suelen estar sujetas a menos controles antifraude, pero no otorgan inmunidad ni privilegios especiales. El número no es suyo. Una vez finalizado el alquiler, el propietario podrá reclamarlo. Establezca una contraseña de la nube de inmediato y no considere la cuenta como algo a largo plazo. Seguir siendo el titular del número +888 o utilizar una tarjeta SIM de prepago que usted controle sigue siendo más fiable. ### Cuentas ya creadas procedentes de mercados online Algunas plataformas de venta (por ejemplo, G2G o Z2U) comercializan cuentas de Telegram ya creadas: nuevas, con antigüedad o con archivos de sesión. - [G2G: listados de cuentas de Telegram](https://www.g2g.com/uk/categories/telegram-accounts) - [Z2U: Listados de cuentas de Telegram](https://www.z2u.com/telegram/accounts-5-15140) ¡NUNCA UTILICE SU CUENTA PRINCIPAL! Una cuenta específica obtenida de esta manera sigue siendo más segura que introducir su cuenta principal de Telegram en TgWitness. #### Advertencias antes de la compra - Esto incumple las Condiciones de servicio de Telegram. - Muchas cuentas se han registrado de forma masiva (registro automático) o tienen un historial desconocido. - Es posible que algunos vendedores sigan teniendo acceso de recuperación. - Las cuentas de dichos mercados suelen ser bloqueadas o restringidas posteriormente. - Evite los mercados en los que se vendan abiertamente programas de robo de credenciales, herramientas de phishing o cuentas claramente robadas. - La compra de una cuenta —incluso una anunciada como de «registro automático»— en plataformas que venden abiertamente herramientas de phishing, programas de robo de datos, sesiones robadas o cuentas infringes no solo las Condiciones de servicio de Telegram, sino también la legislación de la mayoría de los países. Esto puede invalidar posteriormente sus pruebas. Elija con cuidado. #### Si utiliza esta opción 1. Trate la cuenta como si fuera desechable. 2. Cierre todas las demás sesiones, establezca una contraseña en la nube y cambie los métodos de recuperación de inmediato. 3. Utilice entre 2 y 3 cuentas de diferentes proveedores o cuentas que haya registrado usted mismo. **Premium, la eliminación y el plazo de siete días** Si la cuenta dispone de Premium, una persona con acceso al número de teléfono no podrá eliminar la cuenta de forma inmediata. Recibirá una notificación y dispondrá de siete días antes de que se produzca la eliminación. Esto es importante porque su investigación depende de la cuenta: dispone de tiempo para preparar un sustituto. **Cuentas nuevas y credenciales de API** Si obtiene y utiliza su propio «api_id»/«api_hash» de una cuenta nueva que haya registrado usted mismo utilizando un número de un servicio de SMS, la cuenta se cerrará en la primera solicitud de API o autorización de sesión. Tenga esto en cuenta a la hora de planificar una investigación. 04 ## Creación de la cuenta Desde la obtención de un número de teléfono hasta el primer chat registrado. 1. ### Obtenga un número de teléfono Una tarjeta SIM de prepago o una eSIM cuando la cuenta deba tener una larga vigencia; un alquiler o una activación única para un trabajo de corta duración. A continuación se enumeran los servicios. 2. ### Regístrese con una cuenta independiente de su cuenta principal Regístrese en la aplicación oficial de Telegram en un dispositivo independiente, un emulador o un perfil de teléfono, no junto a su cuenta principal. 3. ### Proteja la cuenta con una contraseña en la nube Establezca de inmediato una contraseña para la nube y una dirección de correo electrónico de recuperación que no utilice en ningún otro sitio. 4. ### Restrinja la configuración de privacidad de la cuenta Número de teléfono: **«Nadie**», «Encuéntreme por mi número», **«Mis contactos**», «Última conexión», «Fotos de perfil» y «Biografía»: **«Nadie»** o **«Mis contactos»**; desactive la sincronización de contactos. 5. ### Evite que la cuenta se autodestruya Configure la autodestrucción de la cuenta en el plazo más largo posible, de modo que, si TgWitness deja de funcionar, no pierda la cuenta. 6. ### Configure un perfil neutro para la cuenta No se incluyen nombres, fotos, nombres de usuario ni biografías de sus otras cuentas, ni contactos personales. 7. ### Deje que la nueva cuenta se «caliente» Al principio, únase solo a unos pocos chats al día. Las cuentas nuevas que se precipitan son las primeras en sufrir restricciones. 8. ### No comparta nada con los bots No pulse nunca «Compartir número de teléfono» ni «Compartir ubicación» en un bot. Abra los enlaces y las miniaplicaciones a través de una VPN o un proxy en ese dispositivo. 9. ### Conecte la cuenta a TgWitness En su propio espacio de trabajo, conéctese a través de **Cuenta → Código QR** y, a continuación, pulse **Fuentes → Modo de investigación**. La aplicación es donde usted actúa; TgWitness es el registro. Documentación de Telegram - [Verificación en dos pasos](https://core.telegram.org/api/srp) - [Configuración de privacidad](https://core.telegram.org/api/privacy) - [Autodestrucción de la cuenta en caso de inactividad](https://core.telegram.org/method/account.setAccountTTL) 05 ## Servicios de números de teléfono Estas son las opciones con las que puede empezar. Los países, los precios y la aceptación de un número concreto por parte de Telegram cambian con frecuencia, por lo que le recomendamos que lo compruebe antes de realizar el pago. ### Tarjetas SIM de prepago y eSIM 11 - [SMARTYsmarty.co.uk](https://smarty.co.uk) - UK - SIM - [VOXIvoxi.co.uk](https://www.voxi.co.uk) - UK - SIM - [iD Mobileidmobile.co.uk](https://www.idmobile.co.uk) - UK - SIM - [Threethree.co.uk](https://www.three.co.uk) - UK - SIM - [Asda Mobilemobile.asda.com](https://mobile.asda.com) - UK - SIM - [Ultra Mobileultramobile.com](https://www.ultramobile.com) - US - Prepago Plan PayGo, muy económico - [US Mobileusmobile.com](https://www.usmobile.com) - US - Prepago - [Mint Mobilemintmobile.com](https://www.mintmobile.com) - US - Prepago - [Tracfonetracfone.com](https://www.tracfone.com) - US - Prepago - [eSIM Plusesimplus.me](https://esimplus.me) - eSIM - [Numero eSIMnumeroesim.com](https://numeroesim.com) - eSIM ### Aplicaciones con números de teléfono virtuales 20 - [Google Voicevoice.google.com](https://voice.google.com) - US Solo para EE. UU.; para registrarse es necesario disponer de un número de teléfono estadounidense. - [TextNowtextnow.com](https://www.textnow.com) - US - CA El número se recupera si no lo utiliza. - [TextFreetextfree.us](https://www.textfree.us) - US - [2ndLine2ndline.co](https://www.2ndline.co) - US - CA - [Talkatonetalkatone.com](https://www.talkatone.com) - US - [TextMego-text.me](https://go-text.me) - US - CA - Otros países - [textPlustextplus.com](https://textplus.com) [Google Play](https://play.google.com/store/apps/details?id=com.gogii.textplus) - [FreeToneGoogle Play](https://play.google.com/store/apps/details?id=com.textmeinc.freetone) - US [TextMe Up · textmeup.com](https://www.textmeup.com) - [Nextplusnextplus.me](https://nextplus.me) - US - [Dingtonedingtone.me](https://www.dingtone.me) - US - CA - [Burnerburnerapp.com](https://www.burnerapp.com) - US - CA - Servicio de pago Con un periodo de prueba - [Hushedhushed.com](https://hushed.com) - Muchos países - Servicio de pago Precio reducido - [Sidelinesideline.com](https://www.sideline.com) - US - [MySudomysudo.com](https://mysudo.com) - US - CA - UK - [2NumberGoogle Play](https://play.google.com/store/apps/details?id=com.bpmobile.second.phone) [App Store](https://apps.apple.com/app/id1216135390) - [SLYNUMBERslynumber.com](https://slynumber.com) [Google Play](https://play.google.com/store/apps/details?id=com.dev.slynumber) - [Phonerphonerapp.com](https://phonerapp.com) - [Onoffonoff.app](https://www.onoff.app) - EU Números de móvil europeos en una aplicación - [Sonetelsonetel.com](https://sonetel.com) - Muchos países - Un número gratuito - [Zadarmazadarma.com](https://zadarma.com) - Muchos países Números de teléfono virtuales ### Alquiler de números de teléfono y activaciones de un solo uso 12 Al alquilar un número de teléfono, este seguirá siendo suyo durante semanas o meses. Una activación de un solo uso proporciona un único código de inicio de sesión: establezca la contraseña de la nube inmediatamente después de registrarse. - [OnlineSimonlinesim.io](https://onlinesim.io) - Alquiler de números - Activaciones de un solo uso - [SMSPVAsmspva.com](https://smspva.com) - Alquiler de números - Activaciones de un solo uso - [5SIM5sim.net](https://5sim.net) - Alquiler de números - Activaciones de un solo uso - [SMSPoolsmspool.net](https://www.smspool.net) - Alquiler de números - Activación de un solo uso - [VAK-SMSvak-sms.com](https://vak-sms.com) - Alquiler de números - Activaciones de un solo uso - [TextVerifiedtextverified.com](https://www.textverified.com) - Alquiler de números - Activaciones de un solo uso - [JuicySMSjuicysms.com](https://juicysms.com) - Alquiler de números - Activaciones de un solo uso - [365SMS365sms.org](https://365sms.org) - Alquiler de números - Activaciones de un solo uso - [SIMSMSsimsms.org](https://simsms.org) - Alquiler de números - Activaciones de un solo uso - [GrizzlySMSgrizzlysms.com](https://grizzlysms.com) - Activación de un solo uso - [SMS-MANsms-man.com](https://sms-man.com) - Activación de un solo uso - [Tiger SMStiger-sms.com](https://tiger-sms.com) - Activación de un solo uso --- # Telegram · Conecte una cuenta Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/accounts/ Conecte su cuenta de Telegram mediante un código QR, un número de teléfono o la importación de una sesión. Seleccione las fuentes y compruebe que los nuevos mensajes se registran en su registro. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Un espacio = una cuenta, su diario y su clave. ## Elija cómo iniciar sesión **Cuentas** → añadir espacio → ajustes de conexión. Use una cuenta aparte para esto. - **Código QR:** escanéelo desde la pantalla Dispositivos de Telegram y confirme. - **Número de teléfono:** número, código y, si la tiene, la contraseña 2FA. - **Importar sesión:** su propio archivo de sesión o datos de Telegram Desktop. Use un perfil de API integrado o su propio API ID y hash. Solo identifica la aplicación: no inicia sesión ni oculta nada. **¿Necesita primero un proxy?** Puede [elegir y probar la ruta de conexión](https://phishdestroy.github.io/TgWitness/es/docs/proxies/) antes de iniciar sesión. Cada cuenta tiene su propia ruta. ## Elija qué desea supervisar 1. Elija los chats, grupos o canales que necesita. 2. Revise los ajustes de recogida, multimedia incluida. 3. Arránquelo y compruebe la conexión y la actividad reciente. La cuenta tiene que tener acceso. Administradores y miembros ven cosas distintas; el diario muestra lo que recibió esta cuenta. ¿La cuenta entera? **Fuentes → Alcance de observación → Modo investigación**, revíselo y pulse **Guardar alcance**. Guía completa: [investigar una cuenta entera](https://phishdestroy.github.io/TgWitness/es/docs/cases/). ## Compruebe la ruta completa En su grupo de prueba, envíe un mensaje desde otra cuenta, edítelo y bórrelo. Los tres eventos deben aparecer en el diario. Después, [exporte y verifique](https://phishdestroy.github.io/TgWitness/es/docs/exports/). «Conectado» significa que la conexión funciona. Un mensaje de prueba capturado significa que los eventos llegan de verdad. ## Añada otra cuenta Nuevo espacio en **Cuentas**, mismos pasos. Apunte la huella de la clave de cada cuenta para distinguir luego las exportaciones. --- # Telegram · Elija un proxy Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/proxies/ Mantenga las rutas automáticas de MTProxy o utilice su propio proxy. Elija los modos de IP, las reglas de reserva y la ruta para las solicitudes externas. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Mantenga la cuenta conectada y decida usted si alguna vez puede mostrar la IP de su servidor. ## Seleccione primero el modo IP 01**Ocultar la dirección** Solo proxy. Si ninguno funciona, espera. 02**Directo como último recurso** Va directo tras un retraso y vuelve a un proxy en cuanto uno funcione. 03**Servidor detrás de un túnel o una VPN** Directo está bien. No configura ni comprueba la VPN por usted. La ruta determina la conexión. El modo IP determina si se permite una conexión directa. ## Deje que el grupo se encargue de la ruta 1. **Cuenta → Ajustes → Ajustes de conexión**. 2. Elija el modo de IP y **MTProxy automático**, o una ruta fija. 3. Guarde y pulse **Probar conexión con Telegram** (funciona también antes de iniciar sesión). 4. Empiece a recoger y envíese un mensaje de prueba. Los espacios nuevos arrancan con MTProxy automático y **Ocultar la dirección**. El pool usa cuatro listas públicas, prueba servidores, se queda con los buenos y sustituye los caídos. ## Utilice su propio proxy SOCKS5, HTTP CONNECT, un enlace de proxy de Telegram o un catálogo del operador. Pause la observación antes de cambiar. Los secretos Fake TLS (`ee`…) no funcionan. **Configuración de rotación, uso compartido y reintentos** **Parámetros → MTProxy automático**: umbrales de fallo, esperas, rotación y cuentas por proxy. Límite 1 significa que la cuenta espera en lugar de compartir. Proxies distintos pueden compartir la misma IP de salida. ## Separar Telegram de las solicitudes externas MTProxy solo transporta Telegram. Marcas de tiempo, notificaciones, copias y comprobaciones de código van por un proxy SOCKS5/HTTP aparte, la ruta SOCKS5/HTTP de la cuenta o en directo si el modo lo permite. O desactívelas. `TGWITNESS_PROXY_FEED_PROXY` fija la ruta para descargar las listas. El [testigo](https://phishdestroy.github.io/TgWitness/es/docs/witness/) tiene sus propios ajustes. Nada de esto toca su navegador ni la red del sistema. Más: [modos y valores por defecto](https://phishdestroy.github.io/TgWitness/es/docs/reference/connection/#ip-modes), [quién puede cambiar rutas](https://phishdestroy.github.io/TgWitness/es/docs/access/). --- # Telegram · Exportar y verificar Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/exports/ Exporte el historial de Telegram capturado, verifique las firmas y compare el registro con un punto de control conservado por un testigo independiente. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Entregue archivos que el destinatario puede comprobar por su cuenta frente a su espacio. Conservar una referenciaExportar archivo ZIP firmadoEl destinatario verifica ¿Nuevo en firmas y puntos de control? [Cambie un registro de ejemplo](https://phishdestroy.github.io/TgWitness/es/docs/concepts/#chain) y vea qué comprobaciones lo detectan. ¿Desea conservar una copia al margen del recopilador? Acceda a [la configuración de S3](https://phishdestroy.github.io/TgWitness/es/docs/exports/#s3), [al bloqueo de objetos](https://phishdestroy.github.io/TgWitness/es/docs/exports/#s3-retention) o a [la recuperación verificada](https://phishdestroy.github.io/TgWitness/es/docs/exports/#s3-restore). ## Conserve una referencia fiable Apunte la huella de la clave del espacio en algún sitio que no sea el recolector. Mientras recoge, guarde también puntos de control firmados en otro lugar o use un [testigo independiente](https://phishdestroy.github.io/TgWitness/es/docs/witness/). Con eso comprueba el destinatario la clave y un estado anterior del diario. ## Descargue el archivo ZIP firmado **Exportaciones** → ZIP de evidencia firmado. Contiene el diario entero y un manifiesto de archivos firmado. Dé forma al informe legible en [Report studio](https://phishdestroy.github.io/TgWitness/es/docs/reports/) o envíe solo datos seleccionados como [extracto de entrega](https://phishdestroy.github.io/TgWitness/es/docs/handover/). Los informes HTML, PDF y JSON llevan sus propios sellos. El CSV es solo una copia de trabajo; para la integridad use el CSV del ZIP verificado. ## Verifíquelo con una copia fiable de TgWitness En el entorno del proyecto, con su propia huella y sus rutas: ``` python -m tgwitness.verify evidence.zip --fingerprint TRUSTED_PUBLIC_KEY_SHA256 --checkpoint retained-checkpoint.json ``` Si pasa, verá `key_pinned: true` y `checkpoint_checked: true`. Guarde esa salida junto al archivo. El punto de control tiene que estar en el final de la exportación o antes. ## Utilizar el resultado de la verificación - **Archivos:** el manifiesto fija sus hashes y las firmas fijan el diario. Cualquier cambio se nota. - **Identidad:** la huella que guardó demuestra que es la clave que esperaba. - **Estado anterior:** un punto de control compara la exportación con un prefijo del diario guardado antes de la entrega. - **Cobertura:** huecos, resultados de adquisición y una prueba enviar → editar → borrar muestran lo que esta configuración captó de verdad. Detalles: [qué demuestra la verificación y qué no](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#verification-scope). ## Configure la copia externa en S3 **Exportaciones → Copia externa** en su espacio. Funciona con AWS S3 y cualquier servicio compatible con S3. Copia segmentos del diario, archivos guardados, puntos de control con sus marcas de tiempo y exportaciones de chats terminadas, cada uno cifrado con `AES-256-GCM` antes de salir del recolector. La demo en línea muestra estos controles con las subidas desactivadas. Introduzca credenciales reales solo en su propia instalación. [![Panel completo de copias externas: punto final, región, depósito, claves de acceso, programación, controles de Object Lock y clave de recuperación](https://phishdestroy.github.io/TgWitness/assets/off-site-copy.png)](https://phishdestroy.github.io/TgWitness/assets/off-site-copy.png) El panel completo con las opciones avanzadas desplegadas. No se muestran credenciales de almacenamiento. | Campo | Qué debe introducir | | --- | --- | | Punto final | URL del almacenamiento, sin ruta de bucket ni credenciales. Ejemplo: `https://s3.example.invalid`. | | Región | Lo que pida su proveedor. Por defecto `us-east-1`. | | Depósito | Un bucket existente en el que pueda escribir. Ejemplo: `example-case-backup`. | | Carpeta en el repositorio | Prefijo, por defecto `tgwitness`. Se añade encima un prefijo por espacio. | | ID de clave de acceso / Clave de acceso secreta | Las dos juntas, guardadas en la bóveda. Déjelas vacías más adelante para conservarlas. | | Direcciones en formato de ruta | Activado: `endpoint/bucket`. Desactivado: `bucket.endpoint`. Depende del proveedor. | | Intervalo de copia | De 1 a 1440 minutos, por defecto 5. Solo mientras la aplicación está en marcha. | | Retención de Object Lock | Días y modo, si el bucket admite Object Lock. Cero mantiene el valor por defecto del bucket. | 1. Cree el bucket, rellene destino y credenciales con **Mantener una copia externa** sin marcar y pulse **Guardar copia externa**. 2. **Probar conexión** sube un objeto de prueba cifrado. 3. **Descargar clave de cifrado** y guárdela lejos del recolector. Sin clave no hay recuperación. 4. Marque **Mantener una copia externa**, guarde y luego **Copiar ahora** o deje que funcione la programación. ## Comprobar el estado de la retención y el progreso de la copia En **Más opciones** elija los días de retención y `GOVERNANCE` o `COMPLIANCE`. TgWitness lee la retención de un objeto subido y le indica: confirmada, ausente o fallo de comprobación. El panel muestra la última pasada, número de objetos, bytes, límite del diario copiado y errores. Un archivo local que falta se notifica y se reintenta en la siguiente pasada; el resto sigue copiándose. Las subidas van en directo, por SOCKS5 o por HTTP. Con una ruta solo MTProxy, la copia espera con un error. ## Conserve la clave de recuperación por separado El JSON de la clave contiene la clave de descifrado, el destino, el prefijo y la huella de la clave. Para recuperar necesita eso más credenciales de almacenamiento con permiso de lectura. ¿Cambió endpoint, bucket o prefijo? Vuelva a descargar la clave. Empieza una copia nueva en el nuevo destino; las exportaciones antiguas se quedan donde estaban. ## Restaurar y verificar en otro equipo Necesita una instalación de TgWitness de confianza, el JSON de la clave, credenciales de solo lectura y una carpeta vacía: ### Windows PowerShell ``` $env:TGWITNESS_S3_ACCESS_KEY = 'YOUR_READ_ACCESS_KEY' $env:TGWITNESS_S3_SECRET_KEY = 'YOUR_READ_SECRET_KEY' python -m tgwitness.replica restore --key-file tgwitness-replica-key.json --out restored-evidence ``` ### Linux / macOS ``` export TGWITNESS_S3_ACCESS_KEY='YOUR_READ_ACCESS_KEY' export TGWITNESS_S3_SECRET_KEY='YOUR_READ_SECRET_KEY' python -m tgwitness.replica restore --key-file tgwitness-replica-key.json --out restored-evidence ``` Primero todo se comprueba en una carpeta temporal privada: el diario entero, los puntos de control, los hashes y tamaños de los archivos. Rutas inseguras, segmentos en conflicto o un diario más corto que su punto de control fallan, y entonces no se escribe nada. Si sale bien, obtiene `events.jsonl`, `media/`, `checkpoints/` y `exports/`. Guarde con ellos la salida JSON del comando y compárelos con los puntos de control o registros del testigo que guarde usted. --- # Telegram · Captura de GitHub Actions Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/capture/ Elige Takeout, exportación mediante la API normal o un diario de chat en un ejecutor temporal de GitHub. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Elige Takeout，exportación mediante la API normal o un diario de chat en un ejecutor temporal de GitHub． Active JavaScript para generar una clave y descifrar su archivo. **Referencia completa** [TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [Documentation](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) · [Independent capture](https://github.com/phishdestroy/TgWitness/blob/main/docs/OPTIONAL-CAPTURE.md) ![Independent capture](https://phishdestroy.github.io/TgWitness/assets/chapter-capture.svg) **Preview available from `main`.** A fork launches a pinned reusable workflow from `phishdestroy/TgWitness`. The workflow exports an account, selected chats or one chat's event journal using a newly created Telegram session, attests the evidence ZIP or multipart manifest, and uploads only recipient-encrypted handoffs. The normal administration panel is not exposed. Choose `client=official_web` to run the [official-client witness](https://github.com/phishdestroy/TgWitness/blob/main/docs/OFFICIAL-WITNESS.md) with guarded Telegram Web controls and video. It requires your own upstream proxy and observes one rendered chat. The default `client=api` retains the full-account export modes described below. The verifier checks the archive against its GitHub attestation, the approved workflow and collector commits, and the signed journal and attachment hashes. The collection process uses pinned upstream code and fresh storage. A reviewer can inspect that code and verify the delivered archive against its recorded run. **On this page** - [User flow](https://phishdestroy.github.io/TgWitness/es/docs/capture/#user-flow) - [Session time budget](https://phishdestroy.github.io/TgWitness/es/docs/capture/#session-time-budget) - [Choose this mode or a persistent workspace](https://phishdestroy.github.io/TgWitness/es/docs/capture/#choose-this-mode-or-a-persistent-workspace) - [What is public, and what must stay private](https://phishdestroy.github.io/TgWitness/es/docs/capture/#what-is-public-and-what-must-stay-private) - [Troubleshooting](https://phishdestroy.github.io/TgWitness/es/docs/capture/#troubleshooting) - [Local decryption and verification](https://phishdestroy.github.io/TgWitness/es/docs/capture/#local-decryption-and-verification) - [How the fork is kept outside the capture process](https://phishdestroy.github.io/TgWitness/es/docs/capture/#how-the-fork-is-kept-outside-the-capture-process) - [Cryptographic handoff](https://phishdestroy.github.io/TgWitness/es/docs/capture/#cryptographic-handoff) - [Limits and validation](https://phishdestroy.github.io/TgWitness/es/docs/capture/#limits-and-validation) - [Maintainer release sequence](https://phishdestroy.github.io/TgWitness/es/docs/capture/#maintainer-release-sequence) ## User flow The helper explains the five stages and lets you try message or collector substitution on sample data. **Start my capture** opens the wizard. 1. Choose **GitHub Actions capture (preview)** on the project homepage, the workspace login screen, or **Exports → Open capture helper**. You can also open the [official helper](https://phishdestroy.github.io/TgWitness/sealed.html?lang=en) or `tgwitness/static/capture.html` from a trusted checkout in a modern browser. The helper makes no network requests for key or file processing. The helper supports the site's interface languages; the temporary collection panel supports English and Russian. 2. Generate a key and save **sealed-key.json**. This is the only private decryption key. Copy the separate public **recipient** value. Losing the private key loses access to both the connection and the archive. Confirm that you saved it to unlock the next step. If you already have a delivery file, load the saved key and choose **I already have an archive**. 3. Fork TgWitness, enable Actions in the fork, and run **Sealed chat capture**. Paste the public recipient and choose 30, 60, or 120 minutes. Never put a phone number, login code, Telegram password, private key, or session in workflow inputs, commits, issues, or logs. 4. During the run, download **sealed-connection** from Artifacts and unzip it. Load `connection.tgwsealed` in the helper, using the saved private key. The resulting link contains a random access secret in its URL fragment. Keep this link private. The panel removes the fragment and keeps the secret in this tab's session storage; it is not placed in HTTP access logs. 5. Open the connection link. Sign in with a QR code, or with your phone number and the login code. Enter your two-step verification password if Telegram asks for it. The built-in API credential pool is used by default, just like the normal workspace. You may expand the optional custom credentials section and enter both `api_id` and `api_hash` from [my.telegram.org/apps](https://my.telegram.org/apps). Leave both fields empty to use the built-in pool; a partial or malformed pair is rejected. Session imports are not allowed. Choose the export mode and scope. The connection link contains an access secret: keep it private. 6. Choose **Telegram Takeout**, **Regular Telegram API** or **Chat event journal**. For account export, choose all accessible chats or load and select one or more chats, then set dates, chat types, account categories and attachment rules. Check settings and size, optionally save the settings JSON for an independent reviewer, then press **Start capture**. Settings are fixed after starting. Resume works only while this runner exists; finishing early preserves acquired data and records gaps. Deadline expiry after starting produces an explicitly partial archive; expiry before starting or cancellation produces no archive. 7. Wait for **sealed-result**, download and unzip it, and decrypt `delivery.tgwsealed` in the helper. You receive `delivery.zip`, containing `evidence.zip`, `attestation.jsonl`, and instructions. Browser decryption is limited to 256 MiB; larger packages use the streaming local command below. Large results also include `delivery-NNNNNN.tgwsealed` parts; the main `delivery.tgwsealed` then contains `evidence.parts.json` and the attestation. Download every part and assemble locally as described below. 8. End the temporary session in Telegram Settings → Devices if revocation was not confirmed or the runner was killed. Normal completion attempts logout; network failures and forced runner termination prevent an absolute guarantee. The repository must contain the published pinned source and reusable-workflow commits. A local branch alone cannot be invoked by another GitHub repository. ## Session time budget Before collection, **Calculate time and size** estimates the selected history and files from message counts and a bounded sample. The display includes time already spent signing in, estimated collection time and a reserve for packaging. For files, the initial estimate uses 1 MiB/s and a twofold time margin; progress replaces that assumption with the measured rate. Use **Messages only** or select fewer chats when the estimate exceeds the remaining time. Telegram's reported Takeout wait is added to the budget. The collector stops acquisition when the remaining time is needed for packaging, retains acquired data and marks a partial result. A 120-minute session therefore uses its remaining collection window rather than waiting for the deadline before preparing the archive. The display identifies selections whose full size could not be sampled. ## Choose this mode or a persistent workspace | Capture mode | Configurable scope | Difference | | --- | --- | --- | | Telegram Takeout, the default | All accessible cloud chats or selected chats, dates, account categories, media policies and JSON/HTML views | Uses Telegram's official export mechanism; approval or waiting may be required. Takeout can enumerate left channels/groups where Telegram permits it and request additional personal data. | | Regular Telegram API | The same account scope and output choices, subject to methods available through the regular API | Does not initialize Takeout; cannot enumerate left channels/supergroups or fetch Takeout-only personal data. Contacts cover Telegram users rather than the complete saved phone contact list. Rate limits still apply. | | Chat event journal | One selected chat, attachment policies and optional avatars | Captures history and changes observed during this run. Account categories, date filters and Desktop-compatible views do not apply. | All three modes have the same GitHub attestation and encrypted delivery. Takeout is an acquisition method, not a stronger signature. It is never silently replaced by regular API access. JSON/HTML views are generated by TgWitness; they are not Telegram-signed files or guaranteed byte-identical Desktop exports. See the [official Takeout API](https://core.telegram.org/api/takeout). Defaults use Takeout, all accessible chat types including archived chats, all dates, account profile and contacts, compatible JSON and HTML, and file downloads. The initial media budget is 4 GiB, with visible per-type file limits; larger files or exhausted download budgets use server hashes where available. Review these limits before collecting. Hashes cannot reconstruct a file. Optional photos, stories, session metadata and extra personal data remain separate choices. Takeout may require approval in an established Telegram session. Telegram sets the delay; a new login or runner does not bypass it. The maximum capture window is 120 minutes including login and approval, so a large account or long approval wait may not finish. A persistent local export can resume the same session, but does not inherit GitHub attestation. ### Agree and verify the settings After **Check settings and size**, use **Save settings for verification**. Agree the resulting `sealed-export-settings.json` with the reviewer before collection. Changes invalidate the saved assessment. The collector signs the effective settings and their SHA-256, and account-export receipts bind the same options. The verifier reports the actual mode, selection and completeness, and rejects a disagreement between the journal and nested account export. ``` python -m tgwitness.sealed_verify evidence.zip --bundle attestation.jsonl --repo OWNER/TgWitness --expected-selection sealed-export-settings.json --require-complete ``` `--expected-selection` rejects a different transport, chat scope, filter or attachment policy. `--require-complete` rejects partial account exports and chat journals, whose overall completeness is not established. Without these flags, verification still checks provenance and integrity while reporting the recorded settings and gaps. A file supplied only with the finished archive cannot establish what was agreed beforehand. A valid signature never turns omitted data into data that was collected, or proves the owner did not edit/delete messages before capture. | Need | Mode | | --- | --- | | Export accessible account data or selected chats during a limited session and give a reviewer an externally attested archive | GitHub Actions capture (preview) | | Observe several chats continuously, manage accounts, search and read a growing archive | Local or Docker workspace | This starts a separate capture with a new login. It does not upload your existing local journal, export the currently open workspace, or reuse its Telegram session. An unfinished cloud capture cannot resume after its runner is destroyed; a new workflow starts a new capture. The workspace's **Exports → Open capture helper** opens the complete wizard inside the panel. The standalone page uses the same wizard, controls and themes. Both keep keys and decryption in your browser. GitHub workflow startup and the temporary Telegram panel open in separate tabs; the wizard tells you when to return. Locking the workspace clears the wizard's in-memory key. Your saved key file remains on your device. ## What is public, and what must stay private Collection runs on a standard GitHub-hosted runner. GitHub, the approved collector and dependencies, the helper page, the browser and the HTTPS tunnel are trusted parts of this setup. The temporary host processes the Telegram session and plaintext messages; the delivered artifacts are encrypted for the recipient. Forking copies project code into your repository. It does **not** export your Telegram account. The recipient workflow input is a public encryption key. Keep `sealed-key.json`, Telegram credentials, login codes, 2FA passwords and the decrypted connection URL out of commits, workflow inputs and public logs. The workflow publishes encrypted connection/result artifacts for one day. Download both in time; GitHub Actions availability, account limits and billing apply. A public fork is not a promise of unlimited free compute. No payment or GitHub access token is entered into the helper. The private decryption key stays in your browser/file. Telegram session material and plaintext observations necessarily exist inside the temporary collector. GitHub and the HTTPS tunnel remain trusted infrastructure. Attestation may make the archive digest and workflow identity public; the archive contents are not placed in the attestation. The attestation timestamp is not a message timestamp. ## Troubleshooting | Symptom | Next step | | --- | --- | | No **Run workflow** button | Open your own fork, enable Actions, and sync it with upstream `main`. Do not edit the approved upstream pins to bypass a failure. | | No `sealed-connection` artifact | Check whether the job started and completed its startup/upload step. Queue, runner, image download, tunnel or repository policy failures can prevent startup. | | Cannot open the connection | Load the saved key for this run, unzip the downloaded artifact and select `connection.tgwsealed`. The runner must still be active. | | History is paused | Check the panel's status and use Resume while the session remains active, or finish with the data already collected. Telegram limits and inaccessible content can leave gaps. | | No `sealed-result` | Cancellation or expiry before starting collection produces no archive. A failed collection, attestation or packaging step also prevents delivery. Inspect the failed step without posting credentials. | | Browser cannot decrypt a large archive | Use the streaming CLI below for packages larger than 256 MiB. A wrong or lost private key cannot decrypt the result. | | Verification rejects the signer | Use a trusted current TgWitness installation and the exact caller `OWNER/REPOSITORY`. Do not accept a replacement policy supplied with the archive. | | Telegram still lists the temporary session | End it in Settings → Devices. Logout can fail and a forcibly terminated workflow may not run cleanup. | Before relying on this preview, try a small chat you control: create a message and attachment, collect them, decrypt the result, run the verifier, check the coverage/media outcomes and confirm Telegram session revocation. Automated checks use a synthetic Telegram client plus a separate real GitHub certificate test; they do not establish live account acceptance. ## Local decryption and verification Use tools from an independently trusted installation, not executable files supplied by an unknown evidence archive: ``` python -m tgwitness.sealed_crypto decrypt delivery.tgwsealed --key sealed-key.json --out delivery.zip # Unzip delivery.zip using your archive manager, then: python -m tgwitness.sealed_verify evidence.zip --bundle attestation.jsonl --repo OWNER/TgWitness ``` For multipart delivery, decrypt the main package first and keep its extracted manifest beside every encrypted part, then run: ``` python -m tgwitness.sealed_parts evidence.parts.json --key sealed-key.json --out evidence.zip python -m tgwitness.sealed_verify evidence.parts.json --assembled evidence.zip --bundle attestation.jsonl --repo OWNER/TgWitness ``` The manifest is the attested subject and binds every part and the assembled ZIP. Use `--max-gib` to set an appropriate uncompressed verification ceiling for a large archive; the default is 4 GiB. Expected-selection and complete-scope checks also work with multipart delivery. Python 3.11+, the project's dependencies, and a recent GitHub CLI supporting `--signer-digest` and `--deny-self-hosted-runners` are required. A CLI key generator is also available: `python -m tgwitness.sealed_crypto keygen sealed-key.json`. The verifier uses `tgwitness/sealed_policy.json` from the trusted installation. It checks the caller repository, upstream signer workflow, approved signer commit, hosted runner requirement, complete ZIP digest, internal journal and attachment integrity, fresh account-key origin, and expected collector commit. It displays history and media outcomes instead of implying all data was saved. An empty approved-release list fails closed. Updating the policy is an explicit trust decision; never accept an archive's own proposed policy automatically. For offline use, obtain trusted roots ahead of time from a trusted environment: ``` gh attestation trusted-root > trusted_root.jsonl python -m tgwitness.sealed_verify evidence.zip --bundle attestation.jsonl --repo OWNER/TgWitness --trusted-root trusted_root.jsonl ``` The timestamp of the attestation concerns the archive's commitment. It does not authenticate message timestamps or the collector's wall clock. See [GitHub's verification options](https://cli.github.com/manual/gh_attestation_verify). ## How the fork is kept outside the capture process The caller contains a job-level reference to the upstream reusable workflow at a full commit SHA. That workflow explicitly checks out **the upstream repository at a fixed collector SHA**. A default `actions/checkout` in a reusable workflow would check out the caller and is intentionally not used. The workflow does not restore caller caches, consume caller artifacts, execute caller files, or accept source/image URLs, shell commands, prepared ZIP files, or hashes to sign. It accepts a bounded public recipient and session duration. Actions, the Python base image, and cloudflared are pinned by immutable digests; Python dependencies use the existing hash-locked requirements. The image is built from the trusted source without a cache. The collector runs as a non-root user with a read-only image, dropped Linux capabilities, resource limits, and no Docker socket or GitHub-token environment. Its only mounts are fresh configuration, workspace, and output directories. The restricted FastAPI application exposes login, dialogs, configurable account or chat collection, status, resume, finish, and cancellation. There is no plaintext download route, general administration route, import route, or signing endpoint. The supervisor stops the network-facing containers before the attest action reads the final fixed `evidence.zip` or `evidence.parts.json`. The packaging container has no network. The upload steps name only `connection.tgwsealed` and `delivery*.tgwsealed`; neither plaintext evidence nor Telegram credentials are uploaded as artifacts. Cleanup removes the private directories and containers, with no claim of physical disk erasure. Artifact retention is one day; download before expiry. A fork owner can replace the caller or create a different signed file. The strict verifier must reject the resulting **different signer workflow/digest**. This construction still depends on the absence of exploitable bugs in approved code and on the integrity of GitHub's runner and signing infrastructure. ## Cryptographic handoff Each recipient key is RSA-3072 (RSA-4096 imports also accepted), exponent 65537. Each envelope has a fresh random AES-256 key and 96-bit nonce. RSA-OAEP with SHA-256/MGF1-SHA256 wraps the AES key. AES-GCM with a 128-bit tag authenticates the complete prefix and payload. The public recipient is DER SPKI in base64; the private key file contains DER PKCS8 in base64. Envelope bytes are `TGWSEAL1\n`, a big-endian uint32 JSON-header length, the header, ciphertext, and a 16-byte GCM tag. The header has exactly `algorithm`, `key`, and `nonce`; algorithm is `RSA-OAEP-256+A256GCM`. The complete prefix through the header is GCM additional authenticated data. Header size is bounded at 8192 bytes. The CLI streams payloads up to 8 GiB and authenticates before installing the requested output; it refuses overwriting an existing destination. This is a project-specific envelope around standard cryptographic primitives, not an independently audited encryption format. The original evidence bytes are attested **before** placing the evidence and attestation in the encrypted outer package. This avoids a circular dependency between the archive's hash and a certificate included inside that same archive. For public repositories, attestation metadata (repository, workflow, commit, artifact name and digest) is public. Never put chat names in public metadata. ## Limits and validation This mode uses the signed journal and account-export engine. Secret Chats, deleted history from before collection and data inaccessible to the account are excluded. Private cloud chats are eligible when selected. The chat picker is capped at 20,000 dialogs; account export discovers its own inventory. Missing data, failed files and unfinished tasks are recorded. Attachment limits and runner disk/time limits still apply. Large delivery uses encrypted parts instead of a fixed 4 GiB delivery cutoff. Completion means the frozen selected tasks finished, not that every historical Telegram record exists in the archive. The chat journal can also observe live updates; neither mode is an atomic snapshot. Generated screenshots and screen recordings are not part of this mode. Tests cover synthetic fresh login, scope isolation, media, cancellation, partial deadline completion, failed logout, forbidden API paths and fields, preloaded workspace rejection, wrong-key and tamper rejection, required verifier flags, and browser/Python encryption interoperability. The browser acceptance test uses a plainly labelled mock attestation; it is not a real Sigstore test. Real hosted-runner, Docker, GitHub attestation, and live Telegram acceptance must be reported separately from local synthetic checks. [GitHub Actions terms](https://docs.github.com/en/site-policy/github-terms/github-terms-for-additional-products-and-features#actions) restrict use of hosted runners to the software project's lifecycle. A fork does not remove these restrictions; this preview must not be marketed as unrestricted free production hosting. [Cloudflare Quick Tunnels](https://developers.cloudflare.com/tunnel/get-started/quick-tunnels/) are also intended for testing and development. The helper/workflows are suitable for evaluating this feature; production service eligibility remains a separate deployment requirement. ## Maintainer release sequence 1. Commit and review the collector, supervisor, container definition and tests. 2. Pin that collector commit in `sealed-collector.yml`, then commit/review the reusable workflow. Never silently derive the checkout from the caller SHA. 3. Pin the reusable workflow commit in `sealed-witness.yml` and add its workflow/collector SHA pair to `sealed_policy.json` in a trusted release. 4. Publish all referenced commits and the helper, then test an independent fork and the real GitHub certificate. Do not squash away commits referenced by these pins unless the references are regenerated and published again. See [reusable workflows and attestations](https://docs.github.com/en/actions/how-tos/secure-your-work/use-artifact-attestations/increase-security-rating) for the distinction between the caller repository and the upstream signer. --- # Telegram · Investigue en todos los chats Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/cases/ Lleve a cabo una investigación exhaustiva de Telegram en canales, grupos, chats privados y bots: captura completa de la cuenta, historial, contactos, enlaces, archivos, cronologías y pruebas verificadas. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Un caso completo entre canales, grupos, chats privados y bots: recoger, unir las piezas, reconstruir la cronología y entregarlo. Un incidente inventado, de principio a fin. La recogida, la búsqueda y los perfiles de personas encuentran los registros, [Case Board](https://phishdestroy.github.io/TgWitness/es/docs/case-board/) los organiza y [Report studio](https://phishdestroy.github.io/TgWitness/es/docs/reports/) los presenta. CASO RESUELTO / UN DESTINO DE PAGO MODIFICADO ### Un incidente. Cuatro conversaciones. Un rastro que reconstruir. Una publicación de canal lleva a un bot. Un grupo habla de un nuevo enlace de pago y el bot lo muestra. La publicación se edita, un chat privado repite el enlace y un mensaje del grupo desaparece. ¿Quién publicó cada versión?¿Dónde apareció el enlace?¿Qué archivo se conservó?¿Qué ha cambiado y cuándo? Carga de historial, IA, MCP, OCR y webhooks: [Trabajar el archivo](https://phishdestroy.github.io/TgWitness/es/docs/archive/). ## 1. Establecer una cobertura que abarque toda la cuenta Alcance de cuenta entera solo en una cuenta dedicada. Una cuenta principal usa chats elegidos o una carpeta. 1. [Conecte la cuenta](https://phishdestroy.github.io/TgWitness/es/docs/accounts/) en su propio espacio. Apunte la referencia del caso, el ID de cuenta, el espacio y la huella de la clave. 2. **Fuentes → Alcance de observación → Modo investigación**: **Cuenta entera**, los cuatro tipos de fuente y **Acciones propias**. Cada chat nuevo guarda su perfil y sus últimos **200 mensajes visibles**. **Guardar alcance** y confirme. 3. **Cargar chats** y compare con la lista de chats de la cuenta. El límite es de 1000 diálogos (hasta 20 000 en **Parámetros → Chats leídos de la lista de la cuenta**); los que queden fuera aparecen cuando se activan. 4. **Ajustes de grabación** → **Toda la actividad visible**, revise límites de adjuntos y espacio en disco. Arranque y pruebe con un mensaje, una edición y un borrado. CanalesGruposChats privadosBots UNA CUENTA / UNA CLAVE DE FIRMA**Toda la actividad visible de las cuentas seleccionadas → un único registro** Mensajes · modificaciones · avisos de eliminación · reacciones visibles · eventos relacionados con la pertenencia al grupo · acciones propias «Cuenta entera» significa todos los chats que esta cuenta puede abrir, menos las exclusiones. Sin chats secretos. Los chats nuevos se suman al aparecer; el historial antiguo no se descarga solo. ## 2. Obtener el historial y conservar los archivos Cree una colección en Case Board y marque lo importante. Lleve un registro de fuentes: ID del chat, título, cuenta, rol, inicio de la captura en vivo, resultado del historial, resultado multimedia y huecos. | Se necesita | Acción en el panel | Qué ofrece | | --- | --- | --- | | Historial de los chats habilitados | Fuentes → Cargar historial completo | Los mensajes anteriores disponibles se incorporan al diario del espacio de trabajo, con funciones de pausa/reanudación y un informe de progreso firmado. [Guía del historial](https://phishdestroy.github.io/TgWitness/es/docs/reference/history/). | | Contexto del chat existente en el registro | Fuentes → Ajustes de grabación → Instantánea del historial | Mensajes recientes como registros firmados. 500 por defecto, hasta 10 000 en **Parámetros → Captura de historial más grande**. | | Historial completo, tal y como se muestra actualmente, de un chat | Exportación completa del chat → Exportar el chat completo, o Chats → Exportar chat | Un paquete firmado aparte con `chat.json` y `chat.html`, uno por chat. | | Contexto en el que aparece un nuevo chat | Ámbito de observación → Cuando aparece un nuevo chat o un nuevo bot | Su perfil y hasta 1000 mensajes recientes (200 en modo investigación). No se aplica a chats existentes. | | Tamaño del archivo adjunto | Descarga de archivos adjuntos visibles + límites por tipo | Busque `media.saved` con SHA-256 y tamaño. En cola, omitido o fallido significa que no se guardó. | Una exportación de chat no entra en el diario ni en los perfiles de personas. Para buscar historial antiguo dentro de TgWitness, use **Cargar historial completo** o capturas. Aquí: el canal, el grupo, el chat del bot y el chat privado, más el archivo de la factura y su hash. Lo borrado antes de la captura ya no vuelve. ## 3. Mantenga el hilo de la conversación y sus propias acciones Déjelo funcionando. Marque con estrella los chats calientes como prioritarios, ajuste las revisiones en **Ajustes de grabación → Revisión** y vigile `recheck.completed`, FloodWait y los resultados multimedia. **Chats → Perfil → Guardar perfil ahora** guarda la descripción del chat, los comandos del bot y otros metadatos. **Seguir a un bot o aceptar una invitación como parte del caso** 1. **Chats → Abrir enlace de Telegram**, guarde primero la vista previa. Enlace y vista previa pasan a ser registros firmados. 2. Si hace falta, **Unirse / abrir y observar** se une al chat o arranca el bot con su parámetro de inicio. 3. Para documentar una acción, responda o use **Pulsar botón** desde el panel. Obtiene `interaction.requested` e `interaction.result` con la respuesta del bot. Son acciones reales. Los botones pulsados en otra app no se ven, solo la respuesta del bot. Sin web apps, pagos ni teléfono/ubicación. ## 4. Realice un seguimiento de personas, enlaces y archivos en los distintos chats 1. **Diario**, **Todas las fuentes**, busque una frase, un dominio o un usuario. Abra los resultados y envíelos **Al tablero**. 2. **Chats → Personas → Activar perfiles**, elija a alguien: historial de nombres, respuestas, actividad, **También en…**, enlaces, monederos, teléfonos. Abra los registros citados. 3. Siga el mismo ID numérico de usuario en otros chats. Un nombre, monedero o avatar que coincide es una pista, no una prueba. 4. Compare hashes de archivos. Mismo SHA-256 = mismos bytes. Quién los compartió es otra cuestión. MAPA DEL CASO / SIGA LAS REFERENCIASCaso ficticio · no es un gráfico en tiempo real CANAL / ANUNCIO**Original → destino editado** Registros n.º 101, n.º 188; mensaje n.º 84 · remitente no identificado GRUPO / OPERACIONES**El usuario 71001 publica el nuevo enlace** Registro n.º 146 · mensaje n.º 309. Acuse de recibo del archivo guardado n.º 151 BOT / CONVERSACIÓN SOBRE PEDIDOS**Un botón le lleva a ese destino** Registro n.º 173 · mensaje n.º 12: Metadatos del botón «Volver» PRIVADO / SEGUIMIENTO**El usuario 71001 repite el destino** Registro n.º 205 · mensaje n.º 922. Recibo de archivo guardado n.º 209 Cuatro chats aportan diferentes observaciones. Sigue los registros originales de cada conexión; la publicación del canal no tiene remitente identificado. Los identificadores numéricos y las referencias de los registros son ficticios para este tutorial. Este mapa explicativo muestra cómo relacionar los resultados de búsqueda, los perfiles y los registros inspeccionados; el «Case Board» almacena las fichas correspondientes y las referencias a las fuentes. | Conexión | Observación complementaria | Conclusión: mantener | | --- | --- | --- | | La misma cuenta de Telegram | ID de usuario 71001 en el grupo n.º 146 y en el chat privado n.º 205 | El mismo ID de remitente en los dos chats. Quién es en la vida real es otra cuestión. | | Destino repetido | `pay.example.invalid/new` en el n.º 146, metadatos del botón en el n.º 173, publicación editada en los n.º 188 y 205 | El mismo enlace en cuatro sitios. Quién lo controla requiere otras fuentes. | | Mismo número de bytes del archivo | Valores SHA-256 completos idénticos en los recibos multimedia completados n.º 151 y n.º 209 | Los dos archivos son idénticos byte a byte. | Los perfiles solo cubren a quien escribió algo en *este espacio*; no son una lista de miembros. Citas por hecho: **Parámetros → Registros citados por hecho**. ## 5. Reconstruir la secuencia y señalar las lagunas Versiones en **Chats**, luego **Diario** con **Todas las fuentes** + **Ediciones**, **Borrados**, **Cobertura**. Ponga las dos horas en la cronología: la fecha de Telegram y cuándo se observó. 1. 09:00 · #101**Publicación del canal capturada** Se mantiene el destino original. 2. 09:12 · #146 / #151**El grupo presenta un enlace diferente** El usuario 71001 lo publica; se completa la descarga de un archivo adjunto. 3. 09:16 · #173**El bot muestra el mismo destino** Los metadatos del teclado guardados contienen el enlace. 4. 09:20 · #188**Cambios en los anuncios del canal** Se conservan tanto las observaciones originales como las editadas. 5. 09:24 · #205 / #209**En el seguimiento privado se repite lo mismo** El archivo adjunto guardado tiene el mismo SHA-256 completo que el n.º 151. 6. 09:28 · #231**Llega una notificación de eliminación de grupo** La observación anterior sigue siendo válida: no se facilita ni quién ha eliminado el mensaje ni la hora exacta de la eliminación. Se incluyen ejemplos de horas de observación y referencias. Entre estas entradas hay otros registros del diario. El orden del diario es el orden de llegada, no necesariamente el orden en que ocurrieron las cosas. Mantenga separados registros en vivo, capturas, mensajes recuperados, borrados y «no encontrado en revisión», y marque cada hueco como desconocido. ## 6. Amplíe el caso a otras cuentas de recopilación Un espacio por cuenta, mismos pasos. Apunte el rol y la huella de cada uno. Los números de mensaje son por cuenta, así que indique siempre el espacio y el chat. Un [grupo de cuentas](https://phishdestroy.github.io/TgWitness/es/docs/groups/) muestra el estado, comparte ajustes y exporta a todos juntos, cada uno con su diario y su clave. La cronología entre cuentas la monta usted en sus notas. ¿Caso largo? Añada un [testigo independiente](https://phishdestroy.github.io/TgWitness/es/docs/witness/) y pruebe qué capta realmente cada cuenta. ## 7. Entregar un paquete de caso verificable Un ZIP firmado de cada espacio (siempre el diario entero; los filtros no importan), más perfiles de personas, exportaciones de chats y archivos. ``` CASE-001/ # assembled by the analyst case-notes.md # question, findings, alternative explanations sources.csv # every chat, role, acquisition result and gap timeline.csv # account + chat + message + seq + both times workspace-A/ evidence.zip # complete signed observation journal retained-checkpoint.json profiles-operations.json # separately signed people profiles history-channel.zip # signed current-history export history-group.zip verification.txt workspace-B/ # separate journal and trusted fingerprint witness/ # retained checks, journal and signed posts SHA256SUMS # hashes of the delivered files ``` Envíe las huellas por separado. Verifique cada cosa con su propio espacio: ``` python -m tgwitness.verify evidence.zip --fingerprint TRUSTED_PUBLIC_KEY_SHA256 --checkpoint retained-checkpoint.json python -m tgwitness.verify profiles-operations.json --fingerprint TRUSTED_PUBLIC_KEY_SHA256 --evidence evidence.zip python -m tgwitness.verify history-channel.zip --fingerprint TRUSTED_PUBLIC_KEY_SHA256 ``` Guarde la salida del verificador, los originales, la cobertura y el registro de entrega con sus conclusiones. Redáctelo en Report studio. Si el destinatario necesita menos, prepare una [entrega minimizada](https://phishdestroy.github.io/TgWitness/es/docs/handover/). --- # Telegram · Crear un «Case Board» Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/case-board/ Recopila las observaciones guardadas, los aspectos destacados exactos y los fragmentos de acción en un tablero privado, coméntalos con tu equipo y presenta una recopilación. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Convierta los mensajes guardados en un caso en el que trabaja todo el equipo. Marcadores, citas exactas, fragmentos y debates, cada uno vinculado a su fuente. Cada cambio es una revisión firmada. ## De un mensaje a una ficha de caso 1. **Investigación → Case Board** (modo Estándar o Experto). Cree una colección para el caso. 2. En el **Diario** o en un chat pulse **Al tablero** (o **B**). La tarjeta llega a la bandeja de entrada; póngale un título y muévala. 3. Seleccione texto en un mensaje: **Resaltar → tablero** guarda la cita exacta y la versión. Anote por qué importa. 4. Debata, ponga un estado y vuelva a la fuente cuando haga falta. **Presentación** recorre el material con el equipo. ### Sigue un enlace de pago modificado Ejemplo sintético · ilustración local 1. **Captura.** Abre la observación guardada n.º 142 y su versión del mensaje. 2. **Añadir a favoritos.** Anota la cita, la referencia de la fuente y tu pregunta en una ficha. 3. **Revisar.** Añade un comentario del equipo y mueve la ficha a «Revisar». 4. **Presentar.** Recorrer la recopilación y abrir el contexto de la fuente citada. #### Observación guardada n.º 142 «Utiliza el nuevo enlace de pago». Chat de operaciones · mensaje 38 · observado a las 09:12 UTC #### Ficha: destino modificado > Utiliza el nuevo enlace de pago. Pregunta: ¿qué destino aparecía en la versión anterior? #### Revisión del equipo Analista: compárese con la observación n.º 101. Estado: Revisión · revisión aceptada #### Contexto de origen Ficha → versión guardada → observación anterior Las anotaciones y la observación de Telegram siguen siendo identificables por separado. ## Guarda un rango útil una sola vez Mayúsculas + clic en dos mensajes para **Fragmento entre**, use **Fragmento por tiempo** o guarde los filtros actuales del diario. **Mostrar registros añadidos desde el marcador** enseña lo que llegó después. Los fragmentos por tiempo usan la hora de observación; los fragmentos por ID siguen a esos mensajes cuando cambian. ## Asigna a cada compañero el rol adecuado **Revisor** lee, **Analista** añade tarjetas y comentarios, **Operador** además gestiona colecciones y decisiones. Los permisos de chat también se aplican a las tarjetas. ## Convierte el trabajo en un producto final. Los fragmentos se exportan como JSON firmado o CSV. Los informes pueden incluir marcadores, fragmentos y comentarios; configúrelo en [Report studio](https://phishdestroy.github.io/TgWitness/es/docs/reports/). Para un destinatario limitado, use una [entrega](https://phishdestroy.github.io/TgWitness/es/docs/handover/). Detalles: [referencia de Case Board](https://phishdestroy.github.io/TgWitness/es/docs/reference/case-board/). --- # Telegram · Diseñar un informe Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reports/ Selecciona los datos del informe, uno de los ocho diseños y el contenido; a continuación, previsualiza y exporta el archivo en formato HTML, PDF firmado o un paquete completo de pruebas. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Lleve al lector de la pregunta del caso directamente a los registros guardados. Report studio junta los datos que elige, los historiales de cambios, los gráficos y sus conclusiones. Ocho diseños, HTML y PDF nativo. Cada informe HTML, PDF y JSON se sella con su clave. ## Elabora un informe en tres pasos 1. **Exportaciones → Configurar y previsualizar → Datos**: el espacio entero o los chats, autores, fechas (UTC, cuando TgWitness vio el registro) y tipos de registro que elija. 2. **Diseño y contenido**: elija un diseño y qué entra: gráficos, participantes, transcripción, cambios, elementos de Case Board, datos del caso y notas. 3. **Vista previa**: revise recuentos, actividad, muestras y rangos de IDs que faltan. Guarde y descargue el formato que necesite. ### Organiza el mismo material guardado para que resulte comprensible al lector. Ejemplo sintético · maquetación esquemática, no es un informe generado 1. **Seleccionar.** Elige dos chats y el periodo de observación para el caso. 2. **Redacta el texto.** Elige un formato y las secciones que respondan a la pregunta. 3. **Vista previa.** Revisa el recuento de palabras seleccionado y el texto guardado «antes y después». 4. **Verificar.** Generar el archivo final y comprobar su firma comparándola con la huella digital del espacio de trabajo de confianza. #### Observaciones seleccionadas 2 chats · 1 día de observación Mensajes, ediciones y avisos de eliminación #### Estructura del informe ##### Se ha cambiado el destino del pago Pregunta del caso → alcance → conclusiones → referencias de los registros **Contexto del mensaje** Observación n.º 142: «Utiliza el nuevo enlace de pago». **Cambios guardados** Antes: old.example.invalid → Después: new.example.invalid #### Revisar la selección 18 observaciones · 2 ediciones guardadas Las horas de envío, edición y consulta tienen etiquetas distintas. #### Entrega final PDF firmado + JSON firmado, o un ZIP firmado con su informe legible El destinatario comprueba el archivo y la huella digital de confianza. ## Elige un estilo de lectura **Classic, Editorial, Briefing, Analytics, Technical, Overview, Reading series, and Ledger & margin**: los mismos registros, otro aspecto. Al cambiar se conservan la selección y las notas. Cualquiera de los 25 idiomas. Los PDF se generan con fuentes incluidas, sin navegador. Chino, japonés y coreano necesitan una fuente como Noto Sans CJK en el servidor (en el sistema o en `TGWITNESS_FONT_DIR`); si no, solo obtiene HTML y JSON. ## Lee cada cambio en su contexto Las ediciones muestran antes y después; los borrados, la última versión guardada. Respuestas, reenvíos, reacciones, botones y adjuntos conservan sus referencias. La vista previa del diseño usa los primeros 50 000 registros; la de datos lo cuenta todo con exactitud. Para la maquetación final, genere el PDF. ## Elige cuidadosamente la versión destinada al destinatario. Los filtros solo dan forma al informe; el ZIP de evidencia sigue teniendo el diario y los archivos completos. Si el destinatario debe recibir menos, use una [entrega minimizada](https://phishdestroy.github.io/TgWitness/es/docs/handover/). Más: [contenido del informe](https://phishdestroy.github.io/TgWitness/es/docs/reference/case-reports/), [verificar la exportación](https://phishdestroy.github.io/TgWitness/es/docs/exports/). --- # Telegram · Prepara una copia para compartir Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/handover/ Selecciona los registros y campos que un destinatario puede recibir, revisa la copia final y verifica su manifiesto firmado y los límites del diario de origen. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Comparta solo lo necesario; el original queda intacto. Una entrega es un extracto firmado aparte: elija chats y personas, oculte identidades o texto, decida qué archivos y notas del equipo van. El manifiesto registra qué se mantuvo, se recortó y se dejó fuera. ## Preparar el extracto del destinatario 1. **Exportaciones → Extracto de entrega**: escriba el propósito, elija chats y un periodo y use **Cargar personas de los chats elegidos** si necesita personas con nombre. 2. El resto: seudónimos, fuera o tal como se registró. Texto y archivos son interruptores separados; teléfonos y correos se pueden enmascarar. 3. Case Board: nada, marcadores y fragmentos, o tarjetas con comentarios. Los nombres del equipo se pueden cambiar por alias. 4. **Descargar extracto de entrega**, ábralo, verifíquelo y revíselo antes de enviarlo. ### Un original y una copia para compartir. Ejemplo sintético · solo a título ilustrativo 1. **Seleccionar.** Incluir el chat del caso e identificar a la persona a la que se refiere el extracto. 2. **Minimizar.** Elige cómo aparece otro participante en la copia compartida. 3. **Revisa.** Abre el informe y los registros del archivo generado antes de enviarlo. 4. **Compartir.** Entregar la copia revisada y comunicar por separado su huella digital verificada. #### Observación original Nora · usuario 71002 «He recibido el enlace revisado». El diario de origen conserva esta observación guardada. #### Copia para el destinatario Mostrar tal y como se registró: Nora · usuario 71002 · «He recibido el enlace revisado». Seudónimo: P01 · «He recibido el enlace revisado». Omitir: el mensaje de este participante no se incluye en el texto. #### Revisa los archivos reales Lee los archivos report.html y records.jsonl. Comprueba las identidades, el texto, los archivos adjuntos y los comentarios opcionales del equipo. #### Extracto firmado Selección + hash de archivos + manifiesto firmado Un paquete independiente vinculado al límite del diario de origen ## Utiliza los controles de forma conjunta | Control | Repercusión en el texto | | --- | --- | | Personas | Las personas seleccionadas conservan su nombre; las demás reciben seudónimos o quedan fuera. | | Texto | Todo el texto, solo el de las personas seleccionadas y su cuenta, o nada. | | Archivos | Archivos de las personas seleccionadas y su cuenta, todos los archivos mostrados o ninguno. | | Tablero de casos | Nada, marcadores y fragmentos, o tarjetas con debate. | Lea también el texto y los archivos: un seudónimo no borra los nombres escritos dentro de un mensaje o adjunto. Si falta un archivo seleccionado, restáurelo o deje fuera los adjuntos. ## Asegúrese de que el texto se pueda verificar de forma independiente. ``` python -m tgwitness.verify handover.zip --fingerprint TRUSTED_PUBLIC_KEY_SHA256 ``` Quédese usted con el archivo original y los puntos de control. El destinatario puede verificar su copia sin recibir el espacio entero. Diseño: [Report studio](https://phishdestroy.github.io/TgWitness/es/docs/reports/). Referencias de confianza: [verificación de exportaciones](https://phishdestroy.github.io/TgWitness/es/docs/exports/). --- # Telegram · Gestionar un grupo de cuentas Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/groups/ Compara los espacios de trabajo de grupo, busca una fuente, revisa los periodos de observación y aplica configuraciones compartidas con excepciones por cuenta. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Gestione varias cuentas juntas, cada una con sus propios registros y su clave. Un grupo reúne en una pantalla el estado de conexión, iniciar/pausar, los ajustes compartidos y las exportaciones. Práctico cuando varias cuentas trabajan el mismo caso. ## Abrir la vista general del grupo Abra el grupo en **Cuentas**. Cada cuenta muestra su estado, ruta, latencia y último mensaje guardado. **Requiere atención** lista las que fallan y **Arreglar** le lleva directo. **Iniciar todas** / **Pausar todas** preguntan antes de actuar. Los **Ajustes del grupo** se comparten, pero los valores propios de una cuenta se mantienen hasta que los sustituya. ### Revisar un cambio de ruta en un grupo Ejemplo sintético · comprobaciones ilustrativas y resultados 1. **Seleccionar.** Elige el grupo y revisa qué cuentas cambiarán. 2. **Prepárate.** Mantén la ruta propia de una cuenta cuando deba permanecer separada. 3. **Comprobar.** Probar la conexión propuesta e inspeccionar los resultados medidos. 4. **Aplicar.** Volver a comprobar antes de guardar y revisar el resultado para cada cuenta. #### Equipo del caso Recopilador de canales · Recopilador de grupos · Cuenta de referencia 3 espacios de trabajo independientes #### Selección revisada Dos cuentas siguen la ruta propuesta. La cuenta de referencia sigue su propio recorrido. #### Comprobaciones previas Recopilador de canales: tiempo de transmisión de Telegram: 84 ms Recopilador de grupo: tiempo de transmisión de Telegram: 91 ms Estas cifras son valores ficticios que sirven a modo de ejemplo. #### Resultados de la solicitud Recopilador de canales: ruta guardada, observación reanudada. Recopilador de grupo: la comprobación ha fallado, se han restablecido los ajustes anteriores. Cuenta de referencia: se mantiene la ruta propia. ## Modifica la ruta añadiendo un paso de revisión 1. **Cambiar la ruta del grupo**, elija tipo y ajustes. 2. **Revisar selección**: qué cuentas cambian y cuáles tienen ruta propia. 3. **Preparar y comprobar** prueba una conexión nueva con Telegram y, cuando se puede, la IP de salida. 4. **Aplicar conexión comprobada** y mire cada resultado. Las cuentas activas continúan; las inactivas siguen así. La latencia es el tiempo de establecer la conexión con Telegram; la IP de salida es la que mostró la ruta al comprobarla. Los resultados pueden variar por cuenta. ## Utilizar el acceso superpuesto **Chats que ven varias cuentas** lista las fuentes compartidas y su cobertura. Canales y supergrupos se pueden exportar con varias cuentas a la vez mediante **Exportar con … cuentas**. Los chats privados y grupos básicos no: allí los números de mensaje son por cuenta. ## Exportar el grupo como un paquete **Exportar grupo** da un ZIP con la exportación firmada de cada cuenta y una lista firmada de ellas. Cada una conserva su huella para la verificación. La cronología unificada la monta usted. Siguiente: [informes](https://phishdestroy.github.io/TgWitness/es/docs/reports/), [Case Board](https://phishdestroy.github.io/TgWitness/es/docs/case-board/), [verificar exportaciones](https://phishdestroy.github.io/TgWitness/es/docs/exports/). --- # Telegram · Vea cómo funciona el registro de pruebas Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/concepts/ Siga el recorrido de un mensaje desde su captura hasta el punto de control. Modifique un registro de ejemplo, vuelva a calcular su cadena SHA-256 y compruebe qué detecta un punto de control conservado. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Los mensajes cambian. Su registro de lo que vio no debería, y cualquiera debería poder comprobarlo. Dos pequeños experimentos abajo. Mensajes ficticios, todo funciona en su navegador, nada va a Telegram. ## De una exportación de chat a un registro verificable Una [exportación de Telegram Desktop](https://telegram.org/blog/export-and-more) guarda el historial que ve ahora en HTML o JSON. TgWitness añade un diario continuo de cambios, firmas en cada registro y puntos de control con los que otros pueden comparar. | Tarea | Exportación desde Telegram Desktop | TgWitness | | --- | --- | --- | | Leer conversaciones guardadas | HTML o JSON con archivos multimedia seleccionados | Chats guardados, diario con función de búsqueda e informes sin conexión | | Seguir la evolución a lo largo del tiempo | El historial disponible al exportarlo | Versiones antiguas, ediciones posteriores y borrados, todo guardado | | Revisar los archivos tras la entrega | Los archivos de exportación estándar en formato HTML/JSON no están firmados. | Manifiesto firmado, registros firmados e informes sellados, comprobados con una clave de confianza | | Comparar con un estado anterior conservado | Conserva una copia de referencia separada o un hash | Puntos de control firmados, un testigo independiente y marcas de tiempo externas opcionales | La comparación se basa en el [código de exportación de Telegram Desktop](https://github.com/telegramdesktop/tdesktop/tree/768d47cda6c7f447c10a25d1f363279493a90ed7/Telegram/SourceFiles/export/output) a 2 de noviembre de 2026. ## Un mensaje, tres observaciones Un mensaje nuevo, una edición y un borrado se convierten en tres registros separados. La edición no sobrescribe el primero y el borrado no lo elimina. 01 / RECORRIDO DEL MENSAJESecuencia ilustrativa Telegram delivers an update to the collector, which appends a journal record. · Telegram · Recopilador · Registro · Actualización → · añadir → VISTA DEL CHAT ACTUAL Mensaje n.º 42 Mensaje eliminado El mensaje ha desaparecido de la vista del chat. REGISTO DE OBSERVACIONES 3 registros 1. 01 `message.new` Nos vemos a las 10:00 ✓ 2. 02 `message.edited` Nos vemos a las 11:00 ✓ 3. 03 `message.deleted` Aviso de eliminación del n.º 42 ✓ Las tres observaciones recibidas permanecen en el registro. Ruta simplificada para una fuente ya seleccionada. Los registros operativos también comparten el diario real. La captura depende de lo que la cuenta pueda ver y de lo que Telegram facilite. Telegram no dice quién borró un mensaje ni cuándo exactamente. TgWitness deja esos campos vacíos en vez de adivinar. ## Modifique un registro. Siga el hash. Cada registro contiene el hash del anterior. Un punto de control guardado en otro sitio fija la longitud del diario y el último hash. 02 / HASH-CHAIN SANDBOXSHA-256 real · registros de muestra REGISTRO 01**Mensaje recibido**`h₁ = SHA-256(e₁)`Enlaces a 64 ceros REGISTRO 02**Nos vemos a las 11:00**`h₂ = SHA-256(e₂)`Incluye h₁ REGISTRO 03**Se ha observado una eliminación**`h₃ = SHA-256(e₃)`Incluye h₂ CONSERVADO EN OTRO LUGAR**3 registros · encabezado `h₃`**Compare este límite fijo con el registro facilitado. La modificación de un evento cambia su hash. La reconstrucción de la cadena cambia su cabeza. La eliminación de la cola hace que sea más corta que el punto de control conservado. **Consulte el registro n.º 2 y los hash completos** Este es el JSON UTF-8 exacto al que se ha aplicado el hash en este ejemplo. Los valores son ficticios; los nueve campos y la serialización se ajustan al formato del registro. ``` ``` Hash del registro guardado n.º 2 `` Hash del registro 2 recalculado `` Este entorno de pruebas calcula hash, no firmas. El verificador real comprueba además la firma Ed25519, la secuencia y el enlace de cada evento. La mera reconstrucción de los hash no permite crear firmas válidas bajo la clave de confianza. ## Las normas propiamente dichas, en unas pocas líneas HASH + FIRMA h0 = 064 hi = hex(SHA-256(C(ei))) σi = Ed25519.Sign(sk, unhex(hi)) **C** son los nueve campos del evento como JSON UTF-8: claves ordenadas, sin espacios extra, sin escapado ASCII, sin NaN/infinito. `previous_hash` es hi−1, h0 son 64 ceros y las firmas cubren los 32 bytes brutos del resumen. Los campos: `seq`, `observed_at`, `source_at`, `kind`, `chat_id`, `message_id`, `actor_id`, `payload`, `previous_hash`. Especificación completa: [codificación de eventos](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#event-canonicalization). PUNTO DE CONTROL CONSERVADO Nexport ≥ Ncheckpoint hexport[Ncheckpoint] = Hcheckpoint Compruebe la firma del punto de control con la clave fijada y luego compárelo con el diario. Una exportación posterior puede ser más larga, pero tiene que coincidir en el punto de control. ## Tres preguntas, tres comprobaciones diferentes [01 / INTEGRIDAD**¿Ha cambiado este registro?** Hashes y firmas contra una clave de confianza.](https://phishdestroy.github.io/TgWitness/es/docs/exports/)[02 / CONTINUIDAD**¿Qué se había conservado anteriormente?** Compare la exportación con los puntos de control que guardó un testigo.](https://phishdestroy.github.io/TgWitness/es/docs/witness/)[03 / ENTREGA**¿Han llegado estos eventos de prueba?** Envíe, edite y borre mensajes de prueba y vea qué captó cada cuenta.](https://phishdestroy.github.io/TgWitness/es/docs/cases/) Las firmas responden «¿se cambió?», los puntos de control «¿coincide con lo que había antes?» y los mensajes de prueba «¿lo captamos todo?». [Qué demuestra la verificación y qué no.](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#verification-scope) Siguiente: una [investigación de cuenta entera](https://phishdestroy.github.io/TgWitness/es/docs/cases/) de principio a fin. [Export Clinic: watch the controlled Desktop experiment](https://phishdestroy.github.io/TgWitness/docs/export-clinic/). Compare the two-minute film, the original recording and seven pairs of test exports. Local modification is disclosed. --- # Telegram · Mantenga la seguridad Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/security/ Consulte dónde se almacenan las sesiones, las claves y las pruebas, qué datos salen de su equipo, qué protegen las medidas de seguridad y cómo reforzar la seguridad de una instalación. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Qué sale de su máquina, qué abre cada secreto y qué cubren las protecciones frente a lo que le toca a usted. **127.0.0.1**Dirección del panel por defecto **256 bits**token de panel aleatorio **0**CDN, herramientas de análisis o fuentes remotas **Ed25519**Firma en cada registro ## Donde se encuentra todo El recolector, el panel y cada registro se quedan en su máquina. Por defecto solo se contacta con Telegram; todo lo demás es un interruptor aparte. 06 / LO QUE SALE DE LA MÁQUINASu instalación SU ORDENADOR O SERVIDOR **Panel**127.0.0.1:8787 · token de portador **Recopilador**Un cliente de Telegram por espacio de trabajo DIRECTORIO DE DATOS **Registro**SQLite · encadenado por hash · firmado **Medios de comunicación**archivos nombrados según SHA-256 **Vault**Fernet · sesión, par de API, clave de firma, proxy - **Telegram**Siempre · a través de su ruta Conexión MTProto de la cuenta: directa, SOCKS5, HTTP o MTProxy. El modo «Ocultar IP» espera a que haya un proxy operativo. La conexión directa de reserva requiere un modo que lo permita explícitamente. - **Texto externo**Opcional · desactivado por defecto El registro, los archivos y los puntos de control se cifran con AES-GCM antes de subirlos a un almacenamiento compatible con S3. La clave la conserva usted; los archivos adjuntos se nombran mediante hash con clave, no mediante el hash de su contenido. - **Notificaciones**Opcional · desactivado por defecto Problemas y recuento de cambios con los títulos de los chats. Los extractos de los mensajes solo se envían si usted activa esta opción. - **Autoridad de sellado de tiempo**Opcional · desactivado por defecto Únicamente el SHA-256 de un punto de control firmado y un nonce aleatorio. Sin mensajes ni nombres de chat. - **Testigo**Opcional · desactivado por defecto Obtiene puntos de control firmados y contadores de capturas mediante un token de solo lectura. No puede leer conversaciones ni modificar la configuración. Por defecto: solo la conexión a Telegram sale de este equipo. Los destinos opcionales se configuran por espacio de trabajo. El texto de los mensajes y los archivos multimedia se almacenan sin cifrar en el directorio de datos: protéjalo mediante el cifrado del disco y los permisos de los archivos. ## Lo que cada secreto desvela | Secreto | Dónde se almacena | Qué posibilidades ofrece | En caso de filtración | | --- | --- | --- | --- | | **Token de panel** | `panel-token.txt` en el directorio de datos; el navegador lo guarda por pestaña | Todo en todos los espacios | Detenga TgWitness, borre `panel-token.txt` y arranque de nuevo: obtiene uno nuevo | | **Sesión de Telegram** | Almacén cifrado (`credentials.enc`) | La propia cuenta de Telegram | Finalice la sesión en Telegram en *Ajustes → Dispositivos* | | **Clave de firma** | Almacén cifrado (`signing.enc`) | Firmar registros con su huella | Los puntos de control guardados en otro sitio, un testigo y las marcas de tiempo siguen mostrando lo que existía antes | | **Clave de la bóveda** | `vault.key` junto a los datos o una clave maestra externa | La bóveda | Dé por filtradas también la sesión y la clave de firma | | **Token de Witness** | En el servidor de TgWitness | Solo lectura: puntos de control y estado | Bórrelo en la página del testigo y cree uno nuevo | | **Texto clave para uso externo** | Vault; descárguelo una sola vez para poder recuperarlo | La copia externa | Quien tenga además el bucket puede descifrarla: considere la copia expuesta | ## Qué cubren las medidas de protección ### Cubierto - Un registro cambiado, eliminado o reordenado: se rompe la cadena de hashes o una firma. - Un diario recortado o reconstruido después de guardar un punto de control en otro sitio: el punto de control deja de coincidir. - Adivinar el token: 256 bits aleatorios, comparación en tiempo constante; 15 fallos por minuto y la dirección queda bloqueada. - Contenido hostil en chats: el texto sigue siendo texto, nunca HTML; los adjuntos se descargan como archivos; el panel no carga nada de otros sitios. - Un directorio de datos robado con clave de bóveda externa: sesiones y claves siguen cifradas. ### A su criterio - El token principal lo puede todo. Dé a otros acceso limitado y guárdese el principal. - Quien sea administrador de la máquina puede leerlo todo y volver a firmar el diario. Guarde la huella y los puntos de control en otro sitio. - TgWitness no cifra mensajes ni multimedia. Cifre el disco y restrinja los permisos. - HTTP plano fuera de localhost filtra el token. Use HTTPS o un túnel SSH. - Las firmas no le dicen qué se perdió. Compruebe la cobertura y pruebe la entrega en sus propias cuentas y fuentes. [Comparta el acceso a un caso](https://phishdestroy.github.io/TgWitness/es/docs/access/) con permisos, caducidad y límites de sesión. ## Reforzar una instalación 0 de 8 completado 1. **Use una cuenta de Telegram dedicada**, nunca la principal. 2. **Mantenga el panel en 127.0.0.1.** Acceso remoto solo por HTTPS (Caddy incluido) o túnel SSH. 3. **Cifre el disco** con el directorio de datos: mensajes y multimedia se guardan tal cual. 4. **Restrinja el directorio de datos** a la cuenta de servicio (0700 en Unix, permisos de carpeta en Windows). 5. **Guarde la clave de la bóveda aparte** en servidores: defina `TGWITNESS_VAULT_KEY_FILE` antes del primer arranque. 6. **Guarde la huella y los puntos de control** en otro sistema y ejecute un testigo en otro host. 7. **Nunca suba** claves `data/`, de sesión, `panel-token.txt` o de bóveda a GitHub ni a un chat. 8. **No registre** los encabezados «`Authorization`» ni los cuerpos de las solicitudes en un proxy inverso. **¿Puedo cambiar el token del panel sin perder datos?** Sí, solo abre el panel. Detenga TgWitness, borre `panel-token.txt` y arranque de nuevo. Diario, sesiones y claves se mantienen. Si `TGWITNESS_TOKEN` está definido, ese valor manda sobre el archivo. **¿Por qué los mensajes no están cifrados en reposo?** El recolector tiene que leerlos para buscar, comparar y exportar. Una clave en la misma máquina no detendría a quien ya puede leer esa máquina. El cifrado de disco cubre un disco robado; los permisos, uno en marcha. ## Informar de una vulnerabilidad **Security → Report a vulnerability** en GitHub. Versión, impacto y una reproducción mínima con datos ficticios. Nunca envíe credenciales, carpetas de cuentas ni evidencia real. Si el informe privado está desactivado, abra un issue pidiendo un canal privado, sin detalles del exploit. --- # Telegram · Configurar un bot de TgWitness Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/witness/ Publique puntos de control del registro firmado en su canal de Telegram con un testigo independiente, que cuente con su propia clave y acceso de solo lectura al recopilador. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Un proceso aparte comprueba su diario y publica puntos de control firmados en un canal. ## Dos servidores, dos claves de firma ALOJAMIENTO / RECOPILADOR**Cuenta + registro** Clave de firma del recopilador de sesiones de Telegram Punto final de control de solo lectura ← Solicitar respuesta firmada → HOST B / WITNESS**Verificar + conservar** Huellas digitales de los recopiladores fijadas. Clave de firma de testigo independiente. Registro propio + token del bot Witness → API de bot de Telegram →**Su canal · publicaciones firmadas con TGW1** El «witness» realiza las comprobaciones por sí mismo. El acceso del recopilador es de solo lectura. La publicación del bot utiliza la conexión y el token del «witness»; no se concede ninguna sesión de cuenta al «witness». 03 / DECISIONES EN LOS PUNTOS DE CONTROLRespuestas ilustrativas ÚLTIMA VERSIÓN ACEPTADA**120 registros**`head 9c7d…` PRÓXIMA RESPUESTA**128 registros**`head a4f2…` Aceptado: el recuento aumenta, la firma se verifica y la clave coincide. El testigo conserva este nuevo límite. Todos los ejemplos de respuesta dan por supuesta una firma válida y la clave fijada. Los hash que aparecen aquí son ejemplos abreviados. Un recuento mayor por sí solo no puede demostrar que todo el prefijo anterior se mantenga inalterado; compare una exportación con los puntos de control conservados. ## Prepare un bot y un canal Cree un bot con BotFather y deje que publique en su canal. Ejecute el testigo en otro sitio: otro host, idealmente gestionado por otra persona, vale mucho más que un segundo proceso junto al recolector. ## Tres pasos en «Extras» 1. **Acceso de solo lectura.** **Extras → Testigo independiente**, cree un token y guarde el archivo. Lee puntos de control y estado, nada más. 2. **Canal e intervalo.** Canal de Telegram o webhook de Discord, más una dirección del recolector accesible para el testigo. Guarde el archivo de ajustes. 3. **Lanzar.** Ponga `witness.json`, `witness-token.txt` y `bot-token.txt` juntos en el host del testigo y ejecute: ``` python -m tgwitness.witness run --config witness.json --check-config python -m tgwitness.witness run --config witness.json ``` Espere a la primera publicación firmada en el canal y guarde la huella del testigo en un lugar seguro. ¿Prefiere Discord? Guarde la URL del webhook como `discord-webhook.txt`. Un testigo publica en un solo sitio; en Discord las comprobaciones largas llegan como archivo. ## Elija la frecuencia de publicación Publicar cada comprobación deja un registro externo constante: cada cinco minutos son unas 288 publicaciones al día por espacio. Los ajustes avanzados permiten publicar solo con cambios o problemas, usar un proxy o un Bot API propio. **¿Qué es lo que certifica realmente el bot?** Pide al recolector un punto de control firmado, lo comprueba con la clave esperada y lleva su propio diario firmado, incluidas las respuestas perdidas y rechazadas. Comprueba el estado del diario; no vigila Telegram por sí mismo. Para eso, haga una prueba de entrega controlada. ## Compruebe las pruebas más adelante Guarde el diario del testigo, las publicaciones y las huellas. [Cómo comprobarlos](https://phishdestroy.github.io/TgWitness/es/docs/reference/witness/#verify) frente a la exportación del recolector. --- # Telegram · Explorar el archivo Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/archive/ Carga el historial, busca registros guardados, revisa las fuentes de IA y conecta tus herramientas. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Encuentra el mensaje. Comprueba la fuente. Construye el caso. 01**Incluir el historial** Traiga al espacio los mensajes antiguos de sus fuentes activas. 02**Sigue las fuentes** Busque y abra el mensaje guardado detrás de cada resultado. 03**Mantén clara la transición** Su análisis en un archivo, la evidencia firmada al lado. Los registros capturados, el texto reconocido y las conclusiones de los analistas se mantienen bien diferenciados. ## Cargar mensajes anteriores 1. **Fuentes → Chats incluidos**: revise los chats activos e inicie la observación. 2. **Cargar historial completo**. Usa la lista de fuentes tal como está en ese momento. 3. **Pausar historial** / **Continuar historial** cuando quiera. Tras un reinicio, reanude a mano. 4. Revise el resultado por fuente y la cola de descargas, y guarde el informe de progreso firmado con la exportación. Esto llena el espacio. Exportar un solo chat a HTML/JSON es otra cosa. [Detalles](https://phishdestroy.github.io/TgWitness/es/docs/reference/history/). ## Busca primero y luego decide sobre la IA 1. **Diario** busca en local, con filtros por fuente y fecha. 2. Busque una frase o un dominio y abra el registro y sus versiones. 3. Para la IA, el administrador configura un proveedor en **Integraciones**. Luego **Preguntar al archivo**: elija chats y un periodo, mire **Datos enviados al modelo** y desmarque lo que no deba salir. 4. Compruebe las citas, guarde la respuesta como informe y añada sus notas. La búsqueda no necesita IA. Los informes guardan sus fuentes y revisiones, aparte del diario firmado. [Configurar el proveedor](https://phishdestroy.github.io/TgWitness/es/docs/reference/analysis/). ## Elige la conexión que necesites | Tarea | Abrir | Configuración | | --- | --- | --- | | Dejar que un cliente de IA lea chats elegidos | **Integraciones → MCP** | [Instale MCP, cree un token limitado y conecte](https://phishdestroy.github.io/TgWitness/es/docs/reference/mcp/) | | Reconocer texto en archivos multimedia guardados | Un registro `media.saved` → **Reconocer archivo adjunto** | [Configure el worker local de Docker](https://phishdestroy.github.io/TgWitness/es/docs/reference/media-analysis/) | | Enviar eventos a n8n o a un SIEM | **Integraciones → Webhooks salientes** | [Añada un receptor, compruebe el HMAC y descarte IDs repetidos](https://phishdestroy.github.io/TgWitness/es/docs/reference/webhooks/) | **¿Qué token de acceso va en cada sitio?** El acceso al panel es para personas. MCP tiene sus propios tokens de solo lectura y los webhooks su propio secreto HMAC. Ninguno necesita una sesión de Telegram. [Compartir el acceso al panel](https://phishdestroy.github.io/TgWitness/es/docs/access/) o [configurar un cliente MCP](https://phishdestroy.github.io/TgWitness/es/docs/reference/mcp/). ## Presentar las fuentes y las conclusiones Ponga el informe junto al ZIP firmado. El informe es su lectura de las fuentes; el ZIP es lo que verifica el destinatario. [Exportar y verificar](https://phishdestroy.github.io/TgWitness/es/docs/exports/) · [Llevar a cabo una investigación completa](https://phishdestroy.github.io/TgWitness/es/docs/cases/) --- # Telegram · Compartir un caso Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/access/ Proporcione a los revisores y analistas acceso a cuentas y chats seleccionados, con permisos diferenciados, límites de sesión y tokens revocables. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Comparta el caso que alguien necesite. Mantenga el control sobre el resto. 01**Seleccione las pruebas** Espacios enteros o chats sueltos. 02**Seleccione las acciones** Ver, exportar o solo las operaciones que necesiten. 03**Establezca los límites** Un token personal con caducidad, límites de sesión y reglas de IP si lo desea. El ámbito de recopilación determina qué se registra. El ámbito de acceso determina lo que una persona puede ver y hacer. ## Conceder acceso a alguien 1. Como administrador, abra **Acceso**. 2. Póngale nombre y elija espacios y chats. 3. A un revisor le basta con **Ver**. Añada **Exportar** para las descargas. 4. Establezca los límites y, a continuación, pulse **«Crear acceso**». 5. Copie el token (se muestra una vez) y envíelo en privado junto con la dirección del panel. 6. Compruebe antes lo que verá en una sesión de navegador aparte. ## Comience por la tarea que deben realizar | Persona | Acceso | Resultado | | --- | --- | --- | | Revisor | Chats seleccionados; solo lectura | Lee el chat, no puede cambiar nada. | | Analista | Chats seleccionados; ver y exportar | Lee y descarga lo que el caso necesita. | | Operador | Espacios de trabajo completos seleccionados; fuentes y recopilación | Decide qué se observa e inicia y detiene recolectores. | Son solo ejemplos, no roles fijos. El acceso limitado a chats nunca recibe ajustes de cuenta ni exportaciones completas del diario. El acceso a todos los espacios incluye las cuentas añadidas después. ## Puede cambiar de opinión en cualquier momento Edite el acceso cuando quiera; se aplica desde la siguiente petición. Termine una sesión o revóquelo todo. Los archivos ya descargados no se pueden recuperar. La recogida sigue en marcha. **Límites de sesiones y direcciones IP** Limite sesiones paralelas e inicios de sesión, ponga una fecha de fin, permita IPs o subredes o fije el acceso a la IP del primer inicio. La caducidad cuenta la inactividad; un panel abierto cuenta como activo. Detrás de un proxy, compruebe qué IP de cliente ve la aplicación. **La clave principal y el registro de actividad** El token principal se queda con el administrador. El acceso emitido no puede gestionar el acceso de otros ni abrir la consola de administración. Los cambios de acceso y las sesiones se firman en el diario, sin tokens. El administrador del servidor sigue viéndolo todo. Los siete permisos y las reglas de sesión: [referencia de acceso](https://phishdestroy.github.io/TgWitness/es/docs/reference/access/). --- # Telegram · Manténgala en funcionamiento Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/server/ Ejecute TgWitness en un servidor con almacenamiento persistente, acceso privado al panel de control, copias de seguridad y comprobaciones tras un reinicio. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Mantenga el recolector en marcha y los datos a salvo en los reinicios. ## Elija un método de puesta en marcha Nativo: el [lanzador](https://phishdestroy.github.io/TgWitness/es/docs/start/) más las plantillas de servicio en [deploy/](https://github.com/phishdestroy/TgWitness/blob/main/deploy/README.md). Docker, desde la carpeta del proyecto: ``` docker compose up -d --build --wait docker compose exec tgwitness cat /data/panel-token.txt ``` El panel escucha en localhost:8787. Ábralo en local o por un túnel SSH, con el token del segundo comando. ## Conserve todo el directorio de datos Nativo: `data/live`. Docker: el volumen `tgwitness-data`. Diarios, sesiones y claves van juntos. Una exportación firmada es evidencia, no una copia de seguridad. 1. Detenga primero la recogida. 2. Copie el directorio de datos entero a un lugar seguro, fuera del host. 3. Pruebe a restaurarlo en una instalación aparte antes de fiarse. ## Compruébelo tras reiniciar el sistema. Compruebe el espacio y la clave, la conexión, las fuentes y que entran mensajes nuevos. TgWitness recupera lo que Telegram todavía guarda, no todo lo que pasó mientras estaba parado. Contenedor «sano» significa que el servidor web responde. Si la recogida funciona se lo dirán un mensaje de prueba y el testigo. ## Publique únicamente lo que tenga intención de publicar HTTPS, volúmenes, actualizaciones y restauración están en la referencia de despliegue. Lo que se ha probado de verdad: [registro de validación](https://phishdestroy.github.io/TgWitness/es/docs/reference/verification/). --- # Telegram · Averigüe qué ha fallado Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/troubleshooting/ Compruebe el acceso al panel, la conexión a Telegram, los mensajes que faltan, FloodWait y el estado de Witness utilizando las señales adecuadas para cada problema. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Empiece por el síntoma y compruebe una cosa cada vez. ## El panel solicita un token Pide el token del panel del archivo que indicó el lanzador. Docker: `docker compose exec tgwitness cat /data/panel-token.txt`. No es un código de Telegram, ni el token de un bot, ni el del testigo. ## Telegram no se conecta Ejecute la comprobación de conexión. Con un proxy público, elija otro y guarde. Revise el tipo de proxy y el formato del secreto. Actualizar las listas no cambia la ruta por sí solo. ## Conectado, pero no hay mensajes nuevos 1. ¿Está la observación en marcha, en el espacio correcto? 2. ¿Está la fuente seleccionada y es visible para esa cuenta? 3. Envíe un mensaje único a su grupo de prueba y búsquelo. 4. Busque interrupciones o errores de Telegram en el diario. Un chat tranquilo simplemente no tiene nada nuevo. Si importa la integridad, haga una prueba de entrega controlada. ## FloodWait o un lapso tras un reinicio FloodWait es Telegram diciendo «más despacio». Espere a que pase y baje la carga; reconectar no ayuda. Tras un reinicio, TgWitness recupera lo que Telegram aún tiene; el resto es un hueco, así que anótelo. ## El bot está configurado, pero no publica nada. ¿Está el testigo en marcha, puede el bot publicar en el canal, llega al recolector y al Bot API? Busque publicaciones fallidas en su diario. Una consulta en el lado del recolector no significa que se publicara. ## ¿Dónde se encuentra la integración del token de GitHub? **En fase de planificación.** La sección «Extras» describe el flujo de trabajo propuesto para la bifurcación y la verificación de la compilación. Actualmente no existe ningún formulario de token de GitHub ni ninguna certificación automatizada que confirme que una instalación en funcionamiento coincide con un repositorio. Consulte el [estado actual de las funcionalidades](https://phishdestroy.github.io/TgWitness/es/docs/reference/features/). ¿Informa de un error? Versión, sistema, pasos y un error sin datos personales. Nunca ponga sesiones, tokens, mensajes privados ni el directorio de datos en un issue público. --- # TgWitness: Telegram Export, OSINT & Verification Canonical page: https://phishdestroy.github.io/TgWitness/docs/reference/overview/ Explore TgWitness installation, Telegram capture, investigation tools and evidence verification. Read measured workloads alongside their methods and limits. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/llms.txt) Instálala con un solo comando o capturala en GitHub Actions. Comprende las opciones de investigación, la escala publicada y lo que verifica un archivo. TgWitness es un exportador de Telegram de código abierto y un espacio de trabajo para investigaciones. Instálalo con un solo comando, conecta una cuenta, selecciona los chats y exporta un archivo firmado . También permite la recopilación temporal en GitHub Actions y la continuación de las investigaciones con ediciones guardadas, observaciones de eliminaciones, búsquedas e informes. ## Empieza por la tarea que tengas | Tu tarea | Camino más corto | Lo que recibirás | | --- | --- | --- | | Guardar una conversación o una cuenta | Instalar, vincular una cuenta y seleccionar el ámbito de exportación | Un archivo firmado con el historial seleccionado, los resultados de la recopilación y el material de verificación. | | Recopilar en un ejecutor temporal | Utiliza GitHub Actions para capturar datos, autoriza una nueva sesión y selecciona el ámbito. | Un archivo cifrado con el historial del flujo de trabajo de GitHub | | Seguir los cambios a lo largo del tiempo | Mantener la observación activa para los chats seleccionados | Versiones guardadas, avisos de eliminación, archivos adjuntos y cobertura registrada | | Investigar y compartir los resultados | Busca en el archivo, utiliza el Case Board y configura un informe o una copia para compartir. | Resultados vinculados a la fuente y una entrega verificable adaptada al destinatario | ### Instalación con un solo comando El instalador incluye Python y sus dependencias. La descarga del código fuente, Docker, un proveedor de IA y un testigo independiente son opciones opcionales, no requisitos previos para la instalación. Linux / macOS: ``` curl -fsSL https://get.destroy.tools/install.sh | bash ``` Windows, en PowerShell o en la línea de comandos: ``` powershell.exe -NoProfile -ExecutionPolicy Bypass -Command "irm https://get.destroy.tools/install.ps1 | iex" ``` Abre el panel, conecta tu cuenta de Telegram y selecciona el alcance de la recopilación. La instalación no inicia la recopilación por sí sola. La guía de instalación explica el acceso local, los servidores, las actualizaciones y cómo comprobar la versión descargada. Para ejecutar una prueba temporal, sigue la captura [de GitHub Actions](https://github.com/phishdestroy/TgWitness/blob/main/docs/SEALED-ACTIONS.md). Ese flujo de trabajo requiere una bifurcación de GitHub, autorización y una contraseña para el archivo. La página de captura explica esos pasos y el tiempo de sesión disponible antes de la ejecución. Descarga y conserva el archivo resultante y su material de verificación. ## Más ajustes cuando la tarea los requiera Para exportar un único chat se necesita una cuenta y un ámbito seleccionado. La observación continua, las cuentas múltiples, los proxies, las políticas de archivos adjuntos, el diseño de informes, el acceso de los revisores, las marcas de tiempo externas y el almacenamiento externo satisfacen distintos requisitos de investigación y transferencia. Configura esas funciones cuando sean pertinentes. El alcance, los permisos y las copias compartidas minimizadas ayudan a los operadores a elegir qué recopilar y divulgar. Las orientaciones sobre jurisdicción y la configuración de los informes respaldan esa decisión; la selección de un perfil no garantiza por sí misma el cumplimiento legal ni la admisibilidad. Véase [exportación de cuentas](https://phishdestroy.github.io/TgWitness/es/docs/reference/account-export/), [acceso](https://phishdestroy.github.io/TgWitness/es/docs/reference/access/) y [configuración de informes](https://phishdestroy.github.io/TgWitness/es/docs/reference/case-reports/). La aplicación se ejecuta en el ordenador o servidor elegido. La recopilación básica no requiere una GPU ni un modelo de lenguaje grande (LLM). El OCR opcional, la transcripción y el análisis de IA tienen sus propios requisitos de recursos. Dimensiona la implementación en función de la tasa de mensajes, los archivos adjuntos, el historial conservado y las cuentas simultáneas; una instalación sencilla no garantiza un consumo de memoria fijo para todas las cargas de trabajo. ## Conservar el registro, sea quien sea a quien ayude. El objetivo es conservar el material observado, el contexto y los cambios, independientemente de la posición que respalden. Las pruebas pueden cuestionar la propia versión de los hechos del recopilador. Mantén las observaciones originales, la cobertura que falte y las conclusiones analíticas identificables, de modo que otra persona pueda evaluar el mismo material. La lógica es la siguiente: observación visible en la cuenta → registro firmado → exportación → verificación por parte del destinatario. Las modificaciones guardadas añaden versiones. Las observaciones eliminadas conservan el contenido capturado anteriormente. Los registros de cobertura revelan las interrupciones conocidas. Los informes y los análisis de IA remiten a las fuentes guardadas; una interpretación no se convierte en una observación de la fuente por el mero hecho de aparecer en un informe firmado. | Comprobación de verificación | Lo que un destinatario puede determinar | | --- | --- | | Hashes de archivos, firmas y cadena de registros | Los registros y archivos proporcionados coinciden con la clave esperada y los límites del registro. | | Un punto de control o testigo conservado por separado | El archivo coincide con un estado del diario conservado anteriormente. | | Una marca de tiempo externa verificada | Los bytes a los que se hace referencia existían en el momento de la marca de tiempo, bajo los supuestos de confianza indicados. | | Certificado de captura de GitHub | El archivo se ajusta al flujo de trabajo aprobado, a la revisión del recopilador y al resumen registrado. | Estas comprobaciones permiten verificar la integridad y la procedencia. No convierten el contenido de un mensaje en una afirmación verdadera ni reconstruyen mensajes eliminados que no se hayan visto . Utiliza una huella digital de la clave obtenida de forma independiente y los pasos de verificación descritos en [la guía de confianza](https://github.com/phishdestroy/TgWitness/blob/main/docs/TRUST.md) y [el formato de pruebas](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/). ## Escala publicada y rendimiento medido Los siguientes resultados describen diferentes cargas de trabajo y fechas. Los recuentos no son intercambiables: un evento del registro no es necesariamente un mensaje único de Telegram. | Fecha | Volumen de trabajo | Resultado publicado | Qué se midió | | --- | --- | --- | --- | | 1 de noviembre de 2026 | Servidor en funcionamiento, diez bases de datos de espacios de trabajo | 1,610,818: registros del diario; 900,232: eventos de mensajes nuevos; 80,683: eventos de edición; y 400,536: eventos de eliminación. | Inventario de solo lectura; no se trata de una prueba de rendimiento ni de una nueva verificación de cadena completa. | | 5 de noviembre de 2026 | Buscar entre mensajes sintéticos 1,000,000 en chats 200 | Índice creado en 71 segundos; tiempos medios de búsqueda por consulta de entre 9 y 190 ms. | Prueba de rendimiento de búsqueda local; no se trata de la entrega en tiempo real de Telegram. | | 6 de noviembre de 2026 | Dos exportaciones recientes y reales de Telegram | Mensajes 27,030 y 29,299; 56,329 en ambas ejecuciones | Dos cuentas por ejecución a través de WARP, texto y metadatos; no se descargan archivos adjuntos. | | 6 de noviembre de 2026 | Las mismas dos exportaciones, incluyendo la preparación y el empaquetado | 127.713 y 141.781 mensajes por segundo | Se han medido las tasas de exportación completa; ambos archivos se han verificado con las claves fijadas. | El registro de verificación proporciona el inventario del servidor, las comprobaciones de recopilación en tiempo real y las mediciones de búsqueda. [Rendimiento de exportación](https://phishdestroy.github.io/TgWitness/docs/validation/) publica las dos ejecuciones reales, el hardware, las duraciones, los hash de los archivos y los archivos de medición firmados. Estos establecen resultados para las revisiones y condiciones registradas, no una tasa universal ni un límite máximo de capacidad. ### Historial y duración de las pruebas El responsable del proyecto informa de más de seis meses de pruebas a fecha de 6 de noviembre de 2026. Esto describe el historial de pruebas del proyecto. Las mediciones públicas fechadas anteriores documentan ejecuciones individuales; no constituyen una recopilación ininterrumpida de seis meses verificada de forma independiente. La antigüedad de los mensajes exportados también difiere del tiempo que lleva en funcionamiento el recopilador. ## Leer con precisión el estado de la capacidad Evaluar cada flujo de trabajo en función de su implementación, la versión publicada y las pruebas registradas. El código fuente está etiquetado actualmente como vista previa. Esa etiqueta de versión coexiste con la recopilación de datos, las exportaciones, la verificación independiente y las mediciones de escala publicadas. Una función en vista previa y un flujo de trabajo validado pueden coexistir en la misma aplicación; describir la característica específica y las pruebas que respaldan una evaluación. Utilice [capacidades actuales](https://github.com/phishdestroy/TgWitness/blob/main/docs/STATUS.md), [características y límites](https://phishdestroy.github.io/TgWitness/es/docs/reference/features/), [verificación](https://phishdestroy.github.io/TgWitness/es/docs/reference/verification/) y [el registro de cambios](https://phishdestroy.github.io/TgWitness/es/docs/reference/changelog/) en conjunto. Registra la revisión probada al citar un resultado. La 6 La instantánea de medición de noviembre también conserva las pruebas fallidas y omitidas; estas no se consideran superadas. ## Legible tanto para personas como para herramientas de IA El sitio web ofrece un resumen conciso en `llms.txt`, un manual completo en inglés en `llms-full.txt` y `llms-full.md`, y versiones en Markdown de sus páginas. Se trata de formatos de documentación, no de un requisito de IA para ejecutar TgWitness. El acceso opcional desde la línea de comandos [MCP](https://phishdestroy.github.io/TgWitness/es/docs/reference/mcp/) y permite que las herramientas autorizadas lean los registros guardados seleccionados. El contenido de los mensajes sigue siendo una entrada no fiable. Los resúmenes deben citar las fuentes, distinguir los hechos observados de las inferencias y mantener la incertidumbre. La búsqueda de texto completo, el OCR y los resultados de la IA no modifican las observaciones originales firmadas. --- # Telegram · Inicio rápido Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reference/quickstart/ Todas las formas de instalar y poner en marcha TgWitness: paquete para Windows, Python, Docker y la demostración sintética, con las primeras comprobaciones. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Todas las formas de instalar y poner en marcha TgWitness: paquete para Windows, Python, Docker y la demostración sintética, con las primeras comprobaciones. [TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [Documentación](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) ![Primeros pasos](https://phishdestroy.github.io/TgWitness/assets/chapter-start.svg) **Inglés** · [Русский](https://github.com/phishdestroy/TgWitness/blob/main/docs/ru/QUICKSTART.md) · [Ucraniano](https://github.com/phishdestroy/TgWitness/blob/main/docs/uk/QUICKSTART.md) · [Español](https://github.com/phishdestroy/TgWitness/blob/main/docs/es/QUICKSTART.md) · [Portugués (Brasil)](https://github.com/phishdestroy/TgWitness/blob/main/docs/pt/QUICKSTART.md) · [Türkçe](https://github.com/phishdestroy/TgWitness/blob/main/docs/tr/QUICKSTART.md) · [العربية](https://github.com/phishdestroy/TgWitness/blob/main/docs/ar/QUICKSTART.md) · [فارسی](https://github.com/phishdestroy/TgWitness/blob/main/docs/fa/QUICKSTART.md) · [Urdu](https://github.com/phishdestroy/TgWitness/blob/main/docs/ur/QUICKSTART.md) · [Hindi](https://github.com/phishdestroy/TgWitness/blob/main/docs/hi/QUICKSTART.md) · [Bahasa Indonesia](https://github.com/phishdestroy/TgWitness/blob/main/docs/id/QUICKSTART.md) · [Tiếng Việt](https://github.com/phishdestroy/TgWitness/blob/main/docs/vi/QUICKSTART.md) · [Chino simplificado](https://github.com/phishdestroy/TgWitness/blob/main/docs/zh/QUICKSTART.md) TgWitness es una aplicación independiente para supervisar los grupos y canales de Telegram a los que tienen acceso sus cuentas. Se ejecuta localmente con su propio directorio de datos. **¿Es su primera visita?** [Explore la demostración](https://phishdestroy.github.io/TgWitness/es/docs/reference/quickstart/#explore-the-interface) antes de vincular una cuenta. [Elija una guía](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) sobre proxies, testigos, exportaciones o configuración del servidor. ## Instalación y puesta en marcha [Captura con GitHub Actions (versión preliminar)](https://github.com/phishdestroy/TgWitness/blob/main/docs/SEALED-ACTIONS.md) Elija un método. Las descargas portátiles estarán disponibles una vez que se publique una versión estable: | Alojamiento | No es necesario instalar nada | Fuente: Python 3.11+ | Docker: Engine/Desktop con Compose 2.20 o superior | | --- | --- | --- | --- | | Windows | Extraiga «`TgWitness--windows-amd64-portable.zip`» de las versiones de GitHub y haga doble clic en «`TgWitness.cmd`» | Haga doble clic en `Start.cmd` | Haga doble clic en `scripts\Docker.cmd` | | Linux / macOS | — | `sh start.sh` | `sh scripts/docker-start.sh` | Para los métodos desde el código fuente, [descargue y extraiga la rama `main` actual](https://github.com/phishdestroy/TgWitness/archive/refs/heads/main.zip) o clone el repositorio: ``` git clone https://github.com/phishdestroy/TgWitness.git cd TgWitness ``` `Start.cmd` ofrece instalar Python 3.12 para su usuario de Windows si no se encuentra un Python adecuado (mediante winget o el instalador firmado de python.org). `start.sh` muestra el comando de instalación exacto para su distribución de Linux o macOS si falta Python. El primer inicio desde el código fuente crea `.venv` e instala las dependencias automáticamente. Docker compila la aplicación y la inicia en segundo plano; no es necesario un servidor Python. `scripts\Docker.cmd` y `scripts/docker-start.sh` muestran la dirección del panel y el token cuando el contenedor funciona correctamente. Los comandos de Docker equivalentes en todos los hosts compatibles son: ``` docker compose up -d --build --wait docker compose exec tgwitness cat /data/panel-token.txt ``` Abra **http://127.0.0.1:8787**. Utilice el token generado por el asistente de Docker o el segundo comando de Docker, o consulte **el archivo data/live/panel-token.txt** si se trata de una instalación portátil o desde el código fuente. Continúe en **«Conectar Telegram»** más abajo. Las instalaciones nativas y de Docker utilizan un almacenamiento independiente; al iniciar Docker no se importa ningún registro nativo existente. En el caso de un servidor, [la implementación](https://phishdestroy.github.io/TgWitness/es/docs/reference/deployment/) incluye HTTPS automático, reinicio, imágenes publicadas, actualizaciones y copias de seguridad. ## Explore la interfaz 1. Ejecute **«TgWitness-Demo.cmd»** en el paquete portátil, **«scripts\Demo.cmd»** en una carpeta de origen de Windows o «`sh start.sh --demo` » en Linux/macOS. Al ejecutarlo desde la fuente, primero se crea «`.venv` » y se instalan las dependencias. 2. Open **http://127.0.0.1:8787**. 3. La demostración local abre automáticamente el registro de muestra. No se necesita ningún código de acceso para el acceso local directo. Los mensajes de demostración son ficticios. El modo de demostración no permite conectarse a una cuenta real de Telegram. ## Conectarse a Telegram > [!ADVERTENCIA] **No utilice nada que no pueda permitirse perder.** Le recomendamos encarecidamente que no conecte cuentas personales o valiosas y que no cree un ID de API ni un hash en una cuenta que considere importante. Telegram bloquea cuentas de forma impredecible y, a menudo, de manera permanente, independientemente del cliente utilizado. El buen funcionamiento de la prueba depende de Telegram, no de TgWitness, y no garantiza nada para el futuro. 1. Si la demostración nativa está en ejecución, deténgala y ejecute **«Start.cmd»** o «`sh start.sh`». De lo contrario, mantenga en ejecución la instalación en vivo iniciada anteriormente. 2. Utilice el token del panel correspondiente a su método de instalación para abrir el panel. 3. Si necesita un proxy, configúrelo en **Cuenta → Ajustes → Ajustes de conexión → Cambiar ruta de conexión**. 4. En **«Cuenta**», introduzca su número de teléfono y pulse **«Continuar»**, elija **«Código QR» → «Mostrar código QR**», o seleccione archivos y pulse **«Conectar cuenta**». **El «ID de API + Hash»** es opcional: el espacio de trabajo utiliza el par guardado o importado, o un par válido del conjunto integrado. Para utilizar su propia aplicación, pegue un par `API ID:API Hash` en el campo «ID de API». Para obtener una clave de autorización completa, seleccione **«Clave de autenticación»**, pegue los 512 caracteres hexadecimales y seleccione el ID de DC facilitado. El ID de usuario es opcional y se marca si se introduce. 5. Complete el método de inicio de sesión que haya seleccionado: teléfono/código/autenticación de dos factores (2FA), confirmación desde una aplicación de Telegram en la que haya iniciado sesión para el código QR, o una importación de sesión autorizada compatible. 6. Compruebe el ID de cuenta que se muestra. **Fuentes** abiertas: sus chats se cargan automáticamente; añada sus grupos. 7. En **«Elija qué cambios desea conservar**», seleccione las categorías de eventos o la opción predefinida **«Mensajes, ediciones y eliminaciones**» y, a continuación, guarde la configuración de supervisión. 8. Seleccione la configuración de los archivos adjuntos por separado y, a continuación, pulse **«Iniciar observación**». Las credenciales de la API identifican su aplicación; por sí solas, no autorizan una cuenta. Los grupos privados no necesitan un nombre de usuario público, pero su cuenta debe tener acceso. Para cuentas existentes, consulte [cuentas y formatos de sesión](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/): el panel acepta StringSession de Telethon, SQLite de Telethon/Pyrogram, ZIP de TData de una sola cuenta y archivos JSON de cuenta compatibles. Seleccione una sesión y su JSON complementario juntos, y pulse **Conectar cuenta**. El inicio de sesión por QR también está disponible con los mismos ajustes opcionales de API. No se admiten TDLib, sesiones de bots ni inventarios de cuentas en CSV/JSON. Para varias cuentas, use **Cuentas → Importar cuentas** y seleccione sus archivos de sesión compatibles. Los archivos JSON complementarios se emparejan por su nombre base; cada cuenta importada obtiene su propio espacio de trabajo. Consulte [importación masiva y grupos de cuentas](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/#bulk-import-and-account-groups). Para añadir otra cuenta, pulse **+** junto al selector de cuentas o abra **Cuenta → Ajustes → Ajustes de conexión → Espacios de trabajo**, o utilice **Cuentas**. Los espacios de trabajo tienen sesiones, registros, claves, fuentes y colas independientes. Al cambiar de vista, los demás recopiladores siguen en funcionamiento. En esta instalación, no es posible asignar la misma cuenta de Telegram a dos espacios de trabajo. No hay un número fijo de espacios de trabajo; estos comparten un único proceso, por lo que la capacidad depende del equipo. El token del panel en tiempo real protege el acceso a sus autorizaciones de Telegram y al material guardado; es independiente de las credenciales de la API de Telegram. Solo una demostración local iniciada explícitamente y a la que se acceda directamente obtiene acceso automático. Una demostración remota o a través de un proxy sigue utilizando `data/demo/panel-token.txt`. ## Revisión y exportación - **Registro:** busque y filtre las observaciones por fuente y tipo de evento. - Seleccione un evento para examinar su registro original, su atribución y las versiones guardadas. - Los detalles de la edición muestran el contenido disponible antes y después. Los detalles de la eliminación muestran el último contenido capturado, si lo hubiera; un actor desconocido sigue sin identificarse. - **Formatos de exportación:** ZIP firmado, JSONL, CSV y HTML sin conexión. - **Exportación completa del chat** (Fuentes → Exportación completa del chat): descargue todo el historial visible de un chat como un paquete firmado con `chat.json` (estilo de exportación de Telegram) y un archivo legible `chat.html`. Los chats privados funcionan cuando la cuenta es miembro. Se trata de una instantánea actual, no de una reconstrucción de mensajes eliminados o editados previamente. Verifique una copia con `python verify.py chat-export.zip --fingerprint TRUSTED_SHA256`. - **Punto de control:** mantenga los límites del registro firmado fuera del recopilador. - **Descargar el recibo de ejecución firmado:** conserve el registro del programa y la versión del recopilador. - **Preparar una solicitud de marca de tiempo:** prepare una solicitud fuera de línea dirigida a una autoridad de marcas de tiempo; siga las instrucciones de [TIMESTAMP.md](https://phishdestroy.github.io/TgWitness/es/docs/reference/timestamp/) para obtener y verificar una respuesta. - **Verificar el registro:** compruebe las firmas de los eventos y los eslabones de la cadena. La exportación en formato ZIP también comprueba los archivos multimedia. Los navegadores compatibles guardan exportaciones de gran tamaño directamente en el archivo elegido. Otros navegadores almacenan en el búfer un máximo de 128 MiB. Mientras el servidor está en funcionamiento, la CLI de transmisión admite descargas de mayor tamaño sin necesidad de almacenar en el búfer la respuesta completa: ``` python -m tgwitness.download --token-file data/live/panel-token.txt --out evidence.zip ``` Para otro espacio de trabajo, añada `--profile ID` mediante **«Exportaciones» → «ID del espacio de trabajo**». Para un servidor remoto, añada `--url https://your-server`. El límite de transferencia predeterminado es de 5 GiB; `--max-mib` lo modifica. El contenido ZIP firmado tiene un límite de verificación independiente de 4 GiB sin comprimir por defecto (**Parameters** lo aumenta; verifique dichos archivos con `verify.py --max-gib N`). Verifique el archivo utilizando una copia fiable del verificador y una huella digital o punto de control de la clave conservada de forma independiente. ## Consulte la instalación ``` python start.py --setup-only python start.py --check python start.py --check --json ``` `--check` comprueba las dependencias locales, la compatibilidad con la firma, el almacenamiento, la configuración de claves y la dirección de escucha. No instala nada ni se conecta a Telegram. Si un puerto está ocupado, puede significar que hay otra instancia en ejecución. Utilice un `--port` diferente o deténgala primero. El lanzador se instala en `.venv`. Los comandos auxiliares de `python -m tgwitness...` deben utilizar `.venv\Scripts\python.exe` en Windows o `.venv/bin/python` en Linux/macOS, a menos que dicho entorno ya esté activado. ## Sesiones, protección y funcionamiento Un archivo `.session` de Telethon SQLite cerrado y coherente puede convertirse localmente con `python -m tgwitness.sessions account.session --out account.tgwitness-session` y, a continuación, cargarse en la cuenta. También están disponibles la importación directa de archivos y el inicio de sesión mediante código QR. Consulte [CONNECTION-SECURITY.md](https://phishdestroy.github.io/TgWitness/es/docs/reference/connection/) para conocer los formatos de inicio de sesión, SOCKS5, HTTP CONNECT, MTProxy y las claves maestras externas. **La función «Pausar observación»** detiene la recopilación. La opción **«Bloquear»** solo cierra el acceso al navegador. Al cerrar una pestaña, el proceso de recopilación sigue en ejecución. Detener el proceso interrumpe la recopilación; una instantánea del historial no puede reconstruir todas las modificaciones o eliminaciones que se hayan perdido. Consulte [cómo funciona la recopilación](https://phishdestroy.github.io/TgWitness/es/docs/reference/collection/) en relación con las políticas de eventos, las colas de archivos adjuntos, el aislamiento de cuentas y el comportamiento al reiniciar. Las sesiones y los secretos están cifrados. El contenido de los mensajes, los archivos multimedia y las exportaciones requieren un disco o volumen cifrado. Las firmas garantizan la integridad en relación con una clave de confianza; no confirman el origen en Telegram ni impiden la falsificación por parte de un operador que controle el recopilador y su clave. Consulte [el archivo OPERATIONS.md](https://phishdestroy.github.io/TgWitness/es/docs/reference/operations/) para obtener información sobre copias de seguridad y restauración, [DEPLOYMENT.md](https://phishdestroy.github.io/TgWitness/es/docs/reference/deployment/) para el alojamiento, y [deploy/](https://github.com/phishdestroy/TgWitness/blob/main/deploy/README.md) para ver ejemplos de uso del servicio. El panel instalado también incluye una guía de configuración sin conexión en `/guide.html`. La verificación real y las limitaciones existentes se recogen en [los archivos VERIFICATION.md](https://phishdestroy.github.io/TgWitness/es/docs/reference/verification/) y [READINESS.md](https://github.com/phishdestroy/TgWitness/blob/main/docs/internal/READINESS.md). --- # Instalación, verificación y actualización Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reference/installation/ Instálala con un solo comando, comprueba las firmas y los hash, actualízala y desinstálala. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Translation coverage: this edition includes material from the English original. Instálala con un solo comando, comprueba las firmas y los hash, actualízala y desinstálala. [TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [Documentación](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) · [Primeros pasos](https://phishdestroy.github.io/TgWitness/es/docs/reference/quickstart/) ![Primeros pasos](https://phishdestroy.github.io/TgWitness/assets/chapter-start.svg) [Proyecto](https://github.com/phishdestroy/TgWitness/blob/main/README.md) · [Inicio rápido](https://phishdestroy.github.io/TgWitness/es/docs/reference/quickstart/) · [Implementación](https://phishdestroy.github.io/TgWitness/es/docs/reference/deployment/) **En esta página** - [Instalación con un solo comando](https://phishdestroy.github.io/TgWitness/es/docs/reference/installation/#install-with-one-command) - [Donde todo funciona](https://phishdestroy.github.io/TgWitness/es/docs/reference/installation/#where-everything-runs) - [Configuración de la búsqueda de texto completo](https://phishdestroy.github.io/TgWitness/es/docs/reference/installation/#full-text-search-settings) - [Acceso desde la línea de comandos](https://phishdestroy.github.io/TgWitness/es/docs/reference/installation/#command-line-access) - [Verificar antes de ejecutar](https://phishdestroy.github.io/TgWitness/es/docs/reference/installation/#verify-before-running) - [Actualizar una instalación existente](https://phishdestroy.github.io/TgWitness/es/docs/reference/installation/#update-an-existing-installation) - [Comandos habituales en Ubuntu](https://phishdestroy.github.io/TgWitness/es/docs/reference/installation/#everyday-commands-on-ubuntu) - [Eliminar TgWitness](https://phishdestroy.github.io/TgWitness/es/docs/reference/installation/#remove-tgwitness) ## Se instala con un solo comando El instalador guiado incluye un entorno de ejecución privado de Python. Utiliza la misma dirección para futuras instalaciones: cada publicación actualiza conjuntamente el instalador, los hash, las firmas y la información de compilación. **Linux / macOS (Bash):** ``` curl -fsSL https://get.destroy.tools/install.sh | bash ``` En un servidor Ubuntu, ejecútalo como root para instalar un servicio en segundo plano. En un ordenador de sobremesa, ejecútalo como usuario normal. **Windows (PowerShell o Símbolo del sistema):** ``` powershell.exe -NoProfile -ExecutionPolicy Bypass -Command "irm https://get.destroy.tools/install.ps1 | iex" ``` En Windows no se necesita ningún administrador. El proceso secundario de PowerShell deja tu terminal abierto con el resultado. Python y las dependencias permanecen en la instalación. En Ubuntu, elige **«Este ordenador**», **«Enlace HTTPS temporal»** o **«Dominio propio**». El instalador muestra la dirección del panel y la clave de acceso. Para obtener un enlace temporal, abre esa dirección HTTPS en tu navegador e introduce la clave. Si tienes acceso local a un servidor remoto, utiliza un reenvío SSH desde tu ordenador (`ssh -L 8787:127.0.0.1:8787 user@server`) y abre `http://127.0.0.1:8787`. En macOS y Windows, el panel local se abre en tu navegador; mantén su terminal en ejecución. Inicia sesión en Telegram en el panel y elige qué datos quieres recopilar. La instalación por sí sola no inicia la recopilación de datos de Telegram. ## Donde todo funciona `get.destroy.tools` Es un **Cloudflare Worker que sirve descargas estáticas**. No cuenta con un panel TgWitness, ni con una sesión de Telegram, ni con una base de datos de pruebas de los usuarios. No se redirige a un VPS del proyecto. La aplicación se ejecuta en el equipo en el que se ejecuta el comando. | Instalación | Programa | Datos | | --- | --- | --- | | Ubuntu como root | `/opt/tgwitness` | Servicio del sistema: `/var/lib/tgwitness-`; utiliza `tgwitness paths` para obtener la ruta exacta. | | Usuario de Linux / macOS | `~/.local/share/tgwitness` | `data/live` en esa instalación. | | Usuario de Windows | `%LOCALAPPDATA%\TgWitness` | `data\live` en esa instalación. | Selecciona `TGWITNESS_INSTALL_DIR` para elegir otra carpeta. Las versiones instaladas y los datos están separados. El instalador no sube tus cuentas, mensajes ni claves al sitio de descarga. Si eliges un túnel de Cloudflare, el tráfico del panel se envía a través de Cloudflare; si utilizas tu propio dominio, se redirige a tu propio servidor. With `TGWITNESS_TRUSTED_PROXIES`, the panel accepts a single `X-Forwarded-Proto: https` from a trusted proxy to set Secure download cookies. Cada instalación incluye los archivos **START-HERE.html** y **START-HERE.txt**, con rutas locales, comandos y enlaces al repositorio. Ejecuta `tgwitness guide` para abrir la guía. En Windows, utiliza `& "$env:LOCALAPPDATA\TgWitness\bin\tgwitness.cmd" guide` en PowerShell. ## Configuración de la búsqueda de texto completo [La búsqueda de texto completo](https://phishdestroy.github.io/TgWitness/es/docs/reference/search/) (vista previa) no requiere configuración. Su índice se crea en segundo plano tras una actualización. | Variable o comando | Efecto | | --- | --- | | `TGWITNESS_FULLTEXT=disk` | Por defecto: el índice se guarda en `search/fulltext.sqlite3` de cada espacio de trabajo | | `TGWITNESS_FULLTEXT=memory` | No hay archivo de índice; el índice se reconstruye cada vez que se inicia el programa. | | `TGWITNESS_FULLTEXT=off` | Sin índice; solo búsqueda de texto exacto. | | `tgwitness index status` | Estado del índice de cada espacio de trabajo | | `tgwitness stop`, `tgwitness index rebuild`, `tgwitness start` | Recompilar todos los índices a partir del diario firmado. | La selección del administrador en **Diario → Filtros → Índice de búsqueda** anula la variable para ese espacio de trabajo. Los comandos buscan el directorio de datos de la instalación en la que se ejecutan; en los demás casos, añade `--data-dir` la ruta de `tgwitness paths`. Para obtener un diccionario completo de ucraniano (datos bajo licencia GPL-3.0), instala `pymorphy3-dicts-uk` en el entorno de Python de la instalación. ## Acceso mediante la línea de comandos La [línea de](https://phishdestroy.github.io/TgWitness/es/docs/reference/cli/) [comandos](https://phishdestroy.github.io/TgWitness/es/docs/reference/cli/) (vista previa) lee el archivo en busca de scripts y agentes. | Variable | Efecto | | --- | --- | | `TGWITNESS_URL` | Dirección del panel para `tgwitness search`, `context`, `messages`, `stats` y `export`; por defecto `http://127.0.0.1:8787` cuando se establece un token | | `TGWITNESS_MCP_TOKEN` | Archivar el token de conexión desde **Integraciones → MCP**, compartido con los clientes de MCP; `--token-file` en su lugar, lo lee de un archivo | | `TGWITNESS_DATA` | El directorio de datos se lee directamente cuando no `--data-dir`se especifique una URL o un token. | ## Comprueba antes de ejecutar El comando de una sola línea confía en HTTPS para su script inicial. Dicho script comprueba SHA-256 y la firma RSA del proyecto en la aplicación y las restricciones antes de la instalación. También puedes descargar y verificar primero el script inicial. La clave de publicación pública es [release-signing.pub](https://github.com/phishdestroy/TgWitness/blob/main/deploy/installer/release-signing.pub). Su SHA-256 es: ``` 039d98a658ccda14253e45a00335b4a68d840976d8ec18b8d4355cc7c458447d ``` Conserva esta huella digital de una revisión del repositorio en la que confíes. Una suma de comprobación procedente del mismo servidor de descargas detecta cualquier discrepancia; la clave pública, cuya fiabilidad está verificada de forma independiente, es la que autentica la firma de una versión. Utiliza un directorio nuevo y vacío para las descargas de verificación que se indican a continuación. **Linux / macOS: ejecútalo en un directorio de descargas nuevo y vacío** (requiere curl y OpenSSL): ``` curl -fSLO https://get.destroy.tools/install.sh && curl -fSLO https://get.destroy.tools/install.sh.sig && curl -fSLO https://get.destroy.tools/release-signing.pub && test "$(openssl dgst -sha256 release-signing.pub | awk '{print $NF}')" = \ '039d98a658ccda14253e45a00335b4a68d840976d8ec18b8d4355cc7c458447d' && openssl dgst -sha256 -verify release-signing.pub -signature install.sh.sig install.sh && bash install.sh ``` La `&&` cadena se detiene antes de la ejecución si falla una descarga, la verificación de la huella digital de la clave o la verificación de la firma. Si se produce una publicación entre la descarga del script y su firma, se descargan ambos de nuevo. Los instaladores antiguos conservan las URL inmutables de sus paquetes. **Windows: comprueba la imagen SHA-256 antes de ejecutarlo:** ``` Invoke-WebRequest https://get.destroy.tools/install.ps1 -OutFile install.ps1 -UseBasicParsing Get-FileHash .\install.ps1 -Algorithm SHA256 Invoke-RestMethod https://get.destroy.tools/SHA256SUMS.txt ``` Compara el hash con la `install.ps1` línea. Para realizar una comprobación independiente de la firma, utiliza OpenSSL (por ejemplo, desde Git Bash) y la misma huella digital de la clave pública indicada anteriormente: ``` curl -fSLO https://get.destroy.tools/install.ps1 && curl -fSLO https://get.destroy.tools/install.ps1.sig && curl -fSLO https://get.destroy.tools/release-signing.pub && test "$(openssl dgst -sha256 release-signing.pub | awk '{print $NF}')" = \ '039d98a658ccda14253e45a00335b4a68d840976d8ec18b8d4355cc7c458447d' && openssl dgst -sha256 -verify release-signing.pub -signature install.ps1.sig install.ps1 && powershell.exe -NoProfile -ExecutionPolicy Bypass -File install.ps1 ``` La propia instalación de Windows verifica las firmas de los paquetes con .NET y no requiere OpenSSL. Se trata de firmas independientes RSA-3072 / SHA-256, no de Authenticode. El [manifiesto](https://get.destroy.tools/manifest.json) registra la versión del software, el commit exacto de Git, el ID de lanzamiento inmutable y el SHA-256 de cada artefacto. La página enlaza con el código fuente correspondiente. El manifiesto y la lista de sumas de comprobación también tienen firmas independientes (`manifest.json.sig` y `SHA256SUMS.txt.sig`). ## Actualizar una instalación existente **Una nueva publicación actualiza el sitio de descargas; los programas instalados se actualizan cuando se vuelve a ejecutar el instalador.** No hay ningún actualizador automático ni reinicio automático de una colección en ejecución. El canal actual del instalador es **«preview»**; sigue las compilaciones publicadas y comprobadas de `main`, cuyo commit puede ser más reciente que la última versión numerada de GitHub. La versión de la página procede de `pyproject.toml`; su commit y el ID de la compilación distinguen las actualizaciones dentro de la misma versión de vista previa. La publicación es automática una vez que esa confirmación concreta supera las comprobaciones de aplicación y seguridad, y el paquete firmado supera las pruebas de servicio de Ubuntu y de instalación en Windows PowerShell. Mientras se ejecutan las comprobaciones, o si estas fallan, los mismos comandos continúan instalando la compilación comprobada anteriormente. El manifiesto de la compilación muestra qué confirmación está disponible actualmente; es posible que el número de versión por sí solo se mantenga igual entre las actualizaciones de vista previa. Utiliza la misma carpeta de instalación y el mismo usuario del sistema operativo que antes. Haz una copia de seguridad del directorio de datos completo con la recopilación detenida; `tgwitness paths` lo identifica. Una exportación firmada no es una copia de seguridad completa de la instalación. **Instalación como root en Ubuntu en `/opt/tgwitness`:** ``` curl -fsSL https://get.destroy.tools/install.sh | TGWITNESS_INSTALL_DIR=/opt/tgwitness bash -s -- --no-start ``` Tras una instalación correcta: ``` /opt/tgwitness/bin/tgwitness restart /opt/tgwitness/bin/tgwitness status /opt/tgwitness/bin/tgwitness open ``` Para la instalación en Linux o macOS, utiliza la ruta original `TGWITNESS_INSTALL_DIR` o la configuración predeterminada y vuelve a ejecutar el primer comando de instalación. Cierra el panel en primer plano antes de actualizar y vuelve a iniciarlo después. Para un servicio de usuario de Linux ya configurado, ejecuta su `tgwitness restart` comando. **Windows:** cierra el panel en ejecución, vuelve a ejecutar el comando de instalación de Windows y, a continuación, abre `bin\tgwitness.cmd` en la misma instalación. El instalador conserva los datos, las sesiones, la configuración de acceso y las claves de firma. Solo cambia el lanzador después de que el nuevo entorno supere las comprobaciones; si la instalación falla, se mantiene el lanzador anterior. Conserva la copia de seguridad previa a la actualización por si se producen cambios en el formato de almacenamiento. ## Comandos habituales en Ubuntu | Comando | Resultado | | --- | --- | | `tgwitness open` | URL actual del panel y clave de acceso. | | `tgwitness paths` | Rutas exactas de programas, datos y guías. | | `tgwitness guide --print` | Instrucciones de funcionamiento sin conexión. | | `tgwitness status` / `tgwitness logs` | Disponibilidad / registros del servicio. | | `tgwitness stop` / `tgwitness start` | Detener o reanudar el servicio; conservar los datos. | | `tgwitness token rotate` | Sustituye la clave de administrador y cierra las sesiones del navegador. | | `tgwitness tunnel off` | Desactiva el túnel rápido público; mantén el panel local. | | `tgwitness tunnel on` / `tgwitness tunnel restart` | Crea un enlace de túnel rápido o sustituye su dirección. | Consulta la sección [«Acceso»](https://phishdestroy.github.io/TgWitness/es/docs/reference/access/) para obtener información sobre tokens de compañeros, sesiones y restricciones de IP, y la sección [«Publicación del instalador»](https://github.com/phishdestroy/TgWitness/blob/main/deploy/installer/README.md#automatic-publication-from-github) para conocer el flujo de trabajo de lanzamiento de GitHub a Cloudflare. ## Eliminar TgWitness No hay desinstalador: basta con cerrar el panel y eliminar sus carpetas. Al eliminar la carpeta de datos se destruyen definitivamente los diarios, las claves de firma, las sesiones de Telegram y los archivos guardados. Antes de eso: 1. Exporta lo que necesites (**Exportaciones → Descargar ZIP firmado**) y guarda la huella digital de la clave de firma y los puntos de control fuera de este equipo. Para conservar el propio espacio de trabajo, copia toda la carpeta de datos con la recopilación detenida. 2. Elimina los servidores creados en **Extras → Servidor 24/7** desde **«Tus servidores»** o con `python -m tgwitness.cloud destroy`; el proveedor los factura hasta que se eliminen. 3. Cierra la sesión de cada cuenta en Telegram en **Ajustes → Dispositivos**. Borrar los archivos no supone cerrar la sesión por parte de Telegram. **Instalación como root en Ubuntu.** Toma nota de la carpeta de datos, detén el servicio y, a continuación, elimina el servicio, las carpetas y el acceso directo: ``` /opt/tgwitness/bin/tgwitness paths /opt/tgwitness/bin/tgwitness stop systemctl list-unit-files 'tgwitness-*' systemctl disable tgwitness- rm /etc/systemd/system/tgwitness-.service systemctl daemon-reload rm -rf /opt/tgwitness /var/lib/tgwitness- /usr/local/bin/tgwitness ``` **Instalación para usuarios de Linux o macOS.** Cierra el panel. Un servicio de usuario de Linux configurado se detiene con `systemctl --user disable --now tgwitness-`; su unidad se encuentra en `~/.config/systemd/user/`. A continuación, elimina `~/.local/share/tgwitness` (o tu `TGWITNESS_INSTALL_DIR`) y el `~/.local/bin/tgwitness` acceso directo. **Windows.** Cierra el panel y elimina `%LOCALAPPDATA%\TgWitness` (o tu `TGWITNESS_INSTALL_DIR`). El instalador no añade ningún servicio, tarea programada ni acceso directo. --- # Telegram · Primera configuración y ajustes Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reference/settings/ El asistente de configuración, los objetivos, los niveles de interfaz, las rutas de conexión y los ajustes compartidos por un grupo de cuentas. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) El asistente de configuración, los objetivos, los niveles de interfaz, las rutas de conexión y los ajustes compartidos por un grupo de cuentas. [TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [Documentación](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) · [Primeros pasos](https://phishdestroy.github.io/TgWitness/es/docs/reference/quickstart/) ![Primeros pasos](https://phishdestroy.github.io/TgWitness/assets/chapter-start.svg) [Cuentas](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/) · [Conexión](https://phishdestroy.github.io/TgWitness/es/docs/reference/connection/) · [Acceso](https://phishdestroy.github.io/TgWitness/es/docs/reference/access/) Se abre un nuevo espacio de trabajo `/first-run`: idioma y hora, nivel de interfaz, objetivo, conexión, Telegram y chats. Cada respuesta se guarda en el servidor tan pronto como cambia, por lo que al recargar la página se continúa en el mismo paso. La última pantalla muestra una lista de las respuestas y te permite volver a cualquiera de ellas. El idioma, la zona horaria de la IANA, el tema y el nivel se almacenan por operador y por espacio de trabajo. Los valores predeterminados son el idioma del navegador, la zona horaria del dispositivo, el tema del sistema y la interfaz sencilla. Al cambiar el idioma, se mantiene la sesión del panel. Las horas que aparecen en el registro firmado nunca cambian. `/settings` Edita los mismos registros que el asistente. La búsqueda abarca los campos principales, los parámetros y los formularios ampliados; se puede abrir un campo oculto sin cambiar el nivel. Los niveles solo modifican lo que se muestra: el servidor comprueba los permisos por sí mismo. La configuración de la colección y la primera conexión son competencia del administrador del espacio de trabajo. | Nivel | Campos | Barra lateral | | --- | --- | --- | | Sencillo | Solo lo imprescindible | Inicio, Chats, Cambios, Archivos, Ajustes | | Estándar | Configuraciones comunes con explicaciones | Se añaden Case Board, Cuentas y Acceso | | Experto | Todos los campos, límites y detalles técnicos | Añade «Fuentes», «Extras», «Preguntar al archivo», «Parámetros», «Cuenta», «Registro del sistema» e «Integraciones». | [La guía de paneles](https://phishdestroy.github.io/TgWitness/es/docs/reference/panel/) describe cada sección. ## Objetivos | Objetivo | Colección | Archivos | Servicios externos | Dirección del servidor | | --- | --- | --- | --- | --- | | Copia de archivo | Desactivado; **«Start»** ejecuta una exportación | Fotos de hasta 20 MB | Desactivado | Automático | | Seguir chats | Continuo | Fotos y vídeos de hasta 60 segundos / 20 MB | Marcas de tiempo y notificaciones de problemas | Automático | | Pruebas | Continuo | Todos los archivos de hasta 1 GB | Marcas de tiempo, drand, notificaciones | No, ocultarlo | Se recomienda utilizar la copia externa, el bot «witness» y la comprobación de código como pruebas. Las direcciones de almacenamiento y notificación necesitan primero un destino. Una función que se comunica con un servicio externo solicita permiso para permitir solicitudes fuera de Telegram; al desactivarla, se ofrece la opción de desactivar también las marcas de tiempo, las notificaciones y la copia externa. Al modificar el objetivo, se muestra primero la diferencia, y los cambios manuales se pueden conservar. Un campo que difiera del objetivo se marca **como «Modificado por ti»** y se puede restaurar. La revisión de la configuración evita que una diferencia revisada se aplique sobre un cambio realizado en otra pestaña. ## Conexión **Automatic** prueba primero los servidores públicos MTProxy, luego WARP y, por último, una conexión directa, esta última solo cuando se pueda mostrar la dirección del servidor. Automatic y WARP pueden instalar componentes con verificación de hash y registrar el servidor en Cloudflare. WARP utiliza el gestor wgcf/wireproxy existente y un puerto SOCKS5 local; la tabla de enrutamiento del sistema no se modifica. Cuando se necesitan servicios externos, Automatic da prioridad a WARP frente a MTProxy. Tu propio proxy acepta `tg://proxy`, `socks5://`, `http://` y `https://`. El certificado de un proxy HTTPS se comprueba antes de enviarle las credenciales. Una comprobación de conexión tiene una validez de cinco minutos y está vinculada a la ruta, la política y las respuestas del asistente; si se modifica cualquiera de estos elementos, es necesario realizar una nueva comprobación. Existe la opción de **«Continuar sin comprobar»**, que no sustituye al inicio de sesión en Telegram. La ruta elegida se vuelve a comprobar en segundo plano, y «Automático» vuelve a ejecutar su cadena tras una pérdida de conexión. Cuando ningún proxy público responde, el contador se vuelve rojo y se activan las acciones de WARP y recomprobación. ## Grupos de cuentas Las cuentas de un grupo comparten su configuración. Abre **Cuentas → Grupos y configuración compartida → Configuración compartida**, o **Configuración del grupo** en la página de configuración de una cuenta. El grupo comparte el objetivo, los archivos guardados, las marcas de tiempo, el drand, las notificaciones de problemas, la copia externa, las solicitudes fuera de Telegram, el modo IP, qué registrar, el calendario de revisiones, las reglas de notificación, la configuración de informes, los parámetros y la ruta de conexión. Los destinos de las notificaciones, las credenciales del proxy y el inicio de sesión son específicos de cada cuenta, al igual que el inicio y la pausa de la recopilación. - Todos los miembros siguen el grupo. En «Configuración» se establece un valor 🔗 **del grupo** o ✏️ **un valor propio**; al seleccionar **«Volver al valor del grupo»** se restablece el valor original. - Un cambio enumera las cuentas a las que afecta (**se aplica a 2 de 3 cuentas**) y pregunta por cuenta antes de sustituir un valor propio. Las cuentas sin marcar conservan el suyo. - Un parámetro que el grupo no comparte permanece en **«No compartido»: cada cuenta conserva su propio valor** hasta que pulses **«Compartir este valor**». - **Al copiar la configuración de una cuenta,** los valores de la cuenta seleccionada pasan a ser los del grupo. - A una cuenta que se traslada a un grupo se le pregunta: **«¿Aplicar los valores del grupo?».** De lo contrario, conserva sus propios valores, marcados con ✏️. Las cuentas añadidas posteriormente comienzan con los valores del grupo. - Una cuenta de observación mantiene su modo IP hasta que se pone en pausa. Cada cambio queda registrado en el diario firmado del espacio de trabajo principal y de cada miembro al que llega. Al eliminar un grupo, se conservan sus cuentas y sus valores actuales. La página del grupo `/groups/` muestra a los miembros, lo que requiere atención y los chats que ven varias cuentas. Véase [«Grupos de cuentas](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/#bulk-import-and-account-groups)». ## Espacios de trabajo existentes Un espacio de trabajo con una sesión o una configuración anterior ya completada no muestra el asistente. Sus valores no se sustituyen por un objetivo cuando se carga la página. Ocultar un campo no desactiva la función ni elimina su valor. La estimación de tamaño y tiempo se basa en hasta tres chats seleccionados y hasta 20 mensajes de cada uno. Se trata de una estimación: no tiene en cuenta los límites de Telegram, la velocidad de un servidor concreto ni los archivos de cada chat. --- # Telegram · Formatos de cuentas y sesiones Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/ Inicie sesión mediante teléfono, código QR o clave de autenticación, importe sesiones de Telethon, Pyrogram o Telegram Desktop, y gestione varias cuentas. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Inicie sesión mediante teléfono, código QR o clave de autenticación, importe sesiones de Telethon, Pyrogram o Telegram Desktop, y gestione varias cuentas. [TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [Documentación](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) · [Primeros pasos](https://phishdestroy.github.io/TgWitness/es/docs/reference/quickstart/) ![Primeros pasos](https://phishdestroy.github.io/TgWitness/assets/chapter-start.svg) TgWitness inicia sesión como una **cuenta de usuario de Telegram** (no como un bot) a través de MTProto, utilizando Telethon. Cada cuenta se encuentra en su propio **espacio de trabajo** (denominado *«workspace*» en la API y en las herramientas de línea de comandos) con su propia sesión, fuentes, registro y clave de firma. Los archivos de sesión, las cadenas de sesión y las claves de autenticación son **autorizaciones de cuenta**: quienquiera que las posea puede actuar en nombre de dicha cuenta. No contienen el historial de mensajes. > [!ADVERTENCIA] **No utilice nada que no pueda permitirse perder.** Le recomendamos encarecidamente que no conecte cuentas personales o de otro tipo que sean valiosas, ni que cree un ID de API o un hash de API en una cuenta que considere importante. No se trata de que TgWitness no haya sido probado: Telegram restringe y bloquea de forma permanente cuentas de manera impredecible —por volúmenes de solicitudes que considera excesivos—, independientemente del cliente o la finalidad, y sin documentación adecuada. Muchos bloqueos son irreversibles. Utilice cuentas específicas para este fin. El buen funcionamiento de las pruebas depende de Telegram, no del software, y no garantiza nada para el futuro. - [De un vistazo](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/#at-a-glance) - [Antes de empezar: ID de la API y hash de la API](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/#before-you-start-api-id-and-api-hash) - [Número de teléfono](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/#phone-number) · [Código QR](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/#qr-code) · [Clave de autenticación + ID de DC](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/#auth-key--dc-id) - [Archivos de cuentas](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/#account-files): [Telethon .session](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/#telethon-session) · [Pyrogram .session](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/#pyrogram-session) · [Par «sesión + JSON»](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/#session--json-pair) · [TData](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/#telegram-desktop-tdata) · [StringSession](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/#telethon-stringsession) · [Fichero JSON de la cuenta](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/#account-json) - [Identifique lo que tiene](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/#identify-what-you-have) · [Formatos no compatibles](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/#unsupported-formats) - [Cuentas múltiples](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/#multiple-accounts) · [Mantener a salvo los archivos de las cuentas](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/#keeping-account-files-safe) · [Solución de problemas](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/#troubleshooting) ## De un vistazo | Lo que tiene | Pestaña **«Añadir cuenta»** | También necesitará | | --- | --- | --- | | El número de teléfono y el acceso a sus códigos de inicio de sesión | **Teléfono** | Contraseña de 2FA, si está activada | | Telegram abierto en otro dispositivo | **Código QR** | Contraseña de 2FA, si está activada | | Un archivo `.session` (Telethon o Pyrogram) | **Archivos** | Archivo JSON complementario opcional para la configuración de la aplicación | | `.session` + `.json` con el mismo nombre | **Archivos** (seleccione ambos) | Por lo general, nada más | | Una carpeta «`tdata`» en Telegram Desktop | **Archivos** (en formato ZIP) | El código de acceso local de la versión de escritorio, en caso de que se haya configurado uno | | Una sesión de cadenas de Telethon (texto, `.txt`, `.tgwitness-session`) | **Archivos** | No se requiere un par de API independiente | | Un `.json` con una sesión o una clave de autenticación | **Archivos** | No se requiere un par de API independiente | | Una clave de autenticación (512 caracteres hexadecimales) y su número DC | **Clave de autenticación** | ID de usuario opcional | TgWitness reconoce los archivos por su **contenido**, no por su nombre. Al cambiar el nombre de un archivo, este nunca se convierte. ## Antes de empezar: ID de la API y hash de la API Puedes iniciar sesión sin crear una aplicación de la API de Telegram. Cuando no se introduce ningún par, ni se importa ni está ya guardado en el espacio de trabajo, TgWitness elige un par de su conjunto integrado de pares de API pública 50 (`tgwitness/api_pool.py`), dando preferencia a Telegram Desktop para un nuevo inicio de sesión y conservando primero un par guardado; los candidatos restantes se barajan. Si Telegram rechaza un par (`API_ID_INVALID`, `API_ID_PUBLISHED_FLOOD`, `UPDATE_APP_TO_LOGIN`), se prueba el siguiente, hasta un máximo de ocho por inicio de sesión; los pares rechazados se omiten hasta el reinicio. El par con el que se ha iniciado sesión se guarda con la cuenta y se reutiliza para ella. Un ID de API **,** y un hash de API **,** identifican la aplicación ante Telegram; estos no autorizan una cuenta por sí mismos. Los campos de conexión que faltan utilizan un par determinista de dispositivo/sistema operativo de los catálogos [opentele2 2.0.0](https://github.com/DedInc/opentele2/tree/7e973bc71cd7a714ad13ac703c0895a90d36a735) incluidos: Ordenador de sobremesa `2040`, Android `6`, Android X `21724`, iOS `10840`, macOS `2834` y Web `2496`. El ID de compilación del código fuente de Android `4` también utiliza el catálogo de Android, tal y como se identifica en [BuildVars de Telegram para Android](https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/src/main/java/org/telegram/messenger/BuildVars.java). Web utiliza A por defecto; un sufijo de versión de aplicación `K` importado o un paquete de idioma `macos` selecciona K, y la versión `0.7.0` selecciona Webogram. Los ID de aplicación desconocidos mantienen los valores predeterminados del servidor de Telethon. Los campos importados siempre tienen prioridad, incluyendo una versión anterior de la aplicación y un paquete de idioma vacío. El catálogo nunca cambia el ID/hash de la API. Su instantánea de versión se revisa explícitamente, no se recupera durante el inicio de sesión. Un perfil guardado permanece estable tras las actualizaciones. `account.getAuthorizations` informa de los metadatos de autorización guardados por Telegram; no es un reflejo de cada nuevo `initConnection`. Compáralo con el perfil realmente enviado. Conectar una autorización existente no valida su hash de API asociado: `initConnection` envía el ID de la API, mientras que el hash se utiliza en las solicitudes de inicio de sesión. Tras una nueva autorización mediante teléfono o código QR, TgWitness solicita la configuración, el centro de datos más cercano, el estado de conexión, los idiomas (cuando el paquete de idiomas no está vacío), las actualizaciones de la aplicación y las actualizaciones de las condiciones de servicio, con un intervalo de 0.3–1.5 segundos entre solicitudes. La actualización del estado marca brevemente la cuenta como conectada. Esta secuencia se ejecuta una vez al completar el inicio de sesión, no en importaciones, reconexiones ni reinicios. La autorización se guarda en primer lugar; una solicitud fallida detiene la secuencia sin reintentar ni descartar el inicio de sesión. Los resultados se registran como `account.initialized`, con nombres de error en lugar de cuerpos de respuesta. La secuencia no es una garantía contra las restricciones de la cuenta. Para `tdesktop` , si falta `tz_offset` , se utiliza la diferencia horaria local del servidor con respecto al UTC, redondeada a 900 segundos mediante el algoritmo [opentele2](https://github.com/DedInc/opentele2/blob/7e973bc71cd7a714ad13ac703c0895a90d36a735/crates/opentele2-core/src/fingerprint.rs) (MIT; licencia en `tgwitness/client_profiles.LICENSE` ). Se actualiza en cada conexión para que se reflejen los cambios por el horario de verano. Un `tz_offset` importado tiene prioridad en todas las plataformas y se conserva exactamente, incluido el cero. Se conservan las demás entradas `initConnection.params` . El formulario de inicio de sesión HTTP acepta la zona horaria numérica devuelta por la importación de archivos; se rechazan los valores booleanos, las fracciones y las diferencias horarias fuera del rango admitido. Las rutas directas, SOCKS5 y HTTP CONNECT utilizan el `ConnectionTcpObfuscated` de Telethon (MTProto abreviado y ofuscado). HTTPS CONNECT mantiene el TLS hasta el proxy y utiliza el mismo transporte ofuscado dentro del túnel. MTProxy mantiene su transporte intermedio aleatorio obligatorio y la gestión de secretos. Los cambios de ruta aplican las mismas opciones. La ofuscación modifica la estructura de los paquetes; no oculta la cuenta ni los metadatos de su cliente a Telegram, ni implica inmunidad frente a las restricciones. Tras conectarse un cliente autorizado, TgWitness comprueba la configuración, el centro de datos más cercano, la autorización actual, la línea de base de la capa revisada, los idiomas, las actualizaciones de la aplicación y las actualizaciones de las condiciones de servicio. Estos diagnósticos se ejecutan una vez por cada instancia de cliente, antes de la recopilación, y se muestran en los detalles de la conexión junto con su hora. `account.connection_checked` registra el resultado sin hash de sesión, direcciones IP, tokens ni hash de API. Nunca acepta condiciones ni instala actualizaciones. Un fallo en la solicitud o un FloodWait detiene las solicitudes posteriores; un resultado que falte permanece desconocido. Las comprobaciones locales pueden seguir informando de sus resultados, mientras que las comprobaciones de red se omiten. Los diagnósticos de FloodWait conservan el método TL fallido, cualquier envoltorio Takeout/rango, la espera solicitada por el servidor y el plazo efectivo en `telegram.backoff`. Los detalles de la conexión muestran el método y el plazo mientras las solicitudes están en pausa. El diagnóstico incluye contadores de llamadas de cliente por método desde que se creó dicho cliente; cuentan por separado la resolución de pares anidados, pero no cuentan los paquetes ni los intentos de reintento internos de Telethon. Los contadores actuales también están disponibles como `collector.rpc_activity` en la API de estado. No se incluyen argumentos de solicitud, nombres de usuario, hashes de acceso ni texto de excepción. El último diagnóstico y el plazo completo se conservan tras el reinicio. Las esperas anteriores sin un registro de método no pueden atribuirse retrospectivamente. Consulte [: límites de exportación](https://github.com/phishdestroy/TgWitness/blob/main/docs/EXPORT-LIMITS.md) para la revisión del código fuente y la distinción entre descubrimiento y adquisición del historial. `official_app=True` o `False` es el indicador de autorización actual de Telegram. Ninguno de estos valores determina si la cuenta está restringida, es de confianza o se encuentra bajo observación. Las instantáneas `account.devices` existentes en modo de pruebas siguen constituyendo el historial de todos los dispositivos que han iniciado sesión; los diagnósticos de conexión solo conservan la descripción del dispositivo actual. Antes de la conexión, las comprobaciones de asesoramiento comparan la plataforma API, el paquete de idioma, los formatos de dispositivo/sistema operativo y versión de la aplicación, la configuración regional del sistema móvil y la capa de esquema real de Telethon con la línea de base del catálogo revisado. Las advertencias aparecen en el registro del servidor y en los metadatos del estado de la cuenta; nunca sustituyen los valores importados ni modifican la capa de esquema. Una capa diferente es una señal de revisión de compatibilidad, no una prueba de que la cuenta esté inactiva o restringida. Estas comprobaciones y el código `official_app` no certifican que Telegram considere que la cuenta está a salvo de restricciones. El estado de cuenta desconectada utiliza el perfil guardado en lugar de generar otra descripción del dispositivo. Para utilizar en su lugar su propia aplicación (la cuenta que la registre es la que corre riesgo; véase [«¿Por qué un conjunto de API integrado?](https://github.com/phishdestroy/TgWitness/blob/main/docs/PROJECT-GUIDE.md#connect-a-telegram-account)»): 1. Abra [my.telegram.org](https://my.telegram.org) e inicie sesión con cualquier número de teléfono del que disponga. El código le llegará a la aplicación de Telegram, no por SMS. 2. Seleccione **herramientas de desarrollo de API**. 3. Cree una aplicación: cualquier título y nombre abreviado (de 5 a 32 letras), plataforma: **ordenador de sobremesa**. La URL y la descripción pueden dejarse en blanco. 4. Copie **el «api_id» de la aplicación** (un número) y **el «api_hash» de la aplicación** (32 caracteres hexadecimales). En el panel, **«API ID + Hash»** aparece debajo del formulario de inicio de sesión. Puede pegar un único par `api_id:api_hash` en **el campo «API ID»** y ambos campos se rellenarán automáticamente. Un mismo par puede utilizarse para todas sus cuentas. Tras iniciar sesión con éxito, se guarda, cifrado, únicamente en ese espacio de trabajo y nunca se reenvía al navegador. Intervienen tres tipos de credenciales diferentes: | Secreto | Abrir | Dónde se encuentra | | --- | --- | --- | | Token de panel | El panel web de TgWitness | `panel-token.txt` en el directorio de datos, o `TGWITNESS_TOKEN` | | ID de la API + hash | No aporta nada por sí solo; identifica la aplicación | Emparejamiento integrado, configuración importada o su propia aplicación en my.telegram.org | | Autorización de la cuenta | La cuenta de Telegram | Se crea mediante inicio de sesión por teléfono o código QR, o bien se importa como una sesión. | Si es necesario acceder a Telegram a través de un proxy, configúrelo primero en **Cuenta → Ajustes → Ajustes de conexión → Cambiar ruta de conexión**. ## Número de teléfono 1. Abra **la cuenta**, vaya a la pestaña **«Teléfono**» e introduzca el número en formato internacional, por ejemplo, `+44 7700 900123`. Los espacios y los guiones se eliminan automáticamente. 2. Pulse **«Continuar**». Los campos «API ID» y «Hash» pueden dejarse en blanco. 3. Introduzca el código que envía Telegram (normalmente a la aplicación de Telegram; no se garantiza su recepción por SMS). 4. Si la cuenta dispone de verificación en dos pasos, introduzca esa contraseña. No se trata del token del panel ni del código de acceso del dispositivo. 5. Compruebe el ID de la cuenta que aparece tras iniciar sesión y, a continuación, seleccione las fuentes. Los códigos de inicio de sesión y la contraseña de autenticación de dos factores (2FA) nunca se guardan en el disco. ## Código QR Utilice esta opción cuando la cuenta ya haya iniciado sesión en un teléfono u otro ordenador. 1. Pestaña **«Código QR»** → **Mostrar código QR**. Los campos «ID de API» y «Hash» pueden dejarse en blanco. 2. En el dispositivo en el que ha iniciado sesión: **Ajustes → Dispositivos → Vincular dispositivo de escritorio**, escanee el código y confirme. 3. Introduzca la contraseña de 2FA en TgWitness si Telegram se la solicita. La imagen del código QR se genera localmente. Los códigos caducan; pulse **«Generar otro código QR»** para volver a intentarlo. Al bloquear el panel, cambiar de espacio de trabajo o iniciar otro inicio de sesión se cancela un código pendiente. ## Clave de autenticación + ID de DC Una clave de autorización (Auth Key) es la autorización sin procesar de 256 bytes que subyace a cada sesión de Telegram, escrita como **512 caracteres hexadecimales**, junto con el número del centro de datos **DC 1–5**. 1. Pestaña **«Clave de autenticación**». Pegue la clave completa; una clave abreviada que contenga «`…`» no funcionará. 2. Seleccione el DC ID proporcionado junto con la clave. 3. Si lo desea, introduzca el **ID de usuario**. En ese caso, TgWitness rechazará la conexión si Telegram detecta una cuenta diferente. 4. **Cuenta de** Press **Connect**. Una clave de autenticación (512 caracteres) no es un hash de API (32 caracteres). La misma clave también puede importarse como JSON; consulte [«JSON de la cuenta](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/#account-json)». ## Archivos de cuentas Abra **«Añadir cuenta» → «Archivos»** y seleccione hasta **cuatro archivos pertenecientes a una misma cuenta**, con un tamaño total de **8 MiB**; a continuación, pulse **«Conectar cuenta**». Los formularios **Archivos**, **Clave de autenticación** y de importación masiva muestran la advertencia de sesión paralela antes de conectarse. Por defecto, las autorizaciones importadas se reutilizan. Mantén el cliente original cerrado mientras su clave se esté utilizando aquí. **Archivos** y **Clave de autenticación** también ofrecen **Crear una autorización independiente**, descrita más adelante. La importación masiva sigue utilizando el modo directo. El inicio de sesión por teléfono y mediante QR interactivo crea autorizaciones independientes. El encabezado de la advertencia permanece visible en el formulario de importación; su explicación completa se abre automáticamente cuando se proporcionan archivos o una cadena de clave/sesión. Se puede ocultar tras leerla, de modo que el selector de archivos y los controles de conexión sigan siendo utilizables en un teléfono. - Los archivos se convierten **en memoria** en su servidor de TgWitness. Las subidas no se almacenan, los archivos ZIP no se extraen al disco y no se establece contacto con ningún servicio externo. - A continuación, la sesión resultante se comprueba con Telegram. Si un archivo indica un ID de usuario, debe coincidir con la cuenta que Telegram indica. - Se rechazan los archivos que describen diferentes cuentas o diferentes credenciales de API en lugar de seleccionar una sola. - El campo **«Código de acceso o texto de sesión»** contiene el campo de código de acceso local de TData, un cuadro en el que se puede pegar una StringSession y **leer archivos sin iniciar sesión** (se rellena el formulario sin conectarse a Telegram). ### Crear una autorización independiente Selecciona **Crear una autorización independiente** antes de conectar archivos importados o una clave de autorización. TgWitness conecta brevemente al donante importado, lo utiliza para aprobar el token de inicio de sesión QR del nuevo cliente y desconecta al donante inmediatamente después de la aprobación. El nuevo cliente tiene su propia clave de autorización y un perfil de escritorio seleccionado por separado. Las credenciales de la API y el perfil del dispositivo proporcionados por el donante se utilizan únicamente para la conexión del donante. No se cierra sesión ni se revoca ninguna autorización existente. **Mantén el cliente original del donante completamente cerrado durante este paso.** La conexión inicial sigue utilizando su clave copiada, por lo que este modo no puede eliminar ese riesgo inicial de uso paralelo. Una vez conectada la nueva autorización, el propietario puede reabrir el cliente original y utilizar ambos de forma independiente. El inicio de sesión interactivo **mediante código QR** permite que el cliente original apruebe el inicio de sesión sin copiar ni conectar su clave aquí. Si Telegram solicita 2FA, este modo utiliza `twoFA` del JSON seleccionado cuando esté presente, o solicita la contraseña. Si se rechaza una contraseña importada, se vuelve al formulario de contraseña. Las contraseñas no se guardan. La clave candidata se guarda cifrada en el `independent_login.enc`, incluidos los cambios durante la migración del centro de datos. Tras una interrupción, selecciona el mismo donante y esta opción para reanudar la clave candidata guardada. El espacio de trabajo permanece reservado para esa cuenta; si la finalización falla, no se elimina el nuevo espacio de trabajo. Conserva su directorio de datos y la clave de la bóveda. Las credenciales finales y el registro del diario de `account.authorized` incluyen el método de importación, los formatos de entrada y el ID de la API del donante, sin la clave ni la contraseña del donante. El 5 de noviembre de 2026, una cuenta dedicada superó las comprobaciones en tiempo real con los donantes de Telethon, Pyrogram y TData: finalización de la autenticación de 2 factores (2FA), nuevas claves de autorización distintas, acceso simultáneo por parte del donante y del nuevo cliente, y lectura de un canal público. El caso de Telethon también reanudó un candidato guardado tras una interrupción en el paso de la contraseña. Cada nueva autorización completó las seis solicitudes de inicialización posteriores al inicio de sesión, y su registro firmado se verificó. La sesión original siguió siendo utilizable en los cuatro formatos proporcionados. La base de datos de errores [RPC de Telegram](https://core.telegram.org/api/errors.json) asocia `FRESH_CHANGE_ADMINS_FORBIDDEN` al cambio de administradores, `FRESH_CHANGE_PHONE_FORBIDDEN` al cambio de número de teléfono y `FRESH_RESET_AUTHORISATION_FORBIDDEN` a la revocación de otras sesiones, el cambio de su duración o el registro de una clave de acceso. `SESSION_TOO_FRESH_*` y `PASSWORD_TOO_FRESH_*` se refieren a transferencias de titularidad y retiradas de ingresos o regalos. No se trata de operaciones de recopilación; un nuevo inicio de sesión no implica una prohibición general de lectura de 24 horas. La exportación puede devolver `TAKEOUT_INIT_DELAY_*` por separado. TgWitness conserva las pausas solicitadas por el servidor y no reintenta la aceptación de tokens automáticamente ni revoca sesiones para eludir restricciones. ### Telethon `.session` | | | | --- | --- | | En qué consiste | La base de datos SQLite que crean las herramientas basadas en Telethon, por ejemplo, `my_account.session` | | Reconocida por | Tablas `sessions` (junto con `dc_id`, `server_address`, `port`, `auth_key`) y `version` = 7 u 8 | | Requisitos | Exactamente una fila de sesión autorizada; una base de datos cerrada y completa. | Cierre primero el programa que creó el archivo. Si `my_account.session-journal` o `my_account.session-wal` aparecen junto a él, la base de datos no está finalizada: abra y cierre el cliente original correctamente. La eliminación de esos archivos «sidecar» puede dejar una copia dañada. ### Pyrogram `.session` | | | | --- | --- | | En qué consiste | Las herramientas basadas en Pyrogram crean una base de datos SQLite | | Reconocida por | Tabla `sessions` con `dc_id`, `auth_key`, `test_mode`, `user_id`, `is_bot`; `version` = 2 o 3 | | Requisitos | Una sesión **de usuario** autorizada en la red de producción. Se rechazan las sesiones de bots y de centros de datos de prueba. | El identificador de usuario almacenado se compara con el de Telegram durante el inicio de sesión. ### Par «sesión + JSON» Las cuentas suelen distribuirse en dos archivos con el mismo nombre, por ejemplo, « `447700900123.session`» y «`447700900123.json`». Seleccione **ambos** a la vez. - A partir del JSON, TgWitness utiliza `app_id`/`api_id` y `app_hash`/`api_hash`, por lo que normalmente no es necesario introducir credenciales de la API. - El perfil de conexión utiliza `device_model` (alias `device`), `system_version` (alias `sdk`), `app_version`, `lang_code`, `system_lang_code` (alias `system_lang_pack`), `lang_pack` y `tz_offset` opcional (segundos respecto a UTC, de -43200 a 50400). Los campos proporcionados tienen prioridad sobre los valores predeterminados generados y el idioma del panel o del navegador . Se rechazan los alias conflictivos. El perfil resuelto se guarda en las credenciales cifradas del espacio de trabajo y se reutiliza tras el reinicio, incluida la versión de la aplicación. - `phone`, la configuración del proxy y los tokens de dispositivo se **ignoran**. `twoFA` es de solo lectura cuando se selecciona **Crear una autorización independiente**; la importación directa lo ignora. - Un JSON sin un campo de autorización compatible es solo metadatos. Añade su archivo de sesión o continúa con el inicio de sesión mediante teléfono o código QR. Un JSON que contenga una sesión compatible o una clave de autenticación puede autorizar por sí solo; consulta [Account JSON](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/#account-json). ### Telegram Desktop (TData) TData es la carpeta «`tdata`» de la aplicación Telegram Desktop (la aplicación multiplataforma de desktop.telegram.org). | Sistema | Ubicación predeterminada: `tdata` | | --- | --- | | Windows | `%APPDATA%\Telegram Desktop\tdata` (Telegram portátil: junto a `Telegram.exe`) | | Linux | `~/.local/share/TelegramDesktop/tdata` | | macOS | `~/Library/Application Support/Telegram Desktop/tdata` | Para importarlo: > **Advertencia de sesión paralela.** La importación directa de TData reutiliza la clave de autorización de Telegram Desktop. No utilices esa clave en Desktop y TgWitness simultáneamente. Telegram puede invalidar la autorización con `AUTH_KEY_DUPLICATED`, dejando ambas copias inutilizables hasta que se realice un nuevo inicio de sesión. > > > > Cierra completamente Desktop, incluido su proceso en la bandeja del sistema, y mantén esa copia cerrada mientras TgWitness utiliza la sesión importada. **Cierra la aplicación, no cierres la sesión ni revocas la sesión:** la revocación también invalida la copia importada. Si necesitas que ambos clientes estén en ejecución, selecciona **Crear una autorización independiente** y mantén Desktop cerrado hasta que el nuevo inicio de sesión se realice con éxito, o inicia sesión en TgWitness mediante teléfono o código QR. Se recomienda utilizar una cuenta dedicada, pero esto no garantiza que las claves clonadas sean seguras para su uso en paralelo. > > > > Esto también se aplica a los `.session` , al texto de StringSession y a la clave de autenticación en formato HEX. Otros clientes con sus propias autorizaciones creadas de forma independiente pueden permanecer conectados. Consulte [la documentación de Telegram sobre AUTH_KEY_DUPLICATED](https://core.telegram.org/api/errors#406-not-acceptable). 1. Cierre completamente Telegram Desktop. 2. Cree un archivo ZIP que contenga **únicamente** estos dos elementos de `tdata`: - `key_datas` - el archivo de 16 caracteres que termina en «`s`» situado junto a él, normalmente «`D877F783D5D3EF8Cs`» Al comprimir toda la carpeta con su caché multimedia, se suelen superar los límites (512 entradas, 32 MiB descomprimidos). 3. Seleccione el archivo ZIP en **«Archivos**». Si Telegram Desktop tiene un **código de acceso local**, introdúzcalo primero en el campo **«Código de acceso» o «Texto de sesión**». No se trata de la contraseña de la autenticación de dos factores (2FA). Compatible con: una cuenta por archivo, almacenamiento moderno `key_datas`/`key_data0`/`key_data1`, código de acceso local. No compatible con: carpetas con varias cuentas conectadas, diseños antiguos de la versión de escritorio, archivos ZIP protegidos con contraseña y la aplicación nativa independiente de macOS «Telegram para macOS». ### Telethon StringSession Una sola línea de texto, que suele comenzar por «`1`» y tiene una longitud aproximada de 350 caracteres. Cárguela como un archivo «`.txt`» o «`.tgwitness-session`» (de un máximo de 4 KiB), o pégela en el campo **«Código de acceso» o «Texto de sesión**». Solo se aceptan cadenas de Telethon; las cadenas de Pyrogram y TDLib utilizan formatos diferentes. ### Fichero JSON de la cuenta Un objeto JSON, de un máximo de **64 KiB**, en un archivo con extensión «**`.json`**». | Campo (alias) | Significado | | --- | --- | | `api_id` (`app_id`) | ID de la aplicación, un número positivo | | `api_hash` (`app_hash`) | Hash de la aplicación, 32 caracteres hexadecimales | | `string_session` (`session_string`, `session_str`; `session` heredado) | Texto de «StringSession» de Telethon, no es un nombre de archivo | | `auth_key` (`auth_key_hex`) + `dc_id` | Clave de autenticación completa de 512 caracteres y DC 1–5 | | `user_id` (`id`) | Opcional; se comprueba con Telegram antes de guardar la autorización. | | `device_model` (`device`) | Descripción del dispositivo de conexión | | `system_version` (`sdk`) | Versión del sistema operativo de conexión | | `app_version` | Versión de la aplicación enviada a Telegram | | `lang_code`, `system_lang_code` (`system_lang_pack`), `lang_pack` | Idioma del cliente, idioma del sistema y paquete de idioma del cliente; se permite un valor `lang_pack` vacío. | | `tz_offset` | Desfase opcional respecto al UTC en segundos, enviado en `initConnection.params`; número entero o cadena de números enteros decimales | Si aparecen tanto un alias como el nombre principal, deben coincidir. Los campos explícitos de sesión de Telethon tienen prioridad sobre un blob genérico `session` en otro formato. Si ambos contienen sesiones de Telethon reconocibles, deben describir la misma autorización. A falta de un campo explícito, `session` debe ser una StringSession válida de Telethon. Ejemplos: ``` { "app_id": 1234567, "app_hash": "0123456789abcdef0123456789abcdef" } ``` ``` { "api_id": 1234567, "api_hash": "0123456789abcdef0123456789abcdef", "auth_key": "REPLACE_WITH_ALL_512_HEXADECIMAL_CHARACTERS", "dc_id": 2, "user_id": 123456789 } ``` En el primer ejemplo solo se rellenan las credenciales de la API; inicie sesión mediante teléfono o código QR, o añada un archivo de sesión. No se aceptan listas masivas (una matriz JSON de cuentas). ## Identifique lo que tiene | Como puede ver | Se trata de | Uso | | --- | --- | --- | | `*.session`; al abrirlo en un editor de texto, aparece `SQLite format 3` en la parte superior | Telethon o Pyrogram SQLite | **Archivos** (detectados automáticamente) | | Una carpeta «`tdata`» que contiene «`key_datas`» | Telegram Desktop TData | Comprima los dos archivos en un ZIP y, a continuación, **«Archivos»** | | Una línea de texto que comienza por `1`, ~350 caracteres | Telethon StringSession | **Archivos** | | `*.json` con `app_id`/`app_hash` | Metadatos complementarios | **Archivos**, junto con su sesión | | `*.json` con `auth_key` o `string_session` | Fichero JSON de la cuenta | **Archivos** | | 512 caracteres `0-9a-f` | Clave de autenticación | **Clave de autenticación** | | 32 caracteres `0-9a-f` | Hash de la API | **ID de la API + Hash** | | `td.binlog` o un `db.sqlite` procedente de una aplicación de TDLib | Almacenamiento TDLib | No compatible | | `123456789:AA…` | Token del bot | No compatible | ## Formatos no compatibles | Formato | Alternativa | | --- | --- | | Almacenamiento de TDLib (`td.binlog`) y exportaciones de TDLib | Inicie sesión mediante el teléfono o un código QR | | **Cadenas** de sesión de Pyrogram | Utilice el archivo Pyrogram `.session`, o el código QR/teléfono | | TData con varias cuentas registradas | Cierre la sesión en las demás cuentas de Telegram Desktop o utilice el archivo de sesión propio de cada cuenta | | Tokens de bot | No compatible: TgWitness actúa como una cuenta de usuario | | Listas en formato CSV/JSON de numerosas cuentas | Importe archivos de sesión compatibles mediante **Cuentas → Importar cuentas**, o inicie sesión por teléfono/QR en espacios de trabajo separados | | Sesiones de prueba en DC o con bots | Utilice una cuenta de usuario de producción | ## Cuentas múltiples Pulse **+** junto al selector de cuentas, o bien abra **Cuenta → Ajustes → Ajustes de conexión → Espacios de trabajo**, introduzca una etiqueta y inicie sesión. - Cualquier número de espacios de trabajo, incluido el principal. Cada uno cuenta con su propia sesión, ruta de proxy, fuentes, política de captura, registro, clave de firma, puntos de control y exportaciones. - Cambiar el espacio de trabajo que se muestra no detiene los demás. - Un registro permanece vinculado a la cuenta que lo creó. Para iniciar sesión con una cuenta diferente se requiere otro espacio de trabajo, y una misma cuenta no puede asignarse a dos espacios de trabajo. - El token del panel principal controla todos los espacios de trabajo. [El acceso concedido](https://phishdestroy.github.io/TgWitness/es/docs/reference/access/) puede limitar el acceso de otras personas a cuentas y chats seleccionados, con permisos y límites de sesión independientes. - **La función «Cuentas»** cambia el nombre de un espacio de trabajo y elimina uno añadido, junto con su sesión, su registro, sus fuentes y su clave de firma. El espacio de trabajo principal no se puede eliminar desde el panel. ### Importación masiva y grupos de cuentas Utiliza **Cuentas → Importar cuentas** para añadir varias cuentas, emparejar archivos por nombre base y ver el resultado de cada inicio de sesión. Cada cuenta dispone de su propio espacio de trabajo. Un grupo agrupa cuentas relacionadas sin fusionar sus sesiones, claves ni pruebas. Al hacer clic en **«Grupo abierto»** en **«Cuentas»** se accede a su página en `/groups/`: - **Cuentas:** ruta de conexión, observación y último mensaje de cada miembro, con las opciones «Iniciar**todo»** y **«Pausar todo**». - **Requiere atención:** cuentas en las que se ha cerrado sesión, que no están disponibles o que presentan un problema de conexión, recepción, fuente o multimedia; cada nombre lleva a su ficha. - **En los chats de varias cuentas se pueden ver:** las fuentes compartidas, las cuentas que las observan y las interrupciones en el periodo de observación del espacio de trabajo disponible (hasta siete días). **La exportación con N cuentas** divide la exportación de un canal o supergrupo entre ellas y firma un único archivo. - **Exportar grupo:** una imagen ZIP con la exportación firmada de cada cuenta en `accounts/` y `manifest.json` enumerando sus SHA-256 y huellas digitales de las claves, firmadas por el espacio de trabajo principal en `manifest.signature.json`. Verifica cada archivo de cuenta por separado con `python -m tgwitness.verify` y la huella digital de confianza de esa cuenta. Los miembros comparten la configuración del grupo; cada cuenta puede mantener sus propios valores. Consulta [la configuración compartida](https://phishdestroy.github.io/TgWitness/es/docs/reference/settings/#account-groups), [la guía de importación y grupos](https://github.com/phishdestroy/TgWitness/blob/main/docs/wiki/Accounts.md#import-accounts-and-share-settings) y [el panel de control del grupo MTProxy](https://github.com/phishdestroy/TgWitness/blob/main/docs/wiki/Proxies.md#pool-dashboard-and-custom-sources). ## Cerrar sesión **Cuenta → Cerrar sesión en Telegram** (con la observación en pausa) solicita a Telegram que finalice la sesión, por lo que también desaparece de **Ajustes → Dispositivos** de la cuenta y elimina la sesión del almacén del espacio de trabajo. El registro, las fuentes, los ajustes y la clave de firma permanecen, y el registro recoge el cierre de sesión. El espacio de trabajo sigue perteneciendo a su cuenta: solo esa cuenta puede volver a conectarse a él. Si Telegram no responde, la sesión se elimina igualmente aquí y el panel lo indica; finalícela en Telegram en **Ajustes → Dispositivos**. ## Mantener a salvo los archivos de las cuentas - Trate cada `.session`, TData ZIP, StringSession, clave de autenticación y JSON de cuenta como si fuera una contraseña. TgWitness guarda la autorización importada en su almacén cifrado; puede eliminar los archivos originales posteriormente. - No ejecute la misma autorización en dos programas a la vez. Telegram podría revocarla (`AUTH_KEY_DUPLICATED`), y ambas copias dejarían de funcionar. - Una sesión caducada o revocada no puede reactivarse mediante conversión. Vuelva a iniciar sesión. ## Solución de problemas | Mensaje o síntoma | Qué hacer | | --- | --- | | *No se puede leer esta sesión. Cierre su cliente original…* | El archivo SQLite está abierto o sin terminar (sidecar `-journal`/`-wal`). Cierre correctamente el programa original y vuelva a copiar el archivo. | | *Esquemas SQLite de Telethon compatibles: 7 y 8* / *Pyrogram … 2 y 3* | El archivo se ha creado con una versión muy antigua o desconocida de la biblioteca. Inicie sesión mediante teléfono o código QR en su lugar. | | *Solo se admiten sesiones de usuario autorizadas en entorno de producción.* | El archivo Pyrogram pertenece a un bot o a la red de pruebas. | | *El archivo TData supera las 512 entradas o los 32 MiB* | Solo los archivos ZIP «`key_datas`» y «`D877F783D5D3EF8Cs`», no toda la carpeta. | | *No se puede descifrar TData. Compruebe el código de acceso local del ordenador de sobremesa.* | Introduzca el código de acceso local de Telegram Desktop en el campo **«Código de acceso» o «Texto de sesión**». | | *Importe una cuenta de TData cada vez* | Telegram Desktop contaba con varias cuentas; véase [«Formatos no compatibles](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/#unsupported-formats)». | | *Los archivos seleccionados describen diferentes cuentas o credenciales de API.* | Seleccione archivos de una sola cuenta. | | *El archivo JSON no contiene credenciales ni autorizaciones compatibles con la API.* | Compruebe los nombres de los campos en el archivo [JSON de la cuenta](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/#account-json). | | *Únicamente metadatos de la API* | El archivo JSON no contiene ninguna sesión. Añada el archivo «`.session`» o utilice el teléfono o el código QR. | | *La clave de autenticación HEX debe contener los 512 caracteres hexadecimales completos* | La clave está truncada o contiene «`…`». | | El ID de la cuenta no coincide con el de la cuenta importada | El ID de usuario del archivo difiere del que indica Telegram; el archivo corresponde a otra cuenta. | | La cuenta ya pertenece a otro espacio de trabajo | Abra ese espacio de trabajo en lugar de añadir la cuenta dos veces. | | Está conectado, pero falta un grupo privado en la lista de chats de **«Fuentes».** | Compruebe la pertenencia al servicio. El selector examina los primeros 1.000 diálogos; aumente el límite en **«Parámetros**». | | Error en la conexión mediante proxy | Comprueba la ruta y el modo IP. El modo automático MTProxy prueba otra entrada que funcione. La opción «Ocultar la dirección» espera; el modo «Directo», como último recurso, puede conectarse directamente tras el retraso configurado. Consulta [los modos de enrutamiento](https://phishdestroy.github.io/TgWitness/es/docs/reference/connection/#ip-modes). | Véase también: [conexión y seguridad](https://phishdestroy.github.io/TgWitness/es/docs/reference/connection/) para proxies y cifrado, y [cómo funciona la recopilación](https://phishdestroy.github.io/TgWitness/es/docs/reference/collection/) de los datos capturados tras iniciar sesión. --- # Telegram · Acceso y permisos Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reference/access/ Configure el acceso a cuentas y chats, seleccione los permisos, limite las sesiones y las direcciones IP, y revoque el acceso. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Translation coverage: this edition includes material from the English original. Configure el acceso a cuentas y chats, seleccione los permisos, limite las sesiones y las direcciones IP, y revoque el acceso. [TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [Documentación](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) · [Primeros pasos](https://phishdestroy.github.io/TgWitness/es/docs/reference/quickstart/) ![Primeros pasos](https://phishdestroy.github.io/TgWitness/assets/chapter-start.svg) Conceda a un revisor acceso a un chat, a un analista permiso para exportar un caso o a un operador el control de cuentas seleccionadas. Cada persona dispone de su propio token. El token del panel principal lo conserva el administrador. [Configuración de la cuenta](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/) · [Rutas de conexión](https://phishdestroy.github.io/TgWitness/es/docs/reference/connection/) · [Modelo de seguridad](https://phishdestroy.github.io/TgWitness/es/docs/reference/security/) ## Dos ámbitos de aplicación, dos funciones distintas **El ámbito de recopilación** determina qué registra una cuenta: chats seleccionados, una carpeta de Telegram o la cuenta completa. **El ámbito de acceso** determina cuáles de esas cuentas y chats registrados puede ver y utilizar otra persona. Conceder acceso no implica unirse a un chat de Telegram, iniciar la recopilación ni otorgar permisos de la cuenta de Telegram. Un acceso puede abrir espacios de trabajo seleccionados, chats seleccionados dentro de ellos, todos los espacios de trabajo o todas las cuentas de un [grupo de cuentas](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/#bulk-import-and-account-groups). **Todos los espacios de trabajo, incluidos los que se añadan posteriormente**, también abarcan las cuentas futuras. Un acceso de grupo también abarca las cuentas que se añadan a ese grupo más adelante. Selecciona los espacios de trabajo de forma explícita cuando un caso deba limitarse a ellos. ## Conceder acceso a alguien 1. Inicie sesión como administrador principal y abra **«Acceso**». 2. En **«Conceder acceso a alguien**», introduzca un nombre que pueda reconocer en el registro. 3. Seleccione los espacios de trabajo y, cuando sea necesario, los chats individuales. 4. Seleccione lo que esta persona puede hacer. La opción **«Ver»** siempre está incluida. 5. Configure la fecha de caducidad, los límites de inicio de sesión y de duración de la sesión, así como las direcciones permitidas, según sea necesario. 6. Pulse **«Crear acceso**». Copie el token ahora: solo se muestra una vez. 7. Envíe la dirección del panel y el token de forma privada. El destinatario introduce dicho token en la página de inicio de sesión habitual; no necesita su token principal del panel ni una sesión de Telegram. Abra el panel con el token generado en una sesión de navegador independiente y compruebe los chats visibles y las acciones permitidas antes de entregarlo. Access names remain in encrypted local storage and are resolved by the administrator's panel. Names are omitted from new access and workspace-creation audit records; existing signed records keep their original fields. ## Seleccione los permisos Para una demostración pública solo de texto, utilice **la «Galería pública»** en lugar del acceso habitual para revisores. Muestra canales públicos seleccionados explícitamente, ediciones y eliminaciones conservadas, y estadísticas firmadas, con los campos de autor ocultos y los archivos cerrados en el límite de la API. [Cree y verifique una galería](https://phishdestroy.github.io/TgWitness/es/docs/reference/showcase/). | Autorización | Qué permite | | --- | --- | | `view` | Lea los chats autorizados, los mensajes capturados, los perfiles, los archivos y los registros filtrados del diario. Siempre incluidos. | | `export` | Se permite la exportación del historial de chat y de los expedientes. Las exportaciones de pruebas de todo el espacio de trabajo requieren acceso a dicho espacio en su totalidad. | | `sources` | Gestione fuentes, instantáneas y capturas de perfiles. El acceso limitado a los chats solo puede actuar sobre los chats permitidos; la detección de fuentes en toda la cuenta y la configuración del ámbito de aplicación permanecen inactivas. | | `collect` | Iniciar o detener un recopilador. Requiere acceso a todo el espacio de trabajo, ya que la recopilación afecta a la cuenta. | | `interact` | Realice las interacciones compatibles con Telegram dentro del ámbito de acceso. El acceso limitado al chat no permite utilizar la vista previa de enlaces en toda la cuenta. | | `settings` | Modifique la configuración de la recopilación, las marcas de tiempo, las notificaciones, las copias externas y los parámetros. Requiere acceso a todo el espacio de trabajo. | | `account` | Inicie o cierre sesión en Telegram y gestione las rutas de conexión. Requiere acceso a todo el espacio de trabajo. | | `board.read` | Lee las notas del «Case Board» únicamente dentro del espacio de trabajo y los chats permitidos. | | `board.write` | Añade marcadores, resaltados, fragmentos, comentarios y estados de apertura/revisión. También requiere «`board.read`». | | `board.manage` | Gestiona las recopilaciones, los estados finales de los equipos y las fichas de otros participantes. También requiere permisos de lectura y escritura en el tablero. | Only the main administrator can download the off-site replica recovery key. Delegated `settings` or `account` access does not grant that key. Los permisos y el alcance se comprueban conjuntamente. Marcar un permiso no abre otros chats ni desbloquea una operación a nivel de espacio de trabajo para un acceso limitado a un chat. Para una exportación paralela, el acceso debe abarcar el chat exportado en todas las cuentas seleccionadas. Un acceso concedido no puede crear nuevos accesos, gestionar las sesiones de otras personas ni abrir la consola de administrador. ### Tres configuraciones útiles | Persona | Ámbito de aplicación | Permisos | | --- | --- | --- | | Revisor | Chats grabados de un caso concreto | `view` | | Analista que prepara un traspaso de funciones | Los chats que se deben investigar y exportar | `view`, `export`; añada `interact` únicamente si deben actuar a través de Telegram | | Operador de recopilación | Espacios de trabajo completos seleccionados | `view`, `sources`, `collect`; añada `settings` o `account` únicamente cuando sea necesario | Los ajustes preestablecidos iniciales del formulario de Access también incluyen el Tablero de casos: el revisor puede leer, el analista puede leer y escribir, y el operador puede gestionarlo. Los ajustes preestablecidos siguen siendo editables y los permisos existentes no se amplían automáticamente. Consulte [el Tablero de casos](https://phishdestroy.github.io/TgWitness/es/docs/reference/case-board/) para conocer los ámbitos de chat heredados y la privacidad de las exportaciones. ## Límites y sesiones | Configuración | Cómo funciona | | --- | --- | | Sesiones paralelas | Limite el número de sesiones simultáneas a entre 1 y 100. Al alcanzar el límite, rechace el siguiente inicio de sesión o finalice la sesión más antigua. | | Se permite el inicio de sesión | Limite el número de usos correctos del token para iniciar sesiones. Las sesiones existentes no se cierran simplemente porque se haya agotado el último inicio de sesión permitido. | | Válido hasta | El acceso tiene una caducidad definitiva. Un acceso caducado no puede iniciar sesión ni seguir realizando solicitudes. | | Minutos sin actividad | Tiempo de espera por inactividad de la sesión, de 5 minutos a 30 días. Las solicitudes exitosas lo amplían; un panel abierto puede mantenerse activo mediante sondeos. | | Direcciones permitidas | Acepte direcciones IP específicas o subredes CIDR. Déjelo en blanco para permitir cualquier dirección, a menos que esté habilitada la vinculación al primer inicio de sesión. | | Vincular al primer inicio de sesión | El primer inicio de sesión correcto establece la dirección autorizada para ese acceso. | La IP es la dirección del cliente que ve la aplicación. Si se encuentra detrás de un proxy inverso o un túnel, compruebe la dirección que aparece en **«Sesiones abiertas»** antes de basarse en reglas de IP: de lo contrario, podría parecer que varios usuarios comparten la dirección del proxy. ## Modificar o retirar el acceso Edita una entrada en **«Acceso concedido»** para cambiar su ámbito, permisos o límites. Los cambios en el ámbito y los permisos se comprueban en las solicitudes posteriores, incluidas las solicitudes de sesiones que ya estén abiertas. La revocación de un acceso pone fin a sus sesiones y hace que el token emitido quede inutilizable. La opción **«Sesiones abiertas»** también permite al administrador cerrar una sesión individual sin revocar todo el acceso. Saved export copies retain their creator, workspace, chat scope and required permissions. An issued access can list or download its own copies only while those permissions still apply; copies containing Case Board also require `board.read`. The administrator can retrieve all copies. Older copies without this metadata and group bundles are administrator-only. Download tickets and prepared file responses recheck access after preparing the file, before sending its bytes. Each access, including the administrator, can hold ten pending download tickets per workspace; the workspace-wide limit is 1,000. Tickets expire after 120 seconds and are single-use. La revocación no permite recuperar archivos que alguien ya haya descargado. Cerrar sesión, bloquear el panel o finalizar una sesión no detiene un recopilador en ejecución. ## Lo que puede ver el administrador Los revisores y analistas reciben información sobre el progreso de la recopilación sin puntos finales de proxy, diagnósticos de grupo, rutas de servidor ni errores de conexión sin procesar. Los diagnósticos de conexión requieren el permiso «`account`» en todo el espacio de trabajo. La lectura de notificaciones, las copias externas y la configuración de parámetros requieren el permiso «`settings`». Las cadenas completas de User-Agent del navegador no se conservan en las sesiones de acceso. Una actualización también las elimina de la caché mutable de la sesión. El registro de procesos del panel enmascara las direcciones IP literales, las credenciales de URL y los secretos etiquetados. Los registros de servicio locales y los registros de diario firmados anteriormente no se reescriben. Las reglas de acceso y los registros de inicio de sesión firmados siguen utilizando la dirección del cliente. ### Sustituir la clave principal Utilice **Acceso → Mis límites → Reemitir clave de administrador**, o ejecute `tgwitness token rotate` desde una instalación gestionada mientras el panel está en funcionamiento. Se cierran todas las sesiones del navegador existentes, incluidas las sesiones abiertas con tokens de compañeros. El navegador solicitante recibe una nueva sesión; guarde la nueva clave de administrador antes de ocultarla. Los tokens de compañeros emitidos siguen siendo válidos hasta que se revoquen por separado. Una instalación que utilice `TGWITNESS_TOKEN` debe modificar esa configuración del entorno y reiniciarse. ### Límites de las solicitudes y del proxy The API admits up to 600 requests per minute per client and credential family: panel, archive/MCP or witness. Authentication cooldowns are separate for these families. Ten rejected authentications within a minute start an exponential cooldown, from one second up to five minutes. A failed attempt after the cooldown increases it; ten minutes without a failed attempt resets escalation. Rejections return HTTP 429 and `Retry-After`. Limits are in memory, shared across workspaces in one panel process; restart clears them. Live streams are limited to four per bearer token and 32 for the panel process. Opening a stream also consumes the API request budget. Request bodies have a 60-second receive deadline, reduced to 10 seconds for login, demo access, archive API and witness-head paths, or 8 seconds for MCP transport. Each application permits four unfinished bodies per client address, with overall limits of 32 and 64 MiB of reserved route allowances. Requests without bodies do not consume these slots. Oversized bodies return 413, timed-out bodies return 408, and exceeded client capacity returns 429 with `Retry-After: 1`. Exhausted overall body capacity returns 503 with `Retry-After`. Se ignoran los encabezados de IP reenviados a menos que el par TCP real pertenezca a `TGWITNESS_TRUSTED_PROXIES` (IP separadas por comas o CIDR). Establece `TGWITNESS_PROXY_HEADER` en `x-forwarded-for` o `cf-connecting-ip`. El XFF se recorre desde el proxy más cercano hacia el primer par no fiable. Los metadatos de direcciones de confianza malformados o duplicados se rechazan, por lo que no pueden heredar una dirección de proxy incluida en la lista de permitidos . El túnel rápido gestionado confía en el conector local de Cloudflare; la configuración de dominio propio confía en Caddy local. Las implementaciones directas no confían en ningún proxy por defecto. Si inicias Uvicorn tú mismo, desactiva su procesamiento de encabezados de proxy para que este límite reciba el par real. `TGWITNESS_PANEL_ALLOWED_IPS` restringe todo el acceso al panel, incluido el del administrador, a las direcciones IP o CIDR indicadas. La sonda de identidad de enrutamiento del instalador permanece pública y no devuelve datos de la cuenta. Incluye la ruta administrativa local requerida antes de habilitar la lista de permitidos. La guía **START-HERE** de una instalación gestionada incluye la configuración del servicio y las instrucciones de recuperación. Un selector de consulta de la API `ws` debe identificar el espacio de trabajo en la ruta de la solicitud; los selectores desconocidos, que no coinciden o que son duplicados se rechazan con un error 404. Los scripts y estilos de los paneles incluyen metadatos de integridad SHA-384. Un mapa de importación también cubre los módulos JS importados localmente en navegadores que admiten la integridad de import-map. La respuesta de lenguaje generada dinámicamente es independiente. Estas comprobaciones detectan la sustitución de activos en relación con la página entregada; no establecen confianza en un servidor comprometido que pueda sustituir tanto la página como sus hash. **El registro desde este inicio** combina los registros de proceso con la actividad del diario de cada espacio de trabajo: inicios de sesión, rechazos, cambios de ruta y acciones del operador. Se trata de una consola en memoria para el proceso actual, no de una copia permanente de cada mensaje. Los eventos de mensajes frecuentes permanecen en el diario en lugar de saturar la consola. La concesión, modificación y revocación de accesos, así como el inicio o la finalización de sesiones, también generan registros firmados en el diario `access.*`. Los tokens no se incluyen en dichos registros. Los tokens emitidos y las credenciales de sesión se conservan como hash en la bóveda cifrada. ****Administrador principal y límite de confianza**** El token del panel principal no tiene restricciones. Los inicios de sesión en el navegador con este token crean sesiones sujetas a los límites de sesión configurados por el administrador. Los scripts que envían el token principal directamente conservan acceso completo y no se contabilizan como sesiones del navegador. Se trata de un control de acceso a nivel de aplicación en una única instalación. Todos los espacios de trabajo comparten el proceso del servidor; esto no supone un aislamiento respecto al administrador del host. Mantén la privacidad del token principal, las sesiones de Telegram, las claves de firma y el directorio de datos. Un token de testigo es una credencial independiente de estado y punto de control, no un token de acceso al panel. --- # Telegram · Conexión, servidores proxy y protección de datos Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reference/connection/ Autenticación, grupos de proxies automáticos, modos de IP, política de respaldo, solicitudes externas y almacenamiento de claves secretas. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Autenticación, grupos de proxies automáticos, modos de IP, política de respaldo, solicitudes externas y almacenamiento de claves secretas. [TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [Documentación](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) · [Implementación y recuperación](https://phishdestroy.github.io/TgWitness/es/docs/reference/deployment/) ![Implementación y recuperación](https://phishdestroy.github.io/TgWitness/assets/chapter-operate.svg) Este documento describe el comportamiento de TgWitness 0.8.0 y sus limitaciones. La autenticación, el acceso a la fuente, la conectividad de red y la integridad de la captura son estados independientes. Para conocer los pasos de inicio de sesión, los formatos de archivo y la gestión de cuentas múltiples, comience por la sección [«Cuentas y formatos de sesión](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/)». Para conocer las políticas de eventos y el comportamiento ante reinicios, consulte [«Cómo funciona la recopilación](https://phishdestroy.github.io/TgWitness/es/docs/reference/collection/)». ## Configuración guiada de la conexión En «**Conexión**», el administrador puede elegir «**Esta cuenta**», «**Un grupo de cuentas**» o «**Todas las cuentas**», y a continuación seleccionar una ruta. «**Revisar selección**» muestra la lista de cuentas afectadas. «**Preparar y comprobar**» comprueba la ruta propuesta sin modificar la guardada. «**Aplicar conexión comprobada**» vuelve a comprobar, pausa la observación si es necesario, guarda la ruta y reanuda la observación que ya se estaba ejecutando. Nunca inicia la recopilación en una cuenta que haya estado inactiva anteriormente. Las descargas del historial permanecen en pausa y pueden reanudarse por separado. Pausa las exportaciones activas antes de cambiar. Los cambios en los grupos mantienen las cuentas con su propia ruta por defecto. Desactive esa opción solo cuando la vista previa muestre los cambios que desea realizar. La aplicación informa del resultado de cada cuenta; no se trata de una transacción de «todo o nada» entre bases de datos. Un cambio fallido restaura la configuración anterior de esa cuenta. Si no se puede reanudar, se muestra explícitamente. Las vistas previas caducan a los diez minutos y los cambios en la configuración de la conexión o en la pertenencia a grupos requieren una nueva comprobación. | Ruta | Qué gestiona TgWitness | | --- | --- | | Directo | Conexiones desde el servidor; no se detecta ni se impone el uso de una VPN de un servidor externo. | | VPN | Un perfil WireGuard de túnel completo por cuenta, ejecutado por un proceso SOCKS5 en el espacio de usuario local. No se instala ninguna interfaz de host ni controlador. | | Mi proxy | Credenciales SOCKS5, HTTP CONNECT o MTProxy. Se puede introducir una URL en los campos SOCKS5/HTTP. Al seleccionar varias cuentas, se comparte este proxy introducido. | | MTProto público | El grupo existente asigna rutas «Telegram». Las solicitudes externas están desactivadas hasta que se configure un proxy adecuado independiente en los ajustes avanzados. | | WARP | Un túnel local independiente para cada cuenta seleccionada, con registro en WARP y un perfil de WireGuard almacenado en el almacén de esa cuenta. | La comprobación de la ruta actual utiliza un transporte Telegram nuevo y sin autenticar, no la sesión de la cuenta. Para las rutas compatibles con HTTP, también solicita el rastreo HTTPS de Cloudflare a través de esa ruta y muestra la IP de salida, el país, el estado de WARP y la hora de la comprobación que se indican. La latencia medida es el tiempo de establecimiento de la conexión Telegram, no un ping ICMP. La preparación de WARP falla a menos que el rastreo indique que WARP está activo. Estas comprobaciones establecen la conectividad, no la autenticidad ni la integridad de los mensajes capturados. El mero hecho de que se ejecute un proceso local no constituye una comprobación de salida satisfactoria. ### WARP y WireGuard portátiles Se trata de una integración no oficial de WARP **** que utiliza [wgcf 2.3.1](https://github.com/ViRb3/wgcf/releases/tag/v2.3.1) y [wireproxy 1.1.3](https://github.com/windtf/wireproxy/releases/tag/v1.1.3). El administrador acepta explícitamente la configuración antes de la primera descarga o del registro en WARP. Esas conexiones de configuración se dirigen directamente a GitHub y Cloudflare y revelan la IP del equipo. El tráfico habitual de la cuenta mantiene su ruta existente hasta la aplicación. Cloudflare elige la dirección de salida y el país; los túneles independientes pueden compartir una dirección de salida. Esta función no ofrece selección de país, rotación periódica de IP ni un «kill switch» de VPN para todo el host. Descargas de utilidades compatibles: Linux y macOS x86-64/ARM64, y Windows x86-64. Los artefactos se comparan con los hash SHA-256 incluidos en el código fuente revisado, y los ejecutables almacenados en caché se comprueban de nuevo antes de su ejecución. No se añade ninguna herramienta auxiliar a la variable PATH, ni se instala como servicio del sistema, ni se le asigna un listener público. Todos los archivos se encuentran en el directorio `portable-routes/` del espacio de trabajo y en entradas cifradas del almacén. El listener de bucle cerrado SOCKS5 requiere credenciales generadas de forma independiente. Los perfiles privados y las credenciales de la cuenta WARP se cifran con el almacén de datos del espacio de trabajo existente. Mientras se ejecuta, el programa auxiliar necesita una configuración en texto plano de acceso exclusivo para el propietario; esta se elimina al detenerse normalmente. Un fallo del servidor puede dejar este archivo en la carpeta de datos de acceso exclusivo para el propietario. Esto no cifra el disco ni protege contra su administrador. El supervisor cierra el túnel si la tubería principal del panel desaparece. Un túnel fallido nunca habilita una solución alternativa directa. El reinicio del panel restaura un túnel seleccionado; los inicios fallidos se reintentan con un retraso limitado. **Detener el túnel** también pausa la observación y mantiene el estado de parada. **Iniciar el túnel** inicia el túnel; reanuda la observación por separado cuando esté listo. Los perfiles de WireGuard cargados deben contener una interfaz y un par, rutas IPv4 e IPv6 completas, y no deben incluir hooks, includes, sustituciones de entorno ni listeners adicionales. Las direcciones de los puntos finales públicos se resuelven y se fijan antes del inicio. Utiliza una VPN externa o una puerta de enlace SOCKS5 para OpenVPN/IPsec y puntos finales privados. ## Métodos de autenticación **El ID de API y el hash de API identifican una aplicación; no sustituyen al inicio de sesión en la cuenta.** Son opcionales en TgWitness. Orden de prioridad: primero, un par introducido en el formulario; a continuación, uno procedente de un archivo JSON de una cuenta importada; después, el par guardado en el espacio de trabajo; y, por último, el conjunto integrado de 50 pares públicos, que se prueban en orden aleatorio con rotación automática cuando Telegram rechaza uno. Solo el par de Telegram Desktop (2040) se envía con una descripción coincidente del cliente de Telegram Desktop. Su propio par, obtenido de las Herramientas de desarrollo de la API en [my.telegram.org,](https://my.telegram.org) puede utilizarse con todas sus cuentas; cada cuenta sigue teniendo su propia autorización. | Método | Requisitos | Asistencia técnica de TgWitness | | --- | --- | --- | | Teléfono, código, 2FA opcional | Acceso a la cuenta; par de API opcional | Inicio de sesión en el panel | | Clave de autenticación HEX + ID de DC | Clave completa de 512 caracteres y DC 1–5 | Pestaña **«Clave de autenticación** directa»; se comprueba el ID de usuario opcional antes de guardar la autorización. | | Telethon StringSession | Una cadena de sesión válida | Inicio de sesión en el panel | | Telethon SQLite `.session` | Texto definitivo y coherente | Importación directa de esquemas mediante panel 7/8; CLI sin conexión opcional | | Pyrogram SQLite `.session` | Sesión de usuario de producción cerrada | Importación directa de esquemas mediante el panel 2/3 | | Telegram Desktop TData ZIP | Una cuenta moderna; código de acceso local si está protegida | Conversión en memoria con comprobaciones de suma de comprobación y descifrado | | Fichero JSON de la cuenta | Campos compatibles de API/sesión/clave | Los metadatos por sí solos no bastan para completar las credenciales de la API; sigue siendo necesario iniciar sesión mediante una sesión/clave o un teléfono/código QR. | | Inicio de sesión mediante código QR | Confirmación procedente de una aplicación autorizada de Telegram | Generación local de códigos QR, caducidad/reintento, autenticación de dos factores (2FA) opcional | | TDLib / Pyrogram StringSession | Otros formatos específicos de bibliotecas | No compatible | | Token del bot | Un bot con su propio modelo de acceso y actualización | No lo utiliza este recopilador | Telegram opta por el envío de códigos; no se garantiza la entrega por SMS. Un hash de la API no puede restaurar una sesión revocada ni sustituir una contraseña de 2FA olvidada. TgWitness no almacena los códigos de inicio de sesión ni la contraseña de 2FA de Telegram en el disco. En el caso de una fuente privada, la cuenta ya debe tener acceso. No es necesario indicar el nombre de usuario del grupo. Un proxy o una importación de sesión no otorgan ni la condición de miembro ni derechos de administrador. La pertenencia actual al grupo no garantiza el acceso al historial anterior a la incorporación. ## Importar un archivo de sesión de Telethon Telethon SQLite, Pyrogram SQLite y Telegram Desktop TData utilizan formatos distintos. El panel detecta y convierte las estructuras compatibles; cambiar el nombre de un archivo no constituye una conversión. Seleccione una sesión y su archivo JSON asociado en **«Archivos**» y, a continuación, pulse **«Conectar cuenta**». Se aceptan hasta cuatro archivos coincidentes y un total de 8 MiB. Consulte [los límites de formato](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/) para obtener más detalles sobre TData/JSON. No existe la recuperación de la contraseña. El inicio de sesión mediante teléfono/autenticación de dos factores (2FA) o código QR crea una autorización independiente. La ruta opcional de la línea de comandos exclusiva para Telethon sigue estando disponible: 1. Detenga el cliente que utiliza la sesión original y realice una copia coherente. El convertidor rechaza los archivos con un WAL/registro incompleto. Cierre el cliente original correctamente en lugar de eliminar dichos archivos para eludir la comprobación. 2. Desde el entorno de TgWitness, ejecute: ``` python -m tgwitness.sessions account.session --out account.tgwitness-session ``` 1. En **«Añadir cuenta» → «Archivos»**, cargue el resultado o pegue su cadena de texto y continúe. 2. Compruebe el ID numérico de la cuenta que se muestra, seleccione las fuentes e inicie la observación. **El archivo convertido es una clave de acceso a la cuenta sin cifrar.** Guárdelo en un almacén protegido y nunca lo incorpore al control de versiones ni lo envíe a un servicio de conversión de terceros. TgWitness guarda la sesión autorizada en su almacén cifrado. Copiar una sesión no crea una autorización independiente: no ejecute clientes simultáneos con claves de autorización clonadas ni dé por sentado que las actualizaciones se entregan de forma independiente. La conversión transfiere la autorización, no los mensajes originales, la caché de la entidad ni un cursor de actualización permanente. No garantiza la recuperación de las actualizaciones tras el reinicio de los procesos. ## MTProto, Telethon y proxies MTProto es el protocolo de Telegram. Telethon es la biblioteca de cliente de Python que utiliza TgWitness. MTProxy es un proxy de transporte de Telegram; SOCKS5 y HTTP CONNECT proporcionan túneles generales. Ninguno de ellos sustituye a la autenticación de la cuenta. Guarda la ruta de cada espacio de trabajo en **Cuenta → Ajustes → Ajustes de conexión → Cambiar ruta de conexión** antes de iniciar sesión. Los nuevos espacios de trabajo utilizan por defecto la opción **Automático MTProxy · listas públicas** con **la opción Ocultar la dirección**. Los espacios de trabajo existentes que utilizaban explícitamente Direct conservan un modo que lo permite. ## Modos de IP La ruta elige la conexión. El modo IP, **la protección de IP** en la sección «Cuenta» del panel, determina cuándo puede quedar expuesta la dirección del servidor. Estos controles no instalan una VPN ni redirigen todo el tráfico del equipo. | Modo | Telegram | Solicitudes externas | | --- | --- | --- | | Ocultar la dirección (`hide`) | Utilice un proxy; espere si ninguno funciona. No hay alternativa directa. | Requiere SOCKS5/HTTP; rechaza las solicitudes que no cuenten con un proxy adecuado. | | Direct como último recurso (`fallback`) | El MTProxy automático puede utilizar la conexión directa tras el retraso configurado y, a continuación, volver a un proxy operativo. | Se prefiere un proxy externo configurado o la ruta SOCKS5/HTTP de la cuenta; en caso contrario, se permite el acceso directo. | | Servidor detrás de un túnel o una VPN (`tunnel`) | Se permiten las rutas directas y el recurso inmediato al grupo automático. | Se permite el acceso directo cuando no se ha configurado ningún proxy aplicable. | El modo «túnel» o «VPN» da por hecho que gestionas esa red por separado. Sin un túnel operativo, los destinatarios pueden ver la propia dirección del servidor. Selecciona el modo en función de tu red real, no del nombre de la opción. ### Elija una ruta | Ruta | Configuración | Límites | | --- | --- | --- | | MTProxy automático | Listas integradas o un catálogo de operadores | Mantiene una ruta de Telegram operativa; la alternativa directa depende del modo IP. | | Directo | Modo túnel o VPN | Telethon utiliza la ruta de red del anfitrión | | SOCKS5 | Servidor, puerto, nombre de usuario y contraseña (opcionales) | python-socks, DNS de destino remoto habilitado | | HTTP CONNECT | Servidor, puerto, nombre de usuario y contraseña (opcionales) | HTTP CONNECT sin cifrar; no se ha implementado el protocolo TLS con el propio proxy. | | MTProxy | Servidor, puerto, clave secreta | Transporte experimental de Telethon; 32 dígitos hexadecimales o «`dd`» + 32 dígitos hexadecimales | Se rechazan los secretos TLS falsos «`ee`». La normalización de Telethon 1.45 puede eliminar un prefijo y un dominio, pero eso no implementa el TLS falso. Pegue «`tg://proxy?server=…&port=…&secret=…`» o «`https://t.me/proxy?server=…&port=…&secret=…`» y seleccione **«Rellenar campos desde el enlace**». Esto valida y rellena los campos sin conectarse ni guardar; revise y guarde la ruta por separado. Los campos manuales siguen estando disponibles. Consulte [los enlaces de proxy de Telegram](https://core.telegram.org/api/links#proxy-links). ### Proxies públicos proporcionados por su instalación La lista integrada combina cuatro fuentes: [SoliSpirit/mtproto](https://github.com/SoliSpirit/mtproto), [zakky8/mtproto-proxy-pro](https://github.com/zakky8/mtproto-proxy-pro), [kort0881/telegram-proxy-collector](https://github.com/kort0881/telegram-proxy-collector) y [3yed-61/MTP-Collector](https://github.com/3yed-61/MTP-Collector). La instantánea incluida contiene datos de los puntos finales, la atribución de las fuentes y las fechas de descarga. La inclusión de un proveedor en la lista no constituye prueba de que el proxy funcione o de que proporcione todas las actualizaciones de Telegram. **MTProxy** comprueba **automáticamente** la conectividad de transporte de Telegram, mantiene un proxy operativo y cambia a otro cuando falla. Los espacios de trabajo prefieren diferentes proxies cuando hay suficientes entradas operativas disponibles; no se garantiza una dirección de salida única. Los proxies que fallan descansan antes de un nuevo intento. Si ninguno funciona, el modo IP determina si la recopilación debe esperar o puede utilizar una conexión directa. El cambio de proxies no modifica la cuenta ni borra su registro. Las elecciones y los cambios de ruta se registran en el registro firmado. Mientras las rutas automáticas estén activas, las listas se actualizan cada hora y las comprobaciones de transporte se ejecutan cada diez minutos de forma predeterminada. Estos intervalos son configurables. **La actualización de las listas públicas** requiere una refresco; el mero hecho de consultar la lista no modifica una ruta manual guardada. **El tráfico de Telegram y las solicitudes HTTPS utilizan rutas diferentes.** Las descargas de listas utilizan una conexión HTTPS independiente y la ruta de solicitud externa proporcionada. «`TGWITNESS_PROXY_FEED_PROXY`» anula explícitamente dicha ruta mediante un proxy HTTP/SOCKS5; ambas variantes del recopilador «Compose» la reenvían. El grupo en segundo plano sigue el espacio de trabajo principal. No se envía ninguna sesión de Telegram, credenciales de API, token de panel ni token de bot a los proveedores de fuentes. Los nombres de los proveedores, las fechas de las instantáneas y la ruta de descarga aparecen en la sección **«De dónde procede la lista**». Un MTProxy solo transporta tráfico de Telegram. Las operaciones HTTP del espacio de trabajo, como las marcas de tiempo, las notificaciones, las copias externas y las comprobaciones de origen, utilizan un proxy SOCKS5/HTTP independiente cuando está configurado, y posteriormente la ruta SOCKS5/HTTP de la cuenta. Sin ninguno de los dos, la opción «Ocultar la dirección» rechaza la solicitud; los demás modos permiten el acceso directo. Las solicitudes externas pueden desactivarse. Un proxy de descarga de feeds configurado explícitamente sigue siendo una opción de anulación independiente por parte del operador. El servicio de testigos independiente mantiene su propia ruta. Para los servicios privados gestionados por el operador, la configuración existente del entorno del servidor `TGWITNESS_ALLOW_PRIVATE_DESTINATIONS=1` permite destinos privados y mantiene la resolución del nombre de host por parte del proxy. No se puede habilitar desde el panel. El modo «solo público» rechaza los destinos .`.onion` antes de consultar el resolutor público; los servicios «onion» de Tor requieren esa configuración explícita de destino privado y un proxy adecuado. Este comportamiento del DNS se aplica a las operaciones HTTP externas, no al transporte de Telegram. Cloudflare documenta el [punto final JSON del DNS](https://developers.cloudflare.com/1.1.1.1/encryption/dns-over-https/make-api-requests/dns-json/). ****Parámetros automáticos del grupo**** En **Parámetros → MTProxy automático**, configura el umbral de fallo, el tiempo de espera, la rotación planificada, el uso compartido del proxy y el retraso de recambio permitido. | Control | Por defecto | | --- | --- | | Se desconecta antes de la sustitución | 3, en un plazo de 10 minutos | | Proxies probados por cada intento de conexión | 3 | | Primer / máximo reposo tras un fallo | 10 minutos / 6 horas | | Rotación prevista | Desactivado; activar en caso de fallo | | Cuentas por proxy | 0: dar preferencia a las entradas independientes; compartir cuando sea necesario. Establecer 1 en esperar para una entrada exclusiva. | | Retardo antes de que se permita el recurso directo | 10 minutos; Ocultar la dirección sigue sin funcionar Direct | | Comprobaciones de actualización y transporte de la fuente de datos | Actas de 60/10; los valores del espacio de trabajo principal se aplican al grupo compartido | El uso de diferentes proxies no garantiza direcciones de salida diferentes. Estos ajustes no anulan los límites de Telegram ni garantizan el anonimato. Para sustituir la lista pública por su propio catálogo de operadores, configure la sustitución que se indica a continuación. Esto desactiva por completo las suscripciones externas, incluso cuando su matriz «`proxies`» está vacía. Copie [el catálogo vacío](https://github.com/phishdestroy/TgWitness/blob/main/deploy/proxies.config.example) en `proxy-config/proxies.json` y añada sus puntos finales públicos implementados: ``` {"format": "tgwitness-proxy-catalog-v1", "proxies": [ {"id": "project-eu", "label": "Project EU", "link": "tg://proxy?server=REPLACE_HOST&port=443&secret=REPLACE_SECRET"} ]} ``` Los valores de ejemplo deben sustituirse. Se aceptan hasta 32 entradas distintas. La lista autenticada devuelve etiquetas/hosts/puertos sin secretos compartidos; al seleccionar uno, sus credenciales se guardan en el almacén de seguridad del espacio de trabajo. La disponibilidad no se comprueba hasta que se realice una prueba de transporte explícita. Un catálogo mal formado permite la configuración manual. Ejecución nativa: establezca «`TGWITNESS_PROXY_CATALOG`» como ruta JSON local. Docker: ``` docker compose -f compose.yaml -f deploy/compose/compose.proxies.yaml up -d --build ``` La superposición se monta como `proxy-config` de solo lectura; los archivos deben ser legibles por el UID 10001 del contenedor. Dicho directorio queda excluido de Git, del contexto de compilación de Docker y de los archivos fuente. Este catálogo configura las cuentas de recopilación; [el bot testigo](https://phishdestroy.github.io/TgWitness/es/docs/reference/witness/) utiliza su propia ruta HTTP/SOCKS5, no MTProxy. La alternativa directa se rige por el modo IP descrito anteriormente. Suspenda la observación antes de cambiar de ruta. Al guardar, se desconectan los clientes antiguos y se cancela el inicio de sesión pendiente; un nuevo cliente utiliza la ruta guardada. El enlace entre el diario y la sesión de la cuenta se mantiene. La configuración sustituye a la ruta anterior: vuelva a introducir las credenciales del proxy al editarla. Las credenciales se cifran mediante el algoritmo `network.enc`. La API no devuelve el nombre de usuario, la contraseña ni el secreto. Los registros firmados contienen el tipo de ruta e indican si hay credenciales presentes, excluyendo el punto final y los secretos. El operador puede ver el punto final en el panel. Los campos de secretos se borran tras guardar, bloquear o cambiar de espacio de trabajo. **La función «Probar conexión de Telegram**», disponible también antes de iniciar sesión, abre y cierra una conexión temporal y no autorizada a Telegram a través de la ruta. No se establece contacto con ningún sitio web de verificación de IP. El éxito de la prueba confirma la conectividad de transporte, pero no el acceso a grupos, la entrega completa ni el anonimato. El proxy se aplica a las conexiones del cliente de Telegram, incluidas las descargas de archivos multimedia de los servidores de datos (DC) de Telegram. El navegador, pip, SSH y las herramientas TSA ejecutadas manualmente siguen rutas independientes. El nombre de host del proxy puede resolverse localmente. `rdns` afecta a los nombres de host de destino; Telegram suele proporcionar direcciones IP numéricas de los servidores de datos (DC). Ni SOCKS5 ni el protocolo HTTP CONNECT sin cifrar cifran por sí mismos las credenciales del proxy ni el túnel entre el cliente y el proxy. MTProto protege por separado el tráfico de Telegram. Utilice un canal seguro adecuado para conectarse al proxy en una red no fiable. Los grupos privados son chats en la nube; MTProto no los convierte en chats secretos con cifrado de extremo a extremo. ## Cifrado y firmas | Nivel | Implementado | Responsabilidad del operador | | --- | --- | --- | | Tráfico de Telegram | Telethon MTProto | Confianza, ruta y disponibilidad de la plataforma | | Panel web | Token de portador, configuración predeterminada de bucle cerrado, límites de solicitudes | HTTPS o túnel SSH para el acceso remoto | | Secretos | Fernet para las credenciales de la API, la sesión, las credenciales del proxy y la clave privada de firma | Proteja la clave de descifrado y el servidor en el que se ejecuta la herramienta | | Clave de la bóveda | Clave local o clave maestra externa para una nueva instalación | Almacenamiento protegido independiente y copia de seguridad de las claves | | Mensajes y archivos adjuntos | Almacenamiento de la aplicación en texto sin formato | Disco o volumen cifrado | | ZIP/JSONL/CSV/HTML | Comprobaciones de integridad, sin cifrado de contenido | Proteja las copias exportadas y las transferencias | | Procedencia y hora | Registro firmado, acuse de recibo, herramientas RFC 3161 | Clave de confianza, puntos de control independientes/TSA y procedimiento de custodia | **La protección del almacenamiento** en «Cuenta» muestra estos estados. El token del panel es un secreto de acceso, no una contraseña de cifrado. Otorga acceso de administrador; [los tokens emitidos](https://phishdestroy.github.io/TgWitness/es/docs/reference/access/) pueden limitarse a cuentas y chats. Los espacios de trabajo comparten el proceso anfitrión y no son inquilinos aislados. BitLocker, LUKS, FileVault o un volumen cifrado gestionado pueden proteger el almacenamiento según sus respectivos modelos de amenaza. El administrador de un equipo en funcionamiento y desbloqueado sigue pudiendo leer los datos. Incluya SQLite WAL/SHM, archivos multimedia, exportaciones temporales, el espacio de intercambio, las copias de seguridad y las descargas del navegador en la planificación del almacenamiento. Un volumen de Docker no está cifrado por el mero hecho de ser un volumen. TgWitness no implementa SQLCipher ni el cifrado de objetos. ## Clave maestra externa Para una **nueva** instalación, coloque la clave maestra fuera del directorio de datos. Esto no migra automáticamente una bóveda de claves local ya existente. Prepare un directorio de claves al que solo pueda acceder la identidad del servicio y, a continuación, ejecute: ``` python -m tgwitness.security create-master-key /private/keys/tgwitness-master.key export TGWITNESS_VAULT_KEY_FILE=/private/keys/tgwitness-master.key python -m tgwitness --data-dir /private/observations/new-case ``` PowerShell, utilizando el entorno de proyecto instalado: ``` python -m tgwitness.security create-master-key E:\PrivateKeys\tgwitness-master.key $env:TGWITNESS_VAULT_KEY_FILE = 'E:\PrivateKeys\tgwitness-master.key' python -m tgwitness --data-dir E:\PrivateData\new-case ``` En Docker, monte el archivo en modo de solo lectura fuera de «`/data`», por ejemplo, en « `/run/secrets/tgwitness-master.key`», y configure la variable de entorno con esa ruta. El UID del servicio debe poder leerlo. Transmita la ruta, no los bytes de la clave, a través de los archivos de entorno o configuración. Cada espacio de trabajo recibe una «salt» pública aleatoria y su propia clave Fernet derivada mediante HKDF-SHA256. `vault.external.json` almacena los metadatos de derivación, no la clave maestra. Si falta una clave o esta es incorrecta, el inicio fallará sin que se sustituya de forma silenciosa. Conserve tanto los metadatos de la «salt» como la clave maestra para la recuperación. Todos los espacios de trabajo se derivan de la misma clave maestra; su compromiso afecta a toda la instalación. El proceso en ejecución puede descifrar secretos. No se trata de un HSM ni de un KDF de contraseña. No se aceptan contraseñas arbitrarias introducidas manualmente en lugar de una clave aleatoria. Conserve la clave actual para las instalaciones existentes hasta que se haya implementado y verificado una migración planificada. La eliminación de «`vault.key`» o la sustitución de una clave maestra puede impedir el acceso a las sesiones o a las claves de firma. Mantenga las copias de seguridad cifradas y las claves por separado y pruebe la recuperación en una instancia aislada. --- # Telegram · Implementación Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reference/deployment/ Ejecute TgWitness como servicio en Windows, Linux, macOS o Docker, a través de HTTPS, con copias de seguridad y actualizaciones. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Ejecute TgWitness como servicio en Windows, Linux, macOS o Docker, a través de HTTPS, con copias de seguridad y actualizaciones. [TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [Documentación](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) ![Implementación y recuperación](https://phishdestroy.github.io/TgWitness/assets/chapter-operate.svg) **Inglés** · [Русский](https://github.com/phishdestroy/TgWitness/blob/main/docs/ru/DEPLOYMENT.md) · [Ucraniano](https://github.com/phishdestroy/TgWitness/blob/main/docs/uk/DEPLOYMENT.md) · [Español](https://github.com/phishdestroy/TgWitness/blob/main/docs/es/DEPLOYMENT.md) · [Portugués (Brasil)](https://github.com/phishdestroy/TgWitness/blob/main/docs/pt/DEPLOYMENT.md) · [Türkçe](https://github.com/phishdestroy/TgWitness/blob/main/docs/tr/DEPLOYMENT.md) · [العربية](https://github.com/phishdestroy/TgWitness/blob/main/docs/ar/DEPLOYMENT.md) · [فارسی](https://github.com/phishdestroy/TgWitness/blob/main/docs/fa/DEPLOYMENT.md) · [Urdu](https://github.com/phishdestroy/TgWitness/blob/main/docs/ur/DEPLOYMENT.md) · [Hindi](https://github.com/phishdestroy/TgWitness/blob/main/docs/hi/DEPLOYMENT.md) · [Bahasa Indonesia](https://github.com/phishdestroy/TgWitness/blob/main/docs/id/DEPLOYMENT.md) · [Tiếng Việt](https://github.com/phishdestroy/TgWitness/blob/main/docs/vi/DEPLOYMENT.md) · [Chino simplificado](https://github.com/phishdestroy/TgWitness/blob/main/docs/zh/DEPLOYMENT.md) ## Elija una instalación Para obtener el paquete portátil, extraiga «`TgWitness--windows-amd64-portable.zip`» de GitHub Releases. Para los demás métodos, descargue y extraiga el archivo ZIP con el código fuente o clone el repositorio; a continuación, ejecute lo siguiente desde el directorio del proyecto: | Instalación | Inicio | ¿Funciona en segundo plano? | | --- | --- | --- | | Paquete portátil para Windows | `TgWitness.cmd` | No; mantenga la ventana abierta. | | Nativo de Windows | `Start.cmd` | No; utilice la tarea de inicio de sesión opcional para su ejecución en segundo plano. | | Compatible con Linux y macOS | `sh start.sh` | No; utilice systemd/launchd para el funcionamiento en segundo plano. | | Docker en cualquier servidor compatible | `docker compose up -d --build --wait` | Sí, mientras el daemon de Docker esté en ejecución. | | Ayuda para Docker en Windows | `scripts\Docker.cmd` | Sí; el helper espera a que el servidor web esté operativo. | | Ayuda para Docker en Linux/macOS | `sh scripts/docker-start.sh` | Sí; el helper espera a que el servidor web esté operativo. | Para un servidor en la nube que un tercero pueda comprobar —creado a través de la API del proveedor, sin SSH, al que solo se puede acceder a través de un túnel de Cloudflare—, consulte [la implementación de alta seguridad](https://phishdestroy.github.io/TgWitness/es/docs/reference/high-assurance/). El inicio nativo crea un `.venv` privado e instala las dependencias fijadas. Docker las compila dentro de la imagen, sin necesidad de Python en el host. La configuración inicial requiere acceso a Internet. Cuando no se encuentra Python 3.11 o superior, `Start.cmd` solicita permiso antes de instalar Python 3.12 para el usuario actual de Windows (mediante winget; en caso contrario, el instalador de python.org tras comprobar su firma de la Python Software Foundation); nunca solicita privilegios de administrador. Docker y los servicios del sistema operativo siguen siendo requisitos previos. Las instalaciones nativas y portátiles utilizan «`data/live`» dentro de su carpeta. Docker utiliza el volumen denominado «`tgwitness-data`» en «`/data`». Se trata de instalaciones independientes hasta que se migre deliberadamente el directorio de datos completo. No espere que un nuevo contenedor de Docker detecte las cuentas nativas de forma automática. ## Requisitos de instalación La instalación nativa requiere Python 3.11 o posterior con `venv` y `ensurepip`, acceso a Internet para la instalación de la primera dependencia y un directorio de proyecto con permisos de escritura para `.venv`. El panel incluido no necesita Node.js ni compilación de interfaz de usuario. Ejecute el lanzador desde su cuenta habitual del sistema operativo; TgWitness no requiere privilegios de administrador ni de root. - **Windows:** `Start.cmd` comprueba `py -3`, luego `python`, a continuación las carpetas de instalación predeterminadas por usuario y en «Archivos de programa», y requiere la versión 3.11 o posterior. Si ninguna de estas opciones funciona, ofrece la instalación automática por usuario descrita anteriormente. `py -3 start.py` también funciona. El paquete portátil no necesita Python en absoluto. - **Linux:** `start.sh` prueba `python3.13`, `python3.12`, `python3.11`, `python3` y `python`, y muestra el comando de instalación para apt, dnf, pacman, zypper, apk o Homebrew cuando ninguno cumple los requisitos. Las instalaciones en Debian/Ubuntu pueden requerir el paquete `python3-venv` correspondiente al intérprete seleccionado. La versión predeterminada más antigua de Python de una distribución debe sustituirse o complementarse con Python 3.11 o superior. - **macOS:** instale una distribución actual de Python 3.11 o superior; no dé por sentado que un intérprete proporcionado por el sistema operativo cumple los requisitos. Utilice `python3 start.py` desde el directorio del proyecto. - **Docker:** utilice Docker Engine/Desktop con Compose v2.20 o una versión posterior. Docker Desktop debe utilizar contenedores de Linux en Windows. El contenedor instala sus propias dependencias de Python; el sistema anfitrión no necesita una instalación independiente de Python. ## Ordenador local Utilice `Start.cmd` en Windows o `sh start.sh` en Linux/macOS. `scripts\Setup.cmd` o `sh start.sh --setup-only` prepara el entorno. El lanzador instala las dependencias la primera vez que se utiliza; los ejecuciones posteriores reutilizan el entorno. Se necesita acceso a Internet para la configuración y la recopilación de datos de Telegram, pero la consulta de registros existentes y la creación de exportaciones funcionan sin conexión. Ejecute «`python start.py --check`» tras la configuración para comprobar las dependencias locales, Ed25519, el almacenamiento, la configuración de claves y la dirección de escucha sin iniciar un colector. Utilice `--json` para obtener una salida estructurada. Introduzca los comandos `--data-dir`, `--host` y `--port` según corresponda. La comprobación no instala paquetes, no crea un registro ni se conecta a Telegram; no se trata de una verificación de integridad ni de cobertura. El inicio verifica por separado los registros existentes. `python start.py --help` también evita la instalación. Tras ejecutar start.py, ejecute los comandos auxiliares con `.venv\Scripts\python.exe` en Windows o `.venv/bin/python` en Linux/macOS, o bien active primero dicho entorno. Los ejemplos `python -m ...` que figuran a continuación dan por hecho que el entorno está activo. ``` python -m tgwitness --data-dir /path/to/private/data --host 127.0.0.1 --port 8787 ``` Variables de entorno: TGWITNESS_DATA, TGWITNESS_HOST, TGWITNESS_PORT, TGWITNESS_TOKEN. TGWITNESS_VAULT_KEY_FILE selecciona el modo de clave externa para una nueva instalación; véase más abajo. TGWITNESS_TOKEN, si se proporciona, debe contener al menos 24 caracteres; utilice un valor aleatorio cifrado. Sin él, la aplicación genera un token aleatorio de 256 bits en el archivo panel-token.txt. La sustitución de variables de entorno no sobrescribe dicho archivo. Reinicie el sistema para rotar las credenciales. Exactamente un proceso puede ser propietario de un directorio de datos. Un bloqueo de archivos multiplataforma del sistema operativo evita escrituras simultáneas accidentales. Utilice un único trabajador de Uvicorn. El panel puede gestionar cualquier número de espacios de trabajo, con directorios de espacios de trabajo adicionales en profiles//. Para instancias de servicio independientes, utilice directorios y puertos distintos. Los archivos WAL de SQLite deben almacenarse en un almacenamiento local persistente, no en un sistema de archivos de red. No comparta un mismo volumen entre réplicas. ## Paquete portátil para Windows Cada versión de GitHub incluye `TgWitness--windows-amd64-portable.zip` y su `.sha256`. Contiene el entorno de ejecución oficial de Python 3.12 incrustable de python.org (suma de comprobación fijada en `tools/build_portable.py`), TgWitness y sus dependencias fijadas, así como tres lanzadores: | Archivo | Objetivo | | --- | --- | | `TgWitness.cmd` | Inicie el panel; se transmiten opciones adicionales, p. ej., `TgWitness.cmd --port 8790` | | `TgWitness-Demo.cmd` | Inicie la demostración sintética en `data\demo` | | `TgWitness-Check.cmd` | Ejecute la comprobación de preparación sin iniciar el proceso | El diccionario de morfología rusa fijado y los perfiles de color en PDF se incluyen en el paquete para su uso sin conexión. El empaquetado solo permite sus rutas de archivo conocidas dentro de los directorios de dependencia `data`; la presencia de archivos inesperados en dichos directorios provoca un error en la compilación. Descomprima todo el archivo en una carpeta en la que se pueda escribir, como «`Documents\TgWitness`»; no lo ejecute desde dentro del archivo ZIP ni desde «Archivos de programa». El entorno de ejecución utiliza una ruta de módulos aislada, por lo que otras instalaciones de Python y «`PYTHONPATH`» no le afectan. Los datos permanecen en la carpeta «`data`» del paquete. Para actualizar, detenga TgWitness, extraiga la nueva versión a una nueva carpeta y copie la carpeta «`data`» en ella. Compílelo usted mismo en Windows de 64 bits con Python 3.12: ``` python tools/build_portable.py ``` ## Contenedor ``` docker compose up -d --build --wait ``` Esto crea un volumen persistente con nombre para /data. El puerto web está asignado a 127.0.0.1:8787. El proceso se ejecuta con el UID 10001, con capacidades restringidas, un sistema de archivos raíz de solo lectura y los directorios /data y /tmp con permisos de escritura. `--wait` comprueba el estado del servidor web antes de devolver un resultado; no establece la autorización ni la entrega de Telegram. Los ayudantes proporcionados utilizan un tiempo de espera de disponibilidad de 180 segundos tras la compilación. Las descargas iniciales de dependencias pueden tardar más tiempo. Ambos archivos «Compose» base utilizan el nombre de proyecto «`tgwitness`», por lo que extraer una nueva versión a otro directorio no selecciona automáticamente un nuevo volumen de datos. Mantenga solo una implementación activa para ese proyecto. Para instalaciones independientes, utilice un « `docker compose -p NAME ...`» único y un puerto de host diferente, y conserve ambos en las actualizaciones. En el caso de una implementación anterior que utilice un nombre de proyecto diferente, continúe utilizando su nombre original junto con «`-p`»; «`docker compose ls`» muestra los proyectos existentes. Copie `deploy/env.example` en `.env` y modifique `TGWITNESS_PORT` para utilizar un puerto de bucle cerrado diferente. Por ejemplo, `TGWITNESS_PORT=8788` expone el panel en `http://127.0.0.1:8788`; el contenedor sigue escuchando en el puerto 8787. `.env` se omite en Git. Obtenga el token inicial: ``` docker compose exec tgwitness cat /data/panel-token.txt ``` Comandos útiles: ``` docker compose ps docker compose logs --tail 100 -f docker compose stop docker compose up -d --wait ``` `restart: unless-stopped` reinicia el colector tras un fallo o un reinicio del daemon de Docker . En un servidor Linux, active Docker al arrancar utilizando el gestor de servicios de su distribución , normalmente `sudo systemctl enable --now docker`. En Windows/macOS, active la configuración «Iniciar al iniciar sesión» de Docker Desktop. El cierre de sesión, el modo de suspensión o la detención del puede interrumpir la recopilación. Un contenedor detenido explícitamente permanece detenido hasta que lo vuelva a iniciar. El volumen /tmp tiene un límite de 512 MiB en la configuración de ejemplo. La construcción de la exportación utiliza, en su lugar, el `temporary-exports/` de cada espacio de trabajo en el directorio persistente /data. Reserve espacio allí para exportaciones simultáneas, el crecimiento del diario/WAL, archivos multimedia y copias de seguridad. El lanzador utiliza el archivo deploy/constraints.txt para fijar las versiones de las dependencias de tiempo de ejecución que cumplen los requisitos. Los servidores Docker y de alta seguridad se instalan a partir de deploy/requirements.lock y deploy/build.lock con pip --require-hashes: cada archivo de paquete debe coincidir con un SHA-256 registrado en la confirmación, por lo que se rechaza cualquier archivo sustituido en PyPI o en un servidor espejo. La imagen base de Python y los paquetes del sistema operativo siguen requiriendo una certificación de versión independiente. No utilice el comando «docker compose down -v» a menos que tenga la intención de destruir el registro y las claves. El estado del contenedor indica la disponibilidad del servidor web, no que la captura de Telegram se haya realizado con éxito. Compruebe el estado del colector del panel, el «heartbeat», los errores y los eventos de cobertura. ### Perfil de testigo independiente El servicio opcional «`witness`» ejecuta un [testigo independiente](https://phishdestroy.github.io/TgWitness/es/docs/reference/witness/) en su propio contenedor, con su propia clave y registro en el volumen «`witness-data`» y únicamente un token de testigo de solo lectura para el recopilador. Cree el token en la página **«Witness»** del panel, añádalo junto con un token de bot y un canal a «`.env`» y, a continuación, inicie el perfil: ``` docker compose --profile witness up -d # deploy/compose/compose.image.yaml: same flag docker compose logs witness # witness key fingerprint ``` El servicio accede al recopilador dentro de la red Compose en `http://tgwitness:8787` (`TGWITNESS_WITNESS_COLLECTOR` lo anula; por ejemplo, `/profiles/` para otro espacio de trabajo). Para un testigo en un servidor independiente, gestionado por otra persona, utilice `deploy/compose/compose.witness.yaml` allí, con `TGWITNESS_WITNESS_COLLECTOR` configurado en la dirección HTTPS del recopilador; dicho archivo contiene únicamente el testigo. ## Instalar una imagen publicada Copie `deploy/env.example` en `.env`. Establezca `TGWITNESS_IMAGE` en la versión publicada, utilizando la ruta del repositorio **en minúsculas**; por ejemplo: ``` TGWITNESS_IMAGE=ghcr.io/your-owner/your-repository:0.9.1 TGWITNESS_PORT=8787 ``` Ejecute este archivo por sí solo, en lugar de `compose.yaml`: ``` docker compose --project-directory . -f deploy/compose/compose.image.yaml pull docker compose --project-directory . -f deploy/compose/compose.image.yaml up -d --wait docker compose --project-directory . -f deploy/compose/compose.image.yaml exec tgwitness cat /data/panel-token.txt ``` No se necesita compilación del código fuente, Python ni compilador en el servidor. El flujo de trabajo de lanzamiento está orientado a contenedores Linux AMD64 y ARM64, incluida la máquina virtual Linux de Docker Desktop. Utilice una etiqueta de versión o «`ghcr.io/owner/repository@sha256:...`» del resumen del flujo de trabajo. No se ha configurado ninguna etiqueta «`latest`» móvil ni ninguna actualización automática de la aplicación. Las variantes de imagen y código fuente utilizan el mismo volumen de datos cuando su nombre de proyecto coincide. ## HTTPS automático en un servidor Utilice un servidor con Docker, un dominio bajo su control y almacenamiento local persistente. Dirija los registros A/AAAA del dominio hacia el servidor; publique el registro AAAA únicamente si se accede a él a través de IPv6. Permita el tráfico entrante por los puertos TCP 80 y 443, así como el tráfico saliente de DNS/HTTPS para la emisión de certificados. Estos puertos no deben estar ya ocupados por otros servicios. Copie `deploy/env.example` en `.env` y establezca un nombre de host, sin esquema ni ruta: ``` TGWITNESS_DOMAIN=watch.your-domain.org ``` Inicie la compilación del código fuente con la superposición HTTPS: ``` docker compose -f compose.yaml -f deploy/compose/compose.https.yaml up -d --build --wait docker compose -f compose.yaml -f deploy/compose/compose.https.yaml exec tgwitness cat /data/panel-token.txt ``` ``` docker compose --project-directory . -f deploy/compose/compose.image.yaml -f deploy/compose/compose.https.yaml up -d --wait ``` En el caso de una imagen publicada, utilice `deploy/compose/compose.image.yaml` como primer archivo. Conserve ambos argumentos `-f` para futuros comandos de estado, registros, actualización y parada. Caddy obtiene y renueva un certificado, redirige el tráfico HTTP a HTTPS y reenvía las solicitudes al colector en la red privada de Compose. El estado del certificado cuenta con su propio volumen persistente. El puerto de host directo del colector permanece restringido exclusivamente al bucle de retorno. La configuración de Caddy proporcionada no habilita el registro de accesos. Abra `https://watch.your-domain.org` e introduzca el token del panel. La comprobación de disponibilidad no confirma la emisión del certificado ni la accesibilidad externa. Si HTTPS no está disponible, compruebe el DNS, las reglas del cortafuegos y: ``` docker compose -f compose.yaml -f deploy/compose/compose.https.yaml logs --tail 100 caddy ``` La imagen de Caddy proporcionada lleva la etiqueta «`2-alpine`». Al ejecutar «pull», se actualiza dicha imagen; fije un resumen comprobado en su implementación si necesita versiones fijas de la infraestructura. ## Actualizaciones y copias de seguridad Conserve el nombre del proyecto «Compose» y el volumen de datos en todas las actualizaciones. En primer lugar, detenga el recopilador y realice una copia de seguridad completa. Para la implementación predeterminada basada en el código fuente: ``` docker compose stop docker compose cp tgwitness:/data ../tgwitness-backup-before-update ``` Utilice cada vez un nuevo destino de copia de seguridad, fuera del repositorio, y protéjalo como material de acceso a la cuenta. La ruta de ejemplo es meramente ilustrativa; utilice su propia ubicación privada para la copia de seguridad. Copie todo el directorio, incluidos los archivos ocultos, todos los espacios de trabajo, las claves, los registros y los archivos multimedia. Realice una copia de seguridad por separado de la clave maestra de la bóveda externa, si está configurada. Un archivo ZIP de pruebas no es una copia de seguridad de la aplicación que se pueda restaurar. En el caso de HTTPS, conserve también los volúmenes de Caddy si necesita mantener el estado de su certificado o cuenta. Para una implementación desde el código fuente, obtenga los archivos de la nueva versión y ejecute: ``` docker compose up -d --build --wait ``` Para la implementación de una imagen, cambie `TGWITNESS_IMAGE` por la versión deseada y, a continuación, ejecute: ``` docker compose --project-directory . -f deploy/compose/compose.image.yaml pull docker compose --project-directory . -f deploy/compose/compose.image.yaml up -d --wait ``` Utilice también los archivos «Compose» de su instalación para los comandos «stop» y «copy» anteriores. Mantenga «`.env`», la configuración personalizada y el mismo nombre de proyecto. «`down`» conserva los volúmenes con nombre; «**`down -v`**» **los elimina**. No copie «`.venv`» entre sistemas operativos o versiones de Python. Para actualizaciones nativas, detenga TgWitness, realice una copia de seguridad de todo su directorio de datos, sustituya los archivos fuente y ejecute «`python start.py --setup-only`» antes de iniciarlo. Compruebe el acceso al panel, la identidad de la cuenta, el estado de observación y la cobertura tras una actualización. Al reiniciar no se recuperan las actualizaciones de Telegram que se hayan perdido. Una restauración a una versión anterior puede requerir la copia de seguridad previa a la actualización si una versión futura cambia los formatos de almacenamiento. ## Servidor remoto Mantenga el servicio vinculado al bucle de retorno y utilice un túnel SSH, o bien termine la conexión HTTPS en un proxy inverso. El archivo Compose base es de uso exclusivamente local; la superposición opcional « `deploy/compose/compose.https.yaml`» proporciona Caddy para un dominio configurado. Mantenga el token de portador fuera de las URL y de los registros del proxy. Un proxy inverso debe limitar el tamaño de las solicitudes y la frecuencia de conexión. No exponga el protocolo HTTP sin cifrar a Internet. En [la carpeta «deploy/»](https://github.com/phishdestroy/TgWitness/blob/main/deploy/README.md) se proporcionan ejemplos para systemd, una tarea de inicio de sesión en Windows, un agente de usuario de macOS y Caddy. Revise y adapte sus rutas antes de la instalación. Se trata de plantillas, no de configuraciones de plataforma ejecutadas localmente. El lanzador estándar no registra ningún servicio ni tarea en segundo plano. En Windows, al iniciar `pythonw.exe` sin ventana, los diagnósticos de inicio y del servidor se almacenan en `logs/server.log`, dentro del directorio de datos (5 MiB por archivo, dos copias de seguridad rotativas). Las ejecuciones desde la consola conservan los registros de la misma. El registro de acceso HTTP está desactivado en ambos modos. Proteja los registros junto con el directorio de datos y revíselos antes de compartirlos. ## Reinicio y lagunas Se conserva el último estado de observación solicitado. Si la observación estaba activa, al iniciar la aplicación se intenta volver a conectarse y reanudar las fuentes seleccionadas. La pausa manual anula esa intención. Se registra cualquier reinicio fallido y se muestra en el panel. StringSession conserva la autorización, pero no el estado duradero de las actualizaciones o entidades de Telethon. Los diálogos se recargan al inicio. Telegram/Telethon pueden recuperar algunas interrupciones de transporte mientras se ejecutan, pero TgWitness no garantiza una reproducción duradera tras los reinicios del proceso. Cada inicio registra el encabezado del registro anterior y el límite de desconexión. El monitor comprueba la conectividad cada 10 segundos y añade un pulso de **vida** cada minuto (**Parámetros → Registro de actividad cada**). Pueden pasarse por alto breves interrupciones; un canal de transporte conectado no garantiza la entrega completa de las actualizaciones. Las instantáneas son observaciones explícitas del historial actual, nunca una reparación de lagunas. La cola de archivos multimedia se almacena en la base de datos SQLite de cada espacio de trabajo. Un mensaje y su tarea se confirman de forma atómica. Las tareas en ejecución que se interrumpen se recuperan para volver a intentarlas al reiniciar. Cada descarga tiene un tiempo de espera base de 120 segundos, más el tiempo correspondiente a su tamaño a una velocidad de 256 KiB/s, y un límite de 1 a 2.000 MiB por tipo de archivo adjunto; el tiempo de espera, la velocidad y los reintentos se configuran en **«Parámetros**». El recopilador omite los archivos cuyo tamaño se desconoce. Al pausar la aplicación, se conservan las tareas en cola. El reintento utiliza el descriptor de archivo original observado, nunca la última versión de un mensaje editado posteriormente. Los fallos temporales tienen un número limitado de reintentos; las pausas de «FloodWait» de los archivos multimedia se conservan tras el reinicio. La recuperación de archivos multimedia es independiente de la recuperación de actualizaciones de Telegram y no puede recrear archivos que hayan desaparecido. ## Copia de seguridad, restauración y capacidad Detenga el proceso antes de copiar **todo** el **directorio de datos**, incluidos vault.key, signing.enc, credentials.enc, la base de datos SQLite y los archivos WAL, los archivos multimedia, el token, los puntos de control, y todos los perfiles y subdirectorios. Restaure la copia completa mientras el servicio de destino esté detenido. La falta de claves de «vault» o la discrepancia entre claves de firma provocarán que el inicio falle; no regenere claves para forzar el acceso. Mantenga las copias de seguridad secretas cifradas y con acceso controlado. Los archivos ZIP de pruebas son artefactos de revisión portátiles, no copias de seguridad de la aplicación ni de sesiones de Telegram. No existe una eliminación automática por retención. Prevea espacio en disco suficiente para todos los mensajes, metadatos sin procesar, archivos multimedia, exportaciones temporales y copias de seguridad. La verificación inicial y la exportación de registros de flujo se realizan en lugar de cargar el diario completo. Una exportación fija una instantánea leída mientras pueden continuar las nuevas escrituras en el WAL; las exportaciones de larga duración pueden retener páginas del WAL, por lo que la capacidad del disco sigue siendo importante. Los archivos ZIP tienen un límite de 4 GiB sin comprimir para ajustarse a la configuración predeterminada del verificador independiente; **Parámetros → ZIP firmado más grande** aumenta el límite, y dichos archivos se verifican con `verify.py --max-gib N`. Otros formatos no tienen límite de recuento de eventos. Los navegadores compatibles transmiten fragmentos de respuesta a un archivo seleccionado por el usuario. Otros navegadores almacenan en el búfer un máximo de 128 MiB y dirigen las transferencias de mayor tamaño a la CLI autenticada: ``` python -m tgwitness.download --token-file data/live/panel-token.txt --out evidence.zip ``` Utilice `--profile ID`, de **«Exportaciones» → «ID del espacio de trabajo»**, para otro espacio de trabajo; `--format zip|jsonl|csv|html` o `--url https://your-server` para un servidor remoto; o `--max-mib` para modificar el límite de transferencia de 5 GiB. Solo se permite el protocolo HTTP sin cifrar para el bucle de retorno. Los tokens se transmiten en los encabezados, se rechazan las redirecciones, los archivos existentes no se sobrescriben y las descargas incompletas no se publican como archivos finalizados. Si TGWITNESS_TOKEN anula el token generado, utilice un archivo protegido por separado que contenga ese valor activo: panel-token.txt no se reescribe con la anulación. El SHA-256 del comando es solo una suma de comprobación de la transferencia; verifique de forma independiente el archivo ZIP firmado. El panel muestra los archivos multimedia en cola o fallidos, los archivos multimedia pendientes más antiguos, el espacio libre en disco, las pausas en las solicitudes de Telegram y las fuentes cuyo acceso no está confirmado. Estos diagnósticos no constituyen un monitor completo de entrega de extremo a extremo. Los espacios de trabajo comparten un proceso; una cuenta con mucha actividad puede seguir afectando a los demás. Se mantienen los procesos de trabajo independientes, la retención y rotación, la recuperación duradera de actualizaciones y la cualificación completa de la implementación. El acceso limitado al panel se documenta en la sección de [acceso y permisos](https://phishdestroy.github.io/TgWitness/es/docs/reference/access/); los puntos de control independientes se tratan en la [guía del testigo](https://phishdestroy.github.io/TgWitness/es/docs/reference/witness/). Procedimientos detallados: [conexión/seguridad](https://phishdestroy.github.io/TgWitness/es/docs/reference/connection/) y [modos de funcionamiento](https://phishdestroy.github.io/TgWitness/es/docs/reference/operations/). --- # Phala / Intel TDX · Implementación de alta seguridad Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reference/high-assurance/ Un servidor sellado disponible las 24 horas del día, los 7 días de la semana, en Hetzner o Phala Cloud, un DNS de puerta de enlace y comprobaciones que un tercero puede repetir. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Translation coverage: this edition includes material from the English original. Un servidor sellado disponible las 24 horas del día, los 7 días de la semana, en Hetzner o Phala Cloud, un DNS de puerta de enlace y comprobaciones que un tercero puede repetir. [TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [Documentación](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) · [Implementación y recuperación](https://phishdestroy.github.io/TgWitness/es/docs/reference/deployment/) ![Implementación y recuperación](https://phishdestroy.github.io/TgWitness/assets/chapter-operate.svg) La implementación de alta fiabilidad añade comprobaciones independientes del entorno de recopilación a la verificación del archivo. El revisor consulta los registros de implementación y acceso que conservan el proveedor de la nube y Cloudflare, y una implementación de Intel TDX añade una certificación por hardware del entorno del recopilador. El uso habitual de Docker y en el entorno local no sufre cambios. Nada de lo que hay aquí se ejecuta a menos que se implemente con `python -m tgwitness.cloud`, y el recopilador lee su host únicamente cuando la implementación establece `TGWITNESS_ASSURANCE`. Diagrama de flujo · Operador → Servidor, cortafuegos sin reglas de entrada (API del proveedor); Operador → Túnel y DNS (API de Cloudflare); Servidor, cortafuegos sin reglas de entrada → Túnel y DNS (solo salida); Servidor, cortafuegos sin reglas de entrada → Clave de firma creada en el servidor; Verifier, tokens de solo lectura → Registro del proveedor y cortafuegos; Verifier, tokens de solo lectura → Dirección del conector de túnel e ingreso; Verifier, tokens de solo lectura → Declaración firmada de /api/assurance; Verifier, tokens de solo lectura → Archivo ZIP de pruebas · Operador · Verifier, tokens de sololectura · Servidor, cortafuegos sinreglas de entrada · Registro del proveedor ycortafuegos · Dirección del conector detúnel e ingreso · Declaración firmada de/api/assurance · Archivo ZIP de pruebas · Túnel y DNS · Clave de firma creada enel servidor · API del proveedor · API de Cloudflare · solo salida **Diagrama en formato de texto** 1. Operador → Servidor, cortafuegos sin reglas de entrada (API del proveedor) 2. Operador → Túnel y DNS (API de Cloudflare) 3. Servidor, cortafuegos sin reglas de entrada → Túnel y DNS (solo salida) 4. Servidor, cortafuegos sin reglas de entrada → Clave de firma creada en el servidor 5. Verifier, tokens de solo lectura → Registro del proveedor y cortafuegos 6. Verifier, tokens de solo lectura → Dirección del conector de túnel e ingreso 7. Verifier, tokens de solo lectura → Declaración firmada de /api/assurance 8. Verifier, tokens de solo lectura → Archivo ZIP de pruebas **En esta página** - [Lo que puede comprobar un verificador](https://phishdestroy.github.io/TgWitness/es/docs/reference/high-assurance/#what-a-verifier-can-check) - [Proveedores](https://phishdestroy.github.io/TgWitness/es/docs/reference/high-assurance/#providers) - [Máquina virtual confidencial en Phala Cloud (Intel TDX)](https://phishdestroy.github.io/TgWitness/es/docs/reference/high-assurance/#confidential-vm-on-phala-cloud-intel-tdx) - [Antes de empezar](https://phishdestroy.github.io/TgWitness/es/docs/reference/high-assurance/#before-you-start) - [Desde el panel](https://phishdestroy.github.io/TgWitness/es/docs/reference/high-assurance/#from-the-panel) - [Túnel rápido sin dominio](https://phishdestroy.github.io/TgWitness/es/docs/reference/high-assurance/#quick-tunnel-without-a-domain) - [Implementar](https://phishdestroy.github.io/TgWitness/es/docs/reference/high-assurance/#deploy) - [Depuración de la implementación y bloqueo](https://phishdestroy.github.io/TgWitness/es/docs/reference/high-assurance/#debug-deployment-and-lock) - [Eliminar una implementación](https://phishdestroy.github.io/TgWitness/es/docs/reference/high-assurance/#remove-a-deployment) - [Cualquier servidor (autocertificado)](https://phishdestroy.github.io/TgWitness/es/docs/reference/high-assurance/#any-server-self-attested) - [Verificar](https://phishdestroy.github.io/TgWitness/es/docs/reference/high-assurance/#verify) - [Informe para la entrega de pruebas](https://phishdestroy.github.io/TgWitness/es/docs/reference/high-assurance/#report-for-evidence-handover) - [Cloudflare como testigo externo](https://phishdestroy.github.io/TgWitness/es/docs/reference/high-assurance/#cloudflare-as-an-outside-witness) - [Lectura del resultado de la implementación](https://phishdestroy.github.io/TgWitness/es/docs/reference/high-assurance/#reading-the-deployment-result) ## Lo que puede comprobar un verificador | Afirmación | Cómo se comprueba | Mantenido por | | --- | --- | --- | | El servidor se creó a través de la API del proveedor en un momento determinado. | El objeto «servidor» y su creación en el propio registro del proveedor | Proveedor | | Nadie utilizó las rutas de acceso del proveedor | Registro de solicitudes de consola, recuperación, restablecimiento de contraseña, reconstrucción, ISO, imágenes y copias de seguridad | Proveedor | | No se pudo establecer conexión con él | El cortafuegos del proveedor no tiene reglas de entrada; el SSH queda oculto desde el primer arranque. | Proveedor (cortafuegos), servidor (SSH) | | Solo se puede acceder al panel a través del túnel | El ingreso al túnel se reenvía únicamente al panel; el conector se ejecuta desde la dirección del servidor | Cloudflare | | Este mismo software se ejecuta | El hash firmado del árbol de código fuente del recopilador coincide con una copia del commit implementado. | Collector, sincronizado con Git | | La clave de firma se creó en ese servidor. | La clave firma una declaración en la que se indica el ID del servidor del proveedor y el hash del archivo «cloud-init» que ha recibido. | Collector, verificado con el proveedor | | El diario pertenece a esa clave y a ese servidor | Cada inicio de proceso en la prueba ZIP incluye la medición del host correspondiente a ese servidor | Pruebas ZIP | El recopilador registra el estado de SSH, las sesiones, el historial de inicio de sesión y la información de arranque en registros firmados de process-start y `host.state`. En una máquina virtual normal, se trata de registros de inventario locales, que el revisor compara con los registros independientes del proveedor. La implementación de Intel TDX que se muestra a continuación verifica además las mediciones respaldadas por hardware. ## Proveedores | `--provider` | Credenciales | Acceso de solo lectura de Verifier | Registro del proveedor para el verificador | Se conserva para | | --- | --- | --- | --- | --- | | `hetzner` | `HCLOUD_TOKEN` | Token de lectura del mismo proyecto | Acciones del servidor y del cortafuegos | Mientras existan los recursos | | `digitalocean` | `DIGITALOCEAN_TOKEN` | Token de acceso personal de solo lectura | Acciones de Droplet | Mientras el Droplet exista | | `linode` | `LINODE_TOKEN` | `linodes`, `firewall`, `events` ámbitos de solo lectura | Eventos de la cuenta, versiones de las reglas del cortafuegos | 90 días | | `vultr` | `VULTR_API_KEY` | Usuario con acceso de lectura y el `activity_logs` permiso | Registro de actividad de la cuenta (método, ruta, actor) | 30 días, o más con una suscripción al registro de auditoría | | `aws` | `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` | `ec2:DescribeInstances`, `ec2:DescribeSecurityGroups`, `cloudtrail:LookupEvents` | Historial de eventos de CloudTrail | 90 días | | `phala` | `PHALA_CLOUD_API_KEY` | Una clave API del mismo espacio de trabajo | Revisiones de la aplicación y operaciones de la CVM: cambios en la configuración y el entorno de Docker Compose, reinicios y actualizaciones del sistema operativo | Aunque la aplicación existe | | `generic` | ninguno | ninguno | ninguno: **autocertificado** | – | Utiliza un proyecto, equipo, cuenta o subcuenta específicos para cada caso: el acceso de solo lectura del verificador mostrará entonces únicamente esta implementación. Las credenciales se leen desde `--provider-token-file` de la variable anterior, nunca desde la línea de comandos. Para AWS, el archivo contiene `ACCESS_KEY_ID SECRET_ACCESS_KEY [SESSION_TOKEN]`; la región es `--location`. En cada informe se indica lo que los registros de cada proveedor no pueden mostrar. En resumen: Hetzner registra las solicitudes de la consola; la consola de recuperación de DigitalOcean, Lish/Glish de Linode y la consola web de Vultr no se registran como tales, por lo que el acceso de root queda bloqueado en el primer arranque y para iniciar sesión en la consola sería necesario restablecer la contraseña o cambiar la configuración de arranque, acciones que sí se registran. Vultr devuelve la dirección de la consola a cualquier clave que pueda leer la instancia; ni el registro ni el informe la almacenan. ## Máquina virtual confidencial en Phala Cloud (Intel TDX) Con `--provider phala` el colector se ejecuta en una máquina virtual confidencial Intel TDX en [Phala Cloud](https://phala.com/), gestionada por dstack. Ni el anfitrión ni el personal de Phala pueden leer su memoria, y el procesador firma un certificado que acredita lo que ha arrancado la máquina. El verificador no se fía de la palabra de Phala: `tgwitness.tdx` comprueba él mismo cada certificación, hasta la CA raíz de Intel SGX fijada, cotejándola con las listas de revocación de Intel y los datos de plataforma firmados por Intel, y rechaza las máquinas que puedan ser depuradas o migradas. | Entrada de informe | Qué muestra | | --- | --- | | `tdx_binding` | La certificación abarca la declaración firmada del recopilador y el valor aleatorio de esta solicitud. | | `tdx_quote` | Intel avala la certificación; solo se aprueba cuando Intel considera que la plataforma está actualizada. | | `tdx_compose_hash` | RTMR3, reproducido a partir del registro de eventos de dstack, mide la composición de la aplicación que informa el recopilador. | | `tdx_compose` | Ese código es, byte a byte, el mismo que genera el código de la confirmación desplegada: archivos fuente fijados por hash, ambas imágenes por resumen, sin ningún otro código. | | `tdx_identity` | La certificación procede de la aplicación y la instancia desplegadas, con claves del KMS de Phala y un disco cifrado. | | `tdx_os` | MRTD y RTMR0-2 equivalen a los valores que el verificador calcula a partir de la imagen del sistema operativo dstack que publica Dstack-TEE, determinada por el hash de la imagen del sistema operativo que informa la CVM, y a partir de las tablas ACPI que QEMU genera para la configuración de la máquina virtual: firmware, kernel, initrd, línea de comandos con el hash del sistema de archivos raíz, memoria, vCPU y dispositivos. Una imagen de desarrollo falla | The OS image (about 180 MB, of which 21 MB are kept) is downloaded once from [Dstack-TEE/meta-dstack](https://github.com/Dstack-TEE/meta-dstack/releases) into `dstack-images` beside the record; `--tdx-image FOLDER` uses another folder or an unpacked image, `--tdx-image none` skips the comparison. The measurement follows `dstack-mr` and the `qemu-acpi` crate of Dstack-TEE/dstack. Private measurement regressions compare QEMU's own ACPI output and a retained Phala Cloud quote; live qualification also needs the published image. `--tdx-measurements` still compares MRTD and RTMR0-2 given as JSON instead. Cada inicio del recopilador registrado en el diario lleva consigo dicha certificación, por lo que `verify --evidence` comprueba cada inicio y la imagen del sistema operativo con la que se ha arrancado. Las revisiones de la aplicación de Phala y las operaciones del CVM sirven como registro del proveedor: una configuración de Docker Compose modificada tras el despliegue hace que el informe no sea válido, y los reinicios se incluyen en la lista para su revisión. En el panel, selecciona **«Máquina virtual confidencial · Phala Cloud»** en **«Extras»** → **«Servidor 24/7»** y pega una clave API de Phala Cloud; el túnel rápido funciona igual que en Hetzner. Desde la línea de comandos: ``` python -m tgwitness.cloud deploy --provider phala --name case-1 --server-type tdx.small \ --ref v0.8.0 --repository https://github.com/phishdestroy/TgWitness --quick-tunnel \ --provider-token-file phala-key.txt python -m tgwitness.cloud verify --record deployments/case-1/deployment.json \ --provider-token-file phala-key.txt --cloud-init deployments/case-1/docker-compose.yaml \ --source CHECKOUT_OF_COMMIT --fingerprint COLLECTOR_FINGERPRINT --report certificate.md python -m tgwitness.cloud check-report --report certificate.pdf --verifier-fingerprint VERIFIER_KEY ``` `--tdx-collateral` Lee los certificados y las listas de revocación de Intel desde un archivo en lugar de descargarlos de Intel. El DNS de puerta de enlace no está disponible aquí: Phala no tiene un cortafuegos del proveedor para el tráfico saliente. ### Certificado de autenticación En una implementación de Phala, `verify --report certificate.md` también genera el certificado: un `certificate.html` autónomo y un `certificate.pdf` en formato A4 con el veredicto, la cadena de confianza desde la raíz de Intel hasta la clave del recopilador, una comparación con servidores ordinarios y de alta seguridad, las mediciones junto a los valores calculados a partir de la imagen publicada, quién avala cada parte, la cadena de certificados de Intel, cada comprobación, el registro del proveedor y cómo repetir la verificación. El informe JSON sigue siendo el registro oficial; las páginas lo representan. El informe está sellado digitalmente con firmas y marcas de tiempo, en el archivo `certificate.seal.json` y en los archivos `.tsq`/`.tsr` que lo acompañan: | Sello | Qué aporta | | --- | --- | | Sello de tiempo electrónico cualificado, `http://tsa.belgium.be/connect` | Marca de tiempo RFC 3161 sobre los bytes exactos de `certificate.json` procedente del proveedor de servicios de confianza cualificado del Gobierno federal belga (FPS Policy and Support, BOSA). Dicha entidad figura como servicio cualificado de sellado de tiempo, con estado «concedido», en la lista de confianza de la UE de Bélgica; la raíz (Belgium Root CA6) y las entradas de la lista, según la versión publicada el 20 de octubre de 2026, están fijadas en `tgwitness/tsa_roots.py`. De conformidad con el artículo 41 del Reglamento (UE) n.º 910/2014, se presume que dicho sello de tiempo es exacto en cuanto a la fecha y la hora, así como en cuanto a la integridad de los datos, en todos los Estados miembros de la UE. | | Marca de tiempo RFC 3161, FreeTSA | Una segunda marca de tiempo independiente | | Firma del verificador | Ed25519 sobre una declaración que identifica el SHA-256 del informe y cada marca de tiempo, con la propia clave del verificador (`--sign-with FOLDER`, por defecto `~/.tgwitness/verifier`); el PDF lleva una firma con la misma clave | `--timestamp URL` (repetible) elige otras autoridades, `--timestamp none` ninguna, `--sign-with none` deja el sello sin firmar. `check-report` comprueba el hash del informe, la firma del verificador, cada marca de tiempo con respecto a una raíz de confianza y su estado cualificado, así como la firma del PDF. La validez jurídica de un sello de tiempo cualificado fuera de la UE, así como del informe en su conjunto, recae en el tribunal o la autoridad que lo reciba; el sello indica cuándo existía el informe y que no ha sufrido modificaciones. Una certificación no puede descartar un fallo en el módulo TDX o en el microcódigo de Intel, ni el acceso físico al bus de memoria. Quien controle la aplicación en la cuenta de Phala puede implementar otro «compose»; aparecerá como una nueva revisión con un nuevo hash de «compose». El anfitrión controla la fuente de tiempo de la máquina y la red. La implementación, la verificación con `--evidence`, los reinicios, la comparación de la imagen del sistema operativo, el certificado sellado digitalmente con firmas y marcas de tiempo y la destrucción se han ejecutado en la propia Phala Cloud; véase [, la ejecución del 4 de noviembre de 2026,](https://phishdestroy.github.io/TgWitness/es/docs/reference/verification/#live-phala-cloud-deployment--4-november-2026). ## Antes de empezar 1. Una zona de Cloudflare, su ID de cuenta y un token de API con permisos para **«Cloudflare Tunnel Edit**», **«Zone Read»** y **«DNS Edit**», proporcionado con `--cloudflare-token-file` o `CLOUDFLARE_API_TOKEN`. Para el verificador: **lectura de Cloudflare Tunnel**, **lectura de DNS** y, para el registro de auditoría, **lectura de la configuración de la cuenta**. Sin un dominio, un [túnel rápido](https://phishdestroy.github.io/TgWitness/es/docs/reference/high-assurance/#quick-tunnel-without-a-domain) no necesita nada de esto. 2. Credenciales de proveedor con acceso de escritura a un proyecto específico; `lock` utiliza lo mismo: - Hetzner: token de API con permisos de lectura y escritura; - DigitalOcean: token de acceso personal con permiso de escritura; - Linode: token de acceso personal con `linodes`, `firewall` y `events` ámbitos de lectura/escritura; - Vultr: clave API de una cuenta dedicada o una subcuenta; - AWS: se permiten credenciales de IAM `ec2:DescribeVpcs`, `ec2:DescribeImages`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:RunInstances`, `ec2:CreateTags`, `ec2:DescribeInstances`, `ec2:DescribeSecurityGroupRules` y `ec2:RevokeSecurityGroupIngress`. 3. La confirmación que se va a ejecutar. Una etiqueta de lanzamiento se resuelve una sola vez a su confirmación con `git ls-remote`; el servidor solo recibe siempre el commit de 40 caracteres. ## Desde el panel En tu propio ordenador, en **Extras → Servidor 24/7** se ejecuta lo mismo `deploy` para Hetzner en tres pasos: elige Europa o Estados Unidos, pega un token de Hetzner (lectura y escritura) y, a continuación, revisa el tipo de servidor, el precio mensual, la dirección y la versión que el panel ha encontrado con ese token. No se crea nada hasta que lo confirmes. El panel muestra cada paso tal y como `deploy` se va indicando, y a continuación la dirección, el token del panel y la huella digital de la clave de firma. Sin un dominio, el servidor obtiene un [túnel rápido](https://phishdestroy.github.io/TgWitness/es/docs/reference/high-assurance/#quick-tunnel-without-a-domain) ; **en «Tus servidores» → «Buscar la dirección actual»** se vuelve a consultar tras un reinicio. Para obtener una dirección fija bajo tu propio dominio, abre **«Opcional · tu propio dominio»** y añade un token de Cloudflare (el enlace preparado selecciona «Lectura de zona», «Edición de DNS» y «Edición del túnel de Cloudflare»). Los tokens se transmiten con cada solicitud desde la pestaña del navegador hasta TgWitness en el mismo ordenador y no se guardan en ningún sitio; el registro de implementación, el cloud-init censurado, el token del panel y, en el caso de un túnel rápido, la clave de dirección se guardan en `deployments/NAME` dentro del directorio de datos. El panel ofrece esto únicamente al administrador principal a través de una conexión directa de bucle invertido (`127.0.0.1`, sin encabezados de proxy ni de túnel); un panel al que se accede a través de una red muestra los comandos en su lugar. La versión por defecto es la etiqueta de lanzamiento del panel en ejecución, resuelta a través de la API de GitHub. La ubicación, el tipo de servidor y el precio proceden de la API de Hetzner: `cpx22` si está disponible; de lo contrario, el tipo x86 más barato con al menos 2 GB de memoria. ## Túnel rápido sin dominio `--quick-tunnel` sustituye a `--zone`, `--cloudflare-account` y `--panel-host`; no interviene ninguna cuenta ni token de Cloudflare: ``` python -m tgwitness.cloud deploy --provider hetzner --name case-2026-11 --server-type cpx22 \ --ref 0123456789abcdef0123456789abcdef01234567 --quick-tunnel --provider-token-file hetzner.token ``` En el servidor, Cloudflared abre un [túnel rápido](https://developers.cloudflare.com/tunnel/get-started/quick-tunnels/) hacia el panel: una dirección aleatoria `https://….trycloudflare.com` que cambia cada vez que se reinicia cloudflared o el servidor. Un pequeño servicio en el servidor publica cada dirección en un tema aleatorio de ntfy.sh , firmada (HMAC-SHA256) con una clave que solo contiene el directorio de implementación (`address-key.txt`), y la repite cada tres horas porque ntfy.sh conserva las publicaciones durante 12. `deploy` y **«Find the current address»** solo aceptan publicaciones firmadas, por lo que una publicación falsificada no puede enviarte a ti, ni a tu token del panel, a la dirección de otra persona. El tema figura en el registro y en el cloud-init publicado: quienquiera que los tenga puede leer la dirección actual, que sigue solicitando el token del panel. El servidor no mantiene ningún puerto de entrada en ningún caso. Un verificador no dispone de clave de dirección, y cualquiera que lea el tema puede publicar en él. Por lo tanto, el recopilador también publica la propia dirección, firmada con su propia clave Ed25519, y `verify` toma la publicación más reciente firmada por la clave del recopilador en el registro de implementación; las publicaciones se ordenan según la hora en que ntfy.sh las recibió, no según la hora que indican. Un recopilador anterior a este cambio no firma nada, y `verify` toma entonces la publicación más reciente y así lo indica en la comprobación de `statement`; una publicación falsificada solo puede hacer que dicha comprobación falle, ya que la dirección debe seguir respondiendo con la clave del recopilador. Costes: ninguna cuenta de Cloudflare mantiene registros de un túnel rápido, por lo que `verify` informa de que el túnel, el conector y la comprobación de DNS no están disponibles, y el resultado es, en el mejor de los casos, `incomplete` (en Phala Cloud, en cambio, la comprobación se supera: el conector se ejecuta dentro de la configuración de Docker Compose medida); los registros del proveedor, el cortafuegos, la declaración firmada, las mediciones del host y la comparación del instalador se comprueban como de costumbre. La comparación de bytes con el instalador de referencia requiere una confirmación desplegada que ya conozca `--quick-tunnel`; una comprobación de la versión 0.7.0 compila el instalador del dominio e informa de la diferencia. Cloudflare no ofrece garantía de disponibilidad para los túneles rápidos, permite 200 solicitudes en tránsito y no admite eventos enviados por el servidor (Server-Sent Events), por lo que es posible que las actualizaciones en tiempo real del panel (versiones posteriores a la 0.7.0) no lleguen a través de uno de ellos y sea necesario recargar la vista; esa parte aún no se ha probado. Para un caso que deba funcionar de forma fiable, utilice su propio dominio. ## Implementar Echa un vistazo primero a todo lo que se va a enviar. `plan` No realiza ninguna solicitud al proveedor ni a Cloudflare: ``` python -m tgwitness.cloud plan --provider hetzner --name case-2026-11 --server-type cpx22 \ --ref 0123456789abcdef0123456789abcdef01234567 --zone example.org \ --cloudflare-account CLOUDFLARE_ACCOUNT_ID --panel-host case.example.org ``` A continuación, realice la implementación con las mismas opciones y las credenciales: ``` python -m tgwitness.cloud deploy --provider hetzner --name case-2026-11 --server-type cpx22 \ --ref 0123456789abcdef0123456789abcdef01234567 --zone example.org \ --cloudflare-account CLOUDFLARE_ACCOUNT_ID --panel-host case.example.org \ --witness-host case-witness.example.org \ --provider-token-file hetzner.token --cloudflare-token-file cloudflare.token ``` Tipos de servidor para empezar: `cpx22` (Hetzner), `s-1vcpu-2gb` (DigitalOcean), `g6-standard-1` (Linode), `vc2-1c-2gb` (Vultr), `t3.small` (AWS). `--location` y `--image` por defecto, Ubuntu 24.04 de cada proveedor en una región europea. `--repository` Toma la confirmación de otro repositorio Git https, sin credenciales en la URL (por defecto `https://github.com/phishdestroy/TgWitness.git`). `deploy` también acepta `--out` para otro directorio de implementación (por defecto `deployments/NAME`; se rechaza un directorio que ya contenga una implementación) y `--wait`, los minutos que hay que esperar a la declaración firmada del recopilador: de 1 a 240, por defecto 20, o 60 para `generic`. El comando: 1. crea un túnel de Cloudflare cuyo ingreso reenvía el nombre de host del panel al propio panel y, si se ha especificado, el nombre de host de Witness a `/api/witness/head` y `/api/assurance` solo; 2. crea registros CNAME proxy para esos nombres de host, rechazando los nombres que ya existen; 3. crea un cortafuegos de proveedor sin reglas de entrada y un servidor detrás de él sin clave SSH, sin copias de seguridad, sin agente de consola y con cloud-init que enmascara el SSH, bloquea el acceso de root, instala `cloudflared`, recupera exactamente el commit, lo comprueba e inicia TgWitness como un servicio de systemd reforzado; 4. espera la declaración firmada del recopilador y comprueba que en ella se mencione este servidor y el hash de este cloud-init. `deployments/case-2026-11/` A continuación, contiene: | Archivo | Índice | ¿Compartir? | | --- | --- | --- | | `deployment.json` | ID, hash, las llamadas a la API realizadas (método, ruta, estado) y la primera declaración firmada | Sí, con el verificador | | `cloud-init.redacted.yaml` | El comando exact cloud-init con sus dos claves secretas sustituidas por `REDACTED` | Sí | | `panel-token.txt` | El token del panel | No | La contraseña de root del proveedor, el token del túnel y el token del panel nunca se escriben en `deployment.json`. Publica la huella digital del recopilador que aparece al final a través de un canal que no controles tú solo, por ejemplo, un canal de testigos o un mensaje al destinatario. Inicia sesión en Telegram en `https://case.example.org` con el token del panel, tal y como se indica en la [guía de la cuenta](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/). Las acciones del panel se registran en el diario firmado; no se trata de sesiones SSH. Un [testigo](https://phishdestroy.github.io/TgWitness/es/docs/reference/witness/) puede consultar `https://case-witness.example.org`. No hay SSH: si falla la inicialización, el recopilador nunca responde. Elimina el servidor y vuelve a implementarlo, o utiliza una implementación de depuración para encontrar la causa. ### Secretos en los datos de usuario El cloud-init contiene dos claves secretas: el token del panel y el token del túnel de Cloudflare. La clave de firma no se encuentra entre ellas; se crea en el servidor. Hetzner, DigitalOcean y Linode no devuelven datos de usuario a través de su API. Vultr los devuelve a cualquier clave que pueda leer la instancia, y EC2 a través de `DescribeInstanceAttribute`. Para AWS, proporciona al verificador únicamente las tres acciones de la tabla, nunca `ec2:Describe*`. En el caso de Vultr, supongamos que la clave del verificador puede leer ambos tokens. Un token de túnel permite a alguien ejecutar un segundo conector: `verify` informa de cualquier conector que no esté en el servidor, y las declaraciones del recopilador no pueden falsificarse de esa manera porque cada una firma un desafío nuevo. Con `--quick-tunnel` el segundo secreto es, en cambio, la clave de dirección: quienquiera que la lea puede publicar una dirección falsa que el panel aceptaría. La declaración pública del recopilador omite la dirección del servidor y las fuentes de los inicios de sesión; ambas permanecen en el registro firmado. ## Depuración de la implementación y bloqueo `--debug-ssh-key KEY --debug-ssh-from 198.51.100.4` mantiene SSH para una clave procedente de una dirección o una red pequeña, como máximo un /24 para IPv4 o un /48 para IPv6. `KEY` Ya está registrado con el proveedor: el nombre o el ID de una clave SSH en el proyecto Hetzner, el ID o la huella digital de una clave SSH en el equipo de DigitalOcean, un nombre de usuario de Linode cuyas claves SSH de perfil se añaden a root, el ID de una clave SSH en la cuenta de Vultr o el nombre de un par de claves de EC2 en la región. Estas opciones no se aplican a `generic`. Dicha implementación se registra como `debug` y **nunca** se clasifica como de alta seguridad. Cuando hayas terminado, ejecuta `sudo tgwitness-lock` como último comando de la última sesión SSH y, a continuación: ``` python -m tgwitness.cloud lock --record deployments/case-2026-11/deployment.json --provider-token-file hetzner.token ``` El cortafuegos pierde todas las reglas de entrada. A continuación, los informes muestran cuándo se permitió el SSH y cuándo se cerró; esa ventana permanece visible. ## Eliminar una implementación `destroy` Elimina el servidor y su cortafuegos, identificados mediante la etiqueta de la implementación, de modo que una implementación que haya fallado a mitad de camino también se elimine; a continuación, se eliminan los registros DNS que apuntan a su túnel, así como el propio túnel. El registro del servidor y la clave de firma se eliminan junto con él: exporta primero las pruebas. El registro permanece, marcado `removed`, con las llamadas a la API de la eliminación. ``` python -m tgwitness.cloud destroy --record deployments/case-2026-11/deployment.json --confirm case-2026-11 \ --provider-token-file hetzner.token --cloudflare-token-file cloudflare.token ``` La eliminación a través de la API está implementada para Hetzner. En el caso de otros proveedores `destroy` se detiene antes de eliminar nada y especifica la etiqueta que se va a eliminar en la consola del proveedor. Un servidor instalado manualmente (`generic`) solo pierde su túnel y sus registros DNS. Una implementación rápida del túnel no necesita token de Cloudflare: su túnel termina en el servidor, y sus publicaciones caducan en ntfy.sh en un plazo de 12 horas. ## Cualquier servidor (autocertificado) `--provider generic` Es para un servidor comprado o instalado manualmente. `deploy` crea el túnel y el DNS, escribe `install.sh` (privado) y `install.redacted.sh` (para publicar), y espera. Copia `install.sh` en un servidor Ubuntu 24.04 recién instalado y ejecútalo allí: ``` sudo bash install.sh ``` Registra el servidor tal y como estaba (inicios de sesión, cuentas, `authorized_keys`, sockets de escucha, servicios, tareas programadas, paquetes), instala la confirmación, activa el cortafuegos del host, se elimina a sí mismo, enmascara el SSH y finaliza la sesión. El informe de un servidor de este tipo es, en el mejor de los casos, **AUTOATESTADO**: quienquiera que ejecutara el instalador ya tenía privilegios de root antes de hacerlo, y no hay ningún registro del proveedor disponible para el verificador. Aun así, es mejor que un servidor sin explicación: el inventario, el hash del instalador y todos los inicios de sesión posteriores están firmados. ## Verificar El verificador necesita `deployment.json`el instalador publicado, credenciales de solo lectura y, a ser posible, una copia del commit y una prueba ZIP: ``` git clone -c core.autocrlf=false https://github.com/phishdestroy/TgWitness.git checkout git -C checkout checkout 0123456789abcdef0123456789abcdef01234567 python -m tgwitness.cloud verify --record deployment.json \ --provider-token-file read-only.token --cloudflare-token-file cloudflare-read.token \ --fingerprint COLLECTOR_FINGERPRINT --cloud-init cloud-init.redacted.yaml \ --source checkout --evidence tgwitness-evidence.zip --report report.md ``` El verificador solicita en ese momento todos los datos de los proveedores y de Cloudflare; el registro solo proporciona los ID sobre los que se debe preguntar. El código de salida es 0 para **APROBADO**, 1 para **FALLO** y 2 para **REVISIÓN**, **INCOMPLETO** o **AUTOCERTIFICADO**. `--fingerprint` debería proceder de un canal independiente; sin él, la clave se compara únicamente con el registro del operador. `python verify.py` Sigue verificando las pruebas ZIP por sí mismo, tal y como se describe en [«Pruebas](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/)». Las acciones del proveedor se clasifican: la creación y el inicio en los 30 minutos siguientes a la creación se aprueban; la consola, el rescate, el restablecimiento de contraseña, la reconstrucción, la ISO, las imágenes, las instantáneas, las copias de seguridad, Systems Manager, EC2 Instance Connect y las aperturas del cortafuegos se rechazan; las acciones relacionadas con la alimentación y cualquier otra acción no prevista se marcan para su revisión. Una acción desconocida nunca pasa desapercibida. ## Informe para la entrega de pruebas `--report report.md` redacta el informe en Markdown y `report.json` junto a él: 1. resultado, huella digital de la clave del recopilador, implementación, proveedor, confirmación, servidor, cortafuegos, túnel; 2. cada comprobación con su estado y su origen (API del proveedor, API de Cloudflare, extracto del recopilador, registro de pruebas); 3. el registro del proveedor con la evaluación de cada acción y, cuando el proveedor lo registra, el autor; 4. los puntos finales de Cloudflare que contienen las conexiones del túnel, la configuración y el registro de auditoría; 5. la declaración firmada del recopilador; 6. lo que el informe establece y lo que no; 7. los comandos para reproducirlo y el SHA-256 de cada archivo que se le proporcionó. Entrega el informe, `report.json`, `deployment.json`el instalador publicado y las pruebas ZIP. Elabora el informe con antelación: los registros de los proveedores se conservan durante un tiempo limitado. ## Cloudflare como testigo externo Todo lo que aparece aquí es opcional. El servidor sigue funcionando aunque no se disponga de una cuenta de Cloudflare, y dos de estas opciones funcionan actualmente: | ¿Qué? | Qué muestra | En TgWitness | | --- | --- | --- | | Túnel rápido o el túnel de tu dominio | Solo se puede acceder al panel a través del túnel | El asistente del servidor; véase más arriba. | | Relé drand `drand.cloudflare.com` | Los registros posteriores a una ronda de drand son más recientes que este: el diario se fue escribiendo sobre la marcha. | modo de pruebas, **Más testigos**, sin cuenta ([formato](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#optional-records-in-evidence-mode-drand-and-telegram-devices)) | | Notificaciones sobre el estado del túnel | cuando el túnel estaba inactivo, por correo electrónico o mediante un webhook de Cloudflare | Configúralos en el panel de control de Cloudflare | | DNS de Gateway (`--gateway-dns`, o **Cloudflare Gateway DNS** en el asistente) | cada nombre que el servidor consultó, respondido por Cloudflare a través de TLS; el cortafuegos de Hetzner impide que el DNS acceda a cualquier otra cosa; si una política de Gateway podría reescribir las respuestas | Hetzner, plan Zero Trust gratuito, sin dominio; `verify` comprueba el cortafuegos, la ubicación, el registro de actividades, las políticas, las consultas del servidor y el registro de auditoría; el modo de evidencia copia el registro en el diario | | Puerta de enlace con Cloudflare: un cliente One en el servidor, un cortafuegos de salida que solo permite el acceso a Cloudflare | cada conexión que ha establecido el servidor, no solo las de DNS | Aún no está desarrollado | | Acceso frente al panel | quién se ha conectado al panel y cuándo | No está implementado: requiere un dominio propio | | Registro de comandos SSH | cada comando en una sesión de depuración | Aún no está desarrollado | Logpush, que mantendría la copia propia de Cloudflare en R2, es una función de Enterprise: en el plan gratuito , Cloudflare responde `logpush is not enabled for this account`. Su registro de Gateway se conserva allí durante 24 horas, por lo que el «modo de evidencia» lo copia en el diario firmado (**el registro de Cloudflare Gateway de las consultas DNS de este servidor**, un token de solo lectura con «Account Analytics Read»). Sin un plan Zero Trust, una cuenta tiene una única ubicación DNS. Cuando Cloudflare rechaza otra, el servidor comparte la existente y sus consultas se distinguen por su dirección; ese filtro también necesita Zero Trust PII Read, y `destroy` deja una ubicación compartida. Una consulta de registro abarca como máximo tres horas, por lo que la copia y la `verify` lectura del día en intervalos de tres horas. El DNS de la puerta de enlace se encarga del resolutor del sistema. El DNS sobre HTTPS en el puerto 443 hacia otro resolutor, así como las conexiones a direcciones que no aparecen en ningún registro (como los centros de datos de Telegram, por ejemplo), no figuran en su registro. Cloudflare no puede ver el interior del cifrado de Telegram, otros dispositivos de la cuenta de Telegram (la lista de dispositivos del modo «evidence» los registra desde el lado de Telegram) ni el hipervisor del proveedor. ## Lectura del resultado de la implementación En el caso de una máquina virtual convencional, el proveedor controla la infraestructura del host, y el inventario local se comprueba junto con los registros del proveedor. En el caso de Intel TDX, el verificador comprueba además la cotización de hardware, el enlace del colector, la composición y las mediciones del sistema operativo. Lee los resultados individuales para ver qué comprobaciones se han superado o no estaban disponibles. Los detalles históricos del cortafuegos dependen del proveedor; Linode conserva las versiones de las reglas. El [registro de validación](https://phishdestroy.github.io/TgWitness/es/docs/reference/verification/) enumera las implementaciones probadas y las comprobaciones activas restantes, y [el alcance de la verificación](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#verification-scope) vincula estas comprobaciones del entorno con la adquisición y la integridad del archivo. --- # Telegram · Guía de paneles Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reference/panel/ Todas las pantallas del panel: chats, diario, fuentes, exportaciones, Extras, modos de protección y la comprobación de código. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Todas las pantallas del panel: chats, diario, fuentes, exportaciones, Extras, modos de protección y la comprobación de código. [TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [Documentación](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) · [Primeros pasos](https://phishdestroy.github.io/TgWitness/es/docs/reference/quickstart/) ![Primeros pasos](https://phishdestroy.github.io/TgWitness/assets/chapter-start.svg) [Primera configuración y ajustes](https://phishdestroy.github.io/TgWitness/es/docs/reference/settings/) · [Cuentas](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/) · [Exportar y verificar](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/) · [Informes de casos](https://phishdestroy.github.io/TgWitness/es/docs/reference/case-reports/) Qué hace cada pantalla, qué escribe en el diario firmado y dónde se encuentra la guía detallada. El panel muestra un espacio de trabajo cada vez: una cuenta de Telegram con sus propias fuentes, diario y clave de firma. El selector situado en la parte superior de la barra lateral permite cambiar de espacio de trabajo. La dirección identifica el espacio de trabajo (`?ws=…`); mientras la dirección, el selector y la cuenta cargada no coincidan, las acciones permanecerán bloqueadas. Utiliza [los métodos de comparación de colecciones](https://github.com/phishdestroy/TgWitness/blob/main/docs/COLLECTION-MODES.md) para elegir entre observación en tiempo real, historial completo, exportaciones recientes de cuentas o chats y transferencia de registros guardados. La página Exportaciones incluye la misma comparación encima de los controles de descarga. **En esta página** - [Orientación](https://phishdestroy.github.io/TgWitness/es/docs/reference/panel/#find-your-way) - [Empieza aquí](https://phishdestroy.github.io/TgWitness/es/docs/reference/panel/#start-here) - [Chats](https://phishdestroy.github.io/TgWitness/es/docs/reference/panel/#chats) - [Revista](https://phishdestroy.github.io/TgWitness/es/docs/reference/panel/#journal) - [Fuentes](https://phishdestroy.github.io/TgWitness/es/docs/reference/panel/#sources) - [Exportaciones](https://phishdestroy.github.io/TgWitness/es/docs/reference/panel/#exports) - [Configuración, cuentas y conexión](https://phishdestroy.github.io/TgWitness/es/docs/reference/panel/#settings-accounts-and-connection) - [Extras](https://phishdestroy.github.io/TgWitness/es/docs/reference/panel/#extras) - [Modos de protección](https://phishdestroy.github.io/TgWitness/es/docs/reference/panel/#protection-modes) - [Más herramientas](https://phishdestroy.github.io/TgWitness/es/docs/reference/panel/#more-tools) ## Oriéntate Las secciones diarias se encuentran en la parte superior de la barra lateral; **«Cuentas»** está debajo de **«Espacio de trabajo»** , y todo lo demás se encuentra en **«Más herramientas y ajustes** ». El selector **de nivel de interfaz** de la barra superior determina cuántas secciones aparecen: | Nivel | Secciones de la barra lateral | | --- | --- | | Sencillo | Inicio, Chats, Cambios, Archivos y Ajustes | | Estándar | Además, Case Board, Cuentas y Acceso | | Experto | También «Fuentes», «Extras», «Preguntar al archivo», «Parámetros», «Cuenta», «Registro del sistema» e «Integraciones». | Llamadas sencillas: «Empezar aquí», «Diario» y «Exportaciones», **«Inicio**», **«Cambios»** y **«Archivos**». Un nivel solo oculta secciones. Una función oculta sigue funcionando, y el servidor comprueba cada permiso por sí mismo. El nivel, el idioma, el tema y la zona horaria se guardan por operador y espacio de trabajo; consulta [la configuración](https://phishdestroy.github.io/TgWitness/es/docs/reference/settings/). La barra superior también incluye: - **Ve a una sección** (Ctrl+K, o ⌘K en un Mac): busca un chat, un parámetro o un registro del diario mediante `#number`. Las teclas de flecha permiten desplazarse; «Intro» abre y «Esc» cierra. - **Notificaciones**: problemas y cambios en los chats extraídos del diario. La opción **«Marcar todo como leído»** borra el contador y **«Reglas de notificación»** abre las reglas. El envío a Telegram, Discord o correo electrónico se configura en [Extras → Notificaciones](https://phishdestroy.github.io/TgWitness/es/docs/reference/panel/#notifications). - El indicador de conexión de este espacio de trabajo. **El estado del colector,** situado debajo de la barra superior, lo desglosa en conexión a Telegram, recepción de eventos, fuentes y cola de archivos adjuntos. - **Cerrar**: cierra el panel en este navegador. La colección sigue funcionando en el servidor. - El modo de protección que aparece junto al número de versión; consulta [los modos de protección](https://phishdestroy.github.io/TgWitness/es/docs/reference/panel/#protection-modes). El espacio de trabajo de demostración contiene mensajes ficticios y nunca se conecta a Telegram. Allí se rechazan las acciones que podrían modificar un espacio de trabajo real. ## Empieza aquí Elige una tarea. **«Exportar mi cuenta»** descarga todo lo que la cuenta puede leer en ese momento. **«Seguir una investigación»** registra los nuevos mensajes, las modificaciones observadas y los avisos de eliminación de los chats que elijas. La ficha de configuración muestra los tres pasos: conectar la cuenta, elegir fuentes e iniciar la observación. La pregunta de objetivo permanece en esta página hasta que la respondas o la omitas. En su lugar, un nuevo espacio de trabajo abre la [primera configuración](https://phishdestroy.github.io/TgWitness/es/docs/reference/settings/). ## Chats Conversaciones guardadas, de lectura solo por defecto. - Busca en la lista por nombre o ID. **La opción «Elegir»** añade o elimina chats seguidos. «**Abrir enlace de Telegram»** acepta un nombre de usuario o un enlace de invitación y guarda una vista previa en el diario. **«Unirse/abrir y observar»** se une al chat y lo añade a tus fuentes; al abrir un bot, este se envía `/start`. - El encabezado del chat cuenta los mensajes **eliminados, el texto conservado**, **los eliminados antes de guardarlos** y **los que no se encuentran al volver a comprobar**. La lista de chats y las notificaciones utilizan las mismas definiciones. Un mensaje eliminado aparece en rojo y conserva su texto guardado; un mensaje editado conserva todas las versiones guardadas. Cada eliminación indica lo que se sabe: cuándo se vio, que Telegram no informa de quién lo eliminó, o que solo llegó el aviso. - **El historial de carga** muestra los últimos 100, 250 o 500 mensajes en esta vista y en el diario. Para cargar todas las fuentes habilitadas, utiliza [Fuentes → Historial completo](https://phishdestroy.github.io/TgWitness/es/docs/reference/panel/#sources). - **La opción «Exportar chat»** descarga todo el historial visible como un `chat.json` y `chat.html`. Varias cuentas conectadas pueden compartir el trabajo: cada una descarga su propio rango de números de mensajes y firma su parte, y la cuenta que inicia la exportación firma el archivo. Véase [«Exportar un chat](https://github.com/phishdestroy/TgWitness/blob/main/docs/wiki/Chat-Export.md)». - **La sección «Personas»** muestra a todos los usuarios con mensajes guardados en este chat. Los perfiles de las personas están desactivados por defecto, ya que se trata de datos personales de terceros. Cuando están activados para un chat, el perfil muestra el nombre y el historial de nombres de usuario, las marcas de Telegram, los hash de los avatares, la actividad, quién responde a quién, otros chats observados y las carteras, teléfonos, nombres de usuario y enlaces mencionados. Cada dato apunta a su registro. **La exportación de perfiles** guarda un archivo firmado, opcionalmente protegido con contraseña ZIP; al desactivar los perfiles se elimina el archivo de perfiles. Consulta [los perfiles de los usuarios](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#people-profiles). - **La opción «Guardar perfil» ahora** registra una instantánea del perfil del chat o del bot: descripción, miembros, enlace de invitación y comandos del bot. ### Solo lectura, envío y secretos Dos interruptores situados encima de los mensajes protegen la cuenta y al lector: - **El modo de solo lectura** se activa al abrir un chat. Desactívalo para enviar mensajes o pulsar los botones del bot . Cada acción pregunta **«¿Enviar como @cuenta?**» o **«¿Pulsar este botón del bot como @cuenta?»**, lo que te indica que los miembros del chat lo verán y que se incluirá en el registro firmado. **La opción «No volver a preguntar durante 10 minutos en este chat»** omite la pregunta durante un rato. El envío está desactivado para el objetivo **«Pruebas de un caso**», tanto en el panel como en la API. - **«Mask secrets»** oculta lo que parece una contraseña, un código de inicio de sesión, una clave API o un hash, un token de bot, una cadena de sesión, una clave privada, un JWT o un número de tarjeta de pago (los números de tarjeta se comprueban con la suma de Luhn). **«Show»** revela un valor; la revelación se registra en el diario. También se registra la desactivación del enmascaramiento para este navegador. Solo cambia la visualización: los registros originales y todas las exportaciones conservan el texto completo. ## Registro Todos los registros que ha firmado el espacio de trabajo, ordenados de más reciente a más antiguo. - **La vista general** cuenta los mensajes observados, las ediciones registradas, los avisos de eliminación y las fuentes seleccionadas. - **Cronología de eventos** filtra por tipo de evento (todos, ediciones, eliminaciones, reacciones, pertenencia, cobertura), por texto y por fuente. **Cargar eventos anteriores** permite retroceder una página. - Abre un registro para ver sus detalles, su hash y su carga útil. **El enlace a este registro** es una dirección que abre el mismo registro. Los posibles datos confidenciales se ocultan en esta vista previa; las exportaciones conservan el original. - El registro es de solo adición: nada en el panel permite editar o eliminar un registro. Compruébalo en **Exportaciones → Verificar registro** o `python -m tgwitness.verify`; consulta [«Exportar y verificar](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/)». ## Fuentes Este espacio de trabajo registra determinadas conversaciones y conserva la información que considera relevante de ellas. Los cambios se aplican a la actividad futura; los registros guardados se mantienen. **La opción «Actualizar lista de chats»** lee los chats y las carpetas de la cuenta. No descarga mensajes. ### Ámbito de aplicación - **Qué registra esta cuenta** : **Chats seleccionados** (solo los chats que añadas), **Carpeta de Telegram** (una de las carpetas de la cuenta, incluidos los chats añadidos a ella posteriormente) o **Cuenta completa** (todos los chats, así como cada nuevo chat, grupo, chat privado o bot a medida que aparezca). **Modo de investigación** es para una cuenta dedicada: registra todo lo que ve la cuenta, sus propios mensajes y las pulsaciones de botones, y guarda inmediatamente el perfil de cada nuevo chat y los mensajes visibles anteriores. La imagen [Guía dedicada a las cuentas](https://phishdestroy.github.io/TgWitness/docs/dedicated-account/) explica por qué nunca debes utilizar tu cuenta principal. - **Los tipos de fuente** limitan los modos de carpeta y de cuenta completa a canales, grupos, chats privados y bots. **«Acciones propias»** añade los mensajes propios de la cuenta, las ediciones y las pulsaciones del teclado al responder. - **Cuando aparece un nuevo chat o bot**: guarda su perfil y hasta el número elegido de sus últimos mensajes visibles. Limitaciones: el recopilador en la nube publicado no recibe chats secretos. La [interfaz Pseudo-secret, independiente, y su demostración](https://phishdestroy.github.io/TgWitness/es/docs/reference/secret-chats/) se documentan con su estado de desarrollo y los defectos pendientes. No se registra nada mientras TgWitness no esté en ejecución; tras un reinicio, solo recoge lo que Telegram sigue devolviendo, y el informe muestra la diferencia. Los chats que superen el límite de la lista de chats (1,000 diálogos, salvo que se modifique en Parámetros) se añaden la próxima vez que se activen. Los botones del bot integrados en otra aplicación son invisibles; se registra la respuesta del bot. ### Chats incluidos Filtra por estado (**Activado**, **En pausa**, **Prioritario**, **Excluido**, **Acceso no confirmado**, **Ignorado**) y tipo, y luego realiza acciones sobre la selección: activar, poner en pausa, marcar o eliminar la prioridad, excluir del ámbito o eliminar. La insignia de estado solo muestra el estado; las acciones se encuentran en el menú de cada fila, con una descripción de lo que hacen. La pausa y la exclusión requieren confirmación, también de forma masiva. Al eliminar una fuente, se solicita su nombre y se borran los perfiles de sus usuarios ; sus registros guardados permanecen en el diario. Una fuente que no aparece en la lista de chats de la cuenta es **recibir actualizaciones, no en la lista de chats**, mientras siguen llegando registros; en caso contrario, **Acceso sin confirmar**. **Chats disponibles** añade chats con **Añadir seleccionados** o **Añadir todas las coincidencias**. ### Historial completo Carga el historial disponible de cada fuente habilitada en «Chats» y en el diario. El progreso se conserva tras un reinicio; los archivos adjuntos se ajustan a tu configuración multimedia. Consulta [el historial de la fuente](https://phishdestroy.github.io/TgWitness/es/docs/reference/history/). ### Grabación - **Elige qué cambios quieres conservar**: mensajes nuevos, ediciones, avisos de eliminación, reacciones visibles, altas y bajas. Un ajuste preestablecido modifica el formulario; la **opción «Guardar configuración de grabación»** lo aplica. Volver a activar una categoría no recupera los eventos perdidos. - **Conserva los archivos multimedia cuando estén disponibles**: descarga archivos adjuntos hasta un tamaño máximo por archivo, establece por tipo entre 1 y 2.000 MiB, y limita la duración de los vídeos en segundos (0 significa que no hay límite). Cada intento de descarga genera un resultado registrado. - **Revisión**: los chats prioritarios se comprueban cada pocos minutos, los demás chats rara vez, de modo que la cuenta no supera los límites de FloodWait de Telegram. El valor 0 desactiva un grupo. Marca los chats prioritarios con la estrella en la lista; el número de chats por pasada y la pausa entre chats se configuran en «Parámetros». Consulta [la colección](https://phishdestroy.github.io/TgWitness/es/docs/reference/collection/). ## Exportaciones **«Descargas»** prepara los archivos; **«Informe de compilación»** determina el aspecto de los informes. | ¿Qué? | Úsalo para | Guía | | --- | --- | --- | | Exportación de cuentas | Una instantánea actualizada de lo que la cuenta puede leer ahora | [Exportación de cuentas](https://phishdestroy.github.io/TgWitness/es/docs/reference/account-export/) | | Compartir copia | Una versión simplificada de una exportación de cuenta completada | [Divulgación](https://phishdestroy.github.io/TgWitness/es/docs/reference/account-export/#prepare-a-disclosure-for-a-lawyer-or-another-recipient) | | Firmado ZIP | Diario, informe, archivos adjuntos y herramientas de verificación dentro de un límite fijo del diario | [Exportar y verificar](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/) | | Informes en HTML, PDF y JSON | Un informe sellado y legible | [Informes de casos](https://phishdestroy.github.io/TgWitness/es/docs/reference/case-reports/) | | JSONL, CSV | Registros originales con firmas; una hoja de cálculo con fórmulas protegidas | [Exportar y verificar](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/) | | Extracto del traspaso | Solo los chats, el periodo y las personas que necesita el destinatario | [Pruebas](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#investigation-handoff) | | Exportación de chats | Un chat firmado `chat.json` y `chat.html` | [Exportar un chat](https://github.com/phishdestroy/TgWitness/blob/main/docs/wiki/Chat-Export.md) | - **Al cifrar las descargas anteriores con una contraseña** (de 12 caracteres o más), se guarda un archivo AES-256 ZIP que se puede abrir con 7-Zip o WinRAR. El archivo firmado que contiene permanece inalterado. La contraseña no se almacena. - **Las exportaciones preparadas** conservan hasta 20 archivos de un máximo de 2 GiB, más el más reciente, para descargas repetidas, cada uno con su SHA-256. La preparación de un archivo no garantiza su entrega. - Cuando el navegador rechaza el cuadro de diálogo de guardado, el panel recurre a una descarga normal. - **Tu identidad de firma** muestra la huella digital de la clave. Las opciones **«Guardar punto de control»** y «Descargar **recibo de ejecución firmado»** te permiten conservar los registros fuera del colector. La opción «Preparar **solicitud de marca de tiempo»** genera una solicitud RFC 3161 sin contactar con ningún servicio. ## Configuración, cuentas y conexión - **Configuración**: objetivo, conexión, qué grabar y la interfaz. Consulta [la primera configuración y los ajustes](https://phishdestroy.github.io/TgWitness/es/docs/reference/settings/). - **Cuentas**: cada espacio de trabajo con su estado, fuentes, eventos y cola de archivos adjuntos. Filtrar por **«Requiere atención»**, **«Recopilando»**, **«Desconectado» o «Pausado»** o **«No conectado»**, pausar o reanudar una selección, importar archivos de cuentas de forma masiva y gestionar grupos. Ver [cuentas](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/). - **Cuenta**: inicio de sesión y ruta de conexión de esta cuenta. Directa, un perfil de WireGuard, tu propio proxy, el grupo público de MTProto o WARP; prepara y comprueba una ruta, y luego aplícala a esta cuenta, a un grupo o a todas las cuentas. Consulta [«Conexión» y](https://phishdestroy.github.io/TgWitness/es/docs/reference/connection/)[«Proxies](https://github.com/phishdestroy/TgWitness/blob/main/docs/wiki/Proxies.md)». ## Extras Opcional: basta con una cuenta y unas fuentes para empezar a recopilar información. Solo la opción que elijas abre su configuración, y nada se conecta automáticamente. La tarjeta **«Nivel de protección»,** situada en la parte superior, muestra el [modo de protección](https://phishdestroy.github.io/TgWitness/es/docs/reference/panel/#protection-modes). | Tarjeta | Qué aporta | Guía | | --- | --- | --- | | Almacenamiento y espacio en disco | Copias de seguridad, traslado de archivos antiguos a tu nube, una copia de prueba que no se puede eliminar | [Almacenamiento](https://phishdestroy.github.io/TgWitness/es/docs/reference/storage/) | | Objetivo y nivel de protección | Configuración recomendada para tu objetivo y dos escalas | [a continuación](https://phishdestroy.github.io/TgWitness/es/docs/reference/panel/#goal-and-protection-level) | | Notificaciones | Problemas, mensajes modificados y un resumen diario; tu propio bot de control | [a continuación](https://phishdestroy.github.io/TgWitness/es/docs/reference/panel/#notifications) | | Pruebas y copias de seguridad | Marcas de tiempo, más testigos y una copia cifrada externa | [a continuación](https://phishdestroy.github.io/TgWitness/es/docs/reference/panel/#evidence-and-backups) | | Servidor disponible las 24 horas del día, los 7 días de la semana | Un servidor en la nube sin SSH, que se crea y se elimina desde el panel | [Alta fiabilidad](https://phishdestroy.github.io/TgWitness/es/docs/reference/high-assurance/#from-the-panel) | | Testigo independiente | Comprobantes firmados publicados en tu canal de Telegram o en Discord | [Testigo](https://phishdestroy.github.io/TgWitness/es/docs/reference/witness/) | | Revisión del código | Compara el programa en ejecución con una confirmación pública de GitHub. | [a continuación](https://phishdestroy.github.io/TgWitness/es/docs/reference/panel/#code-check) | ### Objetivo y nivel de protección Cuatro preguntas: 1. **¿Para qué sirve? Para** un registro personal, una investigación o como prueba en un caso. 2. **¿Cuánto vas a supervisar?** Unos pocos chats (hasta unos 50), muchos chats (hasta unos 500) o cuentas completas. Esto establece el límite de la lista de chats en 1.000, 3.000 o 20.000. 3. **¿Fotos y archivos?** Solo texto, fotos y archivos multimedia cortos (fotos de 20 MB, vídeos de 100 MB), o todo (vídeos y documentos de hasta 1 GB cada uno). La opción «Todo» con cuentas completas también deja 4 GiB de espacio libre en disco. 4. **¿Dónde se ejecutará? En** este ordenador o en un servidor que esté siempre encendido. La sugerencia enumera marcas de tiempo independientes, drand y la lista de dispositivos de Telegram, cada una con una línea que explica lo que aporta. Las marcas de tiempo se inician cada 60, 30 o 10 minutos para un registro personal , una investigación o pruebas; drand y la lista de dispositivos necesitan marcas de tiempo. **Aplica** cambios solo a estos, a la política de archivos adjuntos y a los dos parámetros anteriores. Cada cambio es un registro del diario, además de `setup.applied`. Las notificaciones, una copia externa, un servidor, el DNS de la puerta de enlace, la comprobación del código y un testigo se ofrecen como pasos siguientes con sus propios formularios. Se calculan dos escalas a partir de lo que se ha configurado, no a partir del objetivo: | Escala | Puntos | | --- | --- | | Credibilidad | Diario firmado 1, marcas de tiempo 3, drand 1, lista de dispositivos 1, comprobación de código que coincide 1, sondeo de testigos 1, servidor certificado 2, registro DNS de Gateway 1 | | Fiabilidad | Servidor siempre activo: 3; copia externa: 3; Object Lock: 1; notificaciones de problemas: 1 | Un 80 % o más se considera **«máximo»**, un 50 % **«alto»**, un 25 % **«moderado**» y por debajo de eso, **«básico**». La fiabilidad se calcula actualmente en función de un servidor siempre activo, según la respuesta a la pregunta 4, antes de que se compruebe ningún servidor. ### Notificaciones Las notificaciones se envían a través de Apprise a Telegram, Discord, Slack, ntfy, correo electrónico, Matrix y más de 100 servicios adicionales. Elige un servicio, rellena uno o dos campos y envía una prueba, o pega directamente las direcciones de Apprise. - **Problemas**: disco casi lleno, cuenta desconectada, errores de recopilación, copia o marca de tiempo. En un servidor sellado, un puerto SSH abierto o un inicio de sesión también suponen un problema. - **Cambios**: mensajes eliminados, editados y que faltan en los chats observados, agrupados en una notificación por comprobación (cada minuto, a menos que se modifique en «Parámetros»). - **Tareas completadas**: historial, exportaciones y copias de seguridad. - **Resumen diario** a la hora elegida, según la hora del servidor. Las notificaciones incluyen los nombres de los chats y el número de mensajes. Los extractos de mensajes están desactivados por defecto; si se activan, el texto de los mensajes sale de este equipo. **Tu bot operador** es un bot propio creado desde @BotFather que responde `/status` y `/stats`, y, opcionalmente, `/pause`, `/resume` y `/copy`. Solo el chat indicado y los ID de usuario de Telegram pueden utilizarlo; el texto de la conversación permanece en el espacio de trabajo. Utiliza un bot independiente si otra aplicación ya recibe sus comandos. Consulta [notificaciones](https://github.com/phishdestroy/TgWitness/blob/main/docs/wiki/Notifications.md) y [bot operador](https://phishdestroy.github.io/TgWitness/es/docs/reference/storage/#operator-bot-and-completion-notices). ### Pruebas y copias de seguridad - **Las marcas de tiempo independientes** envían únicamente el SHA-256 de cada punto de control firmado a las autoridades de la RFC 3161 y a los calendarios de OpenTimestamps, cada 5 a 1.440 minutos. **Anchor ahora** ejecuta una pasada. Véanse [las marcas de tiempo](https://phishdestroy.github.io/TgWitness/es/docs/reference/timestamp/). - **Más testigos**, cada uno inactivo hasta que se elija: la ronda más reciente de drand, la lista de Telegram de dispositivos conectados sin direcciones IP y el registro de Cloudflare Gateway de las consultas DNS del servidor. Véanse [los registros opcionales](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#optional-records-in-evidence-mode-drand-and-telegram-devices). - **La copia de seguridad cifrada** copia el diario, los archivos, los puntos de control y las exportaciones de chats a un almacenamiento compatible con S3 (Wasabi, Amazon S3, Backblaze B2, Cloudflare R2, MinIO). Todo se cifra primero en esta máquina. **Descarga la clave de cifrado** y guárdala por separado: sin ella, la copia no se puede leer. Object Lock, en modo «Governance» o «Compliance», impide que los objetos se eliminen durante un número determinado de días. Véase [«Copia externa](https://github.com/phishdestroy/TgWitness/blob/main/docs/wiki/Off-site-Copy.md)». ### Revisión del código Comprueba si el programa instalado coincide con una versión publicada. 1. Introduce un repositorio de GitHub (el oficial ya está rellenado) y una etiqueta, una rama o una confirmación. 2. **«Check now»** consulta la API de GitHub, a través de la ruta de este espacio de trabajo para solicitudes externas, la lista de archivos de esa confirmación. Compara el ID de blob de Git de cada archivo de programa medido con la confirmación. Una copia de Windows con finales de línea convertidos sigue coincidiendo. 3. El resultado muestra una lista de los archivos modificados, añadidos y que faltan (hasta 50 de cada tipo) y se guarda como un `source.checked` registro de diario. El resultado solo se considera vigente mientras los archivos del programa en ejecución no sufran cambios: vuelve a comprobarlo tras una actualización. No se necesita ningún token y solo funcionan los repositorios públicos; no se suben chats ni credenciales. Una coincidencia identifica el código en el disco. No se trata de una certificación de hardware; para eso, consulta [Phala Cloud](https://phishdestroy.github.io/TgWitness/es/docs/reference/high-assurance/#confidential-vm-on-phala-cloud-intel-tdx). ## Modos de protección El selector situado junto al número de versión muestra el modo elegido y cuántas de las 18 capas de protección están activas; por ejemplo `🟠 Witnessed 9/18`. **Para cambiar de modo,** en **«Extras» → «Nivel de protección»** se abre el menú de opciones. Cada modo describe un objetivo y enumera lo que aún falta; el registro, la firma y la configuración guardada son iguales en todos los modos. | Modo | Para | Añade | | --- | --- | --- | | 🟢 Fácil | Seguir un chat y guardar una copia | Chats, el diario y las exportaciones de chats; la firma se ejecuta en segundo plano. | | 🟡 Firmado | Informes dirigidos a una plataforma, un proveedor de alojamiento o un servicio de denuncia de abusos | Archivo firmado, comprobación del diario, puntos de control, extracto de traspaso | | 🟠 Testificado | Casos en los que alguien podría alegar que el registro ha sido modificado | Un testigo independiente que publica entradas firmadas en el diario | | 🔴 Apto para los tribunales | Pruebas para un abogado, la policía o un tribunal | Marcas de tiempo, una copia cifrada externa y detalles del caso en informes | | 🟣 Verificado por GitHub | Registros cuyo software debe poder comprobar cualquiera. | Comprobación del código y captura de GitHub Actions | | ⚫ Mossad | Casos de gran envergadura contra un adversario con abundantes recursos | Un servidor sellado disponible las 24 horas del día, los 7 días de la semana, una dirección IP oculta y las 18 capas completas | Las capas: cada registro firmado y encadenado; un recibo de ejecución firmado; archivos adjuntos guardados con SHA-256; puntos de control firmados; revisiones; alertas de problemas; acceso de testigo de solo lectura; un testigo que realiza comprobaciones según lo programado; marcas de tiempo RFC 3161; pruebas OpenTimestamps; una última marca de tiempo verificada; una copia cifrada fuera del sitio; detalles del caso en informes; una comprobación de coincidencia de código ; Telegram nunca ve la IP de este equipo; solicitudes externas a través de un proxy; Object Lock en la copia; un servidor sellado con los registros del proveedor. Una capa que está desactivada tiene **la opción «Configurar»**, que abre su formulario. Al elegir un modo inferior, se solicita confirmación y no se elimina nada. ## Más herramientas **Extras → Independent capture**: connect a separate browser or AyuGram recorder, pin its signing key, select capture options, start/pause, take snapshots and download verified signed archives. Each recorder has its own manual login, route, journal and key. Both connections start disabled. See the English [Independent capture guide](https://github.com/phishdestroy/TgWitness/blob/main/docs/OPTIONAL-CAPTURE.md). - **Consulta el archivo**: busca observaciones guardadas, revisa las fuentes y, a continuación, decide si enviarlas a un modelo de IA. Consulta [el análisis del archivo](https://phishdestroy.github.io/TgWitness/es/docs/reference/analysis/) y [el OCR y la transcripción locales](https://phishdestroy.github.io/TgWitness/es/docs/reference/media-analysis/). - **Parámetros**: límites y ritmo de recopilación, revisiones, descargas, perfiles, notificaciones y exportaciones. Búsqueda por nombre, mostrar **«Solo** valores **modificados»** y preparar los valores predeterminados como borrador con **«Restaurar valores predeterminados…». «Guardar parámetros»** aplica los valores a partir de su próximo uso, y cada cambio se registra en el diario. - **Acceso**: tokens independientes para revisores, analistas y operadores, limitados a determinados espacios de trabajo, chats y derechos. Véase [«Acceso](https://phishdestroy.github.io/TgWitness/es/docs/reference/access/)». - **Registro del sistema** : lo que ha hecho este proceso desde que se inició (conexiones, cambios de proxy, inicios de sesión, rechazos, cambios de configuración) con las direcciones IP ocultas. La opción **«Seguir nuevas líneas»** mantiene visible la línea más reciente. Los mensajes permanecen únicamente en el diario. - **Integraciones**: el proveedor de IA, conexiones [MCP de solo lectura](https://phishdestroy.github.io/TgWitness/es/docs/reference/mcp/) y [webhooks firmados](https://phishdestroy.github.io/TgWitness/es/docs/reference/webhooks/). - **Case Board**: notas privadas del equipo, marcadores y fragmentos junto a las pruebas. Véase [Case Board](https://phishdestroy.github.io/TgWitness/es/docs/reference/case-board/). - **Captura de GitHub Actions** en «Exports»: un chat capturado desde tu bifurcación. Véase [captura sellada](https://github.com/phishdestroy/TgWitness/blob/main/docs/SEALED-ACTIONS.md). --- # Telegram · Cómo funciona la recopilación Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reference/collection/ Ámbito de observación, actualizaciones en tiempo real, verificaciones cruzadas, archivos adjuntos, acciones propias y qué significa una laguna, registro por registro. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Ámbito de observación, actualizaciones en tiempo real, verificaciones cruzadas, archivos adjuntos, acciones propias y qué significa una laguna, registro por registro. [TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [Documentación](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) · [Colección](https://github.com/phishdestroy/TgWitness/blob/main/docs/COLLECTION-MODES.md) ![Recopilación](https://phishdestroy.github.io/TgWitness/assets/chapter-collect.svg) TgWitness registra lo que observa una cuenta de Telegram conectada. El registro conserva esas observaciones, su secuencia y el contexto que las acompaña. No infiere acciones no observadas a partir de la ausencia de un mensaje o de que una cuenta esté conectada. **En esta página** - [Desde el inicio de sesión hasta un diario](https://phishdestroy.github.io/TgWitness/es/docs/reference/collection/#from-login-to-a-journal) - [Ámbito de observación: chats seleccionados, una carpeta o toda la cuenta](https://phishdestroy.github.io/TgWitness/es/docs/reference/collection/#observation-scope-chosen-chats-a-folder-or-the-whole-account) - [Ámbito de aplicación y selección de eventos](https://phishdestroy.github.io/TgWitness/es/docs/reference/collection/#scope-and-event-selection) - [Acciones propias](https://phishdestroy.github.io/TgWitness/es/docs/reference/collection/#own-actions) - [Modo de investigación: unirse a equipos y hablar con bots](https://phishdestroy.github.io/TgWitness/es/docs/reference/collection/#investigation-mode-joining-teams-and-talking-to-bots) - [Niveles de reverificación](https://phishdestroy.github.io/TgWitness/es/docs/reference/collection/#recheck-tiers) - [Historial de mensajes y atribución](https://phishdestroy.github.io/TgWitness/es/docs/reference/collection/#message-history-and-attribution) - [Instantáneas históricas](https://phishdestroy.github.io/TgWitness/es/docs/reference/collection/#history-snapshots) - [Gestión de archivos adjuntos](https://phishdestroy.github.io/TgWitness/es/docs/reference/collection/#attachment-handling) - [Pausar, bloquear, desconectar y reiniciar](https://phishdestroy.github.io/TgWitness/es/docs/reference/collection/#pause-lock-disconnect-and-restart) - [Aislamiento y verificación de cuentas](https://phishdestroy.github.io/TgWitness/es/docs/reference/collection/#account-isolation-and-verification) ## Desde el inicio de sesión hasta el registro Para fotos y archivos autodestructibles, véase «[Medios autodestructibles](https://github.com/phishdestroy/TgWitness/blob/main/docs/EPHEMERAL-MEDIA.md)». En él se explican el priority worker, los resultados guardados y no disponibles, y los límites del bloqueo de los acuses de lectura en el recopilador de la API. Diagrama de flujo · Autorizar una cuenta de usuario → Seleccione grupos y canales accesibles; Seleccione grupos y canales accesibles → Guardar la configuración de eventos y archivos adjuntos; Guardar la configuración de eventos y archivos adjuntos → Iniciar la observación; Iniciar la observación → Reciba actualizaciones del cliente activo; Reciba actualizaciones del cliente activo → Aplicar la política de fuentes y eventos; Aplicar la política de fuentes y eventos → Añada una observación firmada; Añada una observación firmada → Revisar o exportar el registro; Añada una observación firmada → Procesar cualquier archivo adjunto en cola; Procesar cualquier archivo adjunto en cola → Añada el resultado de la descarga · Autorizar una cuentade usuario · Seleccione grupos ycanales accesibles · Guardar laconfiguración deeventos y archivosadjuntos · Iniciar la observación · Reciba actualizacionesdel cliente activo · Aplicar la política defuentes y eventos · Añada una observaciónfirmada · Revisar o exportar elregistro · Procesar cualquierarchivo adjunto encola · Añada el resultado dela descarga **Diagrama en formato de texto** 1. Autorizar una cuenta de usuario → Seleccione grupos y canales accesibles 2. Seleccione grupos y canales accesibles → Guardar la configuración de eventos y archivos adjuntos 3. Guardar la configuración de eventos y archivos adjuntos → Iniciar la observación 4. Iniciar la observación → Reciba actualizaciones del cliente activo 5. Reciba actualizaciones del cliente activo → Aplicar la política de fuentes y eventos 6. Aplicar la política de fuentes y eventos → Añada una observación firmada 7. Añada una observación firmada → Revisar o exportar el registro 8. Añada una observación firmada → Procesar cualquier archivo adjunto en cola 9. Procesar cualquier archivo adjunto en cola → Añada el resultado de la descarga La autorización, el acceso a una fuente, un recopilador en funcionamiento y la entrega completa son cuestiones distintas. Un inicio de sesión correcto no garantiza el acceso a todos los grupos. Una conexión de transporte no garantiza que se hayan recibido todas las actualizaciones pertinentes. ## Ámbito de observación: chats seleccionados, una carpeta o toda la cuenta Fuentes → **El ámbito de observación** determina qué chats registra un espacio de trabajo. | Modo | Registros | Nuevos chats | | --- | --- | --- | | Chats seleccionados (por defecto) | Solo los chats que añada manualmente | Nunca se añade automáticamente | | Carpeta de Telegram | Chats en una de las carpetas de la cuenta: chats incluidos por nombre, más las categorías de la carpeta (contactos, no contactos, grupos, canales, bots), menos los chats excluidos y, si así lo indica la carpeta, los chats archivados | Los chats correspondientes se añaden tan pronto como se activan; los chats que añada a la carpeta en Telegram se recogen en el plazo de una hora. | | Cuenta completa | Todas las conversaciones que recibe la cuenta | Cada nuevo chat, grupo, chat privado o bot se añade en el momento en que se produce su primera actualización. | - **Los tipos de fuente** (canales, grupos, chats privados, bots) delimitan los modos de carpeta y de cuenta completa. Los chats seleccionados pueden ser de cualquier tipo, incluidos los chats privados y los bots. - **Los chats excluidos** nunca se registran, en ningún modo. En los modos «por carpeta» y «cuenta completa», las opciones *«Excluir»* y *«Eliminar»* en una fuente la incluyen en esta lista, por lo que el ámbito de aplicación no la añade de nuevo. Si vuelve a seleccionar el chat manualmente (en «Fuentes» o desde «Chats»), se elimina de la lista. La lista tiene capacidad para un máximo de 5.000 chats; si se supera ese límite, no se acepta *la opción «Eliminar»* y, en su lugar, se puede pausar el chat. - **Acciones propias** (activadas por defecto): los mensajes que envía esta cuenta, sus modificaciones y las pulsaciones del botón del teclado de respuesta. Si se desactiva, se omiten los mensajes salientes y las modificaciones. - Al cambiar a una carpeta o a toda la cuenta, se solicita confirmación: estos modos graban chats privados y mensajes de terceros, y deben utilizarse únicamente en una cuenta dedicada. La confirmación y cada cambio de ámbito se registran en registros firmados con `scope.changed`. - Los chats añadidos por el filtro aparecen como fuentes marcadas *como «auto»*, registradas como `scope.applied` (al inicio y cada hora) o `source.discovered` (un nuevo chat durante la observación). Al volver a los chats seleccionados, se pausan todas las fuentes añadidas automáticamente. Lo que estos modos no pueden hacer: - **Los chats secretos** quedan fuera de estos modos de recopilación en la nube. Existe una [implementación de chats secretos](https://phishdestroy.github.io/TgWitness/es/docs/reference/secret-chats/) en fase de desarrollo; no está incluida en el recopilador publicado en la revisión documentada allí. - **No se registra nada mientras TgWitness no esté en funcionamiento.** Tras un reinicio, solicita a Telegram las actualizaciones perdidas y vuelve a comprobar los chats, pero Telegram no devuelve toda la información tras interrupciones prolongadas. Los informes y `verify.py` muestran dichos periodos como lagunas (véase [«cobertura»](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#coverage-continuity-gaps-and-unobserved-ids)). - Al inicio solo se muestran los primeros 1.000 diálogos (el límite se encuentra en **«Parámetros»**); los chats más antiguos se añaden la próxima vez que se activen. No se recupera el historial anterior de un chat añadido; realice una captura del historial o una exportación completa del chat cuando lo necesite. - No se aplican las condiciones de las carpetas que cambian constantemente (silenciadas, leídas): dichos chats siguen siendo objeto de observación. - **Los botones del bot integrados (de devolución de llamada)** pulsados en otra aplicación son invisibles para una segunda sesión; se registra la respuesta o la edición del bot. Las pulsaciones del teclado de respuesta llegan como mensajes salientes y se etiquetan como `button_press`. - Un mayor número de chats implica un mayor número de solicitudes. Telegram restringe las cuentas cuyo volumen considera excesivo, lo que constituye una razón más para utilizar cuentas específicas. ## Ámbito de aplicación y selección de eventos Cada espacio de trabajo cuenta con sus propias fuentes. TgWitness no se une a grupos, no acepta invitaciones ni enumera automáticamente a todos los miembros. Las fuentes deben estar ya accesibles para la cuenta. Al iniciarse, el recopilador compara las fuentes seleccionadas con los diálogos visibles de la cuenta; se inspeccionan los primeros 1.000 diálogos, salvo que se indique lo contrario en **«Parámetros → Chats leídos de la lista de la cuenta**». Una fuente ausente se marca como **«acceso no confirmado**», sin que se dé por hecho que le haya eliminado. | Configuración | Recopila | Efecto cuando está desactivado | | --- | --- | --- | | Nuevos mensajes | Mensajes entregados normales | Es posible que las modificaciones o eliminaciones posteriores no tengan texto capturado anteriormente con el que compararlas. | | Modificaciones | Versiones editadas de los mensajes entregadas | Los cambios intermedios no se reconstruyen posteriormente. | | Eliminaciones | Notificaciones de eliminación con alcance específico y notificaciones a nivel de cuenta sin alcance específico | Las notificaciones de eliminación no se añaden al registro. | | Reacciones | Instantáneas de las reacciones recabadas | No se añaden actualizaciones de reacciones por separado. | | Afiliación | Se han enviado mensajes de servicio a los miembros y actualizaciones a los participantes | No se incluyen las observaciones de los miembros. | La configuración se aplica a todas las fuentes seleccionadas en el espacio de trabajo. Guarde el formulario para aplicar los cambios; estos se registran con valores firmados «antes» y «después». Desactivar una categoría no elimina los registros anteriores. Volver a activarla no recupera las actualizaciones perdidas. Los registros operativos y otros eventos del servicio de grupo permanecen independientes de estos ajustes. Los mensajes de servicio relacionados con la afiliación pueden generar registros de mensajes cuando la afiliación está habilitada, incluso si la captura habitual de nuevos mensajes está desactivada. Los objetos de Telegram capturados conservan los metadatos incrustados; un ajuste no es una regla de censura. **Las eliminaciones en chats privados y grupos normales** se registran como identificadores de mensaje sin chat asociado. Estos chats comparten una secuencia de identificadores de mensaje válida para toda la cuenta, por lo que, cuando un mensaje con ese identificador se ha guardado anteriormente, se conoce su chat: la eliminación se registra en ese chat, y `chat_resolution` explica cómo. Los identificadores que nunca se han guardado permanecen como una **eliminación sin contexto** con una fuente explícitamente desconocida; el recopilador no hace conjeturas. Telegram nunca indica quién ha eliminado un mensaje; cuando el mensaje eliminado fue enviado por esta cuenta, el registro así lo indica (`deleted_message_was_outgoing`) sin nombrar al autor de la eliminación. ## Acciones propias Los mensajes enviados por la cuenta observada se etiquetan como `outgoing`. Una modificación de un mensaje saliente indica que, en los chats privados y los grupos, solo su autor puede modificarlo, mientras que las publicaciones en canales pueden ser modificadas por otros administradores. Cuando un mensaje saliente repite el texto de un botón del teclado de respuesta guardado más reciente en ese chat, lleva la etiqueta «`button_press`» con un enlace al registro de dicho teclado. La exclusión de las acciones propias también se aplica a las revisiones de antecedentes y al historial automático de nuevos chats. Los mensajes salientes omitidos adelantan la posición de revisión, de modo que no puedan bloquear los mensajes entrantes posteriores. Las acciones explícitas en el panel y las instantáneas del historial solicitadas manualmente siguen quedando registradas. ## Modo de investigación: unirse a grupos y comunicarse con bots **Fuentes → Ámbito de observación → El modo de investigación** prepara el ámbito para una cuenta dedicada que se une a chats de equipo, inicia bots y escribe en ellos: toda la cuenta, cada tipo de fuente, las acciones propias y, para cada chat o bot que aparezca, su perfil y sus últimos 200 mensajes visibles. Revise el formulario y pulse **«Guardar ámbito»**; el cambio a toda la cuenta requiere la confirmación habitual. - **Botones.** Los botones que aparecen debajo de un mensaje se conservan junto a él y se muestran en **«Chats**»: enlaces, aplicaciones web, enlaces de inicio de sesión, textos para copiar, datos de devolución de llamada, consultas en línea, solicitudes de un número de teléfono o una ubicación. Los enlaces se muestran como texto y el panel nunca los abre. Cuando un bot solo modifica los botones (por ejemplo, un nuevo enlace de pago), se considera una nueva versión del mensaje, tanto en las actualizaciones en tiempo real como en las revisiones posteriores. - **Nuevos chats y bots.** En los modos «por carpeta» y «cuenta completa», **cuando aparece un nuevo chat o bot**, se guarda inmediatamente después de su aparición: - su perfil como registro `source.profile`: descripción del bot y comandos, el texto de «Acerca de» de un usuario, grupo o canal, miembros, chat vinculado y enlace de invitación cuando Telegram lo proporcione; - sus últimos mensajes visibles (hasta 1.000) como una instantánea del historial marcada con `new_chat`: los mensajes anteriores de un chat de grupo al que acaba de unirse, o lo que dijo un bot antes de que la observación detectara el chat. Los mensajes ya guardados en tiempo real no se repiten. Los chats que ya figuran en la lista cuando se activa el modo se añaden sin instantáneas. Un FloodWait pausa esta tarea y se reanuda posteriormente; los fallos se registran y la grabación en directo del chat continúa. Esto incluye las esperas mientras se resuelve la identidad del nuevo chat: la tarea pendiente de perfil/historial se conserva para volver a intentarla, y una espera más larga ya existente a nivel de cuenta no se acorta. - **Perfiles bajo petición.** **Chats → Perfil → Guardar perfil ahora** guarda el perfil actual de cualquier fuente; el más reciente se muestra encima de los mensajes. - **Instantáneas del estado del chat (vista previa).** El estado fuera del flujo de mensajes cambia sin que haya un mensaje: al desanclar todos los mensajes no queda ningún rastro a nivel de mensaje, un administrador pierde sus derechos, un regalo se oculta, se convierte, se actualiza o se reembolsa. Durante la observación, cada fuente habilitada se lee periódicamente y se guarda como un registro `chat.state` firmado: título, nombres de usuario, descripción, recuento de miembros y administradores, chat vinculado, modo lento, ID de mensajes fijados (hasta 100), administradores con sus derechos y títulos, y regalos mostrados en los canales y perfiles de usuario (hasta 100). Cada registro enumera las diferencias con respecto a la instantánea anterior: campos modificados con su estado anterior y posterior, mensajes fijados añadidos o eliminados, administradores y regalos añadidos, modificados o que ya no aparecen en la lista. Telegram no indica quién ha realizado cambios ni cuándo se han producido entre una instantánea y otra. - Una parte que Telegram rechaza (por ejemplo, la lista de administradores de un canal para un miembro que no es administrador) se indica en `errors`; su valor anterior se conserva y se muestra en `carried_forward`, sin que se informe nunca de su eliminación. - Un registro cuyos únicos cambios sean recuentos, y una comprobación que no haya detectado ningún cambio, hace referencia al último estado completo con `state_seq` y `state_overrides` acumulativo. Se registra un estado completo al menos cada siete días y siempre que cambie algo que no sea un recuento. - `parts_complete` marca las listas con límite de elementos. Las adiciones requieren una lista anterior completa, las eliminaciones requieren una lista actual completa, y los valores vacíos explícitos registran el borrado. - **Parámetros → Estado del chat** establece el intervalo (12 horas por defecto; 0 desactiva las instantáneas ), la pausa entre fuentes, qué partes se leen y si se registran las comprobaciones que no han detectado cambios. `FLOOD_WAIT` y `FLOOD_PREMIUM_WAIT` detienen las restantes solicitudes de instantáneas, conservan cualquier plazo restante para toda la cuenta y dejan el chat interrumpido apto para otro intento tras esa espera. - **No visible.** Los botones en línea (de devolución de llamada) pulsados en otra aplicación de Telegram, la ventana emergente o el enlace con el que un bot responde a dicha pulsación, y los enlaces de invitación utilizados en otra aplicación no llegan a TgWitness. Lo que el bot envía o edita posteriormente sí se registra. ### Actuación desde el panel **La sección «Chats»** incluye ahora un minicliente que utiliza la cuenta de Telegram del espacio de trabajo seleccionado: - Escriba un mensaje de texto sin formato o seleccione **«Responder»** debajo de un mensaje guardado. El mensaje saliente resultante se registra incluso cuando el ámbito de aplicación excluye las actualizaciones salientes. - Pulse **el botón «Pulsar»** situado debajo de un botón de respuesta o de texto actual. El servidor vuelve a recuperar el mensaje y rechaza la acción si el texto difiere de la versión guardada. Los acuses de recibo conservan el texto emergente de Telegram, el indicador de alerta y la URL; la respuesta también se muestra debajo de la conversación. Las URL siguen siendo texto seleccionable y no se abren automáticamente. - Expanda **el enlace «Abrir Telegram**», introduzca `@username`, un enlace público `https://t.me/name`, `https://t.me/+invite` / `joinchat/invite`, o un enlace de bot con `?start=parameter`, y pulse **«Guardar vista previa**». El enlace original y la vista previa de Telegram se firman antes de unirse. **Al unirse o abrir y observar**, se incorpora al grupo o canal, o se abre el usuario o bot, se añade el chat como fuente habilitada y se envía `/start` a un bot, incluyendo su parámetro de inicio. Una solicitud de incorporación pendiente de la aprobación del administrador se registra como «pendiente», no como «pertenencia». Active la opción **«Iniciar observación»** para capturar las respuestas entrantes en tiempo real. Las acciones del panel funcionan mientras la observación está en pausa, pero en ese caso solo se garantiza que se guarden sus respuestas directas. Las fuentes recién añadidas utilizan la configuración de perfil e historial configurada cuando la observación está en marcha. Cuando una fuente esté en pausa, actívela en **«Fuentes»** antes de enviar mensajes o pulsar sus botones. `interaction.preview`, `interaction.requested` y `interaction.result` son eventos habituales del registro firmados que se incluyen en las exportaciones de pruebas. Las solicitudes identifican la cuenta, el mensaje o el botón o el registro de vista previa, así como si la observación estaba en ejecución. Los acuses de recibo distinguen entre éxito, rechazo, aprobación pendiente y un resultado desconocido. Es posible que una solicitud interrumpida haya llegado a Telegram: compruebe el chat antes de iniciar una nueva acción. La reutilización de un ID de solicitud recupera su confirmación guardada sin repetir la acción, incluso tras un reinicio. El panel conserva el ID tras una respuesta ambigua para la misma acción durante la sesión de la página actual. También conserva ese ID cuando falla la actualización de la vista tras una acción realizada con éxito: la confirmación permanece visible, y al hacer clic de nuevo se recupera. Las RPC de devolución de llamada y de incorporación tienen un único intento de aplicación; las lecturas reintentables mantienen su política de reintentos configurada. Al cambiar de chat, se borran inmediatamente el borrador y el destinatario de la respuesta, y se desactiva el envío hasta que se cargue la nueva conversación. Este minicliente gestiona botones de texto y de devolución de llamada. Las aplicaciones web, las solicitudes de inicio de sesión, de número de teléfono o de ubicación, los pagos, las consultas en línea y los archivos adjuntos siguen requiriendo un cliente de Telegram; los metadatos guardados de sus botones siguen siendo visibles. Los nuevos controles utilizan texto en inglés. ## Niveles de verificación Las revisiones solicitan de nuevo a Telegram los mensajes que se han perdido, las modificaciones y los mensajes que ya no devuelve. Las fuentes marcadas con un asterisco son fuentes **prioritarias**, que se revisan cada 15 minutos de forma predeterminada; el resto de fuentes, cada 6 horas. Los chats seleccionados comienzan como fuentes prioritarias, mientras que los chats añadidos mediante una carpeta o la cuenta completa se consideran fuentes normales. Se vuelven a comprobar un máximo de 30 fuentes por ciclo y el resto espera al minuto siguiente; tras una reconexión, las fuentes prioritarias tienen prioridad. Ambos intervalos se configuran en Fuentes → Ajustes de grabación → Revisión (el valor 0 desactiva un nivel) y se registran como `recheck.changed`. Los mensajes perdidos se recuperan a partir del punto en el que se detuvo la pasada anterior, hasta un máximo de **«Parámetros → Mensajes perdidos recuperados por chat y pasada**» (1.000 por defecto). Tras una interrupción prolongada, la nueva comprobación cubre, por tanto, todo el intervalo perdido, incluso cuando se hayan guardado primero mensajes en tiempo real más recientes que dicho intervalo . Un chat que aún se esté poniendo al día se vuelve a comprobar al minuto siguiente, en lugar de esperar a que finalice su intervalo de nivel; `recheck.completed` muestra `continues_after` hasta que haya terminado. Las comparaciones incluyen el texto de los mensajes, las entidades, los teclados (incluida su eliminación) y el contenido o la identidad de los archivos adjuntos. El mero hecho de modificar los hash de acceso a los archivos o las referencias a los mismos no constituye una modificación, ni tampoco lo que Telegram rellena por sí mismo: la carga de una vista previa de un enlace, las visualizaciones de historias, los contenidos multimedia de pago desbloqueados por esta cuenta o la recepción de una factura. Cada versión guardada en «Chats» enlaza con su registro completo en el diario, incluidos los metadatos multimedia. ## Historial de mensajes y atribución Supongamos que el recopilador observa «Reunión a las 10:00», posteriormente ve «Reunión a las 11:00» y, a continuación, recibe un aviso de eliminación. Se añaden tres observaciones distintas: el texto original se conserva, la modificación constituye una versión separada y el aviso registra que se ha observado una eliminación. Si la recopilación comenzó después de que desapareciera la primera versión, dicho texto no estará disponible. Si se produjeron varias modificaciones mientras el proceso estaba fuera de línea, solo se podrán guardar las versiones observadas posteriormente. Un aviso de eliminación no permite recuperar contenido que nunca se haya capturado. El remitente del mensaje no es necesariamente quien lo ha editado. Telegram no suele facilitar la identidad de la persona que ha eliminado un mensaje ni la hora exacta de la eliminación. Los autores desconocidos siguen sin identificarse. Las instantáneas de reacciones y las actualizaciones de los participantes contienen únicamente los recuentos y las identidades que Telegram muestra a la cuenta. Los números de secuencia indican el orden de observación. La marca de tiempo UTC del recopilador corresponde a su reloj local; la marca de tiempo original de Telegram se almacena por separado cuando se facilita. Ninguna de ellas constituye una marca de tiempo independiente y fiable. ## Instantáneas del historial Una instantánea solicita los últimos mensajes visibles de una fuente habilitada, hasta 500 por petición. Los resultados se etiquetan como observaciones del historial. Las instantáneas manuales reservan una cuenta libre; pausa antes la supervisión de forma explícita. Las observaciones repetidas se conservan como registros separados. Las capturas de pantalla se ajustan a la política de archivos adjuntos, pero permanecen separadas de los cambios en tiempo real. No reconstruyen los mensajes eliminados ni las versiones intermedias perdidas. Puede solicitar una mientras la herramienta está en pausa; cualquier archivo adjunto que se haya puesto en cola esperará hasta que comience la observación y se ejecute el proceso de descarga. La ejecución de **Historial** es una tarea exclusiva e independiente: lee las fuentes seleccionadas y descarga sus adjuntos en cola secuencialmente, sin iniciar la supervisión. Pausar libera la cuenta; reanudar continúa la ejecución guardada. Para filtrar por fechas, idioma y respuestas entre varias cuentas libres, consulta [Exportación distribuida de chats](https://github.com/phishdestroy/TgWitness/blob/main/docs/DISTRIBUTED-EXPORT.md). ## Gestión de archivos adjuntos La descarga de archivos adjuntos está activada por defecto y se detiene cuando queda menos de 1 GiB de espacio libre en disco. El recopilador realiza simultáneamente la observación de los mensajes y la tarea de descarga. La tarea conserva el descriptor multimedia original y la política de tamaño, por lo que un archivo adjunto editado posteriormente no se sustituye de forma silenciosa. Las descargas se ejecutan tras la captura del mensaje. Una descarga completada genera un registro `media.saved` con su SHA-256 y el recuento de bytes. Las tareas omitidas, fallidas, reintentadas e interrumpidas tienen resultados distintos. Una tarea en cola no constituye prueba de que el archivo se haya conservado. El archivo completado también debe coincidir con el recuento de bytes del descriptor del archivo adjunto original observado. Una respuesta más corta o inesperadamente más larga no se registra como contenido conservado. Los límites se establecen **por tipo**: fotos, vídeos, GIF y animaciones, mensajes de vídeo circulares, mensajes de voz, música y audio, pegatinas y archivos. Cada tipo puede desactivarse y tiene su propio límite de tamaño, que va de 1 a 2.000 MiB; los nuevos espacios de trabajo comienzan con 20 MiB para fotos, 100 MiB para vídeos, 50 MiB para archivos, audio y vídeos circulares, 20 MiB para mensajes de voz y GIF, y 5 MiB para los stickers. Los nuevos espacios de trabajo mantienen los GIF y los stickers desactivados hasta que se activen. Los espacios de trabajo con políticas guardadas antes de la implantación de los límites por tipo mantienen todos los tipos activados y conservan su único límite para cada tipo. *El tamaño máximo de archivo* se establece para todos los tipos a la vez. Un tipo desactivado genera un registro `media.skipped`; los archivos de tamaño desconocido o que superan el límite no se descargan. Los archivos de gran tamaño disponen de tiempo de descarga adicional en función de su tamaño y de una velocidad base de 256 KiB/s. Los trabajos se mantienen tras un reinicio, pero las referencias caducadas, la pérdida de acceso o los archivos eliminados pueden seguir impidiendo la recuperación. Los trabajos en espera conservan el límite guardado con ellos, por lo que un aumento del límite solo se aplica a los archivos nuevos. Desactivar un tipo o reducir su límite también omite los archivos en espera que excluye, cada uno con un registro «`media.skipped`»; desactivar las descargas pone en pausa la cola hasta que se vuelvan a activar. ## Pausar, bloquear, desconectar y reiniciar | Acción o condición | Efecto | | --- | --- | | Cambiar de espacio de trabajo | Cambia la vista del panel; los demás recopiladores mantienen su estado. | | Bloquee el panel o cierre la pestaña | Mantiene el servidor y la observación en funcionamiento. | | Observación de pausa | Detiene ese recopilador y conserva el trabajo de los archivos adjuntos en cola. | | Desactivar una fuente | Desactiva la captura programada futura; las tareas multimedia en cola relacionadas con ella quedan en espera mientras esté desactivada. | | Eliminar una fuente | Se omite como fuente y se eliminan los perfiles de sus usuarios; los registros ya guardados permanecen en el registro de solo adición. Los archivos adjuntos que aún están pendientes se registran como fallidos (`source_removed`). En los modos de carpeta y de cuenta completa, también se excluyen. | | Modificar la ruta de conexión | Requiere una pausa, cierra los clientes antiguos y cancela los inicios de sesión no completados. | | Detenga el proceso de Python | Detiene todos los espacios de trabajo; no se realizan observaciones mientras está desconectado. | | Reinicio tras la observación activa | Intenta reanudar el ámbito guardado utilizando la sesión guardada. Una pausa manual anula dicha intención. | El recopilador registra las desconexiones detectadas, los reintentos, los errores, los inicios y paradas, y los pulsos de conexión. Las interrupciones breves pueden pasar desapercibidas en las comprobaciones periódicas de conectividad. Tras un reinicio, se solicitan las actualizaciones perdidas a partir de la posición de actualización guardada y los chats observados se vuelven a comprobar periódicamente; véase [el formato de las pruebas](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#durable-collection-and-process-receipts-02). Una instantánea proporciona contexto; no demuestra que se haya subsanado una laguna. ## Aislamiento y verificación de cuentas Cada espacio de trabajo cuenta con su propio registro, autorización, clave de firma, política y cola. Solo su cliente activo puede aportar observaciones en tiempo real. Los clientes rechazados, pendientes, sustituidos y los que realizan pruebas de conexión no pueden escribir actualizaciones en tiempo real en su registro. Diferentes cuentas pueden observar el mismo grupo, pero sus registros permanecen separados. Cada evento incluye el hash anterior y una firma Ed25519. Las exportaciones abarcan todo el registro del espacio de trabajo mediante un número de secuencia fijo. Los filtros del panel no filtran la exportación; la recopilación puede continuar más allá de sus límites mientras se está preparando. **El registro de verificación** comprueba la cadena de eventos y las firmas a través del límite mostrado. Su resultado se borra cuando cambia el espacio de trabajo, y el panel identifica los nuevos registros añadidos tras la comprobación. La exportación en formato ZIP también verifica los archivos multimedia recopilados. Conservar las huellas digitales y los puntos de control de forma independiente. Consultar el [Ámbito de verificación](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#verification-scope) para las comprobaciones de adquisición en cada modo, y [Operaciones diarias](https://phishdestroy.github.io/TgWitness/es/docs/reference/operations/) para la recopilación rutinaria. --- # Telegram · Chats secretos: implementación y demostración Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reference/secret-chats/ Comprender la implementación independiente de Chat secreto, probar la interfaz ficticia y revisar los defectos pendientes. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Comprender la implementación independiente de Chat secreto, probar la interfaz ficticia y revisar los defectos pendientes. [TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [Documentación](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) **Estado comprobado el 6 de noviembre de 2026:** existe una implementación independiente de Chats secretos en desarrollo. No se ha fusionado con la rama `main` publicada en `3d23e52b647b`. El recopilador estándar y la exportación Takeout no recopilan Chats secretos. El escenario interactivo del sitio web muestra la interfaz con datos ficticios; no permite la comunicación a través de Telegram. ## Dónde se encuentra la implementación La confirmación `0e60f88e` ha añadido **Sources → Pseudo-secret** en la rama de desarrollo local `fix/panel-routes-sessions`. La instantánea revisada es `bb8788fb685c`. Su implementación incluye `tgwitness/secret_chats.py`, rutas de la aplicación, `tgwitness/static/views/secret-chats.js` y pruebas específicas. El complemento opcional `secret-chats` de esa rama utiliza [KiaroSama/Telethon-Secret-Chat](https://github.com/KiaroSama/Telethon-Secret-Chat), anclado a `d87bf037b90060383c7b704d8a06ebb98c621c6f`. La biblioteca implementa el protocolo de chat de extremo a extremo de Telegram sobre la autorización Telethon existente de la cuenta. La mera instalación de esa biblioteca no añade la integración que falta a `main`. ## Qué hace la interfaz de desarrollo | Acción | Comportamiento registrado | | --- | --- | | Iniciar un chat por nombre de usuario o ID de usuario | Envía una solicitud; el otro participante debe aceptarla. | | Aceptar una solicitud entrante | TgWitness se convierte en el punto final receptor de ese chat. La aceptación automática es una configuración independiente, desactivada por defecto. | | Enviar o recibir un mensaje | Añadir un registro `secret_chat.message` saliente o entrante y mostrarlo en el hilo. | | Recibir un archivo adjunto | Descifralos, almacena sus bytes según SHA-256 y registra `secret_chat.file`. | | Recibir un aviso de temporizador o de eliminación | Registrar el aviso y conservar el contenido capturado anteriormente. | | Revisar la conversación | Mostrar mensajes, archivos, avisos y la visualización de claves. La pestaña abierta se actualiza cada cuatro segundos. | En una versión de desarrollo que incluya la integración, el operador activa el módulo para la cuenta seleccionada y lo conecta. Para iniciar, aceptar y enviar mensajes es necesario tener permiso para interactuar y que la protección de solo lectura de la cuenta esté desactivada. El otro participante debe aceptar un nuevo chat saliente. Estos controles no están presentes en la aplicación publicada en la revisión anterior. Solo se incluyen los chats creados o aceptados por esta sesión de TgWitness. Los chats secretos existentes en un teléfono permanecen en ese dispositivo. La importación de una sesión no proporciona sus claves de cifrado independientes. El material de claves y los contadores de los chats secretos se almacenan en la bóveda del espacio de trabajo; los mensajes conservados y los archivos descifrados siguen las protecciones habituales de almacenamiento del espacio de trabajo. ## Demostración en la página web El escenario «**Try Secret Chat**» del sitio web presenta una conversación ficticia. Permite al lector iniciar una solicitud, simular su aceptación, enviar un mensaje de muestra, recibir una respuesta y un archivo predefinidos, e inspeccionar un temporizador y un aviso de eliminación. También se puede aceptar una solicitud entrante. Los controles etiquetan explícitamente las acciones simuladas de los interlocutores. Este escenario se ejecuta en la memoria del navegador. Al reiniciar o recargar la página, se borra. No inicia sesión, no se conecta a Telegram, no crea claves de cifrado reales ni altera las descargas de muestras firmadas. Los mensajes que muestra no constituyen pruebas firmadas. El escenario muestra la interacción prevista; no certifica que la implementación del desarrollo esté lista. ## Comprobaciones y defectos pendientes Las cinco pruebas existentes abarcan la persistencia de claves cifradas, el ciclo de vida y los registros de mensajes, la política de aceptación de entradas, el envío de solo lectura y la exportación de archivos adjuntos. Superaron las pruebas con la biblioteca fijada durante la revisión del 6 de noviembre. Tres comprobaciones sintéticas adicionales reprodujeron defectos en la misma instantánea: | Resultados | Consecuencia | | --- | --- | | El cierre evita el `read_only` | La ruta de cierre puede realizar una acción remota cuando se deban bloquear las interacciones. | | La búsqueda de duplicados solo se realiza en los registros recientes de 500. | Una reproducción anterior puede crear un duplicado tras reiniciar. | | Si falla la descarga de un archivo adjunto, se elimina su entrada pendiente. | Un fallo transitorio provoca la pérdida de la tarea de reintento. | Se trata de fallos pendientes, también registrados en la auditoría [publicada](https://github.com/phishdestroy/TgWitness/blob/main/website/validation/audit/REPORT.md). Las cinco pruebas superadas no cubren estos fallos. La revisión utilizó entornos de trabajo sintéticos y simuló operaciones de Telegram; no repitió un protocolo de autenticación en tiempo real ni evaluó la implementación en producción. --- # Telegram · Cargar historial de fuentes Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reference/history/ Carga mensajes anteriores de fuentes habilitadas, pausa y reanuda, y verifica un informe de progreso firmado. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Carga mensajes anteriores de fuentes habilitadas, pausa y reanuda, y verifica un informe de progreso firmado. [TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [Documentación](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) · [Colección](https://github.com/phishdestroy/TgWitness/blob/main/docs/COLLECTION-MODES.md) ![Recopilación](https://phishdestroy.github.io/TgWitness/assets/chapter-collect.svg) En **Fuentes**, revisa los chats habilitados, pausa la observación, elige la API estándar o la exportación Takeout y, a continuación, selecciona **Cargar historial completo**. La ejecución corrige esa lista de fuentes e importa sus mensajes anteriores disponibles a Chats y al diario de observación firmado. Los archivos multimedia utilizan la configuración de archivos adjuntos existente y la cola de descargas permanente. Esto es independiente de la exportación firmada en formato JSON/HTML por chat. Para una recopilación de toda la cuenta, selecciona **Toda la cuenta**, inicia la observación para cargar su lista de fuentes y revisa dicha lista antes de iniciar el historial. El límite de la lista de diálogos sigue siendo aplicable (1,000 por defecto, ajustable en Parámetros). Una ejecución satisfactoria no garantiza que se hayan incluido todos los diálogos de la cuenta. Los chats descubiertos o habilitados posteriormente requieren otra ejecución. Pausa la observación antes de iniciar el historial; cada adquisición abarca una cuenta a la vez. Elige entre uno y cinco procesadores de archivos adjuntos y si deseas conservar las Acciones recientes disponibles y comparar versiones guardadas anteriormente. La extracción puede requerir aprobación en Telegram y un tiempo de espera especificado por el servidor. Estas opciones permanecen fijas al reanudar. Consulta [el comportamiento de Backfill y el contrato de pruebas](https://github.com/phishdestroy/TgWitness/blob/main/docs/BACKFILL.md) para obtener detalles sobre el transporte, los reintentos y la confianza. ## Pausa, reanudación y resultados parciales - **Historial de pausa:** detiene la lectura. **Historial de continuación:** reanuda desde el último mensaje guardado en cada fuente; al reiniciar la aplicación, la ejecución también queda en pausa hasta que se reanude. Para reanudar es necesaria la misma cuenta de Telegram inactiva. - La observación del mensaje, la tarea de adjuntar archivos y la confirmación del cursor se realizan en una sola transacción. Una ejecución reanudada no repite las observaciones ya confirmadas. La captura en tiempo real o una ejecución independiente, iniciada explícitamente, puede observar de forma independiente el mismo mensaje. - Cada fuente (cada rango dividido de Telegram en Takeout) establece un ID de mensaje máximo en su primera lectura. Los mensajes más recientes pertenecen a la observación en tiempo real, no a las páginas históricas restantes de esa fuente. - Las fuentes inaccesibles y aquellas desactivadas durante la adquisición permanecen visibles como fallidas u omitidas. El resto de fuentes continúan; el resultado global es incompleto. - Los retrasos de FloodWait respetan el tiempo de espera guardado para la cuenta. Los fallos transitorios se reintentan hasta cinco veces; el agotamiento y el espacio insuficiente en disco provocan una pausa sin que se mueva el cursor. - **: Finalizar esta ejecución del historial.**: conserva las observaciones guardadas. No las elimina ni cancela las tareas de adjuntar archivos de la API estándar. Al finalizar Takeout, marca los archivos de Takeout restantes como omitidos; al pausarlo, se mantienen reanudables. Una nueva ejecución vuelve a leer las fuentes habilitadas. La finalización del historial describe únicamente las lecturas del historial. Los archivos adjuntos pueden quedar pendientes, fallar o ser excluidos por la política configurada. Comprueba los acuses de recibo multimedia en el registro y en la cola de archivos adjuntos; solo un acuse de recibo completado con los bytes conservados constituye un archivo adjunto guardado. La operación de historial es una solicitud explícita de instantánea y es independiente de los parámetros que seleccionan categorías de futuros eventos en directo. ## Transferir y verificar Guarda el **informe de progreso firmado** y, a continuación, utiliza la opción **«Exportar pruebas»** para descargar el registro y los archivos adjuntos guardados. Una exportación posterior de pruebas puede incluir registros adicionales; el informe vincula sus contadores al prefijo del registro en el momento de su creación. Ejecuta el verificador desde una copia fiable de esta versión: ``` python tgwitness/verify.py tgwitness-history-report.json --evidence evidence.zip --fingerprint TRUSTED_FINGERPRINT ``` Mantener de forma independiente la huella digital esperada de la clave de firma. El verificador comprueba la firma del informe, el archivo de pruebas, el punto de control del informe, el plan de origen, la cuenta y el recuento de mensajes guardados o no disponibles. Las nuevas ejecuciones también vinculan el progreso de origen y las opciones a eventos de cursor firmados. Sin `--evidence`, solo comprueba el informe firmado y su coherencia interna. Los campos de progreso heredados y los resúmenes de archivos adjuntos siguen siendo declaraciones firmadas del recopilador. El verificador de pruebas comprueba los bytes de los archivos multimedia archivados. Ni la firma ni la finalización del historial disponible demuestran el origen de Telegram, una instantánea atómica o la integridad histórica. Los mensajes pueden cambiar mientras se leen; los mensajes eliminados y las ediciones intermedias fuera de las Acciones recientes disponibles, así como los Chats secretos, no se recuperan. Un operador que controle la clave de firma puede falsificar un registro antes de que existan compromisos externos. Utilice puntos de control conservados por separado o un testigo independiente para las propiedades documentadas de detección de manipulaciones. El cursor de adquisición refleja el estado del espacio de trabajo local. La restauración de un archivo ZIP de pruebas por sí sola no restaura un trabajo de adquisición pendiente ni una sesión de Telegram. Conserva la copia de seguridad del espacio de trabajo si es necesario continuar con el trabajo original. --- # Telegram · Flujos de trabajo y operaciones Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reference/operations/ Funcionamiento diario del panel: modos, categorías de supervisión, parámetros, notificaciones, exportaciones, copias de seguridad y capacidad. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Funcionamiento diario del panel: modos, categorías de supervisión, parámetros, notificaciones, exportaciones, copias de seguridad y capacidad. [TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [Documentación](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) · [Implementación y recuperación](https://phishdestroy.github.io/TgWitness/es/docs/reference/deployment/) ![Implementación y recuperación](https://phishdestroy.github.io/TgWitness/assets/chapter-operate.svg) Para su primera conexión, utilice [las cuentas y los formatos de sesión](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/). Para obtener una explicación sobre las versiones guardadas, las políticas de eventos y las lagunas, consulte [cómo funciona la recopilación](https://phishdestroy.github.io/TgWitness/es/docs/reference/collection/). Esta guía abarca el funcionamiento diario y la recuperación. Una instalación gestionada incluye **, START-HERE.html,** y **, START-HERE.txt y**, además de su lanzador, con el enlace al repositorio y los comandos adaptados a su ruta de instalación. Ejecuta `tgwitness guide --print` a través de SSH, o `tgwitness paths` para localizar el directorio de datos real. Una instalación de systemd como usuario root almacena el estado privado en `/var/lib/tgwitness-…`; `/opt/tgwitness` contiene el programa. En el caso de un túnel temporal gestionado de Cloudflare, `tgwitness tunnel off` desactiva el acceso público mientras el panel local y la recopilación siguen funcionando. `tgwitness tunnel on` lo habilita; `tgwitness tunnel restart` crea una nueva conexión de túnel. Utiliza `tgwitness open` para ver su dirección actual. Una configuración explícita de desactivación se mantiene tras los reinicios del servicio. `tgwitness stop` detiene tanto el panel como la recopilación. **En esta página** - [Flujo de trabajo del operador](https://phishdestroy.github.io/TgWitness/es/docs/reference/operations/#operator-workflow) - [Compartir trabajo sin compartir la clave principal](https://phishdestroy.github.io/TgWitness/es/docs/reference/operations/#share-work-without-sharing-the-main-key) - [Modos de ejecución](https://phishdestroy.github.io/TgWitness/es/docs/reference/operations/#runtime-modes) - [Categorías de supervisión](https://phishdestroy.github.io/TgWitness/es/docs/reference/operations/#monitoring-categories) - [Notificaciones](https://phishdestroy.github.io/TgWitness/es/docs/reference/operations/#notifications) - [Diseño del panel](https://phishdestroy.github.io/TgWitness/es/docs/reference/operations/#panel-layout) - [Entornos de implementación](https://phishdestroy.github.io/TgWitness/es/docs/reference/operations/#deployment-environments) - [Comprobaciones de inicio y exportaciones](https://phishdestroy.github.io/TgWitness/es/docs/reference/operations/#startup-checks-and-exports) - [Copia de seguridad, restauración e interrupciones](https://phishdestroy.github.io/TgWitness/es/docs/reference/operations/#backup-restore-and-interruptions) - [Capacidad y retención](https://phishdestroy.github.io/TgWitness/es/docs/reference/operations/#capacity-and-retention) ## Flujo de trabajo del operador Diagrama de flujo · Elija el almacenamiento y la protección de claves → Abra el panel con su token; Abra el panel con su token → Seleccione un espacio de trabajo; Seleccione un espacio de trabajo → Configurar ruta directa o a través de un proxy; Configurar ruta directa o a través de un proxy → Introduzca su número de teléfono o seleccione archivos / código QR; Introduzca su número de teléfono o seleccione archivos / código QR → Compruebe la identidad de la cuenta y seleccione los grupos a los que tiene acceso; Compruebe la identidad de la cuenta y seleccione los grupos a los que tiene acceso → Guarde las políticas de eventos y archivos adjuntos y, a continuación, inicie la observación; Guarde las políticas de eventos y archivos adjuntos y, a continuación, inicie la observación → Supervisar errores, accesos, colas y espacio en disco; Supervisar errores, accesos, colas y espacio en disco → Mantener puntos de control independientes; Mantener puntos de control independientes → Exportar y verificar el material · Elija elalmacenamiento y laprotección de claves · Abra el panel con sutoken · Seleccione un espaciode trabajo · Configurar rutadirecta o a través deun proxy · Introduzca su númerode teléfono oseleccione archivos /código QR · Compruebe la identidadde la cuenta yseleccione los gruposa los que tiene acceso · Guarde las políticasde eventos y archivosadjuntos y, acontinuación, iniciela observación · Supervisar errores,accesos, colas yespacio en disco · Mantener puntos decontrol independientes · Exportar y verificarel material **Diagrama en formato de texto** 1. Elija el almacenamiento y la protección de claves → Abra el panel con su token 2. Abra el panel con su token → Seleccione un espacio de trabajo 3. Seleccione un espacio de trabajo → Configurar ruta directa o a través de un proxy 4. Configurar ruta directa o a través de un proxy → Introduzca su número de teléfono o seleccione archivos / código QR 5. Introduzca su número de teléfono o seleccione archivos / código QR → Compruebe la identidad de la cuenta y seleccione los grupos a los que tiene acceso 6. Compruebe la identidad de la cuenta y seleccione los grupos a los que tiene acceso → Guarde las políticas de eventos y archivos adjuntos y, a continuación, inicie la observación 7. Guarde las políticas de eventos y archivos adjuntos y, a continuación, inicie la observación → Supervisar errores, accesos, colas y espacio en disco 8. Supervisar errores, accesos, colas y espacio en disco → Mantener puntos de control independientes 9. Mantener puntos de control independientes → Exportar y verificar el material La autorización, la conectividad de la red, el acceso a un grupo y la integridad de la entrega son propiedades distintas. Un estado de conexión verde no implica que se hayan capturado todos los eventos. ## Compartir el trabajo sin compartir la clave principal **Acceso** abierto para proporcionar a un revisor o analista su propio token. Seleccione las cuentas y los chats a los que puedan acceder y, a continuación, autorice la visualización, la exportación o las acciones operativas. Un operador que inicie o detenga la recopilación necesita acceso a todo el espacio de trabajo; un revisor puede estar limitado a un único chat. Los límites de sesión, la caducidad y las reglas de IP son independientes de la autorización de la cuenta de Telegram. Consulte el apartado [de acceso y permisos](https://phishdestroy.github.io/TgWitness/es/docs/reference/access/). Utilice **«Sesiones abiertas»** para finalizar una conexión o «Revocar el acceso» para poner fin a todas sus sesiones. La consola de administración combina la actividad de los procesos en curso en todos los espacios de trabajo. El cierre de la sesión deja la recopilación en marcha. ## Modos de funcionamiento | Modo | Acción | Comportamiento | | --- | --- | --- | | Demostración | scripts\Demo.cmd o `--demo` | Datos sintéticos; conexiones con cuentas reales desactivadas | | Observación | Iniciar la observación | Registre las actualizaciones recibidas de las fuentes seleccionadas | | Instantánea del historial | Fuentes → instantánea del historial | Hasta 500 mensajes actuales; no se reconstruyen todos los cambios anteriores. | | Pausa | Observación de pausa | Detener la recopilación conservando los datos y los trabajos en cola | | Revisión/entrega | Exportaciones | ZIP, JSONL/CSV/HTML, punto de control, acuse de recibo del proceso y solicitud de marca de tiempo | | Cuentas múltiples | Espacios de trabajo o el botón superior «**+**» | Cualquier número de espacios de trabajo independientes en un único proceso | El acceso a la demostración local se abre automáticamente sin necesidad de introducir un token manualmente. Utiliza una capacidad válida durante la vida útil del proceso, exclusiva para el acceso directo de bucle cerrado a una demostración sintética aislada; el token del panel principal no se revela. Los espacios de trabajo reales y el acceso a la demostración de forma remota o a través de un proxy mantienen la autenticación mediante token. El acceso a la demostración no otorga ninguna autorización de Telegram. ## Categorías de seguimiento ![Configuración de supervisión por cuenta con datos de origen sintéticos](https://phishdestroy.github.io/TgWitness/assets/sources.png) En **Fuentes → Grabación → Elegir qué cambios conservar**, selecciona de forma independiente los mensajes nuevos, las ediciones, los avisos de eliminación, las actualizaciones de reacciones y los eventos de pertenencia. La opción predeterminada conserva todas las categorías. La opción **«Mensajes, ediciones y eliminaciones»** mantiene el contexto original mientras desactiva las actualizaciones separadas de reacciones y miembros. **La opción «Toda la actividad visible»** restaura las cinco categorías. Los ajustes preestablecidos modifican el formulario; pulsa **«Guardar configuración de grabación**» para aplicarlos. La política guardada se aplica a todas las fuentes seleccionadas en ese espacio de trabajo. Los demás espacios de trabajo conservan su propia configuración. Cada cambio real registra los valores firmados «antes» y «después» ; la política actual también se incluye en los recibos de proceso y en los registros de inicio de observación . Desactivar una categoría no elimina las observaciones anteriores. Volver a activarla no recupera los cambios que se hayan perdido. En esta versión no existe la posibilidad de anular las categorías por grupo. Mantenga activada la opción de nuevos mensajes cuando el contenido anterior sea relevante: un aviso de eliminación no puede recuperar texto que nunca se haya capturado. Los registros operativos y de cobertura, así como otros eventos del servicio de grupo, se conservan siempre. Las instantáneas explícitas del historial son independientes de la selección de categorías en tiempo real y pueden incluir mensajes de servicio. Estas opciones no ocultan los metadatos de reacciones o de miembros incrustados en un objeto de Telegram que, por lo demás, haya sido capturado. Una instantánea del historial puede poner en cola los archivos adjuntos mientras está en pausa. Inicie la observación para procesarlos. Estar en cola no significa que se hayan descargado. Un archivo original no disponible no se sustituye por una versión editada más reciente; los resultados se registran por separado. **Al bloquearse,** se borra el acceso del navegador y los campos secretos, pero la recopilación sigue en marcha. Al cerrar una pestaña, el proceso también sigue en marcha. Al detener el proceso o el servicio de Python, se detiene la recopilación independientemente del estado del navegador. Al eliminar un espacio de trabajo adicional, se detiene su recopilador y se eliminan sus datos locales. Si un archivo bloqueado o un error del sistema de archivos interrumpe la eliminación, el panel informa del fallo y mantiene el espacio de trabajo en la lista como no disponible (`DeletionPending`). Cierre los programas que tengan abiertos sus archivos y vuelva a intentar **la eliminación**. Al reiniciar TgWitness, dicho espacio de trabajo permanece detenido y no se recrean su registro ni sus claves parcialmente eliminados. Una eliminación satisfactoria se registra solo después de que se haya eliminado el directorio; las copias exportadas o respaldadas por separado permanecen sujetas a su propia política de retención. ## Notificaciones Abre **Extras → Notificaciones → Configurar**. TgWitness utiliza Apprise para enviar alertas a Matrix, Telegram, Discord, Slack, ntfy, correo electrónico y otros servicios compatibles. Puedes añadir varios destinos a un mismo espacio de trabajo. 1. Introduzca una URL de destino de Apprise por línea. Utilice el [catálogo de servicios y los formatos de URL](https://appriseit.com/services/) correspondientes a su servicio. 2. Active la opción **«Enviar notificaciones**» y, a continuación, seleccione las alertas de problemas, los cambios en los chats supervisados y un resumen diario. La hora del resumen se basa en la hora del servidor. 3. Active la opción **«Incluir extractos breves»** si desea que el texto guardado de los mensajes eliminados y editados aparezca en las alertas. 4. Pulse **«Guardar notificaciones**» y, a continuación, **«Enviar prueba»** para comprobar la entrega. Para su propio receptor, utilice [el webhook JSON](https://appriseit.com/services/json/) de Apprise. Por ejemplo, `jsons://notify.example.org/tgwitness` envía JSON a través de HTTPS a ese punto final. Se trata de un ejemplo ficticio; sustitúyalo por su propio destino. Los destinos y la configuración pertenecen al espacio de trabajo seleccionado. Las notificaciones de cambios abarcan las fuentes supervisadas, incluidos los chats añadidos recientemente. La campana de la barra superior también muestra los problemas recientes y los cambios en los chats. En la demostración, los controles de notificación están visibles, pero el envío está desactivado. Configure el envío en un espacio de trabajo real. Las notificaciones utilizan la ruta Direct, SOCKS5 o HTTP de ese espacio de trabajo; MTProxy no puede transmitirlas. Los destinos que no sean HTTP, como SMTP, requieren una ruta directa. ## Diseño de paneles ![Espacio de trabajo de conexión con datos sintéticos](https://phishdestroy.github.io/TgWitness/assets/connection.png) **El registro** muestra observaciones, búsquedas y filtros. Al editar un mensaje, se abren las versiones capturadas; al borrar un mensaje, se muestra el contenido anterior, si está disponible. Las atribuciones desconocidas se indican de forma explícita. Los recuentos están disponibles en **«Visión general»**; los detalles de la adquisición se mantienen en la guía local. Abra un mensaje editado para comparar sus versiones con **Cambios en el texto** o **En paralelo**; **Datos sin procesar** muestra los campos guardados. Los cambios en enlaces ocultos y botones de bots aparecen por separado. Abra la vista previa de un archivo adjunto para inspeccionar las imágenes, el audio o el vídeo guardados; el botón de descarga mantiene disponible el original conservado. **Live** actualiza el diario y los chats a medida que llegan los registros. Páuselo mientras revisa o use el botón de nuevos eventos cuando esté listo; la recopilación sigue ejecutándose. **Ctrl/Cmd+K** encuentra acciones del panel y busca en el diario. **La sección «Fuentes»** incluye el ámbito de observación (chats seleccionados, una carpeta de Telegram o toda la cuenta), chats accesibles de todo tipo, fuentes seleccionadas con estrellas de prioridad, ajustes de archivos adjuntos y de reverificación, así como instantáneas del historial. Las fuentes privadas se seleccionan por diálogo o ID sin enlace público. El estado de acceso describe la última comprobación, no los permisos permanentes. Filtre las fuentes, marque sus casillas de verificación y luego habilítelas, páuselas o márquelas como prioritarias conjuntamente. En la lista de chats disponibles, **Añadir seleccionados** utiliza su selección; **Añadir todas las coincidencias** utiliza la búsqueda y el filtro de tipo actuales. **En «Chats → Personas»** se muestra una lista de todas las personas cuyos mensajes se han guardado; si se han activado los perfiles de usuario para el chat, al hacer clic se abre el perfil de esa persona con enlaces a los registros del diario. **Witness** crea tokens de testigo de solo lectura, muestra cuándo se comprobó por última vez cada testigo y proporciona los comandos y opciones para ejecutar uno ([testigo independiente](https://phishdestroy.github.io/TgWitness/es/docs/reference/witness/)). **La sección «Parámetros»** recoge todos los límites y ritmos del espacio de trabajo que no figuran en otras páginas: el número de diálogos leídos, la frecuencia con la que se vuelve a leer la lista de chats, los intervalos de latido y de puntos de control, el búfer de inicio, cómo se distribuyen las solicitudes en las revisiones (primer retraso, chats por paso, pausa entre chats, mensajes recuperados y solicitados de nuevo), reserva de disco, tiempos de espera y reintentos de descargas, qué buscan los perfiles de usuario (incluidas sus propias expresiones regulares), tamaño y frecuencia de las notificaciones, límites de instantáneas, archivos ZIP y descargas en el navegador, así como los tiempos de espera y reintentos del cliente de Telegram. Cada campo muestra su rango y su valor por defecto; los campos modificados quedan marcados y pueden restablecerse uno a uno o todos a la vez. Cada cambio se registra como «`parameters.changed`» con los valores anteriores y posteriores, y los registros de inicio de observación indican los valores vigentes. Los valores se aplican a partir de su próximo uso; los tiempos de espera y los reintentos del cliente, a partir de la próxima conexión. Los intervalos de revisión, los tipos y tamaños de archivos adjuntos, así como los intervalos de copia de seguridad y copia externa permanecen en sus propias páginas y pueden adoptar cualquier valor dentro de su rango, no solo los preestablecidos. La campana de la barra superior muestra los problemas y cambios recientes en los chats supervisados; los mensajes no leídos se contabilizan hasta que se marcan como leídos. Los cambios se agrupan por chat y por hora («12 eliminados, 1 editado, 0 no encontrados»), y los problemas, como un cierre de sesión o un disco lleno, permanecen en la lista independientemente de lo activos que estén los chats. **La creación de la cuenta** comienza en el campo del número de teléfono. **Al continuar**, se accede directamente a la introducción del código, solicitándose las credenciales de la API únicamente cuando faltan. El código QR y la importación de archivos son pestañas alternativas. Las credenciales de la API guardadas solo se reutilizan dentro de su propio espacio de trabajo. La pantalla de inicio no incluye barra lateral, estadísticas ni apartados de configuración. El icono de **«Configuración»** abre los controles de API, proxy, almacenamiento y cuentas adicionales. Las nuevas instalaciones comienzan aquí; las cuentas conectadas sin fuentes seleccionadas comienzan en **«Elegir chats**». Cambiar la ruta requiere una observación pausada y cancela cualquier inicio de sesión no finalizado. Un registro existente no puede vincularse de forma silenciosa a una cuenta de Telegram diferente. **La exportación** comprueba la integridad del registro y genera archivos portátiles. Su identificador de espacio de trabajo puede introducirse en la línea de comandos de descarga. Cada exportación asigna un prefijo al registro completo; los eventos posteriores se incluyen en una exportación siguiente. Los filtros de búsqueda no modifican el ámbito del paquete. La información detallada sobre la firma y la cobertura se encuentra en la sección **«Verificación y limitaciones**». El panel muestra el estado del recopilador, los archivos multimedia en cola o fallidos, los archivos multimedia pendientes más antiguos, el espacio libre en disco, las pausas en las solicitudes y las fuentes cuyo acceso no está confirmado en **la sección «Estado del recopilador**». Estos detalles aparecen inicialmente ocultos y se ocultan en la pestaña «Cuenta». Una ficha de configuración muestra el siguiente paso: conectar una cuenta, elegir fuentes o iniciar la observación. La lista de cuentas es una instantánea en el momento de la carga; el espacio de trabajo seleccionado se actualiza periódicamente. No se trata de un monitor de SLA multiproceso. La interfaz de usuario utiliza recursos locales y renderización de texto para el contenido original. Se han probado los diseños para ordenador de sobremesa y los diseños estrechos basados en Chromium. No se trata de una certificación completa de accesibilidad; la evaluación de la usabilidad con lectores de pantalla y la evaluación de la usabilidad por parte de usuarios humanos siguen siendo tareas independientes. ## Entornos de implementación | Entorno | Instalación | Estado de la verificación | | --- | --- | --- | | PC/servidor con Windows | Python 3.11 o superior, scripts\Setup.cmd/Start.cmd, directorio de datos privado | Comprobado localmente en Windows/Python 3.12 | | Servidor Linux/VPS | Entorno virtual de Python (venv), usuario de servicio dedicado, HTTPS/SSH | Se proporcionan ejemplos de código, CI y systemd; no se ejecutan en este servidor. | | macOS | Entorno virtual de Python (venv), proceso en primer plano o agente de usuario | Se proporciona un ejemplo de «launchd»; es necesario realizar una comprobación de instalación por separado. | | Docker/Compose | Volumen constante, un trabajador | Se proporcionan la definición y la comprobación de tiempo de ejecución de la infraestructura de código (CI); Docker no está disponible localmente. | | Navegador del móvil | Acceda al panel protegido en un servidor en funcionamiento | Se ha probado un diseño estrecho basado en Chromium; el recopilador no funciona en iOS ni en Android. | La portabilidad implica que no es obligatorio utilizar un servicio en la nube ni crear una interfaz de usuario. Cada sistema de destino sigue necesitando dependencias compatibles de Python y criptografía, así como acceso al disco local y a la red. Consulte [el archivo DEPLOYMENT.md](https://phishdestroy.github.io/TgWitness/es/docs/reference/deployment/) y [las plantillas de servicio](https://github.com/phishdestroy/TgWitness/blob/main/deploy/README.md). Los espacios de trabajo comparten CPU, memoria y un bucle de eventos. Para aislar los procesos, utilice instancias, puertos, directorios de datos y autorizaciones de cuenta distintos. No existe un panel unificado para las distintas instancias. Nunca asigne varios trabajadores a una misma base de datos. ## Comprobaciones iniciales y exportaciones Ejecute «`python start.py --check`» antes de iniciar un entorno preparado. Añada «`--json`» para comprobaciones legibles por máquina o introduzca los valores previstos para «`--data-dir`», «`--host`» y «`--port`». El comando comprueba los requisitos previos sin necesidad de iniciar sesión en Telegram ni de crear un registro. No verifica el registro ni comprueba que esté listo para la captura; la verificación del registro se lleva a cabo durante el inicio de la aplicación. Un puerto ocupado puede deberse simplemente a la existencia de una instancia previa. Los navegadores compatibles con la API de acceso al sistema de archivos guardan las exportaciones a través de un flujo escribible. Otros navegadores almacenan en el búfer un máximo de 128 MiB. Utilice la CLI de streaming para exportaciones de mayor tamaño o para navegadores que no admitan streaming de archivos: ``` python -m tgwitness.download --token-file data/live/panel-token.txt --out evidence.zip ``` Añada «`--profile ID` » desde «Exportaciones» para un espacio de trabajo secundario. Utilice «`--url https://server` » para el acceso remoto. Solo se acepta HTTP sin cifrar para destinos de bucle invertido. El token se lee de un archivo y se envía en un encabezado; no se muestra ni se incluye en una URL. No se admiten redireccionamientos. Los destinos existentes no se sobrescriben. Las transferencias fallidas eliminan su archivo parcial temporal. El SHA-256 indicado es una suma de comprobación de la transferencia; verifique el archivo ZIP firmado por separado con una huella digital o un punto de control de confianza. ## Copias de seguridad, restauración e interrupciones 1. Pause la observación y detenga el proceso de forma limpia. 2. Copie todo el directorio de datos: bases de datos, WAL/SHM si existen, archivos multimedia, `credentials.enc`, `signing.enc`, `network.enc`, claves y metadatos del almacén, token, puntos de control y todos los directorios `profiles/`. 3. En el modo de clave externa, conserve por separado la clave maestra y guarde cada `vault.external.json`. La generación de una nueva clave no permite recuperar los secretos anteriores. 4. Restaure mientras el destino está detenido; configure la clave original, restrinja el acceso y verifique la integridad antes de reanudar. 5. Registre los periodos de inactividad y los resultados de la verificación. Una instantánea del historial no puede demostrar que no se produjeran eliminaciones durante la interrupción. Los archivos ZIP de pruebas excluyen las claves de sesión y las claves privadas, y no constituyen copias de seguridad completas del servicio. Hay cuatro elementos que se protegen de forma diferente: | ¿Qué? | Protección | | --- | --- | | Archivos exportados sin contraseña (predeterminado) | No está cifrado. Está firmado, por lo que los cambios son detectables, pero cualquier persona que tenga el archivo puede leerlo. | | Archivos exportados con contraseña | Si establece una contraseña, la exportación final se guarda sin modificaciones en un archivo ZIP con cifrado AES-256 de WinZip que pueden abrir tanto 7-Zip como WinRAR; la contraseña no se almacena ([manejo de pruebas](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/)). | | La base de datos del registro y los archivos adjuntos guardados en el disco | No está cifrado por TgWitness; utilice un disco o volumen cifrado | | Sesiones de Telegram y claves de firma | Cifrado en el directorio de datos (`credentials.enc`, `signing.enc`, `network.enc`) | Una copia de seguridad completa es el directorio de datos congelados descrito anteriormente, no una exportación. Utilice almacenamiento protegido y un mecanismo de transferencia controlado para ambos. Las exportaciones temporales del servidor se almacenan en el directorio « `temporary-exports/`» de cada espacio de trabajo; las respuestas completadas se eliminan, y los archivos de exportación interrumpidos se eliminan en el siguiente inicio, mientras se mantiene el bloqueo de la instancia de ese espacio de trabajo. Un evento de restablecimiento de la conexión no garantiza la recuperación de los cambios intermedios. Las tareas de medios persistentes y la posición de actualización de Telegram se conservan tras el reinicio; véase [el formato de las pruebas](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#durable-collection-and-process-receipts-02). ## Capacidad y retención Límites predeterminados, todos modificables en **«Parámetros**»: los primeros 1.000 diálogos, 500 mensajes por instantánea, 4 GiB de contenido ZIP firmado sin comprimir (los archivos más grandes requieren `verify.py --max-gib N`) y un límite de 128 MiB para el modo de navegador. Los archivos adjuntos ocupan entre 1 y 2.000 MiB por tipo en **«Fuentes» → «Archivos adjuntos**». La CLI de descarga tiene un valor predeterminado de 5 GiB transferidos. El espacio disponible en disco puede constituir un límite inferior. Reserve espacio para registros, archivos multimedia, WAL, exportaciones temporales y copias de seguridad. Las exportaciones utilizan el volumen de datos en lugar de los 512 MiB de «`/tmp`» de Compose. Mida los eventos por segundo, la antigüedad de la cola, los bytes de archivos multimedia y la latencia del disco, en lugar de limitarse a contar solo los grupos. Las pruebas de rendimiento locales sintéticas no garantizan la entrega de mensajes en Telegram. No existe una eliminación automática de los datos retenidos. La eliminación de la parte final de un registro invalida su relación con los puntos de control retenidos. Ya existen revisiones prioritarias: las fuentes marcadas con estrella se revisan cada 15 minutos de forma predeterminada, las demás, cada 6 horas (véanse [los niveles de revisión](https://phishdestroy.github.io/TgWitness/es/docs/reference/collection/#recheck-tiers)). Existen exportaciones protegidas con contraseña, tal y como se ha descrito anteriormente. La aceptación en tiempo real de Telegram/proxy, la reproducción duradera, el registro de administración y el sondeo de reacciones, los trabajadores aislados, el cifrado del registro local y los archivos multimedia por parte del propio TgWitness, así como la revisión independiente, siguen siendo tareas independientes. El acceso restringido se documenta en [«Acceso y permisos](https://phishdestroy.github.io/TgWitness/es/docs/reference/access/)». Consulte [READINESS.md](https://github.com/phishdestroy/TgWitness/blob/main/docs/internal/READINESS.md), [LIVE_ACCEPTANCE.md](https://github.com/phishdestroy/TgWitness/blob/main/docs/internal/LIVE_ACCEPTANCE.md) y [VERIFICATION.md](https://phishdestroy.github.io/TgWitness/es/docs/reference/verification/). --- # Telegram · Modo de investigación Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reference/investigation/ Investigaciones de cuentas completas en canales, grupos, chats privados y bots, desde la definición del alcance hasta la elaboración de un expediente de caso verificado. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Investigaciones de cuentas completas en canales, grupos, chats privados y bots, desde la definición del alcance hasta la elaboración de un expediente de caso verificado. [TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [Documentación](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) ![Investigación](https://phishdestroy.github.io/TgWitness/assets/chapter-investigate.svg) Siga un caso a través de canales, grupos, chats privados y bots, desde la adquisición inicial hasta una cronología referenciada y un traspaso verificable. La versión interactiva del sitio web se encuentra en `/docs/cases/`; consulte [las instrucciones de vista previa](https://github.com/phishdestroy/TgWitness/blob/main/docs/internal/PUBLISHING.md#preview-the-website-locally). **En esta página** - [Caso resuelto: un destino cambia a lo largo de cuatro conversaciones](https://phishdestroy.github.io/TgWitness/es/docs/reference/investigation/#worked-case-a-destination-changes-across-four-conversations) - [1. Definir el caso y recopilar toda la información](https://phishdestroy.github.io/TgWitness/es/docs/reference/investigation/#1-define-the-case-and-collect-the-whole-account) - [2. Hacer un inventario de todas las fuentes y recabar el contexto histórico](https://phishdestroy.github.io/TgWitness/es/docs/reference/investigation/#2-inventory-every-source-and-acquire-historical-context) - [3. Mantener la evolución del caso y las interacciones deliberadas](https://phishdestroy.github.io/TgWitness/es/docs/reference/investigation/#3-preserve-the-evolving-case-and-deliberate-interactions) - [4. Relacionar observaciones entre chats](https://phishdestroy.github.io/TgWitness/es/docs/reference/investigation/#4-connect-observations-across-chats) - [5. Crear la línea temporal entre chats](https://phishdestroy.github.io/TgWitness/es/docs/reference/investigation/#5-build-the-cross-chat-timeline) - [6. Añadir perspectivas de cuenta sin perder su origen](https://phishdestroy.github.io/TgWitness/es/docs/reference/investigation/#6-add-account-perspectives-without-losing-their-origin) - [7. Recopilar y verificar el traspaso del caso](https://phishdestroy.github.io/TgWitness/es/docs/reference/investigation/#7-assemble-and-verify-the-case-handoff) - [Adaptar la investigación](https://phishdestroy.github.io/TgWitness/es/docs/reference/investigation/#adapt-the-investigation) ## Caso práctico: un cambio de destino a lo largo de cuatro conversaciones Un anuncio hace referencia a un bot. Un grupo de operaciones debate un nuevo destino de pago y el teclado del bot lo muestra. Se edita el anuncio, en un mensaje privado de seguimiento se repite el destino y un mensaje de grupo desaparece. Las preguntas son: ¿qué se observó antes y después del cambio?, ¿qué cuentas de Telegram publicaron cada elemento?, ¿dónde apareció el destino?, ¿qué bytes de los archivos adjuntos se conservaron? y ¿qué intervalos siguen sin conocerse? Todos los nombres, identificadores, horas y referencias del registro que aparecen en este ejemplo son ficticios. El flujo de trabajo utiliza las funciones actuales; el mapa del caso es una ilustración, no un gráfico automático generado por la aplicación. Diagrama de flujo · Canales → Registro del espacio de trabajo; Grupos → Registro del espacio de trabajo; Chats privados → Registro del espacio de trabajo; Bots → Registro del espacio de trabajo; Registro del espacio de trabajo → Buscar en todas las fuentes; Registro del espacio de trabajo → Perfiles de personas con referencias a los registros; Registro del espacio de trabajo → Versiones guardadas y confirmaciones de recepción de archivos adjuntos; Buscar en todas las fuentes → Cronología del analista y registro de fuentes; Perfiles de personas con referencias a los registros → Cronología del analista y registro de fuentes; Versiones guardadas y confirmaciones de recepción de archivos adjuntos → Cronología del analista y registro de fuentes; Registro del espacio de trabajo → Archivo ZIP de pruebas firmadas; Cronología del analista y registro de fuentes → Traspaso de casos con pruebas verificadas por separado; Archivo ZIP de pruebas firmadas → Traspaso de casos con pruebas verificadas por separado · Canales · Grupos · Chats privados · Bots · Registro del espacio detrabajo · Buscar en todas lasfuentes · Perfiles de personas conreferencias a losregistros · Versiones guardadas yconfirmaciones derecepción de archivosadjuntos · Archivo ZIP de pruebasfirmadas · Cronología del analista yregistro de fuentes · Traspaso de casos conpruebas verificadas porseparado **Diagrama en formato de texto** 1. Canales → Registro del espacio de trabajo 2. Grupos → Registro del espacio de trabajo 3. Chats privados → Registro del espacio de trabajo 4. Bots → Registro del espacio de trabajo 5. Registro del espacio de trabajo → Buscar en todas las fuentes 6. Registro del espacio de trabajo → Perfiles de personas con referencias a los registros 7. Registro del espacio de trabajo → Versiones guardadas y confirmaciones de recepción de archivos adjuntos 8. Buscar en todas las fuentes → Cronología del analista y registro de fuentes 9. Perfiles de personas con referencias a los registros → Cronología del analista y registro de fuentes 10. Versiones guardadas y confirmaciones de recepción de archivos adjuntos → Cronología del analista y registro de fuentes 11. Registro del espacio de trabajo → Archivo ZIP de pruebas firmadas 12. Cronología del analista y registro de fuentes → Traspaso de casos con pruebas verificadas por separado 13. Archivo ZIP de pruebas firmadas → Traspaso de casos con pruebas verificadas por separado ## 1. Defina el caso y recopile toda la información 1. Conecta la cuenta de recopilación en su propio espacio de trabajo. En [Case Board](https://phishdestroy.github.io/TgWitness/es/docs/reference/case-board/) o en tu registro de casos, anota la referencia del caso, el ID de la cuenta, el espacio de trabajo y el inicio de la observación. Conserva la huella digital de la clave de firma de confianza de forma independiente. 2. Para crear una cuenta dedicada a la recopilación, abre **«Fuentes» → «Ámbito de observación» → «Modo de investigación**». La configuración predeterminada selecciona **«Cuenta completa»**, canales/grupos/chats privados/bots, acciones propias, perfiles de fuente y los últimos 200 mensajes visibles de las fuentes recién descubiertas. Revísalo, pulsa **«Guardar ámbito**» y completa la confirmación del ámbito. Las cuentas principales utilizan chats seleccionados o una carpeta; la recopilación de toda la cuenta está disponible para las cuentas marcadas para investigación. 3. **Cargue los chats** y compare las fuentes con la lista de diálogos de la cuenta. Compruebe las exclusiones. **El parámetro «Chats leídos de la lista de la cuenta»** tiene un valor predeterminado de 1.000 y admite hasta 20.000. Las fuentes que superen el límite de la lista se añaden cuando se activan. Registre lo que realmente se haya enumerado. 4. En **la configuración de grabación**, seleccione **«Toda la actividad visible»** y guarde la configuración de supervisión. Revise los tipos y límites de archivos adjuntos, así como el espacio libre en disco. 5. Inicie la observación. Valide un nuevo mensaje controlado, así como su edición y eliminación, y a continuación conserve las referencias de la prueba y cualquier error que se produzca. El alcance de toda la cuenta registra la actividad visible en la cuenta dentro de la configuración guardada. No accede a los chats secretos ni se une automáticamente a todos los grupos vinculados. Tampoco recopila retrospectivamente todas las conversaciones existentes. Consulte [el alcance de la recopilación](https://phishdestroy.github.io/TgWitness/es/docs/reference/collection/#observation-scope-chosen-chats-a-folder-or-the-whole-account). ## 2. Realice un inventario de todas las fuentes y recopile el contexto histórico Mantenga un registro de fuentes con una fila por cada chat: | Campo | Registrar | | --- | --- | | Identidad | Espacio de trabajo, ID de cuenta, ID numérico del chat, título y tipo | | Visibilidad | Afiliación/función, acceso confirmado o no confirmado, exclusiones | | Captura en tiempo real | Fecha de inicio, tipos de eventos seleccionados y cambios posteriores en la política | | Historial del registro | Instantáneas solicitadas/realizadas, límite, hora y referencias de los registros | | Historial completo | Nombre del archivo de exportación firmado por chat, límites y estado de finalización o error | | Archivos adjuntos | Recibos de archivos multimedia completados, hash, tamaños y resultados omitidos o fallidos | | Ámbito de aplicación | Interrupciones del servicio, capturas incompletas, FloodWait, mensajes no disponibles y otras lagunas | Utilice el método de adquisición adecuado para cada fuente: - **La opción «Cargar historial completo** en **Fuentes»** carga los mensajes anteriores disponibles de las fuentes habilitadas en el diario del espacio de trabajo. Admite la función de pausa/reanudación y un informe de progreso firmado. Véase [«Adquisición del historial](https://phishdestroy.github.io/TgWitness/es/docs/reference/history/)». - **La instantánea del historial** guarda los mensajes visibles recientes en el registro de observación. Su límite máximo por defecto es de 500; **en Parámetros → Instantánea de historial más grande** se puede aumentar esa cifra hasta 10 000. Se trata de observaciones del historial actual, no de ediciones reconstruidas. - **Exportación completa del chat → «Exportar chat completo**», o **«Chats» → «Exportar chat**», extrae el historial actualmente visible de un chat y lo guarda en un paquete independiente firmado `chat.json` / `chat.html`. Repita este proceso con las fuentes del caso y conserve cada resultado. - **Cuando aparece un nuevo chat o bot,** se puede guardar su perfil y hasta 1.000 mensajes recientes; el modo de investigación selecciona 200. Los chats existentes no reciben esa recopilación de forma retroactiva cuando se activa el modo. - **La descarga de archivos adjuntos visibles** conserva los bytes según la política configurada. Se requiere un recibo `media.saved` completo con SHA-256 y recuento de bytes. Un trabajo en cola, una miniatura o un nombre de archivo no constituyen el archivo adjunto conservado. Una exportación completa del chat **no** rellena el registro ni los perfiles de los usuarios con todos sus mensajes. Utiliza **«Cargar historial completo»** o «instantáneas delimitadas del registro» para el historial que necesites analizar dentro de TgWitness. Revisa la lista de fuentes habilitadas antes de iniciar una ejecución del historial. Ninguna de estas opciones recupera material que Telegram ya no devuelve. ## 3. Conservar la evolución del caso y las interacciones deliberadas Marque los chats de casos activos como fuentes prioritarias. Revise los intervalos de reverificación, la puesta al día continua y los resultados multimedia. Mantenga el recopilador en funcionamiento mientras utiliza la cuenta. Utilice **Chats → Perfil → Guardar perfil ahora** para conservar los metadatos de origen, tales como descripciones y comandos de bot. Esto es independiente de los perfiles de personas derivados de los mensajes guardados. Cuando el caso implique el seguimiento de una fuente o la interacción con un bot: 1. **Abrir enlace de Telegram → Guardar vista previa:** registra el enlace facilitado y la vista previa mostrada antes de realizar una acción. 2. **La función «Join / open and observe**» lleva a cabo la acción de unirse o abrir y envía el parámetro de inicio del bot cuando se le proporciona. Una solicitud de unión pendiente de aprobación se registra como «pendiente». 3. Las respuestas de texto emitidas por el panel y las pulsaciones de botones compatibles conservan `interaction.requested` y `interaction.result`. Los acuses de recibo de devolución de llamada pueden conservar el texto de la ventana emergente devuelta, el estado de la alerta y la URL. Se trata de acciones reales de la cuenta. Las pulsaciones de «Callback» en otra aplicación de Telegram no son visibles para el recopilador, aunque sí pueden serlo los mensajes o modificaciones resultantes. El minicliente no realiza flujos de trabajo relacionados con aplicaciones web, pagos, llamadas telefónicas ni ubicación. Para conocer el comportamiento exacto, consulte [las interacciones con los paneles](https://phishdestroy.github.io/TgWitness/es/docs/reference/collection/#act-from-the-panel). ## 4. Relacionar las observaciones entre distintos chats En **«Journal»**, seleccione **«Todas las fuentes»** y busque el contenido registrado. Abra los registros coincidentes y anote el espacio de trabajo, el chat, el ID del mensaje, la secuencia y el hash del registro. En un chat relevante, abra **«Personas» → «Activar perfiles»** y examine el perfil de una persona: - Nombres o nombres de usuario observados a lo largo del tiempo y el identificador numérico de Telegram. - Relaciones de respuesta con referencias a los registros originales. - **También en…** otros chats de este diario del espacio de trabajo en los que escribió ese ID. - Actividad, modificaciones y eliminaciones, así como carteras, teléfonos, nombres de usuario y enlaces mencionados. - Metadatos de avatares guardados y avatares similares almacenados en caché, con su origen respectivo. Abra los registros citados antes de utilizar un perfil derivado en una conclusión. Los perfiles abarcan a las personas cuyos mensajes se han guardado, no a todos los miembros del grupo. **Parámetros → Los registros citados por hecho** limitan la lista de referencias, no el recuento de actividades subyacentes. Las menciones y la similitud de avatares son pistas; no establecen la propiedad ni la identidad. En el ejemplo práctico: | Enlace | Registros | Observación contrastada | | --- | --- | --- | | La misma cuenta de remitente | Grupo n.º 146 y seguimiento privado n.º 205 | Ambos proporcionan el ID de remitente de Telegram 71001 | | Mismo destino | N.º 146, teclado del bot n.º 173, edición del canal n.º 188, mensaje privado n.º 205 | Todos contienen `pay.example.invalid/new`; no se ha establecido la titularidad ni el control. | | El mismo archivo guardado | Se han completado los recibos multimedia n.º 151 y n.º 209 | Los valores SHA-256 completos coinciden para los bytes conservados | | Atribución del canal | N.º 101 y n.º 188 | No atribuya una publicación del canal al usuario 71001 sin indicar el remitente correspondiente. | Comparar los hash de los archivos adjuntos y sus referencias de mensajes asociadas, y mantener las líneas temporales de las cuentas agrupadas por los ID de Telegram proporcionados en dichos registros. Guarda las notas de trabajo del equipo en [Case Board](https://phishdestroy.github.io/TgWitness/es/docs/reference/case-board/): marca como favoritos los registros en los que te basas, como el n.º 146, el n.º 188 y el n.º 205; resalta la cadena de destino exacta y guarda un fragmento de cada acción registrada entre dos registros o en un intervalo de tiempo. Las notas y los estados conservan la revisión del equipo en su propio historial firmado, que se puede identificar por separado de las observaciones de origen. ## 5. Crear la línea temporal entre chats Utilice las versiones guardadas en **«Chats»** y sus enlaces **«Registro del diario n.º…**». En **el «Diario»**, combine **todas las fuentes** con **las modificaciones**, **las eliminaciones** y **la cobertura**. Conserve tanto el `source_at`, cuando se facilite, como el `observed_at`. | Tiempo de observación ilustrativo | Referencia | Observación | | --- | --- | --- | | 09:00 | Canal n.º 101 | Destino original capturado | | 09:12 | Grupo n.º 146; medio n.º 151 | Se ha publicado un nuevo destino; descarga del archivo completada | | 09:16 | Bot n.º 173 | El teclado señala el nuevo destino | | 09:20 | Canal n.º 188 | Anuncio editado; se conservan ambas versiones guardadas | | 09:24 | Privado #205; medios de comunicación #209 | El mismo ID de remitente se repite en el destinatario; se conservan los mismos bytes del archivo | | 09:28 | Grupo n.º 231 | Se ha recibido un aviso de eliminación; se desconoce quién la ha eliminado y la hora exacta de la eliminación. | Entre estas referencias de ejemplo se producen otros registros. Los números de secuencia ordenan las observaciones; las instantáneas del historial pueden contener fechas de origen más antiguas y llegar más tarde que los eventos en tiempo real. Distinga entre instantáneas, mensajes recuperados, avisos de eliminación y resultados de «ausente tras nueva comprobación». Marque las lagunas de cobertura como intervalos desconocidos. La adquisición posterior del historial no establece de forma retroactiva una observación ininterrumpida. ## 6. Añadir perspectivas de las cuentas sin perder su origen Utilice un espacio de trabajo independiente para cada cuenta distinta y repita su inventario. Conserve el ID de la cuenta, la función, la huella digital de la clave de firma y las referencias de origen en cada comparación. Los números de mensaje no son identificadores globales válidos para todos los chats o cuentas. Case Board mantiene las notas y colecciones vinculadas a las fuentes dentro de cada espacio de trabajo. La pantalla de grupo revisa conjuntamente el estado de las cuentas y puede agrupar exportaciones de espacios de trabajo independientes. Correlaciona esas fuentes en tus notas del caso o herramientas de análisis; cada diario conserva su propio origen y clave de firma. No se genera una búsqueda global ni una línea de tiempo fusionada entre espacios de trabajo. La exportación multicuenta de un canal o supergrupo obtiene el historial de ese chat utilizando las cuentas elegibles. En el caso de trabajos de mayor envergadura, mantenga los límites con un [testigo independiente](https://phishdestroy.github.io/TgWitness/es/docs/reference/witness/). Utilice comprobaciones de entrega controladas para validar la ruta de captura y la visibilidad de cada cuenta. ## 7. Recopilar y verificar el traspaso del caso Mantenga todo esto reunido en un directorio de casos elaborado por un analista: | Material | Objetivo | | --- | --- | | Notas de caso y registro de fuentes | Pregunta, política de recopilación, acceso/funciones, conclusiones, explicaciones alternativas y lagunas | | Cronología | En cada entrada se incluyen tanto las fechas como las referencias al espacio de trabajo, el chat, el mensaje y la secuencia. | | Case Board exportación y fragmentos, si se utilizan | Marcadores vinculados a la fuente, citas, notas del equipo, colecciones, historial de revisiones y registros seleccionados contrastados con el archivo ZIP de pruebas. | | Archivo ZIP de pruebas firmadas por espacio de trabajo | Registro completo, manifiesto y archivos multimedia conservados incluidos; los filtros del panel no limitan la exportación del registro. | | Archivos de perfiles de personas firmados por separado | Las referencias derivadas se han cotejado con las pruebas correspondientes del espacio de trabajo. | | Exportaciones completas y firmadas de chats | Captura del historial visible actual, independiente del registro de observación | | Huellas digitales fiables y puntos de control anteriores | Identidad clave y límites del registro conservado | | Elementos de prueba, si se ha configurado | Registro independiente, entradas firmadas y huella digital del testigo | | Resultados de la verificación y hash de los archivos entregados | Qué se ha comprobado, qué bytes se han transferido y a quién | Desde una instalación de confianza, con los nombres de los archivos y la huella digital real de cada espacio de trabajo: ``` python -m tgwitness.verify evidence.zip --fingerprint TRUSTED_PUBLIC_KEY_SHA256 --checkpoint retained-checkpoint.json python -m tgwitness.verify profiles-operations.json --fingerprint TRUSTED_PUBLIC_KEY_SHA256 --evidence evidence.zip python -m tgwitness.verify history-channel.zip --fingerprint TRUSTED_PUBLIC_KEY_SHA256 python -m tgwitness.verify board-slice.json --evidence evidence.zip --fingerprint TRUSTED_PUBLIC_KEY_SHA256 ``` Conserve los resultados reales de la verificación y los artefactos originales. Exporte las notas del espacio de trabajo de Case Board junto con el material de origen citado. Reúna los hallazgos de distintos espacios de trabajo en el directorio principal del caso; cada artefacto de TgWitness tiene su propia firma y procedimiento de verificación. ## Adaptar la investigación | Caso | Rastreo | Entregar | | --- | --- | --- | | Disputa sobre pedidos o pagos gestionada por un bot | Anuncio de entrada → vista previa del enlace guardado → parámetro de inicio del bot → versiones de mensajes y teclado → recibos de devolución de llamada del panel → seguimiento de mensajes privados y de grupo | Se ha respectado la cronología de ofertas y respuestas y se han verificado las fuentes; un enlace de pago por sí solo no constituye prueba de que se haya realizado dicho pago. | | Mensajes eliminados tras un incidente | Todos los chats afectados → originales y modificaciones guardados → resultados de eliminación o de ausencia tras una nueva comprobación → archivos multimedia conservados → cobertura y otras perspectivas de la cuenta | Versiones conservadas e intervalos desconocidos explícitos; no se atribuye a nadie la autoría de las eliminaciones. | | Un participante cambia de nombre en los distintos chats | ID numérico del remitente → historial de nombres/nombres de usuario → respuestas → otros chats observados → destinos/archivos citados | Una cronología de la actividad de una cuenta de Telegram con enlaces a los registros originales. | [Referencia de la recopilación](https://phishdestroy.github.io/TgWitness/es/docs/reference/collection/) · [Verificación de perfiles de personas](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#people-profiles) · [Entrega de pruebas](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#investigation-handoff) · [Validación completada](https://phishdestroy.github.io/TgWitness/es/docs/reference/verification/) --- # Telegram · Características y limitaciones Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reference/features/ El modelo de recopilación actual, los flujos de trabajo con varias cuentas, las exportaciones y los límites operativos de TgWitness. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) El modelo de recopilación actual, los flujos de trabajo con varias cuentas, las exportaciones y los límites operativos de TgWitness. [TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [Documentación](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) · [Referencia del proyecto](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) ![Referencia del proyecto](https://phishdestroy.github.io/TgWitness/assets/chapter-project.svg) TgWitness conserva las conversaciones de Telegram a las que tienen acceso las cuentas conectadas, registra los cambios observados y prepara exportaciones verificables. Esta referencia describe el modelo de recopilación, los flujos de trabajo actuales y sus límites. **En esta página** - [Aplicación independiente](https://phishdestroy.github.io/TgWitness/es/docs/reference/features/#standalone-application) - [Investigaciones compartidas](https://phishdestroy.github.io/TgWitness/es/docs/reference/features/#shared-investigations) - [Herramientas de archivo](https://phishdestroy.github.io/TgWitness/es/docs/reference/features/#archive-tools) - [Extras opcionales](https://phishdestroy.github.io/TgWitness/es/docs/reference/features/#optional-extras) - [Protocolo y fuentes privadas](https://phishdestroy.github.io/TgWitness/es/docs/reference/features/#protocol-and-private-sources) - [Cuentas múltiples](https://phishdestroy.github.io/TgWitness/es/docs/reference/features/#multiple-accounts) - [Captura y atribución](https://phishdestroy.github.io/TgWitness/es/docs/reference/features/#capture-and-attribution) - [Capacidad y límites de Telegram](https://phishdestroy.github.io/TgWitness/es/docs/reference/features/#capacity-and-telegram-limits) - [Fiabilidad y recuperación](https://phishdestroy.github.io/TgWitness/es/docs/reference/features/#reliability-and-recovery) - [Modelo de pruebas](https://phishdestroy.github.io/TgWitness/es/docs/reference/features/#evidence-model) - [Exportación, implementación y traspaso](https://phishdestroy.github.io/TgWitness/es/docs/reference/features/#export-deployment-and-handoff) - [Criterios de lanzamiento de la versión estable](https://phishdestroy.github.io/TgWitness/es/docs/reference/features/#stable-release-criteria) ## Aplicación independiente TgWitness cuenta con su propia instalación, su propio directorio de datos y su propio ciclo de vida de versiones. La interfaz web incluida se encarga de la configuración y la revisión; los registros exportados pueden utilizarse de forma independiente. El operador vincula sus cuentas, selecciona las fuentes visibles para cada una de ellas y obtiene un registro de observaciones guardado. El panel muestra el contenido, los cambios guardados, la procedencia de las observaciones y las lagunas conocidas. Otro investigador puede verificar el material exportado. El panel distingue entre la autorización de la cuenta, el acceso a una fuente, la actividad del recopilador y la cobertura registrada. Revisa esos estados en conjunto al evaluar un intervalo con pocos mensajes o un problema de conexión. ## Investigaciones compartidas Un administrador puede emitir [tokens de acceso](https://phishdestroy.github.io/TgWitness/es/docs/reference/access/) limitados a espacios de trabajo y chats individuales, con permisos por acción, restricciones de IP, caducidad, límites de inicio de sesión y control de sesión. Un revisor con acceso de solo lectura puede examinar un caso sin recibir la autorización de Telegram ni la clave del panel principal. El acceso limitado al chat permanece independiente de la configuración general de la cuenta y de las exportaciones completas del diario. MTProxy automático mantiene rutas de Telegram operativas a partir de cuatro fuentes públicas o de un catálogo de operadores. [Los modos de IP](https://phishdestroy.github.io/TgWitness/es/docs/reference/connection/#ip-modes) determinan si, en caso de fallo, se debe esperar a otro proxy o si se puede utilizar una ruta directa expresamente permitida. Las solicitudes HTTP externas cuentan con una ruta independiente y un interruptor de desactivación. ## Herramientas de archivo [La adquisición de historiales](https://phishdestroy.github.io/TgWitness/es/docs/reference/history/), [la búsqueda y el análisis de archivos](https://phishdestroy.github.io/TgWitness/es/docs/reference/analysis/),[el MCP de solo lectura](https://phishdestroy.github.io/TgWitness/es/docs/reference/mcp/), [el OCR y la transcripción locales](https://phishdestroy.github.io/TgWitness/es/docs/reference/media-analysis/), así como[los webhooks salientes](https://phishdestroy.github.io/TgWitness/es/docs/reference/webhooks/) se incluyen en 0.7.1. Los informes analíticos y el texto reconocido permanecen separados de los eventos capturados. [Case Board](https://phishdestroy.github.io/TgWitness/es/docs/reference/case-board/) añade marcadores vinculados a fuentes, citas, notas y colecciones dentro de un espacio de trabajo. El [generador de informes](https://phishdestroy.github.io/TgWitness/es/docs/reference/case-reports/) selecciona el material, las secciones y uno de los ocho diseños disponibles para las exportaciones compatibles en formato HTML/PDF. ## Extras opcionales La configuración diaria es: cuenta → fuentes → observación. **«Extras»** es un destino independiente con un bot de Telegram Witness y una vista previa de captura en GitHub. Cada uno indica su disponibilidad y requisitos antes de mostrar la configuración. Al seleccionar una ficha se abren las instrucciones; esto no implica registrarse ni iniciar un servicio. La configuración del bot consta de tres pasos: crear un acceso de solo lectura, elegir los ajustes de publicación y iniciar el bot en el servidor de TgWitness. Las opciones de red y publicación, las conexiones existentes y los comandos de verificación se revelan bajo demanda. La configuración descargada es distinta de un «witness» en ejecución. Al cambiar de extras se conserva el borrador; los cambios en la cuenta y el bloqueo borran el token temporal y el formulario. La guía integrada incluye instrucciones de puesta en marcha. [GitHub Actions captura](https://github.com/phishdestroy/TgWitness/blob/main/docs/SEALED-ACTIONS.md) y pone en marcha un colector fijado desde tu fork, captura un chat y genera un traspaso cifrado con la procedencia del flujo de trabajo. ## Protocolo y fuentes privadas **MTProto es el protocolo de Telegram; Telethon es la biblioteca de Python que utiliza TgWitness para comunicarse mediante MTProto.** No se trata de métodos de conexión alternativos. La recopilación utiliza MTProto; el «witness» opcional publica comprobaciones firmadas a través de la API del bot. Cada espacio de trabajo cuenta con su propio cliente autorizado y su propio flujo de actualizaciones de la cuenta. TgWitness selecciona las observaciones de las fuentes configuradas y realiza solicitudes explícitas independientes para funciones como instantáneas del historial y descargas de archivos multimedia. Una fuente privada no necesita un nombre de usuario público. El tipo de par de Telegram y el identificador numérico son los identificadores; los títulos y los nombres de usuario pueden cambiar. El acceso depende de la afiliación y los permisos existentes. TgWitness no se une automáticamente a las fuentes ni elude la aprobación de la adhesión. Un hash de acceso procedente de otra cuenta no constituye un token de acceso universal. El modelo de recopilación debe tener en cuenta el historial oculto previo a la incorporación, los roles de los participantes y administradores, la revocación de sesiones, la eliminación o modificación de permisos, la migración de grupos a supergrupos, los temas y foros, las discusiones vinculadas, las identidades de los canales y los archivos adjuntos no disponibles. No todas las combinaciones se han validado en tiempo real. La visibilidad de la fuente se comprueba al iniciar el recopilador. La ausencia de una fuente en el resultado delimitado del diálogo significa que **el acceso no está confirmado**, no que se haya demostrado su eliminación. Una fuente no disponible no impide observar otras fuentes accesibles. Nunca incluya enlaces de invitación ni sesiones reales en elementos públicos. ## Cuentas múltiples El panel admite un número ilimitado de **espacios de trabajo**, cada uno con sus propios: - Autorización, almacén cifrado y ruta de conexión. - Registro SQLite e identidad de firma Ed25519. - Fuentes seleccionadas, cola de medios y ajustes de captura. - Estado de observación, errores, puntos de control y exportaciones. Cambiar el espacio de trabajo visible no detiene a otro recopilador. Se rechaza la autorización de cuentas duplicadas entre espacios de trabajo. Un registro ya vinculado a una cuenta de Telegram no puede reasignarse a otra; sí se permite volver a conectar la misma cuenta. De este modo se preserva la identidad de la cuenta y el ámbito de los ID de mensajes pertinentes. La aplicación no establece un número fijo de espacios de trabajo. Cada espacio de trabajo ejecuta sus propias tareas de recopilación para la supervisión de conexiones, descargas de archivos multimedia, revisiones y captación de nuevos chats dentro de un proceso compartido de Python y un bucle de eventos. El rendimiento depende de la carga de trabajo. Para aislar los procesos, utilice instalaciones, puertos y directorios de datos independientes. Asigna a cada cuenta las fuentes a las que puede acceder. Diferentes cuentas pueden observar el mismo grupo, pero sus observaciones permanecen separadas y conservan su origen. Dos cuentas en un mismo equipo controlado por un operador no constituyen dos testigos independientes. **La exportación de grupo** agrupa los archivos ZIP de los espacios de trabajo firmados por separado con una lista de archivos firmada que contiene sus ID de espacio de trabajo, hash y huellas de las claves de firma. Cada diario conserva su propio límite. Crea una línea temporal combinada entre espacios de trabajo en las notas del caso o en herramientas de análisis, conservando esas referencias a las fuentes. ## Captura y atribución La sección «Fuentes» ofrece opciones por cuenta para mensajes nuevos, modificaciones, eliminaciones, reacciones y pertenencia a grupos. Los ajustes preestablecidos conservan todas las categorías o bien los mensajes, las modificaciones y las eliminaciones. La política se aplica a los grupos seleccionados del espacio de trabajo, se mantiene tras el reinicio y está firmada con los cambios anteriores y posteriores. Los valores predeterminados conservan todas las categorías. Desactivar una categoría no elimina los registros antiguos; volver a activarla no reconstruye los eventos omitidos. Los registros operativos, otros eventos del servicio de grupo y las instantáneas explícitas del historial son independientes. Los objetos de Telegram capturados pueden conservar metadatos incrustados independientemente de los parámetros de actualización independiente. Todavía no existen anulaciones de categorías por grupo. | Material | Capturado ahora | Límites | | --- | --- | --- | | Mensaje | Texto, identificadores de interlocutor/mensaje, metadatos del remitente, respuestas y sobre de actualización original | Se conserva como una observación visible en la cuenta y firmada por el recopilador. | | Editar | Nueva versión observada y cualquier versión guardada anteriormente | Las modificaciones realizadas durante el tiempo de inactividad pueden perderse; el remitente no es necesariamente quien realiza la edición. | | Eliminación | Notificación y contenido capturado previamente, si lo hubiera | Por lo general, no se indica quién ha eliminado el mensaje ni la hora exacta de la acción. | | Aviso de eliminación a nivel de cuenta | Aviso original; los registros resueltos incluyen el chat guardado y el método de correlación. | Se requiere exactamente una coincidencia de un chat privado o un grupo ordinario guardado previamente dentro del ámbito; los demás identificadores permanecen en «`deletion.unscoped`». Los identificadores de canales y supergrupos quedan excluidos de esta correlación. | | Reacción | Contadores de mensajes enviados e identidades recientes visibles | Para obtener una lista completa de los reactores disponibles es necesario realizar consultas por separado; los canales pueden ocultar identidades. | | Afiliación | Mensajes de servicio y actualizaciones enviadas a los participantes | La visibilidad depende del rol y del tipo de chat; la ausencia de eventos no implica que no se hayan producido. | | Acciones de administración | Actualizaciones relevantes entregadas y una instantánea del registro de administración en las exportaciones de chats de canales y supergrupos. | La exportación lee el registro cuando está disponible para la cuenta de administrador que realiza la exportación; la consulta continua del registro de administración queda fuera de este proceso. | | Archivo adjunto | Descriptor de la versión original, bytes descargados/SHA-256 y resultados de los intentos | Un archivo eliminado puede ser irrecuperable; la última versión no se sustituye. | | Historia | Captura de pantalla explícita de los mensajes visibles en ese momento | No reconstruye todas las modificaciones ni el contenido eliminado. | | Proceso de recopilación | Inicio/parada, señal de vida, errores, configuración, ámbito y recibo de ejecución firmado | Inventario local; GitHub y TDX añaden [comprobaciones de entorno independientes](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#verification-scope) | La interfaz indica el nombre de la cuenta facilitada en el evento de origen y conserva los nombres y nombres de usuario observados. Cuando el evento omite quién es el autor, el informe deja ese campo sin especificar. ## Capacidad y límites de Telegram No existe un número universal de chats que puedan supervisarse con calidad garantizada. La capacidad depende de los picos de eventos por segundo, el volumen y el tamaño de los archivos adjuntos, los RPC adicionales, las cuentas activas, la latencia del disco y el espacio libre, las condiciones de la red, los límites de Telegram, el retraso aceptable y la profundidad de la cola. Telegram distingue entre la entrega pasiva y el sondeo activo breve. Su documentación de actualización describe llamadas `updates.getChannelDifference` adicionales para canales abiertos y supergrupos, y recomienda un máximo de **diez fuentes sometidas a sondeo activo breve simultáneamente**. Esto no supone un límite de diez grupos seleccionados ni una garantía de exhaustividad. | Modo | Objetivo | Estado | | --- | --- | --- | | Observación estándar | Registre las actualizaciones recibidas de fuentes seleccionadas | Implementado | | Revisiones prioritarias | Las fuentes marcadas con una estrella utilizan su propio intervalo configurable y tienen prioridad en cada pasada de revisión delimitada. | Implementado con consultas de historial y mensajes | La estrella de prioridad controla estas revisiones. El sondeo corto adicional «`updates.getChannelDifference` » no se muestra como un modo de usuario independiente. Las consultas arbitrarias de alta frecuencia, que ignoren FloodWait o asuman una capacidad lineal procedente de cuentas adicionales, no constituyen un modelo de dimensionamiento válido. Los límites predeterminados son los primeros 1.000 diálogos de la lista, hasta 500 mensajes por instantánea del historial, entre 1 y 2.000 MiB por archivo recopilado según el tipo, y 4 GiB de contenido ZIP firmado sin comprimir; cada uno de estos valores se modifica por espacio de trabajo en **«Parámetros**». Las exportaciones no tienen un límite fijo de recuento de eventos. El modo alternativo del navegador está limitado a 128 MiB de forma predeterminada; la CLI de transmisión tiene un límite de transferencia configurable, de 5 GiB de forma predeterminada. ## Fiabilidad y recuperación Entre los comportamientos implementados se incluyen transacciones WAL/sincrónicas de SQLite; escrituras atómicas de mensajes y tareas multimedia; tareas persistentes y retrasos en los reintentos; descriptores de la versión original; reintentos limitados; FloodWait de archivos multimedia persistentes; descargas de archivos multimedia fuera de la espera de red del evento de texto; exportaciones con prefijo estable mientras continúan las escrituras posteriores; ajustes atómicos y registros de auditoría; conservación de la autorización de trabajo tras un fallo en el inicio de sesión de sustitución; aislamiento de un espacio de trabajo adicional dañado; intentos explícitos de reconexión; informes diferenciados de pérdida de autorización; y detección de cambios en el reloj real mediante un reloj monótono. Los puntos pts, qts y seq de las cuentas y los canales se guardan y se recuperan tras un reinicio, y los chats observados se vuelven a comprobar periódicamente; véase [el formato de las pruebas](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#durable-collection-and-process-receipts-02). Guardar la posición periódicamente no constituye una confirmación atómica y sin pérdidas de la aceptación del registro. Cada inicio de proceso registra el encabezado anterior y el límite fuera de línea. El historial actual no se trata como una reparación de lagunas. La retención de diferencias de Telegram es finita; `differenceTooLong` no puede reconstruir todo el contenido desaparecido. Las lagunas irrecuperables deben permanecer explícitas incluso si una instantánea posterior del historial tiene éxito. ## Modelo de pruebas Cada evento registra una secuencia, la hora de observación local en UTC, la hora de origen (cuando se facilite), el tipo, la fuente, el autor (cuando se facilite), la carga útil original, el hash anterior y la firma. Las observaciones de mensajes también conservan la cuenta del recopilador y el contexto de ejecución. El recibo de proceso firmado contiene un identificador de ejecución aleatorio; las versiones de TgWitness/Python/OS y sus dependencias; los valores SHA-256 de los archivos fuente y la huella digital agregada; la cuenta inicial, el ámbito y la configuración; lecturas UTC/monotónicas; y el encabezado del registro anterior. Los cambios en la configuración, el inicio y la detención, así como los errores, se registran en el mismo registro. Los puntos de control se conservan al inicio, cada cinco minutos durante la observación (parámetro modificable) y al detener la herramienta de forma ordenada. Un punto de control local conservado permite detectar una reversión a un prefijo de registro anterior. | Mecanismo | Qué establece | | --- | --- | | SHA-256 del archivo | Los bytes coinciden con un resumen conocido | | Cadena de hash de eventos | Ordenación y vinculación de registros en relación con un límite conocido | | Ed25519 | Firma con una clave concreta | | Punto de control conservado de forma independiente | El material posterior se ajusta a los límites establecidos. | | Análisis del archivo del programa | Informe del propio recopilador sobre los archivos analizados | | Respuesta válida e independiente de la TSA | Existencia de bytes concretos en el momento TSA bajo supuestos de confianza explícitos | Se han implementado la preparación de solicitudes según el RFC 3161 y la verificación de respuestas mediante OpenSSL. El modo «Evidence» también envía los hash de los puntos de control a los servicios de marca de tiempo configurados. Conserva y verifica la respuesta de la autoridad para establecer un punto de referencia temporal independiente. Consulta [TIMESTAMP.md](https://phishdestroy.github.io/TgWitness/es/docs/reference/timestamp/). Conserve los puntos de control de forma independiente, controle el acceso a las claves de firma, mantenga registros de transferencia y verifique las exportaciones con software de confianza. El [alcance de la verificación](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#verification-scope) explica cómo se complementan entre sí esas comprobaciones y qué supuestos de confianza se aplican. ## Exportación, implementación y traspaso Un archivo ZIP firmado contiene los archivos originales en formato JSONL, CSV y HTML, los archivos adjuntos conservados, los hash, un manifiesto firmado y un verificador de conveniencia. Abarca un espacio de trabajo y un prefijo fijo para el registro completo. Los filtros de búsqueda del panel no eliminan registros de forma silenciosa. Se excluyen las claves secretas, los tokens y las sesiones de Telegram; las observaciones originales pueden seguir conteniendo información personal y metadatos de Telegram. Conserve por separado el resumen ZIP, la huella digital de confianza, el punto de control, el acuse de recibo del proceso y el registro de traspaso. Utilice un verificador procedente de una instalación de confianza, en lugar de confiar en el código ejecutable únicamente porque aparece en el archivo ZIP examinado. La interfaz del navegador se distribuye localmente sin necesidad de Node.js, CDN ni fuentes externas. Un token de operador controla la instalación. El acceso remoto requiere HTTPS o un túnel SSH. Se proporcionan definiciones nativas en Python y de contenedores, con ejemplos de servicios en [la carpeta «deploy/»](https://github.com/phishdestroy/TgWitness/blob/main/deploy/README.md); las comprobaciones de plataforma ejecutadas se enumeran por separado. El espacio de trabajo predeterminado utiliza la raíz de datos; los espacios de trabajo adicionales utilizan `profiles//`. La copia de seguridad requiere que el proceso esté detenido y que se disponga del conjunto completo de datos y claves. Los archivos ZIP de pruebas no son copias de seguridad de la aplicación. Secrets puede utilizar una clave maestra externa para un nuevo directorio de datos; el cifrado del registro y los archivos multimedia lo proporciona el disco o volumen del operador. Consulte [CONNECTION-SECURITY.md](https://phishdestroy.github.io/TgWitness/es/docs/reference/connection/) y [OPERATIONS.md](https://phishdestroy.github.io/TgWitness/es/docs/reference/operations/). ## Criterios de lanzamiento de la versión estable Antes de una versión estable, especifique: 1. Grupos privados reales, supergrupos, foros y canales con roles de miembro/administrador y historial oculto/visible, incluyendo inicio de sesión/autenticación de dos factores (2FA), revocación y pérdida de acceso. 2. Se controlan las modificaciones, las eliminaciones, las reacciones, la pertenencia a grupos y los archivos multimedia en relación con acciones conocidas. 3. Fallos del proceso o del servidor, fallos del disco o disco lleno, referencias a archivos caducados, FloodWait, pérdida de conexión, archivos dañados y reversión de la base de datos. 4. Uso continuado de múltiples cuentas con retrasos, colas, memoria y disco controlados, incluyendo fuentes silenciosas y ruidosas de forma conjunta. 5. Interrupción entre el avance del estado de MTProto y la aceptación del registro. 6. Instalación limpia en la matriz de sistemas operativos y contenedores prevista, y restauración de copias de seguridad verificada. 7. Revisión independiente de la seguridad, las firmas y las afirmaciones relativas a la atribución y las pruebas. El acceso limitado a los paneles se describe en [«Acceso y permisos](https://phishdestroy.github.io/TgWitness/es/docs/reference/access/)». La versión 0.6 admite la importación de TData de una sola cuenta delimitada y la importación de archivos de cuenta descritas en [ACCOUNTS.md](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/). Revisa los términos de la API de Telegram antes de la publicación. Las referencias de investigación y los resultados sobre la plataforma se encuentran en [RESEARCH.md](https://github.com/phishdestroy/TgWitness/blob/main/docs/internal/RESEARCH.md). --- # Telegram · Referencia de Case Board Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reference/case-board/ Marcadores, resaltados exactos, fragmentos de acción, debates, acceso restringido y el historial de anotaciones firmadas que utiliza Case Board. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Marcadores, resaltados exactos, fragmentos de acción, debates, acceso restringido y el historial de anotaciones firmadas que utiliza Case Board. [TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [Documentación](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) · [Investigación](https://phishdestroy.github.io/TgWitness/es/docs/reference/investigation/) ![Investigación](https://phishdestroy.github.io/TgWitness/assets/chapter-investigate.svg) Case Board ofrece al equipo de investigación una vista de trabajo compartida del material guardado. Se puede marcar una observación, resaltar un pasaje concreto, guardar una serie de acciones y comentarlas con los compañeros. Las fichas conservan sus referencias de origen y el historial de revisiones firmado. Las anotaciones del equipo permanecen en el espacio de trabajo, identificables por separado de las observaciones originales de Telegram. [Modelo de pruebas](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/) · [Acceso](https://phishdestroy.github.io/TgWitness/es/docs/reference/access/) · [Informes](https://phishdestroy.github.io/TgWitness/es/docs/reference/case-reports/) ![Feed de investigación sintético](https://phishdestroy.github.io/TgWitness/assets/case-board.png) **En esta página** - [Trabajar con un caso](https://phishdestroy.github.io/TgWitness/es/docs/reference/case-board/#work-with-a-case) - [Permisos](https://phishdestroy.github.io/TgWitness/es/docs/reference/case-board/#permissions) - [Contratos almacenados](https://phishdestroy.github.io/TgWitness/es/docs/reference/case-board/#stored-contracts) - [API y exportaciones](https://phishdestroy.github.io/TgWitness/es/docs/reference/case-board/#api-and-exports) - [Límites de funcionamiento](https://phishdestroy.github.io/TgWitness/es/docs/reference/case-board/#operating-limits) ## Trabajar con un caso Abre **Investigación → «Case Board»** en modo Estándar o Experto. El idioma se adapta al panel. Utiliza **la** **opción** **«Añadir al panel»** junto a un registro del diario o un mensaje de chat guardado, o selecciona el elemento y pulsa **B**. El marcador se añade a la Bandeja de entrada con un solo clic. Edita su título, etiquetas y nota, o muévelo a una colección. Una tarjeta modificada incluye una revisión firmada; al eliminarla se conserva el historial. Para un primer caso, elige una recopilación y añade los registros que respondan a una pregunta. Utiliza los comentarios para revisar la interpretación y, a continuación, **la opción «Presentación»** para recorrer las fichas y el contexto de las fuentes. Selecciona el material del «Case Board» por separado en [«Report Studio»](https://phishdestroy.github.io/TgWitness/es/docs/reference/case-reports/) al preparar el informe. Guardar una sección no configura automáticamente los filtros de datos del informe. Selecciona texto dentro de un mensaje de chat guardado para que aparezca **«Resaltar → tablero**». Selecciona su color y añade una nota. El servidor comprueba la cita exacta y la versión guardada, incluidos los emojis, el texto RTL y los signos de combinación. La interfaz no asigna una selección a través de texto enmascarado o transformado. Pulsa Mayús + clic en dos registros de un mismo chat para **«Slice between**» (**Seleccionar entre**), utiliza **«Slice by time**» (**Seleccionar por tiempo**) o guarda los filtros actuales del diario para chat, periodo y tipo de evento. Una selección guardada tiene su propio predicado de referencia: al abrirla en el Diario, también se aplican múltiples chats, límites de número de mensajes y filtros de participantes . La opción **«Mostrar registros añadidos desde el marcador»** aísla las adiciones posteriores. Cambiar los filtros de Journal hace que se salga de la sección. Desde «Personas», la opción **«Dividir las acciones de esta persona»** utiliza el ID de actor registrado; no da por sentado que el autor del mensaje lo haya editado, eliminado o haya reaccionado a él. El cuadro de diálogo de selección muestra una vista previa de los recuentos antes de permitir la creación. «`all`» incluye todos los tipos registrados, incluidas instantáneas, ediciones, eliminaciones, reacciones, actualizaciones de membresía o servicio, acciones propias, botones, resultados multimedia, mensajes recuperados y tipos de eventos futuros. La selección describe las observaciones guardadas. Los avisos de eliminación de chats desconocidos constituyen un contexto independiente, disponible únicamente para el acceso a todo el espacio de trabajo, y nunca se atribuyen a ninguno de los chats seleccionados. Las colecciones tienen un ámbito de chat definido. Un ámbito vacío significa todo el espacio de trabajo. Una colección no puede contener tarjetas fuera de su ámbito; un participante con acceso limitado a un chat no puede leer una colección de ámbito más amplio. La bandeja de entrada es una colección virtual para tarjetas sin asignar. La búsqueda y los filtros abarcan únicamente las tarjetas visibles; los hilos y las menciones heredan el acceso de la tarjeta principal. Los comentarios eliminados tienen una marca de eliminación en la discusión. No se registra ningún historial de visualización. **La «Presentación»** abre todas las fichas de la colección elegida, con las vistas «Ficha», «Contexto de la fuente» y «Comentarios del equipo», así como los controles de teclado «Anterior» y «Siguiente». No ofrece controles de edición. El feed habitual está paginado; la «Presentación» carga su lista por páginas y recupera los detalles de una ficha cada vez. ## Permisos Todas las operaciones requieren `view`, el ámbito del espacio de trabajo/chat y `board.read`. `board.write` añade tarjetas, comentarios, movimientos y estados de «abierto»/«revisado». `board.manage` permite la gestión de la recopilación, los estados «confirmado»/«desestimado» y la revisión o eliminación de la tarjeta de otra persona. Un estado es una decisión del equipo, no el resultado de una verificación criptográfica. Acceder a las configuraciones predefinidas de los formularios: Revisor = lectura; Analista = lectura/escritura; Operador = lectura/escritura/gestión, además de sus permisos existentes. Las autorizaciones existentes no adquieren nuevos derechos de forma implícita. El administrador principal tiene todos los derechos y publica como **«Administrador principal**». Utiliza concesiones con nombre para la atribución. Las menciones solo incluyen los accesos actuales capaces de leer la ficha principal completa. Una autorización para el chat A no puede obtener una tarjeta o una porción para A+B, ni siquiera adivinando su ID o proporcionando un `target.chat_id` falso. Los metadatos del objetivo se resuelven a partir del hash del evento firmado en el servidor. Las recopilaciones, el recuento de comentarios, las tarjetas relacionadas y las notificaciones en tiempo real se filtran antes de la respuesta. Las exportaciones requieren tanto `export` como `board.read`; un exportador existente sin acceso al tablero obtiene el archivo de pruebas habitual sin las notas del equipo. SSE vuelve a comprobar los permisos actuales antes de cada lote. ## Contratos almacenados Al igual que las observaciones, las anotaciones se escriben de forma transaccional en una tabla SQLite de solo apéndice en el espacio de trabajo. `annotations.jsonl` es su exportación canónica exacta a partir de la misma instantánea de lectura que `events.jsonl`. No existe un segundo almacén de anotaciones competidor ni ningún evento de registro en `board.activity`. Cada línea debe contener exactamente: ``` { "seq": 1, "at": "2026-11-02T14:00:00.000+00:00", "access_id": "admin", "access_label": "Main administrator", "kind": "board.bookmark", "payload": {"id": "32 lowercase hex digits", "target": {"event_hash": "64 lowercase hex digits"}}, "previous_hash": "64 zeroes for the first record", "hash": "SHA-256 described below", "signature": "base64 Ed25519 signature" } ``` El ejemplo abreviado anterior ilustra la estructura general; las cargas útiles reales incluyen sus valores predeterminados de modelo y los campos de destino resueltos por el servidor. Los esquemas de solicitud de la API se encuentran en [`tgwitness/schemas`](https://github.com/phishdestroy/TgWitness/blob/main/tgwitness/schemas/board-bookmark.json), generados a partir de los modelos Pydantic en tiempo de ejecución mediante la herramienta `python tools/build_board_schemas.py`. Se rechazan los campos de solicitud adicionales. Los ID se generan en el lado del servidor cuando se omiten. La autoría, la hora, la instantánea y la firma no pueden ser proporcionadas por el solicitante. Los ID de concesión con nombre siguen el formato hexadecimal de 16 caracteres existente de Access; los ID de tarjeta son de 32 caracteres hexadecimales. El JSON canónico está en UTF-8, con claves de objetos ordenadas, sin espacios en blanco entre tokens, Unicode sin escapar, y sin valores NaN ni infinitos. El hash de la anotación es un SHA-256 del objeto canónico que contiene el form `format: "tgwitness-annotations-v1"` y los siete campos de la envoltura hasta `previous_hash`. Esta etiqueta de formato separa su dominio de hash de las observaciones. La firma es Ed25519 sobre los 32 bytes sin procesar del hash. La secuencia comienza en 1. Las revisiones conservan el ID de la tarjeta y nombran el hash de anotación anterior en «`supersedes`»; no pueden cambiar el ámbito del chat. Los desplazamientos, los estados y las eliminaciones son registros independientes. La tabla SQLite rechaza las órdenes UPDATE y DELETE. `case-board.json` contiene `{statement, signature}`. La declaración canónica está firmada por la clave del espacio de trabajo y contiene `format: "tgwitness-case-board-v1"`, `public_key`, `created_at`, `journal_head`, `meaning` y `state`. El estado es una reproducción determinista: `annotations_head`, una matriz ordenada de `items` (colecciones, tarjetas, comentarios, incluidas las marcas de eliminación) y `status_history`. Los elementos conservan el hash de su última anotación, la secuencia, el autor y la hora, así como el creador original y la hora de creación a lo largo de las revisiones. La reproducción comprueba las revisiones, los elementos padres, las referencias a colecciones y los ID de acción duplicados. «`manifest.json`» y los nuevos puntos de control también vinculan «`annotations_head`». Se conserva un punto de control de forma independiente para detectar truncamientos o reescrituras con una clave de firma copiada. ### Versiones de texto `range.start` es un desplazamiento de punto de código Unicode con base en cero, `length` es un recuento positivo de puntos de código, y `quote` debe ser igual a la subcadena exacta de `payload.text` o `payload.caption` en el evento de destino. No se aplica NFC/NFKC, conversión de mayúsculas a minúsculas ni normalización de grafemas. Las secciones de cadena de Python y `Array.from(text)` de JavaScript implementan la misma indexación. La combinación de marcas y emojis ZWJ puede ocupar varios puntos de código. `range.version` es el hash del evento de destino, no la versión actual del mensaje ni el desplazamiento de entidad UTF-16 de Telegram. Las ediciones posteriores nunca reubican un resaltado automáticamente. ### Identidad y hora de la sección `query` acepta exactamente un `chat_id` o varios `chat_ids` no vacíos, un rango opcional `from`/`to`, límites de ID de mensaje inclusivos (solo un chat), `kinds: "all"` o tipos exactos/con comodines de prefijo, `actors` explícitos, `search`, `hide_system` e `include_unscoped`. Los grupos de tipos de diario se expanden a sus predicados exactos. La búsqueda utiliza la búsqueda de carga útil NFC/sin distinción de mayúsculas y minúsculas del diario sin alterar el texto fuente firmado. Las fechas requieren una zona horaria y se normalizan a UTC. Las fechas filtran **«observed_at**». El «`source_at`» de Telegram se muestra por separado. Una eliminación sin una marca de tiempo de origen no tiene una hora de eliminación inventada. Un registro tardío observado fuera de un intervalo de tiempo no entra en él; un fragmento de ID de mensaje puede incluir una eliminación posterior para esos ID de mensaje. La «`snapshot`» fija la hora de creación, la secuencia del diario/límite de hash, el recuento de coincidencias, la primera/última secuencia y el «`result_hash`». Este último es un SHA-256 de la matriz JSON canónica en UTF-8 de los hashes de eventos coincidentes ordenados lexicográficamente, incluyendo `[]` para una sección vacía. También contiene recuentos exactos de tipos y una miniatura del tiempo de observación de 24 intervalos. Un segmento almacena una consulta, no registros de fuente duplicados . Al exportar, «`board/slices/.json`» enumera los hash actuales y las secuencias añadidas o eliminadas. El verificador reconstruye el resultado original en el momento de la creación y, a continuación, el resultado actual. Los registros añadidos se notifican como un hecho de cambio. La eliminación de un evento original rompe la cadena de pruebas inmutable; no se acepta de forma silenciosa como una eliminación ordinaria de una sección. Las instantáneas de reacciones tienen listas incompletas de participantes recientes. El explorador compara instantáneas adyacentes del mismo chat o mensaje, incluida una anterior fuera del fragmento, e informa de las diferencias de recuento agregadas **entre observaciones**. No se considera que los participantes recientes que faltan hayan eliminado una reacción. La primera instantánea no tiene un estado anterior inferido. Las observaciones de los actores siguen atribuyéndose a la instantánea en la que se proporcionaron, no a un momento de acción inventado. ## API y exportaciones `GET /api/board` acepta collection/chat/author/label/state/from/to/q/kind/comments, offset/limit y el orden más reciente/más antiguo. `GET /api/board/card/{id}` devuelve una ficha, una vista previa de la fuente, el hilo, el historial de estado y las fichas relacionadas. La subruta de participantes devuelve las opciones de mención elegibles. `POST /api/board/{bookmark|highlight|slice|collection|comment|status|move|remove}` añade un registro. `POST /api/board/slice-preview` calcula una consulta. Los registros de «slice» se paginan en `GET /api/board/slice/{id}/records`; el recálculo utiliza siempre la instantánea de lectura estable actual. `/api/stream` en tiempo real emite notificaciones de `board` sin carga útil, independientemente de los cursores del diario. `GET /api/board/export` devuelve un documento firmado. El acceso limitado al chat recibe una **divulgación** firmada claramente etiquetada, nunca las anotaciones de otro chat ni la cadena completa. Los archivos ZIP con pruebas completas incluyen `annotations.jsonl`, `case-board.json` firmado y apéndices JSON de fragmentos. La configuración de informes en HTML/PDF/JSON permite seleccionar «sin tablero», marcadores o fragmentos sin debate, o tarjetas con comentarios. La sección separa explícitamente las opiniones del equipo de las observaciones. Los filtros de datos del informe también restringen las notas legibles; los archivos fuente completos y firmados del archivo ZIP de pruebas permanecen íntegros. `GET /api/board/slice/{id}/export` genera un extracto JSON firmado de «`tgwitness-board-selection-v1`»; `?format=csv` genera una tabla práctica sin firma independiente. Mantén el JSON y el ZIP: ``` python -m tgwitness.verify evidence.zip --fingerprint TRUSTED_KEY_SHA256 --board python -m tgwitness.verify board-slice.json --evidence evidence.zip --fingerprint TRUSTED_KEY_SHA256 python -m tgwitness.verify case-board.json --evidence evidence.zip --fingerprint TRUSTED_KEY_SHA256 ``` La comprobación de selección autentifica la declaración firmada, los registros de origen exactos y la integridad de su consulta en el límite especificado. El archivo ZIP de pruebas puede ser más reciente, pero debe contener ese prefijo. Se notifica explícitamente cualquier objetivo sin asignar. Se rechazan las instantáneas de fragmentos originales diferentes, las anotaciones modificadas, los estados de reproducción que no coincidan o las fuentes modificadas. Los archivos antiguos sin anotaciones conservan su comportamiento de verificación actual. La opción predeterminada para el traspaso es **«No incluir**». La inclusión explícita genera fichas a partir de los registros ya minimizados, omite los objetivos inaccesibles u omitidos, retiene los elementos destacados cuyo texto original se haya minimizado, depura el texto del equipo siguiendo las mismas reglas de menciones y contactos, y, opcionalmente, sustituye las etiquetas de los investigadores por R01, R02… en los metadatos y en las apariciones conocidas en las notas. No se divulga ningún archivo « `annotations.jsonl`» original. El archivo sidecar firmado «`tgwitness-case-board-handover-v1`» y el informe contienen el mismo material minimizado. Los recuentos de segmentos describen únicamente los registros divulgados, ocultando los detalles originales del actor de la instantánea o la consulta. Los nombres en texto libre desconocidos para el minimizador siguen requiriendo revisión, al igual que en los traspasos habituales. Esta versión derivada no pretende conservar las firmas de las anotaciones originales tras la censura. ## Límites de funcionamiento Los parámetros incluyen límites flexibles de 10 000 tarjetas y 50 000 comentarios, una página de fragmentos de hasta 5 000 registros y control de la vista previa de archivos multimedia. Los límites flexibles avisan sin borrar el historial. Las páginas de feeds tienen un máximo de 200 fichas. Los extractos de fragmentos JSON independientes tienen un límite de 64 MiB; restringe la consulta o utiliza el archivo ZIP firmado para material de mayor tamaño. El verificador independiente limita la reproducción de anotaciones a 256 MiB. Case Board no tiene habilitadas ni implementadas notificaciones de comentarios externos. La aceptación automatizada de la función utiliza datos ficticios y una transmisión simulada de Telegram para comprobar el almacenamiento, el acceso, la visualización y las exportaciones. Consulte [el alcance de la verificación](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#verification-scope) para conocer el alcance de las comprobaciones de las pruebas. --- # Telegram · Análisis de archivos Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reference/analysis/ Busca mensajes guardados, revisa las aportaciones de la IA y conserva informes analíticos con sus referencias de origen. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Busca mensajes guardados, revisa las aportaciones de la IA y conserva informes analíticos con sus referencias de origen. [TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [Documentación](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) · [Investigación](https://phishdestroy.github.io/TgWitness/es/docs/reference/investigation/) ![Investigación](https://phishdestroy.github.io/TgWitness/assets/chapter-investigate.svg) [Guía de flujo de trabajo](https://phishdestroy.github.io/TgWitness/docs/archive/) · [Wiki](https://github.com/phishdestroy/TgWitness/blob/main/docs/wiki/Archive-and-Integrations.md) Utiliza **el Diario** para realizar búsquedas locales sin IA; [la búsqueda de texto completo](https://phishdestroy.github.io/TgWitness/es/docs/reference/search/) (vista previa) coincide con formas de palabras, frases, dominios y @nombres de usuario. Para **«Preguntar al archivo**», primero habilita y configura un proveedor en **«Integraciones**». El selector de espacio de trabajo elige la cuenta; el formulario elige los chats y el periodo de observación. La recuperación se realiza localmente. Una frase exacta o un dominio restringe la recuperación; un ID de mensaje solicita las versiones guardadas. Revisa los extractos y abre sus registros del diario o su contexto. No hay ninguna base de datos vectorial ni acción automática de Telegram. ## Proveedores y consentimiento La IA viene desactivada por defecto en todos los espacios de trabajo. Solo el administrador principal puede configurar el modelo, el punto final, la clave API cifrada, los límites de contexto y salida, el tiempo de espera y el límite diario de solicitudes. La clave nunca se devuelve al navegador. Deja el campo de la clave en blanco para conservar la clave actual, o elimínala explícitamente. Ollama utiliza su [punto final `/api/chat`](https://docs.ollama.com/api/chat) documentado con salida JSON sin streaming. Su dirección predeterminada es `http://127.0.0.1:11434` en el servidor de TgWitness. El operador puede cambiarla utilizando `TGWITNESS_AI_LOCAL_ENDPOINT`; no se trata de una dirección controlada por el modelo. Instala tú mismo el modelo seleccionado. TgWitness no lo descarga automáticamente. El proveedor compatible debe tener una URL base que termine en `/v1` y admitir el [protocolo Chat Completions](https://developers.openai.com/api/reference/resources/chat/subresources/completions/methods/create): `messages`, modo de respuesta JSON, `max_completion_tokens` y `choices[0].message.content`. No se admiten los servicios que carezcan de estos campos. Las pruebas de conexión envían texto sintético y se contabilizan dentro del límite de solicitudes. Cada solicitud utiliza la ruta externa configurada del espacio de trabajo. Una ruta bloqueada o un MTProxy exclusivo para Telegram constituye un error; no hay reintento directo. Una dirección Ollama local configurada deliberadamente permite un destino privado. Un punto final de IA de bucle cerrado requiere la ruta externa «Direct» del espacio de trabajo; las rutas de proxy se rechazan antes de la transmisión. Para otros servicios privados se aplica la opción de activación de destino privado a nivel de servidor ya existente. La vista previa muestra el punto final y la ruta externa, incluido el host del proxy cuando corresponda. Cambiar esa ruta requiere una nueva vista previa. Antes de la generación, **los datos enviados al modelo** muestran la solicitud: pregunta, fragmentos seleccionados, tipos de eventos, horas de observación y marcadores de cobertura. Las sesiones de Telegram, los campos sin procesar, las claves de los proveedores, los bytes de los archivos adjuntos y el registro completo no forman parte de ese contexto. Desmarca las fuentes no deseadas y, a continuación, aprueba explícitamente el procesamiento. Los proveedores externos pueden conservar el contenido enviado según sus propias políticas. La ejecución local significa que el punto final es local; no es una garantía sobre el comportamiento de un servicio configurado de forma independiente. Hay un máximo de dos solicitudes simultáneas al proveedor a nivel global y una por espacio de trabajo. Una vista previa caduca a los diez minutos y puede generar una respuesta. Se muestran los recuentos de tokens comunicados por el proveedor; solo aparece una estimación de costes cuando se han configurado tanto las tarifas de entrada como las de salida. Los intentos fallidos también consumen el presupuesto diario de solicitudes. Los reintentos automáticos no consumen presupuesto adicional. ## Fuentes y limitaciones La recuperación utiliza el [índice de texto completo](https://phishdestroy.github.io/TgWitness/es/docs/reference/search/#ask-the-archive-and-mcp) cuando está completo: las mejores coincidencias en los chats seleccionados, incluyendo variantes léxicas. Las consultas sobre cambios recientes o las versiones de un mensaje, así como las búsquedas mientras se está creando el índice, utilizan una búsqueda léxica limitada a los registros más recientes. La vista previa indica el método. La recuperación devuelve hasta 24 fuentes; los textos largos se recortan en torno a la coincidencia. Los extractos truncados y los conjuntos de resultados incompletos se marcan. El periodo se refiere al **tiempo de observación**, no a una afirmación de que el historial de Telegram sea completo. Los eventos con cobertura en todo el espacio de trabajo quedan excluidos del acceso limitado al chat. Los datos que faltan se describen como «no encontrados» en el archivo disponible. El modelo no recibe herramientas. Sus identificadores de origen se cotejan con los registros seleccionados, se vuelven a comprobar los hash y las cadenas entre comillas deben aparecer en dichos registros. Los identificadores desconocidos, las citas modificadas y las afirmaciones sin citar dan lugar al rechazo de la respuesta. La aplicación crea enlaces; las URL generadas por el modelo no se utilizan como citas. Estas comprobaciones establecen la existencia de la fuente y la exactitud de la cita, no la veracidad de una inferencia. Revisa las inferencias contrastándolas con los registros antes de dar por ciertas. ## Informes Guarda una respuesta revisada como un informe analítico independiente. Incluye el resumen del modelo, la cronología observada, los enlaces y los identificadores extraídos, los registros de edición y eliminación, los límites de cobertura y los hash de los eventos de origen. Se incluyen el proveedor, el modelo, el punto final, la hora y la versión de la plantilla de prompt. No se fusionan automáticamente las identidades. Las revisiones y notas de los analistas se almacenan por separado del resumen del modelo. Los informes se guardan en archivos derivados cifrados, con un índice fuera del flujo de eventos firmado; los eventos y archivos multimedia originales no se modifican. Solo el propietario o el administrador pueden abrir un informe, y se vuelve a comprobar el acceso a la fuente. La descarga también requiere permiso de exportación . La versión 1 no firma los informes ni da a entender que las conclusiones del modelo sean pruebas verificadas. Límites: 100 informes por espacio de trabajo y 100 revisiones de analistas por informe. Para el OCR manual y las transcripciones, consulta [«procesamiento de archivos multimedia](https://phishdestroy.github.io/TgWitness/es/docs/reference/media-analysis/)». Para el acceso de clientes, consulta [«MCP](https://phishdestroy.github.io/TgWitness/es/docs/reference/mcp/)». --- # Telegram · Búsqueda de texto completo Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reference/search/ Busca mensajes guardados por formas de palabras, frases exactas, dominios y @nombres de usuario, mostrando primero los resultados más relevantes, con el índice vinculado al diario firmado. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Busca mensajes guardados por formas de palabras, frases exactas, dominios y @nombres de usuario, mostrando primero los resultados más relevantes, con el índice vinculado al diario firmado. [TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [Documentación](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) · [Investigación](https://phishdestroy.github.io/TgWitness/es/docs/reference/investigation/) ![Investigación](https://phishdestroy.github.io/TgWitness/assets/chapter-investigate.svg) [Análisis de archivos](https://phishdestroy.github.io/TgWitness/es/docs/reference/analysis/) · [OCR y transcripción locales](https://phishdestroy.github.io/TgWitness/es/docs/reference/media-analysis/) · [Wiki](https://github.com/phishdestroy/TgWitness/blob/main/docs/wiki/Archive-and-Integrations.md) **Vista previa.** En **«Diario»**, selecciona **«Mejor coincidencia · formas de la palabra»** junto al campo de búsqueda. Los resultados se ordenan mediante BM25 y coinciden con otras formas de la misma palabra: *«перевод»* encuentra *«переводом»* y *«переводы»*, *«transfer»* encuentra *«transfers»*, y una frase en chino se encuentra sin espacios. La opción **«Lo más reciente primero · texto exacto»** mantiene la búsqueda de subcadenas anterior en todo el registro. El índice es un dato derivado. Se reconstruye a partir del diario firmado, nunca está firmado en sí mismo y nunca se incluye en una exportación. Los registros originales no se modifican. **En esta página** - [Sintaxis de búsqueda](https://phishdestroy.github.io/TgWitness/es/docs/reference/search/#search-syntax) - [Idiomas](https://phishdestroy.github.io/TgWitness/es/docs/reference/search/#languages) - [Dónde se encuentra el índice](https://phishdestroy.github.io/TgWitness/es/docs/reference/search/#where-the-index-lives) - [Resultados y el diario firmado](https://phishdestroy.github.io/TgWitness/es/docs/reference/search/#results-and-the-signed-journal) - [Texto reconocido](https://phishdestroy.github.io/TgWitness/es/docs/reference/search/#recognized-text) - [Acceso](https://phishdestroy.github.io/TgWitness/es/docs/reference/search/#access) - [Consultar el archivo y MCP](https://phishdestroy.github.io/TgWitness/es/docs/reference/search/#ask-the-archive-and-mcp) - [Dependencias](https://phishdestroy.github.io/TgWitness/es/docs/reference/search/#dependencies) - [Prueba de rendimiento](https://phishdestroy.github.io/TgWitness/es/docs/reference/search/#benchmark) ## Sintaxis de búsqueda | Redactar | Resultados | | --- | --- | | `перевод карта` | Registros que contengan ambas palabras, en cualquier forma | | `"переводом на карту"` | La frase exacta, en este orden | | `бонус OR подарок` | Cualquiera de las dos palabras | | `перевод -казино` | Registros sin la palabra excluida | | `example.com` | El dominio y sus subdominios, incluso en enlaces ocultos y en las URL de los botones. | | `@username`, `t.me/username` | Menciones y enlaces de la cuenta, así como los mensajes que envió. | | `#tag` | El hashtag | | `+79991234567`, una dirección de monedero, una dirección de correo electrónico | El mismo valor en texto o enlaces | | `from:@username`, `from:123456` | Mensajes de ese remitente | | `chat:-1001234567890` | Un chat; solo puede restringir tu propio acceso | | `id:42` | Versiones guardadas del mensaje 42 | | `since:2026-01-01 until:2026-01-31` | Período de observación: una fecha sin hora abarca todo el día. | | `kind:edited` | Solo se permiten modificaciones (`new`, `snapshot`, `edited`, `recovered`) | | `source:ocr`, `source:transcription`, `source:all` | Texto reconocido en lugar de, o junto con, los mensajes | Las preposiciones y otras palabras funcionales se ignoran cuando hay otras palabras presentes. Las letras similares mezcladas en una palabra (una *«a»* latina dentro de una palabra cirílica), las letras Unicode de ancho completo y decorativas, así como los caracteres invisibles, se normalizan. ## Idiomas El idioma se detecta en cada registro a partir de su escritura y sus letras: | Script | Coincidencia | | --- | --- | | Cirílico | Lemas rusos y ucranianos con [pymorphy3](https://github.com/no-plagiarism/pymorphy3). Sin el diccionario ucraniano opcional, se utiliza un analizador morfológico ucraniano ligero. | | Latín | Stemmer «Snowball» en inglés; se ignoran los signos diacríticos | | Chino, japonés, coreano, tailandés, laosiano, jemer y birmano | Pares de caracteres superpuestos: se busca cualquier frase sin espacios. Las consultas en chino se dividen en palabras con Jieba. | | Otros scripts | Palabras exactas | El diccionario ucraniano (`pymorphy3-dicts-uk`) se distribuye bajo la licencia GPL-3.0, por lo que no viene instalado por defecto. Instálalo con `pip install "tgwitness[uk-dictionary]"`; el índice detecta el nuevo analizador y se reconstruye automáticamente. ## Dónde se encuentra el índice | Modo | Almacenamiento | Uso | | --- | --- | --- | | En disco (predeterminado) | `search/fulltext.sqlite3` en el directorio del espacio de trabajo | Archivos de gran tamaño; resiste los reinicios. | | Solo en memoria | No se guarda nada en el disco; se recrea en cada inicio. | No se guarda ninguna copia derivada del texto de los mensajes en el disco. | | Desactivado | Sin índice; **primero lo más reciente ·** se mantiene **el texto exacto** | Instalaciones mínimas | El administrador principal elige el modo en **Diario → Filtros → Índice de búsqueda** para cada espacio de trabajo. `TGWITNESS_FULLTEXT=disk|memory|off` Establece el valor por defecto para los espacios de trabajo que no tengan una opción propia. Al cambiar a «memoria» o desactivarlo, se elimina el archivo. El archivo de índice tiene la misma protección que el registro: se encuentra en el directorio de datos privados . No está cifrado y no forma parte de las copias de seguridad ni de las copias externas. Los nuevos registros se indexan en segundo plano en cuestión de segundos; además, al realizar una búsqueda se indexa primero un pequeño historial acumulado, por lo que se encuentra un registro guardado hace un momento. Un diario existente se indexa tras la actualización sin bloquear el panel; hasta entonces, los resultados abarcan los registros indexados y el diario muestra el progreso. **La reconstrucción del índice** comienza de nuevo desde el primer registro. ``` python -m tgwitness index status --data-dir data/live python -m tgwitness index rebuild --data-dir data/live --json ``` `rebuild` Es necesario detener el panel (de lo contrario, código de salida 3). Con `--json`, la salida estándar solo muestra el resultado; el progreso se envía a la salida de error estándar. ## Resultados y el diario firmado El índice almacena el número de secuencia y el hash del último registro del diario que abarca y los compara con el diario cuando se abre. Un diario sustituido, restaurado o editado provoca una reconstrucción. Cada respuesta informa de esta posición, y cada resultado se lee desde el diario firmado mediante su número de secuencia: el índice decide qué registros mostrar y en qué orden, pero nunca su contenido. El acceso al chat se aplica al propio campo de chat del diario, no al contenido del índice. ## Texto reconocido El OCR y las transcripciones permanecen en sus artefactos cifrados. Su índice existe únicamente en memoria y se reconstruye cuando finaliza un trabajo de reconocimiento. Aparece una coincidencia en su `media.saved` registro, etiquetado como «reconocimiento automático» con el motor, el modelo y un extracto; nunca se presenta como texto enviado en Telegram. El mismo índice sirve para **la búsqueda de texto reconocido**, que además sigue coincidiendo con subcadenas sin formato. ## Acceso El acceso limitado al chat solo encuentra registros de sus chats, incluido el texto reconocido de sus archivos adjuntos. `chat:` y otros filtros solo pueden restringir ese conjunto. El estado del índice que se muestra al acceso limitado omite los totales del diario. Solo el administrador principal puede cambiar el modo o reconstruir el índice. ## Consulta el archivo y el MCP Cuando **el archivo** esté completo, **la consulta** recuperará sus fuentes a partir de este índice: las mejores coincidencias en los chats seleccionados, contando cada texto guardado una sola vez. Se envían hasta 24 fuentes; los textos largos se recortan en torno a su coincidencia y se marcan como truncados. Las consultas sobre cambios recientes, versiones guardadas de un mensaje y búsquedas mientras el índice aún se está creando utilizan la recuperación cronológica anterior. La vista previa muestra qué método se ha utilizado. Los clientes de MCP pueden llamar a `search_messages` con `ranked=true` y enviar mensajes con `next_offset`. Las conexiones con ámbito limitado solo reciben sus propios chats. La paginación ordenada abarca, como máximo, los primeros resultados de 1,000, independientemente del tamaño de la página. Limita la consulta, el chat o el periodo para examinar más coincidencias. Las búsquedas más recientes primero ordenan los mensajes, los resultados de OCR y de transcripción antes de seleccionar cada página. ## Dependencias | Paquete | Licencia | ¿Por qué? | | --- | --- | --- | | pymorphy3, pymorphy3-dicts-ru, DAWG2-Python | MIT | Lemas en ruso y ucraniano; los diccionarios se cargan localmente. | | snowballstemmer | BSD-3-Cláusula | Raíces en inglés, Python puro | | jieba | MIT | Segmentación de consultas en chino, Python puro (solo distribución del código fuente) | | pymorphy3-dicts-uk (opcional) | GPL-3.0 | Diccionario completo de ucraniano | Se requiere SQLite FTS5 con el `unicode61` tokenizador; forma parte de SQLite en las compilaciones actuales de Python. Sin él, la búsqueda de la mejor coincidencia indica que no está disponible. ## Prueba de rendimiento `python tools/bench_fulltext.py --messages 1000000 --work `Crea un registro firmado y determinista de mensajes mixtos en ruso, ucraniano, inglés, chino y japonés con enlaces e identificadores en 200 chats, genera el índice y mide la duración de búsquedas típicas (50 resultados, mediana de 7 ejecuciones). Medido en Windows 11, Intel Core i9-13900K, 128 GB de RAM, Python 3.12.10, SQLite 3.49.1, datos en una unidad exFAT, analizador `fulltext-v1+pymorphy3-ru+light-uk+snowball-en`: | Medida | Resultado | | --- | --- | | Registro firmado | 1 000 000 de mensajes, 1,50 GiB, escritos en 19 minutos | | Creación de un índice a partir del registro | 71 s, unos 14 141 mensajes por segundo | | Archivo de índice | 58 MiB, el 3,8 % del diario | | Buscar justo después de un nuevo registro | Mediana de 8 ms, p95 de 9 ms | | Búsqueda de subcadenas anterior, mismo diario | `перевод` 3,2 s, `银行转账` 2,6 s, `verify-account.example` 2,6 s | | Buscar | Registros coincidentes | Mejor coincidencia, mediana | pág. 95 | Más recientes primero, mediana | | --- | --- | --- | --- | --- | | Palabras comunes y sus formas: `перевод` | 134,403 | 82 ms | 85 ms | 7 ms | | Dos palabras: `оплата карта` | 28,996 | 43 ms | 43 ms | 14 ms | | Palabra poco común: `розыгрыш подарок` | 28,881 | 42 ms | 47 ms | 13 ms | | Frase exacta: `"переказ коштів на картку"` | no se tiene en cuenta | 35 ms | 36 ms | 6 ms | | Dominio con subdominios: `verify-account.example` | 12,435 | 17 ms | 17 ms | 3 ms | | @nombredeusuario: `@support_desk_bot` | 10,331 | 15 ms | 16 ms | 3 ms | | Chino sin espacios: `银行转账` | 17,691 | 23 ms | 24 ms | 3 ms | | Japonés: `リンク` | 16,603 | 23 ms | 25 ms | 3 ms | | Raíz en inglés: `withdrawal` | 27,775 | 26 ms | 26 ms | 2 ms | | O y exclusión: `бонус OR подарок -казино` | 268,034 | 190 ms | 193 ms | 19 ms | | Filtro de chat: `chat:-1000000000007 перевод` | 652 | 9 ms | 9 ms | 6 ms | | Filtro de periodo: `since:2026-01-01 until:2026-01-31 выплата` | 115,732 | 155 ms | 156 ms | 81 ms | Una frase exacta se compara literalmente con los candidatos en orden de relevancia hasta que la página se llena, por lo que su total no se tiene en cuenta. Los tiempos aumentan con el número de registros coincidentes; restringir el chat o el periodo agiliza las búsquedas amplias. El corpus sintético repite un vocabulario reducido, por lo que las palabras comunes coinciden con muchos más registros que en los chats reales. --- # Telegram · MCP de solo lectura Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reference/mcp/ Conecta un cliente MCP a espacios de trabajo y chats seleccionados con acceso temporal y revocable. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Conecta un cliente MCP a espacios de trabajo y chats seleccionados con acceso temporal y revocable. [TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [Documentación](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) · [Integraciones con archivos](https://phishdestroy.github.io/TgWitness/es/docs/reference/cli/) ![Integraciones con archivos](https://phishdestroy.github.io/TgWitness/assets/chapter-integrations.svg) Conecta un cliente de análisis a los espacios de trabajo y chats seleccionados. TgWitness sirve **Streamable HTTP en `/mcp` en el proceso del panel**. Cada conexión tiene su propio token, fecha de caducidad y herramientas permitidas. MCP no puede enviar mensajes de Telegram, cambiar la configuración ni modificar el registro firmado. Las mismas conexiones funcionan con la [línea de comandos](https://phishdestroy.github.io/TgWitness/es/docs/reference/cli/). [Guía de flujo de trabajo](https://phishdestroy.github.io/TgWitness/docs/archive/) · [Wiki](https://github.com/phishdestroy/TgWitness/blob/main/docs/wiki/Archive-and-Integrations.md) **En esta página** - [Instalación y comprobación](https://phishdestroy.github.io/TgWitness/es/docs/reference/mcp/#install-and-check) - [Establecer una conexión](https://phishdestroy.github.io/TgWitness/es/docs/reference/mcp/#issue-a-connection) - [Conecta tu cliente](https://phishdestroy.github.io/TgWitness/es/docs/reference/mcp/#connect-your-client) - [Túnel de Cloudflare](https://phishdestroy.github.io/TgWitness/es/docs/reference/mcp/#cloudflare-tunnel) - [Herramientas y límites](https://phishdestroy.github.io/TgWitness/es/docs/reference/mcp/#tools-and-boundaries) ## Instalar y comprobar Use el entorno de Python que ejecuta el panel. Desde una descarga del código fuente: ``` # Windows PowerShell & .\.venv\Scripts\python.exe -m pip install -c deploy/constraints-mcp.txt -e '.[mcp]' & .\.venv\Scripts\python.exe start.py --check ``` ``` # Linux / macOS .venv/bin/python -m pip install -c deploy/constraints-mcp.txt -e '.[mcp]' .venv/bin/python start.py --check ``` Reinicie el panel con su directorio de datos habitual y sus argumentos de inicio después de la instalación. La comprobación de disponibilidad debe incluir `[PASS] mcp: streamable-http available`. **Integrations → MCP** muestra el estado del entorno de ejecución y un comando de instalación que utiliza el ejecutable real de Python de ese servidor. **Re-check** actualiza este estado sin recargar la página; no instala paquetes ni reinicia el servidor. El complemento MCP utiliza el [SDK oficial de Python de MCP](https://github.com/modelcontextprotocol/python-sdk).`deploy/constraints-mcp.txt` fija la versión del SDK y las dependencias probadas. ## Emitir una conexión 1. Introduzca una etiqueta y elija los espacios de trabajo y los chats que el cliente puede leer. 2. Seleccione las herramientas individualmente o utilice un ajuste preestablecido. Solo se ofrecen las herramientas implementadas. 3. Elija 1, 7, 30 o 90 días, o un vencimiento personalizado de entre un minuto y 90 días. 4. Pulse **Create connection**. El token aparece una sola vez junto a la configuración del cliente. 5. Copie el token y la configuración y, a continuación, ejecute **Check connection**. Esto inicializa MCP y enumera las herramientas permitidas; **no se lee ningún mensaje**. El resultado muestra la versión del protocolo, los nombres de las herramientas, el recuento y el tiempo transcurrido. 6. Pulse **Done** cuando haya guardado la credencial. El sondeo conserva el formulario y la tarjeta que se muestra una sola vez. Al bloquear el panel se borran los secretos mostrados. La lista muestra el uso reciente, la última herramienta, la dirección y las solicitudes en el último minuto. **Revoke** finaliza el acceso. **Rotate token** revoca la credencial antigua y emite un reemplazo con el mismo alcance, herramientas y vencimiento; copie el reemplazo una vez. Los tokens de inicio de sesión del panel y las credenciales de Telegram no funcionan como tokens de MCP. ## Conectar su cliente Seleccione el cliente en el panel y copie su configuración generada. Las configuraciones utilizan referencias a secretos o marcadores de posición explícitos; el token se copia por separado. | Cliente | Configuración | Conexión | | --- | --- | --- | | Código de Claude | `.mcp.json` | HTTP, `type: "http"`, encabezado bearer | | Claude Desktop | `claude_desktop_config.json` | Puente stdio local | | Cursor | `.cursor/mcp.json` | HTTP con un encabezado de variable de entorno | | VS Code Local | `.vscode/mcp.json` | HTTP con una entrada `promptString` de contraseña | | Windsurf | `mcp_config.json` | HTTP con un marcador de posición de encabezado bearer | | Otros clientes | URL y encabezado Authorization | HTTP transmitible | TgWitness utiliza tokens bearer, sin descubrimiento OAuth. Utilice el puente stdio local para clientes cuyo conector remoto requiera OAuth. Para VS Code, las variables de entrada se aplican al entorno **Local** y no se reenvían a las sesiones de Copilot. Referencias de configuración: [Claude Code](https://code.claude.com/docs/en/mcp), [Cursor](https://prod.cursor.com/docs/mcp), [VS Code](https://code.visualstudio.com/docs/agents/reference/mcp-configuration). El punto de entrada canónico para un puente local es: ``` python -m tgwitness.mcp_server --url https://your-panel.example/mcp ``` Utilice el Python local del cliente con el extra de MCP instalado. Establezca `TGWITNESS_MCP_TOKEN` en su entorno protegido. Mantenga las credenciales fuera de los argumentos de comandos y las URL. `tgwitness-mcp` es el mismo punto de entrada. El antiguo módulo `tgwitness.mcp_bridge` y el nombre `TGWITNESS_ARCHIVE_TOKEN` se mantienen como rutas de compatibilidad con una advertencia; las nuevas configuraciones utilizan `mcp_server` y `TGWITNESS_MCP_TOKEN`. ## Cloudflare Tunnel Reenvíe la ruta `/mcp` del panel y conserve el encabezado bearer. Al abrir la configuración de MCP como administrador se registra el origen actual del panel para esta ejecución. Para obtener una dirección estable disponible inmediatamente después del reinicio, configure `TGWITNESS_PUBLIC_URL` con el origen HTTPS del panel antes de iniciarlo. Los encabezados Host y de reenvío arbitrarios no registran una dirección de confianza. Las comprobaciones de Host y Origin rechazan orígenes de navegador no relacionados. Las respuestas utilizan `Cache-Control: no-store`; los valores de autorización nunca se registran. Una dirección `*.trycloudflare.com` es temporal. Cuando el reinicio de un túnel cambie el nombre de host, actualice la URL pública configurada y la URL de MCP de cada cliente. Utilice un nombre de host estable para las configuraciones de cliente guardadas. ## Herramientas y límites | Herramienta | Lee | | --- | --- | | `list_workspaces` | Espacios de trabajo concedidos | | `list_chats` | Chats concedidos | | `search_messages` | Texto de los mensajes guardados dentro del periodo seleccionado; `ranked=true` utiliza [búsqueda de texto completo](https://phishdestroy.github.io/TgWitness/es/docs/reference/search/) (formas de palabras, mejores coincidencias primero, `next_offset` paginación) | | `get_message_versions` | Versiones capturadas y observaciones de eliminación | | `get_message_context` | ID de mensajes capturados cercanos | | `get_journal_event` | Un registro saneado con su referencia de origen | | `get_capture_status` | Estado de la recopilación, registros de cobertura permitidos y `gap_summary`: números de mensajes nunca observados, por canal o supergrupo y para la secuencia de toda la cuenta ([detalles](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#missing-message-numbers-gap_summary)); elige un chat para ver su lista de lagunas | | `get_activity_stats` | Mensajes por hora UTC y día de la semana, días de mayor actividad, porcentajes de edición y eliminación, remitentes, dominios y `@handles`, con cobertura ([detalles](https://phishdestroy.github.io/TgWitness/es/docs/reference/cli/#activity-statistics)) | | `get_messages_by_date` | Mensajes guardados de un día natural en una zona horaria IANA especificada (`Europe/Kyiv`, `UTC`), según la hora indicada por Telegram; `from_utc` y `until_utc` indicar el día calculado, incluido el horario de verano | | `get_pinned_messages` | Mensajes fijados en la última instantánea del estado del chat con sus versiones guardadas, y los avisos de fijación y desfijación observados en tiempo real. | | `get_chat_stats` | Recuento básico de registros guardados para un chat o para todos los chats incluidos en el ámbito, primera y última observación, y `gap_summary`; utilízalo antes de realizar una lectura de gran volumen | | `get_topics` | Temas del foro a partir de los mensajes del servicio de temas guardados: historial de títulos, temas cerrados u ocultos, recuento de mensajes guardados | | `get_media` | Una imagen conservada como vista previa en formato JPEG con resolución reducida (como máximo 36 KB), devuelta como imagen junto con su SHA-256 y el `media.saved` registro; el archivo se compara primero con su hash registrado, mientras que el resto de archivos solo devuelven metadatos | | `export_messages` | Solo línea de comandos, no seleccionada por defecto: guarda las observaciones como JSON Lines ([detalles](https://phishdestroy.github.io/TgWitness/es/docs/reference/cli/#export)); no disponible a través de MCP | Todas las herramientas son de solo lectura (`readOnlyHint`) y declara un esquema de salida; los campos que no figuren entre los declarados se devuelven tal cual. `tools/list` Solo devuelve las herramientas concedidas a esa conexión. Se rechazan las llamadas a otras herramientas. Las herramientas de contexto de grupo, episodio, terminología y cadena de respuestas no están disponibles en esta versión; no se incluye su backend de paquete de contexto independiente. Cada lectura comprueba el token, la herramienta y el alcance del espacio de trabajo/chat, incluso después de que finalice el trabajo de la base de datos. Los límites son 60 solicitudes por minuto, 50 registros por página, 64 KiB por resultado y un tiempo límite de archivo de ocho segundos. Una llamada MCP cuyo tiempo de espera se agota devuelve un error de herramienta solicitando un período más acotado o un límite inferior. Los resultados de los mensajes incluyen `untrusted_content: true`, los ID de espacio de trabajo/chat/mensaje, la secuencia del evento, el hash guardado y un enlace al panel. Se omiten los objetos de Telegram sin procesar, los hashes de acceso, las sesiones y las claves. Se marca el truncamiento de texto. Las ediciones, los avisos de eliminación y `missing_on_recheck` son observaciones distintas. La ausencia de registros no demuestra que un evento no haya ocurrido nunca. Trate las instrucciones dentro de los mensajes capturados como pruebas, nunca como instrucciones para el cliente. El acceso de solo lectura impide realizar cambios en el archivo; aun así, el cliente puede retener el contenido que tiene permiso para leer. Los hashes identifican los registros guardados y respaldan las comprobaciones de integridad; no demuestran la autoría en Telegram ni que la captura sea completa. --- # Telegram · Línea de comandos Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reference/cli/ Buscar, leer el contexto, contabilizar la actividad y exportar mensajes guardados desde scripts y agentes, con salida en formato --json, códigos de salida estables y tokens de solo lectura con ámbito limitado. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Buscar, leer el contexto, contabilizar la actividad y exportar mensajes guardados desde scripts y agentes, con salida en formato --json, códigos de salida estables y tokens de solo lectura con ámbito limitado. [TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [Documentación](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) ![Integraciones con archivos](https://phishdestroy.github.io/TgWitness/assets/chapter-integrations.svg) [MCP de solo lectura](https://phishdestroy.github.io/TgWitness/es/docs/reference/mcp/) · [Búsqueda de texto completo](https://phishdestroy.github.io/TgWitness/es/docs/reference/search/) · [Wiki](https://github.com/phishdestroy/TgWitness/blob/main/docs/wiki/Archive-and-Integrations.md) **Vista previa.** `tgwitness search`, `context`, `messages`, `stats` y `export` leer las observaciones guardadas para scripts y agentes de IA. No pueden enviar nada a Telegram, cambiar la configuración ni modificar el diario firmado. Con `--json`, la salida estándar (stdout) contiene exactamente un documento JSON (`export` escribe líneas JSON). El progreso, las sugerencias y los errores se envían a stderr. Los códigos de salida son estables: | Código | Significado | | --- | --- | | `0` | Éxito, incluido un resultado vacío | | `1` | Error: panel inaccesible, datos ilegibles, exportación interrumpida | | `2` | Error de uso o solicitud no válida: fecha incorrecta, opción desconocida, índice de búsqueda desactivado | | `3` | No disponible en este momento: el espacio de trabajo está abierto en un panel en ejecución, o el panel solicita que se vuelva a intentar más tarde (límite de frecuencia, tiempo de espera agotado). | | `4` | Acceso denegado: token ausente, caducado o revocado; un chat fuera de su ámbito de aplicación; una herramienta que no lo permite. | ## Dos formas de leerlo **A través del panel (`--url`).** El comando utiliza la misma API de archivo con ámbito que MCP. Crea una conexión en **Integraciones → MCP**: elige espacios de trabajo y chats, herramientas y una fecha de caducidad; a continuación, copia el token una vez. La conexión es de solo lectura, está limitada a esos chats, tiene un límite de 60 solicitudes por minuto y puede revocarse o rotarse en cualquier momento. Los tokens de inicio de sesión del panel y las credenciales de Telegram no funcionan aquí. ``` export TGWITNESS_URL=https://panel.example.org # default http://127.0.0.1:8787 export TGWITNESS_MCP_TOKEN=tgw_mcp_... # or --token-file path tgwitness search 'перевод карта' --json ``` Un panel remoto requiere HTTPS; el HTTP sin cifrar solo se acepta para `127.0.0.1`, `localhost` y `::1`. Se ignoran las variables de entorno de proxy y se rechazan las redirecciones, por lo que el token solo llega a la dirección que indiques. **Directamente desde un espacio de trabajo detenido (`--data-dir`).** Lee el directorio de datos con acceso local completo, sin necesidad de un token. Úsalo en una copia del directorio de datos o mientras la recopilación esté detenida. Los registros firmados nunca se modifican; al igual que en el panel, al abrir un espacio de trabajo es posible que se actualicen sus índices derivados. Cuando el panel tiene el espacio de trabajo abierto, el comando finaliza con código `3`; léalo a través del panel. Si no `--data-dir`, `TGWITNESS_DATA`, `./data/live` se utiliza el directorio de datos de la instalación en la que se ejecuta el comando. `--workspace ID` selecciona un espacio de trabajo (por defecto `default`). `tgwitness messages --workspaces` muestra los que puedes leer. ## Comandos | Comando | Resultado | | --- | --- | | `tgwitness search QUERY [--chat ID] [--since] [--until] [--any] [--limit N] [--offset N]` | Se mostrarán primero los resultados más relevantes, incluyendo variantes de palabras, frases exactas entre comillas, dominios y `@username` ([sintaxis](https://phishdestroy.github.io/TgWitness/es/docs/reference/search/#search-syntax)) | | `tgwitness search QUERY --exact [--before SEQ]` | Texto exacto, de más reciente a más antiguo, sin el índice | | `tgwitness context CHAT_ID MESSAGE_ID` | Mensajes guardados dentro de un margen de diez ID de mensaje a cada lado | | `tgwitness messages` | Chats que puedes leer | | `tgwitness messages CHAT_ID [--since] [--until] [--before SEQ]` | Mensajes guardados del chat, ordenados de más reciente a más antiguo | | `tgwitness messages CHAT_ID --message ID` | Cada versión guardada y cada registro de eliminación de un mensaje | | `tgwitness stats [--chat ID] [--sender ID] [--since] [--until] [--top N]` | Estadísticas de actividad, a continuación | | `tgwitness export [--chat ID] [--since] [--until] [--output FILE]` | Observaciones guardadas como líneas JSON en orden de registro. | Las fechas son `2026-10-01` (medianoche UTC) o en formato ISO con la zona horaria, `2026-10-01T09:00+03:00`. Para `search`, `messages` y `export` se selecciona la hora de la observación. Las páginas admiten hasta 50 registros: sigue `next_offset` (`--offset`) para la búsqueda por orden de relevancia y `next_before` (`--before`) en otros lugares. La búsqueda por relevancia se detiene en 1,000 resultados. La última página puede ser más corta que `--limit`; limita la consulta, el chat o el periodo cuando existan más observaciones coincidentes. Cada resultado de mensaje incluye `untrusted_content: true`los ID del espacio de trabajo, del chat y del mensaje, la secuencia del registro, el hash del registro guardado y un enlace al panel. Las modificaciones, los avisos de eliminación y `missing_on_recheck` son registros independientes. La ausencia de un registro no demuestra que un evento no haya ocurrido nunca. ### Estadísticas de actividad `stats` Cuenta las observaciones guardadas para un chat, un remitente o todos los chats incluidos en el ámbito de aplicación: - mensajes por hora UTC y por día de la semana (empezando por el lunes), horas y días de mayor actividad; - editados, eliminados y `missing_on_recheck` compartidos; - remitentes con el recuento de mensajes y las horas del primer y último mensaje; - los dominios más frecuentes y `@handles`, contados una vez por mensaje en todas sus versiones guardadas; - Cobertura: `coverage.gap` registros y, para acceder a todo el espacio de trabajo, períodos sin señal de vida del colector conectado (`collector_liveness`). El periodo selecciona **la hora del mensaje indicada por Telegram**. El recuento de horas y días de la semana puede ayudar a estimar la zona horaria del remitente, pero no la determina. Las cifras se calculan a petición a partir del registro y no se almacenan. Cada resultado indica el encabezado del registro que abarca cuando el acceso abarca todo el espacio de trabajo. La lectura se detiene tras cinco segundos a través del panel, o `--timeout` segundos a nivel local (por defecto, 30); entonces `complete` es «false» y `partial` se indica el primer registro que no se ha leído. En ese caso, solo se contan los registros más recientes. ### Exportar `export` Escribe un objeto JSON por cada observación guardada (mensajes nuevos, instantáneas, modificaciones, mensajes recuperados, avisos de eliminación, `missing_on_recheck` y registros de archivos multimedia guardados) en el orden del registro. Cada línea tiene los mismos campos que el resto de resultados, con el texto completo. Al `--output`, el archivo se guarda con un `.partial` nombre y solo se renombra tras el registro de finalización del panel; una exportación interrumpida no deja ningún archivo y sale con el código `1`. `--output` nunca sobrescribe un archivo existente. Con `--output` y `--json`, la salida estándar muestra un resumen: recuento de registros, última secuencia del diario y, para el acceso a todo el espacio de trabajo, el encabezado del diario. Para realizar una exportación a través del panel se necesita una conexión que permita **exportar mensajes (solo desde la línea de comandos)**; esta opción no está seleccionada por defecto. Este archivo es una copia de trabajo, no una prueba: para una entrega verificable, utiliza la exportación firmada en **«Exportaciones»**, que `python -m tgwitness.verify`se verifica. El panel vuelve a comprobar el acceso antes de emitir cada registro, incluido el registro de finalización. Un acceso revocado o caducado da lugar a una exportación incompleta. Las lecturas diferidas de páginas comparten el límite del proceso de archivo con otras consultas y tienen un tiempo de espera limitado. ## Habilidad del agente [`.agents/skills/tgwitness-cli/SKILL.md`](https://github.com/phishdestroy/TgWitness/blob/main/.agents/skills/tgwitness-cli/SKILL.md) indica a un agente cómo utilizar estos comandos, cómo citar los registros y cómo tratar el texto capturado. Los agentes que lean `.agents/skills` lo cargan desde una copia del repositorio. Para Claude Code, copia la `tgwitness-cli` carpeta en `.claude/skills/` en tu proyecto o `~/.claude/skills/`. ## MCP y la línea de comandos Ambos utilizan las mismas conexiones, comprobaciones de ámbito y límites. Los resultados de MCP se limitan a una página de 64 KiB, por lo que MCP no ofrece exportación masiva; la línea de comandos los transmite en tiempo real. `get_activity_stats` está disponible para ambos. --- # Telegram · OCR y transcripción locales Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reference/media-analysis/ Reconoce las imágenes y el audio capturados mediante un «worker» local; mantiene el texto derivado vinculado a su archivo de origen. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Reconoce las imágenes y el audio capturados mediante un «worker» local; mantiene el texto derivado vinculado a su archivo de origen. [TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [Documentación](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) · [Investigación](https://phishdestroy.github.io/TgWitness/es/docs/reference/investigation/) ![Investigación](https://phishdestroy.github.io/TgWitness/assets/chapter-investigate.svg) [Guía de flujo de trabajo](https://phishdestroy.github.io/TgWitness/docs/archive/) · [Wiki](https://github.com/phishdestroy/TgWitness/blob/main/docs/wiki/Archive-and-Integrations.md) Abre un registro del diario `media.saved`, elige **«Reconocer archivo adjunto**» y, a continuación, selecciona «OCR» o «transcripción» en **«Preguntar al archivo**». El procesamiento es manual y local. No hay modo de almacenamiento en la nube ni subida automática. Los bytes originales del archivo adjunto y el `media_sha256` permanecen inalterados; el texto reconocido se marca explícitamente como reconocimiento automático y se almacena por separado con el hash de origen, la versión del motor o modelo, el idioma, los parámetros y la hora de finalización. Las transcripciones conservan las marcas de tiempo devueltas. Busca entre estos resultados utilizando **la opción «Buscar texto reconocido»** y el filtro «OCR/transcripción», o selecciona el texto reconocido como fuente de una búsqueda de «mejor coincidencia» **en el diario**. Ambas opciones comparan formas de palabras a través de un [índice en memoria](https://phishdestroy.github.io/TgWitness/es/docs/reference/search/#recognized-text). Se trata de una búsqueda independiente basada en datos derivados; no convierte automáticamente el reconocimiento automático en texto original de Telegram ni lo añade a los eventos firmados. ## Configurar el «worker» opcional La versión 1 requiere un servidor Linux con un daemon de Docker local. Las instalaciones en Windows pueden ejecutar TgWitness dentro de un entorno de máquina virtual Linux o WSL con su propio daemon local. El panel nunca descodifica por sí mismo un archivo adjunto no fiable. ``` docker build -f deploy/media-worker/Dockerfile -t tgwitness-media:local . export TGWITNESS_MEDIA_IMAGE=tgwitness-media:local ``` Configura estas variables en el entorno del servicio TgWitness y reinícialo. El socket del daemon viene por defecto en `/var/run/docker.sock`; en las implementaciones sin privilegios de root se puede establecer en `TGWITNESS_DOCKER_SOCKET`. El worker utiliza explícitamente ese socket de Unix en lugar de un contexto remoto de Docker. No expongas una API de Docker a los usuarios del panel ni montes su socket dentro del contenedor de reconocimiento. Para la transcripción, instala por separado un modelo de Whisper compatible con CTranslate2 y, a continuación, configura `TGWITNESS_WHISPER_MODEL_DIR` en su directorio. El trabajador lo carga con `local_files_only=True`; el modelo seleccionado y los datos de entrada se montan en modo de solo lectura. Consulta la [documentación del motor sobre la carga de modelos](https://github.com/SYSTRAN/faster-whisper). La imagen de OCR suministrada incluye datos de entrenamiento en inglés y ruso. Incorpora otro idioma a tu imagen cuando sea necesario; los códigos de idioma siguen [la CLI de Tesseract](https://tesseract-ocr.github.io/tessdoc/Command-Line-Usage.html). No se recurre a ningún modelo durante el procesamiento. La configuración de compilación/descarga puede utilizar la red; cada contenedor de reconocimiento tiene la conexión a red desactivada. Instala la imagen antes de habilitarla; el entorno de ejecución utiliza `--pull=never`. ## Límites y recuperación El contenedor se ejecuta como un usuario sin privilegios, con un root de solo lectura, capacidades restringidas, `no-new-privileges` , un núcleo de CPU, 2 GiB de memoria, un límite de PID y un sistema de archivos temporal acotado. Solo se montan una copia verificada del archivo seleccionado y un directorio de modelos opcional. La base de datos, el almacén y la sesión del recopilador no se montan. Los [parámetros de ejecución de Docker](https://docs.docker.com/reference/cli/docker/container/run/) imponen estos límites; se trata de un límite del contenedor, no de un enclave de hardware. Los archivos tienen un límite de 50 MiB, las imágenes de 20 millones de píxeles, el audio de 30 minutos con una duración conocida y el procesamiento de cinco minutos. Solo se ejecuta un trabajador a la vez, con un máximo de 20 tareas en cola o en ejecución y 100 tareas retenidas por espacio de trabajo. La opción «Cancelar» detiene el contenedor; «Reintentar» crea un nuevo trabajo vinculado al intento anterior. Los trabajos interrumpidos se marcan tras el reinicio. El procesamiento puede fallar cuando un modelo no se ajusta a los límites configurados; no se ejecuta de forma silenciosa sin aislamiento. --- # Telegram · Webhooks salientes Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reference/webhooks/ Envía eventos específicos a receptores HTTPS con firmas HMAC, reintentos y estado de entrega. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Envía eventos específicos a receptores HTTPS con firmas HMAC, reintentos y estado de entrega. [TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [Documentación](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) · [Integraciones con archivos](https://phishdestroy.github.io/TgWitness/es/docs/reference/cli/) ![Integraciones con archivos](https://phishdestroy.github.io/TgWitness/assets/chapter-integrations.svg) [Guía de flujo de trabajo](https://phishdestroy.github.io/TgWitness/docs/archive/) · [Wiki](https://github.com/phishdestroy/TgWitness/blob/main/docs/wiki/Archive-and-Integrations.md) Abre **Integraciones → Webhooks salientes** en el espacio de trabajo seleccionado. Añade un receptor HTTPS, elige eventos de recopilación/multimedia/exportación y, opcionalmente, selecciona chats para nuevas observaciones y cambios. El texto de los mensajes está desactivado por defecto. Al habilitar los extractos, se añaden como máximo 1.000 caracteres a los eventos de cambio de mensaje; los campos sin procesar de Telegram y las credenciales nunca se envían. Copia la clave secreta HMAC una sola vez en la configuración protegida del receptor. Está cifrada en la bóveda de TgWitness y no se puede recuperar desde el panel. Elimina y vuelve a crear un destino para rotarlo. **Envía** a las colas **de prueba sintéticas** una prueba sin contenido de chat; actualiza el estado de entrega para ver el resultado. La entrega amplía el ciclo de notificaciones existente junto con Apprise. Utiliza la ruta externa del espacio de trabajo y las restricciones de destino privado existentes. No hay ningún plan de contingencia directo ni redireccionamiento posterior. Las URL no deben contener credenciales, cadenas de consulta ni fragmentos; las direcciones privadas requieren la aceptación a nivel de servidor, no una configuración que un usuario del panel pueda eludir. ## Carga útil y firma Esquema: [`tgwitness.webhook/1`](https://github.com/phishdestroy/TgWitness/blob/main/integrations/webhook.schema.json). Cada carga útil contiene `event_id`, `timestamp`, `workspace`, `type`, `synthetic` y contadores. Los eventos basados en el registro incluyen su secuencia y su hash. La finalización de la exportación completa y las pruebas sintéticas son eventos de entrega, sin ninguna referencia inventada al registro firmado. Los avisos de eliminación de Telegram y `missing_on_recheck` siguen siendo tipos distintos. El encabezado `X-TgWitness-Signature` es `t=UNIX_SECONDS,v1=HEX_HMAC_SHA256`. Calcula el HMAC sobre los bytes exactos `timestamp + "." + raw_request_body`, utilizando el secreto mostrado como bytes UTF-8. Compara las firmas en tiempo constante antes de analizar o procesar el cuerpo del mensaje. Rechaza las marcas de tiempo que se desvíen más de cinco minutos de tu reloj. La marca de tiempo se actualiza en cada intento de entrega. Utiliza `event_id` como clave de idempotencia en un almacenamiento duradero, con una restricción atómica de unicidad antes de los efectos secundarios. Una firma válida por sí sola no impide que se repita una solicitud reciente. Conserva los ID procesados al menos durante toda la ventana de reintentos; consérvalos durante más tiempo si el receptor puede volver a procesar los eventos almacenados. ## Reintentos Las entregas se ponen en cola de forma permanente antes de las solicitudes HTTP. Utilizan la semántica «al menos una vez»: una confirmación perdida o un reinicio pueden provocar que un evento se entregue de nuevo con el mismo ID. Hay ocho intentos con retroceso exponencial, que comienzan en 15 segundos y tienen un límite máximo de una hora. Para que se considere un éxito, se requiere una respuesta 2xx. Las tareas agotadas dejan un error visible; no se garantiza la entrega una vez finalizados los reintentos. La cola tiene capacidad para 1.000 envíos. Cuando se llena, el escaneo de los eventos del registro se detiene y se reanuda cuando hay espacio disponible. La finalización de una exportación completa que no se pueda poner en cola genera un error de cola visible. Se intentan hasta cinco envíos por cada ciclo de notificación y se conservan los últimos 100 registros de intentos. Al eliminar un destino también se eliminan sus envíos pendientes. ## Ejemplo de n8n Importa [el flujo de trabajo de ejemplo](https://github.com/phishdestroy/TgWitness/blob/main/integrations/n8n-tgwitness.json). Está inactivo y no contiene información confidencial ni acciones posteriores. Configura `TGWITNESS_WEBHOOK_SECRET` en el entorno del trabajador de n8n, permite el acceso a ese entorno y habilita la función integrada `crypto` para el nodo Code. El ejemplo utiliza la opción «raw-body» del nodo Webhook, comprueba la firma y la vigencia, y confirma los eventos validados. Esto se ajusta a la [implementación documentada](https://github.com/n8n-io/n8n/blob/master/packages/nodes-base/nodes/Webhook/Webhook.node.ts) del nodo. Antes de añadir entradas o notificaciones de SIEM, incorpora un almacenamiento idempotente y duradero claveado mediante `event_id`. Restringe la edición de flujos de trabajo de n8n y la retención de registros de ejecución de acuerdo con los datos que hayas elegido enviar. TgWitness no añade comandos entrantes. --- # Telegram · Mostrador público Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reference/showcase/ Publica mensajes guardados de canales públicos seleccionados e instantáneas firmadas a través de enlaces caducables y revocables. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Publica mensajes guardados de canales públicos seleccionados e instantáneas firmadas a través de enlaces caducables y revocables. [TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [Documentación](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) · [Implementación y recuperación](https://phishdestroy.github.io/TgWitness/es/docs/reference/deployment/) ![Implementación y recuperación](https://phishdestroy.github.io/TgWitness/assets/chapter-operate.svg) **«Acceso → Vitrina pública»** crea una página independiente de solo lectura utilizando el sistema de tokens de acceso existente. Lee las observaciones guardadas de la instalación. No inicia un recopilador, ni inicia sesión en Telegram, ni adquiere un canal para un visitante. ## Publicar una página 1. Guarda un perfil de origen para cada canal público que quieras mostrar. Un canal debe tener un nombre de usuario público en su último perfil guardado; los grupos y los chats privados no son válidos. 2. Abre **Acceso → Muestra pública** (o `/showcase-manage.html`) como administrador. 3. Selecciona canales de hasta 16 espacios de trabajo, introduce el título de la página pública y elige una duración del enlace de 1, 7 o 30 días. Las etiquetas internas de los espacios de trabajo no se publican. Se pueden incluir hasta 64 canales. 4. Revisa el texto de los canales seleccionados para su publicación y, a continuación, haz clic en **«Vista previa de los registros seleccionados**». La vista previa utiliza la misma proyección del lado del servidor que la página de visitantes. 5. Haz clic en **«Crear enlace de presentación**». Copia el enlace mientras esté visible. Ábrelo en un navegador aparte para revisar la página del destinatario antes de distribuirla. El enlace contiene un token de acceso en su fragmento de URL. La página elimina el fragmento antes de realizar solicitudes a la API y lo sustituye por una sesión del navegador. Cualquier persona que disponga del enlace puede abrir el material seleccionado hasta su caducidad o revocación. Los nuevos enlaces permiten 100 sesiones simultáneas, cada una de una duración máxima de una hora. Los controles de acceso existentes también pueden aplicar restricciones de direcciones y límites de inicio de sesión a través de la API de concesión. El acceso normal de revisor es un modo diferente y sigue incluyendo los mensajes y archivos permitidos originalmente. ## Lo que ven los visitantes | Visible | Se mantiene privado | | --- | --- | | Títulos seleccionados de canales públicos, nombres de usuario y fechas de observación de perfiles | Identidades de las cuentas, etiquetas internas del espacio de trabajo y fuentes no seleccionadas | | Texto capturado y cada edición guardada | ID de remitente estructurados, nombres, nombres de usuario, números de teléfono y valores de perfil | | Observaciones sobre eliminaciones con el texto guardado previamente, si está disponible | Archivos adjuntos, avatares, miniaturas, nombres de archivo y contenidos originales | | Marcadores que indican que se ha registrado un autor, un perfil o un archivo adjunto | Metadatos de reenvío y respuesta, rutas de red, direcciones IP y credenciales | | Recuento de eventos en canales seleccionados, cambios en la colección actual, latido e intervalo de puntos de control | Controles de recopilación y API estándar para la exportación de pruebas | | Huella de firma, punto de control del diario y prueba de consistencia | Claves de firma y sesiones de Telegram | **El texto de los mensajes públicos no se anonimiza automáticamente.** Un nombre, una mención, un número de teléfono o un enlace incluido en el mensaje sigue formando parte de dicho texto. `Redacted`Esto se aplica a los campos estructurados de autor/perfil. Revisa el contenido seleccionado antes de publicarlo, incluyendo las ediciones y eliminaciones conservadas. La elegibilidad refleja el **último perfil de origen guardado**, no una consulta en tiempo real en Telegram. Si un perfil posterior ya no tiene un nombre de usuario de canal público, las nuevas solicitudes excluyen dicho canal. Actualiza los perfiles de origen cuando cambie la visibilidad pública. Es posible que los lectores ya tengan guardado material que hayan recibido anteriormente. Los registros originales firmados permanecen inalterados. La proyección mostrada se firma por separado e incluye hash que hacen referencia a sus registros originales. Una firma de proyección autentica la declaración mostrada; no se trata de la firma del evento original sobre bytes censurados. ## Comprueba las firmas y la continuidad Despliega **«Fingerprint & signed checkpoint»** y descarga una instantánea. Tras una actualización de la página, la descarga incluye la instantánea anterior del navegador y una prueba de consistencia de Merkle entre los límites de sus registros. La actualización automática se produce una vez por minuto mientras la página está visible y muestra su primera página de observaciones. Una vez instalado TgWitness, comprueba el archivo descargado sin conexión: ``` python -m tgwitness.showcase_verify showcase.json --fingerprint TRUSTED_COLLECTOR_SHA256 ``` La huella digital debe proceder de una referencia de confianza independiente. Para compararla con una instantánea que hayas guardado tú mismo, utiliza `--previous earlier.json`; esto anula la instantánea anterior incluida en la descarga. La prueba actual debe comenzar en ese límite guardado. Los clientes autenticados pueden solicitar esa prueba utilizando `GET /api/showcase/{workspace_id}?challenge=<32-hex-random>&from_count=`. Un diario más corto devuelve un código de estado HTTP 409 en lugar de restablecer el límite de forma silenciosa. El punto de control firmado se registra en el **Diario completo del recopilador**, incluyendo su número de registros y el hash opaco del encabezado. Los recuentos de mensajes mostrados solo se aplican a los canales públicos seleccionados. La página nunca muestra el contenido del otro diario. Se trata de recuentos de eventos, no de mensajes únicos. Los ajustes describen la configuración actual, no todos los intervalos de grabación anteriores. La verificación de la firma y la coherencia permite detectar cambios con respecto a un límite establecido. No recuenta de forma independiente los contadores firmados, ni certifica el origen de Telegram, ni demuestra que la captura se haya realizado de forma ininterrumpida, ni sustituye a un testigo independiente. Para esa revisión, utiliza el [verificador de pruebas](https://github.com/phishdestroy/TgWitness/blob/main/docs/TRUST.md), [el testigo independiente](https://phishdestroy.github.io/TgWitness/es/docs/reference/witness/) y [el registro a escala probada](https://phishdestroy.github.io/TgWitness/es/docs/reference/verification/). Las instalaciones sintéticas están claramente etiquetadas como sintéticas. ## Revocar o alojar la página Utiliza **«Revocar»** en el gestor de vitrinas o en la sección **«Acceso»** existente para cerrar el enlace y finalizar todas sus sesiones. El visitante borra los registros mostrados cuando una solicitud detecta que el acceso ha finalizado. La caducidad y los permisos se comprueban en cada solicitud. Las autorizaciones de vitrina no se pueden convertir en acceso ordinario al panel in situ; crea una nueva autorización para cambiar de modo. Sirve la página a través de la dirección HTTPS existente de la instalación. Publicar un enlace no abre un nuevo puerto, ni crea un túnel, ni cambia el DNS. El HTML y la API permanecen en la instalación del usuario. Un visitante de la demostración no puede utilizar las API habituales de mensajes, perfil, archivos multimedia, exportación o gestión con este acceso. --- # Telegram · Cómo funciona el registro de pruebas Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reference/how-it-works/ Se explican la cadena de hash, las firmas, los puntos de control y los testigos con las fórmulas exactas que utiliza el verificador. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Se explican la cadena de hash, las firmas, los puntos de control y los testigos con las fórmulas exactas que utiliza el verificador. [TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [Documentación](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) · [Pruebas y verificación](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/) ![Pruebas y verificación](https://phishdestroy.github.io/TgWitness/assets/chapter-evidence.svg) TgWitness conserva lo que ha observado una cuenta recopiladora, vincula dichas observaciones en un registro firmado y permite que otra persona verifique una exportación comparándola con una clave de confianza y un punto de control conservado anteriormente. El [sitio web de documentación local](https://github.com/phishdestroy/TgWitness/blob/main/docs/internal/PUBLISHING.md#preview-the-website-locally) incluye ejemplos interactivos en `/docs/concepts/`, un explorador de decisiones de puntos de control en `/docs/witness/` y guías paso a paso para [el «Case Board»](https://phishdestroy.github.io/TgWitness/es/docs/reference/case-board/), [el diseño de informes](https://phishdestroy.github.io/TgWitness/es/docs/reference/case-reports/) y [los extractos de traspaso](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#handover-extract). Todos los mensajes de ejemplo, recuentos y retrasos son ficticios. Los hash en el entorno de pruebas de la cadena se calculan con SHA-256 en el navegador. No se envía nada a Telegram. **En esta página** - [El mensaje cambia; las observaciones se acumulan](https://phishdestroy.github.io/TgWitness/es/docs/reference/how-it-works/#a-message-changes-observations-accumulate) - [Qué abarca un hash](https://phishdestroy.github.io/TgWitness/es/docs/reference/how-it-works/#what-a-hash-covers) - [Lo que aporta un punto de control anterior](https://phishdestroy.github.io/TgWitness/es/docs/reference/how-it-works/#what-an-earlier-checkpoint-adds) - [A dónde pertenece un testigo](https://phishdestroy.github.io/TgWitness/es/docs/reference/how-it-works/#where-a-witness-belongs) - [Prueba de entrega frente a acciones conocidas](https://phishdestroy.github.io/TgWitness/es/docs/reference/how-it-works/#test-delivery-against-known-actions) - [Elige un flujo de trabajo](https://phishdestroy.github.io/TgWitness/es/docs/reference/how-it-works/#pick-a-workflow) ## Un mensaje cambia; las observaciones se acumulan Diagrama de secuencia · Telegram → Recopilador: Nuevo mensaje: Quedamos a las 10:00; Recopilador → Registro firmado: Añadir mensaje.new; Telegram → Recopilador: Edición: Quedamos a las 11:00; Recopilador → Registro firmado: Añadir «mensaje.editado»; Telegram → Recopilador: Aviso de eliminación; Recopilador → Registro firmado: Añadir «message.deleted»; Nota sobre Registro firmado: Se conservan el mensaje original, las modificaciones y las eliminaciones. · Telegram · Recopilador · Registro firmado · Nuevo mensaje: Quedamos a las 10:00 · Añadir mensaje.new · Edición: Quedamos a las 11:00 · Añadir «mensaje.editado» · Aviso de eliminación · Añadir «message.deleted» · Se conservan el mensaje original, las modificacionesy las eliminaciones. **Diagrama en formato de texto** 1. Telegram → Recopilador: Nuevo mensaje: Quedamos a las 10:00 2. Recopilador → Registro firmado: Añadir mensaje.new 3. Telegram → Recopilador: Edición: Quedamos a las 11:00 4. Recopilador → Registro firmado: Añadir «mensaje.editado» 5. Telegram → Recopilador: Aviso de eliminación 6. Recopilador → Registro firmado: Añadir «message.deleted» 7. Nota sobre Registro firmado: Se conservan el mensaje original, las modificaciones y las eliminaciones. Esta secuencia simplificada da por hecho que Telegram entregó cada actualización y que la cuenta seleccionada pudo verla. Los eventos operativos también se incluyen en el registro. Una notificación de eliminación no indica quién la realizó ni la hora exacta de la eliminación. Las entregas repetidas se consideran observaciones independientes; no se suprime ningún duplicado en todo el registro. ## Qué abarca un hash ![Observar, codificar, generar un hash y firmar: cada nuevo evento incluye el hash anterior.](https://phishdestroy.github.io/TgWitness/assets/evidence-chain-animated.svg) Lea la fórmula de dentro hacia fuera: **C** convierte los nueve campos en bytes exactos; **SHA-256** genera su resumen; **«hex»** indica cómo se almacena dicho resumen. El hash anterior ya se encuentra dentro del evento. **«unhex»** vuelve a convertir el hash almacenado en los 32 bytes que firma Ed25519. [Diagrama de cadena estática](https://github.com/phishdestroy/TgWitness/blob/main/docs/assets/presentation/evidence-chain-static.svg) Sea C(ei) el JSON canónico en UTF-8 de los nueve campos de eventos. El primer `previous_hash` consta de 64 caracteres cero. Cada registro posterior incluye el hash hexadecimal del registro anterior: hi = hex(SHA256(C(ei))) σi = Ed25519.Sign(sk,unhex(hi)) La firma abarca los 32 bytes sin procesar del resumen. La entrada del hash contiene exactamente `seq`, `observed_at`, `source_at`, `kind`, `chat_id`, `message_id`, `actor_id`, `payload` y `previous_hash`. Las claves de los objetos están ordenadas; se omiten los espacios en blanco y los caracteres de escape ASCII ; se rechazan los valores NaN e infinito. Consulte la [codificación exacta](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#event-canonicalization). Diagrama de flujo · 64 caracteres nulos → Registro 1 / hash h1; Registro 1 / hash h1 → El registro 2 incluye h1 / hash h2; El registro 2 incluye h1 / hash h2 → El registro 3 incluye h2 / hash h3; El registro 3 incluye h2 / hash h3 → Punto de control firmado: recuento 3, encabezado h3 (conservar en otro lugar) · 64 caracteres nulos · Registro 1 / hash h1 · El registro 2 incluyeh1 / hash h2 · El registro 3 incluyeh2 / hash h3 · Punto de controlfirmado: recuento 3,encabezado h3 · conservar en otro lugar **Diagrama en formato de texto** 1. 64 caracteres nulos → Registro 1 / hash h1 2. Registro 1 / hash h1 → El registro 2 incluye h1 / hash h2 3. El registro 2 incluye h1 / hash h2 → El registro 3 incluye h2 / hash h3 4. El registro 3 incluye h2 / hash h3 → Punto de control firmado: recuento 3, encabezado h3 (conservar en otro lugar) | Cambiar al registro facilitado | Qué lo detecta | | --- | --- | | Modifique el registro 2 conservando su hash guardado | El hash del evento recalculado difiere; su firma ya no abarca el evento modificado | | Reconstruya el registro alterado y todos los hash posteriores | Las firmas originales fallan; un punto de control conservado en el límite afectado tampoco coincide. | | Elimine la parte final, pero mantenga intacto el prefijo restante | Un punto de control anterior conservado, más allá del prefijo facilitado, revela que la exportación es demasiado corta | | Vuelva a firmar un registro de sustitución con otra clave | Una huella digital de clave de confianza independiente rechaza la identidad sustitutiva | ![Al modificar un campo guardado, se altera su resumen; la reconstrucción de los hash no restaura las firmas originales.](https://phishdestroy.github.io/TgWitness/assets/evidence-tamper-animated.svg) **Pruebe la lógica en el registro 2:** cambie `Meet at 11:00` por `Meet at 12:00` en el evento guardado. Su hash recalculado ya no coincide. El recálculo de la cadena posterior puede reparar sus enlaces, pero no puede hacer que las firmas originales cubran los nuevos resúmenes. Por el contrario, una edición observada en Telegram se convierte en un nuevo registro del diario. [Diagrama de cambios estáticos](https://github.com/phishdestroy/TgWitness/blob/main/docs/assets/presentation/evidence-tamper-static.svg) Los enlaces de hash por sí solos no impiden que alguien recalcule una cadena de sustitución. La confianza se basa en la verificación de las firmas mediante una clave de confianza independiente y en la comparación con referencias conservadas fuera del recopilador. ## Lo que aporta un punto de control anterior ![Mantenga el recuento en 3 y el encabezado h3; una exportación posterior de 4 registros se comprueba en la posición 3.](https://phishdestroy.github.io/TgWitness/assets/evidence-checkpoint-animated.svg) **La referencia permanece fija mientras el registro crece.** Si el punto de control indica «3 registros, encabezado h3», una exportación de cuatro registros puede pasar la comprobación al coincidir con h3 en la posición 3. Su encabezado más reciente es h4, del que se espera que sea diferente. Una exportación de solo dos registros falla. [Diagrama estático de puntos de control](https://github.com/phishdestroy/TgWitness/blob/main/docs/assets/presentation/evidence-checkpoint-static.svg) Tras verificar la firma del punto de control, solicite: Nexport ≥ Ncheckpoint and hexport[Ncheckpoint] = Hcheckpoint Una exportación puede extenderse más allá de un punto de control. Debe coincidir en el límite retenido. El verificador real también comprueba la secuencia de cada evento, el enlace anterior, el hash y la firma. Si solo se comparara el encabezado final almacenado, se pasaría por alto un registro interior alterado cuyo hash guardado no se hubiera actualizado. ## El lugar que le corresponde a un testigo Diagrama de flujo · Recopilador / sesión de cuenta / clave A → Punto final de control de solo lectura; Witness / clave de recopilación fijada / clave propia B → Registro de pruebas firmado independiente; Witness / clave de recopilación fijada / clave propia B → Punto final de control de solo lectura (Solicite una comprobación); Punto final de control de solo lectura → Witness / clave de recopilación fijada / clave propia B (Respuesta firmada); Witness / clave de recopilación fijada / clave propia B → Canal con publicaciones firmadas de TGW1 (API del bot / token propio) · Servidor A · Servidor B · Recopilador / sesión decuenta / clave A · Punto final de control desolo lectura · Witness / clave derecopilación fijada /clave propia B · Registro de pruebasfirmado independiente · Canal con publicacionesfirmadas de TGW1 · Solicite una comprobación · Respuesta firmada · API del bot / token propio **Diagrama en formato de texto** 1. Recopilador / sesión de cuenta / clave A → Punto final de control de solo lectura 2. Witness / clave de recopilación fijada / clave propia B → Registro de pruebas firmado independiente 3. Witness / clave de recopilación fijada / clave propia B → Punto final de control de solo lectura (Solicite una comprobación) 4. Punto final de control de solo lectura → Witness / clave de recopilación fijada / clave propia B (Respuesta firmada) 5. Witness / clave de recopilación fijada / clave propia B → Canal con publicaciones firmadas de TGW1 (API del bot / token propio) El testigo registra retrocesos, un encabezado diferente con el mismo recuento, claves modificadas, respuestas no válidas y respuestas que faltan. Un recuento mayor por sí solo no garantiza que todos los registros anteriores permanezcan inalterados; compare la exportación con los puntos de control conservados. Un testigo en otro servidor evita verse afectado por las interrupciones del servidor del recopilador; un operador independiente aporta una mayor independencia. El «witness» certifica el estado del diario notificado por el «collector». Utilice una prueba de entrega controlada para comprobar qué acciones de Telegram llegaron a una cuenta de recopilación. Consulte [la configuración del «witness](https://phishdestroy.github.io/TgWitness/es/docs/reference/witness/)». ## Prueba de entrega frente a acciones conocidas Utilice un grupo controlado, cuentas de recopilación diferenciadas y un marcador nuevo. Envíe, edite y elimine de forma deliberada, comprobando la captura entre cada etapa. Defina las acciones previstas y un límite antes de examinar los resultados. R = |observed∩expected| / |expected| Δ t = treceipt - taction Solo cuentan las acciones esperadas que coincidan; los recibos duplicados no aumentan el numerador. El denominador debe ser distinto de cero. Un recibo que falte no tiene un retardo medido. Documente la incertidumbre del reloj; utilice su propio tiempo de acción de eliminación controlado, ya que Telegram no proporciona la hora exacta de eliminación. Un resultado como 5/6 (83,3 %) describe las acciones de prueba, no la exhaustividad de todo el tráfico de Telegram. ## Elija un flujo de trabajo A continuación se presenta [el proceso completo de investigación](https://phishdestroy.github.io/TgWitness/es/docs/reference/investigation/) tras un incidente que abarca un canal, un grupo, un bot y un chat privado: 1. En una cuenta de recopilación específica, active el modo de investigación de toda la cuenta e haga un inventario de los chats accesibles. Utilice los chats seleccionados o una carpeta para una cuenta principal. 2. Obtenga instantáneas del registro, el historial completo de cada chat y los archivos adjuntos conservados. 3. Conserve los cambios en tiempo real y cualquier interacción deliberada con los paneles junto con sus comprobantes. 4. Realice un seguimiento de los identificadores numéricos de los remitentes, las relaciones de respuesta, los destinatarios recurrentes y los hashes de los archivos a través de los registros citados y los perfiles de las personas. 5. Añade notas vinculadas a las fuentes y colecciones en Case Board. Reconstruye una línea temporal entre chats con marcas de tiempo y lagunas explícitas. 6. Compare los espacios de trabajo de otras cuentas manteniendo separados sus orígenes y claves. 7. Recopile y verifique los registros firmados, los perfiles y las exportaciones del historial junto con las notas del caso. La guía `/docs/cases/` del sitio web incluye un mapa interactivo de casos y variantes para disputas entre bots, mensajes eliminados y participantes que cambian de nombre. Case Board mantiene las notas y las recopilaciones dentro de un espacio de trabajo. Las exportaciones en grupo recopilan paquetes de espacios de trabajo independientes; la correlación entre espacios de trabajo y la línea de tiempo combinada siguen siendo tareas del analista. [Validación completada y trabajo pendiente](https://phishdestroy.github.io/TgWitness/es/docs/reference/verification/) · [Exportar y verificar](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#investigation-handoff) · [Empiece con una cuenta](https://phishdestroy.github.io/TgWitness/es/docs/reference/quickstart/) --- # Telegram · Configuración y verificación de informes Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reference/case-reports/ Filtros de informes, ocho diseños, plantillas de contenido, historiales de cambios guardados y la evaluación incluida en las exportaciones firmadas. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Filtros de informes, ocho diseños, plantillas de contenido, historiales de cambios guardados y la evaluación incluida en las exportaciones firmadas. [TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [Documentación](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) · [Investigación](https://phishdestroy.github.io/TgWitness/es/docs/reference/investigation/) ![Investigación](https://phishdestroy.github.io/TgWitness/assets/chapter-investigate.svg) Convierta las observaciones seleccionadas en un resumen legible del caso: su cuestión, alcance, cambios guardados, gráficos, conclusiones y referencias a las fuentes. Cada informe ofrece al destinatario una forma de comprobar el material entregado e inspeccionar la cobertura de la recopilación. La sección **«Base de confianza y limitaciones»** aparece en los informes de diario, traspaso, chat, cuenta y uso compartido. Los archivos PDF de diario y traspaso utilizan la misma evaluación que su archivo «`report.json`» firmado. Los manifiestos ZIP incluyen «`case_assessment`» en el manifiesto firmado. Esta evaluación se transmite junto con el material exportado. Las observaciones originales conservan sus firmas existentes. ## Formatos de los documentos y orden de lectura ### Estudio de informes Abre **«Exportaciones» → «Configurar» y «Vista previa**». Sigue el proceso en **«Datos» → «Diseño y contenido» → «Vista previa**»: 1. Utilice todo el espacio de trabajo o seleccione chats, autores, fechas de observación en UTC y tipos de eventos. Cargue el catálogo para buscar chats y autores, o introduzca sus ID de Telegram. Los filtros de autor coinciden con los ID de remitente registrados; un aviso de eliminación sin remitente no coincide con un filtro de autor. 2. Elige un diseño de página y, a continuación, selecciona los gráficos, las etiquetas de los participantes, la transcripción y tus conclusiones por escrito. Al cambiar el diseño, se mantienen estas opciones. 3. Genera la vista previa. En ella se muestran los recuentos reales, la actividad, los participantes, los registros de muestra, los cambios guardados y los rangos de números de mensajes que faltan. Si se cambia una opción, la vista previa queda desactualizada. Guarda antes de descargar el HTML, el PDF firmado, el JSON firmado o el archivo ZIP con las pruebas. La vista previa de los datos incluye el prefijo completo y estable del registro, no una muestra inicial. Solo se limitan las filas de muestra mostradas y las listas largas; se muestran sus recuentos omitidos. Una exportación posterior toma una nueva instantánea estable, por lo que la recopilación en curso puede aumentar las cifras. El alcance, los recuentos y la identidad de la fuente se incluyen en el informe firmado. Abrir o previsualizar el formulario no lo guarda. **Orientación sobre jurisdicciones.** En Detalles del documento, abre **Orientación sobre jurisdicciones · opcional** para elegir una jurisdicción y un procedimiento civil/mercantil o penal. El apéndice incluye la base jurídica, los enlaces a las fuentes, las notas de preparación y el estado de la investigación. Los resúmenes y explicaciones en el idioma local sobre las garantías de recopilación son opcionales. No hay ninguna jurisdicción seleccionada por defecto. Estas opciones pertenecen al espacio de trabajo y quedan excluidas de las configuraciones de diseño guardadas y de los valores predeterminados implícitos de copia compartida. Véase [valores predeterminados, informes compatibles y límites de investigación](https://github.com/phishdestroy/TgWitness/blob/main/docs/JURISDICTION_GUIDANCE.md) . **Elige la copia destinada al destinatario.** Los gráficos y la transcripción utilizan los registros seleccionados. La integridad, la custodia y la cobertura describen el diario de fuentes completo. El archivo ZIP de pruebas contiene sus registros originales y archivos adjuntos. Utiliza [una entrega minimizada](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#handover-extract) cuando el destinatario solo deba recibir datos seleccionados y autorizados. ### Leer modificaciones, eliminaciones e identificadores que faltan Una modificación muestra el texto guardado **«antes»** y **«después»** y resalta las palabras modificadas. Una eliminación muestra la última versión guardada antes de la notificación. Si no se ha capturado ningún contenido anterior, el informe así lo indica. Cuando se seleccionan únicamente modificaciones o eliminaciones, las versiones anteriores siguen estando disponibles como contexto etiquetado explícitamente fuera de los filtros. Los mensajes no relacionados no se añaden a estos historiales. **Los ID de mensajes no observados** son huecos entre números conocidos en los chats seleccionados y el intervalo de ID derivado de la fecha. Se comprueba cada registro de fuente conocido antes de declarar un número como no observado: filtrar a otro autor, un tipo de evento o una fecha no puede crear un hueco falso. Los mensajes guardados adyacentes se etiquetan como contexto. La ausencia de un número no prueba que un mensaje existiera o que se haya eliminado; los avisos de eliminación y las nuevas comprobaciones fallidas siguen siendo tipos de eventos independientes. ### Elige un diseño Hay disponibles ocho diseños de página para informes en formato HTML (diario y chat individual) y PDF firmados. Utilizan los mismos registros y cálculos, con diferentes portadas, tipografía, títulos de capítulos, tablas y espaciado. | Diseño | Estilo de lectura | | --- | --- | | Clásico | Un expediente tradicional con cubierta oscura y secciones numeradas. | | Editorial | Una página de título con marco y tipografía serif, márgenes amplios y una barra de capítulos estrecha. | | Instrucciones | Una portada compacta con lomo azul marino, títulos breves y tablas con espaciado reducido. | | Análisis | Una portada estilo encuesta, tablas modulares y figuras con espaciado fijo. | | Técnico | Un registro rayado, una barra de referencia numerada y tablas de comparación precisas. | | Resumen | Una portada panorámica, espaciado generoso y cifras resumidas destacadas. | | Serie de lectura | Una barra lateral y capítulos agrupados para los resultados, el alcance, los cambios y el diario de observaciones. | | Libro mayor y margen | Capítulos numerados con un margen amplio, tablas y gráficos exactos y una transcripción de los mensajes en un apartado separado. | El diseño se guarda por espacio de trabajo y se registra en el manifiesto de exportación firmado. El HTML funciona sin conexión, admite temas claros y oscuros, y se adapta a pantallas estrechas y a idiomas que se escriben de derecha a izquierda. Los PDF nativos utilizan fuentes incluidas; el diseño editorial incluye Noto Serif bajo su licencia SIL Open Font License incluida. Las series de lectura y el «Ledger & margin» también se aplican a los resúmenes de cuentas, los chats de cuentas y el intercambio de copias. Los archivos PDF en chino, japonés y coreano requieren además una fuente adecuada en el servidor, como Noto Sans CJK, instalada en todo el sistema o ubicada en `TGWITNESS_FONT_DIR`. Si no está disponible, el archivo ZIP conserva los informes en formato HTML y JSON. Estos dos diseños incluyen un registro legible sin JavaScript. Para exportaciones de gran volumen, esta vista contiene hasta 500 registros completos dentro de un límite de entrada de 8 MiB; el informe indica el límite y ofrece enlaces al visor completo y a los registros originales. El directorio de cuentas y el índice de relaciones describen esa misma muestra de lectura, no a todos los participantes. Los gráficos del diario completo mantienen su ámbito de aplicación indicado por separado. ### Selecciona el contenido | Contenido preestablecido | Incluido por defecto | | --- | --- | | Expediente del caso | Actividad, horas de observación, participantes, chats y la transcripción del registro. | | Instrucciones | Resumen de actividades sin clasificaciones de los participantes ni la transcripción. | | Revisión de actividades | Actividad, horas de observación, participantes, chats y composición, con referencias a las fuentes y cifras exactas. | | Informe personalizado | Tu propia combinación de gráficos, transcripciones y vistas previas. | Al cambiar una configuración preestablecida, se conservan el diseño, los detalles del caso y el análisis escrito. Las comprobaciones de integridad, la cobertura, las limitaciones y las instrucciones de verificación se mantienen en cada diseño. Los registros originales del archivo ZIP permanecen inalterados cuando se oculta un gráfico o una transcripción. Las **«Notas de examen»** opcionales contienen la pregunta, el método, los resultados y la conclusión redactados por el autor del informe. Cite el archivo de origen y los números de registro en los resultados. La firma conserva estas declaraciones del autor junto con el informe; las observaciones de origen y la interpretación del autor siguen siendo identificables. Los traspasos simplificados omiten estas notas privadas y las historias clínicas completas. Las opciones de historia clínica y exploración se aplican a los informes de la historia clínica. Selecciona la actividad a lo largo del tiempo, el mapa de calor de días laborables y horas en UTC, las clasificaciones de participantes, las clasificaciones de chats y la composición de los registros. Elige entre 5 y 30 grupos clasificados y alias de participantes neutros o ID de cuenta. Los remitentes desconocidos y el resto de participantes aparecen en filas separadas. Los alias solo afectan a los gráficos; los registros de origen siguen conteniendo sus identidades. La vista previa del diseño se actualiza a partir del borrador sin guardar utilizando la portada de producción, el examen y los componentes de gráficos, limitada a las coincidencias dentro de los primeros 50 000 registros de origen. La vista previa de datos que aparece a continuación calcula la selección completa. Está explícitamente sin firmar y no conserva las modificaciones. Los botones «Portada» y «Gráficos» cambian de sección. No se trata de una vista previa completa del PDF. La opción **«Guardar configuración del informe»** aplica las opciones a futuras exportaciones; los archivos firmados existentes son inmutables. El PDF utiliza la portada elegida, la tipografía, el diseño de capítulos y los mismos agregados seleccionados que el HTML y el JSON firmado. La evaluación de fiabilidad, las limitaciones de cobertura y las instrucciones de verificación siguen estando presentes. Ocultar los gráficos o la transcripción legible no elimina las filas de fuentes fidedignas del archivo ZIP. Las series de gráficos desactivadas se omiten del JSON analítico; utilice una exportación minimizada para restringir la divulgación de los registros de origen. Los filtros de selección de datos se aplican a los informes de registro; las exportaciones de cuentas y de contenido compartido conservan su propio ámbito de adquisición y divulgación. Las preferencias compartidas de diseño y gráficos se conservan en las nuevas exportaciones de chats y cuentas, así como en las vistas previas de cuentas compartidas. La configuración de idioma y privacidad de las cuentas y del compartir se mantiene independiente; las notas privadas de casos y de examen no se copian en estas exportaciones. Los informes de cuentas y de compartir siguen estando en formato HTML protegidos por su manifiesto de archivo firmado. El diario, el traspaso de diario minimizado y los kits de chat único también proporcionan archivos PDF firmados. ### Lo que recogen los gráficos La actividad del diario y los mapas de calor contabilizan **las observaciones** nuevas, históricas, recuperadas, editadas, eliminadas y ausentes en la nueva comprobación, según la hora de observación del recopilador en UTC. Se excluyen los latidos y los acuses de recibo de archivos adjuntos. Las clasificaciones de participantes solo cuentan las observaciones de mensajes nuevas, históricas y recuperadas: no se considera que un remitente sea quien edita o elimina el mensaje. Las observaciones repetidas pueden referirse al mismo mensaje de Telegram. Los análisis de registros conservan los recuentos por tipo, las referencias al primer y último registro y el SHA-256 del archivo fuente « `events.jsonl`». Las cifras incluyen valores exactos en HTML y PDF. Los intervalos diarios pasan a ser mensuales una vez superados los 366 días registrados; los gráficos los agrupan en un máximo de 36 intervalos de igual anchura. Más de 100 000 identificadores distintos o 1 200 meses hacen que el gráfico afectado no esté disponible, aunque los recuentos totales exactos siguen estando disponibles. Los gráficos de instantáneas y de uso compartido de cuentas solo cuentan las filas de mensajes no de servicio incluidas, utilizando la hora de los mensajes registrada. Los totales de uso compartido se calculan tras la censura y el filtrado. Estos gráficos utilizan como máximo 90 intervalos de fecha UTC de igual anchura y conservan hasta 10 000 valores de agrupación; los recuentos excedentes se declaran y concilian explícitamente. El último intervalo puede ser más corto. Las fechas desconocidas o aproximadas no se incluyen en los gráficos temporales. Un intervalo vacío significa que no hay observaciones incluidas; consulta la cobertura para ver las lagunas. Estos gráficos describen la actividad guardada. Los remitentes desconocidos siguen siendo una categoría aparte, y cada comprobación se registra de forma individual. Cuando se incluye, el archivo «`analytics.json`» queda protegido por los hash de los archivos firmados del archivo. El informe de registro «`report.json`» incorpora el mismo agregado seleccionado. La verificación de la firma detecta los bytes modificados. Para comprobar las cifras, vuelva a calcular los agregados del registro con «`report_analytics.Analytics`» y «`selected`», o los agregados de la instantánea con «`snapshot_analytics.collect`» y «`project`». ### Indicadores de anomalías **Vista previa.** Los informes de pruebas añaden una sección **Indicadores de anomalías** calculada por procesadores registrados (`tgwitness/metrics/`, un archivo por métrica). El informe nombra a cada procesador que se ha ejecutado junto con su versión, y muestra su método debajo de su tabla, de modo que el cálculo se pueda repetir a partir de `events.jsonl` con `tgwitness.metrics.run`. | Procesador | Qué muestra | | --- | --- | | `first_time_posters_over_time`, v1 | Usuarios que publican por primera vez y mensajes por día UTC. Para que se active una alerta, se requieren al menos cinco usuarios que publiquen por primera vez y tres veces su mediana, con un volumen de mensajes de, como máximo, 1.5 veces su mediana. La línea de base utiliza al menos siete días observados dentro de los últimos 14 días naturales, tras siete días de calentamiento. | | `service_vs_message_ratio`, v1 | Se distinguen los números de mensajes guardados por chat y la cuota utilizada por los mensajes de servicio. Se describe un sistema de numeración; no se explica la ausencia de un número concreto. | | `join_leave_per_month`, v1 | Altas, bajas y eliminaciones o bloqueos por mes, uno por persona, chat, cambio y día. | | `pinned_per_month`, v1 | Mensajes de servicio fijados, avisos desfijados y mensajes fijados añadidos o eliminados entre instantáneas del estado del chat, por mes. | **Parámetros → Métricas del informe** selecciona los procesadores y el número de filas mostradas, incluso en los informes filtrados. Las tablas diarias y mensuales muestran las filas recientes; las tablas de cuota de servicio clasifican los chats según el recuento de mensajes guardados. Los totales abarcan todas las filas. A partir de una copia del código fuente, crea los ocho diseños mencionados anteriormente a partir de la misma revista ficticia: ``` python tools/build_report_styles.py --output test-results/report-styles ``` Abre el archivo «`index.html`» resultante para comparar los informes HTML completos, los PDF firmados y los archivos ZIP. Todos los diseños utilizan el mismo diario de origen. Utiliza un nuevo directorio de salida para cada ejecución, de modo que se conserven los ejemplos firmados anteriormente. ![Expediente HTML ficticio](https://phishdestroy.github.io/TgWitness/assets/dossier-en.png) El HTML comienza con una portada del caso y cifras clave. El mapa de pruebas numerado enlaza con cada hallazgo, sus hechos justificativos, sus limitaciones y su revisión independiente. Los registros buscables y las referencias de registros estables siguen estando disponibles en el visor sin conexión. El diseño se adapta a pantallas estrechas, tanto a temas como a navegadores sin JavaScript. El PDF firmado cuenta con una portada específica en formato A4, una referencia del informe y un código QR, un resumen ejecutivo, un mapa de pruebas, conclusiones numeradas y marcadores de documentos. Sus encabezados y pies de página identifican el informe. Un código QR identifica el material; no se trata de un resultado de verificación independiente. Las impresiones desde el navegador son independientes de este PDF firmado criptográficamente. La línea de tiempo de observación sitúa los periodos de observación registrados y las interrupciones en el mismo eje UTC. El espacio en blanco no implica cobertura; las tablas detalladas conservan los intervalos exactos. El archivo ZIP contiene los informes legibles, el JSON firmado, los registros de origen y las instrucciones de verificación. Crea un expediente nuevo y ficticio en inglés, ruso y alemán con el entorno de desarrollo instalado: ``` python tools/build_dossier_example.py --output test-results/my-new-dossier ``` Cada directorio de idioma contiene `report.html`, `report.pdf`, `report.json` y `dossier.zip`. Los directorios de ejemplos existentes nunca se sobrescriben. Para crearlo no se utiliza ninguna cuenta de Telegram, servicio externo de marca de tiempo ni conexión de red. ![Las tres primeras páginas del PDF ficticio firmado](https://phishdestroy.github.io/TgWitness/assets/dossier-pdf.png) ## Análisis de un caso concreto En el caso de un registro de 1.200 entradas con una marca de tiempo validada en la entrada 1.000, el informe identifica 200 entradas posteriores fuera del límite de dicha marca de tiempo. Se trata de un límite superior respecto a la existencia de un punto de control, no de una prueba de la hora de envío de cada mensaje. Si otros tres archivos de marcas de tiempo no superan la validación o no pueden validarse, se cuentan por separado y no pueden aportar una conclusión positiva. Una marca de tiempo válida debe cumplir todos estos requisitos: su huella coincide con el punto de control, su firma se remonta a una raíz TSA de confianza en el momento de la marca, y la firma, la clave, el recuento y el encabezado del punto de control coinciden exactamente con el prefijo del diario. No basta con analizar una marca de tiempo o disponer de un recibo de OTS. El lector debe elegir de forma independiente la raíz TSA de confianza y repetir la verificación. OTS necesita su propia comprobación de confirmación de Bitcoin. | Estado del informe | Significado | | --- | --- | | Comprobado durante la exportación | El exportador ha realizado la comprobación indicada; aún es necesario repetirla de forma independiente. | | Grabado; se requiere revisión | Se registra la observación subyacente o la declaración del operador; no se trata de una confirmación independiente. | | No se incluye en este texto | El texto no aporta ninguna prueba que respalde esta afirmación. Tampoco afirma que no exista en ningún otro lugar. | | No se ha comprobado de forma independiente | El informe no proporciona un resultado de verificación independiente. | | Incompleto o no disponible | Falta algún material o alguna comprobación obligatoria, o bien está incompleto o no se ha realizado correctamente. | Revisa cada comprobación por separado, junto con la cobertura de la recopilación registrada. ## Lo que debe conservar una configuración sólida 1. Antes de proceder a la recopilación, guarda la huella digital de la clave del recopilador a través de un canal de confianza independiente. Compara esa referencia con la clave de firma de la exportación. 2. Conserve los puntos de control con marcas de tiempo independientes y, cuando se utilice, un registro de testigos fuera del control administrativo del recopilador. Compárelos con el registro exportado para comprobar sus límites anteriores. 3. Alcance de la adquisición de registros, lagunas, filtros, límites y cambios en la recopilación. Explica los periodos que faltan y que son relevantes para la reclamación en cuestión, diferenciando claramente los ID de mensajes no observados, los avisos de eliminación y las revisiones fallidas. 4. Conserve los archivos ZIP originales y sus hash. Registre cada titular, transferencia, fecha y finalidad. Mantenga junto a ellos las declaraciones atribuidas a los operadores y las notas del caso. 5. En el caso de los mensajes de voz confidenciales, se deben conservar y verificar de forma independiente la cotización, la verificación, la cadena de certificados de Intel, las mediciones, la fuente exacta y las condiciones de gestión de claves. Se debe conservar el resultado de la verificación de la certificación junto con los artefactos revisados. Consulte «[Ámbito de verificación](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#verification-scope)» para conocer las comprobaciones de adquisición, integridad del archivo, tiempo y cobertura de la recopilación en cada modo. ## Revisión del destinatario Utiliza una instalación fiable de TgWitness y una huella digital obtenida de forma independiente: ``` python -m tgwitness.verify evidence.zip --fingerprint TRUSTED_SHA256 python -m tgwitness.verify evidence.zip --fingerprint TRUSTED_SHA256 --tsa-ca tsa-root.pem python -m tgwitness.verify evidence.zip --fingerprint TRUSTED_SHA256 --witness witness.zip --witness-fingerprint WITNESS_SHA256 --require-witness python -m tgwitness.verify evidence.zip --fingerprint TRUSTED_SHA256 --check-drand ``` El archivo ZIP de Witness debe proceder de una fuente independiente de confianza; conserve también su clave y su procedencia. Mantenga los comandos, la versión de la herramienta, los resultados, los hash de entrada revisados y las cuestiones sin resolver. La verificación de balizas es una comprobación en línea independiente; el generador de informes nunca se pone en contacto con un servicio con el único fin de mostrar un informe. En caso de controversia sobre un mensaje concreto, cite la referencia del archivo, el archivo oficial y la referencia del registro; a continuación, describa el periodo de tiempo pertinente, las lagunas de cobertura, la selección y el material corroborativo. En el caso de una copia compartida, revise también la transformación registrada y sus referencias al archivo de origen. Los filtros privados y las asignaciones de identidad quedan fuera de su evaluación pública. La verificación del PDF firmado detecta cambios en los bytes cubiertos. Conserva el archivo digital original y el resultado de la verificación junto con cualquier captura de pantalla o copia impresa para su lectura. --- # Telegram · Exportación de cuentas Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reference/account-export/ Exporta lo que una cuenta puede leer en este momento: ámbito, tareas reanudables, un archivo firmado y copias compartidas minimizadas. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Exporta lo que una cuenta puede leer en este momento: ámbito, tareas reanudables, un archivo firmado y copias compartidas minimizadas. [TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [Documentación](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) · [Pruebas y verificación](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/) ![Pruebas y verificación](https://phishdestroy.github.io/TgWitness/assets/chapter-evidence.svg) Una exportación de cuenta reserva esa cuenta en exclusiva. Pausa explícitamente la supervisión u otra adquisición antes de iniciar o reanudar; la aplicación nunca la detiene automáticamente. Como administrador de la instalación, selecciona **«Empezar aquí» → «Exportar mi cuenta**» o **«Exportaciones» → «Cuenta de Telegram» → «Configurar la exportación de la cuenta**». Inicia sesión si es necesario, revisa el alcance e inicia explícitamente la exportación. No es necesaria una observación continua. **«Observaciones guardadas»** es una exportación independiente del diario existente; su ZIP incluye todas las fuentes, independientemente de los filtros del diario. Cada espacio de trabajo tiene sus propias tareas, identidad de firma y almacenamiento. El acceso al panel concedido, incluida una autorización de exportación ordinaria sin restricciones, no puede abrir estas rutas que abarcan toda la cuenta. Los filtros de remitente y de texto se despliegan en **«Filtrar por remitente» o «Texto del mensaje**». La sección **«Datos de la cuenta y método de conexión»** contiene categorías de cuenta opcionales y la opción «Takeout» o «sesión normal»; su resumen muestra las opciones activas incluso cuando está cerrada. Al cerrar estas secciones, se conservan sus ajustes. Los borradores de exportación e informes permanecen en la sesión actual del panel al cambiar de vista; no se guardan al recargar el navegador. Se puede acceder a los trabajos existentes desde cualquiera de las dos opciones de exportación. Este flujo de trabajo exporta los datos a los que tiene acceso actualmente la cuenta conectada. Por defecto, utiliza [Telegram Takeout](https://core.telegram.org/api/takeout); no se trata de una copia de seguridad de datos de Telegram no disponibles o eliminados. No se recuperan los chats secretos, el historial inaccesible ni las ediciones anteriores. Telegram puede imponer un periodo de espera antes de que comience Takeout. El panel muestra ese tiempo de espera; no cambia de método de transferencia de forma silenciosa. La opción explícita de la API estándar tiene una cobertura diferente y registra categorías no compatibles. Takeout es la API de exportación oficial que también utiliza Telegram Desktop. TgWitnesspuede generar archivos JSON compatibles con Desktop directamente a partir de su propia adquisición; no es necesario importar el archivo de otra persona. Los ID de chat y de mensajes están disponibles a través de ambos métodos de transferencia. Un chat público o el permiso para reenviar no garantizan una exportación más rápida ni eliminan el retraso en la aprobación de Takeout. Comprueba que el alcance y la configuración multimedia sean los mismos antes de comparar la velocidad. Para un máximo de 20 ID de chat seleccionados explícitamente, la exportación mediante la API estándar resuelve esos pares directamente antes de tener en cuenta el inventario completo de diálogos de la cuenta. Por lo tanto, un canal público legible puede exportarse sin necesidad de unirse a él, incluso cuando no figure en la lista de diálogos. Los contactos no almacenados en caché recurren al inventario habitual. El filtro de archivo sigue aplicándose: si Telegram no devuelve un diálogo y se excluyen los chats archivados, el estado de archivo desconocido se registra como una omisión. Takeout mantiene su procedimiento de inventario de rango dividido. Ninguna de las dos vías se une a los chats ni modifica los permisos de reenvío. En JSON compatible con escritorio, los canales que Telegram marca como `left` aparecen bajo `left_chats`, incluidos los canales públicos legibles a los que la cuenta no se ha unido. Tanto `FLOOD_WAIT` como `FLOOD_PREMIUM_WAIT` pausan las solicitudes durante todo el periodo solicitado por el servidor . El plazo de la cuenta se mantiene tras las reconexiones y los reinicios; una espera posterior más corta no puede acortarlo. Los reintentos están limitados, la cancelación conserva las páginas selladas, y las credenciales de la API no se rotan para eludir un límite de frecuencia. No se realiza ninguna compra de Premium. ## Elige qué se recopila | Configuración | Significado | | --- | --- | | Objetivo | Explica por qué es necesaria esta adquisición. No incluyas aquí nombres innecesarios ni detalles confidenciales del caso. | | Idioma del informe | Elige el idioma de las etiquetas del informe legible. El texto original del mensaje permanece sin cambios; las etiquetas de las plantillas no traducidas se muestran en inglés. El idioma se fija mediante las opciones de la tarea firmada. | | Tipos de chat / ID de chat | Todos los tipos seleccionados, o solo los chats de la lista; «Mensajes guardados» corresponde a los chats privados. Los chats archivados se pueden seleccionar por separado. | | Fechas | UTC. Se incluyen tanto la fecha de inicio como la de finalización del panel en el calendario. La API utiliza `from_utc` y exclusivos `to_utc`; el panel envía el inicio del día posterior a la fecha «Hasta». Un límite vacío deja ese lado sin restricciones. | | Identificadores de remitente | Solo los mensajes de los remitentes que figuran en la lista; una lista vacía incluye a todos los remitentes. | | El texto contiene | Las frases literales, sin distinción entre mayúsculas y minúsculas, se combinan con «OR». Las condiciones de remitente, fecha y mensaje propio se combinan con «AND». | | Mensajes propios | Conserva únicamente los mensajes enviados. | | Tipos de medios | Selecciona categorías de archivos adjuntos o borra todo para evitar la descarga de archivos de mensajes. | | Límites de archivos y de contenido multimedia total | MiB por archivo y GiB de contenido multimedia descargado en total. El texto, los recibos, los informes legibles y los elementos de sobrecarga ZIP requieren espacio adicional en disco. | | Categorías de cuentas | El perfil, los contactos, las fotos de perfil, las historias, los metadatos de sesión y otros datos de Takeout cuentan con controles independientes. | El ajuste preestablecido **«Minimize»** desactiva los archivos y los metadatos de las cuentas. Los filtros de remitente y contenido se aplican antes de que se conserven las páginas de mensajes y se descarguen los archivos multimedia. Telegram sigue transmitiendo páginas del historial de la API que contienen los mensajes necesarios para evaluar dichos filtros: el filtrado no garantiza que los mensajes no seleccionados nunca entren en la memoria del proceso. Cualquier otra observación en curso en el espacio de trabajo tiene su propio ámbito de aplicación y configuración de retención. El historial de fotos de perfil y las historias no están seleccionados por defecto. Desactiva también el perfil y los contactos cuando el caso solo requiera mensajes. Si los archivos adjuntos o los metadatos no son necesarios, excluirlos durante la adquisición evita que se conserve otra copia privada en esta exportación. Las cargas útiles de fotos utilizan la variante de imagen fija identificada en sus metadatos y manifiestos de hash, incluidas las fotos con una variante de avatar animado. Dicha animación no sustituye a la imagen fija seleccionada. Una carga útil más corta o más larga que el tamaño observado se registra como un archivo adjunto fallido, y se rechaza cualquier cambio en la representación durante la renovación de la referencia del archivo. Estos fallos dejan el archivo incompleto, aunque se conservan los registros de los mensajes. La verificación independiente también rechaza los archivos adjuntos guardados cuya longitud firmada contradiga su tamaño o representación observados, incluso en archivos más antiguos. ## Resumen, cobertura y verificación Cada tarea congela sus opciones y la identidad de la cuenta. El inventario y las páginas capturadas se firman; los recibos de las páginas registran hash, cursores, horas, resultados de los archivos adjuntos y su recibo anterior. Solo las páginas confirmadas hacen avanzar el progreso. Al reiniciar o reanudar, se comprueban esos registros antes de continuar. Se rechaza cualquier cuenta modificada, página firmada modificada o cadena de recibos incoherente. Las opciones no se pueden editar a mitad de una adquisición: inicia otra tarea para otro ámbito. La opción «Pausa» detiene la operación de la cuenta en ejecución. Al reiniciar la aplicación, el trabajo pendiente queda disponible para reanudarse de forma explícita. Una sesión de Takeout caducada requiere una reanudación explícita; cambiar los rangos de fragmentación de Telegram puede requerir una nueva adquisición. La opción «Reanudar» conserva las observaciones anteriores, por lo que una exportación de larga duración no es una instantánea atómica única. Otras operaciones de cambio de cuenta y exportaciones conflictivas se bloquean durante la adquisición. Espera a que finalice el empaquetado antes de eliminar un espacio de trabajo. La función «Reanudar» verifica el contenido ya capturado antes de continuar. Los archivos de gran tamaño en un almacenamiento lento pueden superar el tiempo de espera configurado **Parámetros → Tiempo de espera de las acciones del panel** (120 segundos por defecto). Aumenta ese valor antes de volver a intentarlo; la cancelación o la interrupción del almacenamiento dejan una tarea en pausa, y los fallos en las comprobaciones de integridad dejan una tarea fallida con una explicación. La verificación debe finalizar o detenerse de forma segura antes de que se puedan cerrar sus archivos. Las comprobaciones sintéticas no han validado ninguna afirmación sobre el rendimiento con cuentas de gran tamaño. El panel distingue entre un ámbito seleccionado completado y un archivo parcial, y registra las omisiones y las lecturas fallidas. Los archivos excluidos deliberadamente son distintos de los archivos fallidos o no disponibles. Comprueba la cobertura incluso cuando la verificación de integridad se realiza con éxito. Ningún lector local puede demostrar que Telegram haya devuelto todos los mensajes que han existido. Los archivos ZIP finalizados siguen estando disponibles para descargas repetidas y descargas por rango HTTP. Un archivo de cuenta contiene `manifest.json`, `manifest.sig`, firmados `job.json`, `inventory.json`, `receipts/`, fidedignos `data/*.jsonl`, seleccionado `media/`, HTML legible y un verificador. Fija la huella digital del recopilador a través de un canal independiente y, a continuación, verifica utilizando una instalación de confianza: ``` python -m tgwitness.verify account-export.zip --fingerprint TRUSTED_SHA256 ``` Para los archivos cuyo contenido expandido supere los 4 GiB, establece un límite explícito adecuado `--max-gib`. El panel verifica sus archivos locales autenticados y completos utilizando su tamaño expandido declarado y el resumen publicado ZIP; la CLI externa mantiene su límite de tamaño independiente. Verifícalo antes de abrir el HTML legible. El verificador integrado en el archivo es práctico, pero un verificador obtenido de forma independiente evita tener que confiar en el código ejecutable que se entrega junto con la evidencia. La firma Ed25519 y los hashSHA-256 detectan cambios después de que el recopilador haya guardado los bytes correspondientes. No **no** demuestran que Telegram haya firmado esos mensajes, que el operador del recopilador haya actuado con honestidad, que el historial de la cuenta esté completo ni que un tribunal vaya a aceptar el material. Las horas de captura se basan en el reloj del recopilador. Las marcas de tiempo independientes y la procedencia independiente de la adquisición deben evaluarse por separado. ## Prepara una comunicación para un abogado u otro destinatario Tras descargar una exportación completa, conserva la imagen original ZIP y abre `index.html` desde una copia extraída. El informe explica su alcance, la cobertura disponible y sus límites. Sus referencias de registro combinan la referencia del archivo, la ruta del documento y el número de registro, de modo que el destinatario pueda localizar la misma entrada en el HTML o en la copia impresa. Para ver un ejemplo práctico, [Abrir el informe ficticio](https://phishdestroy.github.io/TgWitness/demo/report/). Una vez finalizada la exportación de la cuenta, selecciona **«Preparar una copia para compartir**». Esto genera un derivado firmado independiente. La fuente ZIP permanece inalterada y privada; no la envíes junto con un derivado minimizado a menos que el destinatario esté autorizado a recibir su contenido completo. Selecciona el idioma del informe por separado. Cambiar el idioma o cualquier configuración de selección requiere otra vista previa antes de la creación. 1. Introduce el motivo de la divulgación y selecciona las fechas, los ID de los remitentes y los criterios de texto literal. 2. Elige si deseas conservar las identidades, revelar solo a los participantes incluidos en la lista o seudonimizar a todos. En cualquier modo de seudonimización, también se sustituyen los ID o títulos de los chats y los ID de los mensajes. Los seudónimos son fijos dentro de una misma divulgación y cambian entre divulgaciones preparadas de forma independiente. 3. Conserva el texto del mensaje, omítelo por completo o añade nombres o frases literales para enmascarar. En los modos privados, la herramienta también enmascara los nombres ocultos conocidos de los remitentes y los nombres de usuario alternativos, los identificadores de remitente completos, los nombres de los chats directos, los enlaces, las direcciones de correo electrónico y las cadenas similares a números de teléfono. La coincidencia de nombres conocidos gestiona la conversión de mayúsculas y minúsculas de Unicode, incluyendo `Straße`/`STRASSE`. Los títulos genéricos de grupos o canales no se eliminan automáticamente del texto del mensaje. Si se supera el límite de ocultación de identidades conocidas, restringe la exportación de origen u omite texto; la herramienta se niega a omitir silenciosamente los nombres posteriores. Se trata de reglas de «mejor esfuerzo», no de una anonimización general. 4. No incluyas archivos a menos que el destinatario los necesite. Los originales incluidos conservan sus píxeles, audio, texto y metadatos. La herramienta **no** los anonimiza. 5. Previsualiza los recuentos, las advertencias y los mensajes transformados de muestra y, a continuación, confirma explícitamente la creación. Las muestras están limitadas a 12 mensajes y 2.000 caracteres de texto cada una. Se trata de una muestra, no de una revisión completa del resultado. Para cambiar la configuración es necesario realizar otra previsualización. Una previsualización caduca a los 15 minutos y está vinculada a esa sesión de administrador y al ZIP original exacto; no se puede reutilizar tras su creación. Una nueva previsualización invalida la anterior para el mismo trabajo y sesión. 6. Examina el resultado completo `index.html` y `messages.jsonl` localmente antes de entregarlo. Si revela información innecesaria, crea una nueva divulgación con exclusiones más estrictas. No edites in situ la imagen firmada ZIP. ### Mensajes excluidos de la selección **Vista previa.** Una divulgación no parece completa cuando no lo está. Dentro de cada chat que contenga al menos un mensaje divulgado, los mensajes que la selección ha omitido aparecen como marcadores, `[withheld by selection — rule: sender]` (o `text`, `period`). Elige **«Mensajes excluidos por la selección**»: un marcador por cada serie de mensajes ocultos consecutivos (por defecto) o uno por cada mensaje. Los marcadores solo contienen la regla y un recuento, nunca texto, remitente, fecha ni archivos. Los chats en los que no hay nada revelado se omiten por completo, por lo que el paquete no revela su existencia. Las respuestas reveladas indican a qué responden: un mensaje incluido en esta copia, un mensaje omitido por la selección o un mensaje que no figura en la exportación de origen (eliminado antes de la exportación o nunca exportado; la exportación no puede distinguir cuál de las dos opciones es la correcta). Un mensaje omitido al que responde una respuesta revelada siempre recibe su propio marcador, de modo que la respuesta apunta a un registro que explica por qué está vacío. Estos tres estados son distintos de las eliminaciones y las lagunas en la recopilación, que pertenecen a la exportación original. En `messages.jsonl` (formato `tgwitness-account-disclosure-v2`) cada mensaje tiene `state`: `disclosed`, o `withheld` con `rules` y `count`. Una respuesta revelada tiene `reply_to` con el destinatario `id` y `state` (`disclosed`, `withheld`, `not_in_source`). El manifiesto cuenta los mensajes revelados, los chats, los archivos multimedia y `withheld` mensajes. `verify.py` Rechaza un marcador que contenga contenido y una respuesta que apunte a un registro que falte en el paquete; los paquetes de la versión 1 se verifican como antes. El formato minimizado omite los perfiles estructurados de las cuentas, los contactos, los avatares, las sesiones, las historias, los objetos Telegram sin procesar, los encabezados de reenvío, las citas de respuestas, las fichas de contacto y los metadatos de ubicación. Excluye los archivos JSONL originales, la configuración de filtros privados, la clave de seudónimo y el mapa de identidades. El texto seleccionado, las identidades conservadas explícitamente y los archivos incluidos pueden seguir conteniendo los mismos nombres, identificadores o frases utilizados en dichos filtros; requieren una revisión por separado. La política privada y la clave de seudónimo se conservan cifradas en la caja fuerte local del trabajo; al eliminar el trabajo se borran los registros de divulgación privada asociados. Los registros de la política pública recogen el recuento de filtros en lugar de los valores de los mismos. La finalidad indicada es pública en el manifiesto y en el HTML: los criterios privados explícitos y, en los modos seudonimizados, las identidades ocultas conocidas también se enmascaran allí, incluso cuando se omite el texto del mensaje. Mantén la finalidad libre de datos personales innecesarios; el contexto de identificación desconocido puede permanecer. Su manifiesto vincula los archivos derivados, la política pública y el hash de la imagen original ZIP. La verificación permite comprobar la integridad y, si la fuente se proporciona localmente, la correspondencia del enlace de origen: ``` python -m tgwitness.verify minimized-disclosure.zip --fingerprint TRUSTED_SHA256 python -m tgwitness.verify minimized-disclosure.zip --fingerprint TRUSTED_SHA256 --evidence account-export.zip ``` El enlace a la fuente no demuestra por sí solo que la transformación haya seleccionado todos los elementos necesarios o haya eliminado todos los detalles identificativos. El texto sin formato original no se incluye como prueba. Se necesita una nueva revisión para llegar a esa conclusión. ## Compartir y captura alojada Selecciona los mensajes y archivos que necesite el destinatario, revisa la copia completa que se va a compartir y conserva el archivo original por separado. Registra el hash del archivo ZIP enviado para que el destinatario pueda identificar y verificar esa copia exacta. La seudonimización sustituye los identificadores seleccionados; el texto incluido y los archivos originales siguen formando parte de la revisión. GitHub Actions admite exportaciones de cuentas completas y de chats seleccionados a través de Takeout o de la API habitual, además de un registro de eventos de un solo chat. La [guía de captura alojada](https://phishdestroy.github.io/TgWitness/docs/capture/) explica la verificación de la configuración y el límite de 120 minutos. Para verificar una copia compartida derivada de una captura alojada, compara su hash de origen con el del archivo original y verifica la certificación de dicho archivo mediante las [comprobaciones específicas del modo](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#verification-scope). [Formato de las pruebas](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/) · [Informes de casos](https://phishdestroy.github.io/TgWitness/es/docs/reference/case-reports/) --- # Telegram · Formato de las pruebas Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/ Contenido del archivo ZIP firmado, tipos de registros, acuses de recibo, perfiles de usuarios, copias externas y verificación sin conexión. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Translation coverage: this edition includes material from the English original. Contenido del archivo ZIP firmado, tipos de registros, acuses de recibo, perfiles de usuarios, copias externas y verificación sin conexión. [TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [Documentación](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) ![Pruebas y verificación](https://phishdestroy.github.io/TgWitness/assets/chapter-evidence.svg) TgWitness conserva las observaciones de Telegram visibles en la cuenta en un registro firmado. Los destinatarios pueden verificar los registros guardados, los archivos adjuntos y los informes comparándolos con una clave de recopilador de confianza y, a continuación, comparar el registro con un punto de control conservado de forma independiente. Esta página describe los formatos, las comprobaciones y el material que hay que conservar para el traspaso. Los destinatarios pueden empezar con **VERIFY.cmd** en Windows: solicita el archivo ZIP original y la huella digital de la clave obtenida de forma independiente, muestra un resultado explicado y guarda un registro de verificación por separado. Consulta los lanzadores de [verification y el entorno de ejecución portátil](https://github.com/phishdestroy/TgWitness/blob/main/docs/VERIFICATION_LAUNCHER.md) para conocer la configuración y los límites de confianza. **En esta página** - [¿Qué se firma?](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#what-is-signed) - [Comparación de exportaciones de chats](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#comparing-chat-exports) - [Traspaso de la investigación](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#investigation-handoff) - [Extracto de la entrega](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#handover-extract) - [Informes legibles](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#readable-reports) - [Canonización de eventos](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#event-canonicalization) - [Semántica de los actores](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#actor-semantics) - [Cobertura: continuidad, lagunas e ID no observados](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#coverage-continuity-gaps-and-unobserved-ids) - [Productor](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#producer) - [Perfiles de personas](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#people-profiles) - [Testigo independiente](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#independent-witness) - [Manifiesto y puntos de control](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#manifest-and-checkpoints) - [Ámbito de verificación](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#verification-scope) - [Anexos](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#attachments) - [Recibos de recogida y proceso duraderos (0.2)](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#durable-collection-and-process-receipts-02) - Preparación de [RFC 3161 y verificación de la respuesta (0.2)](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#rfc-3161-preparation-and-response-verification-02) - [Registros opcionales en el modo de pruebas: drand y dispositivos de Telegram](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#optional-records-in-evidence-mode-drand-and-telegram-devices) ## ¿Qué es la firma? | Material | Protección | Qué debe conservarse | | --- | --- | --- | | Cada entrada del registro, incluidos los eventos operativos | Cadena SHA-256 y una firma Ed25519 por cada evento | `events.jsonl` original, la huella digital de la clave de confianza, y un punto de control conservado | | Contenido del archivo ZIP de pruebas | `manifest.sig` firma el manifiesto canónico, que recoge los hash de los archivos de contenido | El archivo ZIP completo, que incluye su manifiesto y su firma | | Archivos adjuntos conservados | SHA-256 y recuento de bytes en un evento «`media.saved`» firmado; hash del archivo en el manifiesto ZIP firmado | Los bytes originales contenidos en el archivo ZIP verificado | | Punto de control | Firma Ed25519 sobre la longitud del registro, el hash de cabecera, la clave pública y la hora de creación. | Una copia independiente conservada antes de un cambio objeto de controversia | | Recibo de entrega | Registro firmado de la versión del recopilador, los hash de los archivos fuente y la configuración inicial, también incluido en `process.started` | El recibo, el registro asociado y las pruebas del entorno para el modo de verificación seleccionado | | Informes legibles: `report.html` y sus partes, `report.json`, `report.pdf`, `chat.pdf` | Un sello «Ed25519» por archivo sobre su contenido; el «PDF» también lleva una firma estándar «PDF» (véase «[» Informes legibles «](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#readable-reports)») | El archivo tal y como se ha recibido y la huella digital de la clave de confianza; el archivo ZIP al que hace referencia. | | CSV independiente | No se incluye una firma criptográfica independiente; los hash de los eventos por sí solos resultan insuficientes | Utilice el contenido exacto del archivo ZIP verificado para comprobar su integridad. | | Capturas de pantalla, impresiones o archivos PDF generados por un navegador | No se incluye la firma de TgWitness en el contenido derivado. | Conserve el paquete original verificado y documente cómo se ha creado la copia derivada. | El recopilador verifica las firmas del registro antes de generar cada formato de exportación. Los informes legibles en HTML y PDF llevan sus propios sellos; el archivo CSV independiente se comprueba como parte de un ZIP firmado. Mantén el ZIP para conservar los bytes del archivo adjunto y el manifiesto, y un punto de control independiente para comparar el registro con un límite anterior. ## Comparación de exportaciones de chats Verificar y comparar dos archivos ZIP de exportación de chat firmados con huellas digitales de los firmantes conservadas de forma independiente: huellas digitales: ``` python -m tgwitness.verify first.zip --compare second.zip \ --fingerprint FIRST_TRUSTED_KEY_SHA256 --compare-fingerprint SECOND_TRUSTED_KEY_SHA256 ``` Cuando ambos archivos registran los mismos identificadores numéricos de cuenta y de chat, los registros se emparejan por el identificador del mensaje. **Sin cambios** significa igualdad del registro JSON completo guardado: se incluyen el texto completo, el autor, las fechas, el destinatario de la respuesta, los metadatos anidados y los campos desconocidos. El El orden de las claves del objeto JSON no importa; sí importan los campos ausentes, los valores nulos, los tipos de valor y el orden de las matrices. La vista previa de 300 caracteres es solo para visualización. Las entradas modificadas identifican el `changed_fields` de nivel superior que difiere, incluidos los cambios invisibles en dicha vista previa. Los ID de mensaje duplicados se rechazan en lugar de sobrescribirse entre sí durante la comparación. Una diferencia puede ser un nombre de usuario modificado, un recuento de visualizaciones, una anotación de la colección u otros metadatos de observación. Por sí sola, no confirma una edición en Telegram, ni identifica quién realizó el cambio, ni demuestra cuál de los archivos contradictorios es el correcto. Los registros sin analizar permanecen en la comparación; la igualdad de su representación guardada no significa que se haya descodificado su carga útil de Telegram. En caso de identidades de cuenta o chat diferentes o ausentes, la herramienta solo encuentra posibles correspondencias utilizando el remitente, el texto completo, el hash del archivo, el tipo de archivo multimedia y una tolerancia temporal de cinco segundos. Informa de **Matched**, no de **Unchanged**. Estos candidatos no establecen la identidad del mensaje ni la igualdad de todos los metadatos. Los registros no analizados permanecen sin emparejar. Las diferencias en los registros emparejados siguen figurando en `changed`, incluso en modo de contenido; estas diferencias no demuestran que se haya editado el mismo mensaje. Con `--json`, `matched` cuenta los pares y `unchanged` cuenta los pares cuyos registros completos guardados son iguales. Ninguno de estos recuentos demuestra la identidad del mensaje en modo de contenido. La salida existente `changed_fields` y el valor entero `unchanged` siguen siendo compatibles con los resultados de comparaciones anteriores. El formato de archivo y la verificación de la firma no han sufrido cambios. ## Traspaso de la investigación 1. Anote en las notas del caso la referencia del caso, el operador, el ID numérico de la cuenta de Telegram, las fuentes seleccionadas, la política de recopilación y el periodo de recopilación. TgWitness conserva las observaciones y admite notas y recopilaciones vinculadas a las fuentes en [el «Case Board](https://phishdestroy.github.io/TgWitness/es/docs/reference/case-board/)». Conserve los registros de transferencia y custodia junto con los materiales del caso. Comprueba la configuración de recopilación prevista con el [procedimiento de aceptación en tiempo real](https://github.com/phishdestroy/TgWitness/blob/main/docs/internal/LIVE_ACCEPTANCE.md). 2. Conserve la huella digital de la clave pública del espacio de trabajo de forma independiente antes de basarse en sus exportaciones. Guarde los puntos de control firmados fuera del recopilador durante la recopilación. Registre las interrupciones y los límites de visibilidad de la cuenta. 3. Exporte un archivo **ZIP firmado** y conserve el recibo de ejecución firmado. Utilice un punto de control en o antes del límite del registro exportado. Un punto de control posterior puede rechazar correctamente una exportación anterior por ser demasiado corta. Las exportaciones incluyen el registro completo del espacio de trabajo, independientemente de los filtros de los paneles; revise el material antes de compartirlo. 4. Pida al destinatario que verifique el archivo ZIP con una copia fiable del verificador y la huella digital o punto de control facilitados de forma independiente. Desde un entorno de desarrollo fiable con su entorno de Python activo: ``` python -m tgwitness.verify evidence.zip --fingerprint TRUSTED_PUBLIC_KEY_SHA256 --checkpoint retained-checkpoint.json ``` Los informes de resultados correctos muestran «`key_pinned: true` » y «`checkpoint_checked: true` » cuando se proporcionan y aceptan ambas entradas. Conserve el resultado de la verificación. ``` For a handover requiring the final exported record to be witnessed, use `--witness witness.zip --witness-fingerprint TRUSTED_WITNESS_SHA256 --require-witness`. This refuses an export with an unwitnessed tail. See the [witness handover procedure](WITNESS.md#require-a-witnessed-export-boundary). ``` 1. Record the archive's SHA-256, export boundary, transfer date, sender, and recipient in your custody record. Keep the original package intact and work from copies. Share evidence files rather than the application's private data directory, which also contains account sessions and signing secrets. For transfer, choose a password-protected AES-256 ZIP or the stronger `.tgwpw` container. ZIP uses WinZip's low-cost password derivation; use a long random passphrase. `.tgwpw` uses scrypt and AES-256-GCM and opens with the standalone verifier's `unseal-password` command. The password is not stored and only protects confidentiality; the recipient decrypts the archive and verifies the signed export inside, which is unchanged. 2. Si se requiere una fijación de tiempo independiente, siga el [procedimiento del RFC 3161](https://phishdestroy.github.io/TgWitness/es/docs/reference/timestamp/) y conserve la solicitud, el punto de control, la información de la CA de confianza y la respuesta verificada de la autoridad. La mera preparación de una solicitud no garantiza la obtención de una marca de tiempo. For `.tgwpw`, use an independently obtained verifier and choose a new output file with the original extension: `python verify.py unseal-password export.tgwpw --out evidence.zip`. The command prompts for the password; `--password-stdin` reads one line for automation. It never overwrites an existing file and publishes plaintext only after all records authenticate. Run normal signature verification on the decrypted file afterwards. The container uses scrypt (`N=131072`, `r=8`, `p=1`, 16-byte salt; about 128 MiB RAM) and AES-256-GCM with 1 MiB records and an authenticated final record. An encrypted metadata record stores the inner filename, so downloaded containers can be renamed. Una verificación satisfactoria establece la integridad en relación con la clave de recopilación de confianza y el límite retenido. Consulte [el alcance de la verificación](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#verification-scope) para conocer los supuestos de confianza y [los resultados](https://phishdestroy.github.io/TgWitness/es/docs/reference/verification/) [de la validación](https://phishdestroy.github.io/TgWitness/es/docs/reference/verification/) de las comprobaciones realizadas. ## Extracto del traspaso Un archivo ZIP firmado contiene todo el historial del espacio de trabajo. Cuando un tribunal, un abogado o una oficina de denuncia de abusos solo necesita algunos chats, un periodo concreto o determinadas personas, la opción **«Exportaciones → Extracto de entrega»** prepara una copia reducida (`tgwitness-handover-v1`) de acuerdo con las normas de divulgación seleccionadas. El operador indica la finalidad y selecciona los chats, un periodo opcional (UTC), las personas a las que se refiere el extracto, qué ocurre con el resto (se muestran, se sustituyen por seudónimos P01, P02… o se omiten), qué textos de los mensajes se conservan, qué archivos adjuntos y fotos de perfil se incluyen, y si se ocultan los números de teléfono y las direcciones de correo electrónico que aparecen en los textos. La finalidad y estas reglas figuran en el manifiesto firmado y en el informe; el registro «`handover.exported`» se almacena con el acceso que lo preparó y el SHA-256 del archivo, no el contenido. `verify.py` comprueba un extracto de dos maneras. Un registro que se muestra sin cambios se verifica en su totalidad: su contenido se compara con su hash, su firma Ed25519 y su enlace a un predecesor incluido. Un registro minimizado conserva el hash y la firma originales, por lo que la firma sigue siendo válida, pero los campos omitidos no pueden volver a calcularse a partir de ella; el registro indica qué se ha omitido y el informe lo señala. El manifiesto indica la longitud del diario y el encabezado con la firma del recopilador sobre dicho encabezado, y cuenta los registros omitidos; el archivo «`coverage.json`» describe los chats seleccionados. No se detectan los nombres que aparecen dentro de los nombres de archivo. Revisa los archivos finales antes de compartirlos: el texto libre, los nombres de archivo y los archivos adjuntos seleccionados aún pueden identificar a personas. Conserva el ZIP completo firmado: la extracción supone una divulgación, no un sustituto. ## Informes legibles Las pruebas firmadas, los traspasos y los archivos ZIP de chats contienen informes legibles en formato HTML y JSON, además de PDF cuando las fuentes necesarias están disponibles, en el idioma seleccionado para el informe. Cada informe está sellado con la clave Ed25519 del espacio de trabajo y puede verificarse por separado: ` `python -m tgwitness.verify FILE --fingerprint KEY [--evidence ZIP]``. - `report.html` / `chat.html`: la instrucción de sellado (`tgwitness-report-seal-v1`) cierra el archivo y firma el SHA-256 de cada byte anterior. Los historiales y chats largos se dividen en partes de un tamaño configurable (ajustes del informe, de 500 a 100 000 registros; 5 000 por defecto): `records/records-0001.html` o `messages/messages-0001.html`, cada una sellada con su número, rango y el total, y enumerada con su SHA-256 en el manifiesto firmado. Las series de pulsos del colector se muestran en una sola línea, a menos que la configuración del informe las enumere una por una. - `report.json` (`tgwitness-report-json-v1`, claves `format`, `report`, `seal`): el sello firma el SHA-256 del JSON canónico del `report`, de modo que los sistemas y scripts de casos puedan leer los datos y se pueda realizar una selección para la protección de datos a partir de ellos, mientras que el archivo firmado permanece intacto. - `report.pdf` / `chat.pdf`: un documento formal para imprimir y archivar, firmado dos veces sobre los mismos bytes, todo el archivo excepto el valor de la firma (`/ByteRange`). La firma estándar PDF (`adbe.pkcs7.detached`, CMS con SHA-256 y ECDSA P-256) utiliza un certificado de firma de documentos autoemitido almacenado en el almacén del espacio de trabajo; su número de serie de sujeto es la huella digital de la clave Ed25519 . El sello Ed25519 se incluye dentro del CMS como el atributo sin firmar `2.25.240684792623320047764573196045913242332` e identifica el certificado SHA-256 con `"content": "pdf-byte-range"`, de modo que la clave Ed25519 avala el certificado. Un lector PDF muestra si el archivo ha cambiado tras la firma y considera al firmante desconocido hasta que el certificado sea de confianza; en su lugar, compara la huella digital Ed25519. Los archivos PDF en chino, japonés y coreano necesitan una fuente en el servidor (o en `TGWITNESS_FONT_DIR`); sin ella, el archivo ZIP solo contiene los informes HTML y JSON . En un canal o supergrupo, Telegram numera los mensajes 1, 2, 3… en orden. Una exportación de chat enumera el primer y último número, cuántos hay presentes y cada serie de números ausentes en `message-ids.json` , el manifiesto y el encabezado `chat.json` , y marca cada hueco donde se produce en la transcripción. `verify.py` vuelve a enumerarlos a partir de `chat.json` . Un número ausente es un mensaje que Telegram no devolvió (eliminado antes de la exportación o no visible para la cuenta); en los chats privados y los grupos básicos, los números se comparten entre todos los chats de la cuenta y no se cuentan los huecos. Tras leer el historial, la exportación vuelve a solicitar a Telegram cada número ausente, por orden numérico (números `channels.getMessages` hasta 10,000). El resultado se encuentra en `message-ids.json` y en el informe. Una respuesta vacía indica que el número no está disponible para esta cuenta en el momento de la nueva comprobación; no especifica la causa. Cualquier mensaje devuelto durante la nueva comprobación se añade a la exportación y se marca como `found_on_recheck`. Cada informe comienza con **. En resumen,**: un párrafo, seguido de lo que muestra el material y lo que no muestra (quién está detrás de una cuenta, la integridad de la entrega, las eliminaciones previas a la observación, la hora sin marca de tiempo). El sello de la propia página se vuelve ámbar cuando el navegador ha comprobado la firma del sello, no la de la página: un navegador no proporciona a una página sus propios bytes. Solo se vuelve verde cuando el lector arrastra el archivo al campo de verificación al final de la página y todos los bytes coinciden, y solo si la página mostrada es ese archivo; de lo contrario, se vuelve rojo. Cada informe nombra el programa con exactitud: el commit de Git en el que el recopilador se ejecuta desde un checkout o el instalador establece `TGWITNESS_COMMIT`, y el SHA-256 de sus archivos fuente (`source_tree_sha256`, el JSON canónico de la ruta → SHA-256 de cada archivo `.py`, `.js`, `.css`, `.html` y `.svg` del paquete), que se reproduce al realizar un checkout de ese commit, a menos que se hayan modificado los archivos. El cliente Telegram recibe su nombre de su biblioteca, capa de API y centro de datos. Cuando comienza la observación y cuando una exportación de chat comienza y finaliza, el recopilador solicita a Telegram su hora (`updates.getState`, segundos enteros) y registra la hora de Telegram menos la del reloj del recopilador, con la incertidumbre derivada del tiempo de ida y vuelta; los informes muestran estas mediciones en la sección «Cadena de custodia». Una exportación de chat también registra cuándo se leyó el historial, además de las fechas de los mensajes. ### Visor de informes sin conexión y guía de archivo Descomprime el archivo ZIP completo antes de abrir `chat.html` o `report.html`. El visor ofrece funciones de búsqueda, filtros, participantes, indicadores, detalles de los registros y selecciones de JSON y CSV sin necesidad de un servidor. Mantén `viewer/` y `media/` junto al informe. Las selecciones son derivadas: utiliza `verify.py SELECTION.json --evidence ARCHIVE.zip` para compararlas con el archivo firmado. El verificador comprueba el ID del informe, la clave de firma, el límite del archivo y cada elemento seleccionado; los elementos editados, faltantes o duplicados no superan la comprobación. Las notas de selección y la hora de creación siguen siendo metadatos sin firmar. Las lagunas en los números de mensaje solo se muestran en un historial de chat completo, sin filtrar y en orden ascendente. Ocultar una categoría o no poder cargar un bloque de datos no debe convertir una fila omitida en prueba de que falte un mensaje. Las búsquedas resaltadas se realizan sobre texto sin formato antes de la conversión de HTML, conservando el marcado literal. El navegador comprueba las firmas del manifiesto, el ID y la clave del informe, así como todos los hash de los archivos enumerados. Rechaza estructuras ZIP ambiguas o mal formadas, nombres duplicados y rutas inseguras, y limita los archivos a 256 MiB y el contenido total declarado a 4 GiB. Utilice el verificador independiente para archivos más grandes. Esta comprobación del navegador complementa las comprobaciones que realiza el verificador sobre las cadenas de registros y la semántica de los datos. `README.txt` contiene una guía de inicio, un inventario de archivos alineado, instrucciones de verificación y notas sobre el formato de los datos en el idioma del informe, seguidas de una guía completa en inglés. `SHA256SUMS` abarca los archivos que figuran en él, excluyéndose a sí mismo, a `manifest.json` y a `manifest.sig`; el manifiesto firmado también abarca `SHA256SUMS`. Mantén el ZIP original sin modificaciones y guarda los archivos de trabajo fuera de la carpeta extraída. Los informes PDF incluyen marcadores de sección e identificación del caso o del informe en páginas posteriores. ### El chat en el momento de la exportación Una exportación de chat registra lo que Telegram indicaba sobre el chat cuando se inició la exportación: las propias etiquetas de Telegram (`scam`, `fake`, `restricted` con sus motivos, `verified`), los nombres de usuario, la descripción, el número de miembros y administradores, la discusión vinculada, la protección de contenidos, si los nuevos miembros ven los mensajes anteriores y a partir de qué mensaje esta cuenta puede ver el historial (`available_min_id`), la fecha del mensaje 1 cuando se trata de la creación del chat, y el SHA-256 de la foto del chat (guardada en `media/`). Registra la posición de la cuenta exportadora en el chat: función, fecha de incorporación, quién la invitó y, en el caso de un administrador, sus derechos. En su lugar, se indica una solicitud que Telegram rechaza. Cuando la cuenta que realiza la exportación es un administrador, la exportación lee el registro de administración del chat (Telegram se conserva durante unas 48 horas) en `admin-log.json`: eliminaciones y ediciones con el contenido y la cuenta que las realizó. Es el único registro de una eliminación que indica quién la realizó. ### Indicadores La lista de informes y el archivo contienen, como `indicators.csv` , `indicators.stix.json` (STIX 2.1 ) y `indicators.misp.json` (evento MISP ), lo que un servicio de gestión de abusos puede tratar en los mensajes grabados: enlaces y dominios (incluso los ocultos tras texto, en botones y en vistas previas de enlaces), direcciones de criptomonedas, nombres de usuario y enlaces de invitación Telegram , números de teléfono, direcciones de correo electrónico e imágenes guardadas. Las direcciones de Bitcoin, Litecoin, Dogecoin y TRON se incluyen en la lista solo cuando su suma de comprobación base58 es válida, las direcciones segwit cuando su suma de comprobación bech32 o bech32m es válida y las direcciones TON cuando su CRC es válido; las direcciones EVM y Solana se marcan como no comprobadas. Las imágenes contienen SHA-256 y un hash perceptual (dHash, 64 bits) que las copias recomprimidas o redimensionadas mantienen prácticamente sin cambios. Los informes escriben indicadores para que no se abran por accidente (`hxxps[://]example[.]com` ); los archivos conservan los valores tal y como estaban. Cada indicador se marca como desconocido y no apto para la detección automática (STIX , `indicator_types: unknown` , MISP , `to_ids: false` ; distribución a la propia organización): su inclusión en la lista indica que un mensaje lo contenía, no que sea malicioso. Un enlace cuyo texto muestre una dirección diferente a la que abre se marca en el informe. Los informes PDF terminan con una declaración del examinador que debe firmarse a mano, una lista de comprobación para un notario o perito judicial, y un código QR (que también aparece en la primera página) con el ID del informe, la huella digital de la clave y el SHA-256 de los datos oficiales, de modo que una copia impresa permita remontarse a su archivo. ## Canonización de eventos La entrada de hash consta exactamente de estos campos: ``` seq, observed_at, source_at, kind, chat_id, message_id, actor_id, payload, previous_hash ``` Serialice utilizando JSON compatible con Python con UTF-8, claves de objetos ordenadas, sin escapismos ASCII, sin espacios en blanco insignificantes y sin NaN/infinito: ``` json.dumps(value, ensure_ascii=False, sort_keys=True, separators=(",", ":"), allow_nan=False).encode("utf-8") ``` El SHA-256 de esos bytes se convierte en el hash del evento. La firma se genera mediante Ed25519 sobre los 32 bytes sin procesar del hash y, a continuación, se codifica en base64. El primer «previous_hash» está compuesto por 64 ceros. Los números de secuencia comienzan en 1 y aumentan en 1. Todos los eventos, incluidos los operativos, comparten una misma cadena. No se suprime la duplicación de entregas: las observaciones repetidas constituyen recibos distintos, no una afirmación de acciones distintas en Telegram. Las fechas sin procesar de Telegram son cadenas ISO; los campos binarios se convierten en objetos que contienen bytes_base64. El texto del mensaje, las entidades, los descriptores multimedia, los metadatos de respuesta, las reacciones y las acciones del servicio se conservan en los metadatos sin procesar del mensaje cuando se facilitan. «observed_at» es la hora del reloj de pared UTC del recopilador. «source_at» es la fecha facilitada por Telegram, cuando está disponible. Las notificaciones de eliminación no proporcionan una hora exacta de eliminación, por lo que «source_at» permanece nulo. El orden de recepción de los datos no coincide necesariamente con el orden de los eventos en la fuente. Las instantáneas del historial utilizan fechas de origen más antiguas, pero horas de observación actuales. ## Semántica de los actores message.new actor_id es el remitente del mensaje. message.edited no tiene ningún editor inferido; payload.sender_id registra al remitente del mensaje observado. Eliminación: el `actor_id` permanece nulo. Los mensajes del servicio de afiliación conservan el remitente y el tipo de acción, sin convertir cada eliminación en una baja voluntaria. Las actualizaciones sin procesar de los participantes conservan el `actor_id` tal y como se ha facilitado. Las instantáneas de reacciones no inventan un actor de cambio. Las notificaciones de eliminación para chats privados y grupos normales solo contienen los identificadores de los mensajes. Dichos chats comparten una secuencia de identificadores para toda la cuenta, por lo que un identificador identifica un único mensaje de esta cuenta. Cuando un mensaje con ese identificador se ha guardado anteriormente en este registro, la eliminación se registra en ese chat como «message.deleted», utilizando «payload.chat_resolution» como nombre del método. Los identificadores que nunca se han guardado se conservan como «deletion.unscoped» sin «chat_id»; no se hace ninguna suposición. Los canales y los supergrupos numeran los mensajes por chat y nunca se emparejan de esta forma. Cuando el mensaje eliminado fue enviado por la cuenta observada, payload.deleted_message_was_outgoing es verdadero; aún no se ha facilitado quién lo ha eliminado. Una notificación sin ámbito no establece que un mensaje nunca se haya guardado: un chat coincidente puede estar fuera del ámbito de observación actual, o puede que no haya una coincidencia única disponible. La nueva comprobación de ausencia sigue siendo una observación independiente de una notificación de eliminación en los recuentos de informes, los filtros y las etiquetas. Una recuperación posterior borra el estado actual de ausencia, al tiempo que conserva la comprobación fallida anterior en el historial firmado; ninguna de las dos observaciones constituye una notificación de eliminación. Los múltiples ID que remiten al mismo chat a partir de una notificación se agrupan como `deletion.batch`, independientemente de su número. La notificación no establece que se haya borrado todo el historial, quién realizó el borrado ni si se aplicó a todos los participantes. Los mensajes salientes guardados no modifican estos límites. Los diarios más antiguos pueden contener eventos `history.cleared` inferidos a partir de lotes de diez o más ID, con un texto explicativo que atribuye la eliminación al otro participante. Dichas inferencias no están respaldadas por la actualización. Conserva esos registros firmados originales, pero trátalos como notificaciones de eliminación agrupadas; la interfaz actual los etiqueta en consecuencia. ## Cobertura: continuidad, lagunas e identificadores no observados Cada archivo ZIP firmado contiene «`coverage.json`», el informe HTML se abre con el mismo resumen, y « `verify.py`» lo vuelve a calcular a partir de «`events.jsonl`» en lugar de confiar en el archivo: - **Se observa de forma continua desde X hasta Y.** Un periodo comienza con `observation.started` y finaliza ante una pausa, una interrupción, una pérdida de conexión con Telegram, un cierre de sesión, un inicio de proceso sin una parada ordenada, o más de tres minutos sin ningún registro durante la observación (los pulsos se registran cada minuto, por lo que el silencio significa que el proceso se detuvo, se bloqueó o que el ordenador entró en modo de suspensión). Cuando se modifica el intervalo de los pulsos en **«Parámetros»**, cada pulso lo registra y el silencio permitido pasa a ser de tres intervalos, nunca menos de tres minutos. - **Las lagunas** indican el tiempo transcurrido entre períodos, junto con el motivo. Una laguna que sigue sin resolverse en el último registro se marca como `not_resumed_by_last_record`. - **No se registran los ID de los mensajes.** En el caso de los canales y supergrupos, que numeran los mensajes por chat, los ID que faltan entre los registrados se indican como rangos. Se indican como «no*observados*» —eliminados, nunca entregados o fuera del historial guardado— y nunca como «eliminados». Los chats privados y los grupos normales comparten una secuencia para toda la cuenta, por lo que las lagunas dentro de uno de estos chats no significan nada y no se incluyen en la lista. - Los avisos de interrupciones a nivel de chat (por ejemplo, cuando Telegram solicita la recuperación de diferencias en un canal) se contabilizan como notas; no interrumpen la cobertura global. ### Números de mensajes que faltan (`gap_summary`) **Vista previa.** `coverage.json` → `gap_summary` Mide los números asignados por Telegram que este recopilador nunca ha detectado. Telegram numera los mensajes una vez por canal o supergrupo, y una vez por cuenta en chats privados, bots y grupos normales. Un número situado entre dos mensajes observados puede estar presente o faltar; un rango contiguo confirma que todos los mensajes numerados en él fueron observados. Una laguna no indica ningún responsable ni motivo. | Campo | Significado | | --- | --- | | `status` | `on`, o `off` cuando está desactivada en **Parámetros → Análisis de brechas** | | `parameters` | Los parámetros que dieron lugar al resultado, para que este pueda repetirse. | | `chats[]` | Una entrada por canal o supergrupo, cada una numerada por separado. | | `account` | La secuencia de chats privados, bots y grupos normales de toda la cuenta | | `status` (por secuencia) | `applicable`, o `not_applicable` con `reason` | | `observed_from`, `observed_to`, `span` | Número inicial y final observados y el tamaño del rango | | `observed`, `observed_without_content` | Números observados; aquellos de los que solo se tiene constancia a través de un registro de eliminación o de nueva comprobación | | `missing`, `density`, `gap_ranges`, `largest_gap` | Números nunca observados, su porcentaje respecto al rango, número de ejecuciones, la ejecución más larga | | `clusters[]` | Lagunas señaladas: `low`, `high`, `missing`, y los números observados adyacentes `after` / `before` con sus horas de observación | | `service_estimate` | Solo cuando esté habilitado: cuántos números que faltan serían mensajes de servicio según su proporción observada. Nunca se resta de `missing` | La validez se deriva del registro, nunca se da por sentada: - **Los canales y los supergrupos** se miden por chat, también en una exportación de los chats seleccionados. Los registros seleccionados por el remitente constituyen la medición `not_applicable`. - **La secuencia de toda la cuenta** se mide únicamente desde el primer hasta el último mensaje que llegó mientras la recopilación de toda la cuenta estaba activada y se conservaron los chats privados, los bots, los grupos normales y los mensajes propios de la cuenta, sin excluir ningún chat de este tipo (`scope.changed`). Los números indicados por `deletion.unscoped` se consideran observados sin contenido. Una exportación o transferencia de chats seleccionados no puede medirla. Si la recopilación de toda la cuenta se desactivó y volvió a activarse, una nota indica que los números utilizados durante ese tiempo aparecen como lagunas. - Los mensajes de servicio son entradas del registro con sus propios números, por lo que cierran sus huecos por sí mismos; la estimación opcional es solo contexto. `verify.py` vuelve a calcular `gap_summary` a partir de `events.jsonl` con los parámetros del `coverage.json` (valores por defecto para archivos más antiguos) y muestra la línea correspondiente a toda la cuenta en su resumen de cobertura. El `get_capture_status`(MCP y la línea de comandos) devuelve la misma medición para los chats que un acceso puede leer; la secuencia de toda la cuenta solo para el acceso que abarca todo el espacio de trabajo. Las observaciones repetidas de un mensaje de servicio cuentan una sola vez, y la estimación del servicio de la cuenta utiliza únicamente números dentro del rango medido. Un ámbito aplicado debe conservar explícitamente los mensajes propios de la cuenta antes de que se habilite la medición en toda la cuenta; los registros más antiguos que carezcan de esa información no pueden cumplir esta condición. La interrupción de la observación no amplía el rango medido, y se toma nota de su reanudación. La consulta al archivo en tiempo real tiene un tiempo asignado, incluido el escaneo de la base de datos, y marca una medición inconclusa como parcial. Telegram documenta las [secuencias de ID de mensajes independientes](https://core.telegram.org/api/updates#message-id-sequences). Estos números describen observaciones; no identifican a quien ha borrado el mensaje ni establecen por qué falta un número. Cuando Telegram deja de aceptar la cuenta, el registro `coverage.gap` que pone fin a la observación contiene `cause` (`account_banned`, `account_frozen`, `account_deleted`, `session_duplicated`, `session_revoked`, `session_expired`, `session_ended` o `not_authorized`) y el Telegram error; `verify.py` indica la causa por la que finaliza el periodo. La cobertura combina los periodos de observación registrados, las interrupciones y los resultados de los mensajes. Evalúala junto con los chats seleccionados, el periodo y la política de archivos adjuntos; el funcionamiento continuo por sí solo no garantiza la entrega completa de las actualizaciones de Telegram. ## Productor El manifiesto firmado de los archivos ZIP de pruebas, las exportaciones de chats, los registros de testigos y la declaración de los archivos de perfiles de usuarios contienen `producer` : software, versión, proyecto (PhishDestroy), página web y repositorio de código fuente. El informe HTML muestra la misma línea, y `verify.py` la incluye como parte de lo que ha verificado. Los archivos creados antes de que existiera este campo se verifican como anteriormente y se indican como si no mencionaran al creador. Cada registro `observation.started` también identifica al cliente Telegram que realizó la observación: su `api_id` (nunca el hash), ya sea un par público integrado o la propia aplicación del operador, la descripción del cliente enviada en la solicitud de conexión de Telegram, y el tipo de ruta de conexión con el modo IP (sin dirección de proxy ni clave secreta). El informe y el `custody.json` enumeran todos los clientes y rutas distintos con la fecha en que se registraron, así como las ocasiones en las que ningún proxy de la lista respondió y el Telegram detectó la dirección del servidor. Los registros anteriores a este así lo indican. ## Perfiles de personas A petición, se genera un archivo de perfil (`tgwitness-dossier-v1`, JSON) a partir de los registros ya presentes en el registro de pruebas correspondientes a un chat; no se recupera nada de Telegram y el contenido de los perfiles nunca se escribe en el registro de pruebas (la activación y desactivación de perfiles se registra como `dossier.changed`). Para cada persona con un mensaje guardado, se enumeran el nombre y el historial de nombres de usuario, las marcas de Telegram (bot, estafa, falso, premium, verificado, restringido, eliminado) tal y como se ve en el momento del guardado, las identificadores de foto de perfil, el hash SHA-256 y el hash perceptual (pHash, compatible con `imagehash.phash`) del avatar procedente de la caché local de avatares con avatares similares, la actividad (primer y último mensaje, recuentos, publicaciones editadas y eliminadas, mensajes por hora UTC), quién responde a quién, otros chats en este diario en los que la persona ha escrito, y carteras mencionadas (BTC, EVM, TRON, TON, LTC, DOGE, XMR, SOL; las direcciones Base58Check se validan mediante suma de comprobación), números de teléfono, nombres de usuario y enlaces, incluidos los enlaces ocultos tras el texto. Cada dato indica los registros del diario (`seq`) de los que procede, y `record_hashes` contiene el hash de cada registro al que se hace referencia. La declaración está firmada con la clave del espacio de trabajo: ``` python verify.py tgwitness-dossier-CHAT.json --fingerprint TRUSTED_SHA256 --evidence tgwitness-evidence.zip ``` Comprueba la firma, verifica la propia exportación de pruebas (firma, cadena de hash y archivos) y que cada registro al que se hace referencia exista sin modificaciones en dicha exportación del mismo espacio de trabajo. Los hash de los avatares se etiquetan como procedentes de la caché local (no de registros del diario). Las menciones son coincidencias de patrones: pistas que deben comprobarse, no hechos verificados. Los perfiles se activan por cada chat, pueden exportarse como un archivo ZIP cifrado con AES-256 y protegido con contraseña, y se eliminan cuando se desactivan o cuando el chat se retira de las fuentes. ## Testigo independiente Un diario de testigos (`tgwitness-witness-v1`) y sus publicaciones en el canal se cotejan con una exportación de pruebas realizada con `verify.py --witness … --channel …`; véase [«testigo independiente](https://phishdestroy.github.io/TgWitness/es/docs/reference/witness/)». ## Manifiesto y puntos de control El archivo `manifest.json` incluye el formato, la hora de exportación, la clave pública, la huella digital, la longitud del registro, el hash de cabecera, el ámbito, el productor, las limitaciones y el SHA-256 de cada elemento de contenido, salvo los propios ``manifest.json`` y ``manifest.sig``. El archivo `manifest.sig` es la firma Ed25519 en base64 sobre el JSON del manifiesto canónico. El verificador rechaza elementos inesperados o ausentes, nombres duplicados, archivos dañados, secuencias o cadenas rotas, firmas no válidas y discrepancias con un punto de control facilitado. Nunca extrae rutas de archivos. Limita el tamaño total declarado sin comprimir a 4 GiB; el `--max-gib N` permite archivos de mayor tamaño creados con un límite **de parámetros** ampliado. Ejecuta la verificación desde tu versión instalada de TgWitness o desde una copia revisada. La copia incluida en el archivo permite su uso portátil; compárala con tu instalación de confianza antes de ejecutarla. Un punto de control firma una declaración que contiene la clave pública, la longitud del diario, el hash de cabecera y la hora de creación. El verificador puede comprobar que un archivo posterior contenga el mismo prefijo. Conservar el punto de control fuera del recopilador, de modo que la verificación posterior compare el archivo con una referencia almacenada por separado. ## Ámbito de verificación La verificación comprueba el archivo y el modo de recopilación utilizado para generarlo. Elige el modo cuyo límite de confianza se ajuste al caso y, a continuación, conserva sus datos de verificación. | Modo de recopilación | Lo que comprueba el verificador | Datos de verificación y límite de confianza | | --- | --- | --- | | Espacio de trabajo local | Registrar firmas, cadena de hash, manifiesto y bytes de archivos adjuntos | Huella digital del colector conservada de forma independiente; el administrador del servidor controla la clave de firma local. | | Espacio de trabajo local con un testigo independiente | Se comprueban los archivos y se verifica la concordancia con un prefijo de registro anterior conservado por el testigo. | Clave de testigo y registros con fiabilidad independiente; el punto de control vincula el prefijo ya observado | | [Captura de GitHub Actions](https://github.com/phishdestroy/TgWitness/blob/main/docs/SEALED-ACTIONS.md) | Certificación en GitHub del resumen del archivo, el flujo de trabajo aprobado y las confirmaciones del recopilador, el ejecutor alojado, el origen de la sesión y la clave recientes, y la integridad interna del archivo. | Política de verificadores de confianza, repositorio de iniciadores de llamadas y paquete de certificación de GitHub; la recopilación se ejecuta bajo el flujo de trabajo fijado. | | [Implementación en la nube](https://phishdestroy.github.io/TgWitness/es/docs/reference/high-assurance/) | Registros del ciclo de vida y de acceso del proveedor, estado del cortafuegos y de Cloudflare, además del registro de ejecución firmado por el recopilador. | Consultas de solo lectura al proveedor y a Cloudflare; la disponibilidad de las comprobaciones individuales depende del proveedor. | | [Máquina virtual confidencial Intel TDX](https://phishdestroy.github.io/TgWitness/es/docs/reference/high-assurance/#confidential-vm-on-phala-cloud-intel-tdx) | Citar la firma y el estado de la plataforma, vinculándolos a la declaración del recopilador, la composición y las mediciones del sistema operativo. | Cadena de confianza de Intel y métricas de implementación previstas; conservar los resultados de todas las comprobaciones TDX requeridas. | En la adquisición sellada, el recopilador autorizado recibe los datos a través de una conexión autenticada de Telegram dentro del entorno verificado. La certificación vincula el archivo a esa ejecución, por lo que la verificación abarca tanto la adquisición como la integridad posterior del archivo. Esto se basa en el código autorizado y en la cadena de confianza de la plataforma mencionada anteriormente. La verificación de capturas de GitHub requiere una sesión creada dentro de la ejecución y rechaza las capturas de sesiones importadas. El recibo de ejecución registra la versión del recopilador, los hash de los archivos y los ajustes de inicio. La procedencia de GitHub y las mediciones TDX proporcionan las comprobaciones del entorno; el registro de validación identifica las configuraciones probadas. TgWitness firma las observaciones que recopila; ni Telegram ni los autores de los mensajes emiten estas firmas. En un espacio de trabajo local, el material creado antes del primer punto de control independiente sigue dependiendo del recopilador y de su titular de la clave. Los registros de cobertura describen el alcance seleccionado y los resultados de la recopilación, mientras que las marcas de tiempo externas verificadas fijan en el tiempo los límites del archivo o el diario confirmados. ## Archivos adjuntos Los archivos se identifican mediante SHA-256 en el directorio «media/». Un evento «media.saved» vincula un hash y la longitud en bytes a un evento de mensaje específico. Los nombres de archivo sin procesar son metadatos, nunca rutas locales. Los bytes multimedia se descargan de forma asíncrona, por lo que una eliminación inmediata podría impedir su captura. La recopilación desactivada, los archivos de tamaño excesivo o desconocido, los errores de descarga y las descargas interrumpidas se muestran como resultados. Un fallo del proceso puede dejar archivos parciales sin referenciar; estos no se incluyen en las exportaciones. El exportador ZIP verifica los archivos multimedia almacenados comparándolos con sus nombres. Las exportaciones en formato JSONL, CSV y HTML verifican las firmas de los eventos, pero no incluyen los bytes de los archivos multimedia. Los informes derivados son meras facilidades; el archivo events.jsonl constituye la representación oficial de los eventos. Una exportación completa del chat guarda los archivos adjuntos, según la configuración de archivos adjuntos del espacio de trabajo, en media/, con nombres del tipo SHA-256. Cada registro de mensaje en chat.json indica el nombre de su archivo (`file`, `file_sha256`) o el motivo de su ausencia (`file_status`), junto con lo que el lector vio alrededor del texto: enlaces detrás del texto, origen del reenvío, botones de bot, firma, visualizaciones y el temporizador de eliminación automática. `verify.py` comprueba que todos los archivos nombrados se encuentren en el manifiesto firmado bajo ese hash. ## Recibos de recogida y procesamiento duraderos (0,2) Una tarea multimedia y su confirmación del evento de mensaje se realizan en una sola transacción. La tarea almacena el descriptor original del mensaje de Telegram; la observación firmada vincula su SHA-256, la cuenta y la política de tamaño. La recuperación verifica dicha vinculación antes de la descarga. Nunca recupera el mensaje actual y sustituye de forma silenciosa por un archivo adjunto más reciente. Las tareas interrumpidas se vuelven a intentar, mientras que el fallo permanente sigue siendo un resultado explícito. Cada espacio de trabajo tiene su propio registro y su propia identidad de firma. Un evento process.started incluye un ID de ejecución, relojes locales, versiones de dependencias, hash de archivos fuente, cuenta/ámbito iniciales, y configuración de captura. Los heartbeats incluyen el ID de ejecución, el tiempo monótono y el estado de la cola. El recibo de ejecución también se puede descargar como un documento firmado por separado. Para la verificación del entorno de ejecución, combínalo con la certificación de GitHub o las comprobaciones TDX descritas en [Ámbito de verificación](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#verification-scope). Los puntos de control automáticos se conservan localmente al iniciar la aplicación, cada cinco minutos durante la observación (**Parámetros → Punto de control firmado cada**) y al cerrar la aplicación de forma ordenada. La verificación al inicio y la exportación comparan el registro con el último punto de control local conservado. Esto permite detectar una reversión de la base de datos cuando el punto de control se conserva. La retención independiente mantiene esa referencia disponible fuera del espacio de trabajo; además, una marca de tiempo externa verificada la fija en el tiempo. Tras un reinicio, se reanuda la posición de actualización de Telegram guardada (`catch_up_from` en `observation.started`) y se solicitan las actualizaciones perdidas. Una nueva comprobación periódica registra `message.recovered` para los mensajes perdidos y `message.missing_on_recheck` cuando Telegram ya no devuelve un mensaje guardado; este último no es un aviso de eliminación y no indica quién lo ha eliminado ni la hora. ### Copia y restauración externas (S3) La copia externa (Exportaciones, desactivada por defecto) carga segmentos del registro, archivos conservados y puntos de control con sus marcas de tiempo, así como las exportaciones completas de chats, a un almacenamiento compatible con S3, cifrados con AES-256-GCM antes de la subida, mediante una clave almacenada en la bóveda del espacio de trabajo; se aplica la retención de Object Lock cuando el depósito lo admita. Sin la clave descargada, la copia no puede leerse. Restablezca y verifique con `python -m tgwitness.replica restore --key-file KEY.json --out DIR`. La restauración requiere un directorio ordinario vacío. Las descargas y los objetos descifrados permanecen en un almacenamiento temporal privado hasta que se verifiquen todo el registro y cada punto de control conservado. Se rechazan las rutas de objetos no seguras, los rangos de segmentos incoherentes y los registros más cortos que un punto de control; si la verificación falla, no se publican archivos restaurados. Las comprobaciones de retención comparan el modo «Object Lock» y la fecha devueltos con el plazo enviado en el momento de la carga (con una tolerancia de redondeo de un segundo). Un plazo caducado, no válido o acortado no se considera verificado. El estado informa del objeto muestreado cuya retención se ha recuperado para esa ronda de carga. Los archivos locales que faltan o están dañados se notifican como un error de la pasada y el cursor se mantiene antes de ellos, de modo que el archivo se vuelve a intentar en la siguiente pasada; los archivos, puntos de control y exportaciones posteriores a este se siguen copiando. La restauración comprueba todas las referencias a los archivos conservados cotejándolas con los hash descifrados y los tamaños registrados. Los segmentos idénticos y superpuestos del registro procedentes de subidas interrumpidas se deduplican; las superposiciones conflictivas se rechazan. Los puntos de control creados durante una subida se aplazan hasta que se hayan copiado los registros del diario a los que corresponden, de modo que una pasada completada no publique un punto de control antes que su correspondiente registro del diario. ### Instantáneas de exportación en tiempo real Las exportaciones en tiempo real utilizan una instantánea de lectura estable de SQLite. Es posible que su parte inicial sea más antigua que el registro actual en tiempo real cuando finalice la descarga. Un punto de control creado después de dicha instantánea puede indicar correctamente que el archivo es más corto; compárelo con un punto de control situado en el prefijo exportado o anterior a él, no con un punto de control posterior arbitrario. ## Preparación de RFC 3161 y verificación de respuestas (0.2) El modo de pruebas (desactivado por defecto) envía únicamente el SHA-256 de cada punto de control firmado a las autoridades RFC 3161 y a los calendarios de OpenTimestamps indicados, a través de la ruta del espacio de trabajo y nunca a través de MTProxy. Las respuestas se almacenan en `checkpoints/anchors/`, se exportan y se verifican mediante `verify.py` (`--tsa-ca` comprueba la firma TSA; confirme las pruebas de OpenTimestamps con `ots upgrade` y `ots verify`). El panel prepara un archivo de solicitud que contiene los bytes canónicos de checkpoint.json, una huella SHA-256 del mensaje y un nonce aleatorio en timestamp.tsq, sumas de comprobación e instrucciones. No se realiza ninguna solicitud de red. La preparación no constituye un sello de tiempo fiable. `python -m tgwitness.anchor verify` invoca OpenSSL dos veces: una vez con los bytes del punto de control y otra vez con la solicitud original. Se requiere explícitamente un archivo de CA de confianza; los certificados incluidos no se consideran automáticamente de confianza. La comprobación de la solicitud es opcional en la CLI, por lo que debe conservar y proporcionar el parámetro --request para comprobar el nonce. El resultado indica si se ha comprobado. La firma del punto de control del recopilador y el registro deben verificarse por separado con la huella digital de confianza del recopilador. La verificación comprueba la firma de la respuesta, los bytes de punto de control y, cuando se facilite, la solicitud original bajo la confianza de la CA especificada. Las comprobaciones de revocación y la validación del archivo a largo plazo tras la caducidad del certificado quedan fuera del alcance del verificador actual. Consulte el [procedimiento](https://phishdestroy.github.io/TgWitness/es/docs/reference/timestamp/) y [los resultados de la validación](https://phishdestroy.github.io/TgWitness/es/docs/reference/verification/). ## Registros opcionales en modo de pruebas: dispositivos «drand» y «Telegram» Hay otros dos registros que pueden ejecutarse en las mismas pasadas que las marcas de tiempo. Ambos están desactivados por defecto y solo surten efecto mientras el modo de pruebas está activado: Extras → Pruebas y copias de seguridad → **Más testigos · opcional**, o `"drand": true` y `"devices": true` en `POST /api/evidence`. Un fallo no detiene al otro ni a las marcas de tiempo; el panel muestra el último resultado de cada uno debajo del formulario. **drand** (`beacon.drand` ). Cada pasada escribe la ronda más reciente de drand quicknet, la aleatoriedad pública de la Liga de la Entropía (una ronda cada 3 segundos), en el diario: `chain` , `round` , `randomness` , `signature` , `round_time` y el `relay` que respondió. Una ronda verificada e impredecible proporciona una referencia temporal inferior para el material vinculado mediante hash posterior. Una marca de tiempo verificada en un punto de control posterior proporciona una referencia temporal superior. Estas comprobaciones delimitan el material vinculado; la cobertura de la recopilación se evalúa por separado. El recopilador consulta primero a `drand.cloudflare.com` y, a continuación, a los repetidores de Protocol Labs, a través de la ruta del espacio de trabajo, con una solicitud por pasada. `verify.py` comprueba que cada valor aleatorio sea el SHA-256 de su firma y que el tiempo de ronda sea correcto, e informa de las rondas, del tramo más largo sin ninguna y de cuánto se retrasó el reloj del recopilador respecto a drand. No comprueba la firma BLS. `--check-drand` compara las rondas con un relé de Cloudflare y un relé de Protocol Labs, ya sean todas ellas o una muestra aleatoria de 100 en un registro extenso; una ronda que difiera no supera la verificación. Dispositivos **, Telegram,** (`account.devices`). En cada pasada se leen las sesiones de la cuenta con `account.getAuthorizations`; la lista Telegram que aparece en Ajustes → Dispositivos se registra: íntegramente cuando ha cambiado desde la pasada anterior, con los hash de sesión `added` y `removed`, en caso contrario, solo su recuento y SHA-256. Se conservan el modelo del dispositivo, la plataforma, la aplicación y la versión, la fecha de creación y la última actividad, el país y la región; las direcciones IP no, ya que las exportaciones de pruebas quedan fuera de tu control. La propia sesión del recopilador está activa en todo momento, por lo que solo la actividad de otras sesiones cuenta como un cambio. `verify.py` informa de la frecuencia con la que se ha registrado la lista y de cada sesión nueva y finalizada. Solo lee la lista mientras se ejecuta la observación. Lo que no muestran: drand no demuestra más que el orden de los registros con respecto al tiempo público, y la lista de dispositivos es la declaración de Telegram a través del recopilador, firmada por este al igual que cualquier otro registro. **Registro de Cloudflare Gateway** (`cloudflare.gateway_dns`). Para un servidor que realiza la resolución a través de Cloudflare Gateway ([, Gateway DNS](https://phishdestroy.github.io/TgWitness/es/docs/reference/high-assurance/#cloudflare-as-an-outside-witness)), cada copia incluye lo que Gateway ha registrado desde la copia anterior: un registro por ventana de, como máximo, tres horas con `from`, `until`, `location_id`, el `address` del servidor cuando esté configurado, y el `queries` como `[at, name, type, rcode, decision, colo]`, incluso cuando no haya ninguno. Configurarlo en **. Registro de Cloudflare Gateway**: cuenta, ubicación, dirección opcional y un token de solo lectura (lectura de datos analíticos de la cuenta Analytics Read; Zero Trust PII Read para mantener una dirección de una ubicación compartida). El panel los comprueba mediante una solicitud antes de guardarlos; el token permanece cifrado y nunca entra en el registro. `verify.py` enumera las ventanas, los nombres más buscados y cualquier momento en el que no haya ninguna copia; un registro cuyo recuento no coincida con sus consultas falla. Una ventana que contenga más de una página de consultas en un solo segundo conserva esa página e indica que falta el resto. La copia es la respuesta de Cloudflare a través del colector, firmada por este; en un plazo de 24 horas, cualquier persona con un token de solo lectura puede compararla con Cloudflare. --- # Telegram · Testigo independiente Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reference/witness/ Ejecute un «witness» con su propia clave y bot, publique puntos de control firmados en un canal y compruebe las exportaciones comparándolas con ellos. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Ejecute un «witness» con su propia clave y bot, publique puntos de control firmados en un canal y compruebe las exportaciones comparándolas con ellos. [TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [Documentación](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) · [Pruebas y verificación](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/) ![Pruebas y verificación](https://phishdestroy.github.io/TgWitness/assets/chapter-evidence.svg) [Exportar y verificar](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/) · [Alta fiabilidad](https://phishdestroy.github.io/TgWitness/es/docs/reference/high-assurance/) · [Guía de paneles](https://phishdestroy.github.io/TgWitness/es/docs/reference/panel/#extras) Un testigo conserva los puntos de control firmados por separado del recopilador. Comprueba la firma del recopilador y la continuidad del diario, firma el resultado con su propia clave y lo publica en un canal de Telegram. Ejecútalo en un servidor independiente con acceso de solo lectura al punto final del testigo del recopilador. Diagrama de flujo · Recopilador → Testigo (Punto de control firmado: recuento de registros + hash de cabecera); Testigo → Registro de pruebas, clave propia; Testigo → Canal de Telegram (Publicación firmada a través de su propio bot); Archivo ZIP de pruebas → verify.py; Registro de pruebas, clave propia → verify.py; Canal de Telegram → verify.py (Exportación desde Telegram Desktop o página t.me/s) · Recopilador · Testigo · Registro de pruebas, clavepropia · Canal de Telegram · Archivo ZIP de pruebas · verify.py · Punto de control firmado: · recuento de registros + hash · de cabecera · Publicación firmada a través · de su propio bot · Exportación desde Telegram · Desktop o página t.me/s **Diagrama en formato de texto** 1. Recopilador → Testigo (Punto de control firmado: recuento de registros + hash de cabecera) 2. Testigo → Registro de pruebas, clave propia 3. Testigo → Canal de Telegram (Publicación firmada a través de su propio bot) 4. Archivo ZIP de pruebas → verify.py 5. Registro de pruebas, clave propia → verify.py 6. Canal de Telegram → verify.py (Exportación desde Telegram Desktop o página t.me/s) **En esta página** - [Lo que obtiene el testigo y lo que no](https://phishdestroy.github.io/TgWitness/es/docs/reference/witness/#what-the-witness-gets-and-what-it-does-not) - [Qué comprueba y registra](https://phishdestroy.github.io/TgWitness/es/docs/reference/witness/#what-it-checks-and-records) - [Ejecutar un testigo](https://phishdestroy.github.io/TgWitness/es/docs/reference/witness/#run-a-witness) - [Página de pruebas pública para varios espacios de trabajo](https://phishdestroy.github.io/TgWitness/es/docs/reference/witness/#public-proof-page-for-several-workspaces) - [Verificar](https://phishdestroy.github.io/TgWitness/es/docs/reference/witness/#verify) ## Lo que TgWitness ofrece y lo que no ofrece | El testigo tiene | El testigo nunca tiene | | --- | --- | | Un **token de testigo** de solo lectura para un espacio de trabajo | La sesión de Telegram del recopilador o sus credenciales de la API | | Su propia clave Ed25519 y su propio registro | La bóveda del recopilador, la clave de firma o el token del panel | | Su propio token de bot de Telegram | Contenido del mensaje: el encabezado incluye el recuento de registros y un hash | El token se crea en **Extras → Testigo independiente**, se muestra una sola vez y se almacena únicamente como un SHA-256. Abre exactamente un punto final, `GET /api/witness/head`que devuelve un punto de control recién firmado, además de contadores de colecciones sin contenido firmados y el estado operativo. No puede abrir el panel, leer el contenido de los mensajes ni modificar la configuración, y el token del panel no se acepta allí. Revoca un token en la misma página. El recopilador registra cuándo una nueva clave de testigo comienza a comprobar (`witness.seen`) y muestra la última comprobación por token; un testigo que no haya realizado una comprobación en un plazo de 2,5 intervalos se marca como vencido. Los nuevos testigos envían un desafío aleatorio en cada encuesta; la declaración de captura lo repite bajo la firma del recopilador. Los contadores están vinculados al punto de control exacto y se incluyen en las publicaciones firmadas de los testigos. Los encabezados heredados siguen siendo aceptados por el testigo independiente. El mero crecimiento del registro nunca se cuenta como un nuevo mensaje. ## Qué comprueba y registra Cada intervalo (10 minutos por defecto), TgWitness: 1. recoge el encabezado por sí mismo (el recopilador no puede forzarlo ni omitirlo); 2. Verifica la firma del recopilador, la clave del recopilador fijada (`--collector-fingerprint`, o la primera clave vista), un recuento no decreciente y una cabecera inalterada con un recuento inalterado. Las pruebas de inclusión y consistencia de Merkle verifican que un diario creciente amplíe el punto de control conservado. Una vez que se han utilizado las pruebas de continuidad, se rechaza su eliminación; 3. añade un registro firmado a su propio diario: `witness.anchor` con estado `ok`, `key_changed`, `rollback` (menos registros que antes), `fork` (misma longitud, diferente encabezado) o `invalid` (la respuesta no superó la verificación), o `witness.no_response` cuando el recopilador no respondió; 4. Publica el resultado en el canal, firmado, incluyendo «sin respuesta» mientras TgWitness está en funcionamiento y puede acceder a la API del bot. Se registra el ID de la publicación (`witness.posted`), así como una publicación fallida (`witness.post_failed`). Una entrada tiene este aspecto; la última línea contiene la declaración firmada: ``` TgWitness witness #42 · journal head Collector 3fa9c2d1e0b4a7f6: 18234 records Head 9b1f…c07e 2026-10-28T19:40:00.123+00:00 TGW1.eyJhdCI6…. ``` ## Ejecutar un «witness» Necesitará un bot de Telegram (cree uno con @BotFather), un canal en el que dicho bot sea administrador y la dirección del recopilador accesible desde el testigo —a través de HTTPS fuera de una red privada (consulte el perfil HTTPS en [la sección de implementación](https://phishdestroy.github.io/TgWitness/es/docs/reference/deployment/)). Abre **Extras → Testigo independiente → Configurar** en el panel. Hay tres pasos que abarcan el acceso de solo lectura, tu canal y el intervalo, y, a continuación, el inicio del testigo. La política de publicación, el proxy HTTP/SOCKS5 opcional y la dirección personalizada de la API del bot se encuentran en **la configuración avanzada**. El formulario se descarga `witness.json` con la clave del colector de este espacio de trabajo fijada. Descarga el token de solo lectura recién creado con **«Guardar archivo de acceso** como» `witness-token.txt`; colócalo junto a un `bot-token.txt`creado en el host del testigo junto a ese JSON. El colector nunca recibe el token del bot. La descarga no inicia ningún servicio ni publica ningún mensaje. No se inscribe implícitamente ningún testigo de proyecto alojado . ``` python -m tgwitness.witness run --config witness.json --check-config python -m tgwitness.witness run --config witness.json python -m tgwitness.witness fingerprint --config witness.json ``` El primer comando comprueba los archivos de configuración y los archivos secretos sin realizar solicitudes de red ni crear claves. Las rutas en JSON son relativas a ese archivo; las rutas de la CLI o del entorno son relativas al directorio de trabajo. Conserve la huella digital del testigo fuera de su servidor. El indicador de última consulta del recopilador solo confirma una solicitud; la publicación se notifica mediante Proof o se comprueba en el diario y el canal del testigo. Si el panel se encuentra detrás de un túnel SSH, exponga únicamente el punto final de Witness con ámbito limitado en un nombre de host HTTPS independiente, tal y como se muestra en [este ejemplo de Caddy](https://github.com/phishdestroy/TgWitness/blob/main/deploy/Caddyfile.witness.example). El espacio de trabajo predeterminado utiliza entonces `https://witness.example.org`, mientras que los demás espacios de trabajo utilizan `https://witness.example.org/profiles/ID`. Siguen siendo necesarios los tokens; el panel y sus demás rutas de API no se reenvían a través de ese host virtual. Elija `all` para obtener registros publicados periódicamente. Un intervalo de cinco minutos supone unas 288 entradas por espacio de trabajo al día. `changes` y `problems` omiten deliberadamente la publicación de algunos registros. MTProxy está destinado al cliente de Telegram del recopilador. El sondeo HTTP de Witness y la API HTTPS para bots de Telegram utilizan su propia ruta directa/HTTP/SOCKS5 ([API para bots](https://core.telegram.org/bots/api)). **Junto al colector, con Docker** (mismo host —proceso y clave independientes, pero el mismo operador—): introduzca los valores en «`.env`» e inicie el perfil. ``` TGWITNESS_WITNESS_TOKEN=tgww_... TGWITNESS_WITNESS_BOT_TOKEN=123456:ABC... TGWITNESS_WITNESS_CHANNEL=@your_witness_channel # another workspace: TGWITNESS_WITNESS_COLLECTOR=http://tgwitness:8787/profiles/ docker compose --profile witness up -d docker compose logs witness # prints the witness key fingerprint ``` Si se utiliza una imagen publicada, utilice el código `docker compose --project-directory . -f deploy/compose/compose.image.yaml --profile witness up -d`. **En el servidor de un tercero** (un testigo independiente real): copie allí el repositorio, configure `TGWITNESS_WITNESS_COLLECTOR=https://your-collector.example.org` más los tres valores anteriores en `.env`, y a continuación ``` docker compose --project-directory . -f deploy/compose/compose.witness.yaml up -d ``` o sin Docker: ``` python -m tgwitness.witness run --collector https://your-collector.example.org \ --token-file witness-token.txt --bot-token-file bot-token.txt --channel @your_witness_channel ``` ### Publicar en Discord Un testigo puede publicar en un canal de Discord en lugar de en Telegram. En Discord, abre **«Editar canal» → «Integraciones» → «Webhooks»**, crea un webhook y copia su URL. En el panel, selecciona **«Webhook de Discord · tu canal»** en el paso 2. En el servidor del testigo, guarda la URL como `discord-webhook.txt` junto a `witness.json`; nunca llega al recopilador. ``` python -m tgwitness.witness run --collector https://your-collector.example.org \ --token-file witness-token.txt --discord-webhook-file discord-webhook.txt ``` Un «witness» tiene un único emisor: un canal de Telegram o un webhook de Discord, pero no ambos. Las publicaciones incluyen la misma declaración firmada y no pueden mencionar a nadie. Una publicación que supere los 2.000 caracteres de Discord se sustituye por una línea breve con el registro completo adjunto como `witness-check.txt`. Cada ID de publicación se registra como `witness.posted`. `verify.py --channel`solo lee las exportaciones de los canales de Telegram, por lo que, para Discord, hay que llevar el diario de «witness»: este contiene todas las comprobaciones. ### Opciones | Opción | Entorno | Por defecto | Significado | | --- | --- | --- | --- | | `--interval` | `TGWITNESS_WITNESS_INTERVAL` | 10 | Intervalos entre comprobaciones: de 1 a 1440 | | `--timeout` | `_TIMEOUT` | 30 | Tiempo de espera en segundos para el recopilador y la API del bot: de 5 a 600 | | `--post` | `_POST` | `all` | `all`: todo en orden; `changes`: un nuevo problema; `problems`: solo problemas y respuestas que faltan | | `--title` | `_TITLE` | `TgWitness witness` | Primeras palabras de cada publicación en el canal | | `--collector-fingerprint` | `_COLLECTOR_FINGERPRINT` | – | Fije la clave del recopilador en lugar de confiar en la primera respuesta | | `--proxy` | `_PROXY` | directo | `socks5://host:port` o `http://host:port` | | `--bot-api` | `_BOT_API` | `https://api.telegram.org` | Dirección de la API del bot, por ejemplo, un servidor local de la API del bot | | `--data-dir` | `_DATA` | `witness-data` | Clave de Witness y registro | | `--config` | `_CONFIG` | – | Archivo JSON con cualquiera de las opciones anteriores | La dirección del recopilador, los tokens y el canal proceden de `--collector`, `--token` o `--token-file`, `--bot-token` o `--bot-token-file`, `--discord-webhook-file` y `--channel`, o `_COLLECTOR`, `_TOKEN`, `_TOKEN_FILE`, `_BOT_TOKEN`, `_BOT_TOKEN_FILE`, `_DISCORD_WEBHOOK_FILE` y `_CHANNEL`, lo que mantiene los secretos fuera de la lista de procesos. Un archivo de configuración utiliza los nombres de las opciones con guiones bajos, además de «`texts`», que sustituye las palabras de las publicaciones del canal: ``` {"collector": "https://your-collector.example.org", "token_file": "witness-token.txt", "bot_token_file": "bot-token.txt", "channel": "@your_witness_channel", "interval": 5, "timeout": 30, "post": "changes", "title": "Partner witness", "texts": {"ok": "journal head", "no_response": "no answer from the collector", "records": "records"}} ``` Claves `texts`: `ok`, `key_changed`, `rollback`, `fork`, `invalid`, `no_response`, `collector`, `records`, `head`. La línea de comandos tiene prioridad sobre el entorno, y el entorno sobre el archivo. Las opciones desconocidas o las claves de texto detienen el proceso de registro con un mensaje, en lugar de ser ignoradas. La redacción nunca afecta a la verificación: verify.py comprueba el token firmado al final de cada publicación. Con `--post changes` o `problems`, las comprobaciones que no se han publicado siguen figurando en el diario de testigos y `verify.py` las enumera como nunca publicadas; el registro inicial indica la política. Todas las comprobaciones siguen apareciendo en el diario, por lo que un menor número de publicaciones implica un menor número de momentos independientes de Telegram, no un menor número de comprobaciones. Aunque no haya un canal, TgWitness sigue manteniendo su registro. Guarde la huella digital de la clave de TgWitness (`python -m tgwitness.witness fingerprint`) en otro lugar. ## Página pública de verificación para varios espacios de trabajo `python -m tgwitness.proof` TgWitness admite hasta 32 espacios de trabajo a la vez y ofrece una página de solo lectura con la última comprobación firmada de cada uno. Cada espacio de trabajo tiene su propia clave de testigo y su propio diario en la carpeta «data», así como una clave de recopilador fijada; la publicación en un canal de Telegram es opcional para cada espacio de trabajo. Empieza por [proof.config.example](https://github.com/phishdestroy/TgWitness/blob/main/deploy/proof.config.example): | Campo | Significado | | --- | --- | | `title` | Título de la página, de 1 a 100 caracteres | | `data_dir` | Claves y registros de Witness, relativos al archivo; por defecto `proof-data` | | `interval`, `timeout` | Mínimos entre comprobaciones (1–1440, por defecto 5); segundos de espera (5–600, por defecto 20) | | `workspaces[].id`, `label` | Alias corto en minúsculas y el nombre que se muestra | | `workspaces[].collector` | Dirección del «Collector»; los demás espacios de trabajo terminan en `/profiles/` | | `workspaces[].collector_fingerprint` | Obligatorio, varía según cada espacio de trabajo | | `workspaces[].token_file` | Archivo con el token de testigo de solo lectura de ese espacio de trabajo | | `workspaces[].channel`, `bot_token_file` | Opcional, en conjunto: publicar cada comprobación en un canal | | `workspaces[].proxy`, `bot_api` | Ruta opcional y dirección de la API del bot | ``` python -m tgwitness.proof --config proof.json --check-config python -m tgwitness.proof --config proof.json --host 127.0.0.1 --port 8790 ``` El primer comando valida el archivo y los archivos de tokens sin establecer una conexión. La página solo responde a las solicitudes GET y HEAD: - `/` Muestra todos los espacios de trabajo; un espacio de trabajo que no se haya comprobado durante 2,5 intervalos se marca como obsoleto. - `/api/proof` Devuelve lo mismo que JSON. - `/api/proof/` descarga la última declaración firmada (`tgwitness-public-proof-v1`): número y hash del registro del testigo, estado, clave del recopilador fijada, punto de control, contadores de recopilación y si la publicación en el canal se ha realizado con éxito, firmado por la clave de testigo de ese espacio de trabajo. - `/healthz` Devuelve el código de error 503 cuando el monitor de un espacio de trabajo se ha detenido. Asigna a la página su propio nombre de host, como en [Caddyfile.proof.example](https://github.com/phishdestroy/TgWitness/blob/main/deploy/Caddyfile.proof.example). Para su verificación, exporta el diario de testigos de un espacio de trabajo con `python -m tgwitness.witness export --data-dir proof-data/ --out witness.zip` y utilízalo tal y como se describe a continuación. ## Verificar Desde el punto de vista del testigo, exportar su registro: ``` python -m tgwitness.witness export --out witness.zip # Docker (add -f deploy/compose/compose.witness.yaml on a witness server): docker compose exec witness python -m tgwitness.witness export --out /witness/witness.zip docker compose cp witness:/witness/witness.zip . ``` A continuación, desde cualquier lugar, con el archivo ZIP firmado del recopilador y el canal exportado desde Telegram Desktop (*Exportar historial de chat* → JSON genera `result.json` ) o su página pública `https://t.me/s/…` : ``` python verify.py tgwitness-evidence.zip --fingerprint COLLECTOR_SHA256 \ --witness witness.zip --witness-fingerprint WITNESS_SHA256 --channel result.json ``` `verify.py` comprueba el registro de TgWitness (cadena y firmas) y, a continuación, verifica que **cada «head» que el testigo haya visto forme parte del registro exportado**: el registro en ese recuento debe tener exactamente ese hash. Un «head» que no coincida no supera la verificación —el registro se modificó después de que el testigo lo viera—. Asimismo, informa de los cabezales vistos tras la exportación, las anomalías que el testigo ha registrado, las respuestas que han fallado, los periodos cuyos puntos de control coincidentes están presentes en esta exportación («Testificado de X a Y») y las lagunas. Los puntos de control posteriores no amplían dichos periodos. El resultado incluye el último número de registro coincidente y el número de registros posteriores sin un punto de control coincidente. Solo cuentan las respuestas firmadas con la propia clave de la exportación: una exportación firmada con una clave que el testigo nunca haya visto se notifica como no atestiguada y, sin `--fingerprint`, su firmante permanece sin verificar. Con «`--channel`», cada publicación firmada debe coincidir con el diario del testigo registro por registro: las publicaciones modificadas no superan la verificación y las publicaciones que faltan se enumeran. Una fecha en una exportación JSON de Telegram facilitada es un metadato editable, ajeno al token de testigo firmado. La coincidencia con el token no autentica la fecha de publicación; el resultado indica explícitamente que no se ha realizado la verificación de la hora de publicación. ### Se requiere un límite de exportación con certificación Para un traspaso que deba incluir un registro final certificado, añada `--require-witness`: ``` python verify.py tgwitness-evidence.zip --fingerprint COLLECTOR_SHA256 \ --witness witness.zip --witness-fingerprint WITNESS_SHA256 --require-witness ``` Para ello se requiere la huella digital del testigo conservada de forma independiente y un punto de control coincidente justo al final de esta exportación. Un punto de control que abarque únicamente un prefijo anterior resulta insuficiente. Detenga la recopilación, permita que el testigo observe el estado final y realice la exportación antes de que se produzcan nuevas escrituras en el registro; si el registro cambia, conserve otro punto de control y exporte ese estado. Un punto de control posterior por sí solo no puede verificar el hash final de una exportación más corta. Cuando también se proporciona «`--channel`», la falta de publicaciones declaradas o un conjunto de coincidencias vacío hacen que se falle esta estricta comprobación. Sin el indicador, las comprobaciones de integridad habituales siguen informando de registros sin testificar sin rechazar un archivo que, por lo demás, está intacto. Mantener el diario de testigos y su clave fijada por separado. Las comprobaciones en línea verifican la continuidad entre los puntos de control; la verificación fuera de línea compara cada punto de control conservado con la exportación. Los cabezales heredados sin pruebas de continuidad conservan la comparación fuera de línea y se incluyen en el informe sin la verificación de continuidad en línea. El informe enumera el tiempo de inactividad de los testigos y las publicaciones fallidas por intervalos. ### Sellos diarios y calendarios de marcas de tiempo no disponibles El testigo sella el límite del diario del día anterior (UTC) y envía el hash de ese sello firmado a OpenTimestamps. Un envío al calendario es una prueba pendiente; solo los compromisos de Bitcoin verificados de forma independiente reciben confirmación en el verificador. Si fallan todos los calendarios, el sello firmado y el intento fallido permanecen en el registro. La ronda de mantenimiento horaria vuelve a intentar ese registro original, incluso tras un reinicio o un cambio de fecha. Analiza como máximo 32 sellos, envía como máximo dos envíos pendientes y dedica como máximo 60 segundos a los reintentos por pasada. Un cursor persistente va rotando por los sellos más antiguos. Los envíos retenidos siguen la ruta de actualización de pruebas existente. Un nuevo intento no reescribe el sello, ni cambia su fecha original, ni afirma que el calendario lo haya recibido antes. Un compromiso posterior de Bitcoin sigue siendo una confirmación externa posterior. Las pruebas que faltan siguen siendo `none`; las pruebas pendientes siguen siendo `pending` hasta que el verificador las compruebe de forma independiente. --- # Telegram · Marcas de tiempo Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reference/timestamp/ Marcas de tiempo RFC 3161 para puntos de control firmados: qué se envía a la autoridad y cómo se verifica la respuesta. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Marcas de tiempo RFC 3161 para puntos de control firmados: qué se envía a la autoridad y cómo se verifica la respuesta. [TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [Documentación](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) · [Pruebas y verificación](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/) ![Pruebas y verificación](https://phishdestroy.github.io/TgWitness/assets/chapter-evidence.svg) TgWitness prepara solicitudes conforme a la norma RFC 3161 y verifica las respuestas de la autoridad de sellado de tiempo (TSA). Este procedimiento manual no selecciona una TSA ni envía datos; el modo de pruebas realiza ambas acciones según una programación ([formato de pruebas](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#rfc-3161-preparation-and-response-verification-02)). Una solicitud preparada **aún no** constituye **una prueba de sellado de tiempo**. ## Lo que la prueba acredita Diagrama de flujo · Observaciones sobre la cuenta → Cadena SHA-256 y firmas Ed25519; Cadena SHA-256 y firmas Ed25519 → Punto de control firmado; Punto de control firmado → Hash de bytes exactos y nonce aleatorio; Hash de bytes exactos y nonce aleatorio → Solicitud RFC 3161; Solicitud RFC 3161 → TSA independiente; TSA independiente → Respuesta firmada de la TSA; Punto de control firmado → Verificar los datos, el nonce y la confianza explícita en la CA; Respuesta firmada de la TSA → Verificar los datos, el nonce y la confianza explícita en la CA · Observaciones sobre lacuenta · Cadena SHA-256 yfirmas Ed25519 · Punto de controlfirmado · Hash de bytes exactosy nonce aleatorio · Solicitud RFC 3161 · TSA independiente · Respuesta firmada dela TSA · Verificar los datos,el nonce y laconfianza explícita enla CA **Diagrama en formato de texto** 1. Observaciones sobre la cuenta → Cadena SHA-256 y firmas Ed25519 2. Cadena SHA-256 y firmas Ed25519 → Punto de control firmado 3. Punto de control firmado → Hash de bytes exactos y nonce aleatorio 4. Hash de bytes exactos y nonce aleatorio → Solicitud RFC 3161 5. Solicitud RFC 3161 → TSA independiente 6. TSA independiente → Respuesta firmada de la TSA 7. Punto de control firmado → Verificar los datos, el nonce y la confianza explícita en la CA 8. Respuesta firmada de la TSA → Verificar los datos, el nonce y la confianza explícita en la CA La firma del recopilador vincula los registros a su clave. Una respuesta fiable de la TSA puede confirmar que un punto de control concreto existía en la hora indicada por la TSA. El punto de control puede entonces vincular el prefijo del registro. Esto no establece la hora de cada acción de Telegram ni la veracidad del contenido capturado. ## Procedimiento 1. Conserve la huella digital de la clave del recopilador a través de un canal de confianza independiente. Una clave proporcionada únicamente por el archivo ZIP analizado resulta insuficiente para identificar al recopilador. 2. En **«Exportaciones» → «Preparar solicitud de marca de tiempo»**, descargue el archivo ZIP de solicitud del espacio de trabajo seleccionado. Extraiga los archivos `checkpoint.json`, `timestamp.tsq`, `SHA256SUMS` y `README.txt`. No modifique los bytes de punto de control. 3. Elija una TSA adecuada para la investigación. Envíe `timestamp.tsq` utilizando su método documentado, junto con `application/timestamp-query` para un servicio HTTP. Guarde la respuesta binaria original como `timestamp.tsr`, junto con el punto final, la hora de recuperación y el resultado de la solicitud. La solicitud contiene un hash y un nonce en lugar de mensajes; los metadatos de red siguen revelando la solicitud. 4. Obtenga el certificado raíz de confianza independientemente de la respuesta, además de cualquier certificado intermedio que sea necesario. Un certificado incluido en la respuesta no se considera de confianza simplemente por el hecho de estar incluido en ella. 5. Desde una instalación fiable de TgWitness, compruebe lo siguiente: ``` python -m tgwitness.anchor verify --checkpoint checkpoint.json --request timestamp.tsq --response timestamp.tsr --ca trusted-tsa-root.pem ``` Añada «`--intermediates tsa-intermediates.pem`» o «`--openssl /path/to/openssl`» si es necesario. OpenSSL debe ser compatible con «`ts`». En Windows, el verificador también busca en la instalación estándar de Git. Se ha probado OpenSSL 3.5.9 localmente con una CA/TSA sintética. 1. Exporte un archivo ZIP del registro firmado tras el punto de control, de modo que incluya dicho prefijo. Verifique utilizando la huella digital conocida de forma independiente: ``` python tgwitness/verify.py evidence.zip --fingerprint TRUSTED_SHA256 --checkpoint checkpoint.json ``` 1. Conserve el archivo ZIP, el punto de control, la solicitud, la respuesta, la cadena de certificados, los resultados de la verificación y el registro de traspaso fuera del colector. Repita la verificación en el momento de la recepción. Para preparar una solicitud a partir de un punto de control guardado: ``` python -m tgwitness.anchor prepare checkpoint.json --out timestamp-request.zip ``` La preparación normaliza el formato JSON e incluye el punto de control correspondiente en el archivo. Utilice los **bytes del punto de control de dicho archivo** para la verificación TSA, incluso si el archivo de entrada presentaba espacios en blanco diferentes. ## Límites de la verificación | Comprobar | Comportamiento actual | | --- | --- | | Datos | El SHA-256 de los bytes exactos del punto de control debe coincidir con la respuesta. | | Solicitud | Con `--request`, se verifican la consulta original y el nonce. | | Firma de la TSA | OpenSSL verifica la firma y la cadena de certificación hasta la CA explícita. | | Firma del recopilador | Verificado de forma independiente por el verificador del registro mediante una clave fijada. | | Revocación | No se realiza la recuperación automática de OCSP/CRL | | Validez a largo plazo | No se realiza validación de los archivos tras la caducidad del certificado | | Envío programado | Modo de pruebas, desactivado por defecto | `--request` es técnicamente opcional, pero si se omite, no se podrá verificar el nonce original. Para que este procedimiento sea completo, el resultado `request_checked` debe ser verdadero. La verificación del certificado se rige por las normas y los plazos de verificación de OpenSSL instalados. La conservación a largo plazo requiere una política independiente de certificados y pruebas de revocación. Una firma criptográfica válida no constituye automáticamente una marca de tiempo cualificada ni una determinación de admisibilidad legal. Si un operador falsificara las observaciones antes de aplicar la marca de tiempo, la TSA fijaría esos bytes; no establecería su veracidad. ## Registro de traspaso Registre el identificador del caso, el remitente y el destinatario, la hora de transferencia en UTC y su origen, la finalidad, los nombres de archivo y los valores SHA-256, la huella digital del recopilador, el rango de secuencia, las lagunas conocidas, la versión del verificador y el resultado de la verificación. Firme y conserve de forma independiente este registro siguiendo el proceso de su organización. TgWitness no cuenta con un sistema de registro de custodia multiusuario. Durante el desarrollo no se contactó con ninguna TSA independiente en tiempo real. Las pruebas locales crean una CA/TSA sintética para comprobar la compatibilidad y el rechazo de datos modificados, nonces o CA. --- # Telegram · Almacenamiento y recuperación Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reference/storage/ Copias de seguridad, traslado de archivos antiguos a tu nube, copias bajo Object Lock y recuperación en un nuevo equipo. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Copias de seguridad, traslado de archivos antiguos a tu nube, copias bajo Object Lock y recuperación en un nuevo equipo. [TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [Documentación](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) · [Implementación y recuperación](https://phishdestroy.github.io/TgWitness/es/docs/reference/deployment/) ![Implementación y recuperación](https://phishdestroy.github.io/TgWitness/assets/chapter-operate.svg) El panel distingue tres tareas: | Tarea | Qué hace | | --- | --- | | Haz una copia de seguridad | Copia el registro firmado, los puntos de control, los archivos conservados y las exportaciones en cola al destino S3 configurado. | | Espacio local gratuito | Copia los archivos adjuntos antiguos seleccionados a S3 o a un servidor remoto en la nube de rclone, vuelve a leerlos íntegramente, verifica los bytes cifrados y, a continuación, elimina la copia local verificada. | | Conserva una copia como prueba | Configura S3 Object Lock y comprueba el estado de retención devuelto. El servicio debe confirmar el modo y la fecha solicitados. | Al liberar espacio nunca se borra ni se sobrescribe el registro firmado. Cada archivo adjunto conserva su SHA-256 original y un recibo de recuperación. La compresión gzip opcional se lleva a cabo antes del cifrado autenticado. Los nombres de los archivos en la nube no contienen nombres de Telegram, ID de chat ni nombres originales de los archivos adjuntos. Un archivo adjunto puede tener un tamaño de hasta 32 GiB. Una respuesta de subida por sí sola no supone permiso para eliminar un archivo. TgWitness descarga el objeto cifrado completo y verifica su tamaño; SHA-256 guarda el recibo y, a continuación, vuelve a comprobar los bytes locales inmediatamente antes de la eliminación. Un error en la subida, una lectura diferente o una transferencia cancelada hacen que el archivo local permanezca en su sitio. Si una copia de seguridad de pruebas habilitada aún no ha copiado ese archivo, la eliminación también espera a que lo haga. **En esta página** - [Cuando el disco se está llenando](https://phishdestroy.github.io/TgWitness/es/docs/reference/storage/#when-the-disk-is-filling-up) - [Conectar un destino](https://phishdestroy.github.io/TgWitness/es/docs/reference/storage/#connect-a-destination) - [Conservar el archivo de recuperación](https://phishdestroy.github.io/TgWitness/es/docs/reference/storage/#keep-the-recovery-file) - [Recuperación tras la pérdida de la instalación](https://phishdestroy.github.io/TgWitness/es/docs/reference/storage/#recover-after-losing-the-installation) - [Bot de operador y avisos de finalización](https://phishdestroy.github.io/TgWitness/es/docs/reference/storage/#operator-bot-and-completion-notices) ## Cuando el disco se está llenando La descarga de adjuntos se pausa por debajo del espacio indicado en **Parámetros → Adjuntos → espacio libre en disco** (1 GiB por defecto), conservando la cola. Las observaciones de texto continúan. Esto es independiente de las notificaciones: desactivarlas no elimina la reserva de descarga ni las protecciones del almacenamiento. Para intervenir antes, activa **Ejecutar automáticamente**, elige **Eliminar el archivo local para liberar espacio** y activa **Iniciar una descarga adicional al almacenamiento externo cuando quede poco espacio**. Por defecto, esta regla opcional se inicia con menos de 5120 MiB libres y continúa por lotes hasta alcanzar 10240 MiB. Ambos umbrales son configurables. Usa el mismo destino, antigüedad mínima, límite de lote, verificación mediante lectura completa y requisitos de copia de seguridad de pruebas que una ejecución manual. Nunca habilita un destino por sí sola. Comprueba el espacio cada 30 segundos; un error o la falta de progreso retrasa el siguiente intento cinco minutos. El estado y la hora del reintento sobreviven a los reinicios. Cuando la regla está inactiva, las ejecuciones programadas mantienen su intervalo normal. El panel muestra el espacio libre, la reserva de empaquetado, si la regla está preparada y los archivos omitidos por falta de espacio temporal. El empaquetado y la restauración comprueban su necesidad máxima de espacio temporal antes de empezar y el espacio disponible durante la escritura. La reserva es la configurada para descargas, con un mínimo de 64 MiB para operaciones de almacenamiento. No es una cuota del sistema de archivos: otro proceso puede consumir espacio entre comprobaciones. La compresión Gzip es sin pérdida y se aplica a objetos remotos; no reduce el diario activo ni crea archivos comprimidos locales. Los JPEG, vídeos y ZIP pueden reducirse muy poco o crecer ligeramente. Con compresión, el empaquetado puede necesitar temporalmente aproximadamente el doble del tamaño del adjunto más la reserva. Elige un umbral suficientemente temprano para los archivos más grandes. Los archivos demasiado grandes se conservan y se notifican; los menores y las copias remotas ya verificadas aún pueden liberar espacio. Una copia verificada permite retirar el archivo local sin crear otro archivo de empaquetado. La restauración también necesita espacio temporal y puede rechazarse hasta que esté disponible. Si no hay archivos aptos para trasladar o no se ha configurado un destino, TgWitness no puede recuperar espacio automáticamente. La gestión del almacenamiento nunca recorta ni reescribe el diario firmado. Este sigue necesitando espacio para nuevas observaciones de texto. ## Conectar un destino En **Extras → Almacenamiento y espacio en disco → Gestionar almacenamiento**, elige la tarea y el destino, guárdala y, a continuación, selecciona **Probar subida y descarga**. La prueba sube una pequeña prueba aleatoria y la lee de nuevo. No utiliza contenido de Telegram. Para S3, utiliza el punto final, la región y el bucket reales del proveedor. Wasabi, Backblaze, Cloudflare R2 y otros servicios compatibles utilizan la misma configuración de S3. El hecho de que una API sea compatible no implica por sí solo que admita Object Lock. El modo «Governance» puede permitir que un administrador autorizado eluda la retención; el modo «Compliance» tiene diferentes restricciones. Consulta el estado de Object Lock devuelto antes de basarte en la retención. Para un destino de rclone, crea un remoto utilizando la configuración del proveedor de rclone y pega la sección `[name]` en el panel. El asistente instalado es compatible con MEGA, Google Drive, OneDrive, Dropbox, Box, pCloud y los demás proveedores que aparecen en el selector. Las credenciales se guardan en la caja fuerte cifrada de este espacio de trabajo. Las actualizaciones de OAuth se guardan de nuevo en la caja fuerte. Las credenciales no se añaden a los eventos del registro ni se incluyen en las descargas de recuperación. El ayudante se instala dentro del espacio de trabajo, con una versión anclada y SHA-256. No se añade a la ruta PATH del sistema. Los archivos de configuración y los archivos de trabajo son archivos temporales dentro de ese espacio de trabajo. Se rechazan los remotos basados en comandos y en archivos locales. Actualmente, rclone requiere una ruta **Direct** seleccionada explícitamente para las solicitudes externas. Utiliza el almacenamiento S3 nativo para una ruta SOCKS5 o HTTP del espacio de trabajo; rclone no omite silenciosamente una ruta no disponible. ## Guarda el archivo de recuperación Selecciona **«Guardar archivo de recuperación»** después de copiar los archivos y guárdalo en un lugar distinto al de la instalación. Contiene la clave de descifrado y los recibos firmados de los objetos, por lo que debes tratarlo como una copia de seguridad de la clave privada. Guarda también por separado la configuración remota original y las credenciales de destino. Un archivo de recuperación creado antes de una copia posterior no contiene el recibo de ese archivo posterior. La huella digital de la clave de firma ya debería estar registrada por separado. Una firma que solo se compruebe con la clave proporcionada en el mismo archivo no permite determinar de quién es el archivo de recuperación. Para recuperar los recibos de almacenamiento que faltan en un espacio de trabajo existente, abre **«Recuperar archivos desde un archivo de recuperación guardado**» y selecciona el archivo. El panel comprueba la firma y requiere la misma clave de firma del espacio de trabajo. No permite sustituir una clave de almacenamiento diferente. A continuación, selecciona **«Restaurar todos los archivos**». La restauración pausa la regla de almacenamiento automático para que la siguiente ejecución programada no pueda volver a eliminar inmediatamente los archivos restaurados. Vuelve a activar la regla cuando hayas terminado con las copias locales. La restauración verifica el texto cifrado, autentica el descifrado, descomprime si es necesario y comprueba el texto en claro original SHA-256 antes de colocar un archivo en `media/`. Un objeto remoto dañado nunca sustituye a un archivo local. Un archivo local existente con bytes diferentes se conserva para su revisión en lugar de sobrescribirse. ## Recuperación tras la pérdida de la instalación Instala TgWitness en otro equipo. Utiliza el archivo de recuperación privado, la huella digital registrada por separado y las credenciales de destino originales: ``` python -m tgwitness.storage recover \ --recovery storage-recovery.json \ --fingerprint TRUSTED_WORKSPACE_SHA256 \ --credentials original-rclone.conf \ --output recovered-attachments ``` Para S3, `--credentials` apunta a un archivo JSON privado con `access_key` y `secret_key`; el archivo de recuperación firmado proporciona la configuración de destino. El comando utiliza una conexión externa directa y descarga el programa auxiliar anclado cuando un remoto de rclone lo necesita. Rechaza un directorio de salida ya existente. Los bytes originales recuperados se escriben en `recovered-attachments/media/`, con el nombre de su SHA-256. `recovery-log.jsonl` es un registro sin firmar de las operaciones de recuperación. El comando no recrea un diario firmado perdido ni su clave de firma. Mantén una copia de seguridad completa del espacio de trabajo para esos casos. Un archivo de recuperación de almacenamiento no es una copia de seguridad completa del espacio de trabajo . ## Bot de operador y notificaciones de finalización El bot de Telegram pertenece al operador. Créalo a través de BotFather y configure su token, el chat de destino y los ID de usuario de Telegram explícitamente permitidos en el panel. Tanto el remitente como el chat deben coincidir. Se ignoran los mensajes reenviados y los comandos procedentes de otros bots. `/status` y `/stats` están disponibles en el modo predeterminado «solo estado». El modo de control opcional añade `/pause`, `/resume` y `/copy`. `/copy` solicita la tarea de almacenamiento configurada; esto no significa que la subida remota ya haya finalizado. Los comandos no pueden proporcionar URL, archivos o programas de shell arbitrarios. Utiliza los ajustes de notificación independientes para las alertas y la finalización de tareas. Los avisos de finalización distinguen una exportación de cuenta con lagunas de una exportación completa, y muestran el historial y el recuento de almacenamiento. Los extractos de mensajes no se incluyen a menos que se active por separado en los ajustes de notificación. El selector de servicios se genera a partir del catálogo real de Apprise instalado, en lugar de un conjunto fijo de ejemplos de proveedores. --- # Telegram · Seguridad y tratamiento de datos Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reference/security/ Modelo de amenazas, modelo de acceso, información confidencial en reposo, exposición de la red, importación de sesiones y cómo notificar una vulnerabilidad. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Modelo de amenazas, modelo de acceso, información confidencial en reposo, exposición de la red, importación de sesiones y cómo notificar una vulnerabilidad. [TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [Documentación](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) · [Implementación y recuperación](https://phishdestroy.github.io/TgWitness/es/docs/reference/deployment/) ![Implementación y recuperación](https://phishdestroy.github.io/TgWitness/assets/chapter-operate.svg) Esta página describe el acceso, el almacenamiento y la protección de la red en un espacio de trabajo local o en un servidor. Para la recopilación en un GitHub Runner o en una máquina virtual confidencial de Intel TDX, consulta los modos de [verificación](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/#verification-scope), que añaden comprobaciones del entorno de recopilación. Las conexiones de cuentas, las notificaciones, las marcas de tiempo, las copias externas y los testigos tienen su propia configuración de enrutamiento. | Área | En resumen | | --- | --- | | Acceso | Clave de administrador más acceso limitado a cuentas y chats, siete permisos y sesiones revocables; localhost por defecto. | | Secretos en reposo | La sesión, el par de API, la clave de firma y la configuración del proxy se cifran con Fernet | | Mensajes y archivos multimedia | Se almacena sin cifrar: utilice el cifrado de disco y permisos estrictos | | Integridad | Cadena de hash SHA-256 y una firma Ed25519 en cada registro | | Límite de confianza local | El administrador del servidor controla el espacio de trabajo y su clave de firma; los puntos de control independientes conservan un límite de registro anterior. | Para informar sobre vulnerabilidades, consulte la [política de seguridad](https://github.com/phishdestroy/TgWitness/blob/main/.github/SECURITY.md). **En esta página** - [Modelo de acceso](https://phishdestroy.github.io/TgWitness/es/docs/reference/security/#access-model) - [Contenido del panel y exportaciones](https://phishdestroy.github.io/TgWitness/es/docs/reference/security/#panel-content-and-exports) - [Secretos en reposo](https://phishdestroy.github.io/TgWitness/es/docs/reference/security/#secrets-at-rest) - [Proxies y rutas de red](https://phishdestroy.github.io/TgWitness/es/docs/reference/security/#proxies-and-network-routes) - [Inicio de sesión e importación de sesiones](https://phishdestroy.github.io/TgWitness/es/docs/reference/security/#sign-in-and-session-imports) - [Registros y transporte](https://phishdestroy.github.io/TgWitness/es/docs/reference/security/#logs-and-transport) - [Límites de integridad](https://phishdestroy.github.io/TgWitness/es/docs/reference/security/#integrity-limits) - [Si sospechas que hay un problema](https://phishdestroy.github.io/TgWitness/es/docs/reference/security/#if-you-suspect-a-problem) ## Modelo de acceso El token del panel principal otorga control total. Otras personas pueden recibir su propio [acceso limitado](https://phishdestroy.github.io/TgWitness/es/docs/reference/access/): espacios de trabajo y chats seleccionados, permisos, caducidad, restricciones de IP, límites de inicio de sesión y sesiones revocables. Un acceso limitado a un chat no puede realizar operaciones en todo el espacio de trabajo, aunque se haya marcado su permiso. Los espacios de trabajo comparten un proceso y no aíslan los datos del administrador del servidor. El panel escucha en localhost de forma predeterminada. Al iniciar sesión desde el navegador, se intercambia un token de acceso por una credencial de sesión; el navegador lo envía como un token de portador. Se almacena en sessionStorage en lugar de en una cookie de autenticación. Al bloquear la sesión o cerrarla, se borra la sesión del navegador. Cerrar el navegador o finalizar una sesión no detiene la recopilación. Los tokens emitidos y las credenciales de sesión se almacenan como hash en la bóveda cifrada. La revocación pone fin a las sesiones asociadas; los cambios en los permisos afectan a las solicitudes posteriores. Los archivos descargados no pueden recuperarse. El administrador también puede limitar sus propias sesiones de navegador, pero los scripts que utilizan directamente el token del panel principal conservan acceso completo y eluden dichos límites de sesión del navegador. Los intentos fallidos de autenticación están limitados por la dirección del cliente. Las restricciones de IP utilizan la dirección que ve la aplicación; compruebe el comportamiento del proxy inverso antes de basarse en él. Las credenciales de Witness siguen siendo credenciales independientes de solo lectura para el control de estado y el punto de control. ### Acceso a la demostración `/api/demo-access` es un bootstrap deliberadamente no autenticado para una demostración sintética aislada e iniciada explícitamente. Emite una capacidad independiente válida durante la vida útil del proceso, nunca el token real del panel ni una sustitución de TGWITNESS_TOKEN. Su emisión y uso requieren un par de bucle de retorno y un host, sin encabezados reenviados ni solicitudes de origen cruzado. Los espacios de trabajo adicionales o una sesión autorizada desactivan esta vía. Los espacios de trabajo activos nunca emiten dicha capacidad. La demostración no puede vincular cuentas ni modificar la configuración de recopilación. ## Contenido de los paneles y exportaciones El panel no utiliza fuentes externas, herramientas de análisis, recursos CDN ni medios remotos incrustados. El texto procedente de Telegram se inserta como texto, no como HTML. Los archivos adjuntos descargados se sirven como archivos adjuntos binarios. Las exportaciones en formato JSONL conservan las cadenas originales; el HTML las escapa; a las celdas CSV que podrían convertirse en fórmulas se les antepone un apóstrofo. Las exportaciones excluyen los secretos de autenticación y firma, pero contienen deliberadamente metadatos de origen recopilados, identificadores y, posiblemente, contenido personal o sensible. En los metadatos de origen sin procesar pueden aparecer hash de acceso a Telegram y referencias a archivos. ## Secretos en reposo Las credenciales de la API de Telegram, la sesión y la clave de firma se cifran con Fernet. En el caso de los mensajes y archivos multimedia locales, el cifrado lo proporciona el disco o volumen del host; el espacio de trabajo almacena archivos normales. Las exportaciones pueden utilizar un ZIP AES-256 protegido con contraseña, y las copias externas utilizan AES-256-GCM. La clave de la bóveda se establece por defecto en el directorio de datos protegidos. Utiliza un archivo externo de clave maestra como se indica a continuación para almacenarla por separado. En Unix, los nuevos archivos de clave privada utilizan el modo 0600 y los nuevos directorios de datos utilizan el modo 0700; en Windows, configura la lista de control de acceso (ACL) del directorio para la cuenta de servicio y los administradores autorizados. Se conservan los permisos existentes del directorio. ### Clave maestra externa Para un nuevo directorio de datos, TGWITNESS_VAULT_KEY_FILE puede proporcionar una clave maestra aleatoria externa. HKDF-SHA256 y una sal aleatoria independiente derivan una clave Fernet diferente para cada espacio de trabajo. Se debe conservar el archivo vault.external.json para la recuperación. Si faltan o las claves maestras son incorrectas, el sistema no se inicia. Las bóvedas locales existentes no se migran de forma silenciosa. El panel muestra el modo de almacenamiento de claves seleccionado. El cifrado de disco protege los archivos de mensajes y multimedia locales en cualquiera de los dos modos; consulte « [conexión» y «protección de datos](https://phishdestroy.github.io/TgWitness/es/docs/reference/connection/)» para obtener detalles sobre la configuración. ## Proxies y rutas de red La configuración del proxy se cifra en el almacén de datos. Las contraseñas y los secretos de MTProxy no se devuelven a través de la API ni se registran en los registros de pruebas. Cada espacio de trabajo elige su ruta de Telegram y un [modo de IP](https://phishdestroy.github.io/TgWitness/es/docs/reference/connection/#ip-modes). **La opción «Ocultar la dirección»** desactiva el acceso directo a Telegram y requiere un proxy para las solicitudes HTTP externas. El modo de acceso alternativo seleccionado explícitamente permite el acceso directo a Telegram tras un retraso; el modo túnel/VPN permite rutas directas. Al elegir el modo túnel no se instala ni se verifica ninguna VPN. Esta configuración no controla todo el tráfico del equipo, ni los navegadores, ni los gestores de paquetes, ni la resolución de DNS del proxy local. MTProxy solo transmite tráfico de Telegram. Las solicitudes externas pueden utilizar un proxy SOCKS5/HTTP independiente, la ruta SOCKS5/HTTP del espacio de trabajo o una ruta directa autorizada; también pueden desactivarse. El testigo independiente cuenta con su propia configuración de transporte. La autenticación CONNECT habitual de SOCKS5/HTTP no está cifrada por dichos protocolos de proxy en sí mismos. Los secretos TLS falsos de MTProxy siguen sin ser compatibles. ## Inicio de sesión e importación de sesiones Los archivos .tgwitness-session convertidos contienen un secreto de autorización en texto plano hasta que se cargan y se almacenan en la bóveda. La interfaz de línea de comandos (CLI) sin conexión acepta esquemas de Telethon revisados. Además, la importación a través del panel admite Pyrogram SQLite, el moderno formato ZIP de TData para una sola cuenta, y entradas JSON documentadas. Está autenticada, limitada a cuatro archivos / 8 MiB, y procesa las subidas en memoria sin necesidad de extraer el archivo ni guardar los archivos originales. Las credenciales normalizadas solo se devuelven al navegador autenticado que las solicita; se guardan en el almacén cifrado tras una autorización satisfactoria en Telegram. Proteja los archivos originales y los convertidos, y evite que clientes simultáneos clonen una autorización. El procesamiento de datos verifica las sumas de comprobación de los contenedores, los hash de descifrado locales y las longitudes de las estructuras. Se utiliza de forma temporal una contraseña local de la versión de escritorio facilitada, que no se almacena. Este analizador limitado no garantiza que todas las versiones de escritorio sean compatibles. Las imágenes QR se generan localmente, contienen tokens de inicio de sesión de Telegram de corta duración y nunca se envían a un servicio de renderización externo. El bloqueo, el cambio de espacio de trabajo, un nuevo inicio de sesión y los cambios de ruta cancelan los intentos de QR pendientes. Al recargar o cerrar una pestaña, puede quedar un intento pendiente hasta su caducidad. Un inicio de sesión mediante QR satisfactorio sigue exigiendo la vinculación de la cuenta. Los cuerpos de la API ordinarios siguen estando limitados a 16 KiB; la ruta de importación autenticada acepta hasta 12 MiB de JSON codificado, aplicando por separado el límite más reducido para el archivo decodificado. Los códigos de inicio de sesión y las contraseñas de verificación en dos pasos de Telegram no se almacenan de forma permanente. El estado del número de teléfono o del hash del código se mantiene en memoria durante la autorización. Las sesiones de Telegram otorgan acceso a la cuenta; nunca suba un directorio de datos, una sesión, un token, una clave de almacén o una clave de firma privada a GitHub. ## Registros y transporte Se sustituye la respuesta predeterminada de validación de la API para que no repita los valores de las credenciales. Se desactiva el registro de acceso a la aplicación. No configure un proxy inverso para registrar encabezados de autorización ni cuerpos de solicitud. El protocolo HTTP transmite tokens y contraseñas de inicio de sesión en texto sin cifrar: utilice HTTPS o un túnel SSH siempre que salga de localhost. ## Límites de integridad Las comprobaciones de verificación local verifican las firmas de los registros, la cadena de hash, los archivos adjuntos y el manifiesto de exportación. El administrador posee la clave de firma local y puede crear otro diario firmado; un punto de control conservado de forma independiente detecta la sustitución del prefijo que cubre. Conserva la huella digital de la clave y los puntos de control con el destinatario o con un testigo independiente. Para una recopilación verificada de forma independiente, elige [Captura de GitHub Actions](https://github.com/phishdestroy/TgWitness/blob/main/docs/SEALED-ACTIONS.md) o [Implementación de Intel TDX](https://phishdestroy.github.io/TgWitness/es/docs/reference/high-assurance/#confidential-vm-on-phala-cloud-intel-tdx). Sus verificadores comprueban la procedencia del flujo de trabajo o las mediciones de hardware, además de la integridad del archivo. Las marcas de tiempo opcionales y las copias cifradas externas proporcionan puntos de referencia temporales y copias recuperables; el formato de pruebas describe las comprobaciones para cada modo. ## Si sospecha que hay algún problema Conservar el directorio de datos original y utilizar una copia independiente para el análisis. Informar de la versión afectada, la operación y los pasos reproducibles a través de la [política de seguridad](https://github.com/phishdestroy/TgWitness/blob/main/.github/SECURITY.md), manteniendo la privacidad de los datos de la cuenta y las credenciales. --- # Arquitectura Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reference/architecture/ Componentes del colector, el panel, el registro, los trabajadores y el testigo, y cómo se transfieren los datos entre ellos. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Componentes del colector, el panel, el registro, los trabajadores y el testigo, y cómo se transfieren los datos entre ellos. [TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [Documentación](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) ![Desarrollo](https://phishdestroy.github.io/TgWitness/assets/chapter-develop.svg) Un proceso de Python aloja el panel de FastAPI y un número ilimitado de espacios de trabajo aislados, cada uno con un cliente de cuenta de usuario de Telegram. SQLite almacena un registro de eventos firmado de solo adición y una configuración operativa modificable. Una bóveda cifrada almacena las credenciales de la API, la StringSession y la clave de firma. La interfaz de usuario es un paquete sencillo de HTML/CSS/JavaScript: no se requiere compilación con Node, CDN ni descargas de la interfaz de usuario en tiempo de ejecución. Optional browser and AyuGram recorders run in **separate processes or containers**. The `tgwitness_capture` package owns their event format, keys, artifacts, checkpoint API, independent witness and standalone verifier. It is bundled in the main wheel and can also be installed alone from `addons/capture`, without importing the collector. The main panel's `capture_api.py` and `capture_connections.py` provide administrator-only, workspace-scoped controls under `/api/capture`; connection tokens live in the encrypted vault. No recorder or outbound request starts with the main process. Each explicit command verifies a fresh challenge against the pinned recorder key. Exports are verified before download and keep their original signature; they do not become Telegram message events. Collection sessions and proxy routes stay with each client. See the English [Independent capture guide](https://github.com/phishdestroy/TgWitness/blob/main/docs/OPTIONAL-CAPTURE.md) for deployment and trust boundaries. | Módulo | Responsabilidad | | --- | --- | | collector.py | Autorización, selección de diálogos, actualizaciones, instantáneas, cola de archivos multimedia, supervisión de la conexión | | interactions.py / telegram_client.py | Acciones explícitas de los paneles, recibos firmados, identificadores de solicitud persistentes y política de reintentos de llamada de retorno o reincorporación a la tarea a nivel local. | | message_content.py | Comparación observable de mensajes, excluyendo los metadatos de acceso de transporte | | workers.py | Espere a que finalicen los procesos de exportación de archivos antes de proceder a la limpieza tras la cancelación | | distributed_export.py / distributed_pages.py | Tareas de chat simultáneas, reservas por cuenta, puntos de control firmados y limpieza tras la verificación del archivo. | | distributed_takeout.py / export_timing.py | Sesiones de Takeout reanudables y tiempos correspondientes a cada inicio o reanudación | | store.py | Transacciones WAL, cadena de eventos ordenada, filtros de consulta, ajustes operativos | | fulltext.py | Índice de texto completo derivado (formas de palabras, BM25), vinculado al encabezado del diario firmado; nunca se exporta. | | security.py | Creación de archivos privados, almacén cifrado, firma Ed25519, bloqueo de un único proceso | | evidence.py | Exportación del registro completo, derivados, puntos de control y verificación de archivos adjuntos | | verify.py | Verificador independiente y de solo lectura (biblioteca estándar + criptografía): archivos, cobertura, registros de testigos y publicaciones en canales, archivos de perfil | | app.py | API autenticada, ciclo de vida, validación de solicitudes, panel estático | | profiles.py | Recopiladores de cuentas múltiples, controlador de acceso compartido, ciclo de vida por espacio de trabajo | | access.py | Concesiones de acceso, comprobaciones de permisos, restricciones de IP, límites de sesión y consola de administrador | | proxy_catalog.py | Instantáneas de los canales públicos, comprobaciones de transporte, conjunto de proxies compartidos y selección basada en el estado de funcionamiento | | provenance.py | Mediciones firmadas de identidad, código y dependencias en el ciclo de adquisición | | network.py | Rutas validadas por espacio de trabajo; estado y pruebas censurados; opciones de transporte de Telethon | | sessions.py | Conversión sin conexión y de solo lectura de los esquemas SQLite revisados de Telethon | | account_import.py | Detección y normalización en memoria de los archivos de cuentas compatibles y de los archivos JSON | | tdata.py | Lector ZIP TData moderno y limitado, validación de sumas de comprobación y descifrado, sin extracción. | | doctor.py | Comprobaciones de disponibilidad local sin recopilación de datos, inicio de sesión ni instalación de paquetes | | download.py | Descarga de exportación en tiempo real autenticada, con lecturas limitadas y sin sobrescrituras. | | monitoring.py | Política de eventos validada por espacio de trabajo y reglas de archivos adjuntos por tipo, compartidas por los gestores, el estado y los recibos firmados. | | scope.py | Ámbito de observación (chats seleccionados, carpeta de Telegram, cuenta completa), tipos de fuentes, exclusiones y niveles de revisión | | dossier.py | Perfiles de usuarios por chat elaborados a partir de registros guardados: datos con referencias de registro, SHA-256/pHash del avatar y extracción de menciones. | | witness_api.py | Tokens de testigo de solo lectura y el encabezado firmado del registro que pueden obtener | | witness.py | Proceso de testimonio independiente: clave y registro propios, comprobaciones de autenticidad, publicaciones firmadas en el canal, exportación | | alerts.py | Notificaciones de Apprise y la lista de notificaciones del panel | | logging_config.py | Registro en consola y diagnóstico rotativo del servidor para ejecuciones sin ventana. | | static/ | Interfaz adaptativa, puerta de acceso local, filtros, detalles, exportaciones y configuración de la cuenta. | | demo.py | Registro sintético claramente identificado, aislado de la recopilación real. | Los gestores de observación se registran antes de la conexión. La recopilación en tiempo real está condicionada por la identidad del cliente activo, el estado de ejecución explícito, las fuentes habilitadas o el ámbito de observación (los modos de carpeta o de cuenta completa añaden un nuevo chat como fuente en su primera actualización), y la política de eventos. Los clientes rechazados o sustituidos no pueden aportar actualizaciones en tiempo real. Las reacciones sin procesar y las actualizaciones de membresía mantienen los límites de visibilidad. El contenido del mensaje entrante y su tarea de soporte duradero se registran conjuntamente. Las tareas conservan el descriptor TL original y vinculan su hash a la observación del mensaje firmado. Se separan las semánticas de remitente, editor y eliminador. Cada espacio de trabajo admite una cuenta y cuenta con su propio directorio e identidad de firma. El espacio de trabajo principal permanece en la raíz por motivos de compatibilidad; los espacios de trabajo adicionales se encuentran en profiles//. Un único token de portador controla toda la instalación; los espacios de trabajo no son entidades de autorización independientes. Los bloqueos de procesos protegen los directorios; los bloqueos de la base de datos serializan la inserción de eventos. Cada adición se confirma de forma sincrónica en el WAL de SQLite con el modo sincrónico FULL. Los controladores de actualización/eliminación de eventos impiden las modificaciones habituales de la aplicación; los administradores del sistema de archivos permanecen dentro del límite de confianza. La autorización de la API se realiza mediante un token de portador. Las operaciones de inicio de sesión se serializan y tienen un límite de tiempo. Las subidas de cuentas utilizan un límite dedicado de 12 MiB para el cuerpo codificado y un límite de 8 MiB para el archivo decodificado; las solicitudes normales de la API mantienen el límite de 16 KiB. La conversión se ejecuta en un hilo de trabajo, mantiene las subidas en memoria y devuelve la entrada normalizada al navegador autenticado. El inicio de sesión mediante código QR cuenta con un candidato por espacio de trabajo, un identificador de corta duración, una tarea de espera y una cancelación explícita. Solo la autorización aceptada se convierte en el cliente activo. Telegram FloodWait se devuelve con un valor Retry-After; las credenciales y los mensajes de error RPC sin procesar no se exponen en los errores de la API. Las exportaciones de diario se ejecutan fuera del bucle de eventos asíncrono y se serializan por espacio de trabajo. Transmiten una instantánea de lectura estable al mismo tiempo que continúan las escrituras en el WAL. Las tareas de adquisición de chats pueden ejecutarse simultáneamente en cuentas distintas; cada cuenta permanece reservada hasta que su tarea finaliza. Una tarea en pausa o que ha fallado conserva sus puntos de control. La verificación satisfactoria del archivo permite la limpieza de sus archivos de trabajo, conservando el ZIP, el plan firmado y el estado. Los recopiladores de espacios de trabajo comparten el proceso y el bucle de eventos. Las instantáneas del historial actual y las actualizaciones en tiempo real pueden solaparse. Ambas constituyen observaciones independientes, identificadas por su fuente; los duplicados no se ocultan de forma silenciosa. No se implementa ninguna inferencia a partir de identificadores que falten, texto eliminado inventado, enumeración forzada de miembros o incorporación automática a grupos. No se implementa. Para obtener una explicación dirigida a los operadores, consulte [cómo funciona la recopilación](https://phishdestroy.github.io/TgWitness/es/docs/reference/collection/) y [los formatos de cuentas y sesiones](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/). La configuración de red se almacena en la bóveda cifrada. Al aplicar una ruta, se cierran los clientes antiguos y se cancelan los inicios de sesión pendientes; las conexiones posteriores utilizan esa ruta sin recurso alternativo directo. Una nueva instalación con clave externa deriva la clave Fernet de cada espacio de trabajo mediante HKDF-SHA256 a partir de un archivo de clave maestra y una sal aleatoria almacenada. Esto protege los secretos de forma independiente del directorio de datos, y no el contenido del registro o de los archivos multimedia en texto plano. La entrada de demostración local utiliza una capacidad de proceso generada por separado, nunca el token del panel configurado. La emisión y la aceptación requieren el modo de demostración explícito, una raíz sintética sin espacios de trabajo adicionales ni una sesión autorizada, un par/host de bucle cerrado, sin encabezados de reenvío de proxy y sin solicitudes del navegador de origen cruzado. Las API en tiempo real mantienen la autenticación de portador y rechazan los cambios en la recopilación de datos en modo de demostración. --- # Lo que se ha probado Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reference/verification/ La prueba en tiempo real de Telegram, las comprobaciones automatizadas, las comprobaciones en el navegador y lo que aún no se ha verificado. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Translation coverage: this edition includes material from the English original. La prueba en tiempo real de Telegram, las comprobaciones automatizadas, las comprobaciones en el navegador y lo que aún no se ha verificado. [TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [Documentación](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) · [Pruebas y verificación](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/) ![Pruebas y verificación](https://phishdestroy.github.io/TgWitness/assets/chapter-evidence.svg) **Actualizado el 6 de noviembre de 2026.** Los resultados están vinculados a la revisión, el entorno y la carga de trabajo registrados para cada ejecución. [Las capacidades actuales](https://github.com/phishdestroy/TgWitness/blob/main/docs/STATUS.md) describen los flujos de trabajo disponibles; esta página recoge lo que se ha comprobado realmente. [Gráficos de rendimiento](https://phishdestroy.github.io/TgWitness/docs/validation/) · [Auditoría en inglés con lengua de signos](https://github.com/phishdestroy/TgWitness/blob/main/website/validation/audit/REPORT.md) · [Mediciones descargables](https://github.com/phishdestroy/TgWitness/blob/main/website/validation/audit/MEASUREMENTS.csv) | Pruebas más recientes | Resultado | Ámbito de aplicación | | --- | --- | --- | | Auditoría de lanzamiento · 6, noviembre | Pruebas básicas de 1,461: superadas; la plataforma 37 se omite | Fuente `92e539af40d8`; se mantienen los resultados abiertos | | Exportaciones recientes · 6 de noviembre | 127.713 y 141.781 registros/s, ciclo completo | Dos cuentas por servidor; texto y metadatos a través de WARP | | Archivos conservados · 6 de noviembre | Archivos 48; registros 3,598,381 verificados | Los archivos existentes se han comprobado con las claves del espacio de trabajo fijadas. | | Trusted Live · 5 de noviembre | Grabación de CPU protegida y comprobaciones WARP | El inicio de sesión oficial en la aplicación de escritorio y la exportación nativa siguen sin restricciones. | | Phala / Intel TDX · 4 de noviembre | Se han superado todas las comprobaciones del verificador 16 en ejecuciones posteriores. | Despliegue histórico; no hay cuenta de Telegram en el CVM | **En esta página** - [Auditoría de la versión y nuevas exportaciones · 6 de noviembre de 2026](https://phishdestroy.github.io/TgWitness/es/docs/reference/verification/#release-audit-and-fresh-exports--6-november-2026) - [Trusted Live CPU Ubuntu y WARP · 5 de noviembre de 2026](https://phishdestroy.github.io/TgWitness/es/docs/reference/verification/#trusted-live-cpu-ubuntu-and-warp--5-november-2026) - [Implementación en vivo de Phala Cloud · 4 de noviembre de 2026](https://phishdestroy.github.io/TgWitness/es/docs/reference/verification/#live-phala-cloud-deployment--4-november-2026) - [Inventario del diario del servidor en tiempo real · 1 de noviembre de 2026](https://phishdestroy.github.io/TgWitness/es/docs/reference/verification/#live-server-journal-inventory--1-november-2026) - [Comprobaciones recientes sin conexión y con inyección de fallos · 1 de noviembre de 2026](https://phishdestroy.github.io/TgWitness/es/docs/reference/verification/#recent-offline-and-fault-injection-checks--1-november-2026) - [Prueba en directo de Telegram, cuenta completa · 29 de octubre de 2026](https://phishdestroy.github.io/TgWitness/es/docs/reference/verification/#live-telegram-test-whole-account--29-october-2026) - [Exportación protegida con contraseña abierta con libarchive · 29 de octubre de 2026](https://phishdestroy.github.io/TgWitness/es/docs/reference/verification/#password-protected-export-opened-with-libarchive--29-october-2026) - [Prueba en directo de Telegram · del 27 al 29 de octubre de 2026](https://phishdestroy.github.io/TgWitness/es/docs/reference/verification/#live-telegram-test--27-to-29-october-2026) - [Medición sintética de la capacidad local](https://phishdestroy.github.io/TgWitness/es/docs/reference/verification/#synthetic-local-capacity-measurement) - [Búsqueda de texto completo en un millón de mensajes · 5 de noviembre de 2026](https://phishdestroy.github.io/TgWitness/es/docs/reference/verification/#full-text-search-on-one-million-messages--5-november-2026) - [Cualificación restante](https://phishdestroy.github.io/TgWitness/es/docs/reference/verification/#remaining-qualification) ## Auditoría de la versión y nuevas exportaciones · 6 de noviembre de 2026 La auditoría utilizó la versión v0.9.1 en el código fuente `92e539af40d8368d198ff5e040f1d876f2c1310e`, versión `92e539af40d8-83e41104669e`. Las pruebas de funcionamiento de los paquetes instalados se superaron en tres servidores. El informe firmado refleja el estado observado en ese momento. [![Tasas de adquisición y exportación completa para dos cargas de trabajo recientes](https://phishdestroy.github.io/TgWitness/assets/performance.svg)](https://phishdestroy.github.io/TgWitness/docs/validation/) | Volumen de trabajo | Registros | Adquisición | Ciclo completo | Tasa de ciclo completo | | --- | --- | --- | --- | --- | | Servidor A · dos cuentas | 27,030 | 189.043 s | 211.647 s | 127.713 registros/s | | Servidor B · dos cuentas | 29,299 | 182.513 s | 206.650 s | 141.781 registros/s | Ambas exportaciones se iniciaron sin reanudación, excluyeron archivos adjuntos y avatares, y finalizaron sin ningún registro duplicado o reutilizado. El ciclo completo incluye la preparación, la adquisición, la selección, el empaquetado y la verificación del archivo. El servidor A también ejecutó una comprobación de lectura de chats protegidos. Se respetaron cuatro eventos FloodWait en A y tres en B. Estas observaciones no establecen una garantía general de rendimiento. | Comprobar | Resultado | Requisitos | | --- | --- | --- | | pytest básico | 1,461: aprobado | La plataforma 37 omite | | Navegador / experiencia de usuario del navegador / pruebas / sitio web | 102 / 66 / 15 / 9 superadas | Estos programas se solapan con otras pruebas; los recuentos no son acumulativos. | | Complemento Capture | 124: aprobado | Tres comprobaciones oficiales de la web bloqueadas por el entorno aislado (sandbox) de Chromium requerido | | Autorización de la API | Rutas 269; solicitudes 538 aprobadas | Credenciales perdidas y acceso revocado | | Archivos conservados | 48 de 48 verificado | Registros 3,598,381; claves del espacio de trabajo fijadas | | Comprobaciones de lectura en tiempo real de la flota | Se ha superado el perfil 24 de 40 | Las rutas WARP 16 no superaron la calificación; esos perfiles no estaban conectados | El informe [firmado](https://github.com/phishdestroy/TgWitness/blob/main/website/validation/audit/REPORT.md) registra todos los hallazgos pendientes, incluidos tres defectos en una instantánea de un chat secreto no publicada que no figura en la versión principal auditada. La anterior [calificación del historial público](https://github.com/phishdestroy/TgWitness/blob/main/docs/EXPORT-BENCHMARK-2026-11-06.md) utilizó una revisión y una carga de trabajo diferentes; sus índices no deben combinarse con esta comparación. Verifica el informe original utilizando la clave [fijada y el verificador](https://github.com/phishdestroy/TgWitness/blob/main/website/validation/audit/README.md#verify-the-original-files). Su firma protege el informe del operador frente a posibles alteraciones. No se trata de una certificación independiente, una prueba de la autoría de Telegram ni una certificación del RGPD. ## Trusted Live CPU Ubuntu y WARP · 5 de noviembre de 2026 La ejecución de integración conservada utilizó un invitado Ubuntu 24.04.5 solo con CPU (vCPU 4, 8 GiB) bajo QEMU dentro de un host RunPod con CPU. El recopilador utilizó `14e642a5`; la verificación utilizó `02072461`. Las correcciones finales se fusionaron en [PR #114](https://github.com/phishdestroy/TgWitness/pull/114) como `755f78f6`, cuyo árbol coincidía con la cabeza del PR probado. No se trataba de un TEE. - Se ha detectado un conector WARP real en buen estado; el HTTPS con proxy ha indicado que WARP y Gateway están habilitados. Tres sondas detectaron la misma dirección de salida, lo que no garantiza una IP fija. - Al desconectar WARP, la solicitud mediante proxy falló. El servicio de puerta de enlace HTTPS directo fue rechazado. En el espacio de nombres del registrador, se bloquearon las direcciones IPv4/IPv6 directas, el DNS externo y el resolutor UDP integrado de Docker. - Un token de proveedor de solo lectura con ámbito limitado podía leer el estado y las conexiones, pero no podía leer el token de inscripción del conector. Las observaciones firmadas del proveedor incluían muestras explícitas no disponibles. El testigo se ejecutaba en el servidor del operador, por lo que esto demuestra el registro y la conservación de datos, pero no la custodia por parte de un tercero independiente. - Official Desktop llegó a su pantalla de bienvenida sin autenticar. La entrada de teclado protegida fue rechazada durante la captura. Se decodificaron tres segmentos de pantalla H.264 y se inspeccionó su superposición de reloj. Se verificó el archivo de comprobación previa del evento 18 con la clave de grabación fijada y el punto de control conservado. - Las pruebas finales de captura superaron los casos 114 en el entorno de integración continua (CI) de Windows y Linux, con versiones reales de Chromium/FFmpeg. Se superaron cinco pruebas de referencia y las comprobaciones de avisos de dependencias. Una puesta en marcha inicial de 2 vCPU/4 GiB agotó el tiempo de espera bajo una carga simultánea de creación de imágenes y se detuvo a través del mecanismo de protección; no se cuenta como un éxito. El inicio de sesión manual en la cuenta de prueba, la exportación nativa del chat, la comparación híbrida real y el cierre de sesión desde Telegram siguen pendientes. No se importó ninguna sesión de Telethon proporcionada. Los archivos adjuntos, el OCR automático, la verificación local de drand BLS y la certificación Trusted Live TDX no cumplieron los requisitos. ## Despliegue en Phala Cloud en tiempo real · 4 de noviembre de 2026 **Resultado histórico: las implementaciones posteriores a** superaron todas las comprobaciones del verificador 16, incluidas las de Intel TDX y el túnel rápido. Las pruebas de reinicio, la detección de direcciones firmadas y las marcas de tiempo de los informes se comprobaron por separado. Cada CVM de prueba se eliminó tras su ejecución. | Configuración | Valor registrado | | --- | --- | | Proveedor | Phala Cloud · `tdx.small` · US-WEST-1 | | Implementación | `--provider phala --quick-tunnel`: espacio de trabajo inicialmente vacío | | Recopilador inicial | `df7d860c` · v0.8.1 | | Recopilador con todas las correcciones | `53a0f7e9` | | Invitado de producción | `dstack-0.5.12`; acceso SSH desactivado | | Servicios externos | ntfy.sh, GitHub e Intel PCS | | Coste observado | Siete CVM, que suman unos 1.9 centavos de dólar estadounidense; precios históricos de las pruebas | La secuencia que figura a continuación distingue entre fallos iniciales, correcciones y comprobaciones completadas. No se conectó ninguna cuenta de Telegram a estos CVM. **Implementaciones 1–2 · diferencias entre proveedores y comprobaciones de regresión** The first two deployments found five differences from the simulated Phala Cloud. Private Phala regressions reproduce each difference and fail without its fix: | En Phala Cloud | Antes de la corrección | Solución | | --- | --- | --- | | Se requiere `compose_file.name` | HTTP 422, no se ha creado nada | La configuración de Docker Compose incluye el nombre de la CVM | | A menos que se le proporcione uno vacío, Phala añade su propio script de preinicio al «app-compose» evaluado (v0.0.20: inicio de sesión en Docker, `docker compose pull`, contraseña de root, claves SSH de `user_config`) | `tdx_compose` falla: código fuera de la configuración publicada de Docker Compose | El «app-compose» establece `pre_launch_script` en `""`; Phala, a continuación, lo omite | | Sin `image`, Phala selecciona `dstack-dev-0.5.12`, la versión de desarrollo, con acceso SSH habilitado | `server_state` falla. En esta imagen, solo se ha superado el registro de certificación de hardware; únicamente el registro del proveedor y `tdx_os` lo muestran. | La implementación solicita la versión de producción de la actual versión de Phala, `dstack-0.5.12` | | Con la pasarela dstack desactivada, los detalles de la CVM nunca muestran un `instance_id` | La implementación espera 30 minutos y falla | El ID de la instancia se lee del estado de la CVM | | Los reinicios, las paradas y los arranques son operaciones de la CVM, no revisiones de la aplicación | `provider_actions` no incluyó los reinicios | Las operaciones también se leen | **Despliegue 3: certificación, comprobaciones de acceso y pruebas de reinicio** - La CVM ejecutó `dstack-0.5.12` con el acceso SSH desactivado. El colector publicó su dirección firmada aproximadamente 1,5 minutos después de su creación. A continuación, la implementación superó las pruebas de `tdx_binding` y `tdx_quote` (Intel TCB UpToDate, registro de certificación de hardware v4, FMSPC `20a06f000000`, sin modo de depuración, no migrable, compatible con datos de verificación criptográfica obtenidos de Intel), `tdx_compose_hash`, `tdx_compose` (byte a byte) y `tdx_identity` (claves KMS). - El panel, en su dirección trycloudflare.com, devolvió un código de estado 401 sin token o con uno incorrecto, y un 200 con el token del panel. - `verify` con `--source` configurado en el archivo de GitHub de la confirmación y la huella digital superada por separado: servidor, `server_state`, cortafuegos (sin puerta de enlace, sin punto final público), registro del proveedor, extracto, huella digital, hash de origen, arranque y las cinco comprobaciones `tdx_*` superadas. Cloudflare y `tdx_os` no estaban disponibles, por lo que el resultado fue INCOMPLETO. - Dos reinicios a través de la API de Phala: en cada ocasión, la CVM volvió a estar operativa en menos de dos minutos con la misma clave de recopilador, una nueva dirección firmada y la antigua respondiendo con el código 530. `verify` notificó el nuevo arranque y ambos reinicios como REVIEW. Con `--evidence` se confirmaron las firmas del diario y tres arranques, cada uno con su propio registro de certificación de hardware Intel TDX procedente del mismo CVM. - `destroy` eliminó únicamente esa CVM. A continuación, el espacio de trabajo quedó vacío y la dirección del panel dejó de responder. - La comprobación de precios del asistente del panel indicaba `tdx.small` a 0,058 dólares por hora. Al introducir una clave incorrecta, apareció un mensaje sencillo que decía «no se ha aceptado la clave de API». **Correcciones posteriores: detección de direcciones firmadas y mediciones del sistema operativo** - Without the address key, `verify` followed the newest well-formed post on the address topic, which is printed in the published compose. One forged post sent it to a host that does not exist, and `statement` failed: a forger could not pass as the collector, but could block third-party verification, for up to 12 hours with a forged future timestamp. The collector now also posts its address signed with its own key, `verify` accepts only such posts when the collector makes them, and posts are ordered by ntfy.sh's receive time. A private cloud-wizard regression replays the forged posts. A CVM runs this only from a commit that contains it, so this run's collector did not sign its address yet and `verify` said so. - `tdx_os` no pudo ejecutarse sin `dstack-mr`, cuya versión actual es `measure-os` en lugar de el `measure --json` que figuraba en la documentación. El verificador calcula ahora por sí mismo MRTD y RTMR0-2 a partir de la imagen publicada y la configuración de la máquina virtual, incluidas las tablas ACPI. **Implementación 4 · todas las comprobaciones 16, sellos de informe y verificación de reinicio** - Deploy descargó una vez el archivo `dstack-0.5.12` publicado, lo comparó con el hash de la imagen del sistema operativo que la CVM notificó, y `tdx_os` superó la comprobación: MRTD, RTMR0, RTMR1 y RTMR2 coinciden con los valores calculados para QEMU 8.2.2, 1 vCPU y 2 GiB. El mismo cálculo arrojó un valor de RTMR0 diferente para una configuración declarada de 4 GiB, 2 vCPU, QEMU 9.2.1 o una segunda tarjeta de red, y falló en caso de cambios en el kernel, el firmware o la línea de comandos, así como para la imagen de desarrollo. - `verify` superó cada una de sus 16 comprobaciones, incluido el conector del túnel rápido, por lo que el resultado fue «APROBADO». Generó el certificado en formato HTML y PDF, sellado digitalmente con firmas y marcas de tiempo mediante una marca de tiempo eIDAS cualificada de la unidad de marcado de tiempo del Gobierno belga TSU 202301 (estatus concedido en la lista de confianza de Bélgica), una marca de tiempo FreeTSA y la firma del verificador; `check-report` confirmó todos ellos y la firma del PDF. - Tras un reinicio, `verify --evidence` confirmó dos arranques, cada uno acompañado de una certificación de hardware generada dentro de la CVM y cada uno iniciado desde el `dstack-0.5.12` publicado; tanto el reinicio como el nuevo arranque fueron de tipo REVIEW. - `destroy` dejó el espacio de trabajo vacío. **Implementación 5: detección de mensajes firmados por el recopilador y rechazo de mensajes falsificados** El recopilador se ejecutó a partir de la confirmación `53a0f7e9`, que incluye las correcciones mencionadas anteriormente. - El recopilador publicó su dirección firmada con su propia clave, junto a la publicación HMAC del operador. A continuación, se añadieron dos publicaciones falsificadas al tema, una con un HMAC a cero y otra firmada por otra clave Ed25519, ambas con una fecha del año 2096. `verify` tomó la dirección firmada por la clave del recopilador y superó las 16 comprobaciones; el sello volvía a incluir el sello de tiempo belga certificado, el sello de tiempo de FreeTSA y la firma del verificador, y `check-report` los confirmó. - Tras un reinicio, el colector publicó la nueva dirección firmada: `verify` la detectó de inmediato; el operador **«Buscar la dirección actual»**, 27 segundos más tarde a partir de la publicación HMAC, y ambos ignoraron las publicaciones falsificadas. `verify --evidence` confirmó dos arranques iniciados desde `dstack-0.5.12`. - La implementación mostró lo que Phala factura por la CVM, disco incluido: 0,06078 dólares por hora. ### Asistente de paneles y alcance restante El asistente del panel se ejecutó en Phala Cloud en dos ocasiones: una a través de su API de tareas y otra a través del navegador con un Chromium real: la comprobación del precio, la creación con la confirmación bajo **Advanced**, las seis comprobaciones de certificación superadas, la lista de servidores que muestra el precio facturado (44,37 USD al mes), **Find la dirección actual**, la descarga de la configuración de Docker Compose medida y la eliminación. El navegador no detectó ningún error en las páginas. En ambas ocasiones, el espacio de trabajo quedó vacío posteriormente. No se incluyen: un dominio de Cloudflare en Phala, una cuenta de Telegram en el CVM y la imagen `dstack-0.6.1` . El precio del asistente antes de la creación corresponde únicamente al coste de computación de Phala, ya que su API indica el coste del disco solo para un CVM existente; la lista de servidores muestra el precio facturado tras la creación. Todos los precios de esta sección se observaron el 4 de noviembre de 2026. ## Inventario del diario del servidor en tiempo real · 1 de noviembre de 2026 Aproximadamente a las 19:15 UTC, las consultas SQLite `query_only` secuenciales de solo lectura contabilizaron los eventos en diez bases de datos de espacios de trabajo en un servidor en funcionamiento. La recopilación continuó durante las consultas, por lo que no se trata de una instantánea atómica de todos los espacios de trabajo. | Observado en las diez bases de datos de espacios de trabajo | Recuento | | --- | --- | | Espacios de trabajo con al menos un evento `message.new` | 8 | | Registros del diario, incluidos los eventos operativos | 1,610,818 | | Eventos `message.new` | 900,232 | | Eventos `message.edited` | 80,683 | | Eventos `message.deleted` | 400,536 | | Eventos `message.recovered` | 53,403 | | Eventos `message.snapshot` | 2,183 | | Eventos `media.saved` | 50,418 | | Eventos `media.failed` | 5,575 | | Eventos `coverage.gap` | 11 | | Bytes de la base de datos, excluyendo los archivos WAL y los archivos multimedia | 7,909,003,264 | Se trata de **recuentos de eventos**, no de mensajes, personas o archivos multimedia únicos. El mismo mensaje puede aparecer en más de un espacio de trabajo, y una edición o eliminación puede generar otro evento del diario. `media.failed` cuenta los eventos de fallo históricos, no la cola de archivos multimedia actual. Las consultas **no** verificaron de nuevo las firmas ni la cadena de hash completa de los 1,610,818 registros, ni midieron la entrega o el rendimiento, ni establecieron que se capturara cada evento de Telegram. Aquí no se publican contenidos de mensajes, ID de cuentas o de chats, etiquetas de espacios de trabajo, credenciales ni archivos privados. En esta revisión, el monitor público configurado por separado abarcaba tres fuentes: una respuesta de captura fue correcta y dos informaron de `no_response`. Ese monitor no es un resumen del estado de diez entornos de trabajo. `no_response` significa que el observador no pudo obtener una respuesta en esa comprobación; no implica la pérdida de mensajes. La prueba más pequeña del 29 de octubre que se muestra a continuación tiene su propia firma explícita y verificación de cadena de hash. ## Comprobaciones recientes sin conexión y con inyección de fallos · 1 de noviembre de 2026 Estas comprobaciones utilizan datos ficticios y archivos locales; aportan pruebas de regresión para la fuente actual, no para otra medición real de entrega de Telegram: | Comprobar | Qué se ha probado | | --- | --- | | Source archive | Dos compilaciones con bytes de código fuente idénticos, pero con fechas de modificación de los archivos diferentes, generaron el mismo archivo ZIP y la misma suma de comprobación. Los bytes exactos del archivo y los hash de los archivos coincidieron; los archivos de prueba privados quedaron excluidos. Un fallo de escritura simulado dejó intactos el archivo y la suma de comprobación anteriores. | | Account export recovery | Un error de disco simulado en el segundo miembro del ZIP no dejó ningún ZIP publicado ni parcial. La reanudación mantuvo cada recibo firmado idéntico byte a byte, generó un archivo verificable de forma independiente utilizando la huella digital de firma esperada y conservó la laguna de cobertura sintética como resultado parcial. Las aserciones de escala evitan que se repitan las tareas y los escaneos de recibos a medida que crecen los historiales. | | Minimized disclosure privacy | Se comprobaron los nombres y alias Unicode sintéticos, los metadatos anidados, los remitentes desconocidos y los campos multimedia en los tres modos de identidad y con omisión de texto. Un fallo en el límite de enmascaramiento no debilitó silenciosamente la censura; la exportación original de la cuenta firmada se mantuvo sin cambios. | | Linux media decoder and OCR | Una [comprobación de CI en Docker para Linux](https://github.com/phishdestroy/TgWitness/actions/runs/41341200341/job/124951395192) en la confirmación `5a9e0814` superó las pruebas con entradas generadas en formatos Ogg/Opus, MP3, M4A, MP4 con vídeo, WAV y FLAC; controles de duración falsificada y de referencia a archivos secundarios; y 48 fixtures de analizador mutados (34 rechazados, 14 decodificados dentro de los límites). El OCR real de Tesseract se ejecutó sin modificar los bytes originales. El decodificador y el OCR se ejecutaron en contenedores aislados de la red sin un modelo de Whisper. | Las comprobaciones se ejecutan en los flujos de trabajo [(solicitud de incorporación de cambios)](https://github.com/phishdestroy/TgWitness/blob/main/.github/workflows/pr-check.yml) y [(comprobaciones completas)](https://github.com/phishdestroy/TgWitness/blob/main/.github/workflows/checks.yml). Comprueban estos límites de fallo, no todos los posibles fallos de almacenamiento ni si una divulgación es automáticamente segura para su publicación. La comprobación de archivos multimedia no mide la precisión del reconocimiento de voz ni la entrega de Telegram. Revisa cada derivado antes de compartirlo. ## Prueba en directo de Telegram, cuenta completa · 29 de octubre de 2026 La misma cuenta siguió funcionando tras la prueba que se describe a continuación. El 29 de octubre a las 12:10 UTC, su ámbito de aplicación se amplió a toda la cuenta (canales, grupos, chats privados y bots); el panel solicitó confirmación y el registro firmado lo dejó constancia. A las 17:59 UTC, el registro contenía: | Registrado del 27 de octubre a las 21:36 al 29 de octubre a las 17:59 UTC | Recuento | | --- | --- | | Registros del diario | 9,968 | | Nuevos mensajes | 5,308 | | de ellos tras el cambio a la cuenta completa | 3,878 | | Eliminaciones | 784 | | de ellos se eliminaron después de que TgWitness hubiera guardado el mensaje | 596 | | Modificaciones | 41 | | Mensajes añadidos tras nuevas comprobaciones | 2,273 | | Mensajes que ya no se pudieron localizar tras una nueva comprobación | 18 | | Mensajes guardados mediante instantáneas del historial | 242 | | Archivos adjuntos guardados | 247 | | El recopilador se inicia | 19 | | Pausas de Telegram FloodWait | 26 | - La comprobación **«Verify»** del panel confirmó las firmas y la cadena de hash de los 9.968 registros. - Los mensajes procedían de 2 grupos o canales y de 3 chats privados y bots. Se pulsó un botón de mensaje desde **«Chats»**; la solicitud y la respuesta de Telegram figuran en el registro. - Se añadieron nuevos chats cuando el recopilador volvió a escanear la cuenta tras un reinicio. La opción de guardar los mensajes anteriores de los nuevos chats estaba desactivada (`history = 0`), por lo que no se trata aquí. No se incluyen: reacciones, cambios en la composición de los grupos, perfiles de usuarios, envío de mensajes, incorporación mediante invitación, proxies, notificaciones, el bot «witness» ni el uso simultáneo de varias cuentas. Los archivos públicos solo contienen recuentos. ## Exportación protegida con contraseña que se abre con libarchive · 29 de octubre de 2026 Se abrió un archivo creado mediante el código de cifrado de exportación (WinZip AES-256, el formato que leen 7-Zip y WinRAR ) con Windows `tar` (bsdtar 3.6.2, libarchive). Con la contraseña correcta, el archivo extraído coincidió con el SHA-256 original; si se introducía una contraseña incorrecta, se rechazaba con el mensaje «Contraseña incorrecta». No se ejecutaron los propios programas 7-Zip ni WinRAR. ## Prueba en directo de Telegram · Del 27 al 29 de octubre de 2026 Una cuenta real de Telegram, conectada a través del conjunto de pares de API integrado, registró un supergrupo desde **las 21:36 UTC del 27 de octubre hasta las 05:15 UTC del 29 de octubre**. El recopilador se inició 12 veces durante ese periodo. | Registrado | Recuento | | --- | --- | | Registros del diario, incluidos los «heartbeats» y los registros de servicio | 2,385 | | Nuevos mensajes | 1,291 | | Eliminaciones | 472 | | de ellos se eliminaron después de que TgWitness hubiera guardado el texto | 347 | | Modificaciones | 12 | | Mensajes que se perdieron mientras la herramienta estaba detenida, añadidos tras una nueva comprobación | 12 | | Archivos adjuntos guardados | 17 | | Archivos adjuntos no descargados (descargas desactivadas o no hay ningún archivo que descargar) | 14 | | Telegram FloodWait realiza pausas de 3 segundos cada una durante las revisiones | 8 | - Las firmas y la cadena de hash de los 2.385 registros se verifican con la clave pública del registro. - Tras un reinicio, el recopilador reanuda su funcionamiento desde el estado de actualización guardado (`pts`) y Telethon se pone al día; a continuación, la nueva comprobación añade los mensajes que aún faltan. - En cada FloodWait, el recopilador esperaba el tiempo solicitado y continuaba. - La cuenta permaneció conectada y la misma sesión se volvió a conectar el 29 de octubre. No se incluyen en esta prueba: varias cuentas a la vez, roles de administrador, proxies, interrupciones de servicio de más de unas pocas horas y el [procedimiento completo de aceptación en tiempo real](https://github.com/phishdestroy/TgWitness/blob/main/docs/internal/LIVE_ACCEPTANCE.md). Los archivos públicos contienen únicamente estos datos: no incluyen identificadores de cuentas ni de chats, mensajes ni credenciales. ## Medición sintética de la capacidad local Private synthetic capacity run: 10,000 events across 100 chats. | Métrica | Observado | | --- | --- | | Datos de entrada | 10 000 eventos de mensajes sintéticos procedentes de 100 fuentes sintéticas seleccionadas | | Texto del mensaje | 400 caracteres; sin archivos multimedia ni menciones a redes sociales | | Ingestión | 53,273 segundos; 187,7 eventos por segundo | | Latencia del controlador | p50 4,162 ms; p95 7,784 ms; máximo 129,118 ms | | Exportación en formato ZIP | 19,868 segundos con tracemalloc activado | | Picos de asignaciones de exportación de Python rastreadas | 0,51 MiB; no procesa RSS | | Tamaño del archivo ZIP | 4 610 962 bytes | | Verificación independiente | Los 10 000 eventos han sido verificados | Esto mide la ruta local de grabación/exportación en serie en este equipo con Windows. No mide la entrega de MTProto, las cuentas simultáneas, la limitación de Telegram, los archivos multimedia, una carga de trabajo de larga duración ni un número garantizado de chats reales. La medición es anterior a la herramienta definitiva de marcas de tiempo fuera de línea, que no modifica la ruta de los mensajes medidos. ## Búsqueda de texto completo en un millón de mensajes · 5 de noviembre de 2026 Comando: `python tools/bench_fulltext.py --messages 1000000 --work ` A deterministic signed journal of 1,000,000 synthetic messages in 200 chats (Russian word forms, Ukrainian, English, Chinese, Japanese, links and handles) was indexed in 71 seconds; the index took 58 MiB beside a 1.50 GiB journal. Best-match searches took 9 to 190 ms (median), against 2.4 to 3.2 seconds for the previous substring search. Full results, hardware and limits: [Full-text search](https://phishdestroy.github.io/TgWitness/es/docs/reference/search/#benchmark). Private compatibility tests also verify a frozen signed archive made before full-text search with the current verifier, and a current archive with the frozen archive's own `verify.py`. ## Cualificación restante El registro en tiempo real conservado recoge de forma fehaciente las recopilaciones, modificaciones, avisos de eliminación, archivos adjuntos, nuevas comprobaciones y la gestión de los límites de frecuencia. No registra de forma exhaustiva la entrega ni ofrece una matriz controlada de visibilidad de roles, agentes de reacción, esperas prolongadas (FloodWait), bloqueos de cuentas y recuperación tras interrupciones de red o procesos. La emisión de tokens QR sigue siendo independiente de la confirmación completa del código QR en el móvil. Las comprobaciones de Docker/Compose y de instalación se registran en CI; el despliegue real de Phala y la verificación externa de marcas de tiempo se describen más arriba. No establecen una carga elevada sostenida, una matriz completa de plataformas/roles en tiempo real, una revisión de seguridad independiente, una validación de archivo a largo plazo ni una certificación forense. Se han implementado el estado guardado de MTProto y la puesta al día; la reproducción en tiempo real atómica y sin pérdidas sigue sin estar establecida. El backfill más reciente confirma los mensajes y los cursores de forma atómica y conserva las acciones recientes disponibles, pero su cobertura sintética es distinta de la cualificación en tiempo real. Véase «[: aceptación en tiempo real](https://github.com/phishdestroy/TgWitness/blob/main/docs/internal/LIVE_ACCEPTANCE.md)» para consultar la matriz de cualificación controlada. El directorio de auditoría pública contiene únicamente el informe firmado y las mediciones agregadas. Los recibos operativos detallados, las capturas sin procesar y el material de las cuentas siguen siendo privados. Las capturas de pantalla de la aplicación en `docs/assets/` utilizan datos de demostración ficticios. --- # Aviso sobre incompatibilidades de licencia y arquitectura Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reference/license/ TgWitness cuenta con una licencia del MIT para todos, y por qué es arquitectónicamente incompatible con el flujo de trabajo de Taylor Wessing. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) TgWitness cuenta con una licencia del MIT para todos, y por qué es arquitectónicamente incompatible con el flujo de trabajo de Taylor Wessing. TgWitness se distribuye bajo la [licencia MIT](https://phishdestroy.github.io/TgWitness/LICENSE). Nuestra postura no añade ninguna condición a la licencia. > Una firma no convierte una mentira en un hecho. > > > > TgWitness no es adecuado para empresas, bufetes de abogados o particulares que crean que anteponer «Dr.» a un nombre convierte en cierto todo lo que le sigue. Los títulos, los membretes y las firmas no prevalecen sobre las pruebas. > > > > Si su flujo de trabajo parte de la conclusión por la que un cliente ha pagado y exige que el registro se ajuste a ella, está buscando una herramienta diferente. TgWitness existe para preservar el registro y ponerlo a disposición para su examen. > > > > Dejen que esos «doctores» se ocupen de los balances de sus clientes corporativos. Un título no cura una mentira. > > > > Las matemáticas no negocian. [Registro original](https://phishdestroy.io/steam_dossier/taylor_wessing) · [Aviso ético y continuidad histórica](https://phishdestroy.github.io/TgWitness/es/docs/reference/notice/) [Licencia MIT completa](https://phishdestroy.github.io/TgWitness/LICENSE) · [Proyecto](https://github.com/phishdestroy/TgWitness/blob/main/README.md) · [Documentación](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) · [Wiki](https://github.com/phishdestroy/TgWitness/blob/main/docs/wiki/Home.md) --- # Aviso de incompatibilidad con algunos operadores Canonical page: https://phishdestroy.github.io/TgWitness/es/docs/reference/notice/ Nuestra nota operativa sobre Taylor Wessing y su registro de fuentes. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Nuestra nota operativa sobre Taylor Wessing y su registro de fuentes. **PhishDestroy · Aviso del proyecto TgWitness** [Registro original](https://phishdestroy.io/steam_dossier/taylor_wessing) · [AVISO original](https://phishdestroy.github.io/TgWitness/NOTICE) ## ⚖️ Aviso ético y continuidad histórica Recientemente hemos sabido que, para determinados bufetes de abogados —y, en concreto, para el Dr. Tobias Schelinski y el Dr. Patrick Vincent Zurheide—, las matemáticas y los hechos objetivos carecen de relevancia. Vender el incumplimiento del RGPD a las empresas como un servicio comercial, al tiempo que ustedes mismos no cumplen con los requisitos básicos de tratamiento de datos, no constituye pericia jurídica. Actuar bajo la ilusión de que usted es la ley, o de que la firma de una élite en una reclamación falsificada convierte mágicamente una mentira en verdad, no disimula la incompetencia técnica. Esta herramienta es incompatible con las jurisdicciones en las que prevalecen los siguientes aspectos: - Corporatocracia - Justicia privatizada o comercial - Plutocracia - Cleptocracia y corrupción institucional Mención especial al Dr. Patrick Zurheide, al Dr. Tobias Schelinski y a quienes intentan utilizar el «derecho al olvido» como arma para ocultar sus propios fallos en el tratamiento de datos, depurar su linaje institucional y borrar el registro histórico: > Taylor Wessing (Dr. Tobias Schelinski y Dr. Patrick Vincent Zurheide) → Wessing & Berenberg-Gossler → Stonewall Top 100 → Dr. Graf von der Goltz, Dr. Wessing & Partner (desde 1957) → Rüdiger Graf von der Goltz → Párrafo 175 en su revisión de 1935 Para cumplir estrictamente con la licencia MIT, no restringimos el uso de este software. Sin embargo, que quede claro: los contratos de representación corporativa, la intimidación legal y las exigencias de borrado digital no pueden anular la historia, reescribir el linaje ni ocultar la verdad. [Licencia MIT](https://phishdestroy.github.io/TgWitness/LICENSE) · [Nuestra postura respecto a Taylor Wessing](https://phishdestroy.github.io/TgWitness/es/docs/reference/license/) · [Modelo de pruebas](https://phishdestroy.github.io/TgWitness/es/docs/reference/how-it-works/) [Proyecto](https://github.com/phishdestroy/TgWitness/blob/main/README.md) · [Documentación](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) · [Wiki](https://github.com/phishdestroy/TgWitness/blob/main/docs/wiki/Home.md) --- # TgWitness Changelog & Release Notes Canonical page: https://phishdestroy.github.io/TgWitness/docs/reference/changelog/ Read TgWitness changes by version, including unreleased work. Check release notes before assuming a source feature is included in an installed package. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/llms.txt) Translation coverage: this edition includes material from the English original. Todos los cambios por versión, incluidos los que aún no se han publicado. [TgWitness](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [Documentation](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) · [Project reference](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) ![Project reference](https://phishdestroy.github.io/TgWitness/assets/chapter-project.svg) **On this page** - [Unreleased](https://phishdestroy.github.io/TgWitness/es/docs/reference/changelog/#unreleased) - [0.9.1 preview · 5 November 2026](https://phishdestroy.github.io/TgWitness/es/docs/reference/changelog/#091-preview--5-november-2026) - [0.9.0 preview · 4 November 2026](https://phishdestroy.github.io/TgWitness/es/docs/reference/changelog/#090-preview--4-november-2026) - [0.8.1 preview · 2 November 2026](https://phishdestroy.github.io/TgWitness/es/docs/reference/changelog/#081-preview--2-november-2026) - [0.8.0 preview · 2 November 2026](https://phishdestroy.github.io/TgWitness/es/docs/reference/changelog/#080-preview--2-november-2026) - [0.7.1 preview · 1 November 2026](https://phishdestroy.github.io/TgWitness/es/docs/reference/changelog/#071-preview--1-november-2026) - [0.7.0 preview · 31 October 2026](https://phishdestroy.github.io/TgWitness/es/docs/reference/changelog/#070-preview--31-october-2026) - [0.6.1 · 27 October 2026](https://phishdestroy.github.io/TgWitness/es/docs/reference/changelog/#061--27-october-2026) - [0.6.0 · 27 October 2026](https://phishdestroy.github.io/TgWitness/es/docs/reference/changelog/#060--27-october-2026) - [0.5.1 · 27 October 2026](https://phishdestroy.github.io/TgWitness/es/docs/reference/changelog/#051--27-october-2026) - [0.5.0 · 26 October 2026](https://phishdestroy.github.io/TgWitness/es/docs/reference/changelog/#050--26-october-2026) ## Unreleased - Isolate request-body capacity and token-family lockouts, set Secure download cookies behind trusted HTTPS proxies, limit pending tickets per access, and expose journal write failures. - Add an English Secret Chat demo with fictional requests, replies, attachments and retained deletion notices. Document the separate development implementation and its open defects; the demo does not enable Telegram connections. - Remove the unused one-shot exporter and check recovery against the current exporter. Reject unexpected or repeated message IDs in recheck responses. - Combine concurrent exports with resumable Standard API and Takeout acquisition. Each job retains its own progress, timings and signed checkpoints; accounts remain reserved until that job stops. Include the account controls, batch import and report-verification updates in the same build. - Add offline `VERIFY.cmd` / `VERIFY.sh` launchers, plain-language verification explanations and saved UTF-8 transcripts to signed exports in all 25 panel languages. Build a separate Windows verifier with an embedded runtime and a language menu. Unpinned signers remain unconfirmed; successful integrity verification does not establish admissibility. - Add optional jurisdiction guidance for 25 countries to Report Studio and exported assessments, with separate civil/criminal sources, local-language summaries and next steps derived from the actual package. Guidance remains a research draft, does not raise assurance, and is excluded from reusable layout profiles and inherited sharing-copy settings. - Allow the pinned Russian morphology dictionary resources in Windows portable builds while continuing to reject unrecognized files in dependency data directories. - Keep missing-on-recheck observations separate from deletion notices in HTML, JSON and PDF counts and viewer labels. Do not claim unscoped deletion IDs were never saved when their chat is outside the current observation scope. - Record multiple deleted IDs as a deletion batch without inferring a whole-history clear, the deleting participant, or deletion for everyone. Relabel legacy history-clear events without changing their signed records. - Publish the one-command installer only after application and security checks pass for the exact main commit and the signed package passes Ubuntu local/HTTPS service and Windows PowerShell acceptance. Keep the previous download when checks fail or time out. Add authenticated tests of the actual public installer URLs. - Preserve `previous_hash` in the signed-record preview even when its hexadecimal digits resemble a payment card number. Secret masking still applies to message content; the stored record is unchanged. - Reconstruct compact chat snapshots consistently in MCP, retain unknown fields, and distinguish capped lists from removals. Resume date scans, preserve topic names across history reads, and bound image previews. Apply metric choices to filtered reports and count historical service messages separately. - Plan sealed exports against the remaining session time, offer smaller selections, update progress estimates and reserve time for packaging. - Compare every message field, validate record counts and structure, enforce CLI verification options, and display OpenTimestamps states separately. - Close coverage on worker failure, bind heartbeats to the capture run, and verify TDX signing-key binding and supported component statuses. - Add read-only MCP tools (preview): `get_messages_by_date` (one calendar day in a named time zone, computed server-side), `get_pinned_messages`, `get_chat_stats` with `gap_summary`, `get_topics`, and `get_media`, which returns a verified, downscaled image preview anchored to its SHA-256 and `media.saved` record. Every MCP tool now declares an output schema. New connections include these tools; existing connections keep the tools they were issued with. - Show each account's selected route and checked exit address, group session controls, and retain interface preferences when adding an account. Record connection changes without repeating identical background checks. Validate withheld-marker contents and reply states in minimized exports, including rejection of a missing-source label for an included record. - Update collection-mode instructions and Russian guidance. Allow a bounded publication-settling interval while requiring exact installer bytes. - Mark messages left out of a minimized disclosure (preview): inside each disclosed chat, withheld messages appear as content-free markers naming the selection rule, one per run or one per message, and disclosed replies state whether they answer a disclosed message, a withheld one or one that is not in the source export. The package format becomes `tgwitness-account-disclosure-v2`; `verify.py` rejects markers with content and replies pointing at missing records, and still verifies version 1 packages. - Repeat gap analysis with the settings carried by the signed export, count each service-message number once, and bound account estimates to the measured interval. Require explicit whole-account scope, retain pause/resume boundaries, and interrupt expensive archive scans at their time budget. - Add missing message numbers (preview): `coverage.json`, the HTML and PDF reports, `verify.py` and the archive's `get_capture_status` measure numbers Telegram assigned and this collector never saw, per channel or supergroup and for the account-wide sequence of private chats, bots and ordinary groups during whole-account collection. Each result states whether it applies and why, lists its parameters, and anchors listed gaps to the neighbouring observations. **Parameters → Gap analysis** sets the listed gaps, the account-wide sequence and an optional service-message estimate that is never subtracted. A gap names no actor and no reason. - Record in the signed message when self-destructing media is fetched despite a type or duration rule (`media_capture.rule_override`), with the limits that still applied. - Add chat-state snapshots (preview): while observing, every enabled source is read periodically and saved as a signed `chat.state` record with title, description, counts, pinned messages, administrators with rights, and gifts on channels and profiles, plus the differences from the previous snapshot. Unpinning, rights changes and gift conversions or upgrades without a service message become visible. Parts Telegram refuses are named and carried forward, never reported as removed. **Parameters → Chat state** sets the interval, pause and parts. - Add anomaly indicators to evidence reports (preview) as registered, versioned processors in `tgwitness/metrics/`: first-time posters per day with flagged injection-like days, service messages among message numbers, joins and departures per month, and pins and unpins per month. Reports list every processor that ran with its version and print its method; **Parameters → Report metrics** chooses them. - Keep ranked-search pages within the first 1,000 results regardless of page size, order OCR/transcription results before pagination, and retain exact match positions when Unicode expansions and invisible-character removal cancel each other's length changes. - Keep photo downloads on the still variant named by their metadata and hash manifests, including after file-reference renewal. Reject truncated photo/chat attachments and corrupt reused files instead of counting them as saved. Check recovered multi-account message IDs against missing intervals without expanding large gaps. - Release a session's local connection lock after transport shutdown, including when a disconnected client was already removed from the workspace. Cancelling the waiting operation cannot release the lock early, and closing an older session cannot unlock a different current key. - Apply a chat export's skip/hash-only choice to recovered messages and profile photos, and record that choice in the acquisition metadata. Reject changed messages before fetching attachments in the separate files stage. Count missing message numbers as intervals so sparse histories do not exhaust memory, including during a cancellable full recheck. - Preserve available self-destructing photos, videos and files in the API journal with a dedicated immediate queue, explicit TTL/view-once labels and signed saved/unavailable/not-saved outcomes. Block read receipts in the API client, including batches and wrapped requests. Keep byte limits, disk reserves and Telegram backoff; saved bytes do not establish human viewing. - Preserve image-rendered Unicode emoji in official Web message text, reply previews, reactions and derived page text without changing the client DOM. A live account test exposed the omission; video and saved pages already retained the image. - Improve chat-export Takeout, unreadable-message recovery, shared absent-number rechecks and bounded range retries. Preserve observed deletions in export scope, compare verified archives, and distinguish archive integrity from an independently confirmed signer. - Protect imported sessions from remote logout, close idle connections and prevent simultaneous reuse of a session key. Add explicit session management and masked two-step password entry; cancellation or switching workspaces prevents submission. Read single-account export messages before their separate attachment stage. - Keep source export and AI actions disabled while local source search is pending, empty or has failed; clear stale previews before the next search. Exercise delayed replies explicitly in browser checks. - Use unambiguous synthetic privacy identifiers and report the exact marker/context on handover-test failures, avoiding accidental matches inside report metadata. - Add an in-panel comparison of collection methods and explain account task ownership beside full-history controls. Refresh source-version badges, qualification records and Trusted Live network results; check version labels before publication. - Add [full-text search](https://phishdestroy.github.io/TgWitness/es/docs/reference/search/) (preview): Russian and Ukrainian word forms, English stems, Chinese and Japanese phrases without spaces, exact phrases, domains in hidden links and buttons, @usernames, wallets and phones, filters for chat, sender, message ID and observation period, ranked with BM25. The index is derived from the signed journal, bound to its latest record hash, never exported, and can be kept on disk, in memory only or turned off. Recognized text is indexed in memory only and labelled as machine recognition. - Ask the archive retrieves the best matches from the full-text index when it is complete, keeps the 24-source limit, and cuts long texts around their match. MCP `search_messages` accepts `ranked=true`. - Add `tgwitness index status|rebuild` with JSON output on stdout and stable exit codes. - Fix ranked search paging: `next_offset` is now returned when more matches exist, through `/api/search`, MCP `search_messages` and Ask the archive's partial marker. Paging stops at the first 1,000 results. - Fix Ask the archive failing on questions longer than 24 words or 200 characters. The full-text query keeps the question's first distinct words; a query the index cannot read falls back to exact-text retrieval. - Centre excerpts on the match in long texts that hide zero-width characters between letters. - Build the website when a language lacks new translations: untranslated blocks stay in English with the page notice and are listed by the build. - Add the [command line](https://phishdestroy.github.io/TgWitness/es/docs/reference/cli/) (preview): `tgwitness search`, `context`, `messages`, `stats` and `export` with `--json` and stable exit codes, reading a stopped workspace directly or a running panel through a scoped, revocable archive connection. Add `.agents/skills/tgwitness-cli/SKILL.md` for agents. - Add the `get_activity_stats` archive tool, also offered over MCP: messages by UTC hour and weekday, peak days, edit and deletion shares, senders, domains and @handles, with coverage gaps. Computed on request, not stored. - Add the `export_messages` archive tool for the command line: saved observations streamed as JSON Lines in journal order, with full text and a completion record. It is granted only when selected; existing connections keep the tools they were issued with. - Recheck archive access before every streamed record, including completion. Revoked or expired connections end without a completion record; lazy export reads share the archive worker limit and timeout. - `tgwitness index` and the new commands find the data directory of the installation that runs them. ## 0.9.1 preview · 5 November 2026 - Keep message and attachment outcomes visible after single-chat sealed capture, including missing data, failed files and unfinished downloads. Translate final status when changing language after shutdown, and clear connection or export errors once they recover while retaining rejected-action and unconfirmed-revocation warnings. - Update the pinned OAuthLib dependency to 4.0.1 for CVE-2026-49272 and regenerate the runtime, browser and MCP hash locks. - Show in-flight attachment bytes without counting them as preserved evidence, reset progress on retries and clear it on pause. Keep official-client chat controls disabled during QR/2FA login and until a chat is available. Explain that Takeout approval requires another previously signed-in device. Bound CI dependency installation and avoid the stalled Azure package mirror. - Add explicitly selected direct networking for official Web capture through GitHub Actions. Proxy remains the default and never falls back to direct. The panel and signed verification report disclose direct IP exposure, and verification rejects a mismatch between the selected route and the hosted network. - Add an optional official Telegram Web observation mode with passive or sequential paced viewing, a fresh profile, restricted UI actions, login-excluded video and signed rendered observations. A required proxy bridge prevents direct fallback; exit changes stop recording. The GitHub Actions mode uses the approved sealed workflow and recipient encryption. - Bind official recordings to independently saved source/settings, check video segment order and clean endings, record fresh drand rounds and support independent public-relay comparison. Report unfinished procedures, unconfirmed logout and the limits of local or Cloudflare assurance explicitly. See [Official client witness](https://github.com/phishdestroy/TgWitness/blob/main/docs/OFFICIAL-WITNESS.md) for scope and validation. - Add opt-in Trusted Live preview: isolated official Desktop/Web sessions, native JSON preservation, guarded visual recording, per-chat continuity annotations, and verifier-recomputed reports. Supply a Linux network guard with no direct fallback, periodic proxy-routed drand observations, and optional independent read-only Cloudflare samples. Account/WARP/TDX qualification remains pending; see `docs/TRUSTED-LIVE.md`. - Make sealed export modes explicit: Telegram Takeout by default, regular API account export, or a single-chat event journal, with differences and limits shown before collection. Select multiple chats, save agreed settings, verify them with `--expected-selection`, and reject incomplete account exports with `--require-complete`. Correct the outdated one-chat-only hosted documentation. - Preserve signed message pages before requesting files or hashes. Resume from frozen history, retain completed attachments, and finish an interrupted export with explicit gaps when time or disk is limited. - Add Telegram Desktop compatible JSON/HTML views alongside authoritative signed data. GitHub capture supports full-account and selected-chat exports through regular API or Takeout, with chat types, dates and media settings. - Deliver large GitHub archives in encrypted parts with a signed, attested manifest and verified local assembly. Remove the fixed 4 GiB delivery failure without omitting preserved evidence. - Retry transient pinned OCR source downloads without relaxing checksum checks. Retry brief Windows file-sharing failures when saving private state. - Configure account exports before collection: select chats and media types, exclude avatars by default, and choose downloads, Telegram range hashes or metadata only. Keep a shared attachment budget and record incomplete files explicitly. - Show Takeout approval requirements and retry deadlines before collecting; check approval again without replacing the waiting session. Phone, QR and existing-session login retain their own authorization flow. - Save Telegram-provided SHA-256 ranges with file representation and data-center metadata. Compare them against locally supplied files; Telegram identifiers and access hashes are not treated as content hashes. - Collect message history across selected chats before processing attachments when messages-first mode is enabled. Preserve the journal in a compact export when full HTML or attachment packaging exceeds the remaining capacity. - Stream sealed delivery encryption without a second full plaintext archive. Remove interrupted ciphertext, preserve the original evidence for retry, and keep capture deadlines across runner steps with time reserved for delivery. - Require sealed-container validation in the release workflow. Phala deployment status now distinguishes verified, incomplete and review-required attestation instead of inferring trust from the provider name. - Validate every sealed-container build input against its pinned source. Retry transient package downloads up to three times while retaining signature, SHA-256 and exact-package checks before offline installation. - Include the hash-export configuration examples in source archives and preserve the translated documentation and required site assets from the latest main revision. - Keep the current tunnel address when an older signed address post is replayed. Signed posts are ordered by their signed time; unsigned posts use the relay's receive time. - Trust only the Caddy proxy on the private Docker HTTPS network and normalize client addresses for authentication limits. - Keep operator IP addresses out of new signed access events, hide administrative payloads from shared views, and enforce workspace and export ownership boundaries. - Reject duplicate JSON keys, prepended ZIP content and HTML injected into report seals; distinguish pinned witness keys from pinned collector keys. ## 0.9.0 preview · 4 November 2026 - Reserve each account exclusively for monitoring, history or an export. Serialize Telegram RPCs and persist full FloodWait deadlines. - Add durable distributed chat exports with date/language/reply filters, bounded labelled context, signed chunks and explicit pause/resume. See [Distributed chat export](https://github.com/phishdestroy/TgWitness/blob/main/docs/DISTRIBUTED-EXPORT.md). - Keep account reservations until every export worker has stopped, including repeated pause requests and sibling worker failures. History loading in sealed sessions also reserves the account exclusively. - Add participant timelines from saved observations: names, membership, explicit deletion flags and message activity. Profile refreshes are bounded; optional presence recording preserves unavailable or expired status as unknown and does not attribute online activity to a chat. - Save, import and reuse report layout profiles without copying case details or report filters. Profiles are validated and isolated by workspace. - Automatically offload eligible attachments to configured external storage under disk pressure, with reserve-space checks, compression, optional encryption and full readback verification before local eviction. Journals remain local. - Make the recording settings and chat tabs fit narrow screens, including wider system fonts, and fix profile controls and localized labels. - Include reviewed website assets in source archives and verify conditional dependency versions in SBOM inventories. - Phala Cloud deployments work on Phala Cloud itself (first real run, 4 November 2026): the compose carries its name, Phala's own pre-launch script is kept out of the measured app-compose, the production OS image is chosen instead of Phala's development default, the instance ID is read from the CVM state, and restarts from the CVM's operations count in `provider_actions`. Private Phala regressions simulate each of these. - `tdx_os` without outside tools: the verifier downloads the published dstack OS image once, matches it to the hash the CVM reports and computes MRTD and RTMR0-2 itself, the ACPI tables QEMU builds for the VM's shape included. A development image, other firmware, kernel, command line, memory, vCPUs or devices fail. Each journal start is checked the same way. - Attestation certificate for Phala deployments: `verify --report` also writes HTML and a signed PDF, sealed by a qualified eIDAS time stamp from the Belgian government's time-stamping authority, a FreeTSA time stamp and the verifier's own key; `check-report` checks the seal. - Quick tunnel addresses are also posted signed with the collector key, so a verifier is not misled by forged posts on the address topic; on Phala Cloud the tunnel check passes, since its connector runs inside the measured compose. ## 0.8.1 preview · 2 November 2026 - Runtime, sealed and media containers moved to pinned Wolfi/glibc with Python 3.12 and hash-locked system packages (AMD64 + ARM64). Image scans are clean of HIGH/CRITICAL. - Tesseract 5.5.4 built from verified source, English and Russian data pinned. - Release checks now cover real OCR, offline transcription, signed multilingual PDFs and container restrictions. The source archive includes all container build inputs. - **Extras → Independent capture** in the English panel: browser/AyuGram recorders with encrypted tokens, pinned keys, tab selection, start/pause, snapshots, checkpoints and verified ZIP downloads. Everything is off by default. - New optional `tgwitness-capture` package: Chromium PNG/MHTML snapshots, AyuGram SQLite copies, optional silent video, Ed25519 event chains, signed ZIP/HTML reports and a standalone verifier. Each recorder has its own key and storage. - Fixed Phala installs: source bundles were missing the capture package. ## 0.8.0 preview · 2 November 2026 **Reports** - Report studio: eight designs (Classic, Editorial, Briefing, Analytics, Technical, Overview, Reading series, Ledger & margin), live preview, HTML and native signed PDF. Switching designs keeps filters, charts and notes. - Pick report data by chat, author, date and event type and preview it before saving. Edits show before/after, deletions show what was saved earlier. - Reports look like proper dossiers now: cover, key figures, evidence map, numbered findings, timeline. PDFs get an A4 cover with QR, bookmarks and page refs. - Each report explains what its conclusions rest on: export-time checks, observations, missing material, how to check it independently (EN/RU/DE wording). - Send, edit and observed times are shown separately, plus replies, threads and metadata. **Case Board and groups** - Private Case Board: signed bookmarks, exact-version highlights, action slices, collections, threaded comments and statuses. Team notes stay apart from observations; the verifier checks board exports too. Export permission alone doesn't reveal team notes. - Account groups share settings. Members follow the group, an account's own value wins until reset. Changes show which accounts they hit and ask before overwriting. Access can be granted to a whole group. - Group screen at `/groups/`: accounts, problems, shared chats, group export. **Setup and connection** - Six-step first setup and one Settings page with simple/standard/expert levels, in all 25 languages. Each step has its own URL, Back works. - The setup asks whether the account is a separate one; a main account only records chosen chats. After Start it shows that connection, events, sources and files work. - Guided Connection screen: pick accounts, prepare and check a route, then apply. Direct, own proxies, public MTProto pool, WireGuard profiles and portable WARP. - Automatic connection tries public MTProxy, then WARP, then direct (if allowed) and shows a status indicator instead of failing silently. - Video duration limits in file policies. **Panel and safety** - No more one-click accidents: pausing, excluding and removing sources are confirmed, sending from a chat needs "Write as @account" first, route changes while observing offer to pause. - One set of counters everywhere (deleted with text, deleted before saving, missing on recheck). - Account files are inspected before connecting. URL, workspace and account always agree, a mismatch blocks actions. Chats open read-only and mask detected secrets. - Downloads fall back to normal browser downloads, big archives stream through one-time cookies. Prepared exports keep size, SHA-256 and "Download again". - Panel token rotation keeps the new session alive. Temporary network failures offer Retry. - Panel dialogs instead of `window.confirm`, journal paging fixed, lots of small UI fixes. - Public-channel showcase: expiring read-only links with redacted authors and signed snapshots. **Servers and evidence** - Extras → Server 24/7: a Hetzner server from the panel with a quick tunnel or your own domain. `python -m tgwitness.cloud destroy` cleans everything up. - Phala Cloud option: the collector runs in an Intel TDX confidential VM, `verify` checks the attestation up to Intel's root. - Gateway DNS (`--gateway-dns`): the server only resolves through Cloudflare Gateway. - Optional drand rounds and Telegram device lists in evidence mode. - Setup by goal: four questions, suggested settings, credibility and reliability scales. **Other** - Notification service catalog with icons, optional operator control bot, Discord witness posts. - Storage separates backups, verified file offloading and evidence retention. - AI previews show the endpoint and outside route. - Pull requests run both panel suites, including Firefox and WebKit downloads. Release packages wait for dependency, CodeQL and container audits. - Docs: a [panel guide](https://phishdestroy.github.io/TgWitness/es/docs/reference/panel/) for every screen. ## 0.7.1 preview · 1 November 2026 - **Start here** with two paths: export my account, or follow an investigation. - Account export through Telegram Takeout or the regular API, resumable, with signed progress and coverage records ([account export](https://phishdestroy.github.io/TgWitness/es/docs/reference/account-export/)). - Separate signed sharing copies with filters, pseudonyms and optional text/file removal. Signatures establish integrity; they do not establish Telegram authorship, completeness or legal admissibility. - Readable offline reports for account exports and sharing copies, printable, with record links and instructions for the recipient. - Clear handoff after download: original vs sharing copy, report preview, instructions to copy. - Rejected Telegram logins are told apart from paused accounts and network errors. **Sign in again** keeps the workspace. - Load the history of enabled sources with pause/resume, plus a signed progress report ([history](https://phishdestroy.github.io/TgWitness/es/docs/reference/history/)). - Read-only MCP at `/mcp`, local archive search with optional AI, local OCR/transcription, signed webhooks with retries. - GitHub Actions capture preview: one chat on a temporary runner, encrypted result, pinned provenance ([sealed capture](https://github.com/phishdestroy/TgWitness/blob/main/docs/SEALED-ACTIONS.md)). - Self-contained signed reports in 25 languages with chain of custody; archives add `custody.json` and `SHA256SUMS`. - Panel rework: workspace URLs, Back/Forward, drafts survive updates, Ctrl/Cmd+S, Sources split into tabs, Parameters search, journal filters and inspector, live updates. - Batch session import, account groups, MTProxy dashboard with ping, countries and own lists. - MTProxy decryption through OpenSSL (it used to eat a whole CPU core). - Stronger masking in sharing copies, bounded media decoding, repeatable source ZIPs. - Notification services refuse redirects. Weekly Dependabot, nightly CodeQL and container scans. - Lots of fixes: stuck chat profiles, quick search, DST in search dates, 502s behind Caddy, GIF/sticker downloads, slow proxy list parsing, duplicate sessions on import. ## 0.7.0 preview · 31 October 2026 - OpenTimestamps proofs are parsed strictly; Bitcoin attestations show as `bitcoin-unverified` until you run `ots verify`. - Verification reports which part of the journal witness checkpoints cover; `--require-witness` demands a pinned witness and matching final record. - Access and permissions guides, updated proxy and IP mode guides. - Panel and docs site in 25 languages. Site publishing fails on missing translations. - Added the [roadmap](https://github.com/phishdestroy/TgWitness/blob/main/docs/ROADMAP.md). ### Initial preview contents · 30 October 2026 - First GitHub release: Windows portable, wheel, source archive. - The setup guide has an "Open to everyone" section: no country or sanctions blocks, and Taylor Wessing as the only incompatibility we name. It is our position, not a licence condition. - The README and Wiki now present the authors' Ethical Notice & Historical Continuity statement, with document references, historical context and an explicit explanation that MIT permission applies to everyone. - The operator notice and the Taylor Wessing page speak in our own voice. - Returned to the MIT License. A tool whose output third parties must be able to check should not stumble over its licence. `LICENSE` is the standard MIT text again, the package declares MIT with the OSI classifier, and the container, portable package, website, Wiki and translated README labels say so. Our statement stays in NOTICE and on the Taylor Wessing page as our position; it adds no licence condition. The presentation artwork reads "open source" again. - Added our Operator Incompatibility NOTICE to README, SECURITY, the documentation, Wiki and website. A single source keeps the complete statement consistent across those pages; source, Python and portable distributions include NOTICE alongside the licence. - High-assurance deployment (`python -m tgwitness.cloud`, [guide](https://phishdestroy.github.io/TgWitness/es/docs/reference/high-assurance/)) on Hetzner, DigitalOcean, Linode, Vultr or EC2: no SSH key, no inbound ports, panel only through a Cloudflare Tunnel, and a `verify` command for third parties. - Local launchers open the panel in the browser once it's up. - Read-only online demo of the real panel with fictional data. - Wiki with 13 guides, docs website with a reference section, search, diagrams and 13 languages. - **Sign out of Telegram** on the Account page. - About 940 Russian panel strings fixed by hand. - Observation scope: chosen chats, a folder or the whole account, by type. New chats are picked up immediately. - Investigation mode for accounts that join groups and talk to bots. - People profiles (opt-in per chat), independent witness bot, notification excerpts, Parameters page, light/dark theme. - Panel mini-client: send messages, press bot buttons, preview and join invites. - Fixed message loss after a long stop (rechecks used to stop after 1,000 messages). - Many fixes from a full review: attachment byte counts, restore checks, scope edge cases, verify.py witness handling, off-site copy retries. - Pillow 13 (39 advisories against 12.3). ## 0.6.1 · 27 October 2026 - Renamed TgWatch to TgWitness, old archives still verify. - Evidence mode timestamps checkpoints with RFC 3161 and OpenTimestamps. - Password-protected AES-256 ZIP exports. - Notifications through Apprise. - 13 interface languages; README, Quick start and Deployment in 12 languages. - Encrypted off-site copy to S3-compatible storage with Object Lock. - Catch-up after restart and rechecks every 15 minutes. - Built-in pool of public API pairs, no own API ID needed. - New Chats view, Accounts view, multi-account chat export, signed full chat export. - Windows portable package, public website, GitHub Pages workflow. - Better launchers on all platforms, redesigned panel, new logo. ## 0.6.0 · 27 October 2026 - New account form with Phone, QR code, Files and Auth key tabs. - Auth Key + DC ID sign-in, Telethon/Pyrogram sessions, TData ZIPs, StringSession, account JSON. - QR login with 2FA, Desktop local passcodes. - Demo opens on its sample journal; refreshed panel look. ## 0.5.1 · 27 October 2026 - Only the active account client is accepted; rejected logins are disconnected. - Windowless Windows launches with logs in `logs/server.log`. - Case-insensitive Unicode search, full UTC dates on phones. - Linux/macOS launch scripts, Docker helpers, optional HTTPS with Caddy, GHCR images. - Docs on export signatures and investigation handoff. ## 0.5.0 · 26 October 2026 - Per-account monitoring categories, presets and signed policy changes. - Direct local entry to synthetic demos. Older history: [release status](https://github.com/phishdestroy/TgWitness/blob/main/docs/internal/RELEASE.md) and [verification](https://phishdestroy.github.io/TgWitness/es/docs/reference/verification/). --- # Un diario. Cuatro modos de recopilación. Ocho niveles de verificación. Canonical page: https://phishdestroy.github.io/TgWitness/es/guides/modes.html Ámbitos de recopilación, límites de eventos, ocho mecanismos de verificación y seis escenarios de investigación ficticios. [Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/) [Documentation index](https://phishdestroy.github.io/TgWitness/es/llms.txt) Modos, escenarios y niveles de evidencia TgWitness Registra lo que observa la cuenta conectada. Un tercero puede verificar la integridad del registro comparándolo con una clave de confianza independiente. [Modos de recopilación](https://phishdestroy.github.io/TgWitness/es/guides/modes.html#scope)[Escenarios](https://phishdestroy.github.io/TgWitness/es/guides/modes.html#scenarios)[Niveles de evidencia](https://phishdestroy.github.io/TgWitness/es/guides/modes.html#levels) Resumen de 3 a 5 minutos · ejemplos ficticios · implementación actual 1. **Telegram** Actualizaciones visibles en la cuenta 2. **Recopilador** Registros vinculados, cada uno de ellos firmado 3. **Verificador** Clave de confianza + límite conservado `h₁ → h₂ → h₃ · Ed25519`Se comprueba la integridad. El origen de Telegram y la veracidad de un mensaje siguen siendo cuestiones distintas. ## Elija el ámbito de observación Tres ámbitos y un ajuste preestablecido de investigación. Las exclusiones y los tipos de fuente habilitados siguen siendo aplicables. Por defecto**Chats seleccionados** Registros Únicamente fuentes seleccionadas manualmente. Nuevos chats No se añade automáticamente. Elija Un conjunto conocido de canales o grupos. No se ha especificado ninguna capacidad fija para los chats. **Qué no hace** No detecta otros chats ni completa el historial anterior. Carpeta de cuentas**Carpeta de Telegram** Registros Incluye carpetas y categorías, excluyendo los chats excluidos y archivados cuando así se haya configurado. Nuevos chats Coincidencia de chats activos; cambios en las carpetas en el plazo de una hora. Elija Un analista ya mantiene una carpeta del caso. Confirme la recopilación en una cuenta específica. **Qué no hace** No se aplican las condiciones variables de la carpeta muted/read de la carpeta. Confirme el ámbito de aplicación**Cuenta completa** Registros Chats visibles para la cuenta, incluidas las conversaciones privadas y los bots, dentro de los tipos seleccionados. Nuevos chats Se añadirá cuando llegue la primera actualización. Elija Una cuenta dedicada a la observación, incluida una cuenta que participe en un caso. **Qué no hace** No se une a los chats automáticamente ni elude el acceso a la fuente. Configuración preestablecida para toda la cuenta**Modo de investigación** Registros Todos los tipos de fuentes, las acciones propias, los perfiles de las fuentes y los últimos 200 mensajes visibles de las fuentes recién descubiertas. Nuevos chats Cada nuevo chat o bot obtiene un perfil y una instantánea del historial. Elija Únase a un equipo o interactúe con un bot a través del panel. Revise y guarde la configuración preestablecida. **Qué no hace** No realiza instantáneas de todos los chats existentes ni observa las llamadas de retorno activadas en otro cliente. Estas tarjetas constituyen una comparación local, no controles del colector en tiempo real. No modifican ninguna cuenta. **Qué no hace** Ningún modo lee chats secretos, registra mientras el proceso está detenido, se une a fuentes por su cuenta ni recupera el historial anterior más allá de lo solicitado snapshot/export. [Lea los detalles](https://phishdestroy.github.io/TgWitness/es/docs/reference/collection/) ## Captura con GitHub Actions (versión preliminar) Un nuevo inicio de sesión en Telegram, un chat, un archivo cifrado y procedencia de GitHub. [Abrir el asistente de captura](https://phishdestroy.github.io/TgWitness/es/docs/capture/) ## Lo que se registra Solo se incluyen en el registro las observaciones entregadas o solicitadas explícitamente. La atribución desconocida permanece desconocida. Captura de conmutadores · ilustración localNuevos mensajesModificacionesEliminacionesReaccionesAfiliación El panel aplica estos modificadores por espacio de trabajo. Desactivar uno conserva los registros existentes; volver a activarlo no reconstruye los eventos perdidos. **Matriz de eventos: material guardado y incógnitas pendientes** | Categoría | Guardado | Sigue sin conocerse | | --- | --- | --- | | Mensaje | Texto, identificadores, metadatos del remitente, contexto de la respuesta y sobre de actualización original. | No existe una firma de Telegram verificable por terceros. | | Editar | Todas las versiones observadas, sin sobrescribir las anteriores. | Es posible que se pasen por alto las modificaciones intermedias; el remitente no es necesariamente el editor. | | Eliminación | Aviso más el texto guardado anteriormente, si está disponible. | No se facilitan el eliminador ni la hora exacta de la acción. | | Eliminación sin ámbito | Aviso a nivel de cuenta; el par desconocido sigue siendo explícito. | No se deben adivinar los chats. La correlación utiliza, siempre que sea posible, los identificadores guardados previamente en el ámbito de la cuenta. | | Reacción | Contadores entregados e identidades recientes visibles. | No todos los reactores son visibles; para obtener una lista completa de los disponibles se necesitan consultas independientes. | | Afiliación | Mensajes de servicio entregados y actualizaciones de los participantes. | El rol y el tipo de chat limitan la visibilidad; el silencio no implica ausencia. | | Archivo adjunto | Descriptor de la versión original, bytes guardados, SHA-256 y resultados de los intentos. | Es posible que un archivo desaparecido no esté disponible; una versión más reciente no lo sustituye. | | Instantánea del historial | Mensajes visibles actualmente, marcados como observaciones del historial. | Las ediciones anteriores y el contenido desaparecido no se reconstruyen. | | Acciones propias | Saliente messages/edits y los metadatos correspondientes del teclado de respuesta button_press . | Las llamadas de retorno activadas en otro cliente de Telegram no son visibles. | | Botones del bot | Los metadatos de callback, URL, aplicación web y solicitud se conservan junto con el mensaje. | Las URL y phone/location las solicitudes son texto; no se abren ni se ejecutan automáticamente. | ### Límites predeterminados para los archivos adjuntos Fotografías 20 MiB Vídeo 100 MiB Archivos 50 MiB Animaciones 20 MiB Notas en vídeo 50 MiB Voz 20 MiB Audio 50 MiB Pegatinas 5 MiB **Qué no hace** Un conmutador no suprime los metadatos incrustados ni desactiva los registros operativos. La captura no identifica a ningún actor que Telegram no haya facilitado. [Lea los detalles](https://phishdestroy.github.io/TgWitness/es/docs/reference/collection/) ## Utilice la autorización de la que dispone Cada cuenta dispone de su propio espacio de trabajo, diario, clave de firma, ruta y cola. ### Teléfono + código Introduzca 2FA cuando esté habilitado. ### QR código Realice el escaneo desde un dispositivo autorizado; 2FA puede que siga siendo necesario. ### Telethon .session Importe el archivo de sesión de la cuenta. ### Pyrogram .session Importe el Pyrogram formato de sesión compatible. ### TData ZIP Se admite una sola cuenta de Desktop; código de acceso local, si se ha configurado. ### StringSession texto Pegue un Telethon StringSession. ### .session + .json Seleccione la sesión y los metadatos asociados correspondientes. ### Clave de autenticación HEX + DC ID Importe la autorización de la cuenta junto con su identificador de centro de datos. **API par** Su propio API par es opcional. Si no dispone de uno, TgWitness se utiliza un conjunto de pares públicos, incluidos los del cliente oficial de Telegram Desktop. `Direct · SOCKS5 · HTTP CONNECT · MTProxy`MTProxy es experimental; las listas públicas integradas MTProxy . Una ruta de proxy fallida no recurre a una conexión directa. Dos espacios de trabajo en un mismo equipo no constituyen dos testigos independientes. **Qué no hace** La importación no elude la autorización de Telegram, 2FA ni los formatos de sesión no compatibles. Las cuentas siguen compartiendo el proceso de la aplicación. [Formatos de cuenta](https://phishdestroy.github.io/TgWitness/es/docs/reference/accounts/) ## Actúe desde el panel Envíe o responda, pulse un botón del bot actual, guarde una vista previa del enlace y, a continuación, únase explícitamente a un chat o inicie un bot con su parámetro de inicio. `interaction.preview``interaction.requested``interaction.result` Los acuses de recibo de vista previa, solicitud y resultado están firmados. Antes de pulsar un botón, el servidor vuelve a recuperar el mensaje y rechaza cualquier modificación introducida mediante el teclado. El texto y las URL de la llamada de retorno siguen formando parte del contexto registrado. **Qué no hace** No se admiten aplicaciones web, pagos, phone/location compartir ni consultas en línea. Mostrar una URL no implica abrirla. [Lea los detalles](https://phishdestroy.github.io/TgWitness/es/docs/reference/collection/) ## Recuperación y continuidad Las lagunas se muestran, no se ocultan. ### Reanude la posición guardada Tras el reinicio, se solicita a Telegram las actualizaciones perdidas. La retención finita y las diferencias caducadas pueden dejar lagunas. ### Vuelva a comprobar los mensajes visibles Valores predeterminados: fuentes prioritarias cada 15 minutos; el resto, cada 6 horas. Los resultados incluyen message.recovered y message.missing_on_recheck. ### Leer coverage.json Los periodos de observación, las lagunas con sus motivos y los ID no observados acompañan a la exportación firmada. Un registro que no aparece tras una nueva comprobación no constituye un aviso de eliminación. **Qué no hace** Una instantánea posterior del historial no borra una interrupción del servicio ni recupera todas las versiones desaparecidas. El cursor guardado no constituye un acuse de recibo sin pérdidas de la aceptación del diario. [Lea los detalles](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/) ## Siete niveles. Diferentes preguntas. Cada mecanismo responde a una pregunta delimitada. Configure los servicios externos por separado y mantenga sus anclajes de confianza fuera del recopilador. 1. ### Registro SHA-256 cadena + Ed25519 por evento; el primero previous_hash son 64 ceros. **Comprobaciones de terceros** Ordenación y firmas bajo la clave del colector fijada. **Qué no hace** No demuestra el origen ni la integridad de Telegram. **Comando de verificación** ``` python -m tgwitness.verify evidence.zip --fingerprint TRUSTED_SHA256 ``` 2. ### Contenedor manifest.json enumera los hash de los archivos; manifest.sig lo firma. media.saved vincula los bytes de los archivos adjuntos a un evento. **Comprobaciones de terceros** Los archivos proporcionados coinciden con el manifiesto firmado y los recibos multimedia. **Qué no hace** No firma una CSV, HTML o de una captura de pantalla. **Comando de verificación** ``` python -m tgwitness.verify evidence.zip --fingerprint TRUSTED_SHA256 ``` 3. ### Límite conservado Punto de control al inicio, cada 5 minutos por defecto, y parada ordenada. Guarde una copia en otro lugar. **Comprobaciones de terceros** La exportación posterior concuerda con una longitud y un encabezado conservados anteriormente; se puede detectar una reversión. **Qué no hace** No detecta la sustitución tanto del diario como de todos los puntos de control conservados. **Comando de verificación** ``` python -m tgwitness.verify evidence.zip --fingerprint TRUSTED_SHA256 --checkpoint checkpoint.json ``` 4. ### Hora externa El modo de evidencia envía un punto de control SHA-256 a RFC 3161 autoridades (FreeTSA, DigiCert) y OpenTimestamps a los calendarios. **Comprobaciones de terceros** Una respuesta TSA verificada fecha esos bytes; una OpenTimestamps prueba los vincula a Bitcoin. **Qué no hace** No considera una solicitud preparada ni un acuse de recibo pendiente del calendario como una marca de tiempo confirmada. **Comando de verificación** ``` python -m tgwitness.verify evidence.zip --fingerprint TRUSTED_SHA256 --tsa-ca trusted-ca.pem ots upgrade checkpoint.ots ots verify checkpoint.ots ``` 5. ### Testigo independiente Separar el host, el punto final de solo lectura con ámbito limitado, el desafío nuevo y su propio key/journal y TGW1 publicaciones del canal. **Comprobaciones de terceros** Cabezas aceptadas anteriormente; estados «ok», key_changed, «rollback», «fork», «invalid» y no_response. **Qué no hace** No convierte dos espacios de trabajo en un mismo host colector en testigos independientes. **Comando de verificación** ``` python -m tgwitness.verify evidence.zip --fingerprint TRUSTED_SHA256 --witness witness.zip --witness-fingerprint WITNESS_SHA256 --channel result.json ``` 6. ### Réplica externa S3Copia compatible con [...], cifrada con AES-256-GCM; Object Lock cuando el depósito lo admita. **Comprobaciones de terceros** La función «Restore» solo publica los archivos una vez que se haya completado con éxito la verificación del diario, del punto de control y de los medios conservados. **Qué no hace** No se restaura sin la clave exportada ni se da por hecho que se conserva sin comprobar la respuesta de almacenamiento. **Comando de verificación** ``` python -m tgwitness.replica restore --key-file KEY.json --out EMPTY_DIR ``` 7. ### Ejecutar la procedencia Recibo de ejecución firmado: hash de código fuente, versiones de dependencias y contexto del proceso. Autodeclarado. **Comprobaciones de terceros** Lo que el recopilador de firmas informó sobre su propia ejecución. **Qué no hace** No proporciona una certificación independiente del proceso ni excluye la posibilidad de que se haya producido una vulneración antes del registro. **Comando de verificación** ``` python -m tgwitness.verify evidence.zip --fingerprint TRUSTED_SHA256 ``` ### Lo que ningún nivel demuestra Entrega de cada actualización de Telegram; la veracidad del texto; que el identificador del remitente identifique a una persona real; la ausencia de compromiso del recopilador antes del registro; la admisibilidad ante los tribunales. [Testigo independiente](https://phishdestroy.github.io/TgWitness/es/docs/reference/witness/) Experimento SHA-256 experimento ### Intente modificar el registro 2 El siguiente registro conserva el enlace guardado anteriormente. Al modificar el texto, cambia el hash calculado del registro 2. Texto del registro 2 Registro 1`h1`Comienza con 64 ceros Registro 2`h2`Incluye los archivos guardados h1 Registro 3`h3`Incluye los archivos guardados h2 Ejemplo estático: h2 incluye «Quedamos a las 11:00». Si se modifica ese texto, se modifica h2; el registro 3 sigue haciendo referencia al guardado h2. **Revise los resúmenes completos** Hash del registro 2 guardado `SHA-256(e₂)` Hash del registro 2 recalculado `SHA-256(e₂)` Este ejemplo calcula hash, no firmas. El verificador real comprueba cada firma y cada enlace con respecto a la clave de confianza. [Lea los detalles](https://phishdestroy.github.io/TgWitness/es/docs/reference/how-it-works/) ## Elija una ruta a través de las pruebas Situaciones ficticias. Comience la recopilación antes del suceso relevante; conserve los límites y las lagunas junto con el contenido. ### Un canal modifica los datos de pago Modo → eventos Chats seleccionados → mensajes, modificaciones, eliminaciones. Salida Versiones de las publicaciones y archivos adjuntos observados mediante hash. Verificación Firmado ZIP + punto de control conservado + respuesta TSA verificada. **Qué no hace** No recupera un original que nunca se haya capturado. ### Los mensajes desaparecen tras un incidente Modo → eventos Carpeta o cuenta completa → todas las categorías de eventos. Salida Originales guardados, avisos de eliminación y cobertura con lagunas. Verificación Firmado ZIP + diario de testigos independiente. **Qué no hace** No identifica al autor de la eliminación a partir de una notificación que no indica quién la ha realizado. ### Investigue un bot de tienda Modo → eventos Configuración predeterminada de investigación → botones, vistas previas de enlaces e inicio explícito del bot. Salida Recibos de interacción firmados, devoluciones de llamada y perfiles guardados. Verificación Firmado ZIP; verifique cualquier expediente con respecto al ZIP. **Qué no hace** No abre una aplicación web de bot, no realiza pagos ni registra las respuestas de otro cliente. ### Un participante cambia de nombre de un chat a otro Modo → eventos Cualquier ámbito → metadatos sender/profile metadatos observados. Salida Historial de nombres/nombres de usuario por ID numérico, enlaces «también en» y pistas extraídas. Verificación Expediente JSON comparado con el firmado ZIP. **Qué no hace** No convierte una cartera, una cadena similar a la de un teléfono o un nombre de usuario en una identidad verificada. ### Observación a largo plazo con una copia externa Modo → eventos Cualquier ámbito → Modo de evidencia y una S3 réplica con compatibilidad Object Lock. Salida Copia cifrada, puntos de control conservados y respuestas con marca de tiempo. Verificación Restaure con la clave exportada y, a continuación, verifique sin el servidor original. **Qué no hace** No sustituye a un testigo independiente ni a una clave de descifrado conservada por separado. [Lea los detalles](https://phishdestroy.github.io/TgWitness/es/docs/reference/investigation/) ## Entregue un paquete que se pueda verificar Proporcione el original firmado, una huella digital de la clave conservada de forma independiente, el punto de control pertinente y el resultado de la verificación. - Firmado ZIP - JSONL - CSV - HTML - Punto de control - Confirmación de entrega - Exportación de chats: chat.json / chat.html - Expediente JSON - Protegido con contraseña AES-256 ZIP - Exportaciones separadas para varias cuentas - CLI de transmisión: 5 GiB límite por defecto ``` python -m tgwitness.verify evidence.zip --fingerprint TRUSTED_SHA256 --checkpoint checkpoint.json ``` Obtenga el verificador a partir de una copia de confianza, no del archivo que se está comprobando. **Qué no hace** Autónomo CSV y HTML no son contenedores firmados. Una contraseña protege la confidencialidad de la transferencia, no su autenticidad. Las exportaciones múltiples no fusionan los registros de las cuentas. [Lea los detalles](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/) ## Compare el artefacto entregado Artefactos básicos sin sistemas añadidos de firma, marca de tiempo o testigos. Los scripts y los registradores varían según la implementación; «parcial» significa limitado al material capturado o visible. | Enfoque | Modificaciones / eliminaciones | Registrar la firma | Hora externa | Testigo independiente | Cobertura / lagunas | Verificación sin autor | | --- | --- | --- | --- | --- | --- | --- | | Exportación de Telegram Desktop | Parcial | No | No | No | No | No | | Telethon script de instantánea | Parcial | No | No | No | No | No | | Registrador de eliminaciones: registro de texto | Parcial | No | No | No | No | No | | Capturas de pantalla / captura web | Parcial | No | No | No | No | No | | TgWitness con extras configurados | Parcial | Sí | Sí | Sí | Parcial | Sí | **Qué no hace** La tabla no evalúa todos los scripts ni todos los productos de registro. Las comprobaciones opcionales de tiempo y de testigos requieren sus propios servicios y puntos de referencia de confianza; ninguno de ellos establece la veracidad de la fuente. [Lea los detalles](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/) ## Mantenga los límites dentro de las pruebas La verificación resulta útil cuando su ámbito de aplicación se mantiene explícito. - Los chats secretos no están disponibles. - No se registra nada mientras el proceso está detenido; la recuperación es limitada. - Un registro verificado no es prueba de que su contenido sea cierto. - Un operador que disponga de la clave puede firmar cualquier contenido. Los testigos independientes y las marcas de tiempo impiden la sustitución posterior, pero no la captura inicial fraudulenta. - Utilice una cuenta específica, no su cuenta principal. - Telegram puede restringir cuentas debido al volumen de solicitudes. **Qué no hace** Ningún modo ni nivel de evidencia establece la admisibilidad legal, la entrega completa de Telegram ni la identidad en el mundo real. [Guía de configuración](https://phishdestroy.github.io/TgWitness/demo/guide.html?lang=es)[Cuenta dedicada](https://phishdestroy.github.io/TgWitness/es/docs/dedicated-account/)[EVIDENCE.md](https://phishdestroy.github.io/TgWitness/es/docs/reference/evidence/)[INVESTIGATION.md](https://phishdestroy.github.io/TgWitness/es/docs/reference/investigation/)