目前很多地方都轉(zhuǎn)載著利用9行代碼史windows崩潰的文章，不過我發(fā)現(xiàn)沒有關(guān)于為什么會使windows崩潰的分析。我先把原文給大家看看。然后把具體的細節(jié)說一下。  

微軟一直聲稱Windows XP多么多么穩(wěn)定可靠，但日前一位名為Masaru Tsuchiyama的外國編程愛好者刊出了一小段C語言代碼。這一只有9行的小程序如果在Windows XP/2000下運行，則可導(dǎo)致系統(tǒng)完全崩潰，并重新啟動。但此程序?qū)ζ渌姹镜腤indows沒有任何影響。這一產(chǎn)生無限循環(huán)輸出的小程序的代碼如下：  

　　#include  
　　int main( void )  
　　{　  
　　for(;{  
　　　　　　　printf( "hung up\t\t\b\b\b\b\b\b" );  
　　　　　　　print("hung up\t\t\b\b\b\b\b\b";  
　　　　　　}  
　　return 0;  
　　}  

　　如果去掉Print語句，此程序還會導(dǎo)致NT 4.0系統(tǒng)出現(xiàn)藍屏錯誤。  

　　但愿微軟趕快修補這一漏洞。同時提醒大家，此代碼只可用于研究，不得用于任何非法勾當。  
　　如果去掉Print語句，此程序還會導(dǎo)致NT 4.0系統(tǒng)出現(xiàn)藍屏錯誤。  

以上遍上網(wǎng)上紛紛轉(zhuǎn)載的原文。  

關(guān)于為什么會導(dǎo)致錯誤，就在看下面的分析吧。  

\b是退格  
代碼是用退格符把console里的光標退成null,  
然后顯示任一字符(除\t),即崩潰.  
但是一般情況\b是不能退出規(guī)定的區(qū)域的,  
而如\b的前一個字符是\t則可以退出規(guī)定的區(qū)域(bug?).  
雙擊運行時,系統(tǒng)將新建一個console,所以我們的顯示在console  
的左上角,我們只需兩個\b就可退出屏幕(第一個吃掉\t).  
原因是win32子系統(tǒng)意外中止導(dǎo)致系統(tǒng)崩潰.smss是windows系統(tǒng)建立的第一個用戶進程,他的工作之一是建立csrss和winlogon進程,然后一直等待這兩個進程的句柄,如果這兩個進程意外中止,  
smss將導(dǎo)致系統(tǒng)崩潰.csrss進程就是專門負責所有win32進程和系統(tǒng)進行通信的進程.所有win32進程的系統(tǒng)調(diào)用都會由csrss幫你完成,但是這樣做因為需要進程切換所以效率太低.所以在windowsNT從3.51升級到4.0時將許多部分從用戶態(tài)移入內(nèi)核態(tài),win32進程的系統(tǒng)調(diào)用將直接進行以減少進程切換時間.但是仍有少量系統(tǒng)調(diào)用需要csrss進程完成,據(jù)我所知createprocess  
是這樣的函數(shù),所有console上的顯示是這樣的函數(shù)(還有其他的).  
當我們調(diào)用printf("\t\b\ba")最終將調(diào)用WriteFile API.  
WriteFile((HANDLE)7,"\t\b\ba",NULL,NULL)等同于  
printf("\t\b\ba"),7是console標準輸入的句柄.  
WriteFile判斷句柄類型,如是文件句柄將調(diào)用ntdll.dll中的  
NtWriteFile函數(shù).如是console句柄將調(diào)用WriteConsoleA函數(shù).  
WriteConsoleA函數(shù)將調(diào)用ntdll.dll中的csrClientCallServer  
函數(shù)通知csrss進程,然后調(diào)用NtRequestWaitReplyPort等待結(jié)果.  
估計是csrss進程在處理這個請求過程中出錯了.  

幾年前侯杰老師分析后我整理出來的。因為沒有地方說過，甚至簡單的分析都沒有，所以我才把他翻出來 ：） 細心的人發(fā)現(xiàn)csrss出錯的細節(jié)沒有描述，誰有時間就補充一下吧.. 

最新評論