TSforge - 永久激活 Windows 7、Office 2013 之后的全部版本
當前位置：點晴教程→知識管理交流
→『 技術文檔交流 』
MAS 團隊近期發布了名為 TSforge 的激活方案，可激活自 Windows 7、Office 2013 之后的全部版本。方案利用一個漏洞繞過傳統的激活驗證，實現超過 4000 年的永久激活。 打開 PowerShell 輸入： 適用于 Windows 7 到 11 的激活/評估擴展方法的集合。注意：我們不支持直接使用此工具。此處介紹的方法的唯一受支持的實現是在 Microsoft 激活腳本中。 包含的方法和工具：
用法Usage: TSforge [/dump <filePath> (<encrFilePath>)] [/load <filePath>] [/kms4k] [/avma4k] [/zcid] [/rtmr] [/duid] [/igpk] [/kmsc] [/ctpr] [/revl] [/prod] [/test] [<activation id>] [/ver <version override>] Options: /dump <filePath> (<encrFilePath>) Dump and decrypt the physical store to the specified path. /load <filePath> Load and re-encrypt the physical store from the specified path. /kms4k Activate using KMS4k. Only supports KMS-activatable editions. /avma4k Activate using AVMA4k. Only supports Windows Server 2012 R2+. /zcid Activate using ZeroCID. Only supports phone-activatable editions. /rtmr Reset grace/evaluation period timers. /rrmc Reset the rearm count. /duid Delete product key Unique ID used in online key validation. /igpk Install auto-generated/fake product key according to the specified Activation ID. /kmsc Reset the charged count on the local KMS server to 25. Requires an activated KMS host. /ctpr Clear the physical store tamper state. /revl Remove the key change lock in evaluation edition store. /prod Use SPP production key. /test Use SPP test key. /ver <version> Override the detected version. Available versions: vista, 7, 8early, 8, blue, modern. <activation id> A specific activation ID. Useful if you want to activate specific addons like ESU. /? Display this help message. 常見問題這是如何工作的？ 該工具處理存儲在稱為“物理存儲”的文件中的數據，Windows 使用該文件來存儲關鍵激活數據，包括到期計時器和綁定到每個許可證的 HWID。由于我們的逆向工程工作，我們能夠將自己的數據插入到物理存儲中，從而允許我們為 Windows 軟件保護平臺管理的任何產品添加自定義激活數據。物理存儲中的數據也稱為“受信任存儲”，因此得名“TSforge”。 這種方法相比其他激活方法有什么優勢？TSforge 為激活較舊的 Windows 版本（例如 Windows 7 到 8.1）提供了最大的優勢，因為它可以永久激活這些版本的任何版本，而無需修改啟動過程或 Windows 系統可執行文件。TSforge 也是唯一能夠激活任何 Windows 插件的公共激活器，使其對希望激活 ESU 許可證的用戶很有用。此外，TSforge 是唯一提供硬件固定激活的公共激活器，無需任何持久網絡連接、添加的服務/任務或注入的 DLL。 TLDR：只有當您使用舊的 Windows 版本或想要激活 ESU 等插件以延長支持結束日期時，您才應該使用 TSforge。 缺點是什么？對于 Windows 10 和 11，建議使用 HWID 方法激活 Windows。TSforge 既不太可靠，又缺乏 HWID 提供的功能，例如在功能升級和完成作系統重新安裝后幸存下來的能力。對于 Windows 7 到 8.1，沒有明顯的缺點。 這里的任何方法都需要互聯網嗎？不，這里介紹的所有方法都不需要連接到互聯網才能運行。一切都在本地完成。 如何在不安裝相應產品密鑰的情況下安裝特定許可證？您可以使用 TSforge 中的開關來安裝許可證，只需使用激活 ID。您可以通過運行 來獲取所有可安裝許可證及其激活 ID 的列表。您可以單擊彈出窗口并按 CTRL + C 復制所有信息。找到所需許可證的激活 ID 后，按如下方式運行：。/igpkslmgr /dlv all/igpkTSforge.exe /igpk <activation id> 如何激活 KMS 主機服務器？您可以將 和 選項與要激活的 KMS 主機 SKU 的激活 ID 一起使用。然后，您可以使用帶有此激活 ID 的選項向 25 個客戶端的 KMS 服務器收費。請注意，KMS 服務器將保留其客戶端計數最多 30 天。/igpk/zcid/kmsc 為什么任何激活方法都不支持 Windows Vista？Windows Vista 包含一個驅動程序，該驅動程序持有物理存儲的永久句柄，即使 SLSvc 未運行時也是如此。這可以防止 TSforge 在系統啟動時寫入新的受信任的存儲數據，而不會濫用對另一個內核驅動程序的訪問。盡管可以離線修改物理存儲，但這需要在 WinPE 映像中托管 TSforge，而 WinPE 映像缺少 MAS 和 TSforge 所需的許多工具和 API。到目前為止，這阻止了我們實現 Vista 支持。 如何防止因 Windows 7 上的 WAT 而停用？如果安裝了通用密鑰，則需要運行以刪除產品密鑰的唯一 ID。這將阻止 WAT 在線驗證密鑰。安裝虛假產品密鑰將具有等效效果。或者，您可以使用非通用密鑰繞過此檢查，盡管 WAT 會阻止許多公開可用的密鑰。TSforge.exe /duidTSforge.exe /igpk <activation id> AVMA4k 在我的虛擬機中不起作用，為什么？Windows 不支持在無法提供 Hyper-V 啟發的 VM 軟件下激活 AVMA。這主要意味著 AVMA4k 僅在正確配置的 QEMU 實例或 Hyper-V 下運行的 VM 受支持。如果您的 VM 的激活狀態在使用 AVMA4k 后出現狀態代碼，則需要使用其他激活方法。Notification0xC004FD01 如何刪除此激活？運行 Microsoft 激活腳本，選擇 > 。這將重置物理存儲并恢復 TSforge 所做的任何更改。TroubleshootFix Licensing Microsoft 可以修補此問題嗎？是的，盡管有一些困難。 他們會嗎？可能不會。如果他們知道，請告訴我們，這樣我們就可以像一群瘋子一樣在本周剩下的時間里自嘲。 構建說明
學分核心研發
其他貢獻SpCreatePackaedLicense - 工具開發、測試
特別鳴謝BetaWiki - 記錄用于逆向工程的泄露測試版
許可證該項目根據 GNU 通用公共許可證 v3.0 的條款獲得許可。 更多介紹： 介紹2025 年是 Windows 當前 DRM 系統軟件保護平臺 （SPP） 推出近 20 周年。自 Windows Vista 開發初期以來，它就作為激活的主要網關，許多人想出了巧妙的方法來欺騙它，從重置寬限期計時器到模擬 KMS 服務器再到掛接引導加載程序。雖然所有這些系統都濫用了各種激活方法，但從未有過直接攻擊 SPP 本身的漏洞......直到現在。 在這篇博文中，我們介紹了 TSforge，這是我們有史以來最強大的激活漏洞之一。TSforge 能夠激活自 Windows 7 以來每個版本的 Windows 的每個版本，以及自 Office 2013 以來的每個 Windows 插件和 Office 版本，它是我們迄今為止在 MAS 中實施的最復雜、影響最廣泛的漏洞，只有我們命運多舛的 Keyhole 漏洞才能與之媲美。除了討論 TSforge 的工作原理外，我還將討論我們發現和理解它所走的崎嶇道路，以及我們在此過程中用它做的一些有趣的事情。 SPPSPP 是一個非常復雜的系統，涉及多個活動部分。為簡單起見，我們將只關注與此漏洞相關的部分：
CID 技巧我們第一次出現通用 SPP 漏洞利用的跡象是在 2023 年，我們發現了一種我們稱之為“CID 技巧”的方法，它允許我們存入虛假的確認 ID。 確認 ID （CID） 是用于通過電話通過對話框或命令激活 Windows 的數值。由于可以在不連接到任何網絡的情況下完成手機激活，因此所有 Windows 版本和插件都至少有一個可以通過手機激活的許可渠道，包括 KMS 服務器和 ESU 插件等其他無法破解的產品。slmgr /atp 認識到這一點，asdcorp 決定研究 CID 驗證在內部是如何工作的。在做了一個簡單的內存補丁以使提供的任何 CID 有效后，他們注意到它有一些奇怪的效果： 如視頻中所示，修補 CID 驗證代碼允許我們使用全由 0 組成的 CID 進行激活。但至關重要的是，即使在通過重新啟動 sppsvc 清除補丁后，此激活仍然存在。對我們來說，這表明了一些非常重要的事情：無論 SPP 保存什么數據以記住它已被激活，在寫入后都不會進行驗證。sppobjs.dll 這對我們來說是一個非常令人興奮的發現，因為這意味著如果我們可以編寫相同的數據，我們就可以輕松激活 Windows 的任何副本，而無需使用調試器或利用內核驅動程序。對我來說更重要的是，這也意味著這種方法可以擴展到在 Windows 7 和 8 等舊版本上運行，在這些版本中，在運行時修補 SPP 代碼要困難得多。 但是，為了使此方法成為可行的方法，我們需要回答以下問題：
初始工作從之前的調查中，我們對第一個問題有了部分答案。使用進程監視器觀察 sppsvc，我們可以準確地看到它存儲激活數據的位置：
在 Windows 8.1 和 10 上，我們觀察到數據主要存儲在以下位置：
Windows 8 幾乎相同，只是文件存儲在 ..datC:\Windows\System32\spp\store 然而，Windows 7 的情況卻截然不同：
在這里，我看到了對以下位置的引用：
但是，更奇怪的是，我發現 sppsvc 不會直接寫入“7B296...”文件或 WPA 注冊表項。相反，它將使用 DeviceIoControl 方法調用稱為 .然后，此驅動程序將處理對“7B296...”文件和 WPA 注冊表項的寫入。spsys.sys
在比較這些文件和注冊表項時，我發現了很多相似之處。起初，這些文件大多無趣，因為在所有版本中，這些文件似乎只是將 XML 許可證的內容保存在一個名稱相似的文件夾中：。tokens.datC:\Windows\System32\spp\tokens “7B296...”和文件似乎起著類似的作用，因為這些文件不僅被加密，而且似乎還包含某種哈希或簽名。損壞或刪除這些文件將卸載所有已安裝的產品密鑰并重置所有其他激活數據（重置計數、KMS 客戶端計數等）。在 Windows 7 上，它還會顯示以下可愛的錯誤消息：data.dat
撇開我如何無法獲得對自己的計算機進行更改的授權問題不談，在安裝產品密鑰后，我收到了多個版本“篡改受信任存儲”的通知：
把所有這些放在一起，看起來就像 “7B296...”文件，它們都用作重要激活數據的存儲，它們似乎在內部被稱為 “可信存儲”。data.dat 對 WPA 注冊表項進行暴力篡改的類似過程表明，它們以某種方式與受信任的存儲相關聯。定期添加具有看似加密數據的新密鑰，以及在重大許可更改后添加。此外，由于 NtLockProductActivationKeys 函數，這些密鑰是完全只讀的，無法刪除，除非您從 Windows PE 環境中弄亂它們。篡改或刪除這些密鑰會導致出現類似的“許可證篡改”錯誤，但如果我們將這些密鑰與受信任的存儲文件一起從一個安裝復制到另一個安裝，sppsvc 似乎不再抱怨篡改。HKEY_LOCAL_MACHINE\SYSTEM\WPA 從所有這些工作中，我們學到了以下幾點：
不幸的是，在很長一段時間里，我們對此知之甚少。我對 sppsvc 的舊版本和新版本進行反混淆的工作幫助我們確認了我們的一些理論，但在不了解 的情況下，它們并沒有做出太大貢獻。與此同時，SpCreatePackaedLicense 構建了 CID 技巧的自動化版本，使用自定義內核驅動程序來修補 sppsvc，而無需調整其受保護的進程狀態，這對測試 CID 技巧有很大幫助。spsys.sys
不過，除此之外，我們基本上擱置了這項工作，轉而研究 CLiP，它似乎有更有前途的開發途徑。 當它泄漏時，它會泛濫盡管我們主要關注 Windows 盜版，但我們中的許多 MASSGRAVE 成員也對它的開發歷史感興趣，或者更具體地說，它的各種預發布 beta 版本。研究和弄亂這些版本不僅作為一種新奇事物很有趣，而且在開發過程中留下的工件可以幫助我們了解很多關于 Windows 工作原理的知識。 在與一些測試版專家討論最近泄露的 Windows 8 版本的激活機制時，我不經意間被幾個重大發現弄得措手不及：
盡管內部版本 7792 和內部版本 7850 正在開發 Windows 8 的道路上，但它們的內部版本號與 Windows 7（內部版本 7600）足夠接近，因此我對 spsys 的一些新信息充滿希望。事實上，在內部版本 7850 的符號存檔中，我找到了 spsys 的符號以及激活子系統的其余部分。
Build 7792 也有一個完全未混淆的 spsys 版本，就像宣傳的那樣，但沒有符號。另一方面，Build 7850 的 spsys 具有完整的符號和完全混淆。雖然我沒能得到我的蛋糕并吃掉它，但這對仍然是一個非常幸運的發現，所以我決定用它來弄清楚可信商店是如何運作的。 咒語與詛咒像往常一樣，幸運的休息時間，這個帶有附加條件。最大的一個是，與任何其他普通的 Windows 版本不同，使用 WinDBG 進行內核調試在版本 7792 上根本不起作用，因為這是 Windows 最早的 ARM 端口之一。
因此，盡管我有一個完全去混淆的 spsys 副本，沒有任何煩人的反調試功能，但我幾乎沒有實際調試它的選項。由于此版本是在 QEMU 中模擬的，我仍然可以選擇使用其內置的 GDB 調試服務器，但這將非常難以使用，因為我必須在內存中手動定位內核和驅動程序才能執行任何有用的作。幸運的是，我能夠與 Rairii 取得聯系，由于他在 ARM 上模擬早期 Windows，他對這種調試方法更加熟悉。 不幸的是，我對 QEMU OS 調試或 ARM 或非常低級的 Windows 內部結構知之甚少，所以他的建議一開始有點難以遵循......
使問題更加復雜的是，我選擇為這個項目編寫自定義工具，使用 GDB 客戶端庫來控制 QEMU 并在加載 spsys 時自動中斷。就像我嘗試自定義工具的大多數嘗試一樣，這最終是巨大的浪費時間，最終甚至沒有奏效，尤其是由于我對 GDB 缺乏一般經驗。在浪費了更多時間嘗試通過其 Python API 向 GDB 添加 Windows 支持之后，我最終硬著頭皮選擇了我所知道的魔鬼，即 IDA Pro 調試器。 是的，對于調試內核或調試 QEMU（或者真的任何東西）來說，它是最不“合適”的選擇，但對我來說更重要的是我熟悉它。使用我從內部版本 7915 的符號集中抓取和修改的各種內核結構，我能夠編寫出一個腳本，該腳本將在各種內核函數上斷點并獲取重要數據，例如內核基址和加載的內核模塊列表。通過以編程方式中斷 ，我甚至可以在加載每個驅動程序時自動更新模塊列表。IopLoadDriver
然而，即使有了這個監控系統，我仍然無法捕捉到加載的時刻。只有在檢查了其加載程序的代碼后，我才發現了一個有趣的調用：spsys.sysspldr.sysZwSetSystemInformation
參考 Geoff Chappell 的表格，我看到這對應于 ，當然，它在內核代碼中有自己的分支，可以在不調用 .SystemLoadGdiDriverInSystemSpaceIopLoadDriver
在這個樹枝上也折斷后，我終于可以在它加載后立即接住了！spsys.sys
請注意，所有這些工作最終都實現了如果 WinDBG 正常工作的情況。無論如何，我現在能夠在 7792 內部版本加載時捕獲和調試它，而不會遇到煩人的混淆和反調試。sxe ld spsys 說到混淆，我仍然需要解壓縮 Build 7850 的 spsys 才能理解它。幸運的是，這要容易得多，因為我可以搜索對加密函數的調用位置。
然后，我只需在內核調試器中中斷這些調用并從內存中轉儲驅動程序，然后我就相當輕松地解密了所有代碼。從這里開始，這只是一個通過眼睛傳輸符號的漫長過程，我終于回到了原點。
終于進步了標記所有函數后，我注意到代碼中生成受信任存儲文件的一種有趣模式，該文件似乎稱為“物理存儲”。Microsoft 似乎沒有選擇將加密數據存儲在單獨的緩沖區中的典型方法，而是選擇就地進行加密。
這可能會防止某種側信道攻擊，但更重要的是，這意味著我只需在調試器中跳過此調用并讓 spsys 將未加密的內容寫入磁盤，即可“解密”物理存儲。因此，我做到了：
asdcorp 和 abbodi1406 立即開始工作，弄清楚數據格式以及其中存儲的數據類型。與此同時，我專注于在 Windows 10 上復制這個技巧，在那里分析會容易得多，尤其是因為有一個實際的調試器 （x64dbg） 可用。方便的是，函數 HIDHash 中有一些非常獨特的常量：
在 Windows 10 的 sppsvc 中搜索這些常量后，我在 sppsvc 中找到了相同的函數：
正如我發現的那樣，spsys 的大部分代碼最終都包含在 Windows 10 上的 sppsvc 中。通過比較這些代碼庫，我發現了所有的加密、解密、簽名檢查和哈希檢查例程。在調試器中修補所有這些例程后，我們不僅可以讓 sppsvc 為我們解密它，還可以加載和接受我們在其中所做的任何修改。data.dat
在測試這些補丁的過程中，我們最終找到了失傳已久的 Redpill 產品密鑰，Redpill 是 Windows 8 測試版的功能鎖定系統。
在一些實驗和我的一些幫助下，asdcorp 設法重現了 CID 技巧，但這次沒有修補 CID 驗證例程。
從這里開始，asdcorp 和 Lyssa 找出并測試了更多的漏洞，包括一種 4000 多年來離線激活 KMS 的方法。
盡管這些結果標志著重大進展，但我們仍然需要使用調試器來測試這些方法，因為我們無法自己解密和重新加密物理存儲。因此，我的下一個任務是弄清楚如何做到這一點。 私鑰派生通過查看 spsys，我知道我需要派生的唯一真正密鑰是 RSA 密鑰，它對加密物理存儲數據的 AES 密鑰進行加密。我還從使用 asdcorp 進行的測試中了解到，只有兩個這樣的密鑰：一個用于生產/官方測試版，一個用于內部測試/Windows Insider 版本。在沒有原始密鑰數據的情況下，我們通過一種非常先進的方法發現了這一點：復制物理存儲文件，編輯其版本，然后等待 sppsvc 可怕地崩潰，表明它可以解密但不能解析交換的文件。 檢查名為 的 RSA 解密例程，我發現了一個稱為 的字節碼系統的解釋器。通過大量的苦差事和正則表達式，我能夠用 Python 編寫該系統的模擬器。SpModExpPrvExecCodes
觀察這個模擬的輸出，我意識到所有這些混淆都掩蓋了我以前隱約聽說過的一種技術，稱為加法鏈冪運算。經過一番思考，我意識到我可以跟蹤和轉儲每個模乘法的輸入和輸出，并使用它來派生私鑰。只需要 x64dbg 日志記錄和幾行 python：
最后，我擁有了從 Windows Vista 到 Windows 11 的所有 SPP 的完整生產密鑰。
由于模乘法的實現方式存在一些奇怪的差異，因此派生測試密鑰需要更長的時間，但最終，我們擁有了我們需要的所有 SPP 私鑰。 釘棺材有了私鑰，我們就能夠輕松激活幾乎任何我們想要的版本。不過，仍然存在一點麻煩，那就是獲取通用密鑰以啟用激活。 在 Windows 8 及更高版本上，為您想要的任何版本的任何通道生成通用密鑰都相當簡單。但是，Windows 7 和 CSVLK（KMS 主機密鑰）直到 Server 2022 都使用 PKEY2005，這是一種更復雜的編碼系統，需要私鑰來生成通用密鑰。由于我沒有任何加密技巧，因此我們決定解決此問題的最佳方法。 在物理存儲中，每個產品密鑰都有大型 blob，其中包含各種預先計算的信息，例如產品 ID 和手機激活數據。此外，我們發現令牌存儲 （） 還包含將產品密鑰與當前版本的 Windows 相關聯的元數據。因此，我們認為，只需復制此數據就足以欺騙 Windows 認為已安裝密鑰，而這一次，我們是對的。tokens.dat
與此同時，在為新的 CID 技巧（我們現在稱為 ZeroCID）開發編程方法時，我們在處理需要寫入物理存儲的 HWID 數據時遇到了問題。最初，我們嘗試使用 GatherOsState 的 HWID 派生的 C# 端口，但在極少數情況下最終無法驗證。由于我們幾乎沒有選項來調試或修復此端口，因此 asdcorp 決定創建一個適用于所有硬件的 HWID 值，而且它再次運行良好，甚至允許在機器之間傳輸激活。
隨著 HWID 驗證和 PKEY2005 的失敗，我們現在幾乎完全擊敗了 SPP 的離線保護。 結束語即使我們能夠使用調試器和十六進制編輯器對 SPP 造成如此多的損害，我仍然認為它是一個相當先進且構建良好的 DRM 系統。它的內部結構肯定比 Windows XP 的 DRM 有所改進，盡管有些人可能會告訴你，但 DRM 的設計相當糟糕。它還能夠很好地保護自己免受最常見的攻擊，例如通過交換物理存儲文件來重置評估計時器。此外，SPP 還有一些部分我們尚未成功破解，例如用于定義其行為的簽名 XML 許可證。畢竟，并不是說有另一個微不足道的補丁可以繞過他們的簽名檢查......
學分核心研發
其他貢獻
特別鳴謝
該文章在 2025/2/17 18:47:39 編輯過 |
關鍵字查詢
相關文章
正在查詢... 
|
400 186 1886
