在Windows 8的Windows Store應用程序開發中，有一個名為remoteSettings的類，開發人員可以使用該類存儲批量數據，以便用戶可以使用多台計算機訪問這些數據，只要它們使用同一帳戶登錄即可。 。
我連接了WireShark，發現該數據包存儲在Azure中，並使用TLS保護。我想自己進行MITM，以便我可以解密數據包，並查看Azure上的數據是否已加密。
我顯然沒有Azure的私鑰，所以我想知道是否任何人都有關於如何完成MITM分析的想法。
您可能要做的另一件事是攔截48字節TLS主密鑰的創建，這可能有點過頭，但在其他情況下很有用。對於許多Windows應用程序（包括IE），這發生在以下功能（取自Win7 SP1 32位）中的 lsass.exe 中：
調用者：ncrypt！ _Tls1ComputeMasterKey @ 32 + 0x57 EIP：ncrypt！_PRF @ 40 + 0x11a 然後您可以在Wireshark中通過設置（Pre）-Master-Secret log對解密的數據包進行解密SSL偏好設置中的文件名到如下所示的文件文件：
RSA會話ID：87492B3586DE289FAE1598B0A19CC7BCCB69371993F2C0DF32438034E06FE3FBMaster-Key：F58C0EFA2BF87602646B318400DFEB0C8CCDE9B4EC9B4EC9BED4B9E4B4E3B9E8B9E8B9E8B9E8B9E8B8E8B8E8B9E8B9E8E8B8E8B8E8B9E8B8E8B8E8B8E8B3E8B8E8B3E8E8B3E8E8B8E8B8E8B9E8B9E8B9E8B8E8B9E8B9E8B8E8B9E8B8E8B8E8B9E8B9E8B9E8B9B＆E＆F＆C此處的ID可以在您感興趣的流的TLS標頭中找到（未加密）。（不要被RSA欺騙-這適用於所有TLS連接，而與使用的密碼套件無關。） 此方法的優點在於，由於您不在中間做人，因此客戶端應用程序不必信任您的CA，如果您想逆轉某些確實具有加密權限的惡意軟件，則特別方便。
缺點是您需要能夠調試 lsass.exe ，這可以棘手的這裡。
如果數據通過HTTPS傳遞，則可以嘗試使用經典的 Fiddler中間人方法。我不確定Windows應用商店是否尊重代理設置或它是否具有固定證書。如果它確實遵守應有的代理設置，並且沒有固定的證書，則應該可以使用Fiddler輕鬆地將其居中。
如果數據是“ t HTTPS且證書未固定，一種選擇是使用 SSLNetcat代理安全連接。您要做的是更改主機文件，以使Store可執行文件連接到本地運行的SSLNetcat，然後設置SSLNetcat，以使其使用具有私鑰的證書。然後，您要么讓SSLNetcat直接將數據轉發到您選擇的程序，要么將私鑰輸入Wireshark並使用它來嗅探流量。如果二進製文件固定並沒有存儲在文件中，則可以修補Windows Store可執行文件，並用具有私鑰的證書替換證書。 OpenSSL應該能夠輕鬆為您生成替換證書。然後可以將此私鑰輸入到Wireshark中，然後解密該流量。
您距離複製保護區域很近，因此可能會遇到許多麻煩。
您可以採用多種方法來提取Windows Store使用的本地密鑰並將其輸入到Wireshark中，但是，我認為最好的選擇是注入一個掛接Network IO功能的DLL send （）和 recv（）。
您可以嘗試自己“低級”執行此操作，但是出於實用主義的考慮，明智的做法是檢查Microsoft Detours是否具有鉤子功能，有很多示例可以利用它-很簡單知道函數原型是唯一必要的條件。
您還可以嘗試 oSpy，它基本上掛接了適當的API調用，並允許您在加密/解密之前和之後查看數據。
oSpy是一個工具，可以對在Windows平台上運行的軟件進行逆向工程。 [...]在API級別上進行嗅探時，它可以讓您更精細地了解正在發生的事情。 [...]如果應用程序使用加密的通信，也很容易攔截這些調用。 oSpy已經攔截了一個這樣的API，它是MSN Messenger，Google Talk等用於加密/解密HTTPS數據的API。