Author： Crystal
2018/1/5
0x00：細節研究
細節一
ASLR和DEP
首先研究wifi芯片漏洞作爲突破口，是因爲手機對主應用處理器做的保護已經比較難實現攻擊了
細節二
由於對電源的考慮導致設備設計人員選擇應用 FullMAC WiFi 實現方式，這樣 WiFi 芯片是自行負責處理 PHY，MAC 和 MLME ，並自行傳輸準備好的內核驅動程序數據包，這也就是說 WiFi 芯片是會自行處理可能被攻擊者控制的數據輸入。
在選擇攻擊面的考慮時，還有一個因素影響了我們的選擇。在博通芯片上進行測試的時候，我們欣喜地發現，它不受 ASLR 保護，而整個 RAM 都有 RWX 許可——這意味着我們可以在內存中的任何地方進行讀，寫和運行代碼的操作！==但是在 Shannon 、聯發科技、以及高通的基帶中存在 DEP 機制的保護，所以相對而言，更難進行漏洞利用。 ==
這一點結合之前的研究難點來看，我們需要處理的部分是找到wifi芯片向內核驅動程序傳輸數據包的過程，以及傳輸完後怎麼在內核驅動中執行。這一點來看，確實需要wifi內核驅動相關的知識。
細節三
在不算特別詳盡的研究中，我們發現以下智能手機的型號使用的是博通的 WiFi 芯片：
部分三星 Galaxy 系列的 S3 至 S8
所有三星 Notes 3，Nexus 5, 6, 6X 和 6P
所有 iPhones 5 之後的型號
芯片的型號則是從 BCM4339 到 BCM4361型號。
芯片固件的逆向工程和調試相對簡單，因爲每次芯片重製後的主 OS 都將未加密的固件二進制程序加載到芯片的 RAM 中，由此，只是通過手機系統的簡單搜索就足以定位博通固件的地址。但如果在 Linux 內核上，這樣的路徑通常會在配置的變量 BCMDHD_FW_PATH 中定義。
我們之後又發現了另一件讓人高興的事情，固件上並不會對完整性進行檢驗，==也就是說攻擊者可以輕鬆地對原始固件進行修改，添加 hook 進行打印輸出調試或者其他行爲修改，甚至修改內核來調用我們自己的固件。我們在研究的過程中就經常地放置 hook 並觀察系統的行爲（更有趣的是系統的不正常行爲）。 ==
這一塊，調試wifi驅動，最簡單方式。給一點建議。開發驅動着手有可能會走很多彎路。
細節四
這個系統的奇怪之處在於，大部分代碼都是在 ROM 上運行的，大小爲 900 k。而後續的更新都是存放在 RAM 中的，也佔 900 k 的大小。在執行更新或修復的時候，在 RAM 中會有一個附加的 thunk 表，然後在執行的特點位置進行調用這個表。如果有錯誤需要進行修復，則可以對 thunk 表進行重定向指向新代碼。
這個問題之前在問題單裏也有提出，然後這次可以根據這個思路，再分析一下RAM固件。
細節五
將 BCM43xx 視爲 WiFi 片上系統（SoC）應該是正確的，因爲這裏有兩個不同的芯片在處理包數據。主處理器 Cortex-R4 在將收到的包數據交給 Linux 內核之前，會先處理 MAC 和 MLME 層的數據==；但使用專有博通處理器架構的單獨芯片則可處理 802.11 PHY 層。==SoC的另一個組件是應用處理器的接口：早期的博通芯片使用的是較慢的 SDIO 連接，而 BCM4358及更高版本使用的 PCIe。
這部分的話我們研究的是BCM4358
最有用的資源則是 VMG-1312 的源代碼，VMG-1312 也是使用博通芯片組的路由器，雖然這個產品早已被人們遺忘。儘管之前的 brcmsmac 驅動中包含博通開源使用在 Linux 上的代碼，但在 VMG-1312 中居然包含有博通專有的閉源代碼，可以看到代碼上標註了 “這是博通未公開的專有源代碼” 警示信息。顯而易見，這是博通代碼不小心混在 VMG-1312 源碼中錯誤公開了！
這些泄露的代碼片段包含我們在固件 blob 中找到的大部分功能。但這部分還是有些過時，沒有包含最新的 802.11協議的相關處理方法。但我們找到的這部分對於此次研究已經非常有用，主要的數據包處理功能並沒有發生大的變化。我們==通過將源代碼與固件進行比對，能夠快速地獲取數據包處理代碼部分的整體概念，==幫助我們尋找到值得關注的代碼區域，並將關注點移到下一個階段上——如何找到合適可用的漏洞。
這部分需要關注的是在研究固件的基礎上把數據包處理流程梳理出來。
0x01：細節研究
細節五：數據包處理流程
先找到固件中的漏洞位置，如下代碼所示，有幾個關鍵的數據幀標誌類型。根據數據幀的類型在 VMG-1312 的源代碼定位到處理這部分數據包的代碼。
frame_type = *(unsigned __int16 *)(arg + 8); // arg->frame_type
cfg = *(_DWORD *)(arg + 4); // arg->bsscfg
v4 = wlc;
ie = *(_DWORD *)(arg + 0xC); // arg->ie
current_wmm_ie = *(_BYTE **)(cfg + 0x354); // cfg->current_wmm_ie
if ( frame_type == 0x20 ) // FC_REASSOC_REQ = 0x20 重新關聯請求幀
goto LABEL_9;
if ( frame_type <= 0x20 )
{
if ( *(_WORD *)(arg + 8) )
{
if ( frame_type != 0x10 ) // FC_ASSOC_RESP = 0x10 //關聯幀
return 0;
goto LABEL_15;
}
...
...
...
if ( frame_type != 0x30 ) // FC_REASSOC_RESP = 0x30 重新關聯響應幀
{
if ( frame_type == 0x80 ) // FC_BEACON = 0x80 信標幀
{
v16 = **(_DWORD **)(*(_DWORD *)arg + 0x1C);
if ( *(_DWORD *)(*(_DWORD *)wlc + 0x34) )
...
...
...
總共定位到兩處位置一處應該是發送數據包的過程 在 1）首先發送探測請求幀
細節四：thunk表問題
應該是thunk技術的傳名調用。
root
google nexus 6p 7.0 root 參考：鏈接：http://bbs.gfan.com/android-8330379-1-1.html