動機：一筆警報留下來之後呢？
入侵偵測通常從「有沒有發現異常」開始。我做這個區塊鏈課程期末專案時，還想往後追一段：如果主機上的紀錄被刪除或修改，調查者還能不能確認當時看到了什麼？因此系統不只要採集事件，也要把資料送進可追溯的保存層，再提供能回到原始欄位的檢視介面。
設計：四條採集路徑、兩個合約、兩種讀寫權限
Sysmon、Security Event Log 與 Frida 事件先組成 JSON payload，經 Flask 驗證與轉換，再由 Web3.py 寫入 EventLogger／MaliciousLogger，最後透過 Flask GET 供 Vue 3 儀表板讀取；完整資料流如圖所示。
來源的差異會直接影響資料被送到哪個 API，而不是所有事件都走同一條「惡意」路徑：
| 來源與程式 | 具體條件與 payload | 後端／鏈上去向 |
|---|---|---|
Sysmon listen_sysmon |
只查詢 EID 1 Process Create，抽取 Image、CommandLine、ProcessId、User、IntegrityLevel 等欄位 | POST /api/logs，由 write_logs_to_contract 呼叫 EventLogger.recordEvent |
Security listen_security_log |
查詢成功登入 EID 4624，去重 EventRecordID，以 Logon 類型送出並把 LogonType 放入 detail |
POST /api/malicious，由 write_maliciousLogs_to_contract 呼叫 MaliciousLogger.addMaliciousLog |
Sysmon listen_sysmon_registry |
查詢 EID 13 或 14，將 EventType、TargetObject、Details 組成 Registry payload |
POST /api/malicious，保存為疑似惡意事件 |
Frida frida_hook |
附加到 DLL_Injector.exe，hook LoadLibraryA 與 LoadLibraryW，回傳 DLL 名稱與呼叫函式 |
POST /api/malicious，以 DLL Injection 和 hook 函式寫入 detail |
這裡要分清楚「程式怎樣分流」和「事件是否證明攻擊」：目前程式把 4624、Registry 和 Frida 的事件送入 MaliciousLogger，只是課程專案的疑似惡意分類；原始 EID 4624 只代表登入成功，不能單獨當成入侵證據。
Flask 是資料進入鏈上前的信任邊界。/api/logs 只接受一般欄位，/api/malicious 另外要求 detail；兩者都要求 JSON 物件、固定欄位集合、字串長度限制，以及非負的 timestamp／PID。寫入 API 使用 IDS_PRODUCER_TOKEN，前端讀取與分析使用不同的 IDS_BROWSER_TOKEN，缺少或錯誤的 Bearer token 會被拒絕。這些檢查能擋掉格式錯誤、過長或未授權的請求，但不能判斷欄位內容是否為真。
| API／合約介面 | 作用 | 讀寫方式 |
|---|---|---|
POST /api/logs → recordEvent |
保存一般安全事件 | EventLogger；讀取時先 getLogCount()，再逐筆 getLog(index) |
POST /api/malicious → addMaliciousLog |
保存疑似惡意事件與 detail |
MaliciousLogger；讀取時先 getLogsCount()，再逐筆 getMaliciousLog(index) |
GET /api/logs、/api/malicious |
給儀表板查詢鏈上紀錄 | 由 Web3.py adapter 將 Solidity tuple 轉成前端 JSON |
Vue 3 儀表板以 browser token 查詢兩類紀錄，每五秒輪詢；介面支援搜尋、事件類型篩選與欄位排序，分頁進入背景時會暫停輪詢。使用者按下分析時，前端送出最近 30 筆紀錄給 Gemini 2.0 Flash；Flask 仍把它們當成不可信事件資料，只讓模型根據 timestamp、event_type、command_line 產生繁體中文摘要。摘要是閱讀輔助，不取代原始紀錄。
結果與學到的技術：鏈上可核對，不等於事件真實
這個專案完成了從 Windows／Frida 採集、Flask API、Web3.py 交易，到 Solidity 合約與 Vue 儀表板的串接。EventLogger 和 MaliciousLogger 分開保存一般與疑似惡意事件，adapter 也分別以 getLogCount／getLog 和 getLogsCount／getMaliciousLog 讀回資料，讓畫面上的一筆紀錄能回到合約索引與原始欄位。
區塊鏈的價值在於：在鏈與交易歷史本身可信且可取得的前提下，寫入交易後對合約狀態或紀錄的修改會留下可核對的痕跡，提升竄改可見性。但它不會替輸入背書。持有 producer token 的來源仍可能送出捏造的 JSON；主機事件也受權限、監聽範圍與 Frida hook 目標影響；Flask 的型別與長度驗證只保證資料形狀，不保證事件語意。這是我在設計「可信保存」時最需要保留的限制。
反思與下一步
我學到安全系統的完整性至少分成兩層：採集時要留下能解釋上下文的欄位，保存後要能核對紀錄是否被改動。這個專案證明的是資料流和查詢流程能在課程環境串起來，不是未知攻擊的偵測率、誤報率或鏈上效能保證；頁面也不把成功登入 EID 4624 寫成 raw malicious proof。
若往真實環境延伸，下一步會是把來源身分、事件簽章、重播／重複事件、producer token 外洩與鏈上交易成本納入測試，並重新定義哪些條件才應進入 MaliciousLogger。在有這些證據前，增加更多警報類型不會自動增加可信度。
專案也有展示影片；原始碼與完整部署說明見 IDS-Web3 GitHub。