哈哈，微軟的CE6簡直是大門洞開啊

最近通過看LocalAlloc的問題結合之前研究如何用AP去讀寫CE6的物理地址的過程，發現CE6的核心存在巨大安全隱患。
如果說CE5是蝸牛殼，那麼CE6就是雞蛋殼了，騷味動點腦筋，CE6的核心就能馬上被你控制，下面簡述幾個CE6設計上的敗筆。
敗筆1：KDataStuct位置固定
稍微瞭解一點wince的都知道這個結構體吧，這個結構體在wince初始化的最早期的時候會由OAL先去初始化放置於一個“kernel才有特權”的專屬地址，以CE6為例，它位於虛擬位址0xffffc800，此結構體放置大量關鍵核心資訊，此敗筆在於此地址固定，而且只需要得到“kernel特權”就可以訪問此結構體。
敗筆2：CE6的OAL和NK的global結構體
CE6和CE5最重要的區別之一就算OAL和kernel正式分家了，以前CE5因為OAL和Kernel打包成一個exe，外界很難進入和破壞裡面的連結關係。但是CE6為了把OAL和kernel.dll分開而又要考慮讓它們之間可以建立一些必要的聯絡，創造性的設計了兩個新結構體：_NKGLOBAL和_OEMGLOBAL（nkglobal.h/oemglobal.h）。在新的設計中，kernel只提供和平台無關的一些核心演算法，OAL只提供和平台相關的函數介面，kernel提供的API在被上層調用後如果需要訪問硬體就必須要透過oemglobal去調用oal的函數，反過來OAL需要做一些關鍵調用比如entercriticalsection的時候，又要依賴kernel提供的nkglobal來調用kernel的函數。但是如果這兩個結構體暴露到外部就非常危險，因為結構體上面的函數指標如果被篡改，那麼kernel和oal就會被牽著鼻子走了。
敗筆3：Kdatastruct結構體包含了oal和nk的global結構體
微軟為了方便啟動過程中oal找到nkglobal，把nkglobal和oalglobal的指標都掛在了Kdatastruct中，只要具有核心許可權的代碼都可以找到它們。
敗筆4：使用者態名存實無
雖然微軟規定了所有AP都是使用者態，但是AP卻可以自己掛載一個核心態的驅動，這個驅動可以作為內鬼去協助使用者態的AP做任何事情。通過ARMCE兄弟們前期的探索，我們已經知道，我們可以用一個AP去讀寫CE6的物理地址。

綜合上述敗筆，我們可以做如下想象：
1.我們先寫一個AP和一個傀儡核心態驅動，AP動態註冊和載入這個自己的核心驅動。
2.在核心態驅動裡面去fetch那個位於0xffffc800的Kdata結構體。
3.核心態驅動從Kdata結構體裡面拿到NKglobal和Oemglobal結構體
4.撰寫傀儡函數於核心態驅動
5.篡改oemglobal或者nkglobal的相關函數指標指向傀儡函數
6.傀儡函數提供資料給AP
這就實現了對CE6的一個簡單破*解。
哈哈，是不是很有意思啊，CE6大門洞開啊。

 

打個淺顯一點的比方，只針對實際應用，大體過程參考1樓。 比如你想監視M8上面的所有的kerneliocontrol的調用。 你可以這樣偷梁換柱。 用傀儡核心驅動找到pOemglobal->pfnOEMIoctl指標，先存下來。 然後自己實現一個傀儡OEMIoctl，介面要和kerneliocontrol一致，做的事情就是先得到調用參數記錄下來，然後再去call實際的pfnOEMIoctl指標。 然後把傀儡OEMIoctl的地址寫到pOemglobal->pfnOEMIoctl 萬事大吉了。