固件逆向魔改 MP3 ，我掉進(jìn)了「賽博老虎機(jī)」的「陷阱」

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

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

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

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

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

▍這個設(shè)備挺爛的

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

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

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

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

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

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

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

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

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

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

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

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

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

▍固件魔改 初探

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

但咱有大語言模型不是！

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

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

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

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

字庫提取

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

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

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

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

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

一定是哪里出了問題，我當(dāng)時一直陷入了一個死胡同里，認(rèn)為是提取算法的問題。

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

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

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

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

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

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

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

直到后面我開了一個新的上下文，請 LLM 做了一個渲染結(jié)果到 ROM 地址的映射可視化工具，我一塊一塊看，并且跟新的上下文做了確認(rèn)，他問了我一句「你這固件文件哪里來的」？我把「修復(fù)腳本」給他看，他告訴我：那修復(fù)腳本 Fuck Up 了你的所有分析，他用錯誤的方式解讀了固件把數(shù)據(jù)結(jié)構(gòu)破壞掉了，所以才會出現(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ù)學(xué)，我給他幾個樣本字符，他「尋找規(guī)律」但一直告訴我沒有規(guī)律，一定是查表得到的。于是我找了更多樣本，甚至碼著 CJK 碼位搞出來了好幾排字，讓機(jī)器渲染出來、拍照，用 Gemini 的 Canvas 寫了兩個工具，造了一大堆的樣本給他搜。

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

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

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

這個問題卡了整整兩天。

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

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

上下文管理

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

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

結(jié)構(gòu)化歸檔

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

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

問題樹

單純歸檔還不夠，因?yàn)樗艿氖恰敢阎闹R」，而逆向工程推進(jìn)的過程中，問題本身是動態(tài)生長的。

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

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

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

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

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

NotebookLM

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

NotebookLM 在這個項(xiàng)目里扮演的是完全不同的角色。

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

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

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

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

具體流程是這樣的：

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

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

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

我把這份任務(wù)報告上傳進(jìn) NotebookLM 的文檔庫。NotebookLM 讀取最新報告，結(jié)合已有的全部文檔，生成下一份任務(wù)書。

循環(huán)往復(fù)。

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

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

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

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

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

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

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

讓兩個模型吵架

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

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

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

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

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

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

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

第一次：找 TRM 手冊

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

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

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

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

TRM 那條鏈接死了。

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

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

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

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

第二次：把設(shè)備本身當(dāng)文檔

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

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

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

刷！到！設(shè)！備！里！

研究推進(jìn)到一定階段之后，有一件事必須搞清楚：刷機(jī)有沒有簽名校驗(yàn)？

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

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

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

結(jié)論和直覺完全對不上：從固件結(jié)構(gòu)來看，它應(yīng)該有校驗(yàn)；從代碼邏輯來看，找不到任何地方在做校驗(yàn)。

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

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

工具的成型

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

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

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

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

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

▍當(dāng) LLM 變成老虎機(jī)

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

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

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

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

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

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

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

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

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

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

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

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

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

▍So What

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

但這個過程也讓人有點(diǎn)擔(dān)心。

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

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

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

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

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

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

但它在變低。

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

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

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

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

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

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

作者：LOSSES

責(zé)編：克萊德