Security

最近整理抽屜時，翻出了這台陪伴我一段時間的 Google Pixel 5。 身為一個喜歡折騰的開發者，早在它退役成為備用機時，我就第一時間把它刷成了 GrapheneOS。不得不說，GrapheneOS 在隱私保護和安全性上做得真的很好，沒有 Google Play Services 的純淨體驗也別有一番風味（雖然依賴 Sandboxed Google Play 還是能解決大部分 App 的問題）。 但就在前幾天，或許單純是想念 Pixel 原生系統的那些獨家功能（原生相機等等），我決定讓它「回歸原廠」。 原本以為又要經歷一番 adb 和 fastboot 的指令轟炸，還要自己去 Google 官網下載好幾 GB 的 Factory Image 壓縮檔，解壓後再祈禱 flash-all.sh 不要噴錯。 沒想到現在 Google 官方提供了一個方便的網頁工具：Android Flash Tool。 這篇文章簡單紀錄一下如何從 GrapheneOS 這種 Custom ROM，透過官方工具刷回 Stock Firmware 的過程。 為什麼選擇 Android Flash Tool？ 以前刷機的標準作業流程（SOP）： 搜尋正確的 Factory Image（還要對型號，買到電信商鎖定版就哭哭）。 下載 Android SDK Platform-Tools。 解鎖 Bootloader。 執行 flash-all script。 遇到驅動程式問題、傳輸線問題、路徑問題… 現在的 Android Flash Tool 直接把這些步驟簡化了： WebUSB: 直接透過瀏覽器與手機溝通，不用煩惱太底層的驅動設定（至少在 macOS/Linux 上是這樣）。 Auto Detect: 自動偵測裝置型號，自動下載對應的最新版韌體。 Fool-proof: 圖形化介面引導你開啟 USB Debugging 和 OEM Unlocking。 事前準備 雖然工具很強大，但基本的準備還是要有的： ...

最近換了新工作，到了一間資訊安全公司，讓我更加重視開發環境的安全。 還記得之前分享過透過 Distrobox 解決 Linux 環境依賴問題，用他來解決不同 Linux distribution 的依賴關係，背後即是讓程式跑在 container 內。 既然能夠將應用程式一來透過 container，與 Host OS 本身做出區隔，那麼我們也能透過 container 來對開發的依賴做出隔離。於是，開始擁抱 Dev Container，一個能讓我更安心、更有效率（？）的開發環境。 什麼是 Dev Container？ 簡單來說，Dev Container 就是把開發環境「容器化」。我們可以把所有需要的工具、函式庫、設定檔都放在一個 Docker Image 裡，然後用這個 Image 啟動一個 Container 作為你的開發環境。 Consistency (一致性)： 不管是在哪台機器上開發，只要有 Docker，就能保證開發環境完全一致。再也不用擔心「在我這台電腦上可以跑啊！」這種崩潰的狀況發生。 Isolation (隔離性)： Dev Container 與本機系統完全隔離，可以避免各種依賴衝突，也能保護系統安全。 Reproducibility (可重現性)： 透過 Dockerfile，你可以完整記錄你的開發環境設定，方便團隊協作和版本控制。 為什麼需要 Dev Container？ 身為一個資安從業人員，Dev Container 解決了以下痛點： 不同版本的 Node 環境，告別 nvm！需要 node14, node16, node18 或是 stable 版本，隨時產生開發環境。 需要下載 malware 到本地進行 e2e 測試，透過 container 進行蛤蜊（🦪意象），盡可能避免破壞系統安全性。 在 macOS 上解決一些只支援 linux 的 binary，或是在 arm64 host 上透過 rosetta2 模擬 x86_64 環境，進而執行 amd64 執行檔。 使用 rootless 模式，在危機四伏的 npm 環境中，確保開發環境的安全性。 我的 Dev Container 工作流 我將 dev-container 放在 github omegaatt36/lab/dev-container 中，以下 demo 僅「目前版本」，會依據使用情境進行迭代。 ...