# Як працює система збереження доказів

Canonical page: https://phishdestroy.github.io/TgWitness/uk/docs/reference/how-it-works/

Пояснення щодо хеш-ланцюга, підписів, контрольних точок та свідків із зазначенням точних формул, які використовує верифікатор.

TgWitness зберігає дані, зафіксовані обліковим акаунтом, пов’язує ці спостереження у підписаний журнал і дозволяє іншій особі перевірити експорт за допомогою надійного ключа та раніше збереженої контрольної точки.

[Місцевий веб-сайт документації](https://github.com/phishdestroy/TgWitness/blob/main/docs/internal/PUBLISHING.md#preview-the-website-locally) містить інтерактивні приклади за адресою `/docs/concepts/`, а також інструмент для аналізу рішень на контрольних точках за адресою `/docs/witness/`. Усі приклади повідомлень, кількість та затримки є вигаданими. Хеші в пісониці ланцюга обчислюються за допомогою алгоритму SHA-256 у браузері. Ніщо не надсилається до Telegram.

## Повідомлення змінюється; спостереження накопичуються

Діаграма послідовності · Telegram → Collector: Нове повідомлення: Зустріч о 10:00; Collector → Підписаний журнал: Додати повідомлення.new; Telegram → Collector: Редагування: Зустріч о 11:00; Collector → Підписаний журнал: Додати повідомлення.edited; Telegram → Collector: Повідомлення про видалення; Collector → Підписаний журнал: Додати повідомлення.deleted; Примітка щодо Підписаний журнал: Зберігаються спостереження за оригінальними повідомленнями, редагуваннями та видаленнями · Telegram · Collector · Підписаний журнал · Нове повідомлення: Зустріч о 10:00 · Додати повідомлення.new · Редагування: Зустріч о 11:00 · Додати повідомлення.edited · Повідомлення про видалення · Додати повідомлення.deleted · Зберігаються спостереження за оригінальнимиповідомленнями, редагуваннями та видаленнями

**Діаграма у вигляді тексту**

1. Telegram → Collector: Нове повідомлення: Зустріч о 10:00
2. Collector → Підписаний журнал: Додати повідомлення.new
3. Telegram → Collector: Редагування: Зустріч о 11:00
4. Collector → Підписаний журнал: Додати повідомлення.edited
5. Telegram → Collector: Повідомлення про видалення
6. Collector → Підписаний журнал: Додати повідомлення.deleted
7. Примітка щодо Підписаний журнал: Зберігаються спостереження за оригінальними повідомленнями, редагуваннями та видаленнями

Ця спрощена послідовність передбачає, що Telegram доставив кожне оновлення і що вибраний акаунт міг його побачити. Операційні події також заносяться до журналу. Повідомлення про видалення не вказує особу, яка здійснила видалення, або точний час видалення. Повторні доставки є окремими спостереженнями; у журналі не відбувається придушення дублікатів.

## Що охоплює хеш

![Спостереження, кодування, хешування та підписання: кожна нова подія містить хеш попередньої події.](https://phishdestroy.github.io/TgWitness/assets/evidence-chain-animated.svg)

Прочитайте формулу зсередини назовні: **C** перетворює дев’ять полів на точні байти; **SHA-256** генерує їхній дайджест; **hex** — це спосіб зберігання цього дайджесту. Попередній хеш уже міститься всередині події. **unhex** перетворює збережений хеш назад на 32 байти, які підписує Ed25519.

[Схема статичного ланцюга](https://github.com/phishdestroy/TgWitness/blob/main/docs/assets/presentation/evidence-chain-static.svg)

Нехай C(ei) — це канонічний JSON у форматі UTF-8, що містить дев’ять полів події. Перший запис `previous_hash` складається з 64 нулів. Кожен наступний запис містить шістнадцятковий хеш попереднього запису:

hi = hex(SHA256(C(ei)))

σi = Ed25519.Sign(sk,unhex(hi))

Підпис охоплює 32 байти необробленого дайджесту. Вхідні дані хешу містять саме `seq`, `observed_at`, `source_at`, `kind`, `chat_id`, `message_id`, `actor_id`, `payload` та `previous_hash`. Ключі об’єктів відсортовані; пробіли та ASCII- ескейп-символи опущені; значення NaN та нескінченність відхиляються. Дивіться [точне кодування](https://phishdestroy.github.io/TgWitness/uk/docs/reference/evidence/#event-canonicalization).

Блок-схема · 64 нульових символів → Запис 1 / хеш h1; Запис 1 / хеш h1 → Запис 2 містить h1 / хеш h2; Запис 2 містить h1 / хеш h2 → Запис 3 містить h2 / хеш h3; Запис 3 містить h2 / хеш h3 → Підписаний контрольний пункт: count 3, head h3 (зберігати в іншому місці) · 64 нульових символів · Запис 1 / хеш h1 · Запис 2 містить h1 /хеш h2 · Запис 3 містить h2 /хеш h3 · Підписаний контрольнийпункт: count 3, headh3 · зберігати в іншому місці

**Діаграма у вигляді тексту**

1. 64 нульових символів → Запис 1 / хеш h1
2. Запис 1 / хеш h1 → Запис 2 містить h1 / хеш h2
3. Запис 2 містить h1 / хеш h2 → Запис 3 містить h2 / хеш h3
4. Запис 3 містить h2 / хеш h3 → Підписаний контрольний пункт: count 3, head h3 (зберігати в іншому місці)

| Змінити на наданий журнал | Що це виявляє |
| --- | --- |
| Змінити запис 2, залишивши його збережений хеш | Перерахований хеш події відрізняється; його підпис більше не охоплює змінену подію |
| Відтворити змінений запис та всі наступні хеші | Оригінальні підписи не пройшли перевірку; збережений контрольний пункт на відповідній межі також не збігається |
| Видалити кінцеву частину, але залишити префікс без змін | Раніше збережена контрольна точка, що виходить за межі вказаного префікса, вказує на те, що експортний файл занадто короткий |
| Повторне підписання замінювального журналу іншим ключем | Окремий відбиток ключа, що викликає довіру, відхиляє заміну ідентифікатора |

![Зміна збереженого поля змінює його дайджест; відновлення хеш-сум не відновлює оригінальні підписи.](https://phishdestroy.github.io/TgWitness/assets/evidence-tamper-animated.svg)

**Спробуйте застосувати цю логіку до запису № 2:** змініть `Meet at 11:00` на `Meet at 12:00` у збереженому події. Його перерахований хеш більше не збігається. Перерахунок пізнішого ланцюжка може відновити його ланки, але не може змусити оригінальні підписи покривати нові дайджести. Натомість виявлене редагування в Telegram стає новим записом у журналі.

[Схема статичних змін](https://github.com/phishdestroy/TgWitness/blob/main/docs/assets/presentation/evidence-tamper-static.svg)

Самі по собі хеш-посилання не заважають комусь перерахувати ланцюжок замін. Довіра ґрунтується на перевірці підписів за допомогою незалежно перевіреного ключа та порівнянні з еталонними даними, що зберігаються поза межами колектора.

## Що додає попередній контрольний пункт

![Зберегти лічильник 3 та заголовок h3; пізніший експорт із 4 записами перевіряється у позиції 3.](https://phishdestroy.github.io/TgWitness/assets/evidence-checkpoint-animated.svg)

**Посилання залишається незмінним, тоді як журнал поповнюється.** Якщо контрольна точка вказує: «3 записи, заголовок h3», експорт із чотирма записами може пройти, оскільки h3 збігається на позиції 3. Його найновіший заголовок — h4, який, як очікується, має відрізнятися. Експорт із лише двома записами не пройде.

[Схема статичних контрольних точок](https://github.com/phishdestroy/TgWitness/blob/main/docs/assets/presentation/evidence-checkpoint-static.svg)

Після перевірки підпису контрольної точки необхідно:

Nexport ≥ Ncheckpoint and hexport[Ncheckpoint] = Hcheckpoint

Експорт може виходити за межі контрольної точки. Він повинен збігатися на збереженій межі. Реальний верифікатор також перевіряє послідовність кожної події, попереднє посилання, хеш та підпис. Порівнюючи лише кінцевий збережений заголовок, можна пропустити змінений внутрішній запис, хеш якого не було оновлено.

## Де знаходиться свідок

Блок-схема · Колектор / сесія облікового запису / ключ A → Кінцева точка контрольної точки, доступна лише для читання; Witness / закріплений ключ-збирач / власний ключ B → Окремий підписаний журнал свідчень; Witness / закріплений ключ-збирач / власний ключ B → Кінцева точка контрольної точки, доступна лише для читання (Замовити перевірку); Кінцева точка контрольної точки, доступна лише для читання → Witness / закріплений ключ-збирач / власний ключ B (Підписана відповідь); Witness / закріплений ключ-збирач / власний ключ B → Канал із підписаними публікаціями TGW1 (API бота / власний токен) · Хост A · Хост B · Колектор / сесіяоблікового запису / ключ A · Кінцева точка контрольноїточки, доступна лише длячитання · Witness / закріпленийключ-збирач / власний ключB · Окремий підписаний журналсвідчень · Канал із підписанимипублікаціями TGW1 · Замовити перевірку · Підписана відповідь · API бота / власний токен

**Діаграма у вигляді тексту**

1. Колектор / сесія облікового запису / ключ A → Кінцева точка контрольної точки, доступна лише для читання
2. Witness / закріплений ключ-збирач / власний ключ B → Окремий підписаний журнал свідчень
3. Witness / закріплений ключ-збирач / власний ключ B → Кінцева точка контрольної точки, доступна лише для читання (Замовити перевірку)
4. Кінцева точка контрольної точки, доступна лише для читання → Witness / закріплений ключ-збирач / власний ключ B (Підписана відповідь)
5. Witness / закріплений ключ-збирач / власний ключ B → Канал із підписаними публікаціями TGW1 (API бота / власний токен)

Свідок фіксує відкат змін, інший заголовок при тому самому лічильнику, змінені ключі, недійсні відповіді та відсутні відповіді. Сам по собі більший лічильник не доводить, що всі попередні записи залишаються незмінними; порівняйте експорт із збереженими контрольними точками. Розміщення свідка на іншому хості дозволяє уникнути впливу відбоїв у роботі хосту колектора; окремий оператор забезпечує додаткову незалежність.

Witness підтверджує стан журналу, про який повідомляє збирач даних. Він не самостійно відстежує всі повідомлення Telegram. Див. [налаштування Witness](https://phishdestroy.github.io/TgWitness/uk/docs/reference/witness/).

## Перевірка доставки на основі відомих дій

Використовуйте контрольну групу, окремі облікові записи для збору даних та новий маркер. Надсилайте, редагуйте та видаляйте повідомлення навмисно, перевіряючи збереження даних між етапами. Визначте очікувані дії та межу, перш ніж перевіряти результати.

R = |observed∩expected| / |expected| Δ t = treceipt - taction

Враховуються лише очікувані дії; дублікати квитанцій не збільшують чисельник. Знаменник повинен бути відмінним від нуля. Відсутня квитанція не має виміряної затримки. Вкажіть похибку часу; використовуйте власний контрольований час дії видалення, оскільки Telegram не надає точного часу видалення. Результат, наприклад, 5/6 (83,3 %), описує тестові дії, а не повноту всього трафіку Telegram.

## Оберіть робочий процес

[Повний покроковий опис розслідування,](https://phishdestroy.github.io/TgWitness/uk/docs/reference/investigation/) що відбувається після інциденту у каналі, групі, боті та приватному чаті:

1. Увімкніть режим розслідування всього облікового запису та проведіть інвентаризацію всіх доступних чатів.
2. Отримуйте знімки журналу, повну історію кожного чату та збережені вкладення.
3. Зберігайте зміни в режимі реального часу та будь-які навмисні взаємодії з панелями разом із відповідними підтвердженнями.
4. Відстежуйте числові ідентифікатори відправників, зв’язки у відповідях, повторювані адресати та хеш-коди файлів через цитовані записи та профілі користувачів.
5. Відтворення хронології переписки між чатами з позначенням часу та явними пропусками.
6. Порівнюйте робочі простори інших облікових записів, зберігаючи їхнє походження та ключі окремо.
7. Збирайте та перевіряйте підписані журнали, профілі та експортовані дані історії разом із примітками до справ.

Посібник «`/docs/cases/`» на сайті містить інтерактивну карту справ та варіанти розв’язання суперечок щодо ботів, видалених повідомлень та учасників, які змінюють імена. Нотатки щодо справ та аналіз між робочими просторами здійснюються зовні; додаток не створює автоматично загального графіка розслідування або об’єднаного архіву справ.

[Завершена валідація та робота, що залишилася](https://phishdestroy.github.io/TgWitness/uk/docs/reference/verification/) · [Експорт та перевірка](https://phishdestroy.github.io/TgWitness/uk/docs/reference/evidence/#investigation-handoff) · [Почніть з одного облікового запису](https://phishdestroy.github.io/TgWitness/uk/docs/reference/quickstart/)