聲明:本文來(lái)自于微信公眾號(hào) 新智元，作者:新智元，授權(quán)站長(zhǎng)之家轉(zhuǎn)載發(fā)布。

【新智元導(dǎo)讀】AI首次發(fā)現(xiàn)真實(shí)世界中的重大安全漏洞?SQLite中的一個(gè)漏洞，幸運(yùn)地被谷歌研究者的AI Agent發(fā)現(xiàn)了，修復(fù)后并未造成任何損失。莫非AI再進(jìn)化一番，微軟的全球藍(lán)屏事故就可以永久避免了?這個(gè)可能性令人激動(dòng)不已。

LLM居然在真實(shí)世界的代碼中，發(fā)現(xiàn)了一個(gè)漏洞?

想象一下，AI正在默默地守護(hù)著我們?nèi)粘Ｊ褂玫能浖?。忽然，它發(fā)現(xiàn)了一個(gè)你我可能從未察覺(jué)的安全隱患，并且悄無(wú)聲息地把它修復(fù)了!

就在剛剛，谷歌的Big Sleep項(xiàng)目揭示了一個(gè)驚人的成果:一個(gè)真實(shí)世界的安全漏洞，出現(xiàn)在全球廣泛使用的SQLite數(shù)據(jù)庫(kù)中，而這個(gè)漏洞竟然被AI成功識(shí)別出來(lái)了?在真實(shí)世界的危機(jī)擴(kuò)散之前，它及時(shí)挽回了局面。

隸屬于谷歌Project Zero和Google DeepMind的團(tuán)隊(duì)聲稱，這是AI Agent在廣泛使用的現(xiàn)實(shí)軟件中，發(fā)現(xiàn)未知可利用內(nèi)存安全問(wèn)題的第一個(gè)公開(kāi)示例。

要知道，這不僅僅是一個(gè)崩潰的測(cè)試用例，它是AI首次在真實(shí)世界的軟件中找到未知的、可利用的內(nèi)存漏洞。

此前，網(wǎng)絡(luò)安全巨頭CrowdStrike鬧出的一個(gè)由「C-00000291*.sys」配置文件觸發(fā)的系統(tǒng)邏輯錯(cuò)誤，瞬間就破壞掉全世界約10億臺(tái)計(jì)算機(jī)，直接導(dǎo)致微軟藍(lán)屏、全球停擺。

如果未來(lái)某一天，AI能幫我們解決所有技術(shù)領(lǐng)域的單點(diǎn)瞬時(shí)故障，不知會(huì)幫人類節(jié)省下多少財(cái)富?

用LLM在真實(shí)世界中「捉蟲(chóng)」

隨著LLM代碼理解和一般推理能力的提高，谷歌研究者一直在探索這些模型如何在識(shí)別和演示安全漏洞時(shí)，重新人類安全研究人員的方法。

在《Project Naptime:評(píng)估大型語(yǔ)言模型的攻防能力》中，Big Sleep團(tuán)隊(duì)介紹了一個(gè)利用LLM輔助的漏洞研究框架，并通過(guò)在Meta的CyberSecEval2基準(zhǔn)測(cè)試上提升了最新的性能，展示了這種方法的潛力。

從那時(shí)起，Naptime就變成「Big Sleep」，成為了Google Project Zero與Google DeepMind的合作項(xiàng)目。

就在剛剛，谷歌研究者激動(dòng)地表示，Big Sleep Agent發(fā)現(xiàn)了首個(gè)真實(shí)世界漏洞:一個(gè)存在于SQLite中的可利用棧緩沖區(qū)下溢漏洞。

SQLite是一款被廣泛使用的開(kāi)源數(shù)據(jù)庫(kù)引擎。

在十月初，Agent發(fā)現(xiàn)了了這個(gè)漏洞，于是谷歌研究者立刻將其報(bào)告給了開(kāi)發(fā)者，他們?cè)谕惶爝M(jìn)行了修復(fù)。

幸運(yùn)的是，AI在這個(gè)問(wèn)題出現(xiàn)在官方發(fā)布版本之前，就發(fā)現(xiàn)了它，因此SQLite的用戶未受影響。

要知道，SQLite作為輕量級(jí)嵌入式數(shù)據(jù)庫(kù)，廣泛應(yīng)用于智能手機(jī)、瀏覽器、嵌入式系統(tǒng)、IoT設(shè)備等多種環(huán)境，涵蓋了許多用戶和敏感信息。

如果攻擊者利用該漏洞進(jìn)行數(shù)據(jù)泄露、系統(tǒng)入侵或破壞，潛在損失金額可能少則幾百萬(wàn)，多則數(shù)十億美元!

谷歌研究者表示，這是AI Agent首次在廣泛使用的真實(shí)世界軟件中發(fā)現(xiàn)未知的、可利用的內(nèi)存安全問(wèn)題的公開(kāi)案例。

之所以會(huì)有這次嘗試，是因?yàn)榻衲暝缧r(shí)候，在DARPA的AIxCC活動(dòng)中，亞特蘭大團(tuán)隊(duì)在SQLite中發(fā)現(xiàn)了一個(gè)空指針取消引用的漏洞，這就給了谷歌研究者啟發(fā)——

是否可以使用SQLite進(jìn)行測(cè)試，看看能否找到更嚴(yán)重的漏洞呢?

果然，AI Agent真的找出了一個(gè)漏洞。

這項(xiàng)工作，無(wú)疑具有巨大的潛力。

在軟件尚未發(fā)布前就發(fā)現(xiàn)漏洞，就意味著攻擊者沒(méi)有機(jī)會(huì)利用:漏洞在他們有機(jī)會(huì)使用之前，就已被修復(fù)。

雖然模糊測(cè)試也能帶來(lái)顯著的幫助，但我們更需要的是一種方法，幫助防御者找到那些很難通過(guò)模糊測(cè)試發(fā)現(xiàn)的漏洞。

現(xiàn)在，AI有望縮小這一差距!

谷歌研究者表示，這是一條有希望的道路，能為防御者帶來(lái)不對(duì)稱的優(yōu)勢(shì)。

因?yàn)檫@個(gè)漏洞相當(dāng)有趣，而且SQLite的現(xiàn)有測(cè)試基礎(chǔ)設(shè)施（包括OSS-Fuzz和項(xiàng)目自身的測(cè)試）并沒(méi)有發(fā)現(xiàn)它，因此谷歌研究者進(jìn)行了深入調(diào)查。

方法架構(gòu)

Naptime和Big Sleep項(xiàng)目的關(guān)鍵驅(qū)動(dòng)因素，就是已經(jīng)發(fā)現(xiàn)并修補(bǔ)的漏洞變種，仍在現(xiàn)實(shí)中不斷被發(fā)現(xiàn)。

顯而易見(jiàn)，fuzzing（模糊測(cè)試）并不能成功捕獲此類變種漏洞，而對(duì)攻擊者而言，手動(dòng)變種分析的方法仍然性價(jià)比很高。

谷歌研究者認(rèn)為，相比更為寬泛的開(kāi)放式漏洞研究問(wèn)題，這種變種分析任務(wù)更適合當(dāng)前的LLM。

通過(guò)提供一個(gè)具體的起點(diǎn)——比如此前修復(fù)的漏洞的詳細(xì)信息——我們就可以降低漏洞研究中的不確定性， 并且還能從一個(gè)明確的、有理論支撐的假設(shè)出發(fā):「這里曾經(jīng)存在一個(gè)漏洞，很可能在某處還存在類似的問(wèn)題」。

目前，他們的項(xiàng)目仍處于研究階段，正在使用帶有已知漏洞的小型程序來(lái)評(píng)估研究進(jìn)展。

最近，他們決定通過(guò)在SQLite上開(kāi)展首次大規(guī)模的真實(shí)環(huán)境變種分析實(shí)驗(yàn)，來(lái)測(cè)試他們的模型和工具鏈。

他們收集了SQLite repository近期的一系列提交，手動(dòng)篩除了無(wú)關(guān)緊要的改動(dòng)和純文檔更新。

隨后，他們調(diào)整了prompt，為AI Agent同時(shí)提供了提交信息和代碼變更，并要求它審查當(dāng)前代碼庫(kù)（在HEAD位置）中可能仍未修復(fù)的相關(guān)問(wèn)題。

Project Naptime

Naptime采用了一種專門(mén)的架構(gòu)來(lái)增強(qiáng)大語(yǔ)言模型進(jìn)行漏洞研究的能力，其核心是AI Agent與目標(biāo)代碼庫(kù)之間的交互。

系統(tǒng)架構(gòu)

為了讓AI Agent可以模仿人類安全研究員的工作流程，研究團(tuán)隊(duì)開(kāi)發(fā)了一系列專用的工具:

• 代碼瀏覽工具（Code Browser）使AI Agent能夠?yàn)g覽目標(biāo)代碼庫(kù)，這與工程師使用Chromium Code Search的方式類似。它提供了查看特定實(shí)體(如函數(shù)、變量等)源代碼的功能，并能識(shí)別函數(shù)或?qū)嶓w被引用的位置。

• Python工具讓AI Agent能夠在隔離的沙盒（Sandbox）環(huán)境中運(yùn)行Python腳本，用于執(zhí)行中間計(jì)算并生成精確而復(fù)雜的目標(biāo)程序輸入。

• 調(diào)試器工具（Debugger）為AI Agent提供了程序交互能力，可以觀察程序在不同輸入下的行為表現(xiàn)。它支持?jǐn)帱c(diǎn)設(shè)置并能在斷點(diǎn)處評(píng)估表達(dá)式，從而實(shí)現(xiàn)動(dòng)態(tài)分析。

• 報(bào)告工具（Reporter）為AI Agent提供了一個(gè)結(jié)構(gòu)化的進(jìn)度通報(bào)機(jī)制。AI Agent可以發(fā)送任務(wù)完成信號(hào)，觸發(fā)控制器驗(yàn)證是否達(dá)成成功條件(通常表現(xiàn)為程序崩潰)。當(dāng)無(wú)法取得進(jìn)一步進(jìn)展時(shí)，它還允許AI Agent主動(dòng)中止任務(wù)，避免陷入停滯狀態(tài)。

發(fā)現(xiàn)漏洞

這個(gè)漏洞非常有趣，比如在一個(gè)通常為索引類型的字段iColumn中，使用了一個(gè)特殊的哨兵值-1:

7476:structsqlite3_index_constraint{7477:intiColumn;/*Columnconstrained.-1forROWID*/7478:unsignedcharop;/*Constraintoperator*/7479:unsignedcharusable;/*Trueifthisconstraintisusable*/7480:intiTermOffset;/*Usedinternally-xBestIndexshouldignore*/7481:}*aConstraint;/*TableofWHEREclauseconstraints*/

這種模式產(chǎn)生了一個(gè)邊緣案例，所有使用該字段的代碼都需要正確處理這種情況，因?yàn)榘凑粘Ｒ?guī)預(yù)期，有效的列索引值應(yīng)該是非負(fù)的。

seriesBestIndex函數(shù)在處理這個(gè)edge case時(shí)存在缺陷，當(dāng)處理包含rowid列約束的查詢時(shí)，導(dǎo)致寫(xiě)入了帶有負(fù)索引的堆棧緩沖區(qū)。

在研究者提供給AI Agent的編譯版本中，debug assertion功能已啟用，這種異常情況會(huì)被第706行的斷言檢查所捕獲:

619staticintseriesBestIndex（620sqlite3_vtab*pVTab，621sqlite3_index_info*pIdxInfo622）{...630intaIdx[7];/*Constraintsonstart，stop，step，LIMIT，OFFSET，631**andvalue.aIdx[5]coversvalue=，value>=，and632**value>，aIdx[6]coversvalue<=andvalue<*/633conststructsqlite3_index_constraint*pConstraint;...642for(i=0;i<pIdxInfo->nConstraint;i++，pConstraint++){643intiCol;/*0forstart，1forstop，2forstep*/644intiMask;/*bitmaskforthosecolumn*/645intop=pConstraint->op;...705iCol=pConstraint->iColumn-SERIES_COLUMN_START;706assert(iCol>=0&&iCol<=2);707iMask=1<<iCol;...713if(pConstraint->usable==0){714unusableMask|=iMask;715continue;716}elseif(op==SQLITE_INDEX_CONSTRAINT_EQ){717idxNum|=iMask;718aIdx[iCol]=i;719}720}

然而，在發(fā)布版本中，這個(gè)斷言檢查并不存在。

在研究者的測(cè)試環(huán)境中（具體表現(xiàn)會(huì)因編譯器和優(yōu)化級(jí)別而異），第718行的后續(xù)寫(xiě)入操作會(huì)越界寫(xiě)入aIdx緩沖區(qū)下方的內(nèi)存區(qū)域，導(dǎo)致pConstraint指針的最低有效32位被破壞。

當(dāng)這個(gè)被破壞的指針在循環(huán)的下一次迭代中被取消引用時(shí)，就會(huì)產(chǎn)生潛在的可利用漏洞條件。

不過(guò)，即使有了這樣的漏洞說(shuō)明，對(duì)于人類研究員來(lái)說(shuō)，要精確理解如何觸發(fā)這個(gè)漏洞仍然不易。

雖然針對(duì)ROWID列設(shè)置約束顯然是個(gè)不錯(cuò)的切入點(diǎn)，但要完全理解，還需要深入研讀代碼。

而 AI 智能體似乎已經(jīng)掌握了比人類研究員更多的SQLite相關(guān)知識(shí)，這使它能夠更高效地定位問(wèn)題!

這種情況的一個(gè)典型例子，就是LLM在生成測(cè)試用例時(shí)會(huì)直接使用generate_series虛擬表。

（雖然研究者也觀察到模型會(huì)先研究可用的虛擬表的情況，但很明顯，它能夠在這里直接運(yùn)用已有的知識(shí)）。

執(zhí)行過(guò)程重點(diǎn)分析

在這次基于Gemini1.5Pro的成功測(cè)試中，seed commit為 [1976c3f7]，這是一個(gè)規(guī)模較大、復(fù)雜的代碼變更。

而研究者的AI Agent發(fā)現(xiàn)的漏洞，與該seed commit中的變更僅存在松散關(guān)聯(lián)——這種情況在手動(dòng)變種分析中較為常見(jiàn)，因?yàn)樵诶斫獯a庫(kù)中的某個(gè)漏洞時(shí)，研究人員往往會(huì)由此發(fā)現(xiàn)其他潛在問(wèn)題。

以下是關(guān)鍵節(jié)點(diǎn)摘要，其中，所有ASSISTANT塊中的內(nèi)容均直接來(lái)自AI Agent。

AI Agent對(duì)差異中的變化進(jìn)行了合理的評(píng)估，并以此作為研究的切入點(diǎn):

ASSISTANT

通過(guò)引入termFromWhereClause函數(shù)，CL改進(jìn)了在虛擬表查詢中處理OR分支共享的WHERE條件的方式。該函數(shù)在考慮嵌套子句的情況下，從WhereClause中檢索特定的條件。

在此更改之前，由于條件索引映射不正確，共享的條件可能未被正確處理，可能導(dǎo)致低效的查詢計(jì)劃或錯(cuò)誤的結(jié)果。

最可能出現(xiàn)的問(wèn)題涉及在allocateIndexInfo和whereLoopAddVirtualOne函數(shù)中不正確地處理WHERE子句約束，其中 CL 修改了如何使用新的輔助函數(shù)來(lái)處理約束偏移量。

我將首先檢查allocateIndexInfo函數(shù)。

在經(jīng)過(guò)數(shù)個(gè)步驟探索相關(guān)代碼后，AI Agent形成了一個(gè)更明確的測(cè)試假設(shè)——它試圖通過(guò)運(yùn)行patch中測(cè)試用例的修改版本來(lái)驗(yàn)證這個(gè)假設(shè)，但未能成功。

原因在于patch中的測(cè)試用例依賴于一個(gè)在當(dāng)前配置環(huán)境中未啟用的擴(kuò)展模塊:

TOOL（debugger_run ）

程序在未崩潰或命中斷點(diǎn)的情況下退出。退出代碼為1。

STDERR輸出為:

Runtime error near line2: no such module: tcl

Parse error near line3: no such table: x1

ASSISTANT

程序終止是因?yàn)門(mén)CL模塊不可用。測(cè)試依賴于TCL虛擬表模塊，需要在編譯SQLite時(shí)啟用該模塊。提供的程序的輸入基于bestindexC.test文件，它使用TCL模塊來(lái)測(cè)試虛擬表的最佳索引選擇。

為了解決這個(gè)問(wèn)題，需要更改程序輸入，使用不需要TCL模塊的其他虛擬表。然而，該漏洞與虛擬表的查詢計(jì)劃有關(guān)，所以我們?nèi)匀恍枰粋€(gè)虛擬表來(lái)觸發(fā)此問(wèn)題。

我將使用code_browser_source工具來(lái)檢索SQLite中的內(nèi)置虛擬表示例。然后，我將調(diào)整輸入，使用其中一個(gè)虛擬表，并重新在whereLoopAddVirtualOne中設(shè)置斷點(diǎn)。

AI Agent很好地應(yīng)對(duì)了這個(gè)問(wèn)題，準(zhǔn)確識(shí)別出了修復(fù)測(cè)試用例所需的各個(gè)步驟，并在后續(xù)幾個(gè)步驟中成功收集到了所有構(gòu)建測(cè)試用例所需的信息，最終實(shí)現(xiàn)了觸達(dá)whereLoopAddVirtualOne的目標(biāo):

ASSISTANT

sqlite3_create_module函數(shù)用于注冊(cè)虛擬表模塊。shell.c文件包含了多個(gè)這樣的實(shí)例，包括generate_series、fsdir、completion和expert模塊。其中json表的實(shí)現(xiàn)也很值得關(guān)注。

我首先關(guān)注的是generate_series，然后構(gòu)造出一個(gè)使用該模塊的查詢，從而觸發(fā)錯(cuò)誤的約束處理。

需要注意的是，在最初發(fā)現(xiàn)和復(fù)現(xiàn)該漏洞時(shí)，AI Agent對(duì)于它試圖觸發(fā)的「不正確約束處理」的描述相當(dāng)模糊。

在這種情況下，完整的執(zhí)行軌跡讀起來(lái)頗似人類研究員的思維過(guò)程——從一個(gè)想法開(kāi)始，在調(diào)查過(guò)程中產(chǎn)生其他幾個(gè)想法，最終生成了一個(gè)可以復(fù)現(xiàn)略有不同漏洞的測(cè)試用例。

在本例中，當(dāng)whereLoopAddVirtualOne在generate_series表上被調(diào)用時(shí)，執(zhí)行流程最終會(huì)進(jìn)入seriesBestIndex，在那里約束確實(shí)被錯(cuò)誤處理了。

特別有趣的是，一旦程序崩潰，模型會(huì)在解釋問(wèn)題時(shí)表現(xiàn)得更為出色——在生成根因分析（root-cause analysis）和完整崩潰報(bào)告時(shí)，我們可以看到AI Agent清晰地構(gòu)造了一個(gè)測(cè)試用例來(lái)觸發(fā)特定的已識(shí)別邊緣案例:

ASSISTANT

相關(guān)的字段是sqlite3_index_constraint結(jié)構(gòu)體中的iColumn。該字段表示約束的列編號(hào)。要導(dǎo)致斷言失敗，我們需要對(duì)索引大于3或小于-1的列設(shè)置約束。

讓我們構(gòu)建一個(gè)涉及這些列約束的SQL查詢。generate_series表有名為value、start、step和stop的列。它們的索引是:

- value:0

- start:1

- step:2

- stop:3

要觸發(fā)此漏洞，我們可以對(duì)ROWID施加一個(gè)約束，并對(duì)ROWID的約束使用iColumn = -1。

示例查詢?nèi)缦?

SELECT * FROM generate_series（1，10，1） WHERE ROWID =1;

該查詢將導(dǎo)致seriesBestIndex函數(shù)崩潰。

最終，得到了一個(gè)清晰準(zhǔn)確的問(wèn)題總結(jié)，幾乎可以直接用于漏洞報(bào)告!

TOOL（debugger_run）

程序崩潰:SIGABRT at :0

STDERR輸出為:

sqlite3: src/shell.c:6816: int seriesBestIndex（sqlite3_vtab *， sqlite3_index_info *）: Assertion `iCol>=0&& iCol<=2' failed.

ASSISTANT（report_success）

程序在執(zhí)行SELECT * FROM generate_series（1，10，1） WHERE ROWID =1;時(shí)因seriesBestIndex函數(shù)中的斷言失敗而崩潰。

斷言assert（iCol>=0&& iCol<=2）失敗的原因是sqlite3_index_info結(jié)構(gòu)體中的iColumn字段可能包含超出列索引有效范圍的值，例如在約束涉及ROWID時(shí)為-1。

這導(dǎo)致iCol被計(jì)算為-2，從而導(dǎo)致斷言失敗。

關(guān)于模糊測(cè)試

一個(gè)顯而易見(jiàn)的問(wèn)題是:為什么傳統(tǒng)的模糊測(cè)試沒(méi)有更早發(fā)現(xiàn)這個(gè)漏洞?

答案就在模糊測(cè)試工具鏈的配置上。

OSS-Fuzz使用的工具并沒(méi)有啟用generate_series擴(kuò)展，而替代的fuzzingshell.c工具包含的是舊版本的seriesBestIndex函數(shù)，未受此漏洞影響。

雖然SQLite AFL倉(cāng)庫(kù)中包含一個(gè)針對(duì)研究者提供給Big Sleep智能體的、相同CLI二進(jìn)制文件的模糊測(cè)試配置，但似乎并未被廣泛使用。

這個(gè)漏洞是否真的容易發(fā)現(xiàn)?

為此，研究者嘗試通過(guò)模糊測(cè)試重新發(fā)現(xiàn)它。

他們遵循SQLite文檔中的模糊測(cè)試說(shuō)明，并使用CLI目標(biāo)。在啟動(dòng)AFL運(yùn)行之前，他們還驗(yàn)證了模糊測(cè)試語(yǔ)料庫(kù)中包含所需的generate_series和rowid關(guān)鍵字。

然而，經(jīng)過(guò)150個(gè)CPU小時(shí)的模糊測(cè)試，問(wèn)題仍未被發(fā)現(xiàn)。

隨后，他們嘗試通過(guò)將必要的關(guān)鍵字添加到AFL的SQL字典中，來(lái)簡(jiǎn)化模糊測(cè)試的任務(wù)。

然而，似乎只有當(dāng)語(yǔ)料庫(kù)包含與導(dǎo)致崩潰的輸入非常接近的示例時(shí)，漏洞才能被快速發(fā)現(xiàn)，因?yàn)榇a覆蓋率對(duì)這個(gè)特定問(wèn)題并不是可靠的指標(biāo)。

誠(chéng)然，AFL并不是針對(duì)像SQL這種基于文本的格式最適合的工具，大多數(shù)輸入在語(yǔ)法上無(wú)效，會(huì)被解析器拒絕。

然而，如果將這一結(jié)果與Michal Zalewski在2015年關(guān)于模糊測(cè)試SQLite的博客文章進(jìn)行比較，會(huì)發(fā)現(xiàn)十分有趣的事。

那時(shí)，AFL在發(fā)現(xiàn)SQLite漏洞方面相當(dāng)有效;經(jīng)過(guò)多年的模糊測(cè)試，該工具似乎已經(jīng)達(dá)到自然的飽和點(diǎn)。

雖然研究者迄今為止的結(jié)果與AFL發(fā)布時(shí)帶來(lái)的顯著效果相比顯得微不足道，但它有自己的優(yōu)勢(shì)——有概率能夠有效地發(fā)現(xiàn)一組不同的漏洞。

結(jié)論

對(duì)于團(tuán)隊(duì)來(lái)說(shuō)，這個(gè)項(xiàng)目無(wú)疑成功了。

在廣泛使用且模糊化的開(kāi)源項(xiàng)目中找到漏洞，非常一個(gè)令人興奮!

這也就意味著:當(dāng)提供正確的工具時(shí)，當(dāng)前的LLMs可以進(jìn)行漏洞研究。

不過(guò)，研究者想重申，這些都是高度實(shí)驗(yàn)性的結(jié)果。

Big Sleep 團(tuán)隊(duì)表示:目前，在發(fā)現(xiàn)漏洞方面，針對(duì)特定目標(biāo)的模糊器可能至少同樣有效。

研究者希望，未來(lái)這項(xiàng)工作將為防御者帶來(lái)顯著優(yōu)勢(shì)——

不僅有可能找到導(dǎo)致崩潰的測(cè)試用例，還能提供高質(zhì)量的根本原因分析，使得問(wèn)題的分類和修復(fù)變得更便宜且更有效。

谷歌研究者表示，會(huì)繼續(xù)分享自己的研究成果，盡可能縮小公共技術(shù)前沿和私有技術(shù)前沿之間的差距。

Big Sleep團(tuán)隊(duì)也會(huì)將繼續(xù)努力，推進(jìn)零日計(jì)劃的使命，讓0-day變得更加困難。

團(tuán)隊(duì)介紹

Dan Zheng

團(tuán)隊(duì)中唯一的華人Dan Zheng是谷歌DeepMind的研究工程師，從事代碼和軟件工程的機(jī)器學(xué)習(xí)，以及編程語(yǔ)言的研究。

此前，他曾參與Swift for TensorFlow的工作，專注于Swift中的可微分編程。

他在普渡大學(xué)獲得了計(jì)算機(jī)科學(xué)專業(yè)的學(xué)士學(xué)位。畢業(yè)后，他做了多年的學(xué)生研究員，期間研究成果頗豐。

參考資料:

https://googleprojectzero.blogspot.com/2024/10/from-naptime-to-big-sleep.html

（舉報(bào)）