首先這事得搜索網路，發現網路上的看起來很牛的文章，咱們得承認在之前是還算不錯的，但是也沒有真正實作。
或許有實作的，但是網上肯定是搜不到具體的，肯定都當私貨處理了，拿到現在這年代來說。都算是被淘汰了。
為什么這么說呢，因為這得分具體情況。在vista以及以后的系統中，未匯出函式ZwCreateThreadEx已經自己內置實作了
跨session 通知csrss等操作，所以用起來還是很省心的。填充好引數，直接就不管了，也很順利的運行。
但是吧，咱們寫程式就是為了兼容性(不然內心一萬匹草泥馬在翻滾)。在國內xp可還是一大堆的~
但是xp卻沒有ZwCreateThreadEx，只有ZwCreateThread
(請自行ida一下xp的ntkrnlpa.exe,
至于為什么是這個而不是ntoskrnl.exe當然這個pchunter看下驅動的加載就好了啊,本文不是掃盲篇,這些不具體解釋,當然我也是大菜鳥)
然而ZwCreateThread這個家伙 可真是讓人操碎了心。
因為按照ZwCreateThread的引數 我填充好之后，編譯，然后直接往taskmgr.exe里面注入dll，而dll的代碼就是dllmain里MessageBox了一下
大家可以想到結果是什么。
結果是：彈框出來了，哎呀，萬事大吉，收工保存，抽只煙，然后休息下，真爽。
等過了些時候，打算用用了。于是就真正的寫功能dll,至于dll的功能當然是有點小復雜。
然后測驗下。
哎，不對啊，怎么有點問題。是不是我系統壞了，或者dll那里有問題？真是奇怪。
仔細檢查dll，沒發現啥錯誤啊，為啥結果不正確。
得仔細定位dll.加了點除錯資訊輸出。最終定位到dll里 執行緒創建失敗了？然后，又仔細核對了下創建執行緒的函式
也沒發現什么問題啊。真是莫名其妙。
還是網上搜搜前輩們吧。這一搜不要緊，原來這事 絕沒這么簡單，復雜的在后面呢。
所以本文的重點是針對版本號3790(2003和64位xp)以及以下的所有的系統的兼容性,核心問題也就是：如何正確處理ZwCreateThread
那么到底如何正確處理呢？
我們為了解決這個問題,自然會網上搜，但是真正會思考這個問題的一定會聯想到CreateRemoteThread這個r3的api因為這個大家肯定太熟悉了。
好吧，先說個題外話。魯迅曾經說過:"不想吃天鵝的蛤蟆不是好的蝌蚪",還說過:"電腦不備好ida,windbg,od,wrk,reatos的程式員不是好的廚師"
那么我最開始的想法是：先看看reatos里有沒有，實在沒有就ida逆CreateRemoteThread(反正有符號,沒符號的話真沒太大勇氣逆)
天公做美竟然給搜出來了，路徑在這里
dll\win32\kernel32\thread\thread.c
我們來看下內容
簡化代碼如下：
CreateRemoteThread()
{
//堆疊
BasepCreateStack
//背景關系
BasepInitializeContext
//創建掛起執行緒
NtCreateThread
//判斷是否自身,我們不管忽略過去,我們不會往csrss里面注
//通知
BasepNotifyCsrOfThread
//恢復
NtResumeThread
}
從上面的偽代碼中我們可以看到除了通知這個,其他的都很好處理。所以我們直接將重點精力繼續追下去,也就是說看BasepNotifyCsrOfThread的具體實作
當然還是reatos里面搜,路徑如下
dll\win32\kernel32\process\procsup.c
內容如下:
NTSTATUS
WINAPI
BasepNotifyCsrOfThread(IN HANDLE ThreadHandle,
IN PCLIENT_ID ClientId)
{
。。。。
/* Call CSR */
Status = CsrClientCallServer(&CsrRequest,
NULL,
MAKE_CSR_API(Request, CSR_NATIVE),
sizeof(CSR_API_MESSAGE));
。。。。
}
一看就知道,實際上這個函式算是個小封裝，沒意思，重點還是在CsrClientCallServer里面。
那么繼續搜,路徑在
dll\ntdll\csr\connect.c
看下內容如下:
簡化代碼如下：
CsrClientCallServer()
{
//填充訊息
if (!InsideCsrProcess) //這里我就是顧名思義,我們不往csrss里面注
{
xxxxxxxxxx
NtRequestWaitReplyPort //發送lpc訊息
回傳然后xxxx我們不管
}
}
好了，看到這里，我想思路基本就明確了，寫一下偽代碼
MyNtCreateThread()
{
//堆疊
//背景關系
ZwCreateThread
ZwRequestWaitReplyPort //發訊息通知csrss等著回傳
恢復
}
==================我是華麗的分割線==========================
其中除了ZwRequestWaitReplyPort之外基本沒啥難點。下來所說的全部都是針對ZwRequestWaitReplyPort所說的。
如果看到這里的話，請忘記上面所有的內容，重點關注著ZwRequestWaitReplyPort
ZwRequestWaitReplyPort(Handle, PPORT_MESSAGE, PPORT_MESSAGE)
這個里面重要是引數的結構體非常復雜，這里可以網上搜basemsg.h,這里面都包含著呢.所以第二第三個引數可以說是能解決，那么第一個引數呢？
這個從網上找資料說\windows\apiport 不能連(實際上不準，連是可以連的，只是創建了共享記憶體，發現有共享記憶體就失敗了而已)，也不能attach
而有前輩們說可以從目標行程中查找已經存在的port型別句柄(LPC port,ALPC port),然后ZwDuplicateObject出來用。
恩，好象還真是那么回事。那么怎么辦？快去想辦法實作啊，不去實作你永遠也不可能知道行還是不行
那么針對第一個引數這個問題，自然重點就是如何查找指定pid的\windows\apiport的句柄~
放出偽代碼
Enumed(IN PHANDLE_TABLE_ENTRY HandleEntry,IN HANDLE Handle,IN PVOID Context)
{
POBJECT_HEADER Obh;
PLPCP_PORT_OBJECT CsrApiPort = (PLPCP_PORT_OBJECT)Context;
Obh = ObpGetObject(HandleEntry);
Port = (PLPCP_PORT_OBJECT)&Obh->Body;
if (Port->ConnectionPort == CsrApiPort)
{
}
}
CsrPortHandle(PEPROCESS proc, PHANDLE pCsrHandle)
{
UNICODE_STRING usType;
POBJECT_TYPE *pType;
UNICODE_STRING uName;
PLPCP_PORT_OBJECT ApiPort = NULL;
RtlInitUnicodeString(&uType, L"LpcPortObjectType");
pType = MmGetSystemRoutineAddress(&uType)))
RtlInitUnicodeString(&uName, L"\\Windows\\ApiPort");
ObReferenceObjectByName(&uName, 0, NULL, PORT_ALL_ACCESS, *pType, KernelMode, NULL, &ApiPort);
ExEnumHandleTable(xxxxxxx, Enumed, ApiPort, pCsrHandle);
ObDereferenceObject(ApiPort);
}
那么好了，第一 第二 第三個引數都有了，直接呼叫就好了~
恩。到這里好象可以收尾了。
為什么這么說呢？因為編譯好之后 我在xp下 往taskmgr注入了個dll,這個dll里 不僅僅創建了執行緒，執行緒里又創建了執行緒，然后還降權做了點事情
測驗結果一切正常。于是就抽了只煙。然后再看看xp 64位，恩也可以，好的，再最后看看2003，
哎呀，我草。。我草。。。完了，不對，雜沒出來啊，什么也不對，這這？？難道，莫非？，不應該啊。
傷心了。但是傷心之余還得繼續看。
首先看了下驅動輸出，奇怪，windows\apiport句柄雜回傳0 沒找到。
把pchunter放進去看看，哎，竟然不支持。好吧 procexp
用這個看了一下，忽然意識到好象要出大問題。因為看到了session\2\windows\apiport
這么忽然一想。感覺好象自己被自己騙了。不行，把session全部弄出來。
對著session=0的隨便一個行程注入試試（我不是iocontrol的是驅動里直接注入的所以session=0）
可以預見，這個可以。沒問題。再找個session=2的注入試試。真的不行
然后又想到了測驗的xp和xp 64。再進去看看，一看里面的所有的session=0
進行內心糾結的總結：因為同都在session 0下 所以才成功，如果用多用戶登陸，那肯定失敗。或者說驅動session=0 注session=2 失敗
這下看來真的碰到江湖上傳說中的跨session問題了，或者說跨session通知csrss的問題。
于是仔細觀看行程，發現2003里面有兩個csrss.exe 這下也意識到原來每個csrss.exe控制著一個session
行程中有10個csrss.exe就控制著10個session
而且每個csrss與每個csrss之間 互不打擾，隔離
或者通俗的說，我們的電腦登陸一個用戶就創建一個csrss
于是想到剛接觸電腦時候，網上問：“我行程中有兩個csrss.exe是怎么回事，下面回答肯定有一個是病毒，殺掉就行，當然我也那樣認為”
現在想起來，這好象再正常不過啊~
我們到這里需要對上面所有所有的內容去總結：
那就是注和驅動一樣session的完全沒有問題，不同session的創建是成功的只是（如果dll里再創建執行緒等會失敗）
那么現在問題就來了，我們的驅動session=0(說了沒有使用iocontrol,否則session是呼叫它的exe所在session)
那么怎么去通知session=2的csrss呢?（我們一切都以我2003上目前的這個狀態來說事情）
基于上面已經實作的和總結的，我們是不是可以這樣想：我們既然要通知csrss并且session=2的，那么我們是否
選擇一個session=2的其他行程（雖然dll里再創建執行緒失敗，但是dllmain入口里的沒問題啊）
然后注給它，然后它再去通知csrss(session=2)的。恩
想了想，邏輯沒問題。于是繼續寫查找session的代碼一大通。編譯好。
自己腦袋里過了一遍，感覺很緊張，因為思路上是通的。要是測驗通過，就可以以后安心使用了，也算是對抗精神嫡的再一次成功
如果失敗，那么必瘋無疑，甚至開始懷疑人生。
拿出來一試，十萬個我草。失敗。
真想用李云龍的話說事情。。。奶奶個腿
罵沒有用，得找出是為什么失敗來。經過系列跟蹤，發現，csrss（session=2）的 確實是成功了的
但是，csrss回復的時候，是回復給 我們選擇的 session=2的 所謂的其他行程
現在到這里，所有的問題成了一個僵局
而且越弄越復雜了。
到底應該怎么辦呢？
到底應該怎么辦呢？
能不能柳暗花明呢？
==================我是華麗的分割線==========================
下文就是讓柳暗花明。
我們上文當中碰到了一個非常麻煩的事情，那就是session=0的驅動，去通知session=2的csrss.exe.
我們嘗試的找個session=2的a.exe，往a.exe注一點代碼，這個代碼就負責通知session=2的csrss
最后發現的是session=2的csrss收到訊息后回復給了a.exe，我們驅動里并沒有得到通知。
我們所有的問題都是為了得到通知。實際上這里走了很多彎路，實驗了很多方法。真的是弄的腦袋爆。
驅動注入用戶執行緒之跨session通知csrss之真正解決 中的所謂的‘真正’的含義！
這里真正是加了引號，實際上我是重點標記，我說的的確是真正。
當問題沒辦法解決的時候會怎么辦呢？當然是所有的辦法也猜測，所有的資料也看。這里我們為了節約時間突出重點。
我們不再說我們走的彎路（實際上彎路很多很多）
當然這其中也免不了看 csrss.exe用了什么模塊。自然會關注到CSRSRV.dll
網上搜也會看到這個是csrss.exe的核心。既然我們關注了這個dll.我們也就避免不了看看匯出啊，對感興趣的函式逆逆啊，搜搜啊什么的
我們來看這個dll的匯出函式。
如下：
匯出, CSRSRV.dll
序列 地址 名字
00000001 75AA544F CsrAddStaticServerThread
00000002 75AA4160 CsrCallServerFromServer 看名字我有興趣
00000003 75AA3FCE CsrConnectToUser 看名字我有興趣
00000004 75AA5D26 CsrCreateProcess
00000005 75AA60E0 CsrCreateRemoteThread 看名字我有興趣
00000006 75AA6010 CsrCreateThread 看名字我有興趣
00000007 75AA63FE CsrCreateWait
00000008 75AA6362 CsrDebugProcess
00000009 75AA636F CsrDebugProcessStop
0000000A 75AA500B CsrDereferenceProcess
0000000B 75AA55AA CsrDereferenceThread
0000000C 75AA658B CsrDereferenceWait
0000000D 75AA5F58 CsrDestroyProcess
0000000E 75AA619A CsrDestroyThread
0000000F 75AA54C2 CsrExecServerThread
00000010 75AA508D CsrGetProcessLuid
00000011 75AA4EE9 CsrImpersonateClient
00000012 75AA535D CsrLockProcessByClientId
00000013 75AA53DD CsrLockThreadByClientId
00000014 75AA6615 CsrMoveSatisfiedWait
00000015 75AA652D CsrNotifyWait 看名字我有興趣
00000016 75AA2A17 CsrPopulateDosDevices
00000017 75AA3FC3 CsrQueryApiPort 看名字我有興趣
00000018 75AA4F9D CsrReferenceThread
00000019 75AA4F30 CsrRevertToSelf
0000001A 75AA305E CsrServerInitialization
0000001B 75AA4D1F CsrSetBackgroundPriority
0000001C 75AA516F CsrSetCallingSpooler
0000001D 75AA4CF8 CsrSetForegroundPriority
0000001E 75AA624F CsrShutdownProcesses
0000001F 75AA3204 CsrUnhandledExceptionFilter
00000020 75AA53BA CsrUnlockProcess
00000021 75AA622C CsrUnlockThread
00000022 75AA4421 CsrValidateMessageBuffer
00000023 75AA449D CsrValidateMessageString
我有興趣的函式我都在reatos里面搜了。
當搜到CsrCreateRemoteThread函式的時候，一切都傻眼了。為什么呢？我們來看CsrCreateRemoteThread的代碼。
路徑如下：
subsystems\csr\csrsrv\thread.c
代碼核心如下：
NTSTATUS
NTAPI
CsrCreateRemoteThread(IN HANDLE hThread,
IN PCLIENT_ID ClientId)
{
。。。
}
CsrCreateRemoteThread(IN HANDLE hThread,IN PCLIENT_ID ClientId)
從注釋和內容看，這明擺著不就是：把我們要注的目標行程的hThread和ClientId傳給這個函式，這個函式
自動進行關聯起來的內置操作嗎？
又是一個挖槽。我們干嘛總是驅動里給他發通知，這不是自己自尋死路嗎，我們為什么不
為什么不
為什么不
為什么不
太重要了這點資訊，下面說的這點資訊將是重點中的重點。通篇廢話就是為了下面的這幾句。
*********************************************************************************************
我們再來回想一下，我們通篇都在做什么？都在做一件事情，那就是 驅動(session=0) 通知 csrss(session=2)
我們從來就沒想過往csrss(session=2)里面注,現在人家csrss(session=2)有個現成的函式自己實作這些。
我們現在就往csrss(session=2)里面注，讓csrss自己通知自己。而我們驅動不等port的回傳，因為所有的關于
port等的資訊都tmd與我們沒關系了。我們只等著 注入csrss(session=2)里面的 的一點代碼 把CsrCreateRemoteThread
的回傳值通過結束執行緒的介面給傳回來。
來點片段代碼說清楚上面的看似模糊的話。
片段1:r3里的
注入csrss(session=2)里面的 的一點代碼,實際上重點就這兩行，當然是r3的代碼
//csrss自己去處理通知吧，我們什么也不管,我們只管驅動把這兩引數給傳好就行了。就讓csrss自己通知自己
CsrCreateRemoteThread(ThreadHandle,UniqueProcess);
//如果執行到這里的話肯定上面的代碼就已經完成了，下面的這行代碼是為了讓驅動知道(驅動里可以恢復真正的執行緒運行了)
NtTerminateThread(GetCurrentThread(),0);
片段2:r0里的
MyZwCreateThread()
{
//堆疊
//上先文
//ZwCreateThread目標執行緒掛起
//ZwCreateThread(&CsrssThreadHandle, THREAD_ALL_ACCESS...) 目標執行緒所在行程所在session的 csrss 不掛起（內容就是片段1里的）
//ZwWaitForSingleObject(CsrssThreadHandle...)
//恢復目標行程
}
已經非常清晰了，重點中的重點啊，真的是放血了。
這樣做的好處太多了。簡單明了，不用那個通知函式又復雜又麻煩，事情又多，彎路又多，網上又很多忽悠人的看似可以的文章。讓大家更加迷茫。
簡單幾行替代上百行，又穩定又安全又有依據。
*********************************************************************************************
所以標題可以這么稱呼：
驅動注入用戶執行緒之跨session通知csrss之真正解決之CsrCreateRemoteThread大法之全球首創
哈哈，夠霸氣吧~~
感謝busy,感謝csdn ,感謝所有幫助過我的朋友。
注意：只因這樣的代碼危害性太大就暫不發到論壇里了
有興趣的朋友可以加 微信號:hh8560851 加時標注csdn，送上代碼并一起交流
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/86007.html
標籤：C語言