# 跨所有聊天室進行調查

Canonical page: https://phishdestroy.github.io/TgWitness/zh-Hant/docs/cases/

跨頻道、群組、私人聊天室及機器人處理整個案件：蒐集、串聯、重建並移交證據。

本操作指南透過一個虛構案例，完整展示整個處理流程。其中實際運用了資料蒐集、搜尋、人物檔案及匯出等功能。案例地圖僅為文件範例；您的結論與案件紀錄將由應用程式外部管理。

已處理案例／付款目的地變更

### 一樁事件。四段對話。一條待重構的軌跡。

某頻道的公告指向一個機器人。一個運作小組正在討論一個新的付款連結。一則私下跟進訊息重複了該連結。隨後，該公告被編輯，而一則群組訊息則消失了。

每一個版本是由誰發布的？該連結出現在哪裡？哪個檔案被保留下來了？有哪些變更，以及何時進行的？

有關歷史資料載入、可選的 AI 來源審查、MCP、OCR 及外發 Webhook 等功能，請參閱[「檔案管理」頁面](https://phishdestroy.github.io/TgWitness/zh-Hant/docs/archive/)。

## 1. 建立涵蓋整個帳戶的記錄範圍

1. 請在專屬的工作區中[連結資料蒐集帳戶](https://phishdestroy.github.io/TgWitness/zh-Hant/docs/accounts/)。請將案件參考編號、帳戶 ID、工作區名稱及簽名金鑰指紋記錄於您的案件筆記中。
2. 開放**來源 → 觀察範圍 → 調查模式**。檢視「**整個帳戶**」、「所有四種來源類型」及「**自身操作**」。此預設設定可儲存新來源的檔案及其最近 **200 則可見訊息**。按下「**儲存範圍」**並完成範圍確認。
3. 按下**「載入對話**」。將來源與該帳號的對話清單進行比對，並檢視排除項目。在**「參數」→「從帳號清單讀取的對話」**中，如有需要可調整初始清單限制：預設為 1,000 則對話，可設定上限至 20,000 則。 超出限制的對話將在變得活躍時被偵測到。
4. 在「**記錄設定**」中，選取並儲存「**所有可見活動**」。檢視附件類型、大小限制及可用磁碟空間。在完全信賴此設定之前，請先啟動監測功能，並驗證一則受控訊息、編輯及刪除操作。

頻道群組私人聊天室機器人

一個帳戶／一個簽署金鑰**所有選定的、帳戶可見的活動 → 整合為一份日誌**

訊息 · 編輯 · 刪除通知 · 可見反應 · 群組活動 · 自身操作

「整個帳號」涵蓋該帳號可存取的聊天室，包含已設定的來源類型與排除項目。秘密聊天室無法納入。新對話會隨著更新而加入；啟用此模式並不會自動下載每個現有聊天室的完整歷史紀錄。

## 2. 取得歷史紀錄並保存檔案

建立涵蓋整個調查範圍的來源登記表。為每個聊天室建立一行記錄，包含其數字 ID、標題、帳戶、存取權限／角色、即時記錄起始時間、歷史記錄取得時間、媒體結果及已知缺漏。僅在核對相關結果後，才將來源標記為「已取得」。

| 需求 | 面板中的操作 | 功能介紹 |
| --- | --- | --- |
| 已啟用聊天室的歷史紀錄 | 來源 → 載入完整歷史紀錄 | 當前主要功能：可用的過往訊息會被記錄至工作區日誌中，並提供暫停／恢復功能及經簽署的進度報告。[使用指南](https://phishdestroy.github.io/TgWitness/zh-Hant/docs/reference/history/)。 |
| 日誌中的現有聊天內容 | 來源 → 記錄設定 → 歷史快照 | 最近可見的訊息將作為已簽署的觀察記錄。預設上限為 500 則；透過「**參數」→「最大歷史快照」**可將其提高至 10,000 則。 |
| 某個聊天室目前可見的完整歷史紀錄 | 完整聊天記錄匯出 → 匯出完整聊天記錄，或 聊天 → 匯出聊天記錄 | 包含 `chat.json` 和 `chat.html` 的獨立簽名套件。針對每個來源重複執行；保留成功／失敗的結果。 |
| 當出現新聊天室時的背景說明 | 監測範圍 → 當出現新的聊天室或機器人時 | 包含來源檔案及多達 1,000 則近期可見的訊息；若啟用「調查模式」，則僅選取 200 則。現有聊天室不會追溯性地納入這些資料。 |
| 附件位元組 | 下載可見附件 + 各類別上限 | 請確認檔案是否為「`media.saved`」，並核對其 SHA-256 值與位元組數。排入佇列、被跳過或下載失敗的檔案均不視為已保存的檔案。 |

完整聊天記錄匯出屬於獨立的快照；它不會將整個聊天歷史記錄匯入日誌或人員檔案中。若需在 TgWitness 內搜尋歷史資料，請使用「**載入**所有已啟用來源的**完整歷史記錄**」功能，或使用「有限範圍的日誌快照」。執行前請先檢視來源清單。

在實際案例中，可取得公告頻道、運作群組、機器人對話及私下後續討論的內容。並保留發票附件的位元組與雜湊值。目前可取得的歷史紀錄無法還原在擷取前已被刪除的訊息，亦無法還原 Telegram 已不再回傳的中間編輯內容。

## 3. 記錄不斷演變的對話內容以及您自身的行動

隨著案件發展，請持續進行監測。將活躍的案件聊天室標記為優先來源；在「**記錄設定」→「重新檢查」**中配置優先級及其他來源的重新檢查。隨著工作進展，請檢視 `recheck.completed`、持續補錄、FloodWait 及媒體結果。

請使用**「聊天室」→「個人資料」→「立即儲存個人資料」**，以保留當前來源描述、機器人指令以及 Telegram 回傳的其他元資料。此來源個人資料與根據日誌訊息建立的聯絡人個人資料是分開的。

**作為案件調查的一部分，追蹤機器人或接受邀請**

1. 在「**聊天」→「開啟 Telegram 連結」**中，請先儲存預覽。原始連結與回傳的預覽皆會成為經簽署的記錄。
2. 若調查需要，執行「**加入／開啟並監控**」將開啟原始來源，並根據提供的啟動參數啟動一個機器人。待處理的加入請求將在記錄中保持待處理狀態。
3. 若需記錄某項操作，請使用面板中的文字回覆功能，或支援的「**按下按鈕」**控制項。該日誌會保留 `interaction.requested` 與 `interaction.result`，包含回傳的回調文字或網址。

這些控制項會執行實際的 Telegram 操作。在其他 Telegram 應用程式中按下的回調按鈕，收集器無法偵測到；但該機器人隨後發送的訊息或編輯操作則可能被記錄。網頁應用程式、支付功能以及電話號碼／位置請求均不在迷你客戶端（mini-client）的監控範圍內。

## 4. 追蹤聊天室中的人員、連結與檔案

1. 開啟**「日誌」**（Open **Journal**），將來源篩選器維持在「**所有來源」**，並搜尋特定短語、網域、使用者名稱或已儲存的識別碼。開啟每筆符合條件的記錄，並記錄其對話、訊息 ID 及日誌序號。
2. 若要查看相關聊天紀錄，請開啟「**聊天**」**→「人員」→「開啟個人檔案」**，然後選取一名使用者。檢視姓名／使用者名稱歷史紀錄、回覆關係、活動紀錄，以及**「亦出現在⋯⋯」**中的其他被監測聊天紀錄與萃取的連結、錢包或電話號碼。開啟引用的日誌紀錄。
3. 在同一工作區內，追蹤相同的 Telegram 用戶 ID 至其他聊天室。若發現名稱、錢包提及或相似頭像等匹配資訊，應視為需核實的線索。被提及的地址並不代表所有權；相似的頭像也不代表是同一人。
4. 比較各記錄中保存附件的 SHA-256 值。相等的雜湊值可驗證儲存檔案的位元組內容是否完全一致。在判定分享者身分之前，請先檢視相關的訊息及發送者記錄。

案例地圖 / 追蹤參考資料虛構案例 · 非即時圖表

頻道 / 公告**原文 → 編輯後內容**

記錄 #101、#188 訊息 #84 · 未標示發送者

群組 / 運作**使用者 71001 發布了新連結**

記錄 #146 · 訊息 #309 已儲存檔案收據 #151

BOT / 訂購對話**一個按鈕可導向該頁面**

記錄 #173 · 訊息 #12 返回按鈕的元資料

私密 / 後續追蹤**使用者 71001 重複輸入目的地**

記錄 #205 · 訊息 #922 已儲存檔案收據 #209

四個聊天室提供了不同的觀察結果。請追蹤每項連結的原始記錄；若未標明發送者，請勿將該頻道貼文歸屬於使用者 71001。

本操作指南中的數字 ID 和記錄參考編號均為虛構。此圖解說明分析師如何運用搜尋、個人檔案及記錄檢視功能進行工作流程；本應用程式不會生成全局調查圖譜。

| 連結 | 輔助觀察 | 結論：保留 |
| --- | --- | --- |
| 同一 Telegram 帳號 | 群組 #146 及私人聊天室 #205 中的使用者 ID 71001 | 兩則聊天紀錄中顯示的發送者 ID 相同。其真實身分則另當別論。 |
| 重複的目標 | `pay.example.invalid/new` 在 #146、按鈕元資料 #173、編輯過的貼文 #188 及 #205 | 同一目標在四個觀察到的情境中出現。僅憑此點尚無法確定其控制者。 |
| 相同檔案位元組 | 已完成的媒體收據 #151 和 #209 中的 SHA-256 值完全相同 | 這兩份被保存的附件在位元組層面上完全相同。僅憑檔案名稱或縮圖無法證明這一點。 |

使用者個人檔案涵蓋在該聊天室中儲存了訊息的作者，並將其與*同一工作區*日誌中的其他聊天室建立關聯。這些個人檔案並非完整的成員名錄。頭像雜湊值來自獨立的本地快取；個人檔案引用次數可在「**參數」→「每個事實的引用記錄」**中設定上限。

## 5. 重建事件序列並標記缺漏處

在**「聊天**」頁面中，檢視已儲存的版本及其「**日誌記錄 #…」**連結。在**「日誌**」頁面中，使用**「所有來源」**加上**「編輯」**、**「刪除**」及**「涵蓋範圍」**功能。結合 Telegram 提供的日期與收集器的觀察時間，建立案件時間軸。

1. 09:00 · #101**已擷取的頻道貼文**

   原始目標網址已保留。
2. 09:12 · #146 / #151**群組提供了一個不同的連結**

   使用者 71001 發佈此內容；附件下載完成。
3. 09:16 · #173**該機器人顯示相同的目的地**

   儲存的鍵盤元資料中包含該連結。
4. 09:20 · #188**頻道公告變更**

   原始內容與編輯後的內容均予以保留。
5. 09:24 · #205 / #209**私人後續訊息再次重申此點**

   所儲存的附件與 #151 具有相同的完整 SHA-256 值。
6. 09:28 · #231**群組刪除通知已送達**

   先前的觀察依然成立：系統既未提供刪除者身分，也未提供確切的刪除時間。

示例中的觀察時間與參考資料。其他日誌記錄則位於這些條目之間。

日誌序列依接收順序排列，未必與原始 Telegram 操作順序一致。較舊的歷史快照可能在較新的即時訊息之後才送達。請將即時觀察、快照、恢復的訊息、刪除通知以及「重新檢查時缺失」明確區分。凡是覆蓋範圍出現缺口之處，請明確標註「未知時間間隔」；後續的快照並不會消除該缺口。

## 6. 將此案例擴展至其他資料蒐集帳戶

針對每個獨立帳戶新增一個工作區，並重複進行範圍與歷史紀錄的清點。記錄每個帳戶的成員資格／角色及簽名金鑰指紋。識別碼須以工作區和聊天室為限定條件：相同的訊息編號並非跨帳戶的通用識別碼。

請在您的案件筆記或分析工具中比對相關觀察結果，並保留每行所對應的帳戶及日誌參考資訊。TgWitness 目前尚未提供橫跨所有工作區的全球性搜尋、合併時間軸、人際關係圖或案件檔案庫功能。針對單一頻道或超級群組進行的多帳戶完整匯出是一項獨立功能；此功能並非所有帳戶日誌的合併。

在進行較長時間的工作時，請新增[獨立見證](https://phishdestroy.github.io/TgWitness/zh-Hant/docs/witness/)者以保留先前的邊界。使用「受控傳送」試點計畫來驗證帳戶的擷取路徑與可見性。

## 7. 提供完整且可核查的案件資料包

從每個工作區匯出經簽署的日誌 ZIP 檔案。該檔案包含完整的記錄日誌，不受面板搜尋篩選條件的影響。請分別匯出相關人員的個人檔案，保留每個完整的聊天記錄包，並完整保存附件證據。

```
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
```

請透過獨立通道保存可信的指紋。從可信的安裝環境出發，依據其自身的工作區身分驗證每個證據：

```
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
```

查閱實際驗證結果、保留原始檔案，並將涵蓋範圍報告、資料擷取失敗紀錄及傳輸紀錄與您的調查結果一併保存。頂層案件資料夾與分析師結論均由外部彙整；各 TgWitness 證據檔案則各自附有專屬簽章。

## 其他調查亦可採用相同方法

**由聊天機器人觸發的訂單或付款糾紛**

**問題：**該機器人曾承諾什麼、提供了哪個按鈕的連結，以及之後發生了什麼變化？

**追蹤路徑：**頻道加入貼文 → 儲存的機器人連結預覽 → 機器人啟動參數 → 訊息及鍵盤版本 → 任何由面板發出的回呼收據 → 群組／私訊後續互動。將每個目標與其來源記錄配對；保留個人檔案描述及完整的媒體檔案。

**提供內容：**已觀察到的要約與回應的時間軸、來源參考資料及經驗證的匯出檔案。顯示的付款連結並不構成付款已發生的證據。

**因跨聊天室事件而被刪除的訊息**

**問題：**在相關訊息消失之前，已經觀察到哪些情況？

**追蹤路徑：**所有受影響的聊天室 → 原始訊息 → 已送達的編輯內容 → 刪除通知或後續重新檢查時發現的缺失結果 → 已保存的附件 → 事件相關的涵蓋範圍。將獨立帳戶的觀察結果與其聲明的可見性進行比對。

**呈現方式：**一連串被保存的版本，以及明確標示的未知時間區間。切勿將缺失的歷史訊息視為某人刪除該訊息的證據。

**某位參與者在多個聊天室中使用不同的名稱**

**問題：**儘管名稱有所變更，哪些被觀察到的活動仍屬於同一個 Telegram 帳號？

**追蹤路徑：**數值發送者 ID → 儲存的名稱／使用者名稱歷史紀錄 → 回覆訊息 → 工作區內的其他聊天室 → 被提及的目標及儲存的檔案。針對每項聲稱的連結，皆須查核原始紀錄；並將外觀相似的帳戶區分開來。

**提供：**附有引用來源的帳戶活動時間軸，以及關於關係的獨立假設。名稱相似性與頭像 pHash 僅為線索，並非身分證明。