2019獨角獸企業重金招聘Python工程師標準>>>

從原理和使用程度上看，微軟沒有必要，也的確沒有要廢棄RPC/DCOM的跡象，但是顯然這些技術會長期退入幕后當作基礎設施了。

他們都是跨進程間的通信的（跨機器自然也算是也），無非就是尋找接口，數據序列化反序列化，但他們的確是最高效的。

廣為人知的point：

• RPC是基礎。DCOM可以看成RPC的C++版。

• RPC/DCOM在本機使用時主要是依靠LPC Port（而他又使用共享內存，queue等東西）。用WinObj工具能夠看到各種ALPC類型的東西，其中就有很多是RPC/DCOM生成的。

• 這類東西，別的系統里也有，例如Android里的Binder，非常類似于DCOM，只不過僅限于本機而已。而Mac OS X里也有XPC Service，NSProxy/NSConnection之類的。

不夠廣為人知的point：

• RPC可以通過文件共享協議(SMB)來調用，也就是TCP端口445。這是SMB協議為RPC開的一個擴展。這時，RPC的認證也就委托給SMB了，這其實很方便實用。

• RPC在本機的使用非常頻繁，但在跨機器間的使用較少，幾乎只限于微軟做的服務(例如計算機管理，遠程注冊表...)。

• 通過注冊表把普通組件升級成DCOM組件的使用方式實際存在很多。

• 在跨機器場景里，DCOM和RPC的認證方式，通信端口不一樣。RPC/DCOM本身的認證方式不方便。

• 每次看到DllHost.exe啟動了，就說明有DCOM組件被啟動了，而且是Dll組件升級的那種。

---

本機內RPC/DCOM使用例

• 各種服務通過原始RPC提供基本控制接口，就是sc命令那套。還有很多系統服務提供額外接口，例如Registry，Netlogon，Firewall，Service Control，SQL Server... ，具體RPC接口信息可以在msdn里有(檢索rpc找到相應的服務，然后可以概括看看idl，例如netlogon的idl)。

  有工具例如rpcdump，rpcdump.py，ifids，portqry可以列出本機或者遠程機器上所有活動的RPC接口：

  ... ... [MS-RSP]: Remote Shutdown Protocol [MS-TSCH]: Task Scheduler Service Remoting Protocol [MS-TSCH]: Task Scheduler Service Remoting Protocol [MS-TSCH]: Task Scheduler Service Remoting Protocol [MS-EVEN6]: EventLog Remoting Protocol Adh APIs AppInfo Base Firewall Engine API DHCP Client LRPC Endpoint DHCPv6 Client LRPC Endpoint DfsDs service EFSK RPC Interface Event log TCPIP Fw APIs Group Policy RPC Interface IP Transition Configuration endpoint IdSegSrv service Impl friendly name KeyIso LicenseManager NRP server endpoint NSI server endpoint NetSetup API Ngc Pop Key Service Proxy Manager client server endpoint Proxy Manager provider server endpoint Secure Desktop LRPC interface Security Center UserMgrCli WM_WindowManagerRPC\Server WinHttp Auto-Proxy Service Witness Client Test Interface Witness Client Upcall Server XactSrv service ...Received 499 endpoints.

• Component Services工具(運行comexp.msc或者DCOMCnfg)列出了很多DCOM組件，包括COM+ Applications里的一部分。

  我曾經好奇DCOMCnfg->My Computer->Property->“Launch Permissions->Edit Limits是干什么用的，我把所有的ACL(權限控制）都給刪除了，結果系統幾乎不能操作了！后來明白那是一個“最大”權限定義）。

  
  

• 具體點，Excel，Internet Explorer，Visual Studio... 他們都提供了DCOM組件，所以才能自動化遙控操作。

• 還有，各種DllHost.exe進程都是DCOM。

  
  

  系統里經常會運行DllHost.exe，這是一個泛用的DCOM套子，把普通的COM組件包在里面運行，而利用者那邊不需要意識到，仍然像以前一樣利用組件，系統會自動提供虛擬的組件來做跨進程通信。用Process Explorer工具看看這些DllHost.exe進程的命令行，里面包含了AppID，再拿著他到注冊表里找找就知道包含的組件是什么了。

  例如，Explorer里的一部分Shell Extension，例如文件屬性對話框組件，以前使用的是普通的組件方式，即調入Exploer進程內部來使用，后來為了安全性，越來越多的把Shell Extension組件隔離到單獨的DllHost進程了，就是升級成DCOM了。

  具體的做法僅僅是向組件的注冊表信息里增加AppID設定。不光是Explorer，其實IE或者其它的系統程序有時為了安全都這樣配置組件。

  實際上，我按照上面的Link結合這個Link折騰了一陣子發現：單單修改這些注冊表并不自動起作用！還要改一丁點代碼。創建組件時，需要指定明確的標記：CLSCTX_LOCAL_SERVER。后來發現的確也有人發現這個現象。

---

跨機器RPC/DCOM使用例

• 遠程管理工具，例如:計算機管理，注冊表，sc.exe，psexec.exe，都可以管理別的機器。其底層是通過RPC over SMB做的，更具體點，就是通過文件共享服務的TCP端口445。 但這些不是DCOM，僅僅是原始的RPC。代碼例:DNSRPC over SMB。

  C:￥> psexec ￥￥remote_machine -u user -p password cmd.exe C:￥> TASKLIST /S remote_machine /U username /P password

• Domain服務器上提供了較多的原始RPC服務，直接通過TCP 135公開的(進一步會使用其它單獨的port)。代碼例：DNS RPC。

• 遺憾，跨機器使用DCOM沒找到什么實例。有個安全產品OPC跨機器使用了DCOM，可以看到配置是比較羅嗦的，認證方式，權限，用戶，policy...。原因是他是通過原始的RPC端口TCP 135認證的，特別不便于從外部控制。

  一般RPC/DCOM跨機器調用時，有兩種傳輸途徑：

  • A: 通過默認的RPC接口查詢端口(TCP135)。DCOM的CoCreateInstanceEx就是這么干的。

    惡心的是，在網絡身份認證上，除非在客戶端在代碼里寫好類型和用戶密碼，否則只能用當前用戶身份，也就是說無法從外部控制通信隧道。DCOM也只是稍微從側面提供了一點點認證后的身份利用方面的設定而已（通過DCOMCnfg設定里的Edit Limits最大權限配置)。

    所以比較現實的認證方式是，兩臺機器都加入domain，客戶端機器使用domain用戶登錄，或者讓兩邊都做相同的本地用戶名稱和密碼。否則就只能干瞪眼被當作匿名用戶，然后一般會得到拒絕訪問的錯誤。看了這個帖子后我才停止追查。

  • B: 通過RPC over SMB(TCP port 445)。這是一些諸如sc，psexec的遠程管理工具用的。

    在網絡身份認證上，可以輕松地事先在Explorer或者net use命令行里認證遠程機器(有密碼輸入對話框的)，等于說是可以從外部事先建立一個隧道，兩臺機器不需要同屬一個domain，用戶可以自由設定。

    關于通過這種路徑調用DCOM，可以先使用RPC的IRemoteActivator之類的接口，進一步啟動任何DCOM組件，用的人很少，例子：DNSRPC over SMB。但我還沒有完全做好這類實驗，牽扯到一些安全設定。

有個開源projet里提供了不少這方面的協議的python代碼:impacket，當然metasploit里就更全了。

還有一種通過HTTP調用的沒研究，服務器端要額外安裝一些東西，好啰嗦。

---

那COM+呢？

COM+是個更加晦澀混雜的技術，有一部分是DCOM。COM+的管理也是放在上面提到的Component Service工具里。

COM+實際上等同于微軟攔截了COM底層API，一旦把普通組件登記到COM+里，那么當調用這些組件時，就會有不同的效果。COM+透明地實現了一下幾個功能：

• • 組件進程獨立化(通過DllHost.exe變成DCOM)。當然，這不是必須的，只是在把組件登記到COM+里時的選項。如果不選獨立，那么就還是和普通組件一樣在調用者進程里動作，只不過多了后面要說的幾個額外的好處。

  • 組件內接口調用監視。

  • Transaction注入。讓組件可以使用調用者本身擁有的Transaction。這個和TLS(Thread-Local-Storage)技術類似，在當前線程里藏一些Transaction關聯信息。關鍵字:GetObjectContext。

• COM+的使用很少，幾乎只有IIS的ASP組件以及SENS服務在使用。

• COM+的登記信息基本不放在注冊表里，而是在C:￥Windows￥registration￥*里。

在組件進程獨立化上，相比于依靠注冊表添加AppID加上修改客戶端代碼的方法，COM+做地極好，完全不需要修改代碼，卻能強行改變所有利用處。我做過實驗，把一個組件(例如Scripting.Dictionary)登記到COM+ Applications里(新作一個空的Server Application，然后忘其下的Components里引入既存組件），結果該組件就會被單獨拎出來放在DllHost.exe里運行，調用者還是像以前一樣Set obj = CreateObject(Scripting.Dictionary)就可以的。

另外，COM+的Library Application型我也試了試，就是依然讓組件運行在調用者進程內部，只是可以監視其使用情況，能看到哪個方法在什么時候被調用的，什么時候結束的，還可以取消Transaction。

我在Windows 10上試了試依然是管用的。（只不過，有一點，向Components里添加時，如果按照添加新組件，那么在刪除時會出錯，這個估計是因為注冊表的好多地方都是沒有權限刪除，哪怕是升級后的管理員，而是只有Trusted Installer才行。）

COM+的組件進程獨立化、監視看起來很好用啊，但是在COM退入幕后的如今年代，其實也沒什么大用了。

轉載于:https://my.oschina.net/osexp2003/blog/606866

總結

以上是生活随笔為你收集整理的Windows遗产之RPC/DCOM:还在用吗，内部又有什么区别？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。