用 20 美元工具救活變磚的 Framework 13 筆電
quantum5.ca (Guanzhong Chen) · 2026-08-16
2026 年 8 月，開發者 Guanzhong Chen（quantum）在為自己的 Framework 13（AMD 7040 系列）更新 BIOS 到 3.20 版時遭遇變磚，機器完全無法開機。Framework 官方支援表示保固已過期，唯一解法是花 500 加幣購買整片新主機板。由於論壇上至少從 2025 年 3 月就有其他用戶回報同款筆電的刷機失敗問題，且官方從未正式承認此瑕疵，他決定自己動手救援。
拆機與硬體讀寫
主機板上的韌體晶片是 Winbond W25Q256JWEQ，32 MiB 容量、WSON 8×6mm 封裝、工作電壓 1.8V。作者選用 CH347 USB 燒錄器搭配 15MHz SPI 時脈，並加上一個 1.8V 電位轉換模組，因為他先前測試的 CH341A 燒錄器在電壓相容性上有問題。接著用 WSON8 6×8mm 探針夾具搭配排線，直接夾在晶片腳位上讀寫，全程不需要拆下晶片或重新焊接。
正確的原廠映像檔則是先用 InsydeH2O-extractor-2 工具從 Framework 官方發布的 .cap 更新檔中,擷取出完整的 32 MiB 原始 BIOS 映像。實際燒錄指令如下：
sudo flashrom --programmer ch347_spi
sudo flashrom --programmer ch347_spi -r read-v1.bin --progress
sudo flashrom --programmer ch347_spi -nNw wanted.bin --progress
sudo grub-install /dev/nvme0n1p1作者先多次讀取確認雜湊值一致，再寫入目標映像檔，整個燒錄過程在一分鐘內完成，最後重新安裝 grub 開機程式即恢復正常開機。他強調實際動手燒錄只花不到五分鐘，真正費時的是取得工具與正確映像檔的過程。
原始來源：Fixing a bricked AMD 7040 series Framework 13" laptop with $20 tools
把火車車廂變成一台平台掃描機
philo.gay · 2026-08-17
工程師 Philo 在 2026 年 EMFcamp 上發表了一場演講，說明如何把行進中的火車與渡輪變成巨型「掃描機」。他借用工業界檢測輸送帶用的線掃描相機（line-scan camera）技術：感光元件每次只擷取一整列像素，靠載具本身的移動把一列列影像拼接成連續的全景照片，原理跟平台掃描機的掃描頭移動方式如出一轍。
硬體：從輸送帶相機到隨身裝置
核心硬體是 Basler ruL2048-19gm 工業線掃描相機，感光元件僅 1×2048 像素，卻能以每秒近 19000 次的速度連續擷取單列影像；專案後期加入彩色版本 Basler ruL2098-10gc。相機透過 C-mount 接環裝上一顆 Vivitar 28mm 鏡頭，外殼是自行 3D 列印、附腳架孔的機構。輔助電路包含六軸 IMU 加速度計、GPS 接收器與 SAMD21 微控制器，用來同步記錄姿態與位置資料。
擷取端程式以 Basler SDK 撰寫，介面用 Dear ImGui 搭配 OpenGL 做即時預覽與曝光控制。真正的難題在後製：由於火車行進速度並不固定，每一列影像必須依據加速度計資料做速度校正，這個模組被作者稱為 grindstone，起初以 NumPy 重寫，後來又拆成模組化管線以便調整。
視差與色彩對位的取捨
除了速度補償，另外兩個主要挑戰是不同距離物體造成的視差扭曲，以及三線感光元件（RGB 各自獨立掃描列）在拼接時的色彩通道錯位問題。這篇近 4600 字的文章詳細記錄了從最初的單色原型，到加入彩色感光元件、逐步排除各種運動與光學誤差的完整過程，最終產出的火車窗外全景照片解析度遠超過一般相機所能拍出的效果。
一份「AI 廢話」風格的組合式開機鏈漏洞公告引發爭議
oss-security mailing list (Solar Designer) · 2026-08-18
2026 年 8 月 18 日，oss-security 郵件列表的維護者 Solar Designer（Alexander Peslyak）轉發了一份遲來的安全公告，內容涉及 shim 與 GRUB2 開機鏈的組合式繞過攻擊。這份公告最早由研究者 trexnegr0（Jeremy Erazo）於 6 月 21 日投稿到 distros 郵件列表，但對方承諾的 7 月 1 日公開時間一再跳票，最終才由 Solar Designer 出面補發到公開列表。
四個串連起來的繞過點
公告描述的攻擊鏈由四個環節組成：fallback.efi 的 BOOT.CSV 處理常式沒有過濾路徑跳脫字元，可被導向目錄外的執行檔；fallback.efi 本身載入檔案前不做任何簽章驗證，完全跳過 SBAT 與 MOK 檢查；SBAT 世代編號用 UINT16 儲存，數值溢位後可讓已被撤銷的舊版開機檔重新通過驗證；GRUB 的驗證鏈對 memdisk 與 procfs 裝置會直接短路放行，載入核心時不做任何驗證。攻擊者只需短暫實體接觸 ESP 分割區，或已具備 root 權限，就能組合利用這四點載入任意核心程式碼。
- fallback.efi 路徑跳脫（BOOT.CSV 處理）
- fallback.efi 缺少簽章 / SBAT / MOK 驗證
- SBAT generation 欄位 UINT16 溢位
- GRUB memdisk / procfs 驗證短路
Solar Designer 在轉發信中直言不滿：14 天的 distros 列表禁運期上限，根本不夠讓 SBAT 撤銷清單完成跨廠協調所需的修補時程，公告卡在流程夾縫中遲遲無法公開。他也點名報告者在描述中坦承使用 Claude（Anthropic）協助草擬文字與產生修補程式，但強調自己有做過原始碼層級的獨立驗證，並用 ASAN 測試工具跑過執行期驗證。Red Hat 安全團隊的 Peter Jones 與 Marco Benatto 則在討論串中質疑嚴重程度，認為攻擊前提本身（實體接觸或 root 權限）已代表系統遭入侵，個別漏洞未必能獨立構成可利用的攻擊面。
原始來源：AI slop "Combined chain advisory" — fallback.efi/SBAT/memdisk bypass