把「執行檔」塞進 SQLite 資料庫:SELF 格式讓程式變成一張資料表
Farid Zakaria's Blog · 2026-08-23
背景:ELF 其實早就是個資料庫
軟體工程師 Farid Zakaria 在 8 月 23 日發布的文章中提出一個實驗性格式 SELF(Structured Executable & Linkable Format),把傳統 ELF 執行檔整個內容改存進一個 SQLite 資料庫檔案裡,讓這個 .db 檔案本身就能在 Linux 上被直接執行。他的觀察起點是:ELF 格式其實一直在手刻資料庫才有的功能,例如字串表(.strtab)本質是字串池、雜湊表(.hash/.gnu.hash)是索引、重定位表則是外鍵關聯。與其讓每個工具各自解析這些結構,不如直接用 SQLite 這種自我描述、可延伸的格式取代它。專案原始碼公開在 GitHub 的 fzakaria/selfdb,作者形容這是把先前的 sqlelf(在 ELF 上疊一層 SQL 視圖)概念反過來做。
怎麼讓一個資料庫檔案可以執行
關鍵手法是 SQLite 檔案格式在第 68 個位元組保留了一個 4-byte 的 application_id 欄位供應用程式自訂用途,SELF 把它填入 0x53454c46(即 ASCII 的 "SELF")。Linux 核心的 binfmt_misc 子系統可以註冊辨識這個魔數與 application id 的組合,一旦偵測到就交給對應的直譯器處理。這個直譯器叫 self-exec,它本身仍是一個普通 ELF 執行檔(避免遞迴呼叫自己),負責從資料庫的 segments、symbols、self_meta 等資料表讀出程式頭、符號與 ELF 標頭欄位,把可載入的區段映射進記憶體、完成重定位,再跳到進入點開始執行。
動態連結與「closure」打包
動態連結有兩種做法。第一種借助 glibc 的 rtld-audit 介面攔截函式庫查找請求,把原本的檔案系統搜尋改寫成 SQL 查詢,同時保留原生 ld.so 處理 lazy PLT、TLS 等機制;第二種是實驗性的 self-ld,直接用 SQL 完成整個連結器邏輯,例如透過 join 查詢解出重定位位址。更特別的是「closure」概念:可以把一支執行檔和它所有遞移依賴的函式庫,一次打包進同一個資料庫,依賴關係以外鍵表示,徹底消除 soname 版本混淆的問題。
self closure "$(command -v ls)" coreutils.db
sqlite3 hello 'SELECT soname FROM ldd'
sqlite3 hello 'DELETE FROM sections; DELETE FROM notes; VACUUM;'效能代價與被重新發明的工具鏈
代價也很直接:單一執行檔因為 SQLite B-tree 結構的額外開銷,體積大約膨脹一倍,但去除除錯資訊後與原生 ELF 相差不到 1%;啟動時固定多出約 5 毫秒的 SQLite 開檔延遲,且因為資料是從 B-tree 複製出來而非 mmap,多個行程之間無法共享同一份程式碼頁。作者實際把 723 個執行檔、400 個函式庫組成的完整 userland 打包進一個資料庫,結果是 611.9 MiB,反而比原本一堆 ELF 檔案的 644.4 MiB 更小。過去仰賴一堆命令列工具的工作,如今都能改寫成一行 SQL:strip(1) 變成刪除 sections 表後 VACUUM,ldd 變成查詢 ldd 視圖,patchelf 的修改變成單純的 UPDATE 陳述式。作者也提供一個可直接執行的 NixOS 展示環境(nix run .#self-vm),並強調 Nix 讓他能整套重建系統、嘗試不受 ELF 歷史包袱束縛的「激進想法」。
原始來源:Your executable is a SQLite database、fzakaria/selfdb (GitHub)
逆向工程揭密:Windows 小畫家與相片程式替「本機生成」的圖片偷偷蓋上伺服器核發的 GUID
Xusheng Li's Blog · 2026-08-20
發現過程
資安研究者 Xusheng Li 在 8 月 20 日發布的逆向工程報告中指出,Windows 內建的小畫家(Paint)與相片(Photos)應用程式,會替所有 AI 生成的圖片嵌入一組肉眼看不見的浮水印。他透過 Binary Ninja 搭配 MCP 與 Codex 對相關元件做靜態分析,起點是小畫家內附的四個 .onnxe 模型檔(seg、inseg_enc、inseg_dec、mager)。這些檔案用存放於 segapi.dll 裡的金鑰做 XOR 加密,解密還原後可用 onnx.checker.check_model() 驗證為合法的 ONNX 模型。
浮水印怎麼藏進像素
負責寫入的函式 WmkWriteWatermark 採用內容自適應的區塊域隱寫術(SVD 風格處理),實際攜帶的訊息只有 18 個位元組:1 個標記位元組 0x4c、16 位元組的 GUID,再加上一個以 GUID 位元組總和取模 256 算出的檢查碼。在一張測試用的 512×512 圖片中,262,144 個像素裡有多達 193,376 個被修改,演算法透過 24.0、0.25、0.5、0.2 等常數與 3x5 矩陣運算,把每個位元至少重複寫入三個位置、分散在 144 個計數器中,以提升被裁切或壓縮後仍可還原的韌性。
GUID 從哪裡來:雲端審核伺服器
報告發現這組 GUID 並非在裝置端產生,而是由微軟的雲端審核伺服器核發(端點為 apsaiservices-*.azurefd.net/v1/paint-cocreator/moderate-prompt)。伺服器回應內容除了要嵌入像素的 watermarkId,還包含會轉交給 C2PA 簽章服務的 promptGenerationId、被伺服器改寫過的 revisedPrompt,以及一個 containsHumanReference 旗標。這組 GUID 之後也會出現在 C2PA 的軟綁定(soft-binding)中繼資料裡,標籤為 com.microsoft.invismark.1,經過簽章後寫入 PNG 的 caBX 區塊或 JPEG 的 APP11 區段。
「本機生成」不代表「不連網」
关键的架構差異在於:雲端路徑(Image Creator)全程在遠端生成、蓋章、簽署;但即便是強調在 Copilot+ PC 的 NPU 上「本機生成」的 Cocreator 路徑,提示詞審核與 GUID 核發仍必須連到微軟伺服器,只有像素浮水印的寫入(透過 Watermarker.dll)真正發生在本機,事後又得把資料送回雲端做 C2PA 簽署。兩個應用程式的容錯態度也不同:小畫家把浮水印寫入失敗視為生成失敗、直接不回傳圖片;相片程式則只記錄失敗,仍會把沒有標記的圖片還給使用者。此外,只有 PNG、JPEG、GIF 與 .paint 格式能保留 C2PA 資訊,BMP 則被排除在外。
- 浮水印訊息:1 位元組標記 + 16 位元組 GUID + 1 位元組檢查碼
- GUID 核發端點:
/v1/paint-cocreator/moderate-prompt - 簽章標籤:
com.microsoft.invismark.1(C2PA 軟綁定)
IPFS 背後推手 Shipyard 宣布停止維運:9 月底後 Kubo、Helia 都將沒有專職維護者
Interplanetary Shipyard Blog · 2026-08-24
Shipyard 是誰
負責維護 IPFS 與 libp2p 核心生態的獨立團隊 Interplanetary Shipyard,在 8 月 24 日由 Cameron Wood 與 Adin Schmahmann 具名發表部落格文章,宣布由於 Protocol Labs 決定不再續約資助,團隊將於 2026 年 9 月 30 日結束所有與 IPFS 相關的工程、維護與基礎設施工作。Shipyard 於 2023 年從 Protocol Labs 獨立出來成為專職團隊,此前一直是服務全球逾 7500 萬月活躍使用者的 IPFS 與 libp2p 協定的核心維護者。這則公告等於宣告這個協定生態自此進入沒有專職維護團隊的階段。
停止前的最後成果
公告中列出團隊在資助中止前完成的幾項工程成果,包括讓網頁可在瀏覽器內驗證內容的 inbrowser.link、重新設計後可承受 3 倍流量卻讓維運成本下降約 80% 的 gateway 基礎設施,以及簡化部署方式的 HTTP-native IPFS 實作。這些原本規劃要親自落實的改善,如今都得交棒,包括更具韌性的內容路由等尚未完工的項目。
受影響的專案與基礎設施
失去專職維護者的專案清單相當長,涵蓋 Go 語言實作 Kubo、JavaScript 實作 Helia、函式庫 Boxo、gateway 實作 Rainbow,以及 IPFS Desktop、IPFS Companion、Someguy、Service Worker Gateway、IPFS Check 等周邊工具;團隊對上游 go-libp2p 與 js-libp2p 的貢獻也將停止。公共基礎設施同樣受衝擊,包括 ipfs.io、dweb.link、check.ipfs.network、delegated-ipfs.dev 等 gateway 與 bootstrap 節點,以及像「Wikipedia on IPFS」這類協作叢集,後續由 Protocol Labs 決定去留。
- 核心實作:Kubo(Go)、Helia(JS)、Boxo、Rainbow
- 周邊工具:IPFS Desktop、IPFS Companion、Someguy、Service Worker Gateway、IPFS Check
- 公共設施:ipfs.io、dweb.link、check.ipfs.network、delegated-ipfs.dev、bootstrap 節點
接下來呢
libp2p 的維運工作將轉交社群維護者接手,延續去年公告中已經啟動的交棒計畫。Shipyard 表示團隊會持續營運到 2026 年 9 月底,期間協助各方 stakeholder 處理轉移相關的問題與脈絡,但強調此後這些專案將不再有負責新功能、修錯、發版或長期維護規劃的固定團隊。