一、背景
Tor（The Oninon Router）提供一個匿名交流網絡平台，它使得使用者在浏覽網頁或通路其它網絡服務時不會被跟蹤。作為該網絡的一部分即所謂的“暗網”（darknet），是指隻能通過Tor網絡通路的伺服器群組，這些伺服器提供包括社群論壇、電子郵件等多種服務。雖然提供這些服務都是無惡意的，初衷是用來關注侵犯人權問題，但是由于匿名的原因吸引了很多有犯罪意圖的人，比如傳播兒童色情。事後執法部門也不能追蹤到犯罪者的源IP位址。
2013年，在“暗網”伺服器上發現了一款惡意軟體，它利用特定Web浏覽器上的安全漏洞在使用者電腦上執行一段代碼。該代碼收集一些使用者資訊，發往弗吉尼亞州的伺服器，之後自毀。就惡意軟體的特征來講，它沒有明顯的惡意意圖。初步推斷是FBI植入，他們在弗吉尼亞州有辦事處，曾經也派專人開發過惡意程式，可能是他們建立了它————現在看來是真的。
二、對Shellcode的逆向分析
1、漏洞利用
漏洞利用代碼用javascript編寫，利用一個出名的firefox浏覽器的特定版本（Tor網絡預裝的firefox）的漏洞。該漏洞利用代碼經過了模糊處理，但通過快速掃描可以看到一長串十六進制字元，這些字元是shellcode的前幾個标志性位元組，即call操作碼(shellcode經常以一個jump或call開始,是以知道了這些操作碼使得識别shellcode變得容易起來)。
我不會在這裡分析這個漏洞，但是要看一下這個shellcode。
首先，讓我們用一些基本的shellcode原則設定一個場景。
2、位置無關代碼
Shellcode的成功執行經過了獨一無二的挑戰，因為它是直接注入到一個程序而不是由Windows加載器加載。是以，我們不知道shellcode位于記憶體中的什麼地方，更關鍵的是，不知道标準的windowsAPI函數位于什麼地方（而通常情況下，Windows加載器會告訴一個程式這些資訊）。
是以，我們必須使用一系列技巧去獲得這個資訊。FBI惡意程式用了一個常用的技巧去找出它的記憶體位址：
call start
start：
pop ebp
call函數将執行程式移動到start标簽處，同時将程式目前執行的位置壓入堆棧中（這樣我們稍後可以從call函數傳回）。
在此，我們将要用這個值，從棧裡竊取位置，堆棧彈出的值儲存到ebp寄存器。我們現在知道了下一條指令的位址，那麼就可以用它來通路跟我們的shellcode相關的資料。
三、定位Windows API
因為正常情況下Windows加載器會加載Windows API的位置到我們的程式，是以我們不奢望運作一個shellcode時能夠知道程式的位置資訊。找出API函數慣用的方法是檢視FS段寄存器所指的線程資訊塊（thread information block）。我們能夠通過這個結構體去定位被我們shellcode宿主程式加載的DLLs，然後利用這些DLL的輸出直到找到目标函數為止。當然這個過程是很乏味的，是以，FBI這個shellcode使用了一個庫，包含在MetasploitFramwork内，這是由Stephen Fewer寫的一個函數解析器。它的工作原理如下：
push arguments
. . .
push FUNCTIONHASH
call <Stephen’sResolver>
這個函數的哈希值是由一個簡單的hash算法生成，以我們調用函數的名稱命名。這樣做的目的不是為了混淆代碼（盡管它達到這個目的），但隻允許我們用一個32位的DWORD來調用此函數,而不是一個長型字元串（shellcode空間往往是有限的）。 值得慶幸的是，我們自己可以計算出hash值，或者用别人生成的查找表。
四、開始
如果我們對shellcode的開始進行反彙編，如下圖：
我們一旦計算出指向API解析器的ebp寄存器值，我們就可以在windows的API進行哈希調用前擷取其十六進制數。如此，如果在查找表裡查找到那個值，在那個值附近查找調用的函數，并且添加一些注釋，如下圖：
這段代碼執行完整性檢查，通過用GET 開始的HTTP請求頭部資訊以確定shellcode安全運作。然後調用Windows
API函數LoadLibrary（）載入兩個動态連結庫：ws2_32.dll（用于網際網路通信的Windows套接字庫）和iphlpapi.dll（WindowsIP輔助庫）。
五、連接配接到HTTP伺服器
在必要的庫檔案都加載完之後，shellcode将執行下圖中的操作：
再一次，用相同的步驟，用哈希值查找一個Windows API函數：connect()函數。我們可以看見，在[ebp +0x2e1]位置的資料作為一個參數傳遞給connect()函數—從手冊我們知道，那個參數是一個sockaddr結構體（sockaddr structure）。我們知道ebp寄存器指向我們在記憶體中的位址，使用那個位址，再加上偏移量，我們就能定位出那些資料在記憶體0x2E8處（ebp=0×7）。
是以，我們在分析sockaddr之前，先給這些代碼添加一些注釋，命名一些記憶體偏移位址，如下圖：
這個eax寄存器儲存着調用connect()函數的傳回值，如果這個值為0（來自微軟使用者手冊）表示connect()調用成功。但是我們成功連接配接到哪兒？如果我們現在添加一些注釋到我們之前的反彙編檔案，基于我們在微軟使用者手冊中能查到的關于sockaddr結構體的資訊，我們可以這樣添加注釋，如下圖：
通過對IP位址進行whois快速查詢,隻得到很少資訊。如下圖：
六、收集使用者資訊
接下來，這個惡意軟體嘗試獲得windows主機名—通常情況下這是windows機器的名字。這可能有助于确認嫌疑犯和确認他們沒有逮捕錯人。
其次，它枚舉了活躍主機的hostname和IP位址。
使用SendARP()函數來發現網絡中所有電腦的MAC位址。有一些“恰當”的方式做到這樣，但是shellocode隻能獲得有限的空間去完成這些事。MAC位址将使用者與一張特定的網卡綁定，于是可以通過這些網卡的供應鍊來追蹤使用者。
最後，它要建構HTTP頭部資訊，将MAC位址放進Cookie字段，使用者的主機名放進Host字段，并且要以GET請求方式發送到
http://65.222.202.54/05cea4de-951d-4037-bf8f-f69055b279bb。這些十六進制數字的意義不清楚，它們可能是任意選擇或連結一個使用者到特定的接入伺服器。
七、最後階段
這個shellcode最後階段的唯一目的就是在該shellcode結束時運作更多的shell代碼—它這樣做的方式稍微有點迂回，我也不知道為什麼這樣，也許是一次粗略的嘗試。
那麼，最後一歩要怎麼做。首先，它利用一些字元串長度操作找出一些被嵌入在其他所有資料區的代碼。那些代碼計算出我們的HTTP請求字元串結束的位置，跳過在shellcode結尾處的所有的無效的空操作指令，然後跳到那裡。那裡是哪裡？誰知道！我被告知有更多的shellcode（這不重要），但是我已經沒有時間來調試這個漏洞并獲得它。
建構頭部，然後跳轉到頭部結尾處。
查找http頭部結尾處的無效指令并且跳過它們。
八、運作代碼
到目前為止，我以完全靜态的方式分析了這些代碼—主要是為了完整性。通過運作這些代碼能夠更快速的分析它們，同時可以驗證我們的分析是否正确。既然這段惡意代碼沒有任何破壞系統的行為，是以我們可以安全的在真機上運作它。于是運作它并觀察它發送給FBI的确切資料。因為shellcode不是一個exe可執行檔案，我需要一個shellcode加載器去運作它—-它們快速的配置設定需要的記憶體，加載shellcode并跳轉到該處。這是加載shellcode需要做的—-在調用真正的shellcode之前會自動斷開。
然後我們啟動調試器跨步執行到調用cnnect（）函數。我們不得不把這個shellcode的目标指向另一台我們自己的機器，便于觀察運作結果。是以，我将讓他指向ip位址為192.168.0.254的77端口，然後在這個機器上運作netcat程式抓取資料。在下圖代碼暫停的箭頭所指處,就是早期通過patch方式來修改sockaddr結構體。
然後我們繼續跨步執行到調用send（）函數，執行它，之後我們能看見在netcat終端的輸出，它将輸出它收到的所有資料—顯示的那些資料原本是發給FBI。你可以看到，cookie裡面的ID包含了我的MAC位址，Host
頭部包含了我的desktop名。
最後，我們跨步執行到最後階段—最後的空操作可能是用來注入更多的已經提取的shellcode。在那個十六進制檢視器視窗可以看見，我們構造的那個HTTP請求已經發出。
九、結論
這個惡意軟體從使用者浏覽器發送确認資訊給攻擊機，然後使使用者firefox浏覽器崩潰。就複雜性而言，它沒有很明顯的特别之處，也沒有使用一些大家不知道的新技術。
如果這個惡意軟體作者是FBI，那麼他們需要去回答一些很嚴肅的問題。這些惡意程式被植入到非美國的伺服器上，并攻擊利用全球使用者的浏覽器（他們當中很多人是無辜的）他們這樣做甚至可能會得到法律授權？我不這麼認為。當有人告發時FBI是否需要出示他們曾經得到過法律授權的證據？未必。我希望他們會依據使用者的電腦内發現的證據和在收到起訴時取得的證據—-盡管最初的搜尋授權可能很不靠譜。不管怎麼說，我畢竟不是一個律師。