在本文開始之前，請留意這是一份十分冗雜的信息安詳告示。有關(guān)于Windows節(jié)制呼吁符，我大概發(fā)明白一個可以通過簡樸批處理懲罰文件舉辦進攻的BUG。這個BUG存在于Windows 2000版本以上的64位以及32位呆板上，它是一個批處理懲罰理會錯誤。它不需要特別安裝任何軟件（cmd.exe是Windows默認安裝的），它可以由任意權(quán)限的用戶提倡（假設(shè)他們可以運行cmd.exe，從而理會批處理懲罰文件）包羅理會錯誤產(chǎn)生的位置（妨礙代碼可以或許表明這個原因）。這并不是一個遠端節(jié)制條理的BUG，僅僅是一個DoS范例，需要獲得用戶請求才氣運行（可能是把其作為一個開機啟動項）。可是由于他的簡樸性，以及Windows系統(tǒng)的普及率，我小我私家認為它值得你看上那么一眼。

請留意，假如你啟用這些批處理懲罰文件導(dǎo)致系統(tǒng)瓦解我是不認真任的！任務(wù)打點器會竣事這個失控劇本的PID，以防備你運行。

Tldr：一個僅僅包容^ nul<^ 的批處理懲罰文件會造成一個龐大的內(nèi)存泄漏，在一個僅僅只有 ^|^  的批處理懲罰文件會使呼吁行無限遞歸導(dǎo)致瓦解。這些行為大概導(dǎo)致一些有趣的批處理懲罰編程，雖然我是指的在windows2K版本以上的操縱系統(tǒng)中，原因在于cmd.exe在處理懲罰批處理懲罰文件時產(chǎn)生的邏輯錯誤。

當(dāng)我再回覆一位用戶提出的問題時，我碰著一個十分有趣的批處理懲罰文件理會異常，假如^這個字符是文件的最后一個字符，就大概產(chǎn)生內(nèi)存泄漏，插入文件的最后一個字符不可以或許是 n （換行符），由于 r （回車符）在脫字標(biāo)記之前就已經(jīng)執(zhí)行，所以沒有這種環(huán)境產(chǎn)生，理會器可以或許正常事情，沒有什么可以追蹤到（當(dāng)插入^rt，理會卻成為了^r “t”就被忽略掉了）。最后留意一下，回車字符是可以或許正常執(zhí)行的，雖然這也是一個小趣點，我們可以在大大都文本編輯器中對回車字符造假，在記事本的最后你可以傻逼的認為哪里尚有一個回車符

顛末一系列的折騰，我發(fā)明^字符在文件的最后大概導(dǎo)致內(nèi)存泄漏，可能會致使呼吁提示符瓦解（詳細點說就是 command.com 可能cmd.exe措施），我還發(fā)明非凡的批處理懲罰文件（及其序列）會引起一些有趣的現(xiàn)象。進一步的觀測，引導(dǎo)我去存眷 是否其他人也有碰著過雷同的環(huán)境， a Stack Overflow question where a user noted a memory leak（在Stack Overflow提問中一個用戶暗示內(nèi)存泄漏）在SS64.com的主題 other interesting behaviors with the caret at the EOF（在文件最后加上回車符引起的有趣現(xiàn)象）。Stack Oveflow上面的提問輔佐我確認了這并不是一個無限輪回范例的環(huán)境，可是并沒有表明清楚到底是怎么一回事，在SS64.com的主題中大部門內(nèi)容都是在接頭從各個方面讓呼吁提示符瓦解，可是并沒有對道理舉辦表明。

自然的在我心中發(fā)生了疑問，到底是怎么產(chǎn)生的？怎么產(chǎn)生的呢？這個環(huán)境是否可以舉辦操作呢？謎底是巨大的，可是辦理要領(lǐng)確是很簡樸（至少看起來簡樸），我發(fā)明一些欺騙批處理懲罰文件組合，可以或許發(fā)生內(nèi)存泄漏。是快是慢取決與你放入的批處理懲罰文件是什么（不是插入了幾多字符，而是管道序列，以及行數(shù)長度）無論是呼吁提示符瓦解照舊內(nèi)存泄漏，理會代碼一直都是在單線程中駐留，所以CPU的占用量一直在增漲（單核CPU平均占用率到達98%）

讓呼吁提示符瓦解很簡樸，一個沒有換行的批處理懲罰文件只需要包容 ^&^ (可能 ^|^)就足以導(dǎo)致呼吁提示符呈現(xiàn)0xC00000FD錯誤 ，這是一個由于無限遞歸棧/幀呈現(xiàn)的泄漏。這重現(xiàn)了“無限輪回”的場景，但沒有完美表明內(nèi)存泄漏（可能說是為什么這個無限輪回會導(dǎo)致瓦解），工作到這個水平，我開始通過舉辦一些最簡樸的要領(lǐng)來發(fā)生一個內(nèi)存泄漏，事實證明，一個2字節(jié)的批處理懲罰文件是需要耗損整顆CPU以及吃內(nèi)存的（盡量速度慢的離譜，~8k/5s on a 2.2GHz i7）

我用來測試的批處理懲罰文件包括以下16進制字節(jié)

0x01 0x5E

0X5E 是脫字標(biāo)記(^) ，0X01是標(biāo)題開始的Ascll碼。第一個16進制代碼，在這個BUG中危險水平?jīng)]有其它的高，因為他不能是NULL（0X00），r, |, 可能 & 這些字符會導(dǎo)致批處理懲罰文件通過正常途徑退出（也就是 ‘invalid command detected’）。我利用0X01證實它沒有一個有效的呼吁（可能顯示出有關(guān)的字符）導(dǎo)致這個BUG，一個2字節(jié)的批處理懲罰文件包括一個簡樸的^就足夠了。

做一些其他測試，我發(fā)此刻批處理懲罰文件最后加上^ nul<^是最快也是最簡樸的耗損CPU的要領(lǐng)。

隨機的運行若干次后，請?zhí)岣吡粢猓@么做去耗損64位系統(tǒng)CPU是很快的。僅僅是花了20S，就吃掉了我14G的RAM（總共16GB，四核I7而且利用超線程技能），最后我不得不重啟電腦。在32位系統(tǒng)上運行這個快速版本，盡量32位系統(tǒng)有2GB的限制，呼吁理會器也會很快的因為內(nèi)存不敷而竣事任務(wù)。它不會導(dǎo)致呼吁提示符瓦解，相反的，它好像有一個檢測機制掩護內(nèi)存分派，當(dāng)它不可以或許直接終止批處理懲罰歷程時。