Log for Ubuntu 台灣社群
Floppinux：單張 1.44 MiB 軟碟上的嵌入式 Linux（2025 年版） （★ 106 分）
FLOPPINUX 2025 年版（v0.3.1）把一套可開機的 Linux 做進單張 3.5 吋 1.44 MiB 軟碟，定位像是「做單張軟碟版的 Linux From Scratch」：帶你從頭裁切 Linux 核心與使用者空間工具，最後在有軟碟機的老 PC 上直接開機進入終端機，能編輯檔案、寫簡單腳本，且在軟碟上保留約 264 KB 的可寫入空間讓使用者檔案能持續儲存。專案目標是極簡但可用，硬體門檻鎖定 i486（Intel 80486 等級的 32 位元 x86）以上處理器，最低 486DX 33 MHz、20 MB 記憶體與內建軟碟機，並強調可在實機或模擬器上運作。
教學核心是「把每一個 KB 都算到極致」。作者指出 Linux 核心從 6.15 起移除 i486 支援，因此選用仍相容的 6.14.11，先用 tinyconfig 起步，再以 menuconfig 只保留必要元件，例如 XZ 壓縮的 initramfs/initrd（開機時載入到記憶體的初始檔案系統）、486DX 目標處理器、軟碟與 RAM disk、TTY、可執行檔格式（ELF 與 #! 腳本）、以及 FAT（MSDOS）/proc/sysfs 等基本檔案系統支援。使用者空間則選 BusyBox（把多個常用指令整合成單一小型可執行檔的工具箱）1.36.1 並採靜態連結，挑選 vi、ash、mount/umount、mdev、init 等最小指令集合；為了在 64 位元主機上建置 32 位元目標，搭配 i486-linux-musl 交叉編譯器（musl libc：輕量 C 標準函式庫），最後做出最小目錄結構、裝置節點、inittab 與開機腳本。
持續儲存的設計是此版亮點：開機腳本會把 /dev/fd0 以 msdos（FAT）可讀寫方式掛載到 /mnt，建立 /mnt/data 後再用 bind mount 把它對應到 /home，讓使用者在 /home 的變更實際寫回軟碟資料區，同時把系統本體留在壓縮的 rootfs.cpio.xz。完成後用 Syslinux（常用於 FAT 的輕量開機載入器）做開機設定，建立 1440 KiB 軟碟映像檔、格式化、安裝開機載入器並複製核心與 rootfs；作者也提供用 QEMU（開源硬體模擬器）在 i386 模式、20 MB 記憶體與 486 CPU 參數下先行測試的方法。最終映像檔仍維持 1.44 MiB，作者列出的成果是核心約 881 KiB、工具與 rootfs 壓縮後約 137 KiB，df 顯示約 253 KiB 可用空間，並提醒寫入後要記得 sync，實際燒錄到軟碟時更要小心 dd 目標裝置避免毀損分割區。
留言區一方面充滿復古感：有人懷念軟碟讀寫聲與等待開機的期待感，也有人第一次聽到「floppy」而被科普這是 USB 隨身碟與 CD-ROM 普及前的常見儲存媒介，過去軟體也常以軟碟販售；還有人補充 3.5 吋其實是硬殼「diskette」，早年更大張、真的會「軟」的才更符合 floppy 的字面意思。也出現大量回憶與考古：1999 年的 QNX 1.44 MB 展示版可直接進視窗管理員並帶基本瀏覽器、MuLinux 與 Puppy Linux 等軟碟發行版、Slackware 曾需用多張軟碟安裝（有人爭論是 12 張還是 30+ 張，並分享撥接時代壞片重抓的痛苦），以及用 486 加兩張網卡跑 floppyfw／CoyoteLinux 當家用路由器、防火牆的實戰經驗。也有人質疑「為什麼要做」，但多數回應把它定位為學習與懷舊專案，就算沒有實體軟碟機，也能靠模擬器或復古硬體體驗。
技術討論則集中在「把 FAT12（早期 FAT 檔案系統的 12 位元版本）當持續儲存」的可靠度：有留言肯定用 bind mount 省空間很巧妙，但擔心 FAT12 不是日誌式（journaling）檔案系統，軟碟寫入又慢，若當機或中途斷電，可能造成檔案系統不一致甚至資料遺失；因此有人提議把剩餘空間當 raw block，或改用偏向追加寫入的日誌式檔案系統（例如精簡的 JFFS2，Journalling Flash File System 2），甚至把變更累積成 tar 並在關機時一次序列化寫回，以降低風險。也有人反駁「斷電就整張報廢」太誇張，指出 FAT 有兩份配置表可供復原，頂多出現 lost clusters（遺失叢集鏈）可用檔案系統檢查工具清理，並延伸到「日誌式檔案系統未必如想像中必要」的觀點。另一路討論把這類專案放回現實：即使 32 位元硬體效能對文書早已足夠，真正難題往往是應用層與驅動逐漸不再支援、以及瀏覽器型軟體的膨脹；有人補充 Debian 仍有 i386 支援，也有人建議改用 NetBSD 或用 isohybrid 等工具解決老 ISO 的開機媒介限制。
👥 57 則討論、評論 💬
https://news.ycombinator.com/item?id=46866544
FLOPPINUX 2025 年版（v0.3.1）把一套可開機的 Linux 做進單張 3.5 吋 1.44 MiB 軟碟，定位像是「做單張軟碟版的 Linux From Scratch」：帶你從頭裁切 Linux 核心與使用者空間工具，最後在有軟碟機的老 PC 上直接開機進入終端機，能編輯檔案、寫簡單腳本，且在軟碟上保留約 264 KB 的可寫入空間讓使用者檔案能持續儲存。專案目標是極簡但可用，硬體門檻鎖定 i486（Intel 80486 等級的 32 位元 x86）以上處理器，最低 486DX 33 MHz、20 MB 記憶體與內建軟碟機，並強調可在實機或模擬器上運作。
教學核心是「把每一個 KB 都算到極致」。作者指出 Linux 核心從 6.15 起移除 i486 支援，因此選用仍相容的 6.14.11，先用 tinyconfig 起步，再以 menuconfig 只保留必要元件，例如 XZ 壓縮的 initramfs/initrd（開機時載入到記憶體的初始檔案系統）、486DX 目標處理器、軟碟與 RAM disk、TTY、可執行檔格式（ELF 與 #! 腳本）、以及 FAT（MSDOS）/proc/sysfs 等基本檔案系統支援。使用者空間則選 BusyBox（把多個常用指令整合成單一小型可執行檔的工具箱）1.36.1 並採靜態連結，挑選 vi、ash、mount/umount、mdev、init 等最小指令集合；為了在 64 位元主機上建置 32 位元目標，搭配 i486-linux-musl 交叉編譯器（musl libc：輕量 C 標準函式庫），最後做出最小目錄結構、裝置節點、inittab 與開機腳本。
持續儲存的設計是此版亮點：開機腳本會把 /dev/fd0 以 msdos（FAT）可讀寫方式掛載到 /mnt，建立 /mnt/data 後再用 bind mount 把它對應到 /home，讓使用者在 /home 的變更實際寫回軟碟資料區，同時把系統本體留在壓縮的 rootfs.cpio.xz。完成後用 Syslinux（常用於 FAT 的輕量開機載入器）做開機設定，建立 1440 KiB 軟碟映像檔、格式化、安裝開機載入器並複製核心與 rootfs；作者也提供用 QEMU（開源硬體模擬器）在 i386 模式、20 MB 記憶體與 486 CPU 參數下先行測試的方法。最終映像檔仍維持 1.44 MiB，作者列出的成果是核心約 881 KiB、工具與 rootfs 壓縮後約 137 KiB，df 顯示約 253 KiB 可用空間，並提醒寫入後要記得 sync，實際燒錄到軟碟時更要小心 dd 目標裝置避免毀損分割區。
留言區一方面充滿復古感：有人懷念軟碟讀寫聲與等待開機的期待感，也有人第一次聽到「floppy」而被科普這是 USB 隨身碟與 CD-ROM 普及前的常見儲存媒介，過去軟體也常以軟碟販售；還有人補充 3.5 吋其實是硬殼「diskette」，早年更大張、真的會「軟」的才更符合 floppy 的字面意思。也出現大量回憶與考古：1999 年的 QNX 1.44 MB 展示版可直接進視窗管理員並帶基本瀏覽器、MuLinux 與 Puppy Linux 等軟碟發行版、Slackware 曾需用多張軟碟安裝（有人爭論是 12 張還是 30+ 張，並分享撥接時代壞片重抓的痛苦），以及用 486 加兩張網卡跑 floppyfw／CoyoteLinux 當家用路由器、防火牆的實戰經驗。也有人質疑「為什麼要做」，但多數回應把它定位為學習與懷舊專案，就算沒有實體軟碟機，也能靠模擬器或復古硬體體驗。
技術討論則集中在「把 FAT12（早期 FAT 檔案系統的 12 位元版本）當持續儲存」的可靠度：有留言肯定用 bind mount 省空間很巧妙，但擔心 FAT12 不是日誌式（journaling）檔案系統，軟碟寫入又慢，若當機或中途斷電，可能造成檔案系統不一致甚至資料遺失；因此有人提議把剩餘空間當 raw block，或改用偏向追加寫入的日誌式檔案系統（例如精簡的 JFFS2，Journalling Flash File System 2），甚至把變更累積成 tar 並在關機時一次序列化寫回，以降低風險。也有人反駁「斷電就整張報廢」太誇張，指出 FAT 有兩份配置表可供復原，頂多出現 lost clusters（遺失叢集鏈）可用檔案系統檢查工具清理，並延伸到「日誌式檔案系統未必如想像中必要」的觀點。另一路討論把這類專案放回現實：即使 32 位元硬體效能對文書早已足夠，真正難題往往是應用層與驅動逐漸不再支援、以及瀏覽器型軟體的膨脹；有人補充 Debian 仍有 i386 支援，也有人建議改用 NetBSD 或用 isohybrid 等工具解決老 ISO 的開機媒介限制。
👥 57 則討論、評論 💬
https://news.ycombinator.com/item?id=46866544
我錯過了！但我回去看了討論
我看到「新鮮備份」一開始也霧煞煞（有看沒有懂）
後來這裡陸續有它的動作，我就突然覺得，搞不好作者把資料當成食物了，這樣剛好能得知為什麼作者會用「新鮮」來相容了（不過我還是投「全新備份」一票）
我看到「新鮮備份」一開始也霧煞煞（有看沒有懂）
後來這裡陸續有它的動作，我就突然覺得，搞不好作者把資料當成食物了，這樣剛好能得知為什麼作者會用「新鮮」來相容了（不過我還是投「全新備份」一票）
Notepad++ 供應鏈攻擊事件拆解 （★ 100 分）
Kaspersky 旗下 Securelist 研究指出，Notepad++ 開發團隊在 2026 年 2 月 2 日公告其更新基礎設施遭入侵，起因是 2025 年 6 至 9 月間主機代管商層級事件，但攻擊者仍能持續存取部分內部服務直到 2025 年 12 月。這起供應鏈攻擊（supply chain attack，入侵軟體發佈/更新管道以感染使用者）在 2025 年 7 到 10 月間呈現高度「輪替」特徵：攻擊者頻繁更換 C2（Command and Control，指揮與控制伺服器）位址、投放器與最終酬載（payload，惡意程式實際執行內容），以小規模、目標式方式鎖定約十餘台電腦，包含越南、薩爾瓦多、澳洲的個人使用者，以及菲律賓政府機關、薩爾瓦多金融機構、越南 IT 服務供應商；Kaspersky 表示其防護在當下已攔截到相關攻擊。
研究拆解出三條主要感染鏈。第一條（2025 年 7 月下旬至 8 月初）利用合法更新程式 `GUP.exe` 啟動被置換的 `update.exe`，其本體是 NSIS（Nullsoft Scriptable Install System，Windows 安裝程式框架）安裝包，會執行 `whoami`、`tasklist` 等指令蒐集系統資訊，將結果透過 `curl` 上傳到 temp.sh，再把上傳後的網址藏在 HTTP 的 User-Agent 欄位回傳給攻擊者；值得注意的是，該惡意網址在 VirusTotal 首次掃描出現於 2025 年 9 月下旬，來源使用者位於台灣。接著它投放一組檔案到 `%appdata%ProShow`，以合法的 ProShow 程式搭配早期已知漏洞啟動 exploit，解出殼碼（shellcode，置於記憶體中執行的機器碼片段），再由 Metasploit（滲透測試框架）下載器拉下 Cobalt Strike Beacon（常被濫用的紅隊工具植入程式，用於持續回連 C2）並建立通訊；期間還出現以「假殼碼」作為填充，企圖干擾研究與自動化分析。
第二條（2025 年 9 月中下旬）延續相同更新投放點，但將工作目錄改到 `%APPDATA%AdobeScripts`，蒐集資訊擴充到 `systeminfo`、`netstat -ano` 等，外傳手法仍依賴 temp.sh 與 User-Agent 夾帶網址。其第二階段改用一套看似正常的 Lua 直譯器檔案，真正的惡意邏輯藏在 `alien.ini`，負責把殼碼寫入可執行記憶體並透過 `EnumWindowStationsW` API（Application Programming Interface，作業系統提供的函式介面）觸發執行，之後同樣載入 Metasploit 下載器與 Cobalt Strike；到 9 月底又分拆指令、改用不同網域與端點。第三條（2025 年 10 月）則改以 `BluetoothService.exe` 搭配 `DLL sideloading`（利用合法程式載入惡意 DLL）執行惡意 `log.dll`，將加密殼碼注入程序並落地客製化 Chrysalis 後門；Securelist 也對照 Rapid7 的事件應變觀察，指出其 Beacon 設定與通訊端點仍與前兩條鏈有多處相似。整體攻擊在 2025 年 10 月中旬到月底間繼續變更更新網址與檔名，但 11 月起未再觀測到新投放；文末提供大量入侵指標 IoC（Indicators of Compromise，可用來偵測/追獵的網域、檔案雜湊、路徑等），並建議從 NSIS 執行痕跡、企業環境罕見的 temp.sh 解析紀錄、含 temp.sh 網址的異常 User-Agent、以及 `whoami` 等指令執行紀錄著手追查。
Hacker News 留言則把焦點拉回「到底該不該立刻更新」的兩難：不少人主張把安全修補與重大版本分流、用分批上線與延後（例如新版本發布後等一個月）換取外界偵測時間；企業端若有人力可做人工核准，並盡量從內部映像檔或本機鏡像更新以降低風險。也有人強調供應鏈攻擊雖可能相對少見，但一旦命中就會同時波及大量系統，且自動更新本質上是「主動去要一個可執行檔來跑」，風險往往高於偶發的檔案解析漏洞；討論中並點出 Notepad++ 的更新工具 WinGUP 可能未檢查更新安裝檔的憑證/簽章而直接執行，讓「有簽章」不足以保證更新路徑安全，因而建議改用 winget 等套件管理工具安裝、或採 Debian stable 這類以安全更新為主的發行版策略。另一條延伸脈絡是「把傷害關在沙箱」：多位留言者呼籲桌面作業系統應更接近 iOS/Android 的細緻權限與預設隔離，Linux 的 Flatpak/Snap 雖朝此方向前進但仍受質疑，並有人提出以能力導向安全（capability-based security）落實最小權限；同時也有人以 Windows 更新可靠性問題為例，認為當更新本身常出狀況，使用者更容易關閉自動更新，反而讓防護更脆弱。
👥 41 則討論、評論 💬
https://news.ycombinator.com/item?id=46878338
Kaspersky 旗下 Securelist 研究指出，Notepad++ 開發團隊在 2026 年 2 月 2 日公告其更新基礎設施遭入侵，起因是 2025 年 6 至 9 月間主機代管商層級事件，但攻擊者仍能持續存取部分內部服務直到 2025 年 12 月。這起供應鏈攻擊（supply chain attack，入侵軟體發佈/更新管道以感染使用者）在 2025 年 7 到 10 月間呈現高度「輪替」特徵：攻擊者頻繁更換 C2（Command and Control，指揮與控制伺服器）位址、投放器與最終酬載（payload，惡意程式實際執行內容），以小規模、目標式方式鎖定約十餘台電腦，包含越南、薩爾瓦多、澳洲的個人使用者，以及菲律賓政府機關、薩爾瓦多金融機構、越南 IT 服務供應商；Kaspersky 表示其防護在當下已攔截到相關攻擊。
研究拆解出三條主要感染鏈。第一條（2025 年 7 月下旬至 8 月初）利用合法更新程式 `GUP.exe` 啟動被置換的 `update.exe`，其本體是 NSIS（Nullsoft Scriptable Install System，Windows 安裝程式框架）安裝包，會執行 `whoami`、`tasklist` 等指令蒐集系統資訊，將結果透過 `curl` 上傳到 temp.sh，再把上傳後的網址藏在 HTTP 的 User-Agent 欄位回傳給攻擊者；值得注意的是，該惡意網址在 VirusTotal 首次掃描出現於 2025 年 9 月下旬，來源使用者位於台灣。接著它投放一組檔案到 `%appdata%ProShow`，以合法的 ProShow 程式搭配早期已知漏洞啟動 exploit，解出殼碼（shellcode，置於記憶體中執行的機器碼片段），再由 Metasploit（滲透測試框架）下載器拉下 Cobalt Strike Beacon（常被濫用的紅隊工具植入程式，用於持續回連 C2）並建立通訊；期間還出現以「假殼碼」作為填充，企圖干擾研究與自動化分析。
第二條（2025 年 9 月中下旬）延續相同更新投放點，但將工作目錄改到 `%APPDATA%AdobeScripts`，蒐集資訊擴充到 `systeminfo`、`netstat -ano` 等，外傳手法仍依賴 temp.sh 與 User-Agent 夾帶網址。其第二階段改用一套看似正常的 Lua 直譯器檔案，真正的惡意邏輯藏在 `alien.ini`，負責把殼碼寫入可執行記憶體並透過 `EnumWindowStationsW` API（Application Programming Interface，作業系統提供的函式介面）觸發執行，之後同樣載入 Metasploit 下載器與 Cobalt Strike；到 9 月底又分拆指令、改用不同網域與端點。第三條（2025 年 10 月）則改以 `BluetoothService.exe` 搭配 `DLL sideloading`（利用合法程式載入惡意 DLL）執行惡意 `log.dll`，將加密殼碼注入程序並落地客製化 Chrysalis 後門；Securelist 也對照 Rapid7 的事件應變觀察，指出其 Beacon 設定與通訊端點仍與前兩條鏈有多處相似。整體攻擊在 2025 年 10 月中旬到月底間繼續變更更新網址與檔名，但 11 月起未再觀測到新投放；文末提供大量入侵指標 IoC（Indicators of Compromise，可用來偵測/追獵的網域、檔案雜湊、路徑等），並建議從 NSIS 執行痕跡、企業環境罕見的 temp.sh 解析紀錄、含 temp.sh 網址的異常 User-Agent、以及 `whoami` 等指令執行紀錄著手追查。
Hacker News 留言則把焦點拉回「到底該不該立刻更新」的兩難：不少人主張把安全修補與重大版本分流、用分批上線與延後（例如新版本發布後等一個月）換取外界偵測時間；企業端若有人力可做人工核准，並盡量從內部映像檔或本機鏡像更新以降低風險。也有人強調供應鏈攻擊雖可能相對少見，但一旦命中就會同時波及大量系統，且自動更新本質上是「主動去要一個可執行檔來跑」，風險往往高於偶發的檔案解析漏洞；討論中並點出 Notepad++ 的更新工具 WinGUP 可能未檢查更新安裝檔的憑證/簽章而直接執行，讓「有簽章」不足以保證更新路徑安全，因而建議改用 winget 等套件管理工具安裝、或採 Debian stable 這類以安全更新為主的發行版策略。另一條延伸脈絡是「把傷害關在沙箱」：多位留言者呼籲桌面作業系統應更接近 iOS/Android 的細緻權限與預設隔離，Linux 的 Flatpak/Snap 雖朝此方向前進但仍受質疑，並有人提出以能力導向安全（capability-based security）落實最小權限；同時也有人以 Windows 更新可靠性問題為例，認為當更新本身常出狀況，使用者更容易關閉自動更新，反而讓防護更脆弱。
👥 41 則討論、評論 💬
https://news.ycombinator.com/item?id=46878338