在本文開始之前，請留意這是一份十分冗雜的信息安詳告示。有關于Windows節制呼吁符，我大概發明白一個可以通過簡樸批處理懲罰文件舉辦進攻的BUG。這個BUG存在于Windows 2000版本以上的64位以及32位呆板上，它是一個批處理懲罰理會錯誤。它不需要特別安裝任何軟件（cmd.exe是Windows默認安裝的），它可以由任意權限的用戶提倡（假設他們可以運行cmd.exe，從而理會批處理懲罰文件）包羅理會錯誤產生的位置（妨礙代碼可以或許表明這個原因）。這并不是一個遠端節制條理的BUG，僅僅是一個DoS范例，需要獲得用戶請求才氣運行（可能是把其作為一個開機啟動項）。可是由于他的簡樸性，以及Windows系統的普及率，我小我私家認為它值得你看上那么一眼。
請留意，假如你啟用這些批處理懲罰文件導致系統瓦解我是不認真任的！任務打點器會竣事這個失控劇本的PID，以防備你運行。
Tldr：一個僅僅包容^ nul<^ 的批處理懲罰文件會造成一個龐大的內存泄漏，在一個僅僅只有 ^|^ 的批處理懲罰文件會使呼吁行無限遞歸導致瓦解。這些行為大概導致一些有趣的批處理懲罰編程，雖然我是指的在windows2K版本以上的操縱系統中，原因在于cmd.exe在處理懲罰批處理懲罰文件時產生的邏輯錯誤。
當我再回覆一位用戶提出的問題時，我碰著一個十分有趣的批處理懲罰文件理會異常，假如^這個字符是文件的最后一個字符，就大概產生內存泄漏，插入文件的最后一個字符不可以或許是 n （換行符），由于 r （回車符）在脫字標記之前就已經執行，所以沒有這種環境產生，理會器可以或許正常事情，沒有什么可以追蹤到（當插入^rt，理會卻成為了^r “t”就被忽略掉了）。最后留意一下，回車字符是可以或許正常執行的，雖然這也是一個小趣點，我們可以在大大都文本編輯器中對回車字符造假，在記事本的最后你可以傻逼的認為哪里尚有一個回車符
顛末一系列的折騰，我發明^字符在文件的最后大概導致內存泄漏，可能會致使呼吁提示符瓦解（詳細點說就是 command.com 可能cmd.exe措施），我還發明非凡的批處理懲罰文件（及其序列）會引起一些有趣的現象。進一步的觀測，引導我去存眷 是否其他人也有碰著過雷同的環境， a Stack Overflow question where a user noted a memory leak（在Stack Overflow提問中一個用戶暗示內存泄漏）在SS64.com的主題 other interesting behaviors with the caret at the EOF（在文件最后加上回車符引起的有趣現象）。Stack Oveflow上面的提問輔佐我確認了這并不是一個無限輪回范例的環境，可是并沒有表明清楚到底是怎么一回事，在SS64.com的主題中大部門內容都是在接頭從各個方面讓呼吁提示符瓦解，可是并沒有對道理舉辦表明。
自然的在我心中發生了疑問，到底是怎么產生的？怎么產生的呢？這個環境是否可以舉辦操作呢？謎底是巨大的，可是辦理要領確是很簡樸（至少看起來簡樸），我發明一些欺騙批處理懲罰文件組合，可以或許發生內存泄漏。是快是慢取決與你放入的批處理懲罰文件是什么（不是插入了幾多字符，而是管道序列，以及行數長度）無論是呼吁提示符瓦解照舊內存泄漏，理會代碼一直都是在單線程中駐留，所以CPU的占用量一直在增漲（單核CPU平均占用率到達98%）
讓呼吁提示符瓦解很簡樸，一個沒有換行的批處理懲罰文件只需要包容 ^&^ (可能 ^|^)就足以導致呼吁提示符呈現0xC00000FD錯誤 ，這是一個由于無限遞歸棧/幀呈現的泄漏。這重現了“無限輪回”的場景，但沒有完美表明內存泄漏（可能說是為什么這個無限輪回會導致瓦解），工作到這個水平，我開始通過舉辦一些最簡樸的要領來發生一個內存泄漏，事實證明，一個2字節的批處理懲罰文件是需要耗損整顆CPU以及吃內存的（盡量速度慢的離譜，~8k/5s on a 2.2GHz i7）
我用來測試的批處理懲罰文件包括以下16進制字節
0x01 0x5E
0X5E 是脫字標記(^) ，0X01是標題開始的Ascll碼。第一個16進制代碼，在這個BUG中危險水平沒有其它的高，因為他不能是NULL（0X00），r, |, 可能 & 這些字符會導致批處理懲罰文件通過正常途徑退出（也就是 ‘invalid command detected’）。我利用0X01證實它沒有一個有效的呼吁（可能顯示出有關的字符）導致這個BUG，一個2字節的批處理懲罰文件包括一個簡樸的^就足夠了。
做一些其他測試，我發此刻批處理懲罰文件最后加上^ nul<^是最快也是最簡樸的耗損CPU的要領。
隨機的運行若干次后，請提高留意，這么做去耗損64位系統CPU是很快的。僅僅是花了20S，就吃掉了我14G的RAM（總共16GB，四核I7而且利用超線程技能），最后我不得不重啟電腦。在32位系統上運行這個快速版本，盡量32位系統有2GB的限制，呼吁理會器也會很快的因為內存不敷而竣事任務。它不會導致呼吁提示符瓦解，相反的，它好像有一個檢測機制掩護內存分派，當它不可以或許直接終止批處理懲罰歷程時。