PatchGuard （簡稱PG） 是微軟在x64體系下加入的內核哨兵，作用是檢測系統(tǒng)關鍵點是否被惡意篡改，也就是說，在x64下不能像X86下面那樣各種SSDT HOOK INLINE HOOK
了，同時以前的一些騷操作例如斷鏈隱藏進程，調試端口清零都不能做了，當然，內核界猛人輩出，看雪的老V就曾放出過win7 x64的過PG源碼，于是大家都樂呵了。好景不長
win10來了，早年的方法統(tǒng)統(tǒng)不能用了，網上也曾開源過一些pass win10的源碼，但都是靜態(tài)的（也就是修改內核文件，需要重啟電腦），意義不是很大。后來織夢論壇的大佬
另辟蹊徑，想到了動態(tài)過的辦法，并且把思路公開了，看雪的老V后來在這個思路的基礎上，進行了深入的研究，也開源了一部分代碼（偽碼），該思路一直能用到win10 1607上
我在研究了PG系統(tǒng)和老V的源碼后，在他的基礎上更進一步，能一路殺到1803，好吧 廢話有點多了，直接講重點吧。
PG在初始化的時候，會隨機將自己的PG代碼復制N分到非換葉內存里去，有時候是0 有時候是5，我最多一次抓到了五個，但不確定是不是五個。
前面的思路都和織夢老大，老V等人的一樣
貼代碼
PVOID LoadAndReadFile(WCHAR * szFileName)
第一步 將NT模塊載入內存
第二步 搜KEY （這部分代碼在GITHUB上有，我就不貼了，因為沒有得到作者授權）
第三步 掃BIGPOOL
PSYSTEM_BIGPOOL_INFORMATION pBigPoolInfo = (PSYSTEM_BIGPOOL_INFORMATION)ExAllocatePoolWithTag(NonPagedPool, sizeof(SYSTEM_BIGPOOL_INFORMATION), 'ttt');
ULONG64 ReturnLength = 0;
status = ZwQuerySystemInformation(SystemBigPoolInformation, pBigPoolInfo, sizeof(SYSTEM_BIGPOOL_INFORMATION), &ReturnLength);
BIGPOOL里 有分頁內存和非分頁內存
因為PG必須執(zhí)行在非分頁內存里，所以就不用掃分頁內存了
到這里 我和老V的思路都是一樣的，最大的區(qū)別是 bigpool會出現(xiàn)一種奇怪的現(xiàn)象，什么呢 就是系統(tǒng)PTE越界的問題，當你掃PG的代碼的時候，有時候會跳過兩個連續(xù)的頁面
大概意思就是 A 和B 頁面 是連在一起的，掃完A后，應該接著掃B，但是參考老V的代碼，會出現(xiàn)跳過B的情況，還有種情況就是要考慮頁面大小的問題 到底是4K的頁面 還是2MB的頁面 也要加入判斷
所以最后我果斷放棄了搜BIGPOOL
直接爆搜物理內存，攻擊PG流程的代碼 也能在前文說的那個網站上搜到，我也就不貼了。
所以，最終的解決方案就是
1.放棄掉BIGPOOL 直接搜物理內存
2.要判斷一下系統(tǒng)PTE的頁面大小
當然 這只是攻擊PG的思路，具體到代碼還是有很多騷操作和小技巧的，我就不細說了，有興趣的朋友可以谷歌搜索下PG1,2,3的分析文章，會對你有幫助的
然后據(jù)說在1803上 加入了新的守護體系 H-TV，但是好像我的代碼依舊能跑，該怎么鉤還是怎么鉤。
最長的一次掛了一夜沒藍屏
但是有個奇怪的BUG 就是在內存32G的機器上，會引發(fā)一個硬件異常，至今沒分析明白！蛋疼
1803也能鉤，只是PCHUNTER不支持1803 我就沒辦法展示了。
寫在最后，一般討論這樣的話題，都會引起紛爭，因為我也確實沒放什么干貨，我其實挺想開源的，但是這玩意不是我一個人搞出來的，見諒
全部思路來自織夢老大和看雪老V，我只是在他們的基礎上，解決了一些小問題。
一個半小時過去了 沒藍屏
| 
