ASLR編譯

❶ c#使用命令行編譯生成dll文件

C#使用csc.exe編譯程序，csc使用/target:library(縮寫: /t:library)參數生成Dll文件。
其它參數如下：
Visual C# 編譯器選項
- 輸出文件 -
/out:<文件> 指定輸出文件名(默認值: 包含主類的文件或第一個文件的基名稱)
/target:exe 生成控制台可執行文件(默認) (縮寫: /t:exe)
/target:winexe 生成 Windows 可執行文件 (縮寫: /t:winexe)
/target:library 生成庫 (縮寫: /t:library)
/target:mole 生成能添加到其他程序集的模塊 (縮寫: /t:mole)
/target:appcontainerexe 生成 Appcontainer 可執行文件 (縮寫: /t:appcontainerexe)
/target:winmdobj 生成 WinMDExp 使用的 Windows 運行時中間文件 (縮寫: /t:winmdobj)
/doc:<文件> 要生成的 XML 文檔文件
/platform:<字元串> 限制可以在其上運行此代碼的平台: x86、Itanium、x64、arm、anycpu32bitpreferred 或 anycpu。默認值為 anycpu。

- 輸入文件 -
/recurse:<通配符> 根據通配符規范，包括當前目錄和子目錄下的所有文件
/reference:<別名>=<文件> 使用給定的別名從指定的程序集文件引用元數據 (縮寫: /r)
/reference:<文件列表> 從指定的程序集文件引用元數據 (縮寫: /r)
/addmole:<文件列表> 將指定的模塊鏈接到此程序集中
/link:<文件列表> 嵌入指定的互操作程序集文件中的元數據 (縮寫: /l)

- 資源 -
/win32res:<文件> 指定 Win32 資源文件(.res)
/win32icon:<文件> 對輸出使用此圖標
/win32manifest:<文件> 指定 Win32 清單文件(.xml)
/nowin32manifest 不包括默認 Win32 清單
/resource:<資源信息> 嵌入指定的資源 (縮寫: /res)
/linkresource:<資源信息> 將指定的資源鏈接到此程序集 (縮寫: /linkres)
其中 resinfo 的格式是 <file>[,<string name>[,public|private]]

- 代碼生成 -
/debug[+|-] 發出調試信息
/debug:{full|pdbonly} 指定調試類型(「full」是默認類型，可以將調試程序附加到正在運行的程序)
/optimize[+|-] 啟用優化 (縮寫: /o)

- 錯誤和警告 -
/warnaserror[+|-] 將所有警告報告為錯誤
/warnaserror[+|-]:<警告列表> 將特定警告報告為錯誤
/warn:<n> 設置警告等級(0-4) (縮寫: /w)
/nowarn:<警告列表> 禁用特定的警告消息

- 語言 -
/checked[+|-] 生成溢出檢查
/unsafe[+|-] 允許「不安全」代碼
/define:<符號列表> 定義條件編譯符號 (縮寫: /d)
/langversion:<字元串> 指定語言版本模式: ISO-1、ISO-2、3、4、5 或 Default

- 安全性 -
/delaysign[+|-] 僅使用強名稱密鑰的公共部分對程序集進行延遲簽名
/keyfile:<文件> 指定強名稱密鑰文件
/keycontainer:<字元串> 指定強名稱密鑰容器
/highentropyva[+|-] 啟用高平均信息量的 ASLR

- 雜項 -
@<文件> 有關更多選項，請閱讀響應文件
/help 顯示此用法信息 (縮寫: /?)
/nologo 取消編譯器版權信息
/noconfig 不要自動包含 CSC.RSP 文件

- 高級 -
/baseaddress:<地址> 要生成的庫的基址
/bugreport:<文件> 創建「Bug 報告」文件
/codepage:<n> 指定打開源文件時要使用的代碼頁
/utf8output 以 UTF-8 編碼格式輸出編譯器消息
/main:<類型> 指定包含入口點的類型(忽略所有其他可能的入口點) (縮寫: /m)
/fullpaths 編譯器生成完全限定路徑
/filealign:<n> 指定用於輸出文件節的對齊方式
/pdb:<文件> 指定調試信息文件名(默認值: 擴展名為 .pdb 的輸出文件名)
/errorendlocation 輸出每個錯誤的結束位置的行和列
/preferreilang 指定首選輸出語言名稱。
/nostdlib[+|-] 不引用標准庫(mscorlib.dll)
/subsystemversion:<字元串> 指定此程序集的子系統版本
/lib:<文件列表> 指定要在其中搜索引用的附加目錄
/errorreport:<字元串> 指定如何處理內部編譯器錯誤: prompt、send、queue 或 none。默認值為 queue。
/appconfig:<文件> 指定一個包含程序集綁定設置的應用程序配置文件
/moleassemblyname:<字元串> 此模塊所屬程序集的名稱

❷ windows 7中內存保護機制不包括哪項技術

Windows操作系統為解決棧溢出漏洞的問題引入了一個對策——GS編譯保護技術。

GS編譯保護技術是通過編譯時添加相關代碼而實現的，開啟GS 編譯選項後會在函數的開頭和結尾添加代碼來阻止棧溢出漏洞的利用。當應用程序啟動時，程序的cookie被計算出來（偽隨機數）並保存在.data 節段中，在函數的開頭這個 cookie 被拷貝到棧中，位於返回地址和局部變數的中間。
函數調用完後系統檢測cookie值是否被修改。

1.2 繞過方法
計算/猜測cookie值
覆蓋虛函數表
堆棧布局：[局部變數][cookie][入棧寄存器][返回地址][參數][虛表指針]。

覆蓋對象和虛函表指針，如果你把這個指針指向一個用於欺騙的虛函數表，你就可以重定向這個虛函數的調用，並執行惡意的代碼。

覆蓋SHE
SEH句柄用於指向異常處理函數，這個句柄被存在SecurityCookie的上方，這使得攻擊者不需要覆蓋到SecurityCookie就可以修改SEH句柄指向的位置。

同時替換掉棧中和.data段中的cookie值
通過替換載入模塊.data 節中的cookie 值（可寫）來繞過棧上的 cookie 保護，並用相同的值替換棧中的cookie。

2 SafeSEH機制
2.1 基本原理
通過覆蓋SEH可以繞過GS編譯保護，所以微軟又引入了一種SEH的安全校驗機制——SafeSEH。

通過啟用/SafeSEH編譯選項來把這種機制應用到所有的執行模塊上，當異常處理器被執行前，SafeSEH會驗證異常處理鏈是否被修改過。系統會從頭到尾遍歷異常處理鏈表，並逐個驗證它們的有效性。

如果覆蓋SEH，這將破壞鏈表並觸發SafeSEH機制。

2.2 繞過方法
利用未開啟SafeSEH保護的模塊
尋找程序中載入的未開啟SafeSEH保護的模塊來繞過，比如軟體本身自帶的dll文件。

利用堆繞過
SafeSEH允許其異常處理句柄位於除棧空間之外的非映像頁面。如果你將shellcode寫在堆空間中 ，再覆蓋SEH鏈表的地址。使程序異常處理句柄指向堆空間，就可以繞過SafeSEH的檢測了。

覆蓋虛函數表（同上）
3 SEH覆蓋保護
3.1 基本原理
SEH覆蓋保護（SEHOP）可作為SEH的擴展，用於檢測SEH是否被覆寫。

SEHOP的核心特性是用於檢測程序棧中的所有SEH結構鏈表的完整性，特別是對最後一個SHE結構的檢測。在最後一個SEH結構中擁有一個特殊的異常處理函數指針，指向一個位於ntdll中的函數ntdll!FinalExceptHandler()。

3.2 繞過方法
利用未開啟SEHOP保護的模塊
覆蓋虛函數表
偽造SEH鏈表
4 數據執行保護（DEP）
4.1 基本原理
數據執行保護 (DEP) 是一套軟硬體技術，能夠在內存上執行額外檢查以防止在不可運行的內存區域上執行代碼。

DEP 有兩種模式，如果 CPU 支持內存頁 NX 屬性， 就是硬體支持的 DEP。如果 CPU 不支持， 那就是軟體支持的 DEP 模式，這種 DEP 不能阻止在數據頁上執行代碼，但可以防止其他的 exploit（如SEH覆蓋）。

4.2 繞過方法
ret2libc
ret2libc是一種通過retn指令在庫函數中尋找可用代碼的攻擊方式。由於其所有代碼都是從libc中找到的，所以不存在不可執行的問題。

關閉進程的DEP (NtSetInformationProcess)
因為 DEP 可以設置不同的模式，操作系統需要能動態關閉DEP，因此系統肯定有API來啟用或關閉NX，如果黑客可以找到這個NTDLL中的 API，就能繞過硬體DEP保護。一個進程的DEP設置標志保存在內核結構中（KPROCESS結構），這個標志可以用函數NtQueryInformationProcess和NtSetInformationProcess通過設置ProcessExecuteFlags類來查詢和修改，用內核調試器也可以達到同樣的目的。

利用可寫可執行內存
有些程序可能由於配置的問題或者其他原因，在進程中存在可讀可寫可執行的區域。如果攻擊者可以將shellcode寫入這部分空間中並劫持流程，就可以繞過DEP。

利用TEB突破DEP（局限於XP SP2以下的版本）
利用WPN與ROP技術

利用SEH

5 地址隨機化（ASLR）
5.1 基本原理
ASLR（地址空間布局隨機化）技術的主要功能是通過對系統關鍵地址的隨機化，防止攻擊者在堆棧溢出後利用固定的地址定位到惡意代碼並加以運行。它主要對以下四類地址進行隨機化：堆地址、棧基址、PE文件映像基址、PEB地址。

適用范圍：Windows Vista，Windows 2008 server，Windows 7下是默認啟用。

5.2 繞過方法
覆蓋部分返回地址

雖然模塊載入基地址發生變化，但是各模塊的入口點地址的低位元組不變，只有高位變化。部分返回地址覆蓋，可以使得覆蓋後的地址相對於基地址的距離是固定的，可以從基地址附近找可以利用的跳轉指令。這種方法的通用性不是很強，因為覆蓋返回地址時棧上的Cookie會被破壞。不過具體問題具體分析，為了繞過操作系統的安全保護機制需要考慮各種各樣的情況。

❸ win7有何優越性能

你好，Windows 7 使基本操作變得前所未有的簡單。藉助家庭組，您可以與家裡另外運行 Windows 7 的電腦輕松共享音樂、文檔、列印機及任何其他內容。 Windows Search 免去從眾多文件夾和子文件夾中查找資料的繁瑣。更優的任務欄預覽允許您更好地查看正在運行的任務，並且只需單擊一下右鍵，Jump List 就會為您列出最近訪問的文件。 如果電腦不能按照您希望的方式順暢運行，不需要您的電腦有很多功能就能解決。Windows 7 旨在幫助您的電腦更快速地休眠和恢復。 Windows 7 支持最先進的電腦硬體，例如 64 位計算及多核處理器；同時經過改善的內存使用率可幫助硬體充分發揮性能潛力。 一旦您的電腦變得更快、更簡單，您就會發現一些很酷的新功能。例如：不管在家中、辦公室或是咖啡店，您只需雙擊滑鼠就可以連接到網路；並且藉助 Windows 觸控功能（以及合適的硬體），您很快就可以用手指翻閱文件、處理圖片甚至「畫圖」。 希望我的回答能夠幫助你。

❹ 漏洞分析的內容導讀

本書分為5篇，共33章。
第1篇 漏洞利用原理（初級）
第1章 基礎知識
本章著重對漏洞挖掘中的一些基礎知識進行介紹。首先是漏洞研究中的一些基本概念和原理；然後是對Windows平台下可執行文件的結構和內存方面的一些基礎知識的介紹；最後介紹了一些漏洞分析中經常使用的軟體工具。包括調試工具、反匯編工具、二進制編輯工具等。您會在後面的調試實驗中反復見到這些工具的身影。在這章的最後一節，我們設計了一個非常簡單的破解小實驗，用於實踐工具的應用，消除您對二進制的恐懼感，希望能夠給您帶來一些樂趣。
第2章 棧溢出原理與實踐
基於棧的溢出是最基礎的漏洞利用方法。本章首先用大量的示意圖，深入淺出地講述了操作系統中函數調用、系統棧操作等概念和原理；隨後通過三個調試實驗逐步講解如何通過棧溢出，一步一步地劫持進程並植入可執行的機器代碼。即使您沒有任何匯編語言基礎，從未進行過二進制級別的調試，在本章詳細的實驗指導下也能輕松完成實驗，體會到exploit的樂趣。
第3章 開發shellcode的藝術
本章緊接第2章的討論，比較系統地介紹了溢出發生後，如何布置緩沖區、如何定位shellcode、如何編寫和調試shellcode等實際的問題。最後兩小節還給出了一些編寫shellcode的高級技術，供有一定匯編基礎的朋友做參考。
第4章 用MetaSploit開發Exploit
MetaSploit是軟體工程中的Frame Work（架構）在安全技術中的完美實現，它把模塊化、繼承性、封裝等面向對象的特點在漏洞利用程序的開發中發揮得淋漓盡致。使用這個架構開發Exploit要比直接使用C語言寫出的Exploit簡單得多。本章將集中介紹如何使用這個架構進行Exploit開發。
第5章 堆溢出利用
在很長一段時間內，Windows下的堆溢出被認為是不可利用的，然而事實並非如此。本章將用精闢的論述點破堆溢出利用的原理，讓您輕松領會堆溢出的精髓。此外，這章的一系列調試實驗將加深您對概念和原理的理解。用通俗易懂的方式論述復雜的技術是本書始終堅持的原則。
第6章 形形色色的內存攻擊技術
在了解基本的堆棧溢出後，本章將為大家展示更為高級的內存攻擊技術。本章集中介紹了一些曾發表於Black Hat上的著名論文中所提出的高級利用技術，如狙擊Windows異常處理機制、攻擊虛函數、off by one、 Heap Spray等利用技巧。對於安全專家，了解這些技巧和手法不至於在分析漏洞時錯把可以利用的漏洞誤判為低風險類型；對於黑客技術愛好者，這些知識很可能成為激發技術靈感的火花。
第7章 手機里的緩沖區溢出
在PC機上的溢出攻擊進行的如火如荼的時候，您是否也想了解手機平台上的緩沖區溢出問題？那就不要錯過本章！本章以ARM和Windows Mobile為例，介紹手機平台上編程和調試技巧。並在最後以一個手機上的exploit me為大家揭開手機里緩沖區溢出的神秘面紗。
第8章 其他類型的軟體漏洞
緩沖區溢出漏洞只是軟體漏洞的一個方面，我們來看看其他一些流行的安全漏洞。如格式化串漏洞、SQL注入、XPath注入、XSS等安全漏洞產生的原因、利用技巧及防範措施。
第2篇 漏洞利用原理（高級）
第9章 Windows安全機制概述
微軟在Windows XP SP2和Windows 2003之後，向操作系統中加入了許多安全機制。本章將集中討論這些安全機制對漏洞利用的影響。
第10章 棧中的守護天使：GS
針對緩沖區溢出時覆蓋函數返回地址這一特徵，微軟在編譯程序時使用了一個很酷的安全編譯選項——GS。本章將對GS編譯選項的原理進行詳細介紹，並介紹幾種繞過GS的溢出技巧。
第11章 亡羊補牢：SafeSEH
攻擊S.E.H已經成為windows平台下漏洞利用的經典手法。為了遏制日益瘋狂的攻擊，微軟在Windows XP SP2及後續版本的操作系統中引入了著名的S.E.H校驗機制SafeSEH。本章將會對這一安全機制進行詳細的分析，並介紹其中的不足和繞過方法。
第12章 數據與程序的分水嶺：DEP
溢出攻擊的根源在於現代計算機對數據和代碼沒有明確區分這一先天缺陷， 而DEP這種看似釜底抽薪式的防護措施是否真的可以杜絕溢出攻擊呢？答案馬上揭曉。
第13章 在內存中躲貓貓：ASLR
程序載入時不再使用固定的基址載入，ASLR技術將溢出時使用的跳板在內存中隱藏了起來，沒有了跳板我們如何溢出呢？本章將帶領您在黑暗中尋找溢出的出口。
第14章 S.E.H終極防護：SEHOP
SafeSEH的敗北，讓微軟推出一種更為嚴厲的S.E.H保護機制SEHOP。這里將為您展示這種保護機制的犀利之處。
第15章 重重保護下的堆
當堆溢出變成可能後，微軟不能再無視堆中的保護機制了，讓我們一覽堆中的保護機制，並分析其漏洞。
第3篇 漏洞挖掘技術
第16章 漏洞挖掘技術簡介
不論從工程上講還是從學術上講，漏洞挖掘都是一個相當前沿的領域。本章將從動態測試和靜態審計兩方面對漏洞挖掘技術的基礎知識進行簡單的介紹。
第17章 文件類型漏洞挖掘與Smart Fuzz
文件類型的漏洞層出不窮，持續威脅著互聯網的安全。如何系統的測試文件格式，產生精確有效的畸形測試用例用以發掘文件解析器的安全漏洞，並不是一件容易的事情。本章將從理論和實踐兩個方面向您講述灰盒測試技術。
第18章 FTP的漏洞挖掘
本章將簡述FTP協議，並手把手地帶領您完成幾個初級的漏洞測試案例，讓您親身體會下真實的漏洞長什麼模樣。
第19章 E-mail的漏洞挖掘
E-mail系統涉及的安全問題不光只有緩沖區溢出，在本章的挖掘案例中，您會發現除了工具和常用方法外，威力最為強大的武器還是您的大腦。Evil thinking是安全測試中最重要的思維方式之一。
第20章 ActiveX控制項的漏洞挖掘
控制項類漏洞曾經是大量網馬的棲身之地。本章將結合若干個曾經的0 day向您比較系統的介紹這類漏洞的測試、調試的相關工具和方法。
第4篇 操作系統內核安全
第21章 探索ring0
研究內核漏洞，需要首先掌握一些內核基礎知識，例如內核驅動程序的開發、編譯、運行和調試，內核中重要的數據結構等，本章將為讀者開啟探索ring0之門，逐步掌握一些內核基礎知識。
第22章 內核漏洞利用技術
本章將帶領讀者從一個簡單的內核漏洞程序exploitme.sys的編寫開始，展示內核漏洞利用的思路、方法，以及利用程序和Ring0 Shellcode的編寫和設計。
第23章 FUZZ驅動程序
掌握了內核漏洞的原理和利用方法，本章將進入內核漏洞挖掘階段，學習較為高級的內核漏洞挖掘技術，最後實踐該漏洞挖掘技術，分析挖掘出內核漏洞。
第24章 內核漏洞案例分析
本章對幾種典型的內核漏洞，用幾個真實的內核漏洞案例來詳細分析，分析漏洞造成的具體原因和細節，並構造漏洞成功利用的方法。
第5篇 漏洞分析案例
第25章 漏洞分析技術概述
本章縱覽了漏洞分析與調試的思路，並介紹了一些輔助漏洞調試分析的高級逆向工具。
第26章 RPC入侵：MS06-040 與MS08-067
由於可以做到主動式遠程入侵，RPC級別的漏洞被譽為漏洞中的王者，此類漏洞也極其稀有，每一個都有一段曲折的故事。值得一提的是最近的兩個RPC系統漏洞竟然出自同一個函數。本章將對這個縫來補去沒有修好的函數進行詳細分析，讓您從攻防兩方面深刻理解漏洞的起因和修復策略的重要性。
第27章 MS06-055分析：實戰Heap Spray
通過網頁「掛馬」是近年來攻擊者慣用的手法。本章通過分析微軟IE瀏覽器中真實的緩沖區溢出漏洞，告訴您為什麼不能隨便點擊來歷不明的URL鏈接，並在實戰中為大家演示Heap Spray技術。
第28章 MS09-032分析：一個「&」引發的血案
一個視頻網頁的背後可能是一隻兇狠的木馬，這就是著名的Microsoft DirectShow MPEG-2視頻ActiveX控制項遠程代碼執行漏洞。本章將為您分析該漏洞產生的原因及分析技巧。
第29章 Yahoo!Messenger棧溢出漏洞
在波濤洶涌的溢出大潮中Yahoo也沒能倖免，作為國外非常流行的Yahoo!Messenger也存在過非常嚴重的漏洞。本章將重現當時的場景，並分析漏洞產生的原因。
第30章 CVE-2009-0927：PDF中的JS
您可能不會隨便運行一個可執行文件，但是您會想到別人發過來的PDF文檔中也有可能隱藏著一些東西嗎？本章將以PDF文檔為例，帶您領略文件類型溢出漏洞的風采。
第31章 壩之蟻穴：超長URL溢出漏洞
安全軟體不一定安全，即便是這款保護未成年人健康上網的計算機終端過濾軟體，也有可能成為黑客攻擊的窗口。本章將介紹綠壩軟體中一個已經被修復了的安全漏洞。
第32章 暴風影音M3U文件解析漏洞
晚上回家後用暴風影音打開別人發過來的M3U列表文件，在你陶醉於其內容之時，一隻精乾的小馬已悄然在後台運行。想要了解這只小馬是如何進入你的電腦的？請閱讀本章。
第33章 LNK快捷方式文件漏洞
是否我不去運行任何可疑文件，不去打開陌生的網址就安全了呢？答案是否定。LNK快捷方式漏洞無需打開文件，只要瀏覽惡意文件，所在文件夾就會中毒，俗稱「看一眼就掛」。本章將帶您分析這一神奇的漏洞。
Failwest

❺ 如何檢查 Android 應用的內存使用情況

解析日誌信息
最簡單的調查應用內存使用情況的地方就是Dalvik日誌信息。可以在logcat（輸出信息可以在Device Monitor或者IDE中查看到，例如Eclipse和Android Studio）中找到這些日誌信息。每次有垃圾回收發生，logcat會列印出帶有下面信息的日誌消息：

java

1

D/dalvikvm: <GC_Reason> <Amount_freed>, <Heap_stats>, <External_memory_stats>, <Pause_time>

GC原因
觸發垃圾回收執行的原因和垃圾回收的類型。原因主要包括：
GC_CONCURRENT
並發垃圾回收，當堆開始填滿時觸發來釋放內存。
GC_FOR_MALLOC
堆已經滿了時應用再去嘗試分配內存觸發的垃圾回收，這時系統必須暫停應用運行來回收內存。
GC_HPROF_DUMP_HEAP
創建HPROF文件來分析應用時觸發的垃圾回收。
GC_EXPLICIT
顯式垃圾回收，例如當調用 gc()（應該避免手動調用而是要讓垃圾回收器在需要時主動調用）時會觸發。
GC_EXTERNAL_ALLOC
這種只會在API 10和更低的版本（新版本內存都只在Dalvik堆中分配）中會有。回收外部分配的內存（例如存儲在本地內存或NIO位元組緩沖區的像素數據）。
釋放數量
執行垃圾回收後內存釋放的數量。
堆狀態
空閑的百分比和（活動對象的數量）/（總的堆大小）。
外部內存狀態
API 10和更低版本中的外部分配的內存（分配的內存大小）/（回收發生時的限制值）。
暫停時間
越大的堆的暫停時間就越長。並發回收暫停時間分為兩部分：一部分在回收開始時，另一部分在回收將近結束時。
例如：

Java

1

D/dalvikvm( 9050): GC_CONCURRENT freed 2049K, 65% free 3571K/9991K, external 4703K/K, paused 2ms+2ms

隨著這些日誌消息的增多，注意堆狀態（上面例子中的3571K/9991K）的變化。如果值一直增大並且不會減小下來，那麼就可能有內存泄露了。
查看堆的更新
為了得到應用內存的使用類型和時間，可以在Device Monitor中實時查看應用堆的更新：
1.打開Device Monitor。
從<sdk>/tools/路徑下載入monitor工具。
2.在Debug Monitor窗口，從左邊的進程列表中選擇要查看的應用進程。
3.點擊進程列表上面的Update Heap。
4.在右側面板中選擇Heap標簽頁。

Heap視圖顯示了堆內存使用的基本狀況，每次垃圾回收後會更新。要看更新後的狀態，點擊Gause GC按鈕。

圖1.Device Monitor工具顯示[1] Update Heap和 [2] Cause GC按鈕。右邊的Heap標簽頁顯示堆的情況。
跟蹤內存分配
當要減少內存問題時，應該使用Allocation Tracker來更好的了解內存消耗大戶在哪分配。Allocation Tracker不僅在查看內存的具體使用上很有用，也可以分析應用中的關鍵代碼路徑，例如滑動。
例如，在應用中滑動列表時跟蹤內存分配，可以看到內存分配的動作，包括在哪些線程上分配和哪裡進行的分配。這對優化代碼路徑來減輕工作量和改善UI流暢性都極其有用。
使用Allocation Tracker：
1.打開Device Monitor 。
從<sdk>/tools/路徑下載入monitor工具。
2.在DDMS窗口，從左側面板選擇應用進程。
3.在右側面板中選擇Allocation Tracker標簽頁。
4.點擊Start Tracking。
5.執行應用到需要分析的代碼路徑處。
6.點擊Get Allocations來更新分配列表。
列表顯示了所有的當前分配和512大小限制的環形緩沖區的情況。點擊行可以查看分配的堆棧跟蹤信息。堆棧不只顯示了分配的對象類型，還顯示了屬於哪個線程哪個類哪個文件和哪一行。

圖2. Device Monitor工具顯示了在Allocation Tracker中當前應用的內存分配和堆棧跟蹤的情況。
注意：總會有一些分配是來自與 DdmVmInternal 和 allocation tracker本身。
盡管移除掉所有嚴重影響性能的代碼是不必要的（也是不可能的），但是allocation tracker還是可以幫助定位代碼中的嚴重問題。例如，應用可能在每個draw操作上創建新的Paint對象。把對象改成全局變數就是一個很簡單的改善性能的修改。
查看總體內存分配
為了進一步的分析，查看應用內存中不同內存類型的分配情況，可以使用下面的 adb 命令：

Java

1

adb shell mpsys meminfo <package_name>

應用當前的內存分配輸出列表，單位是千位元組。
當查看這些信息時，應當熟悉下面的分配類型：
私有(Clean and Dirty) 內存
進程獨占的內存。也就是應用進程銷毀時系統可以直接回收的內存容量。通常來說，「private dirty」內存是其最重要的部分，因為只被自己的進程使用。它只在內存中存儲，因此不能做分頁存儲到外存（Android不支持swap）。所有分配的Dalvik堆和本地堆都是「private dirty」內存；Dalvik堆和本地堆中和Zygote進程共享的部分是共享dirty內存。
實際使用內存 (PSS)
這是另一種應用內存使用的計算方式，把跨進程的共享頁也計算在內。任何獨占的內存頁直接計算它的PSS值，而和其它進程共享的頁則按照共享的比例計算PSS值。例如，在兩個進程間共享的頁，計算進每個進程PPS的值是它的一半大小。
PSS計算方式的一個好處是：把所有進程的PSS值加起來就可以確定所有進程總共佔用的內存。這意味著用PSS來計算進程的實際內存使用、進程間對比內存使用和總共剩餘內存大小是很好的方式。
例如，下面是平板設備中Gmail進程的輸出信息。它顯示了很多信息，但是具體要講解的是下面列出的一些關鍵信息。
注意：實際看到的信息可能和這里的稍有不同，輸出的詳細信息可能會根據平台版本的不同而不同。

Java

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

** MEMINFO in pid 9953 [com.google.android.gm] **
Pss Pss Shared Private Shared Private Heap Heap Heap
Total Clean Dirty Dirty Clean Clean Size Alloc Free
------ ------ ------ ------ ------ ------ ------ ------ ------
Native Heap 0 0 0 0 0 0 7800 7637(6) 126
Dalvik Heap 5110(3) 0 4136 4988(3) 0 0 9168 8958(6) 210
Dalvik Other 2850 0 2684 2772 0 0
Stack 36 0 8 36 0 0
Cursor 136 0 0 136 0 0
Ashmem 12 0 28 0 0 0
Other dev 380 0 24 376 0 4
.so mmap 5443(5) 1996 2584 2664(5) 5788 1996(5)
.apk mmap 235 32 0 0 1252 32
.ttf mmap 36 12 0 0 88 12
.dex mmap 3019(5) 2148 0 0 8936 2148(5)
Other mmap 107 0 8 8 324 68
Unknown 6994(4) 0 252 6992(4) 0 0
TOTAL 24358(1) 4188 9724 17972(2)16388 4260(2)16968 16595 336

Objects
Views: 426 ViewRootImpl: 3(8)
AppContexts: 6(7) Activities: 2(7)
Assets: 2 AssetManagers: 2
Local Binders: 64 Proxy Binders: 34
Death Recipients: 0
OpenSSL Sockets: 1

SQL
MEMORY_USED: 1739
PAGECACHE_OVERFLOW: 1164 MALLOC_SIZE: 62

通常來說，只需關心Pss Total列和Private Dirty列就可以了。在一些情況下，Private Clean列和Heap Alloc列也會提供很有用的信息。下面是一些應該查看的內存分配類型(行中列出的類型)：
Dalvik Heap
應用中Dalvik分配使用的內存。Pss Total包含所有的Zygote分配（如上面PSS定義所描述的，共享跨進程的加權）。Private Dirty是應用堆獨占的內存大小，包含了獨自分配的部分和應用進程從Zygote復制分裂時被修改的Zygote分配的內存頁。
注意：新平台版本有Dalvik Other這一項。Dalvik Heap中的Pss Total和Private Dirty不包括Dalvik的開銷，例如即時編譯（JIT）和垃圾回收（GC），然而老版本都包含在Dalvik的開銷裡面。
Heap Alloc是應用中Dalvik堆和本地堆已經分配使用的大小。它的值比Pss Total和Private Dirty大，因為進程是從Zygote中復制分裂出來的，包含了進程共享的分配部分。
.so mmap和.dex mmap
mmap映射的.so(本地) 和.dex(Dalvik)代碼使用的內存。Pss Total 包含了跨應用共享的平台代碼；Private Clean是應用獨享的代碼。通常來說，實際映射的內存大小要大一點——這里顯示的內存大小是執行了當前操作後應用使用的內存大小。然而，.so mmap 的private dirty比較大，這是由於在載入到最終地址時已經為本地代碼分配好了內存空間。
Unknown
無法歸類到其它項的內存頁。目前，這主要包含大部分的本地分配，就是那些在工具收集數據時由於地址空間布局隨機化(Address Space Layout Randomization ，ASLR)不能被計算在內的部分。和Dalvik堆一樣， Unknown中的Pss Total把和Zygote共享的部分計算在內，Unknown中的Private Dirty只計算應用獨自使用的內存。
TOTAL
進程總使用的實際使用內存(PSS)，是上面所有PSS項的總和。它表明了進程總的內存使用量，可以直接用來和其它進程或總的可以內存進行比較。
Private Dirty和Private Clean是進程獨自佔用的總內存，不會和其它進程共享。當進程銷毀時，它們（特別是Private Dirty）佔用的內存會重新釋放回系統。Dirty內存是已經被修改的內存頁，因此必須常駐內存（因為沒有swap）；Clean內存是已經映射持久文件使用的內存頁（例如正在被執行的代碼），因此一段時間不使用的話就可以置換出去。
ViewRootImpl
進程中活動的根視圖的數量。每個根視圖與一個窗口關聯，因此可以幫助確定涉及對話框和窗口的內存泄露。
AppContexts和Activities
當前駐留在進程中的Context和Activity對象的數量。可以很快的確認常見的由於靜態引用而不能被垃圾回收的泄露的 Activity對象。這些對象通常有很多其它相關聯的分配，因此這是追查大的內存泄露的很好辦法。
注意：View 和 Drawable 對象也持有所在Activity的引用，因此，持有View 或 Drawable 對象也可能會導致應用Activity泄露。
獲取堆轉儲
堆轉儲是應用堆中所有對象的快照，以二進制文件HPROF的形式存儲。應用堆轉儲提供了應用堆的整體狀態，因此在查看堆更新的同時，可以跟蹤可能已經確認的問題。
檢索堆轉儲：
1.打開Device Monitor。
從<sdk>/tools/路徑下載入monitor工具。
2.在DDMS窗口，從左側面板選擇應用進程。
3.點擊Dump HPROF file，顯示見圖3。
4.在彈出的窗口中，命名HPROF文件，選擇存放位置，然後點擊Save。

圖3.Device Monitor工具顯示了[1] Dump HPROF file按鈕。
如果需要能更精確定位問題的堆轉儲，可以在應用代碼中調用mpHprofData()來生成堆轉儲。
堆轉儲的格式基本相同，但與Java HPROF文件不完全相同。Android堆轉儲的主要不同是由於很多的內存分配是在Zygote進程中。但是由於Zygote的內存分配是所有應用進程共享的，這些對分析應用堆沒什麼關系。
為了分析堆轉儲，你需要像jhat或Eclipse內存分析工具(MAT)一樣的標准工具。當然，第一步需要做的是把HPROF文件從Android的文件格式轉換成J2SE HRPOF的文件格式。可以使用<sdk>/platform-tools/路徑下的hprof-conv工具來轉換。hprof-conv的使用很簡單，只要帶上兩個參數就可以：原始的HPROF文件和轉換後的HPROF文件的存放位置。例如：

Java

1

hprof-conv heap-original.hprof heap-converted.hprof

注意：如果使用的是集成在Eclipse中的DDMS，那麼就不需要再執行HPROF轉換操作——默認已經轉換過了。
現在就可以在MAT中載入轉換過的HPROF文件了，或者是在可以解析J2SE HPROF格式的其它堆分析工具中載入。
分析應用堆時，應該查找由下導致的內存泄露：
對Activity、Context、View、Drawable的長期引用，以及其它可能持有Activity或Context容器引用的對象
非靜態內部類（例如持有Activity實例的Runnable）
不必要的長期持有對象的緩存
使用Eclipse內存分析工具
Eclipse內存分析工具（MAT）是一個可以分析堆轉儲的工具。它是一個功能相當強大的工具，功能遠遠超過這篇文檔的介紹，這里只是一些入門的介紹。

在MAT中打開類型轉換過的HPROF文件，在總覽界面會看到一張餅狀圖，它展示了佔用堆的最大對象。在圖表下面是幾個功能的鏈接：
Histogram view顯示所有類的列表和每個類有多少實例。
正常來說類的實例的數量應該是確定的，可以用這個視圖找到額外的類的實例。例如，一個常見的源碼泄露就是Activity類有額外的實例，而正確的是在同一時間應該只有一個實例。要找到特定類的實例，在列表頂部的<Regex>域中輸入類名查找。
當一個類有太多的實例時，右擊選擇List objects>with incoming references。在顯示的列表中，通過右擊選擇Path To GC Roots> exclude weak references來確定保留的實例。
Dominator tree是按照保留堆大小來顯示的對象列表。
應該注意的是那些保留的部分堆大小粗略等於通過GC logs、heap updates或allocation tracker觀察到的泄露大小的對象。
當看到可疑項時，右擊選擇Path To GC Roots>exclude weak references。打開新的標簽頁，標簽頁中列出了可疑泄露的對象的引用。
注意：在靠近餅狀圖中大塊堆的頂部，大部分應用會顯示Resources的實例，但這通常只是因為在應用使用了很多res/路徑下的資源。

圖4.MAT顯示了Histogram view和搜索」MainActivity」的結果。
想要獲得更多關於MAT的信息，請觀看2011年Google I/O大會的演講–《Android 應用內存管理》（Memory management for Android apps），在大約21:10 的時候有關於MAT的實戰演講。也可以參考文檔《Eclipse 內存分析文檔》（Eclipse Memory Analyzer documentation）。
對比堆轉儲
為了查看內存分配的變化，比較不同時間點應用的堆狀態是很有用的方法。對比兩個堆轉儲可以使用MAT：
1.按照上面描述得到兩個HPROF文件，具體查看獲取堆轉儲章節。
2.在MAT中打開第一個HPROF文件（File>Open Heap Dump）。
3.在Navigation History視圖（如果不可見，選擇Window>Navigation History），右擊Histogram，選擇Add to Comp are Basket。
4.打開第二個HRPOF文件，重復步驟2和3。
5.切換到Compare Basket視圖，點擊Compare the Results（在視圖右上角的紅色「！」圖標）。
觸發內存泄露
使用上述描述工具的同時，還應該對應用代碼做壓力測試來嘗試復現內存泄露。一個檢查應用潛在內存泄露的方法，就是在檢查堆之前先運行一會。泄露會慢慢達到分配堆的大小的上限值。當然，泄露越小，就要運行應用越長的時間來復現。
也可以使用下面的方法來觸發內存泄露：
1.在不同Activity狀態時，重復做橫豎屏切換操作。旋轉屏幕可能導致應用泄露 Activity、Context 或 View對象，因為系統會重新創建 Activity，如果應用在其它地方持有這些對象的引用，那麼系統就不能回收它們。
2.在不同Activity狀態時，做切換應用操作（切換到主屏幕，然後回到應用中）。
提示：也可以使用monkey測試來執行上述步驟。想要獲得更多運行 monkey 測試的信息，請查閱 monkeyrunner 文檔。

❻ 如何禁用win7的ASLR

一些原來XP下有的，不過不能很好的發揮作用。這些機制包括/GS安全編譯選項、SafeSEH、SEHOP，還有最重要的兩個ASLR和DEP的結合。

❼ framework3.0.exe是什麼意思

是一個新的Windows編程框架 微軟今天發布了.NET Framework 3.5第一個SP服務包的最終版。這是一個累積更新，包含很多基於.NET Framework 2.0、3.0和3.5不斷生成的新功能，此外還包括.NET Framework 2.0 SP2和.NET Framework 3.0 SP2累積更新，支持x86、x64、IA64三種架構。.NET Framework 3.5 SP1集成了此前發布的三十個相關Hotfix熱修復補丁，同時還引入了不少新特性和改進：1.ASP.NET動態數據，它提供了豐富的框架，從而使用戶可以快速進行數據驅動的開發，而無需編寫代碼；ASP.NET AJA 的一項新增功能，對管理瀏覽器歷史記錄提供了支持（支持後退按鈕）。有關更多信息，請參見ASP.NET和Web開發中的新增功能。2.對公共語言運行時的核心改進包括：改進了.NET Framework本機映像的布局、選擇不再對完全受信任的程序集進行強名稱驗證、提高了應用程序啟動性能、改進了生成的代碼以縮短端對端應用程序執行時間、選擇在ASLR（地址空間布局隨機化）模式下運行託管代碼（如果操作系統支持）。此外，從網路共享打開的託管應用程序在完全受信任環境下運行時與本機應用程序具有相同的行為。3.提高了Windows Presentation Foundation的性能，包括縮短了啟動時間，提高了與點陣圖效果有關的性能。WPF的其他新增功能包括：改善了對業務線應用程序、本機初始屏幕、DirectX 像素著色器的支持，並且新增了WebBrowser控制項。4.ClickOnce應用程序發行者可以決定在適當情況下不進行簽名和加密，開發人員可以編程方式安裝ClickOnce應用程序以顯示自定義署名，並且ClickOnce錯誤對話框支持鏈接到Web上應用程序特定的支持網站

❽ Google與微軟互懟，看看誰的瀏覽器沙箱更安全

前言
Google安全團隊Project Zero曾多次揭露微軟產品的安全漏洞，有幾次更在微軟修補前即公布，惹來微軟的不滿。雙方曾為此隔空交戰，微軟在10月18號也揭露了Chrome瀏覽器漏洞，並指責其沙箱安全性不足，修補政策無法有效防止黑客攻擊。
下面就讓我具體分析一下此次事件，看看微軟說的有沒有道理。讓我先從Chrome開始，看看Chrome是如何阻止一個RCE漏洞的，然後進一步探討是否有強大的沙箱模式足以使瀏覽器達到最安全的狀態。
通過取證分析，我發現了Chrome所包含的以下漏洞：
1.CVE-2017-5121漏洞表明在Chrome中有RCE漏洞；
2.Chrome缺乏預防RCE漏洞的技術，這意味著從發現漏洞到使用漏洞的時間會很短；
3.在Chrome沙箱內進行的幾次安全檢查表明，RCE能夠繞過同源策略（SOP），讓攻擊者訪問受害者的在線服務(如電子郵件、文檔和銀行會話)並保存登錄憑據；
4.由於Chrome的漏洞處理流程是先向用戶公開披露漏洞細節，所以很可能使得漏洞在修復之前被濫用。
發現並利用一個RCE漏洞
要發現漏洞，就要首先找到一個異常現象。通常，我們都會找到內存漏洞，如緩沖區溢出或UAF漏洞來來實現此目的。對瀏覽器的攻擊方法多種多樣，包括V8 JavaScript引擎編譯、Blink DOM引擎和pdfium PDF渲染器等，其中V8編譯是本文的重點。
本文所使用的CVE-2017-5121漏洞就是微軟使用基於Azure的漏洞檢查工具ExprGen發現的。ExprGen是通過監測Chrome瀏覽器所使用的V8 JavaScript引擎，從而發現的CVE-2017-5121。
譯者註：Google在2014將其V8JavaScript 解析引擎移到Github地址是：https://github.com/v8/v8。****V8是Google發布的開源 JavaScript引擎，採用C++ 編寫，在Google的Chrome瀏覽器中被使用。V8 引擎可以獨立運行，也可以用來嵌入到C++應用程序中執行。
識別漏洞
與手動審查代碼相比，基於Azure的自動化模糊檢測的缺點就是不能很快地分析出漏洞發生的原因。
由於模糊檢測技術經常產生大量復雜的代碼片段，所以在使用ExprGen檢測時，首先要將測試樣本的代碼進行精簡，只留下一些能夠識別的代碼。
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
當使用D8運行此代碼時，V8的獨立可執行版本由git標簽6.1.534.32構建，我們會遇到崩潰：
這段代碼的任務就是創建一個奇怪的結構化對象，然後設置一些欄位。雖然從理論上講，這不應該引發任何奇怪的行為，但實際上卻出現了一些運行結果。當使用D8運行這段代碼運行時，發現V8的獨立可執行版本是由git標簽6.1.534.32構建，此時會出現一次崩潰（如下圖）。
譯者註：如果你想了解如何使用D8分析javascript被V8引擎優化，請點此鏈接。
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
由上圖可以看出，崩潰發生的地址是0x000002d168004f14，因此我可以斷定該崩潰是不會發生在靜態模塊中的。因此，它必須是由V8的just-in-time(JIT)編譯器動態生成的。還能看到，崩潰發生是因為rax寄存器是零。
乍一看，這看起來像空引用異常（null dereference bug），如果是這樣的話就沒有什麼可講的了，因為這些異常通常不是可利用的，因為目前的操作系統會禁止零虛擬地址（zero virtual address）的映射。
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
我可以從上圖的代碼中發現兩個有用的線索：
首先,可以注意到崩潰發生在一個函數調用之前，該函數看起來像一個JavaScript函數調度器存根，這主要是由於v8::internal::Builtin_FunctionPrototypeToString的地址被載入到該調用之前的一個寄存器中。看看位於0x000002d167e84500的函數代碼，我發現地址0x000002d167e8455f確實包含一個調用rbx指令，這似乎證實了我的懷疑。
調用Builtin_FunctionPrototypeToString很有趣，因為這是Object.toString方法的實現。這似乎表明崩潰發生在func0 Javascript函數的JIT編譯器中。
其次，在崩潰時寄存器rax中包含的零值是從內存中載入的。這個過程看起來像是原本應該被載入的值被傳遞給作為參數的toString函數調用，並且是從[rdi + 0x18]載入的，以下就是內存載入的部分代碼。
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
以上代碼並沒有包含什麼有價值的信息，因為大多數值都是指針。但是，分析指針的來源卻很有用，因為它可以幫助我弄清楚為什麼這個值一開始就為零。使用WinDbg最新公布的「時間旅程調試（TTD）」 功能，我可以在該位置上放置一個內存寫入斷點(baw 8 0000025e ' a6845dd0)，然後在函數的起始處放置一個執行斷點，最後重新反過來進行跟蹤(g -)。
有趣的是，放置的內存寫入斷點並不會被觸發，這意味著這個內存數據不會在這個函數中被初始化，或者至少在使用之前不會被初始化。但如果我對測試樣本進行一些處理，例如把o.b.bc.bca.bcab = 0;替換成o.b.bc.bca.bcab = 0xbadc0de;，然後就可以發現崩潰值源自於內存區域的變化:
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
由上圖可以看到， 0xbadc0de常數值最終出現在內存區域中。盡管這並沒有證明什麼，但卻似乎表明，這個內存區域被jit編譯的函數使用過，用來存儲局部變數，因為開始處的代碼看起來像是前面被傳遞給Object.toString作為參數的載入值。
結合TTD確認該內存槽未被該功能初始化的事實，可能的解釋是JIT編譯器無法發出將初始化表示用於訪問o.b.ba.bab欄位的對象成員的指針代碼。
為了證實我的推斷，我可以用-trace-turbo和-trace-turbo-graph參數在D8中運行測試樣本。這樣，D8就會輸出有關TurboFan，V8的JIT編譯器如何構建和優化相關代碼的信息。Javascript 引擎 V8採用的是新的引擎：TurboFan 和 Ignition，其中 Turbofan 是新的優化編譯器，而 Ignition 則是新的解釋器。
TurboFan的工作原理是將各個階段的優化信息都轉化成對象映射圖，如下圖所示。
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
可以看出優化器將func0嵌入到無限循環中，然後拉出第一個循環進行迭代。這些信息有助於了解這些功能塊之間如何相互關聯。然而，用映射圖進行表示的缺點就是無法表示對應於載入函數調用參數的節點，以及局部變數的初始化。
幸運的是，我們可以使用turbolizer來顯示出這些內容。關注第二個Object.toString調用，我可以看到參數的來源，以及它被分配和初始化的位置：
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
在優化流程的階段，代碼看起來完全合理：
1.分配存儲塊以存儲局部對象o.b.ba（節點235），並且其欄位baa和bab被初始化；
2.分配存儲塊以存儲局部對象o.b（節點259），並且其欄位都被初始化，其中ba專門用對前一個o.b.ba分配的引用來初始化；
3.分配存儲塊以存儲局部對象o（節點303），並且其欄位都被初始化；
4.局部對象o的欄位b被具有對象o.b（節點185）的引用覆蓋；
5.局部對象欄位o.b.ba.bab被載入（節點199,209和212）；
6.調用Object.toString方法，將o.b.ba.bab作為第一個參數傳遞。
不過，優化過程中編譯的代碼不應該顯示未初始化的局部變數行為，所以我可以假設這chrome漏洞發生的根本原因。話雖如此，這只是我的一個假設。查看分別被載入到o.b.ba和o.b.ba.bab的節點209和212，它們被用作函數調用參數，如下圖，我可以在偏移量+ 24和+ 32處看到被反匯編過的崩潰代碼。
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
0x17和0x1f分別為23和31，考慮到V8標簽的值可以區分實際對象與內聯整數（SMI），可以進行這樣的推測：如果一個表示JavaScript變數的值具有最低有效位設置，則被視為指向對象的指針，否則就是SMI。因此，在取消引用（dereferencing）之前，可以使用V8代碼進行優化，減去一個JavaScript對象的偏移量。
不過到目前我還是沒有找出chrome漏洞的原因，所以我會繼續進行優化以找到原因。之後我進行了逃逸分析(Escape Analysis) ，分析試圖如下所示。
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
可以看出，有兩個顯著的不同:
1.代碼不需要從o載入到o.b，被優化後直接引用o.b，我想可能是因為該欄位的值從未更改過；
2.代碼不再初始化o.b.ba，從上圖中可以看出，turbolizer輸出了節點264，這意味著它不再是實時的，因此不會被嵌入到最終的代碼中。
此時，查看所有的活動節點似乎都確認這個欄位不會再被初始化了。不過為了保險起見，我還是在這個帶有–no-turbo-escape標志的測試樣本上運行d8，以跳過此優化階段。結果我發現d8不再崩潰，所以可以確定這就是漏洞的真正原因。其實， Google已在v8 6.1中完全禁用了逃逸分析階段，只有在v8 6.2中才會發生逃逸分析。
現在我已經掌握了該漏洞的所有信息，不過為了深度驗證此漏洞，我還要想辦法利用它，看看它是不是一個攻擊力很大的漏洞，不過這完全取決於我控制未初始化的內存插槽的能力。
獲取泄漏信息
此時，利用漏洞的最簡單的方法是對樣本進行簡單地處理。例如，可以從未初始化的指針中更改正在載入的欄位類型，看看會出現什麼反應：
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
其結果是，該欄位現在直接被載入為一個FLOAT 數據類型，而不是一個對象指針或SMI:
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
同樣，我可以嘗試在對象中添加更多欄位:
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
運行以上的代碼段，可以得到以下崩潰：
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
這很有趣，因為它看起來像是將欄位添加到經過對象修改的偏移量中，其中該偏移量的位置位於被載入的對象欄位中。如果你感興趣，可以做個數學運算，你會看到(0x67 – 0x1f)/ 8 = 9，這恰好是我從o.b.ba.bab中添加的欄位數量。這同樣適用於從rbx載入的新偏移量。
經過對測試樣本進行更多的操作後，我可以確認，即使這些欄位沒有被初始化，我還是能對未初始化的指針載入的偏移量進行控制。現在，就讓我檢測一下，看看是否可以將任意的數據放到這個內存區域中發生反應。使用0xbadc0de進行的早期測試似乎肯定了我的檢測，不過每個測試樣本的每次運行所檢測出的偏移量都不一樣。通常情況下，我會利用噴灑數值（spray value）的方式來解決這些問題。其原理是這樣的：如果我不能准確地將目標鎖定到給定的位置，那我就可以讓目標范圍擴大。在實踐中，我經常使用內嵌數組（inline array）來擴大數值范圍。
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
發生的故障轉儲（crash mp）如下所示：
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
可以看出，崩潰與以前基本相同，但如果我查看來自內存的未初始化數據，你會發現如下的情況。
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
在r11的偏移位置處，我可以看到一大塊由任意腳本控制的值。將這個發現與之前的偏移量相結合進行分析，我可以得出更靠譜的結論。
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
由上圖可以看出，我取消了任意地址的float值:
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
當然，這是非常強大的，因為它會立即導致任意讀取原語。但不幸的是，沒有初始信息泄漏的任意讀取原語在實踐中並不是很有用的，因為我需要知道要讀取哪些地址才能使用它。
變數v可以替換成任何我想要的東西，比如，我可以用一個對象替換它，然後讀取它的內部欄位。再比如，我可以使用自定義的回調來替換對Object.toString()的調用，並將V替換為DataView對象，從而讀取該對象的備份存儲地址，這就為我提供了一種找到完全由腳本控制的數據的方法。
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
以上就是返回的代碼（以ASLR為模型）：
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
使用WinDbg，就可以驗證這是我的緩沖區的後備存儲器。
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
由於這是一個非常強大的原語，我可以使用它來泄漏任何來自對象的欄位，以及任何JavaScript對象的地址，因為這些對象有時會存儲為其他對象中的欄位。
構建任意的讀/寫原語
能夠在已知地址處放置任意數據，就意味著我可以構建一個更強大的原語，因為此時我已經具備了創建任意JavaScript對象的能力。只需改變從float讀取到的對象的欄位類型，我就可以從內存中的任何地方讀取對象指針，比如已知地址的緩沖區。我可以使用WinDbg在已知的地址(上面發現的原語)中使用以下命令來進行測試:
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
這將在我的任意對象指針的載入位置放置一個表示整數0xbadc0de的SMI，由於我沒有設置最低有效位，它將被V8解釋為內聯整數：
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
正常情況下，V8會列印以下輸出：
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
鑒於此，我就可以創建任意對象，比如，我可以通過創建假的DataView和ArrayBuffer對象來組合一個我使用起來很方便的任意讀/寫原語。現在，我會再次使用WinDbg將我的假對象數據放在已知位置。
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
然後我會用以下JavaScript進行測試：
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
如預期的那樣，調用DataView.prototype.setUint32會觸發崩潰，因為調用會嘗試將0xdeadcafe值寫入0x00000badbeefc0de地址。
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
可以看出，數據寫入或讀取的地址被控制了，該問題只是修改通過WinDbg填充的obj.arraybuffer.backing_store插槽所出現的問題之一。因為在實際的漏洞中，內存將成為真正的ArrayBuffer對象的後備存儲器的一部分，要實現這點很容易，例如，寫入如下所示的原語。
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
這樣，我就可以在JavaScript的Chrome渲染程序中可准確地讀寫任意內存位置。
實現任意代碼執行
只要有任意讀/寫原語，就可以很容易地在Chrome渲染程序中實現代碼執行。由於V8會將其JIT代碼頁分配給讀寫執行(RWX)許可權，這意味著可以通過定位一個JIT代碼頁，然後覆蓋該頁面，最後通過調用來完成代碼執行。在實際操作過程中，可以通過使用我的信息泄漏來定位JavaScript函數對象的地址並讀取其函數entrypoint欄位來實現。一旦我將代碼放在了入口點，就可以調用JavaScript函數來執行代碼。
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
值得注意的是，即使V8沒有使用RWX頁面，由於缺乏對控制流程的完整性檢查，仍然很容易觸發返向導向編程（ROP）鏈的執行。如果發生這種情況，可以通過重寫JavaScript函數對象的entrypoint欄位來指向所需的gadget，然後進行函數調用。
不過，這些技術都不能直接用於具有CFG和ACG功能的Microsoft Edge。在Windows 10 Creators Update中引入的ACG會執行嚴格的數據執行保護（DEP），並將JIT編譯器移動到外部進程。這就形成了一個強大的防禦，即攻擊者在不破壞JIT進程的情況下，是不能重寫可執行代碼的，這就需要發現和開發其它的漏洞。
其次，CFG保證了間接調用站點只能跳轉到某一組函數，這意味著該函授不能用於直接啟動ROP執行。另外， win10 creators update還引入了CFG導出抑制，通過將大部分導出的函數從有效的目標集合中刪除，從而大大減少了有效的CFG間接調用目標集，所有這些緩解措施都使得黑客很難利用Microsoft Edge中的RCE漏洞。
RCE漏洞的危險
Chrome採用多進程模式，涉及到多種流程類型，比如瀏覽器進程，GPU進程和渲染器進程。
每個渲染器都會負責解析和解釋對應網頁的的HTML，JavaScript等。沙箱模型使得這些進程只能訪問其需要的功能。因此，我無法通過渲染器中對受害者的系統進行攻擊。
如此一來，我就要考慮攻擊者有沒有可能使用了其它的漏洞完成攻擊。雖然大多數選項卡的進程中都是進行單獨隔離的，但還是有些特殊情況，例如，如果在bing.com上使用JavaScript開發者控制台（可以通過按F12打開該控制台）來運行window.open（'https://microsoft.com'），則會打開一個新的選項卡，但新的選項卡通常會與原始標簽的進程完全相同。這可以通過使用Chrome的內部任務管理器來看到，你可以通過按Shift + Esc來打開它。
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
Google與微軟互懟，看看誰的瀏覽器沙箱更安全？
這是一個有趣的觀察，因為它表明渲染器進程沒有被鎖定到任何一個來源。這意味著在渲染器進程中實現任意代碼執行就可以使攻擊者訪問其他來源的進程。雖然攻擊者以這種方式繞過同源策略（SOP）的可能性並不大，但如果一旦發生，則後果不堪設想：
1.攻擊者可以通過劫持PasswordAutofillAgent界面從任何網站竊取用戶保存的密碼；
2.攻擊者可以將任意JavaScript注入任何頁面，例如通過劫持 blink::ClassicScript::RunScript 的方法；
3.攻擊者可以在用戶沒有注意的情況下導航到後台的任何網站，例如，通過創建隱藏的彈出式窗口。因為許多用戶交互檢查是發生在渲染器進程中的，無法讓瀏覽器進行進程驗證。這樣，類似ChromeContentRendererClient:AllowPopup的進程就會被劫持。這樣在不需要用戶交互的情況下, 攻擊者就可以隱藏新的窗口。他們還可以在關閉的時候繼續打開新的彈出窗口，例如，通過連接到onbeforeunload窗口事件。
這種攻擊更好地研究並實施了渲染器和瀏覽器進程如何相互通信並直接模擬相關消息，但這表明這種攻擊可以在有限的努力下實現。雖然雙重身份驗證的民主化減輕了密碼盜竊的危險，但是由於可以讓攻擊者在已經登錄的網站上欺騙用戶的身份，所以不可認為雙重認證就是絕對可靠的。
這表明只要在渲染器和瀏覽器進程的通信中做點文章，即使用戶採用了雙因素身份驗證，攻擊者還是能夠達到盜取賬號的目的的。
總結
客觀地講，Google與微軟互懟的結果，會讓普通的用戶受益，因為每個瀏覽器都有其長板和短板，互相競爭的結果迫使它們不得不努力改善自己以吸引用戶。就Microsoft Edge而言，目前它正在繼續改進隔離技術，並使得任意代碼執行難以實現。就Google而言，Google正在開發一個網站隔離功能，一旦該功能實現，Chrome就可以通過保證任何給定的渲染器進程只能與單一來源進行交互，這樣Chrome就能輕松應對RCE攻擊。

❾ 如何從零開始寫一個簡單的操作系統

早先寫過一個玩具內核，現在正做操作系統課助教，帶一夥學弟學妹做這個事情。 假定題主對操作系統有一定的認識（被丟去裸考期末考試不會掛科）。 總體路線圖大約是這樣的： *以下內容全是干貨，試圖在不幹預題主自己的設計的條件下盡可能指出所有的大坑，此方案不能代替看書/讀論文/上課/看手冊等* 第一階段：早期規劃 1. 搞清楚自己打算寫一個內核幹啥：試著設計？練習實現？拿來實用的話打算跑什麼呢？打不打算跨平台？打算跨哪些平台，兼容到什麼程度？ 2. interface大概會長什麼樣？給用戶空間提供哪些服務？（並不一定要和現有系統兼容或者怎麼樣） 3. 想怎麼樣boot？兼容一個現有bootloader還是自己寫一個？內核被load的時候是什麼格式？ 第二階段：方案設計 4. 選個架構吧，推薦IA32或者ARMv7A之類的 5. 找到各種手冊翻看一下，腦內構思一下內核里各種機制該用什麼方案實現 6. 選個目標設備吧，qemu可以玩玩但是內核都寫了，還是上個設備跑一跑比較好。（如果你打算在樹莓派上做的話下一步你會比較郁悶） 7. 這個設備的啟動流程怎麼樣，和之前的想法有沒有沖突？ 8. 找到各種手冊看一下，之前想好的實現方案有沒有坑？時鍾、中斷、DMA之類的，大概怎麼搞，心裡要有數了。 9. 想不想要JTAG之類的調試方案？有沒有？方不方便？ 10. 提前組織一下模塊劃分、代碼結構、編譯管理方案等。 第三階段：初步實施 11. 選好之後就把設備買下吧，需要的SD卡啦電源啦都買下，按照noobs' kit之類的東西試試好不好用 12. 准備工具鏈。在linux上你需要gcc和binutils。libgcc要不要加？不加的話有什麼坑？（CortexA9沒有硬體整數除法我說的就是你）怎麼處理？ 13. 編寫字元輸出驅動，不管是UART還是IA32的默認控制台或者是什麼的。 14. 編寫Hello world並作為最簡單的內核或者bootloader運行。 15. （如果自己寫bootloader）讀啟動介質的驅動和你想load的內核格式的支持代碼應該寫出來了。內核load到哪裡去？內核想要load到非常奇怪的地址（比如設備區或者和bootloader重疊）怎麼辦？ 16. 平台初始化要做一做了吧？頁表准備一下該開MMU了吧？說道MMU就要說緩存，目標架構上緩存需要內核做哪些維護？如何啟用？設備區怎麼處理？（MIPS沒有硬體table walker這種事情也要在這里處理掉） 17. 要不要跳虛擬地址？虛擬地址空間怎麼劃分？ 第四階段：各種內核組件 18. 一套完整的線性映射能不能容納？不能的話怎麼辦？類似vmalloc和ioremap的機制，要實現的話需要提前規劃好。 19. 物理內存怎麼管理？連續頁的分配和回收使用怎樣的演算法？ 20. 任意大小內存塊的分配和釋放要怎麼處理？有沒有什麼會要求非常大塊的對齊（ARM的一級頁表你別跑），怎麼辦？ 21. 虛擬地址空間怎麼管理？用戶空間的和內核自己的虛擬地址空間管理方案可不一樣的。 22. 中斷和出錯該怎麼處理？向量表怎麼搞？中斷路由怎麼設置？ 23. 系統調用使用怎樣的格式？中斷信息獲取之類的雜務該怎麼做？ 24. 上下文保存和恢復應該怎麼做？保存哪些內容？ 25. 各種驅動程序怎樣部署和運行？靜態攜帶還是動態注冊？有沒有打算做內核模塊機制？怎麼做？驅動的特權級要不要低於內核？怎麼實現？驅動要不要參與未來的調度？和用戶空間比有什麼特別的？ 26. 進程和線程打算怎樣實現？依靠用戶空間的庫來調度還是像linux這樣做線程和線程組？進程描述符長什麼樣？ 27. 時鍾怎麼用？時鍾比較器是共享的還是獨享的？ 28. 調度演算法是怎樣的？有沒有什麼好處壞處？ 29. 自旋鎖該怎麼實現？有哪些使用要求？ 30. 內核提供哪些同步機制？怎麼實現？ 31. 超過一個CPU的話，其他核心怎樣喚醒？喚醒之後哪些初始化需要另做？ 32. 各種系統調用內部該如何實現？ 第五階段：和用戶態的配合 33. 怎樣把提供的系統調用包成一個C庫一類的東西？ 34. 做哪些文件系統支持？內核要不要導出虛擬文件系統？控制台輸入輸出算不算文件？ 第六階段：可選內核組件 35. 管道、共享內存等IPC方案？ 36. 動態掛載和卸載文件系統？ 37. 前面提到過的內核模塊？ 38. kexec和kmp一類的機制？ 39. ASLR？運行禁止？其他一些被動安全機制？ 40. 隨機數生成器？ 41. 安全內存？處理器的加密解密部件？ 42. 缺頁和換頁？ 43. 區分一下用戶？組？密碼？shadow？ 44. 文件許可權？SUID/SGID？ 45. 用戶態的init差不多應該負擔一些責任了？ 46. 管理一下電源和頻率？idle的時候做點節能？ 47. 用文件/文件系統的方式和內核做一些交互？ 48. 網路？路由？名稱服務？防火牆？ 49. 動態的設備管理？熱插拔？ 50. （我想不出更多了）來點圖形界面？