上篇帶大家分析了一下服務端的軟體，現在更進一步，對OPC的包進行深度解析。OPC使用的RPC協定和其它的工控協定有所不同，如Modbus協定服務端的固定端口是502，RPC協定在真正建立資料連接配接之前通訊雙方要協商使用的服務端口，即要有一個綁定的過程。基于RPC協定本身的定義，RPC建立連接配接時有一個固定的135号端口供用戶端綁定專用，然後RPC從服務端的端口池（1024 ~ 65535）中選一個未使用的端口傳回給用戶端（如下圖中的1118）。用戶端以後用此端口作為後續真正請求使用的端口。注意該端口是動态暫時的，該會話結束若再請求的話會得到一個不同的端口。具體的RPC通路初始綁定建立的過程見下圖。
注意這裡的ISystemActivator接口，它是負責真正地請求和傳回服務端口的連接配接，但也不是唯一能達到此目地的接口，後面會另外介紹另一個接口也可以傳回動态端口。
Windows下的RPC是基于TCP協定的，它的豐富的PDU(Protocol Data Unit)有二十多種不同的類型，有的負責綁定（11-13），有的負責請求和響應（0，2）。也有的是維護連接配接的長期有效（1）。本文關心的主要是請求/應答和綁定類型。
使用自創的OPC三合一用戶端程式（見該篇），在建立一個執行個體前設定斷點，然後啟動Wireshark，運作用戶端完成一個讀操作，獲得相應的一系列捕獲的包，見下，
這張圖檔給了我們什麼資訊？我們看到，這是一個請求(0)類型的PDU，它的協定欄标為ISystemActivator接口而不是DCERPC，該接口下被調用的函數是RemoteCreateInstance，操作代碼(Opnum)是4。請求方的端口在某個時間點從135變成了53286，而這個時間點正是ISystemActivator協定應答後發生的，由此我們有理由相信這個應答帶回了動态端口資訊，需要仔細審視。也許有人會問在協定欄，為什麼标為ISystemActivator，不像其它行一樣标為DCERPC？這裡涉及到COM和DCOM及DCERPC的差別。COM一般都定義在IDL檔案中，需要注冊才能被使用者使用。DCOM一般是系統使用，它隻定義了一些有限的接口，而這些接口有的并沒有在系統資料庫出現，因為不是供使用者使用的，比如ISystemActivator，IRemoteActivation等等。DCOM接口如下，
由此可見，DCOM是一些特殊的DCERPC請求/應答PDU，是微軟平台下專有的接口，是以在協定欄中使用接口名稱而不是一般的DCERPC。那麼ISystemActivator到底是什麼？檢視源碼，
獲得了ISystemActivator的uuid，000001A0-0000-0000-C000-000000000046，但是如果搜尋系統資料庫卻找不到它的相關資訊，因為它不是給使用者使用的，使用者也不應直接調用。根據uuid再查相關資訊，
看來ISystemActivator改名了，現在叫IRemoteSCMActivator，進一步查下它，
我們沒有微軟的相應IDL來檢視該接口，但從文檔上可以看到IRemoteSCMActivator接口下共有五個函數，最後一個就是抓包中所展現的RemoteCreateInstance，它相應的Opnum值是4，也就是說它是該接口下的第五個函數。看到這裡大家應該對Opnum有個概念了，其實它是用來表示接口下的函數順序，告訴服務端我要調用某個接口下的第x個函數。
繞了一大圈，有了這些鋪墊，現在專注于ISystemActivator的應答，
果然不出所料，應答中包含了從服務端帶回的以後連接配接所使用的端口号，53286。根據文檔，STRINGBINDING正是存放服務端端點的地方，
至此我們獲得了一個服務端傳回的動态端口，工業防火牆設計上的一大挑戰劃上了句号。除了ISystemActivator會帶來動态端口的資訊，還有沒有其它接口也會帶來動态端口資訊？
我用了另一個用戶端，發起類似的建立過程，得到如下的包截圖，
這裡可以看見類似的端口改變，從135變成了52997。這種改變是從REMACT協定的應答後開始的，是以我們有理由相信該應答帶回了動态端點内容。進一步看下應答，
果不其然，在STRINGBINDING中帶回了服務端點52997。也許有人會問，REMACT到底是什麼協定？上圖顯示是IRemoteAcitvation接口，uuid如下，
它的IID，4d9f4ab8-7d1c-11cf-861e-0020af6e7c57，同樣在系統資料庫中也查不到。其實已經改名了，叫IAcitvation，隻有一個函數如下，自然Opcnum就是0了。
本文總結了二種方法下如何擷取OPC的動态端口，抛磚引玉希望大家看完後點個贊，留個言。2020歲末已至，活下來真心不容易。這裡的疫情沒控制住還在蔓延，第一針疫苗也剛開打。此文算是留給難忘的2020作個總結，2021再續下篇，專講OPC讀寫操作時的包解析。再見2020，你好2021！