月底折騰目前這套黑蘋果，到現在開始有點心得，知道個中的懵逼跟難處，特意發一文給各位新手小白解惑。
CPU：
雖然AMD的CPU已經可以吃上黑果，但某些軟件，例如Adobe全家桶會出現各種閃退bug；對專業用戶來說依然不太推薦。
建議大家還是選擇英特爾的CPU，至少目前來說是這樣。
顯卡：
N卡自10.13.6之后就不再被蘋果支持了，即使支持也沒有視頻編解碼加速，完全不建議黑果使用。
A卡RX580/570免驅，但是RX580 2048SP需要刷成RX570才可以。目前比較合適的型號是新一代7nm的5500 5600 5700以及XT。
硬盤：
Mac原生支持NVME的固態硬盤，強烈推薦。SATA盤需要打補丁。
主板：
芯片組最好選Z390 Z370。
我的配置：
i9-9900k
技嘉Z390 Aorus Pro Wifi
迪蘭5700XT 公版
科賦16G 3200MHz 4條
OCZ RD400 500G NVME固態硬盤
浦科特M9PeG 1T NVME固態硬盤
當初黑蘋果時，除了EFI知道什么意思外，對其它都一頭霧水；到目前我依舊認為：專業名詞太多是黑蘋果的最大門檻。下面就來看看這幾個名詞的通俗解釋。
ACPI：給操作系統看的主板的說明書。告訴Mac OS顯卡在哪，CPU在哪，聲卡在哪。成功安裝之后可以通過提取ACPI來完善黑果。一般用戶大概了解就行了。
提取方法：使用Clover引導，在Clover引導界面按一下鍵盤上的F12，開機后就會在桌面看到ACPIOrigin文件夾里，里面就是這臺電腦的原始ACPI信息。
DSDT：如果我們提取到ACPI，里面會有一個DSDT，詳細寫明了硬件位置等信息；我們人類就是通過DSDT來知道硬件信息的。
SSDT：跟DSDT差不多，DSDT是全文，SSDT就是里面的一個章節，譬如說，顯卡的SSDT、聲卡的、CPU的等等；一般完善黑蘋果，我們會通過編輯SSDT來修改硬件信息。
左邊為原始SSDT，右邊為添加獨顯信息的SSDT
譬如上圖所示；左邊為原始的獨顯SSDT，其中的SB.PCI0.PEG0.PEGP就是我的獨顯地址；通過修改其中的條目，我們讓Mac OS把顯卡識別為w5700x，并成功驅動它。
修改SSDT算是黑蘋果中比較重要的完善方法。因為很多硬件Mac是不認的，我們就改名讓它能被系統識別。
不過，據現在黑蘋果的大神發現，OpenCore（OC）引導下修改SSDT是有風險的行為，就算老手也有翻車的可能。
EFI：無論Clover四葉草還是OpenCore都有有EFI，這個EFI就是撬動蘋果系統的鑰匙。配置相同的機器可以通用EFI。所以對小白和新手來說，依照大神的配置裝機，扒拉EFI是最容易上手的方法。
BIOS必須先設置
這幾個項目是必須設置好的，不然無法安裝。
選擇機型
選擇機型還是比較重要的，選擇不好有時會導致無法硬解，無法開機（往往選擇iMac較常見），無法加載蘋果電源管理之類的各種個樣的問題。
選擇機型的大方向應該這樣：有核顯的選iMac，沒有核顯的選擇iMac Pro。
如果選擇iMac，需要在BIOS里把核顯打開
另外推薦安裝的時候選擇iMac Pro，完成安裝后有需要再把機型設置為iMac。這樣安裝成功率會大些。
設置方法，在Clover Configuration的機型查找里選擇合適的機型，它會自動幫你填好所有信息。
最后推薦大家搜搜“黑果小兵”，他那里有吃黑果的實戰指南。這篇的目的其實就是讓大家比較順利地看懂他。
祝大家吃上自己的黑果果吧。
針對進程行為的監控需求，以往很多安全軟件都是采用的Hook技術攔截關鍵的系統調用，來實現對惡意軟件進程創建的攔截。但在x64架構下，系統內核做了很多安全檢測措施，特別是類似于KDP這樣的技術，使得Hook方法不再有效。為此OS推出了基于回調實現的行為監控方案。本文借助IDA逆向分析該技術的實現原理并給出了關鍵數據結構及調用鏈，通過雙機內核調試驗證了該數據結構以及調用鏈的正確性。
涉及到的內容如下：
1、內核對象及內核對象管理；
2、進程回調；
3、內核調試；
4、Windbg雙擊調試；
近年來，各種惡意軟件新變種層出不窮，攻擊方法、手段多種多樣，造成了巨大的經濟損失。作為防守的第一個環節就是能夠識別出惡意進程創建的動作，而進程創建監控技術是為了能夠讓安全軟件有機會攔截到此動作的技術。安全軟件根據匹配算法判斷是否準許該進程創建，以此達到保護用戶數據安全的目的。x86架構下的實現方案多為Hook技術，通過攔截內核中進程創建的關鍵API如nt!NtCreateProcess或nt!NtCreateProcessEx，通過堆棧來回溯到關鍵參數，如待創建進程的exe全路徑、父進程信息，然后根據獲取到的全路徑檢測exe磁盤文件，同時也可以分析進程鏈最終確定是否放行該動作。但這種技術方案存在一些缺陷，一方面其破壞了內核的完整性，導致系統的穩定性下降；另一方面，這些API很多都是未公開的，也就意味著需要通過逆向工程等技術手段來分析OS內核鏡像文件，定位到關鍵的API。但如果系統升級了，該API可能就不存在了，這也導致安全軟件的兼容性特別差；最重要的是各個安全廠家的實現方案不一樣，掛鉤的點也不同，很容易出現相互競爭的情況，極有可能會導致BSoD（Blue Screen of Death）。另一種傳統的基于特征碼的攔截方式，也同樣存在類似的問題。需要為每個子版本的系統關鍵API做逆向分析，取出特征碼，當系統更新或者打補丁，則需要再次逆向分析取出特征碼。工作量巨大，效率低下，適配性很低，如果沒有及時更新特征碼，很可能會使得監控失效，情況糟糕的時候會直接導致BSoD。為此，在x64架構下，內核一方面為了保護關鍵數據的完整性，另一方面也為了提高內核程序自身的穩定性，推出了諸如KDP（Kernel Data Protection）、PG等安全措施，使得傳統的 Hook技術失效；同時OS為了規范化安全相關信息的獲取，使得安全軟件能夠在內核可控的情況下提供安全服務，Windows系統層面提供了一種基于回調的方式來通知安全軟件注冊的內核回調例程。這種方式優點是方便高效，可移植性好，穩定性高，且各個安全廠商之間也不會出現競爭的關系。
本文基于逆向工程及內核調試技術，分析了該技術的具體實現及系統額外增加的數據檢測機制。借助逆向工具IDA靜態逆向分析了系統關鍵API的內部動作及具體的實現，相關的數據結構，得到該技術實際觸發的調用源以及整個調用鏈。借助VMWare搭建雙機調試環境，利用Windbg動態調試系統內核，查看系統中所涉及到的關鍵數據，并與PCHunter給出的數據做對比分析，驗證了分析結論的正確性。此外還通過對調用鏈中的關鍵函數下斷點，通過棧回溯技術，動態觀察了整個調用鏈及觸發時間。分析得到的關鍵數據結構和系統對數據做的檢測校驗算法可用于檢測病毒木馬等軟件惡意構造的表項，且還可以應用到安全廠商對抗惡意代碼時，自動構造表項來檢測系統行為，完全脫離系統提供的注冊卸載API。
根據微軟官方技術文檔MSDN上的說明，通過PsSetCreateProcessNotifyRoutine、PsSetCreateProcessNotifyRoutineEx和PsSetCreateProcessNotifyRoutineEx2這三API來安裝一個進程創建、退出通知回調例程，當有進程創建或者退出時，系統會回調參數中指定的函數。以PsSetCreateProcessNotifyRoutine為例子，基于IDA逆向分析該API的具體實現。如圖1所示，由圖可知，該API內部僅僅是簡單的調用另一個函數，其自身僅僅是一個stub，具體的實現在PspSetCreateProcessNotifyRoutine中，此函數的安裝回調例程的關鍵實現如圖所示。
調用ExAllocateCallBack，創建出了一個回調對象，并將pNotifyRoutine和bRemovel作為參數傳入，以初始化該回調對象，代碼如圖所示；其中pNotifyRoutine即是需要被回調的函數例程，此處的bRemovel為false，表示當前是安裝回調例程。
緊接著調用ExCompareExchangeCallBack將初始化好的CallBack對象添加到PspCreateProcessNotifyRoutine所維護的全局數組中。值得注意的是，ExCompareExchangeCallBack中在安裝回調例程時，對回調例程有一個特殊的操作如圖所示。
與0x0F做了或操作，等價于將低4位全部置1；若ExCompareExchangeCallBack執行失敗，則接著下一輪循環繼續執行。由圖2中第66行代碼可知，循環的最大次數是0x40次。如果一直失敗，可調用ExFreePoolWithTag釋放掉pCallBack所占用的內存，且返回0xC000000D錯誤碼。
然后根據v3的值判斷是通過上述三個API中的哪個安裝的回調，來更新相應的全局變量。其中PspCreateProcessNotifyRoutineExCount和PspCreateProcessNotifyRoutineCount分別記錄當前通過PsSetCreateProcessNotifyRoutineEx和PsSetCreateProcessNotifyRoutine安裝回調例程的個數。PspNotifyEnableMask用以表征當前數組中是否安裝了回調例程，該值在系統遍歷回調數組執行回調例程時，用以判斷數組是否為空，加快程序的執行效率。
除了能夠安裝回調例程，這三個API也能卸載指定的回調例程。以PsSetCreateProcessNotifyRoutine為例，分析其實現的關鍵部分，如圖所示。
通過一個while循環遍歷PspCreateProcessNotifyRoutine數組，調用ExReferenceCallBackBlock取出數組中的每一項，該API內部會做一些檢驗動作且對返回的數據也做了特殊處理，如圖所示。圖6中*pCallBackObj即是取出回調對象中的回調例程的函數地址，通過判斷其低4位是否為1來做一些數據的校驗，如17行所示。系統做這個處理也是起到保護作用，防止惡意構造數據填入表中，劫持正常的系統調用流程。此外，圖中第33行處的代碼，在將回調例程返回給父調用時，也將回調例程的低4位全部清零，否則返回的地址是錯誤的，調用立馬觸發CPU異常。
ExReferenceCallBackBlock成功返回后，調用ExGetCallBackBlockRoutine從返回的回調對象中取出回調例程，并判斷取出的是否為當前指定需要卸載的項，如果是則調用ExDereferenceCallBackBlock遞減引用計數，接著調用ExFreePoolWithTag釋放掉Callback所占用的內存。期間也會更新PspCreateProcessNotifyRoutineExCount或PspCreateProcessNotifyRoutineCount的值。根據源碼還可以得知，該數組總計64項，也即只能安裝64個回調例程。如果遍歷完數組的64項依舊沒有找到，則返回0xC000007A錯誤碼。
回調例程安裝完之后，如果有新的進程創建或退出，內核則便會遍歷該數組來執行其中安裝的每一項回調例程。通過IDA的交叉引用功能，可分析出內核其他地方對PspCreateProcessNotifyRoutine的交叉引用，如圖所示，
共計5個地方涉及到此變量。其中PspCallProcessNotifyRoutines是直接調用回調例程的函數，該函數的關鍵部分如圖所示。
通過while循環，遍歷PspCreateProcessNotifyRoutine數組中安裝的所有回調例程，依次執行。PspNotifyEnableMask & 2的操作即為判斷當前數組中是否安裝有回調例程，加快程序的執行效率，這個變量的值在PsSetCreateProcessNotifyRoutine中安裝回調例程時設置。bRemove & 2這個if分支，是用來判斷當前的回調例程是通過PsSetCreateProcessNotifyRoutine還是PsSetCreateProcessNotifyRoutineEx安裝，因為這兩個API安裝的回調例程的原型不同，在實際調用時傳入的參數也不同。兩者的回調例程原分別為：void PcreateProcessNotifyRoutine(HANDLE ParentId,HANDLE ProcessId,BOOLEAN Create)和void PcreateProcessNotifyRoutineEx(PEPROCESS Process,HANDLE ProcessId,PPS_CREATE_NOTIFY_INFO CreateInfo)。此外，圖8中IDA給出的偽C代碼RoutineFun((unsigned __int64)RoutineFun)明顯不對，因為回調例程的參數個數是3個，而IDA分析出的參數只有1個，顯然有問題。直接看下反匯編代碼即可得知，如圖所示，
根據x64下的調用約定可知，函數的前4個參數是通過rcx、rdx、r8和r9這四個寄存器傳遞，圖給出的正是回調例程的前三個參數，_guard_dispatch_icall內部會直接取rax的值調用過去，而rax的值正是ExGetCallBackBlockRoutine調用返回的回調例程函數地址。
上圖中的第二個涉及到PspCreateProcessNotifyRoutine數組的是PspEnumerateCallback函數，該函數是系統內部函數，沒有導出，其具體實現如圖所示。
該函數根據dwEnumType來判斷想要枚舉的是哪個數組，由代碼分析可知，系統內核維護了三個回調相關的數組，分別為鏡像加載回調數組，進程創建退出回調數組，線程創建退出數組。類似之前的函數校驗，這里也檢測了索引是否超過0x40，超過了則返回0，以示失敗。
上節分析了回調例程的直接調用上級函數，本節分析整個調用鏈，主要分析調用源及調用過程中涉及到的關鍵函數。根據IDA給出的交叉引用圖如圖所示。
涉及到的函數調用非常多，很多不相關的也被包含進來，不便于分析。經手動分析整理后的調用鏈，其鏈路中的關鍵API如圖所示。
虛線以上部分為用戶態程序，虛線以下為內核態程序，紅色標注的都是標準導出的API。根據圖12可知，當用戶態進程調用RtlCreateUserProcess、RtlCreateUserProcesersEx或RtlExitUserProcess時，內核都會去遍歷PspCreateProcessNotifyRoutine數組，依次執行回調例程，通知給驅動程序做相應的處理。驅動接管之后，可以做安全校驗處理，分析進程的父進程或者進一步分析進程鏈，此外還可以對即將被拉起的子進程做特征碼匹配，PE指紋識別，導入表檢測等防御手段。這種方式不需要去Hook任何API，也無需做特征碼定位等重復繁瑣的工作，完全基于系統提供的回調機制，且在Windows系統中都可以無縫銜接。且各個安全廠家之間也不存在相互競爭，大大縮小了系統藍屏的風險。圖12中NtCreateUserProcess調用PspInsertThread的原因是創建進程的API內部會創建該進程的主線程。將遍歷回調例程數組的工作統一到PspInsertThread中，由其去調用下層的PspCallProcessNotifyRoutines更為合理。
實驗環境如表1所示，借助于VMWare進行雙機調試。
Guest OS Build 10.0.16299.125
Host OS Build 10.0.17134.885
Windbg版本 10.0.17134.1
VMWare 14.1.1 build-7528167
PCHunter V1.56
在Windbg中觀察PspCreateProcessNotifyRoutine數組，共計14項有效數據，如下所示；
1: kd> dd PspCreateProcessNotifyRoutineCount l1
fffff802`151f4e78 00000009
1: kd> dd PspCreateProcessNotifyRoutineExCount l1
fffff802`151f4e7c 00000005
1: kd> dq PspCreateProcessNotifyRoutine l40
fffff802`14da2a80 ffffcc8b`d884b9bf ffffcc8b`d8d9c96f
fffff802`14da2a90 ffffcc8b`d939975f ffffcc8b`da00044f
fffff802`14da2aa0 ffffcc8b`d9bd382f ffffcc8b`da41e8df
fffff802`14da2ab0 ffffcc8b`da53815f ffffcc8b`da5ca8bf
fffff802`14da2ac0 ffffcc8b`dac5178f ffffcc8b`dbef624f
fffff802`14da2ad0 ffffcc8b`dce333af ffffcc8b`dcec67df
fffff802`14da2ae0 ffffcc8b`dc735def ffffcc8b`dcabd32f
拆解第一項，尋找其所對應的回調例程，如下:
1: kd> dq ffffcc8b`d884b9b0 l3
ffffcc8b`d884b9b0 00000000`00000020 fffff802`13fd6268
ffffcc8b`d884b9c0 00000000`00000000
由此可知，安裝的回調例程起始地址為fffff802`13fd6268，且還可知道Remove為0，即這個是已經安裝的。尋找該回調例程對應的驅動模塊，如下：
1: kd> u fffff802`13fd6268
360qpesv64+0x26268:
fffff802`13fd6268 mov qword ptr [rsp+08h],rbx
fffff802`13fd626d mov qword ptr [rsp+10h],rbp
fffff802`13fd6272 mov qword ptr [rsp+18h],rsi
fffff802`13fd6277 push rdi
1: kd> lmvm 360qpesv64
start end module name
fffff802`13fb0000 fffff802`14002000 360qpesv64
Loaded symbol image file: 360qpesv64.sys
Image path: 360qpesv64.sys
Image name: 360qpesv64.sys
Timestamp: Wed May 27 20:13:22 2020 (5ECF2C52)
CheckSum: 00054A2A
ImageSize: 00052000
可知該回調例程是360官方提供。借助PCHunter來對比下，其給出的數據如圖所示，
以表項的第14項為例，內容如下，
1: kd> dq ffffcc8b`dcabd320 l3
ffffcc8b`dcabd320 00000000`00000020 fffff802`13d795b4
ffffcc8b`dcabd330 00000000`00000006
1: kd> bp fffff802`13d795b4
1: kd> g
斷點命中，查看父進程相關信息，如下，
Breakpoint 0 hit
fffff802`13d795b4 48895c2408 mov qword ptr [rsp+8],rbx
1: kd> dt _EPROCESS @$proc -yn ImageFileName
nt!_EPROCESS
+0x450 ImageFileName : [15] "svchost.exe"
由此可知，是svchost.exe這個父進程創建或者銷毀了一個子進程，更具體的信息如下分析；查看下當前的上下文環境；
1: kd> r
rax=fffff80213d795b4 rbx=ffffcb8050526c80 rcx=ffffcc8bdd67e080
rdx=0000000000001f28 rsi=000000000000000d rdi=ffffcc8bdd67e080
rip=fffff80213d795b4 rsp=ffffcb8050526c38 rbp=ffffcb8050526ca9
r8=ffffcb8050526c80 r9=ffffcc8bdc735de0 r10=ffff9401cdcc2760
r11=0000000000000000 r12=0000000000000001 r13=0000000000000000
r14=ffffcc8bdcabd320 r15=fffff80214da2ae8
iopl=0 nv up ei pl zr na po nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00000246
根據x64的調用約定可知，rcx寄存器中存儲的是EPROCESS對象指針，該對象存儲的是即將被創建的子進程的相關信息，可以獲取到的作為身份識別或者安全檢測的關鍵信息如下：
1: kd> dt _EPROCESS ffffcc8bdd67e080 -yn ImageFile
ntdll!_EPROCESS
+0x448 ImageFilePointer : 0xffffcc8b`dc97c5c0 _FILE_OBJECT
+0x450 ImageFileName : [15] "UpdateAssistan"
1: kd> dt 0xffffcc8b`dc97c5c0 _FILE_OBJECT -yn FileName
ntdll!_FILE_OBJECT
+0x058 FileName : _UNICODE_STRING "\Windows\UpdateAssistant\UpdateAssistant.exe"
1: kd> .process /p ffffcc8bdd67e080; !peb 186ef07000
Implicit process is now ffffcc8b`dd67e080
.cache forcedecodeuser done
PEB at 000000186ef07000
CurrentDirectory: 'C:\Windows\system32\'
WindowTitle: 'C:\Windows\UpdateAssistant\UpdateAssistant.exe'
ImageFile: 'C:\Windows\UpdateAssistant\UpdateAssistant.exe'
CommandLine: 'C:\Windows\UpdateAssistant\UpdateAssistant.exe /ClientID Win10Upgrade:VNL:NHV19:{} /CalendarRun'
可以獲取到該進程的EXE路徑，創建時的命令行參數，父進程的PID等信息，這些足以用于安全軟件的檢測。
父進程的完整調用棧如下，
1: kd> k
# Child-SP RetAddr Call Site
00 ffffcb80`50526c38 fffff802`14ef4ae5 0xfffff802`13d795b4
01 ffffcb80`50526c40 fffff802`14ef752c nt!PspCallProcessNotifyRoutines+0x249
02 ffffcb80`50526d10 fffff802`14f2797b nt!PspInsertThread+0x5a4
03 ffffcb80`50526dd0 fffff802`14b79553 nt!NtCreateUserProcess+0x9c7
04 ffffcb80`50527a10 00007ffe`547d1654 nt!KiSystemServiceCopyEnd+0x13
05 0000002f`4b67d258 00007ffe`50b406df ntdll!NtCreateUserProcess+0x14
06 0000002f`4b67d260 00007ffe`50b3d013 KERNELBASE!CreateProcessInternalW+0x1b3f
07 0000002f`4b67dec0 00007ffe`5216ee0f KERNELBASE!CreateProcessAsUserW+0x63
08 0000002f`4b67df30 00007ffe`4ce0a136 KERNEL32!CreateProcessAsUserWStub+0x5f
09 0000002f`4b67dfa0 00007ffe`4ce0bdd9 UBPM!UbpmpLaunchAction+0xb36
0a 0000002f`4b67e280 00007ffe`4ce08ee0 UBPM!UbpmLaunchTaskExe+0x279
0b 0000002f`4b67e490 00007ffe`4ce10a86 UBPM!UbpmpLaunchOneTask+0x6c0
0c 0000002f`4b67e8f0 00007ffe`4ce0b8bc UBPM!UbpmpHandleGroupSid+0x236
0d 0000002f`4b67ea10 00007ffe`4ce0b78b UBPM!UbpmpLaunchExeAction+0xec
0e 0000002f`4b67eaf0 00007ffe`4ce0b5a3 UBPM!UbpmpTakeAction+0xeb
0f 0000002f`4b67eb50 00007ffe`4ce0b193 UBPM!UbpmpPerformTriggerActions+0x293
10 0000002f`4b67eca0 00007ffe`4ce1316c UBPM!UbpmpHandleTriggerArrived+0x563
11 0000002f`4b67ef50 00007ffe`508c32d0 UBPM!UbpmpRepetitionArrived+0x1c
12 0000002f`4b67ef90 00007ffe`508c3033 EventAggregation!EaiSignalAggregateEvent+0x16c
13 0000002f`4b67f060 00007ffe`508c27aa EventAggregation!EaiSignalCallback+0xe7
14 0000002f`4b67f140 00007ffe`508c253e EventAggregation!EaiProcessNotification+0x1aa
15 0000002f`4b67f270 00007ffe`508caef8 EventAggregation!WnfEventCallback+0x506
16 0000002f`4b67f3a0 00007ffe`5476769f EventAggregation!AggregateEventWnfCallback+0x38
17 0000002f`4b67f3f0 00007ffe`54767a51 ntdll!RtlpWnfWalkUserSubscriptionList+0x29b
18 0000002f`4b67f4e0 00007ffe`5476b510 ntdll!RtlpWnfProcessCurrentDescriptor+0x105
19 0000002f`4b67f560 00007ffe`54766b59 ntdll!RtlpWnfNotificationThread+0x80
1a 0000002f`4b67f5c0 00007ffe`54764b70 ntdll!TppExecuteWaitCallback+0xe1
1b 0000002f`4b67f600 00007ffe`52171fe4 ntdll!TppWorkerThread+0x8d0
1c 0000002f`4b67f990 00007ffe`5479ef91 KERNEL32!BaseThreadInitThunk+0x14
1d 0000002f`4b67f9c0 00000000`00000000 ntdll!RtlUserThreadStart+0x21
由于前四個參數是通過的寄存器傳遞的，所以無法直接通過棧來回溯到參數，但可以通過手動方式分析得到。分析ntdll!NtCreateUserProcess的調用父函數，其返回地址處的匯編代碼如下所示：
1: kd> ub 00007ffe`50b406df
KERNELBASE!CreateProcessInternalW+0x1b11:
00007ffe`50b406b1 488b842440040000 mov rax,qword ptr [rsp+440h]
00007ffe`50b406b9 4889442420 mov qword ptr [rsp+20h],rax
00007ffe`50b406be b800000002 mov eax,2000000h
00007ffe`50b406c3 448bc8 mov r9d,eax
00007ffe`50b406c6 448bc0 mov r8d,eax
00007ffe`50b406c9 488d942448010000 lea rdx,[rsp+148h]
00007ffe`50b406d1 488d8c24e0000000 lea rcx,[rsp+0E0h]
00007ffe`50b406d9 ff1521901600 call qword ptr [KERNELBASE!_imp_NtCreateUserProcess (00007ffe`50ca9700)]
可知，NtCreateUserProcess第一個參數和第二個參數再rsp+0xE0和rsp+0x148處；查看該處的數據如下：
1: kd> dpu 0000002f`4b67d260+E0 0000002f`4b67d260+148
0000002f`4b67d340 00000000`00000000
0000002f`4b67d348 00000000`00000004
0000002f`4b67d350 00000100`00000000
0000002f`4b67d358 00000000`00000020
0000002f`4b67d360 000001f2`d9b87cc0 "C:\Windows\UpdateAssistant\UpdateAssistant.exe"
0000002f`4b67d368 00000000`00000000
0000002f`4b67d370 00000000`00000000
0000002f`4b67d378 0000002f`00000000
0000002f`4b67d380 000001f2`d8d43580 "C:\Windows\UpdateAssistant\UpdateAssistant.exe /ClientI"
0000002f`4b67d388 00000000`00000000
0000002f`4b67d390 00000000`00008664
0000002f`4b67d398 000001f2`d9d73c40 "ALLUSERSPROFILE=C:\ProgramData"
0000002f`4b67d3a0 00000000`00000000
0000002f`4b67d3a8 00000000`00000000
由此可知，svchost拉起的子進程為UpdateAssistant.exe，與之前分析得到的參數也相吻合。從調用棧可知，是在svchost創建子進程UpdateAssistant.exe時遍歷的回調例程，通知給驅動軟件做相應的處理。
本文詳細地分析了系統實現進程回調安全機制的內部原理，借助IDA工具逆向系統鏡像文件，分析了實現的關鍵代碼部分，得到了關鍵數據結構及系統額外做的數據檢測校驗算法。對關鍵全局變量的作用也做了詳細解釋。此外，通過逆向分析，給出了整個機制的調用源與調用鏈。最后基于雙機調試環境，動態查看內核中維護的進程回調例程表，并且下斷點實際動態調試了整個過程。對于驅動開發，內核安全相關方面的研究工作者提供了該技術實現原理與機制。基于得到的關鍵數據結構和系統數據檢驗保護算法，可以解密關鍵字段后檢測表項中的惡意代碼，也可以用于安全廠商在對抗過程中，完全脫離系統提供的API手工構建表項，達到監控系統行為的目的。