固件逆向魔改 MP3 ，我掉進了「賽博老虎機」的「陷阱」

編注：我們會不定期挑選 Matrix 的優(yōu)質(zhì)文章，展示來自用戶的最真實的體驗和觀點。文章代表作者個人觀點，少數(shù)派僅對標題和排版略作修改。

導讀：全文 11169 字，閱讀所需 20-25 分鐘。毫無逆向經(jīng)驗的 LOSSES，靠著給 GLM 和 NotebookLM 當「傳話筒」，成功拆解了 MP3 的底層固件并做出了魔改工具。文章不僅復盤了解決 AI 長上下文降智的雙模型工作流，更深度剖析了 AI 高頻反饋如「老虎機」般榨干精力的心理陷阱。如果你對硬核的賽博修車感興趣，或是想了解 AI 工具帶來的隱蔽心理陷阱，不妨花點時間讀一讀。

敝人對「保存音樂的介質(zhì)」有一種迷一樣的執(zhí)著。如果你看過一個叫「科幻枸杞」的 YouTuber，那你大概就能懂。

我跟他的愛好還挺像的：小學的時候特別喜歡用家里的磁帶機做 MixTape，留下了很多美好回憶。而現(xiàn)在的人生理想是搞一臺自己的 Walkman 磁帶機。

但這事兒它不咋好搞。Walkman 這東西，死貴、坑又多。我今年的生日愿望就是期待一個好心「群友」送我一臺，但我知道他們會罵我臭不要臉。為了填補那深邃的消費主義空洞。半年前，我湊合著買了個飛傲（Fiio）出的 Echo Mini，一個長得像 mini 磁帶機的 MP3。

▍這個設備挺爛的

到手之后用了一陣子，產(chǎn)生了一種相當復雜的感受：挺好，但是活整得挺爛。

最辣眼睛的是那個大果粒顯示器，擱十五年前你可能會覺得它就是 Average Level 的顯示屏幕。但在 2026 年的今天，盯著它那個屏幕，就只會覺得頗為微妙。其實哪怕屏幕是大果粒，只要你的視覺做得好（比如復古像素風），說不定還是個優(yōu)勢。但這設備的設計爛就爛在那破 UI，一開機「地鐵老人看手機」的扭曲面龐就糊臉上了。

我一直跟「群友」抱怨，這些設計師一看就是小年輕，因為他犯的設計執(zhí)行錯誤實在太離譜了。所有的圖標，清一色全沒做像素對齊，所以看啥都是糊的。In case you didn't know, 蜀黍阿姨們還在玩設計的時候，屏幕分辨率都很低，為了讓畫面看上去銳利清晰通常都會盡可能避免錨點卡在半像素上導致次像素平滑。這設備的問題是很多圖標特別小，糊成一團基本就看不出來個形狀，盯著瞅半天滿腦子問號：這?是個啥？最荒謬的是，圖標是糊的，文字渲染又是像素字體。

再比如，當你正在升級固件的時候，屏幕上會顯示一個用中易黑、宋畫出來的丑陋界面，而且提示文字竟然不在畫面正中間！日用的時候如果你把語言切成法語，會發(fā)現(xiàn)帶裝飾符的字母和不帶裝飾符的字母大小還不一樣，字母全都全都高高低低參差不齊。

還有更迷幻的，所有的位圖 UI 素材看起來都像是先用有損格式導出，又轉(zhuǎn)成了 BMP 最后嵌入固件的。所有貼圖的明暗交界處都莫名其妙地多一圈白邊，而且細節(jié)充滿壓縮后的噪點痕跡。加上那說不上好的操作手感，用起來不免讓人身心不適。

當然它也有優(yōu)點：長得挺可愛、很小，揣出去還能當個社交談資。讓我最喜歡的一點是，它有兩個耳機孔！一個平衡口，一個 3.5mm 接口，甚至能一起工作！這讓我想起了上學時和好同學分享同一副耳機的青春歲月。現(xiàn)在有了這玩意兒，你可以和另外三個好朋友一起分享音樂了，四人同樂就非常的生草。

另外還有一些更離譜的玩法。

眾所周知，索尼降噪大耳包基本上就是低音拉滿玩命轟頭，高頻那邊則是又糊又難聽。但是我手邊正好有個平頭塞（YINCROW 那款，最近剛買的），高音處理得還不錯但是缺低音。那么問題來了：能不能讓他們一個負責高音，一個負責低音嘞？

既然要強化低音，那不如就把 Clear Bass 直接拉到 +10。平頭塞就正常聽，沒加額外 EQ。當我同時戴上兩個耳機（就是把平頭塞耳朵里，再把 XM3 罩在外面），然后輪流拔掉其中一個的插頭，發(fā)現(xiàn)拔掉索尼，聲音瞬間變薄，吉他指彈的泛音還在，但低頻的箱體共振沒了；拔掉平頭，聲音直接糊成一團，索尼那個悶糊感一下子就凸顯出來了。

兩個一起的時候，竟然出現(xiàn)了真 正 的 音 樂 d(???)b！

但這玩法不是沒有代價的，輸出相位肯定對不上，導致聲音聽起來特別「死」，像在水泥池子里游泳，空間感有很大的損失。

總體氣氛上就是這樣——硬件是好的，軟件是爛的，爛得非常均勻徹底。不光軟件 UI 設計是爛的，其實工程實踐也是爛的，這點后面再說。

所以我一氣之下（其實也沒太生氣，就是動了個念想）開始嘗試魔改固件。

▍固件魔改 初探

我?guī)缀鯖]有任何逆向工程的經(jīng)驗，上一次干這事兒還是在初中，經(jīng)驗早就忘光了。關于「逆向」這事情封頂?shù)慕?jīng)驗是研究被 Uglyify 的 JS 代碼。所以，這活兒不是專業(yè)的人恐怕是真的干不來。

但咱有大語言模型不是！

我試了下讓 GLM 4.7 摸了一下固件大體的形狀，他還真給分析出了點有料的東西。一開始，我和他講「這有個固件，我的目標是把里面的位圖給提出來，你告訴我咋整。」他就告訴我，他需要 capstone, ghidra, r2pipe, rzpipe, angr。NixOS 裝這些玩意的 Python binding 有一丟丟麻煩，但最后還是給配上了。

接下來他就開始自己掃二進制文件。沒一會兒，芯片型號、SDK 型號全給掃出來了。他還找到了分區(qū)表，甚至自己嘗試讀取指令序列，發(fā)現(xiàn)了某種「固件加密」，做了修正程序（此處有巨大伏筆）。

后面，他爬到了文件內(nèi)嵌的文件系統(tǒng)，順藤摸瓜把.bmp文件全都給拽了出來了，我一看，圖還真都是那么個形狀。

但提取的時候也遇到了麻煩。那個 BMP 的顏色編碼怎么都對不上。這地方就得我上場了，畢竟它不長眼睛，但我長眼睛。我負責看，它負責不停地試參數(shù)，最后我倆總算是把正確的解碼參數(shù)給碰出來了。

字庫提取

因為是像素圖，所以有一個最簡單的假設，字庫的存儲是二進制序列，0 是空白 1 是帶字的部分。于是我掏出手機拍了一下屏幕上的漢字，然后開始數(shù)像素顆粒碼到 TXT 文檔里面當成搜索樣本——不得不說，這還真得感謝它是大果粒像素字體！讓我能看清那一顆一顆的像素。

我把摳出來的幾個字交給 GLM 4.7，告訴他「就這幾個字，你想辦法去掃掃看。」結果意外的好，他通過各種墊 padding，還真把那像素字體存儲的位置給抓出來了。

雖然找到了字形文件，但不知道數(shù)據(jù)結構是啥，也不知道索引表在哪。這就開始了漫長的盲人摸象。而且有一個很擰巴的點是，每隔幾個字就會出現(xiàn)字符撕裂，就是左半邊往上挪一點，右半邊往下挪一點，隔一個字就來一下，完全不知道咋回事。

沒啥招，只能看固件里面的文字渲染邏輯了。反正字在哪兒已經(jīng)知道了，在地址上下摸一摸，總能摸出點東西。不到半小時，它就把渲染函數(shù)給摸出來了，然后一步步往上爬，最后找到了渲染公式。

但是這一直都沒辦法解釋為什么會出現(xiàn)圖像撕裂。為了解決這個問題，我們還一度懷疑是不是一些軟硬件通信協(xié)議層面上的協(xié)定，甚至造了一個涉及 VOP DMA 的迷你渲染模擬器，問題都沒抓出來。

一定是哪里出了問題，我當時一直陷入了一個死胡同里，認為是提取算法的問題。

撕裂的模式很明確左半邊往上偏一點，右半邊往下偏一點，隔一個字出現(xiàn)一次。于是我便嘗試讓 GLM 4.7 嘗試找出偏移規(guī)律。這里面出現(xiàn)了一個很煩人的點，它經(jīng)常打出一大堆 ASCII Art，明明打出來的字都已經(jīng)扭曲了，但是他還是信誓旦旦地告訴我：對的，這是漢字，完整的漢字沒問題。

但那個字明明已經(jīng)裂開了。

LLM 是文本模型，它只能一行一行地橫向讀數(shù)據(jù)。 它看到的是一行行由點和井號構成的字符串，它能從統(tǒng)計規(guī)律上猜測「這看起來像漢字」，但它根本沒有二維視覺，它看到的東西和人眼看到的完全不是同一件事。你要它判斷一個字形對不對，它給你的不是視覺判斷，是一個概率預測，而這個預測非常容易出錯。

另外，他非常喜歡統(tǒng)計建模，認為「80% 對上了」比「50% 對上了」更好，哪怕它比對的可能完全不是一個東西。此時，你得非常耐心地告訴他，這東西只有完全對上了和完全對不上，沒有只對得上一半的情況。

這件事反復發(fā)生了十多次。每次我說「你確定這是漢字嗎？字都撕裂了，形狀不對，字形不完整是好幾個字拼在一起的」，它就道歉、重新分析，上下文爆掉壓縮，犯過的錯誤被很糟糕的壓縮提示詞給搞丟，你明確告訴他「你要一列一列地讀，不要一行一行地讀」，他聽了，然后過一會兒自動退回到行讀模式。再告訴一遍，再退回去。你的指令對它來說是臨時覆蓋，不是真正改變了它的工作方式。

這個過程中我有幾次情緒失控，直接開始飆罵。事后發(fā)現(xiàn)這是個非常具體的問題：你的情緒一旦注入對話，它會留在上下文里，甚至這些信息會在上下文壓縮過程中保留下來（但是重要的方法論經(jīng)驗不會流下來），然后持續(xù)污染后續(xù)的推理質(zhì)量。罵它之后，它開始把大量精力用來安撫你的情緒，而不是解決技術問題，并且前方百計地避免觸發(fā)你的情緒感受，最后變得什么都不做，非常像人類的 FoF 反應。結果就是，推理越來越弱，你越來越煩，惡性循環(huán)。

這是個很實用的教訓：和 LLM 協(xié)作時，你的情緒狀態(tài)是工程變量，不是私事。

直到后面我開了一個新的上下文，請 LLM 做了一個渲染結果到 ROM 地址的映射可視化工具，我一塊一塊看，并且跟新的上下文做了確認，他問了我一句「你這固件文件哪里來的」？我把「修復腳本」給他看，他告訴我：那修復腳本 Fuck Up 了你的所有分析，他用錯誤的方式解讀了固件把數(shù)據(jù)結構破壞掉了，所以才會出現(xiàn)字符撕裂的問題。

至此懸案解開了。

檢字系統(tǒng)逆向

至此我們只找到了 CJK 區(qū)域的字，但是對于其他區(qū)域的字一無所知。我們看到了平面之間有大量純 0 空白數(shù)據(jù)，有一段連續(xù)數(shù)據(jù)，中間又有大片空白，然后又是一大堆數(shù)據(jù)。LLM 說數(shù)據(jù)是分塊存儲的，并且狡猾地繞過了對那一大堆純 0 數(shù)據(jù)來源的解釋。

按照整個邏輯，如果數(shù)據(jù)是分片的，那么就需要有一個表，它就開始嘗試產(chǎn)生一千零一種幻覺，試圖把「查表」這個假說給硬凹出來。

另外你也知道的，模型極不擅長數(shù)學，我給他幾個樣本字符，他「尋找規(guī)律」但一直告訴我沒有規(guī)律，一定是查表得到的。于是我找了更多樣本，甚至碼著 CJK 碼位搞出來了好幾排字，讓機器渲染出來、拍照，用 Gemini 的 Canvas 寫了兩個工具，造了一大堆的樣本給他搜。

具體來講，其中的一個工具是二進制序列復原工具，傳入一張照片切片，自動切成 16×15 的格子，每格生成一個直方圖，中間加一條拖動的分割線，標記左邊是黑，右邊是白，自動做二值化判斷。之后我只需要拍照、傳圖、調(diào)分割線，字形就自動描出來了。

還有一個工具：給定一個位圖，自動生成前后 100 個 Unicode 碼位的字符表，點擊某個字符就把對應的碼位復制出來。這是因為當時根本找不到一個好用的 Unicode 碼位查詢網(wǎng)站，干脆自己造一個。

但是他一直在錯誤的上下文當中牽強附會，直到我把所有掃到的數(shù)據(jù)導出來扔給 Gemini 的 Canvas 做了一個線性回歸擬合把公式甩回去之后……嘿！它依然不聽！因為這跟它看到的指令序列邏輯對不上。它說推出來的寬度是 32，實際渲染的卻是 33。

這個問題卡了整整兩天。

但好在我用 LLM 的習慣比較好，每次有研究成果都會直接輸出一份 Markdown 筆記，并且有適度地維護整個文檔庫。于是我把整個文檔庫全都塞給了 NotebookLM，并且把整個問題上下文全都粘給 NotebookLM。NotebookLM 一眼就看出來了：編譯器把乘以 33 優(yōu)化成了「左移 5 位再加原值」，即x << 5 + x。因為位移運算比乘法快，編譯器會自動做這種替換，但 GLM 在分析反編譯結果時沒有識別出這個模式，所以一直把參數(shù)認成了 32。

這里又學到了兩個重要的知識：復雜任務需要多個模型進行眾議，一個模型很有可能會陷入知識盲區(qū)。事實上 Grok 最近也上架了一個集成多模型眾議的模式，看著還挺好玩的。

上下文管理

到這個階段，一個很明顯的問題就被暴露出來了：只要你的上下文窗口一大，塞的東西一多，它就會變?nèi)踔恰?/strong>當時我們倆生成的各種文檔、日志、代碼片段已經(jīng)有好幾千行了，它開始胡說八道，不停地抱怨，開始戳一步走一步，執(zhí)行開始變得非常死板。

而且之前留下來的文檔越累積越多，越來越長。如果一篇文檔就能把上下文吃個大半，那整個研究便無從繼續(xù)。所以是時候做 House Keeping 了。

結構化歸檔

第一步是把所有積累下來的文檔一次性扔給 Claude，讓它幫我整理成樹狀目錄，每個知識點單獨成文，文件之間互相索引，入口是一份導讀。后續(xù)遇到具體問題時，只需要把目錄加上相關的一兩個小文件投喂給模型，而不是把整個研究歷史都塞進去。上下文消耗量大幅壓縮，模型能跑得更久、更準。

但這只解決了存量文檔的問題。GLM 還有個壞習慣：讓它記一份文檔，它會偷偷創(chuàng)建三份。你的文檔庫很快就變成垃圾堆，所以借助額外的模型維持文檔庫是很重要的（但后面我發(fā)現(xiàn) NotebookLM 做這事情效率更好一些）。

問題樹

單純歸檔還不夠，因為它管的是「已知的知識」，而逆向工程推進的過程中，問題本身是動態(tài)生長的。

我維護了一份專門的問題樹文檔。這里面不是一個簡單的待辦清單，記錄了整個問題空間的動態(tài)演化：一個大問題在研究推進中會衍生出若干子問題，子問題解決了一部分，又暴露出新的未知，新的未知再裂變成更具體的小問題。這棵樹完整地記錄了這個裂變過程。

這種結構帶來的解決帶來了兩個好處。一方面，它對問題空間有一個高維度的抽象描述，你隨時能看清楚「我們現(xiàn)在在哪、還有什么不知道、當前最重要的瓶頸是什么」，而不是淹沒在一堆零散的技術細節(jié)里。第二，也是更關鍵的，它極大地幫助維護上下文的清潔。

具體來說：每次開啟新的攻堅，我不是把所有研究文檔都塞給模型，而是只把問題樹的當前狀態(tài)貼進去，從里面挑一個最重要的子問題，讓模型圍繞這一個問題生成任務指導書。模型拿到的是一個被高度抽象和壓縮過的問題描述，而不是幾天來積累的原始推導過程。這樣它的上下文是干凈的，推理質(zhì)量就能維持在正常水平。

這一點在項目后期尤其關鍵。當研究推進到最深處、GLM 4.7 開始不停胡說的時候，我開了一個全新的對話窗口，把問題樹的當前狀態(tài)貼進去，挑出最重要的那個子問題，讓 GLM 研究清單。原因很簡單：它拿到的是一個干凈的、經(jīng)過抽象的問題，而不是被幾天噪聲污染過的上下文。

這套方法的核心邏輯是：大語言模型的有效工作窗口是有限的，你塞進去的信息越多，它能分配給真正思考的空間就越少。問題樹做的事情，是把一個復雜項目的知識狀態(tài)壓縮成一個可以隨時拎起來、隨時投喂的抽象結構，它不記錄你做了什么，它記錄你還不知道什么，以及這些未知之間的關系。

NotebookLM

在整個逆向工程項目里，GLM 承擔的是主要的執(zhí)行工作，掃描二進制、反編譯、寫代碼、追調(diào)用棧。但它有一個難以回避的缺陷：它太容易順著你的思路走。你給它一個方向，它會沿著這個方向一直推，推到撞墻為止，然后開始在墻邊原地打轉(zhuǎn)，卻不會主動后退一步質(zhì)疑這個方向本身是不是錯的。

NotebookLM 在這個項目里扮演的是完全不同的角色。

任務書—任務報告的協(xié)作模式

這套工作流的核心是把知識積累和任務執(zhí)行拆成兩個彼此獨立的上下文。

• NotebookLM 負責知識側(cè)：它的文檔庫里存放著所有的研究成果、問題樹、技術文檔。它不參與具體執(zhí)行，它只讀文檔，然后輸出任務書。

• GLM 負責執(zhí)行側(cè)：它拿到任務書，專注執(zhí)行，完成后輸出任務報告。它的上下文里只有當前任務的執(zhí)行細節(jié)，不需要記住整個項目的歷史。

具體流程是這樣的：

項目卡住，或者一個階段告一段落，我讓 NotebookLM 讀當前文檔庫里的所有研究成果，生成一份任務書。任務書的結構是固定的：問題陳述（我理解你現(xiàn)在卡在哪里）、分步課題（把大問題拆成三四個可管理的小目標）、任務清單（每個目標下列出具體步驟，明確說動作是什么、目的是什么）。

我把這份任務書原樣交給 GLM 執(zhí)行。不加任何個人解釋，不加任何情緒，就是一份簡簡單單的結構化文檔。

GLM 執(zhí)行完成后，輸出一份任務報告：研究目標、關鍵發(fā)現(xiàn)、結論、遺留問題、下一步建議。同樣是固定結構。

我把這份任務報告上傳進 NotebookLM 的文檔庫。NotebookLM 讀取最新報告，結合已有的全部文檔，生成下一份任務書。

循環(huán)往復。

表面上看，我只是在兩個模型之間來回傳文檔，但它解決的是一個很麻煩的問題：上下文污染。

正常的人機對話模式里，你的情緒、你不專業(yè)的描述、你那些啰嗦的廢話、你的錯誤假設，全都會隨著對話積累進上下文，然后隨著壓縮過程被保留下來，持續(xù)干擾模型的推理質(zhì)量。罵它一句，這句話會留著；給了一個錯誤的前提，這個前提會留著；繞了一大圈彎路，這段彎路會留著。上下文越長，這些垃圾積累得越多，模型的推理能力就會變得越弱。

任務書機制切斷了這個污染路徑。NotebookLM 只讀結構化文檔，這樣就不存在你和 GLM 之間的聊天記錄；GLM 只執(zhí)行任務書，不需要理解整個項目的來龍去脈。兩者之間傳遞的全是格式化的、無情緒的、經(jīng)過提煉的信息。

這相當于變相拓展了整個系統(tǒng)的有效上下文空間。不是把一個模型的上下文窗口變大，而是把知識和執(zhí)行分離存放，讓每一側(cè)都只承載它真正需要的信息。

GLM 看到任務書之后會表現(xiàn)出一種很「興奮」的態(tài)度，表示「哦，原來可以這樣做！」然后 GLM 又能跑一段了。跑一會兒，又哭了。我再把新的問題陳述扔給 NotebookLM……

基本上，我就成了個「人肉管道」（SPL, System Prompt Line）。我看他倆聊得火熱，但我一個人是懵的，很多細節(jié)我根本不懂。我只負責在他倆之間來回傳話，全程發(fā)懵，只能在旁邊鼓掌：「大佬們真棒！」

不過這事情后面有了更加自動化的解決方法，用了這個 Skill 之后，只要提示詞給好，讓它倆自己聊就行了，我也不用來回復制粘貼了。

讓兩個模型吵架

這套機制還有一個變體用法：當某個技術問題存在爭議時，我會讓兩個模型互相批判對方的方案。提示詞是固定的：

請系統(tǒng)性的用逆向分析工具調(diào)查，并用建設性批判（constructive criticism）的方式回應以下觀點。

GLM 給出結論，交給 NotebookLM 批判；NotebookLM 給出修正，交回 GLM 批判。來回幾輪之后，一個經(jīng)過雙向檢驗的分析框架自然浮現(xiàn)出來。兩個模型單獨面對人類輸入時都傾向于順從，但面對另一個模型的結論時批判性會明顯提高。字符渲染管線最難啃的部分就是用這個方式調(diào)出來的。

我在這套機制里做的事情只有三件：決定什么時候切換（執(zhí)行卡死了就切到 NotebookLM）、判斷任務報告的結論是否可信（模型沒有眼睛，視覺判斷必須由我來做）以及維護問題樹（決定下一個最重要的子問題是什么）。其他所有事情，都在這個機器對機器的閉環(huán)里自動完成。

這是整個項目里最重要的一個方法論發(fā)現(xiàn)：雖然聰明的模型很重要，但是一個不會讓它變笨的工作環(huán)境也很重要。

LLM 開始胡說時，說明你喂的信息可能不夠了

這是整個項目里反復驗證的一條規(guī)律，也是最反直覺的一條：當 LLM 開始四處碰壁、原地打轉(zhuǎn)、輸出越來越離譜的結論時，第一反應不應該是換個提示詞，而是問它：你缺什么信息？

第一次：找 TRM 手冊

字庫逆向推進到一半，GLM 開始出現(xiàn)典型的「信息饑渴」癥狀，靜態(tài)分析反復聲稱「找到了函數(shù)入口」，但給出的地址在固件里根本不存在；推導鏈條越來越長，結論越來越玄；每隔幾輪就說「我已經(jīng)達到了靜態(tài)分析的極限」。

我停下來直接問它：你現(xiàn)在需要什么才能繼續(xù)？

它說：我需要這顆芯片的 Spec 和 TRM。Spec 是硬件規(guī)格書，TRM 是技術參考手冊，里面有完整的指令集、寄存器定義、內(nèi)存映射。沒有這些它只能靠猜，而它已經(jīng)猜不下去了。

芯片型號是 Rockchip RKnano D。我去搜，找到了一份 Spec，但 Spec 只有硬件層面的參數(shù)，沒有指令集。TRM 才是真正需要的東西，但搜遍常規(guī)渠道，什么都沒有。搜索過程中找到一個日本人的網(wǎng)站，上面列出了兩條 URL，分別指向硬件文檔和指令集文檔。點進去之后赫然彈出了一個 404。

TRM 那條鏈接死了。

我盯著那個 404 的 URL 看了一會兒，然后把之前有效的 Spec URL 并排放在一起對比。一級域名相同，二級域名不同，一個是 Wiki 子域，一個是主站域名。網(wǎng)站搬過家，內(nèi)容從 Wiki 遷到了主站，但日本人的那個網(wǎng)站上記錄的還是舊地址。我把 TRM 那條 URL 里的子域名改成主站格式，刷新。文件下載成功了。

這是一個純粹靠人的思維方式才能解決的問題。幾乎不會有模型去盯著一個 404 的 URL 想「這兩條鏈接的域名結構有什么關系」，它只會告訴你「文件不存在」然后建議你換個搜索詞。發(fā)現(xiàn) URL 結構規(guī)律、推斷網(wǎng)站遷移、手動修改路徑，這個推理鏈條需要的是人對網(wǎng)站運作方式的隱性經(jīng)驗，不是模型能做到的。

TRM 到手之后，我把它交給 NotebookLM。它拿到文檔，立刻找到了之前那些「不存在的地址」對應的硬件機制，卡了很久的分析線索重新跑起來了。

順手把這份 TRM 手動備份到了互聯(lián)網(wǎng)檔案館，發(fā)現(xiàn)幾年前已經(jīng)有人備份過，只是沒被搜索引擎收錄。白忙了一場，但也只是浪費了一點時間。

第二次：把設備本身當文檔

推進到硬件模擬階段，GLM 在判斷某些具體硬件規(guī)格時又開始亂說。這次我沒有去找外部文檔，而是想到了另一個信息來源：設備本身。

我把播放器的軟硬件版本號、以及播放器官方頁面上列出的產(chǎn)品 Spec 全部整理出來，一起交給 GLM。

這些信息看起來很普通，甚至有點像湊數(shù)，但它為一處基礎的硬件版本判斷提供了重要的數(shù)據(jù)錨點。順著條件判斷邏輯樹一路往后推，發(fā)現(xiàn)了幾處和之前推理對不上的地方，順著這些矛盾點往回追，核心的硬件規(guī)格判斷問題得到了突破。最后關于文本渲染的完整調(diào)用棧被徹底抓了出來，這也直接促成了 Flame Ocean 的字庫檢索和替換工具的完成。

刷！到！設！備！里！

研究推進到一定階段之后，有一件事必須搞清楚：刷機有沒有簽名校驗？

不管固件逆向做得多漂亮，如果設備在寫入時會驗證固件簽名，一切努力都白費。我先讓 GLM 掃了一遍固件，問它有沒有發(fā)現(xiàn)任何簽名校驗或安全防護機制。它言之鑿鑿地說：沒有找到任何防護措施。

但這個結論站不住腳。「沒找到」不等于「沒有」這是個典型的條件概率問題，就像統(tǒng)計學里 p 值不顯著不能說明沒有效應一樣。沒有證據(jù)不是沒有的證據(jù)。于是我換了要求：不能憑空下結論，必須用反編譯數(shù)據(jù)做實際佐證，找到代碼，看到邏輯，才能說話。

接下來我讓模型 M 認真去掃，還真找到了東西，固件里有一個 CRC 校驗的函數(shù)。但這個函數(shù)非常奇怪：返回結果只有 8 bit。與此同時，固件最尾端有一段數(shù)據(jù)，結構上看起來非常像某種校驗哈希。之前我大概研究過一下，Rockchip 自己有一套叫 RKCRC 的算法，這段數(shù)據(jù)的位置和格式都很符合。但追了半天也找不到任何驗證邏輯去讀取或比對這段數(shù)據(jù)。

結論和直覺完全對不上：從固件結構來看，它應該有校驗；從代碼邏輯來看，找不到任何地方在做校驗。

靜態(tài)分析給不出確定答案，于是我頭鐵直接把做了一點修改的刷機包塞到了機器里。它真的一點校驗都沒做就把我的固件包給吃下去了，中間沒有任何攔截。我去問了群里做硬件的群友。他們告訴我，這類低端 MP3 設備校驗一般做在刷機軟件里，不做在硬件上。而且 Snowsky 這臺設備的刷機方式本來就很奇特，你只需要把刷機包復制到根目錄，設備開機自動檢測到就會升級，不需要專用的刷機工具。so……

也有群友告訴我，哪怕很多車機的固件升級也不會做任何完整性校驗，如果你把下載了一半就斷掉的固件喂給它，你的車就會被刷成超巨大黑磚——也算是長見識了。

工具的成型

研究材料都備齊了，接下來就是寫一個小工具，用來做資源編輯和替換。整個工具是用 Svelte 搞的，我基本也沒親自動手寫，直接讓 LLM 幫忙做了簡單的組件封裝，界面突突突就給做出來了。說真的我也沒太在乎美丑，就是個實用工具而已。

出于好玩的心態(tài)，我給這工具起了個名字叫 Flame Ocean——as you can see, Snow Sky 的相反。工具寫完扔到了 Reddit 上，幾乎是同一天立刻就有人把 Boot Screen 動畫換掉了，還發(fā)了個 PR 過來，可以自動把視頻變成序列幀動畫（雖然那 PR 的品質(zhì)有點低，我花了一整天才把它的 UX 修到可以接受的水平，但還是感謝社區(qū)參與）。

后面陸續(xù)開始出現(xiàn)各種改 Mod 的案例，前幾天都是簡單開機畫面魔改。上傳官方 firmware 到 flame-ocean.not.ci，點一下「Replace Image」、下載新 bin 文件、刷機。幾分鐘后，你的二刺猿老婆就住到設備里了。

再過幾天，更加徹底的魔改皮膚開始出現(xiàn)。我最喜歡的是這個破真磁帶機主題、EVA 主題、 Fallout 主題。這個仿 macos 的主題也挺好玩的，而且作者提出了 pixel perfect 的重要性。

社區(qū)的環(huán)境也挺不錯的。后面出現(xiàn)了一個網(wǎng)站專門收集魔改固件。如果有新手提問，沒過多久就會有人在下面答疑，來自社區(qū)的魔改教程文檔也開始出現(xiàn)了。

▍當 LLM 變成老虎機

關于大語言模型的心理健康風險，現(xiàn)有的討論集中在兩個方向：用 LLM 做心理咨詢反而讓心理變差，以及用 LLM 寫代碼產(chǎn)生冒牌者綜合征。這兩個問題都有人講過，我不想重復。

整個逆向工程項目期間，我把很多晚上耗到凌晨三點。同學在小組作業(yè)會議里聽到我的聲音，問：你還好嗎？我說沒事很好。但我手表告訴我已經(jīng)長期處于應激狀態(tài)，身體和心理都在承受持續(xù)的消耗，我自己完全沒有察覺。

原因不是項目難，而是大語言模型制造了一種極高密度的實時正反饋。

每發(fā)出一個任務，五分鐘內(nèi)就有進展報告。每份報告都把當前的進展描述成突破性進展。解決一個子問題，立刻暴露出下一個子問題在等待。這個循環(huán)沒有自然的停頓點，沒有「今天做完了」的時刻，只有永遠的「再推一步就出來了」。

對于 ADHD 患者來說，這個模式和賭場老虎機在神經(jīng)機制上是同構的。老虎機的設計原理是變比率強化，不是每次都贏，但贏的時刻不可預測，這種不確定性制造的多巴胺刺激比固定獎勵強得多。大語言模型的協(xié)作過程完全符合這個模式：大多數(shù)時候在推進但沒有突破，偶爾突然跳出一個關鍵發(fā)現(xiàn)，然后立刻又陷入下一個未知。你永遠不知道下一個任務書執(zhí)行完是平淡收場還是重大突破，但你迫切地想知道。

再來一把。再推一步。說不定這次就出來了。

這件事對普通人也有影響，但對 ADHD 患者的殺傷力則是另外一個故事。

ADHD 的核心機制之一是執(zhí)行功能出現(xiàn)問題，他們難以啟動任務，但一旦進入高度感興趣的狀態(tài)，又極難主動脫離。這不是意志力問題，是神經(jīng)層面的調(diào)節(jié)困難。大語言模型的高頻反饋恰好精準地觸發(fā)了這個機制的第二面：它不停地用小獎勵把你釘在椅子上，讓你的大腦持續(xù)處于「再做一點就完成了」的錯覺里。

與此同時，我對這個項目的難度存在系統(tǒng)性低估。我不懂逆向工程，所以我評估不出來「找到 Unicode 到字形的完整映射公式」這件事究竟有多難。不懂的人傾向于低估難度，低估難度就會持續(xù)覺得「馬上就好了」，而大語言模型每次給出的進展報告又在不斷強化這個錯覺。我在想象這件事成功的樣子，我在追逐一個我以為觸手可及但實際上還很遠的終點。

這是一種很隱蔽的痛苦，一點一滴的把你的精力榨干。你不會覺得自己在受苦，你會覺得自己在全力沖刺。直到精疲力竭你才意識到某種痛苦，但是人卻完全無法脫離這個高速反饋的實時環(huán)境。

冒牌者綜合征的問題是：LLM 替你做了事，你懷疑自己的能力。這是一個關于自我認知的問題。

我描述的這個問題不同。它不質(zhì)疑你的能力，它消耗你的身體。它利用的不是你的不自信，而是你對進步的渴望、對完成的執(zhí)念、以及你大腦里那個停不下來的獎賞回路。它和賭博成癮、手機上癮的底層機制是一樣的，只是包裝成了「我在做一件很有意義的事」。

在我寫這篇文章的當下，所有待解決的問題還沒有清理干凈。我也沒有找到一個好的方法在保持高效協(xié)作的同時主動踩剎車。我能做到的只是把這件事說清楚，讓下一個陷進去的人至少知道那種停不下來的感覺不只是熱情，也是一個需要警惕的信號。

▍So What

通過這一頓狂暴折騰，逆向工程基本上是跑通了。我用 LLM 寫了各種調(diào)試用的小工具，甚至還寫了個很小的硬件模擬器模擬字符渲染，最終把字庫渲染那一坨給基本搞明白了。

但這個過程也讓人有點擔心。

你想想，我，一個只做過前端、只會解混淆 JS 的菜狗，靠著兩個 LLM 吵架，就能把一個設備的底層固件給拆得七七八八。這意味著什么？這意味著未來「腳本小子」的門檻被無限拉低了。

而且，那個全自動的未來已經(jīng)很近了。

最一開始我還是那個坐在中間手動傳紙條的人：從 NotebookLM 取任務書，貼給 GLM 執(zhí)行，把報告取回來，再送回 NotebookLM。整個流程是自動化的，但調(diào)度靠人。NotebookLM Skill 的出現(xiàn)把這一步也省了，我只需要坐椅子上盯著就行了。

另外，DeepSeek 最新發(fā)表的稀疏注意力機制，在相當程度上緩解了本文反復提到的那個核心痛點：上下文一長模型就變?nèi)酢Ｈ绻@個問題被真正解決，「人」的參與空間會進一步被壓縮，原本需要人來判斷「現(xiàn)在該切到哪個模型」的那個決策，也開始可以被自動化。

更值得警惕的是另一件事：很多能力很強的大模型是開源的。這意味著只要你有足夠的算力，相當多大語言模型的行為可以完整運行在你自己的機器上，不經(jīng)過任何第三方服務，不受任何平臺審計。一套完整的逆向工程流水線從固件掃描、反編譯、漏洞識別、利用路徑推導，這當中的每一步理論上可以在任何人的地下室里全天候不間斷地跑，針對任何一個目標。

目前這條路還有一道真實的門檻：小模型的推理能力依然不夠。IQuesta Coder 這類自稱 SoTA 的輕量模型，在面對稍微復雜一點的工程任務時，連 OpenCode 的基本文件編輯命令都拉不利索，更不用說獨立完成完整的逆向分析鏈條。復雜項目依然需要大模型，大模型依然需要算力，算力依然需要錢。這道門檻現(xiàn)在還在。

但它在變低。

我做這個項目的出發(fā)點只是嫌一臺 MP3 的 UI 太丑。沿著這條線走下來，在一個完全不是我專業(yè)領域的方向上，借助兩個模型和一份手冊，把一顆嵌入式芯片的字符渲染管線從頭到尾摸了個七七八八。我不是安全研究員，我沒有逆向工程背景，我只是有耐心，會提問，懂得什么時候該喂什么信息。

如果這件事?lián)Q成一個真正懂安全的人來做，換成一套自動化的流水線來做，換成一個不需要睡覺、不會情緒崩潰、上下文永遠干凈的系統(tǒng)來做，它能做到什么程度呢。

或許不會有白癡希望把自己車機的開機畫面改成二刺猿老婆，但是你正開在高速上突然車機上跳出來一個 Jump Scare，也挺嚇人的。

那個全自動的未來不是科幻，它已經(jīng)在路上了。

后續(xù)：做了一些深度 Hack 把設備搞磚了，然后 Claude 一頓神操作，進了 maskrom，連 loading bin 都不需要直接就把磚了的設備給刷回來了，這神秘的世界……

https://sspai.com/post/106443?utm_source=wechat&utm_medium=social

作者：LOSSES

責編：克萊德