解讀 WCP 環境

環境

WCP.dll

Windows Componentization Platform Servicing API

6.3.9600.16384

10.0.10240.16384

10.0.10240.16565

這裡的版本并不重要。

原先是用的第一個版本，即 win8.1 中的檔案。

後來在處理增量壓縮時，發現 Win10 中增量壓縮的格式比 Win8.1 有所增加，是以，就改用了 Win10 中的檔案了。

本着越新越好的原則，最終標明了率三個版本。

版本一旦標明，就很難再改了。

這是由于我們調用的是系統未導出的函數，直接調用函數的位址；而不同版本的函數是不一樣的，10.0.10240.16565 是當時的最新版本，後面有新的版本，也不能再換了。

檔案在 \Windows 下WinSxs 下x86_microsoft-windows-servicingstack_31bf3856ad364e35_10.0.10240.16384_none_b5413773a99a53d2 目錄下。

實際上，如果系統是 64 位，系統真正使用的并不是這個目錄，而是 amd64_microsoft-windows-servicingstack_31bf3856ad364e35_10.0.10240.16384_none_115fd2f761f7c508。

兩者肯定是有差別的，但主體功能是相似的，研究問題，當然是從簡單、友善入手，是以，我們主要使用 32 位的檔案進行，配合使用 64 位的檔案。後面我們會看到，有些 32 位的函數已經優化成了函數聲明。

WinSxs 稱為 Side-by-side assemblie，後面再詳細介紹。

在 WinSxs 下的目錄成千上萬，目錄名基本上都像上面的這兩個，看着讓人眼暈。

要知道這些名稱的組成，參看檔案名解析。

WCP.dll 雖然稱為 API，但是，并未提供必要的文檔，連頭檔案也沒有。好在從網上發現了 ida 工具，好在微軟還是提供了符号檔案，才算真正找到了解決問題的正确方向。

即便是這樣，難度還是很大的。光是 WCP.dll 一個檔案，其中的函數就有 8400 多個。

再到後來，發現 WCP.dll 并不是主程式，但不影響我們對系統的了解，以及修複系統。