：深入解析 EVM 整數(shù)溢位與下溢（Integer Overflow and Underflow）)
文檔網(wǎng)絡安全教程【免費下載鏈接】ctf-wikiCome and join us, we need you!項目地址https://gitcode.com/gh_mirrors/ct/ctf-wiki點擊查看免費下載本篇技術指南以 ctf-wiki 區(qū)塊鏈章節(jié)為核心系統(tǒng)講解以太坊虛擬機EVM中整數(shù)溢位Overflow與下溢Underflow漏洞的成因、利用手法與防禦方案。通過對 Capture The Ether 的 Token sale 經(jīng)典題目的完整推導、一個錯誤的取款合約示例以及與重入攻擊的關聯(lián)分析讀者將掌握如何在 CTF 比賽中識別、計算並利用整數(shù)回繞漏洞同時了解 SafeMath 等緩解措施的底層原理與適用前提。原理EVM 整數(shù)的位寬與靜默取模以太坊虛擬機中所有整數(shù)計算都發(fā)生在 256 位字word的基礎上。Solidity 為開發(fā)者提供了兩類整數(shù)類型int有符號整數(shù)uint無符號整數(shù)。在int或uint之後可以跟隨一個 8 的倍數(shù)用來表示該整數(shù)的位數(shù)例如 8 位的uint8、16 位的uint16。位數(shù)上限為 256 位因此int和uint本質上分別是int256和uint256的別名在實際的智能合約代碼中uint的使用更為常見。關鍵的漏洞機制在於當整數(shù)計算的結果超出其位數(shù)所能表示的上限或下限時EVM 不會拋出錯誤而是靜默地對結果進行取模wrap around操作。這與傳統(tǒng)語言如 C/C中無符號整數(shù)的溢出行為一致但對於依賴餘額計算的智能合約而言後果可能是災難性的。從 EVM 指令層面看算術運算對應的 opcode如ADD、MUL、SUB本身不攜帶任何溢位檢測結果直接以 256 位截斷後返回。相關指令的語義可以參考 Ethereum Opcodes 一章操作碼助記符棧輸入棧輸出表達式01ADD| a | b || a b |a b02MUL| a | b || a * b |a * b03SUB| a | b || a - b |a - b從攻擊者的視角看我們通常希望費用向上溢出變得極小或者存款向下溢出變得極大——前者讓我們花極少的錢買到大量資產(chǎn)後者讓我們能取出超過餘額的資金。而對於合約開發(fā)者而言則可以借助 SafeMath 庫來防禦SafeMath 中的add、sub、mul等函數(shù)在運算發(fā)生溢位時會主動觸發(fā)revert回滾整筆交易從而使溢位不可利用。實戰(zhàn)案例一Token sale 的乘法溢位Capture The Ether原題以 Capture The Ether 的 Token sale 挑戰(zhàn)為例其合約源碼如下pragma solidity ^0.4.21; contract TokenSaleChallenge { mapping(address uint256) public balanceOf; uint256 constant PRICE_PER_TOKEN 1 ether; function TokenSaleChallenge(address _player) public payable { require(msg.value 1 ether); } function isComplete() public view returns (bool) { return address(this).balance 1 ether; } function buy(uint256 numTokens) public payable { require(msg.value numTokens * PRICE_PER_TOKEN); balanceOf[msg.sender] numTokens; } function sell(uint256 numTokens) public { require(balanceOf[msg.sender] numTokens); balanceOf[msg.sender] - numTokens; msg.sender.transfer(numTokens * PRICE_PER_TOKEN); } }題目邏輯清晰合約部署時要求打入 1 ether構造函數(shù)中的require(msg.value 1 ether)isComplete的判斷條件是address(this).balance 1 ether即把合約裡的錢抽到不足 1 ether即可通關。溢位計算推導購買單個代幣需要支付 1 ether即require(msg.value numTokens * PRICE_PER_TOKEN)。在 EVM 中貨幣以 wei 為最小單位1 ether 實際上是 $10^{18}$ wei即十六進制的0xde0b6b3a7640000wei。若讓這裡的numTokens取得足夠大numTokens * PRICE_PER_TOKEN這一乘法就可能發(fā)生 256 位回繞。令numTokens 2^256 // 10^18 1//表示整數(shù)除法則有numTokens * 10^18 (2^256 // 10^18 1) * 10^18 2^256 (10^18 - 2^256 mod 10^18)該值超過了uint256的最大值 $2^{256}-1$EVM 對其取模後實際得到(2^256 // 10^18 1) * 10^18 mod 2^256 415992086870360064 wei ≈ 0.416 ether也就是說攻擊者只需支付約0.4 ether就能買到數(shù)量近乎天文數(shù)字的代幣餘額記錄在balanceOf[msg.sender]中。由於balanceOf也由uint256保存這筆巨額代幣可以正常參與後續(xù)的sell操作。接下來只需將買到的代幣部分賣出合約餘額便會低於 1 ether滿足isComplete條件。值得一提的是0.4 ether的數(shù)值與部署時注入的 1 ether 之和約為 1.4 ether而賣出操作會按numTokens * PRICE_PER_TOKEN向合約索取資金合約只要沒有餘額不足的限制此處sell中僅檢查了balanceOf[msg.sender] numTokens攻擊者即可反覆賣出直至將合約掏空。攻擊復現(xiàn)要點復現(xiàn)該題目時可以結合 Ethereum Basics 中介紹的 Remix 或 web3.py / web3.js 工具鏈用 Remix 部署TokenSaleChallenge並傳入 1 ether計算numTokens 2^256 // 10^18 1以msg.value 0.416 ether左右調用buy(numTokens)調用sell賣出部分代幣直到address(this).balance 1 ether觸發(fā)isComplete()返回true。注意該題目基於^0.4.21編譯未啟用任何溢位檢查這是漏洞成立的版本前提。從 Solidity 0.8.0 開始編譯器會在語言層面默認插入溢位檢查遇到溢位直接revert同源代碼在新版本下將無法以相同方式利用。實戰(zhàn)案例二取款邏輯的下溢Underflow整數(shù)下溢的典型場景是減法操作。假設有一個合約實現(xiàn)了如下功能contract Bank { mapping(address uint256) public balanceOf; ... function withdraw(uint256 amount) public { require(balanceOf[msg.sender] - amount 0); balanceOf[msg.sender] - amount; msg.sender.send.value(amount)(); } }乍看之下似乎沒有問題——取款前先檢查了餘額減去金額不小於 0。但實際上require那一行的balanceOf[msg.sender] - amount的結果作為無符號整數(shù)uint256無論運算結果在數(shù)學上為多少最終值永遠是大於等於 0 的。原因正是本節(jié)開頭所述的靜默取模當amount balanceOf[msg.sender]時balanceOf[msg.sender] - amount會回繞為一個接近 $2^{256}$ 的巨大正數(shù)永遠滿足 0的檢查導致攻擊者可以任意取款甚至把餘額扣成一個巨大的數(shù)字。正確的寫法應該是先比較、後運算require(balanceOf[msg.sender] amount); balanceOf[msg.sender] - amount;這裡的對比正好呼應了 以太坊存儲佈局 一章中的要點balanceOf這類映射的值最終以 32 字節(jié)256 位的形式存放在特定插槽slot中負數(shù)在存儲層面上就是0xffff...ffff這樣的全 1 大數(shù)讀出來便是巨大正數(shù)而web3.eth.getStorageAt()可以隨時讀取這些狀態(tài)。與重入攻擊的關聯(lián)下溢的另一種形態(tài)整數(shù)下溢的另一個重要例子與重入攻擊Re-Entrancy密切相關。經(jīng)典的重入攻擊流程是先給錢後記賬在 Re-Entrancy 一章的Bank.withdraw實現(xiàn)中合約先執(zhí)行msg.sender.call.value(amount)()轉賬再執(zhí)行balanceOf[msg.sender] - amount扣賬。由於轉賬時收款合約的 fallback 函數(shù)會被調用攻擊合約可以在 fallback 中再次調用withdraw此時餘額尚未扣減檢查條件依然滿足於是可以反覆取款。這就產(chǎn)生了兩種典型的利用結果將持有數(shù)為 1 的物品賣出兩次將 1 ether 的存款取出兩次。每一次透支都會讓balanceOf[msg.sender]在數(shù)學上變成負數(shù)而由於uint256的存儲特性負數(shù)實際上保存為一個極大的正數(shù)下溢回繞攻擊合約後續(xù)可以繼續(xù)使用這個大數(shù)額的存款形成取之不盡的資金來源。因此在 CTF 中絕大部分重入攻擊題目都涉及到向下溢位兩類漏洞常常組合出現(xiàn)重入提供了反覆觸發(fā)的攻擊路徑下溢則提供了餘額被扣成巨數(shù)的狀態(tài)後果。兩者還有共同的防禦要點先檢查、後生效Checks-Effects-Interactions先更新狀態(tài)扣減餘額再進行外部調用可同時堵住重入與下溢導致的錯誤狀態(tài)限制外部調用的 gas使用transfer/send僅提供 2300 gas替代call可削弱重入的執(zhí)行能力詳見 Re-Entrancy 章節(jié)中的注意點說明。溢位的相關攻擊面與防禦總結容易出現(xiàn)溢位的操作乘法MUL如 Token sale 中numTokens * PRICE_PER_TOKEN以及各種amount * rate形式的定價計算加法ADD如balanceOf[msg.sender] numTokens累加型餘額易發(fā)生上溢減法SUB如balanceOf[msg.sender] - amount扣減型餘額易發(fā)生下溢。此外以太坊存儲佈局 storage.md 中提到的任意寫如 uninitialized-storage-pointer與 short address 攻擊 等漏洞也常與算術回繞共同作用構造出組合利用鏈感興趣的讀者可以在 attacks 目錄 中進一步閱讀。防禦手段SafeMath 庫對add、sub、mul等運算封裝檢查發(fā)生溢位時revert回滾整筆交易使漏洞不可利用。這是原文檔明確推薦的經(jīng)典方案Solidity 0.8.0 內建檢查新版本編譯器默認啟用算術溢出檢查可通過unchecked區(qū)塊顯式關閉從語言層面根除靜默回繞先檢查後運算如require(balanceOf[msg.sender] amount)寫在減法之前Checks-Effects-Interactions 模式先更新內部狀態(tài)再做外部調用兼顧重入與下溢兩類風險注意適用前提SafeMath 與 0.8.0 的內建檢查都依賴於運算發(fā)生時的revert能力若合約使用低版本編譯器如^0.4.x必須手動引入檢查邏輯。賽題指引絕大部分重入攻擊題目都涉及向下溢位可參照 重入攻擊 部分。不涉及重入攻擊的溢位題目相對較少可以參考以下題目ByteCTF 2019題目名稱hf題目名稱bet!!! note 注題目附件相關內容可至 ctf-wiki 的 ctf-challenges/blockchain 倉庫尋找位於 ctf-wiki 組織下的附屬挑戰(zhàn)倉庫用於存放歷屆 CTF 題目附件與合約源碼。贊分享文檔網(wǎng)絡安全教程【免費下載鏈接】ctf-wikiCome and join us, we need you!項目地址https://gitcode.com/gh_mirrors/ct/ctf-wiki點擊查看免費下載相關推薦A2UI Express 格式優(yōu)化實錄run_020 數(shù)據(jù)路徑斜杠預處理如何讓評測通過率穩(wěn)定在 100%A2UI Express 格式優(yōu)化實錄run_020 數(shù)據(jù)路徑斜杠預處理如何讓評測通過率穩(wěn)定在 100% 本篇以 A2UI 倉庫中一次完整的迭代優(yōu)化報告 ev文檔網(wǎng)絡安全教程ctf-wiki 以太坊智能合約重入攻擊Re-Entrancy完全解析從 The DAO 硬分叉到 CTF 實戰(zhàn)ctf wiki 以太坊智能合約重入攻擊Re Entrancy完全解析從 The DAO 硬分叉到 CTF 實戰(zhàn) 導讀 本文以 ctf wiki 中 重入文檔網(wǎng)絡安全教程ctf-wiki 橢圓曲線加密ECC從入門到實戰(zhàn)離散對數(shù)基礎、ElGamal 方案與 SECCON CTF 破解ctf wiki 橢圓曲線加密ECC從入門到實戰(zhàn)離散對數(shù)基礎、ElGamal 方案與 SECCON CTF 破解 本篇技術指南以 ctf wiki 的 e文檔網(wǎng)絡安全教程上一篇如何在AMD MI300X上部署DeepSeek-R1SGLang優(yōu)化指南下一篇Ultimate Hacking Keyboard Agent開發(fā)指南從USB通信到I2C設備調試創(chuàng)作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考 CTF Wiki 智能合約安全實戰(zhàn)：深入解析 EVM 整數(shù)溢位與下溢（Integer Overflow and Underflow）
文檔網(wǎng)絡安全教程【免費下載鏈接】ctf-wikiCome and join us, we need you!項目地址https://gitcode.com/gh_mirrors/ct/ctf-wiki點擊查看免費下載本篇技術指南以 ctf-wiki 區(qū)塊鏈章節(jié)為核心系統(tǒng)講解以太坊虛擬機EVM中整數(shù)溢位Overflow與下溢Underflow漏洞的成因、利用手法與防禦方案。通過對 Capture The Ether 的 Token sale 經(jīng)典題目的完整推導、一個錯誤的取款合約示例以及與重入攻擊的關聯(lián)分析讀者將掌握如何在 CTF 比賽中識別、計算並利用整數(shù)回繞漏洞同時了解 SafeMath 等緩解措施的底層原理與適用前提。原理EVM 整數(shù)的位寬與靜默取模以太坊虛擬機中所有整數(shù)計算都發(fā)生在 256 位字word的基礎上。Solidity 為開發(fā)者提供了兩類整數(shù)類型int有符號整數(shù)uint無符號整數(shù)。在int或uint之後可以跟隨一個 8 的倍數(shù)用來表示該整數(shù)的位數(shù)例如 8 位的uint8、16 位的uint16。位數(shù)上限為 256 位因此int和uint本質上分別是int256和uint256的別名在實際的智能合約代碼中uint的使用更為常見。關鍵的漏洞機制在於當整數(shù)計算的結果超出其位數(shù)所能表示的上限或下限時EVM 不會拋出錯誤而是靜默地對結果進行取模wrap around操作。這與傳統(tǒng)語言如 C/C中無符號整數(shù)的溢出行為一致但對於依賴餘額計算的智能合約而言後果可能是災難性的。從 EVM 指令層面看算術運算對應的 opcode如ADD、MUL、SUB本身不攜帶任何溢位檢測結果直接以 256 位截斷後返回。相關指令的語義可以參考 Ethereum Opcodes 一章操作碼助記符棧輸入棧輸出表達式01ADD| a | b || a b |a b02MUL| a | b || a * b |a * b03SUB| a | b || a - b |a - b從攻擊者的視角看我們通常希望費用向上溢出變得極小或者存款向下溢出變得極大——前者讓我們花極少的錢買到大量資產(chǎn)後者讓我們能取出超過餘額的資金。而對於合約開發(fā)者而言則可以借助 SafeMath 庫來防禦SafeMath 中的add、sub、mul等函數(shù)在運算發(fā)生溢位時會主動觸發(fā)revert回滾整筆交易從而使溢位不可利用。實戰(zhàn)案例一Token sale 的乘法溢位Capture The Ether原題以 Capture The Ether 的 Token sale 挑戰(zhàn)為例其合約源碼如下pragma solidity ^0.4.21; contract TokenSaleChallenge { mapping(address uint256) public balanceOf; uint256 constant PRICE_PER_TOKEN 1 ether; function TokenSaleChallenge(address _player) public payable { require(msg.value 1 ether); } function isComplete() public view returns (bool) { return address(this).balance 1 ether; } function buy(uint256 numTokens) public payable { require(msg.value numTokens * PRICE_PER_TOKEN); balanceOf[msg.sender] numTokens; } function sell(uint256 numTokens) public { require(balanceOf[msg.sender] numTokens); balanceOf[msg.sender] - numTokens; msg.sender.transfer(numTokens * PRICE_PER_TOKEN); } }題目邏輯清晰合約部署時要求打入 1 ether構造函數(shù)中的require(msg.value 1 ether)isComplete的判斷條件是address(this).balance 1 ether即把合約裡的錢抽到不足 1 ether即可通關。溢位計算推導購買單個代幣需要支付 1 ether即require(msg.value numTokens * PRICE_PER_TOKEN)。在 EVM 中貨幣以 wei 為最小單位1 ether 實際上是 $10^{18}$ wei即十六進制的0xde0b6b3a7640000wei。若讓這裡的numTokens取得足夠大numTokens * PRICE_PER_TOKEN這一乘法就可能發(fā)生 256 位回繞。令numTokens 2^256 // 10^18 1//表示整數(shù)除法則有numTokens * 10^18 (2^256 // 10^18 1) * 10^18 2^256 (10^18 - 2^256 mod 10^18)該值超過了uint256的最大值 $2^{256}-1$EVM 對其取模後實際得到(2^256 // 10^18 1) * 10^18 mod 2^256 415992086870360064 wei ≈ 0.416 ether也就是說攻擊者只需支付約0.4 ether就能買到數(shù)量近乎天文數(shù)字的代幣餘額記錄在balanceOf[msg.sender]中。由於balanceOf也由uint256保存這筆巨額代幣可以正常參與後續(xù)的sell操作。接下來只需將買到的代幣部分賣出合約餘額便會低於 1 ether滿足isComplete條件。值得一提的是0.4 ether的數(shù)值與部署時注入的 1 ether 之和約為 1.4 ether而賣出操作會按numTokens * PRICE_PER_TOKEN向合約索取資金合約只要沒有餘額不足的限制此處sell中僅檢查了balanceOf[msg.sender] numTokens攻擊者即可反覆賣出直至將合約掏空。攻擊復現(xiàn)要點復現(xiàn)該題目時可以結合 Ethereum Basics 中介紹的 Remix 或 web3.py / web3.js 工具鏈用 Remix 部署TokenSaleChallenge並傳入 1 ether計算numTokens 2^256 // 10^18 1以msg.value 0.416 ether左右調用buy(numTokens)調用sell賣出部分代幣直到address(this).balance 1 ether觸發(fā)isComplete()返回true。注意該題目基於^0.4.21編譯未啟用任何溢位檢查這是漏洞成立的版本前提。從 Solidity 0.8.0 開始編譯器會在語言層面默認插入溢位檢查遇到溢位直接revert同源代碼在新版本下將無法以相同方式利用。實戰(zhàn)案例二取款邏輯的下溢Underflow整數(shù)下溢的典型場景是減法操作。假設有一個合約實現(xiàn)了如下功能contract Bank { mapping(address uint256) public balanceOf; ... function withdraw(uint256 amount) public { require(balanceOf[msg.sender] - amount 0); balanceOf[msg.sender] - amount; msg.sender.send.value(amount)(); } }乍看之下似乎沒有問題——取款前先檢查了餘額減去金額不小於 0。但實際上require那一行的balanceOf[msg.sender] - amount的結果作為無符號整數(shù)uint256無論運算結果在數(shù)學上為多少最終值永遠是大於等於 0 的。原因正是本節(jié)開頭所述的靜默取模當amount balanceOf[msg.sender]時balanceOf[msg.sender] - amount會回繞為一個接近 $2^{256}$ 的巨大正數(shù)永遠滿足 0的檢查導致攻擊者可以任意取款甚至把餘額扣成一個巨大的數(shù)字。正確的寫法應該是先比較、後運算require(balanceOf[msg.sender] amount); balanceOf[msg.sender] - amount;這裡的對比正好呼應了 以太坊存儲佈局 一章中的要點balanceOf這類映射的值最終以 32 字節(jié)256 位的形式存放在特定插槽slot中負數(shù)在存儲層面上就是0xffff...ffff這樣的全 1 大數(shù)讀出來便是巨大正數(shù)而web3.eth.getStorageAt()可以隨時讀取這些狀態(tài)。與重入攻擊的關聯(lián)下溢的另一種形態(tài)整數(shù)下溢的另一個重要例子與重入攻擊Re-Entrancy密切相關。經(jīng)典的重入攻擊流程是先給錢後記賬在 Re-Entrancy 一章的Bank.withdraw實現(xiàn)中合約先執(zhí)行msg.sender.call.value(amount)()轉賬再執(zhí)行balanceOf[msg.sender] - amount扣賬。由於轉賬時收款合約的 fallback 函數(shù)會被調用攻擊合約可以在 fallback 中再次調用withdraw此時餘額尚未扣減檢查條件依然滿足於是可以反覆取款。這就產(chǎn)生了兩種典型的利用結果將持有數(shù)為 1 的物品賣出兩次將 1 ether 的存款取出兩次。每一次透支都會讓balanceOf[msg.sender]在數(shù)學上變成負數(shù)而由於uint256的存儲特性負數(shù)實際上保存為一個極大的正數(shù)下溢回繞攻擊合約後續(xù)可以繼續(xù)使用這個大數(shù)額的存款形成取之不盡的資金來源。因此在 CTF 中絕大部分重入攻擊題目都涉及到向下溢位兩類漏洞常常組合出現(xiàn)重入提供了反覆觸發(fā)的攻擊路徑下溢則提供了餘額被扣成巨數(shù)的狀態(tài)後果。兩者還有共同的防禦要點先檢查、後生效Checks-Effects-Interactions先更新狀態(tài)扣減餘額再進行外部調用可同時堵住重入與下溢導致的錯誤狀態(tài)限制外部調用的 gas使用transfer/send僅提供 2300 gas替代call可削弱重入的執(zhí)行能力詳見 Re-Entrancy 章節(jié)中的注意點說明。溢位的相關攻擊面與防禦總結容易出現(xiàn)溢位的操作乘法MUL如 Token sale 中numTokens * PRICE_PER_TOKEN以及各種amount * rate形式的定價計算加法ADD如balanceOf[msg.sender] numTokens累加型餘額易發(fā)生上溢減法SUB如balanceOf[msg.sender] - amount扣減型餘額易發(fā)生下溢。此外以太坊存儲佈局 storage.md 中提到的任意寫如 uninitialized-storage-pointer與 short address 攻擊 等漏洞也常與算術回繞共同作用構造出組合利用鏈感興趣的讀者可以在 attacks 目錄 中進一步閱讀。防禦手段SafeMath 庫對add、sub、mul等運算封裝檢查發(fā)生溢位時revert回滾整筆交易使漏洞不可利用。這是原文檔明確推薦的經(jīng)典方案Solidity 0.8.0 內建檢查新版本編譯器默認啟用算術溢出檢查可通過unchecked區(qū)塊顯式關閉從語言層面根除靜默回繞先檢查後運算如require(balanceOf[msg.sender] amount)寫在減法之前Checks-Effects-Interactions 模式先更新內部狀態(tài)再做外部調用兼顧重入與下溢兩類風險注意適用前提SafeMath 與 0.8.0 的內建檢查都依賴於運算發(fā)生時的revert能力若合約使用低版本編譯器如^0.4.x必須手動引入檢查邏輯。賽題指引絕大部分重入攻擊題目都涉及向下溢位可參照 重入攻擊 部分。不涉及重入攻擊的溢位題目相對較少可以參考以下題目ByteCTF 2019題目名稱hf題目名稱bet!!! note 注題目附件相關內容可至 ctf-wiki 的 ctf-challenges/blockchain 倉庫尋找位於 ctf-wiki 組織下的附屬挑戰(zhàn)倉庫用於存放歷屆 CTF 題目附件與合約源碼。贊分享文檔網(wǎng)絡安全教程【免費下載鏈接】ctf-wikiCome and join us, we need you!項目地址https://gitcode.com/gh_mirrors/ct/ctf-wiki點擊查看免費下載相關推薦A2UI Express 格式優(yōu)化實錄run_020 數(shù)據(jù)路徑斜杠預處理如何讓評測通過率穩(wěn)定在 100%A2UI Express 格式優(yōu)化實錄run_020 數(shù)據(jù)路徑斜杠預處理如何讓評測通過率穩(wěn)定在 100% 本篇以 A2UI 倉庫中一次完整的迭代優(yōu)化報告 ev文檔網(wǎng)絡安全教程ctf-wiki 以太坊智能合約重入攻擊Re-Entrancy完全解析從 The DAO 硬分叉到 CTF 實戰(zhàn)ctf wiki 以太坊智能合約重入攻擊Re Entrancy完全解析從 The DAO 硬分叉到 CTF 實戰(zhàn) 導讀 本文以 ctf wiki 中 重入文檔網(wǎng)絡安全教程ctf-wiki 橢圓曲線加密ECC從入門到實戰(zhàn)離散對數(shù)基礎、ElGamal 方案與 SECCON CTF 破解ctf wiki 橢圓曲線加密ECC從入門到實戰(zhàn)離散對數(shù)基礎、ElGamal 方案與 SECCON CTF 破解 本篇技術指南以 ctf wiki 的 e文檔網(wǎng)絡安全教程上一篇如何在AMD MI300X上部署DeepSeek-R1SGLang優(yōu)化指南下一篇Ultimate Hacking Keyboard Agent開發(fā)指南從USB通信到I2C設備調試創(chuàng)作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考