精品熟人妻一区二区三区四区不卡-精品爽黄69天堂a-精品水蜜桃久久久久久久-精品丝袜国产自在线拍-精品丝袜国产自在线拍a-精品丝袜国产自在线拍免费看

MAS 團隊近期發(fā)布了名為 TSforge 的激活方案，可激活自 Windows 7、Office 2013 之后的全部版本。方案利用一個漏洞繞過傳統(tǒng)的激活驗證，實現(xiàn)超過 4000 年的永久激活。

打開 PowerShell 輸入：

irm https://get.activated.win | iex

注意：我們不支持直接使用此工具。此處介紹的方法的唯一受支持的實現(xiàn)是在 Microsoft 激活腳本中。

包含的方法和工具：

• ZeroCID - 永久激活，直到重新安裝/功能升級

• KMS4k - 4000 多年的離線 KMS 激活

• AVMA4k - 超過 4000 年的離線 AVMA 激活（僅限 Server 2012 R2+）

• Reset Rearm Count - 重置重置計數(shù)器以進行無限評估

• Reset Eval Period — 重置無限評估的評估期

• Dump/Load Trusted Store - 轉(zhuǎn)儲和加載受信任的存儲數(shù)據(jù)

• 刪除唯一 ID - 刪除產(chǎn)品密鑰的唯一 ID 以防止在線驗證

• Install Generated Product Key （安裝生成的產(chǎn)品密鑰） - 為任何產(chǎn)品安裝生成的產(chǎn)品密鑰數(shù)據(jù)

• KMS 充電器 – 為現(xiàn)有 KMS 服務器充電，以便立即用于激活

• Clear Tamper State （清除篡改狀態(tài)） - 清除由于存儲損壞或刪除而設置的篡改狀態(tài)

• 刪除評估密鑰鎖定 - 刪除評估產(chǎn)品密鑰的產(chǎn)品密鑰更改鎖定集

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.

TLDR：只有當您使用舊的 Windows 版本或想要激活 ESU 等插件以延長支持結(jié)束日期時，您才應該使用 TSforge。

1. 將下載的存檔內(nèi)容提取到C:\dotnet-sdk-9.0.200-win-x64

2. 在可以找到的目錄中打開命令提示符TSforge.sln

3. 跑C:\dotnet-sdk-9.0.200-win-x64\dotnet.exe build -c Release TSforge.sln

4. 構(gòu)建的二進制文件可以在TSforgeCLI\bin\Release\net35

• WitherOrNot - 領(lǐng)導工具開發(fā)、逆向工程、測試

• asdcorp - 初始演示、逆向工程、工具開發(fā)、測試

• abbodi1406 - 逆向工程、開發(fā)、測試

• Lyssa - 逆向工程、工具開發(fā)、測試

• 5 月 - 代碼格式化、構(gòu)建設置

• Rairii - 協(xié)助初始逆向工程工作

• Microsoft - 有趣的挑戰(zhàn)

更多介紹：

介紹

2025 年是 Windows 當前 DRM 系統(tǒng)軟件保護平臺 （SPP） 推出近 20 周年。自 Windows Vista 開發(fā)初期以來，它就作為激活的主要網(wǎng)關(guān)，許多人想出了巧妙的方法來欺騙它，從重置寬限期計時器到模擬 KMS 服務器再到掛接引導加載程序。雖然所有這些系統(tǒng)都濫用了各種激活方法，但從未有過直接攻擊 SPP 本身的漏洞......直到現(xiàn)在。

在這篇博文中，我們介紹了 TSforge，這是我們有史以來最強大的激活漏洞之一。TSforge 能夠激活自 Windows 7 以來每個版本的 Windows 的每個版本，以及自 Office 2013 以來的每個 Windows 插件和 Office 版本，它是我們迄今為止在 MAS 中實施的最復雜、影響最廣泛的漏洞，只有我們命運多舛的 Keyhole 漏洞才能與之媲美。除了討論 TSforge 的工作原理外，我還將討論我們發(fā)現(xiàn)和理解它所走的崎嶇道路，以及我們在此過程中用它做的一些有趣的事情。

SPP

SPP 是一個非常復雜的系統(tǒng)，涉及多個活動部分。為簡單起見，我們將只關(guān)注與此漏洞相關(guān)的部分：

• sppsvc.exe/slsvc.exe- SPP 的主要用戶模式服務，負責管理許可證和激活狀態(tài)

• spsys.sys- （僅限 Windows Vista/7）負責存儲敏感的激活信息，自 Windows 8 起合并到 sppsvc 中

• sppobjs.dll- 一個插件庫，包含用于產(chǎn)品密鑰和確認 ID 驗證的大部分邏輯

CID 技巧

我們第一次出現(xiàn)通用 SPP 漏洞利用的跡象是在 2023 年，我們發(fā)現(xiàn)了一種我們稱之為“CID 技巧”的方法，它允許我們存入虛假的確認 ID。

確認 ID （CID） 是用于通過電話通過對話框或命令激活 Windows 的數(shù)值。由于可以在不連接到任何網(wǎng)絡的情況下完成手機激活，因此所有 Windows 版本和插件都至少有一個可以通過手機激活的許可渠道，包括 KMS 服務器和 ESU 插件等其他無法破解的產(chǎn)品。slmgr /atp

認識到這一點，asdcorp 決定研究 CID 驗證在內(nèi)部是如何工作的。在做了一個簡單的內(nèi)存補丁以使提供的任何 CID 有效后，他們注意到它有一些奇怪的效果：

如視頻中所示，修補 CID 驗證代碼允許我們使用全由 0 組成的 CID 進行激活。但至關(guān)重要的是，即使在通過重新啟動 sppsvc 清除補丁后，此激活仍然存在。對我們來說，這表明了一些非常重要的事情：無論 SPP 保存什么數(shù)據(jù)以記住它已被激活，在寫入后都不會進行驗證。sppobjs.dll

這對我們來說是一個非常令人興奮的發(fā)現(xiàn)，因為這意味著如果我們可以編寫相同的數(shù)據(jù)，我們就可以輕松激活 Windows 的任何副本，而無需使用調(diào)試器或利用內(nèi)核驅(qū)動程序。對我來說更重要的是，這也意味著這種方法可以擴展到在 Windows 7 和 8 等舊版本上運行，在這些版本中，在運行時修補 SPP 代碼要困難得多。

但是，為了使此方法成為可行的方法，我們需要回答以下問題：

• 激活數(shù)據(jù)寫入何處？

• 在導致激活的 CID 技巧期間寫入哪些數(shù)據(jù)？

• 這些數(shù)據(jù)是如何編碼的？

初始工作

從之前的調(diào)查中，我們對第一個問題有了部分答案。使用進程監(jiān)視器觀察 sppsvc，我們可以準確地看到它存儲激活數(shù)據(jù)的位置：

在 Windows 8.1 和 10 上，我們觀察到數(shù)據(jù)主要存儲在以下位置：

• C:\Windows\System32\spp\store\2.0\data.dat

• C:\Windows\System32\spp\store\2.0\tokens.dat

• HKEY_LOCAL_MACHINE\SYSTEM\WPA

Windows 8 幾乎相同，只是文件存儲在 ..datC:\Windows\System32\spp\store

然而，Windows 7 的情況卻截然不同：

在這里，我看到了對以下位置的引用：

• C:\Windows\System32\7B296FB0-376B-497e-B012-9C450E1B7327-5P-0.C7483456-A289-439d-8115-601632D005A0

• C:\Windows\System32\7B296FB0-376B-497e-B012-9C450E1B7327-5P-1.C7483456-A289-439d-8115-601632D005A0

• C:\Windows\ServiceProfiles\NetworkService\AppData\Roaming\Microsoft\SoftwareProtectionPlatform\tokens.dat

• HKEY_LOCAL_MACHINE\SYSTEM\WPA

但是，更奇怪的是，我發(fā)現(xiàn) sppsvc 不會直接寫入“7B296...”文件或 WPA 注冊表項。相反，它將使用 DeviceIoControl 方法調(diào)用稱為 .然后，此驅(qū)動程序?qū)⑻幚韺Α?B296...”文件和 WPA 注冊表項的寫入。spsys.sys

在比較這些文件和注冊表項時，我發(fā)現(xiàn)了很多相似之處。起初，這些文件大多無趣，因為在所有版本中，這些文件似乎只是將 XML 許可證的內(nèi)容保存在一個名稱相似的文件夾中：。tokens.datC:\Windows\System32\spp\tokens

“7B296...”和文件似乎起著類似的作用，因為這些文件不僅被加密，而且似乎還包含某種哈希或簽名。損壞或刪除這些文件將卸載所有已安裝的產(chǎn)品密鑰并重置所有其他激活數(shù)據(jù)（重置計數(shù)、KMS 客戶端計數(shù)等）。在 Windows 7 上，它還會顯示以下可愛的錯誤消息：data.dat

撇開我如何無法獲得對自己的計算機進行更改的授權(quán)問題不談，在安裝產(chǎn)品密鑰后，我收到了多個版本“篡改受信任存儲”的通知：

把所有這些放在一起，看起來就像 “7B296...”文件，它們都用作重要激活數(shù)據(jù)的存儲，它們似乎在內(nèi)部被稱為 “可信存儲”。data.dat

對 WPA 注冊表項進行暴力篡改的類似過程表明，它們以某種方式與受信任的存儲相關(guān)聯(lián)。定期添加具有看似加密數(shù)據(jù)的新密鑰，以及在重大許可更改后添加。此外，由于 NtLockProductActivationKeys 函數(shù)，這些密鑰是完全只讀的，無法刪除，除非您從 Windows PE 環(huán)境中弄亂它們。篡改或刪除這些密鑰會導致出現(xiàn)類似的“許可證篡改”錯誤，但如果我們將這些密鑰與受信任的存儲文件一起從一個安裝復制到另一個安裝，sppsvc 似乎不再抱怨篡改。HKEY_LOCAL_MACHINE\SYSTEM\WPA

從所有這些工作中，我們學到了以下幾點：

• 產(chǎn)品密鑰和重置計數(shù)等關(guān)鍵激活數(shù)據(jù)存儲在稱為“受信任存儲”的內(nèi)容中

• 受信任存儲的數(shù)據(jù)保存在加密文件中

• 此數(shù)據(jù)以某種方式與HKLM\SYSTEM\WPA

不幸的是，在很長一段時間里，我們對此知之甚少。我對 sppsvc 的舊版本和新版本進行反混淆的工作幫助我們確認了我們的一些理論，但在不了解 的情況下，它們并沒有做出太大貢獻。與此同時，SpCreatePackaedLicense 構(gòu)建了 CID 技巧的自動化版本，使用自定義內(nèi)核驅(qū)動程序來修補 sppsvc，而無需調(diào)整其受保護的進程狀態(tài)，這對測試 CID 技巧有很大幫助。spsys.sys

不過，除此之外，我們基本上擱置了這項工作，轉(zhuǎn)而研究 CLiP，它似乎有更有前途的開發(fā)途徑。

當它泄漏時，它會泛濫

盡管我們主要關(guān)注 Windows 盜版，但我們中的許多 MASSGRAVE 成員也對它的開發(fā)歷史感興趣，或者更具體地說，它的各種預發(fā)布 beta 版本。研究和弄亂這些版本不僅作為一種新奇事物很有趣，而且在開發(fā)過程中留下的工件可以幫助我們了解很多關(guān)于 Windows 工作原理的知識。

在與一些測試版專家討論最近泄露的 Windows 8 版本的激活機制時，我不經(jīng)意間被幾個重大發(fā)現(xiàn)弄得措手不及：

盡管內(nèi)部版本 7792 和內(nèi)部版本 7850 正在開發(fā) Windows 8 的道路上，但它們的內(nèi)部版本號與 Windows 7（內(nèi)部版本 7600）足夠接近，因此我對 spsys 的一些新信息充滿希望。事實上，在內(nèi)部版本 7850 的符號存檔中，我找到了 spsys 的符號以及激活子系統(tǒng)的其余部分。

Build 7792 也有一個完全未混淆的 spsys 版本，就像宣傳的那樣，但沒有符號。另一方面，Build 7850 的 spsys 具有完整的符號和完全混淆。雖然我沒能得到我的蛋糕并吃掉它，但這對仍然是一個非常幸運的發(fā)現(xiàn)，所以我決定用它來弄清楚可信商店是如何運作的。

咒語與詛咒

像往常一樣，幸運的休息時間，這個帶有附加條件。最大的一個是，與任何其他普通的 Windows 版本不同，使用 WinDBG 進行內(nèi)核調(diào)試在版本 7792 上根本不起作用，因為這是 Windows 最早的 ARM 端口之一。

因此，盡管我有一個完全去混淆的 spsys 副本，沒有任何煩人的反調(diào)試功能，但我?guī)缀鯖]有實際調(diào)試它的選項。由于此版本是在 QEMU 中模擬的，我仍然可以選擇使用其內(nèi)置的 GDB 調(diào)試服務器，但這將非常難以使用，因為我必須在內(nèi)存中手動定位內(nèi)核和驅(qū)動程序才能執(zhí)行任何有用的作。幸運的是，我能夠與 Rairii 取得聯(lián)系，由于他在 ARM 上模擬早期 Windows，他對這種調(diào)試方法更加熟悉。

不幸的是，我對 QEMU OS 調(diào)試或 ARM 或非常低級的 Windows 內(nèi)部結(jié)構(gòu)知之甚少，所以他的建議一開始有點難以遵循......

使問題更加復雜的是，我選擇為這個項目編寫自定義工具，使用 GDB 客戶端庫來控制 QEMU 并在加載 spsys 時自動中斷。就像我嘗試自定義工具的大多數(shù)嘗試一樣，這最終是巨大的浪費時間，最終甚至沒有奏效，尤其是由于我對 GDB 缺乏一般經(jīng)驗。在浪費了更多時間嘗試通過其 Python API 向 GDB 添加 Windows 支持之后，我最終硬著頭皮選擇了我所知道的魔鬼，即 IDA Pro 調(diào)試器。

是的，對于調(diào)試內(nèi)核或調(diào)試 QEMU（或者真的任何東西）來說，它是最不“合適”的選擇，但對我來說更重要的是我熟悉它。使用我從內(nèi)部版本 7915 的符號集中抓取和修改的各種內(nèi)核結(jié)構(gòu)，我能夠編寫出一個腳本，該腳本將在各種內(nèi)核函數(shù)上斷點并獲取重要數(shù)據(jù)，例如內(nèi)核基址和加載的內(nèi)核模塊列表。通過以編程方式中斷 ，我甚至可以在加載每個驅(qū)動程序時自動更新模塊列表。IopLoadDriver

然而，即使有了這個監(jiān)控系統(tǒng)，我仍然無法捕捉到加載的時刻。只有在檢查了其加載程序的代碼后，我才發(fā)現(xiàn)了一個有趣的調(diào)用：spsys.sysspldr.sysZwSetSystemInformation

參考 Geoff Chappell 的表格，我看到這對應于 ，當然，它在內(nèi)核代碼中有自己的分支，可以在不調(diào)用 .SystemLoadGdiDriverInSystemSpaceIopLoadDriver

在這個樹枝上也折斷后，我終于可以在它加載后立即接住了！spsys.sys

請注意，所有這些工作最終都實現(xiàn)了如果 WinDBG 正常工作的情況。無論如何，我現(xiàn)在能夠在 7792 內(nèi)部版本加載時捕獲和調(diào)試它，而不會遇到煩人的混淆和反調(diào)試。sxe ld spsys

說到混淆，我仍然需要解壓縮 Build 7850 的 spsys 才能理解它。幸運的是，這要容易得多，因為我可以搜索對加密函數(shù)的調(diào)用位置。

然后，我只需在內(nèi)核調(diào)試器中中斷這些調(diào)用并從內(nèi)存中轉(zhuǎn)儲驅(qū)動程序，然后我就相當輕松地解密了所有代碼。從這里開始，這只是一個通過眼睛傳輸符號的漫長過程，我終于回到了原點。

終于進步了

標記所有函數(shù)后，我注意到代碼中生成受信任存儲文件的一種有趣模式，該文件似乎稱為“物理存儲”。Microsoft 似乎沒有選擇將加密數(shù)據(jù)存儲在單獨的緩沖區(qū)中的典型方法，而是選擇就地進行加密。

這可能會防止某種側(cè)信道攻擊，但更重要的是，這意味著我只需在調(diào)試器中跳過此調(diào)用并讓 spsys 將未加密的內(nèi)容寫入磁盤，即可“解密”物理存儲。因此，我做到了：

asdcorp 和 abbodi1406 立即開始工作，弄清楚數(shù)據(jù)格式以及其中存儲的數(shù)據(jù)類型。與此同時，我專注于在 Windows 10 上復制這個技巧，在那里分析會容易得多，尤其是因為有一個實際的調(diào)試器 （x64dbg） 可用。方便的是，函數(shù) HIDHash 中有一些非常獨特的常量：

在 Windows 10 的 sppsvc 中搜索這些常量后，我在 sppsvc 中找到了相同的函數(shù)：

正如我發(fā)現(xiàn)的那樣，spsys 的大部分代碼最終都包含在 Windows 10 上的 sppsvc 中。通過比較這些代碼庫，我發(fā)現(xiàn)了所有的加密、解密、簽名檢查和哈希檢查例程。在調(diào)試器中修補所有這些例程后，我們不僅可以讓 sppsvc 為我們解密它，還可以加載和接受我們在其中所做的任何修改。data.dat

在測試這些補丁的過程中，我們最終找到了失傳已久的 Redpill 產(chǎn)品密鑰，Redpill 是 Windows 8 測試版的功能鎖定系統(tǒng)。

在一些實驗和我的一些幫助下，asdcorp 設法重現(xiàn)了 CID 技巧，但這次沒有修補 CID 驗證例程。

從這里開始，asdcorp 和 Lyssa 找出并測試了更多的漏洞，包括一種 4000 多年來離線激活 KMS 的方法。

盡管這些結(jié)果標志著重大進展，但我們?nèi)匀恍枰褂谜{(diào)試器來測試這些方法，因為我們無法自己解密和重新加密物理存儲。因此，我的下一個任務是弄清楚如何做到這一點。

私鑰派生

通過查看 spsys，我知道我需要派生的唯一真正密鑰是 RSA 密鑰，它對加密物理存儲數(shù)據(jù)的 AES 密鑰進行加密。我還從使用 asdcorp 進行的測試中了解到，只有兩個這樣的密鑰：一個用于生產(chǎn)/官方測試版，一個用于內(nèi)部測試/Windows Insider 版本。在沒有原始密鑰數(shù)據(jù)的情況下，我們通過一種非常先進的方法發(fā)現(xiàn)了這一點：復制物理存儲文件，編輯其版本，然后等待 sppsvc 可怕地崩潰，表明它可以解密但不能解析交換的文件。

檢查名為 的 RSA 解密例程，我發(fā)現(xiàn)了一個稱為 的字節(jié)碼系統(tǒng)的解釋器。通過大量的苦差事和正則表達式，我能夠用 Python 編寫該系統(tǒng)的模擬器。SpModExpPrvExecCodes

觀察這個模擬的輸出，我意識到所有這些混淆都掩蓋了我以前隱約聽說過的一種技術(shù)，稱為加法鏈冪運算。經(jīng)過一番思考，我意識到我可以跟蹤和轉(zhuǎn)儲每個模乘法的輸入和輸出，并使用它來派生私鑰。只需要 x64dbg 日志記錄和幾行 python：

最后，我擁有了從 Windows Vista 到 Windows 11 的所有 SPP 的完整生產(chǎn)密鑰。

由于模乘法的實現(xiàn)方式存在一些奇怪的差異，因此派生測試密鑰需要更長的時間，但最終，我們擁有了我們需要的所有 SPP 私鑰。

釘棺材

有了私鑰，我們就能夠輕松激活幾乎任何我們想要的版本。不過，仍然存在一點麻煩，那就是獲取通用密鑰以啟用激活。

在 Windows 8 及更高版本上，為您想要的任何版本的任何通道生成通用密鑰都相當簡單。但是，Windows 7 和 CSVLK（KMS 主機密鑰）直到 Server 2022 都使用 PKEY2005，這是一種更復雜的編碼系統(tǒng)，需要私鑰來生成通用密鑰。由于我沒有任何加密技巧，因此我們決定解決此問題的最佳方法。

在物理存儲中，每個產(chǎn)品密鑰都有大型 blob，其中包含各種預先計算的信息，例如產(chǎn)品 ID 和手機激活數(shù)據(jù)。此外，我們發(fā)現(xiàn)令牌存儲 （） 還包含將產(chǎn)品密鑰與當前版本的 Windows 相關(guān)聯(lián)的元數(shù)據(jù)。因此，我們認為，只需復制此數(shù)據(jù)就足以欺騙 Windows 認為已安裝密鑰，而這一次，我們是對的。tokens.dat

與此同時，在為新的 CID 技巧（我們現(xiàn)在稱為 ZeroCID）開發(fā)編程方法時，我們在處理需要寫入物理存儲的 HWID 數(shù)據(jù)時遇到了問題。最初，我們嘗試使用 GatherOsState 的 HWID 派生的 C# 端口，但在極少數(shù)情況下最終無法驗證。由于我們幾乎沒有選項來調(diào)試或修復此端口，因此 asdcorp 決定創(chuàng)建一個適用于所有硬件的 HWID 值，而且它再次運行良好，甚至允許在機器之間傳輸激活。

隨著 HWID 驗證和 PKEY2005 的失敗，我們現(xiàn)在幾乎完全擊敗了 SPP 的離線保護。

結(jié)束語

即使我們能夠使用調(diào)試器和十六進制編輯器對 SPP 造成如此多的損害，我仍然認為它是一個相當先進且構(gòu)建良好的 DRM 系統(tǒng)。它的內(nèi)部結(jié)構(gòu)肯定比 Windows XP 的 DRM 有所改進，盡管有些人可能會告訴你，但 DRM 的設計相當糟糕。它還能夠很好地保護自己免受最常見的攻擊，例如通過交換物理存儲文件來重置評估計時器。此外，SPP 還有一些部分我們尚未成功破解，例如用于定義其行為的簽名 XML 許可證。畢竟，并不是說有另一個微不足道的補丁可以繞過他們的簽名檢查......

學分

核心研發(fā)

• WitherOrNot - 領(lǐng)導工具開發(fā)、逆向工程、測試

• asdcorp - 初始演示、逆向工程、工具開發(fā)、測試

• abbodi1406 - 逆向工程、開發(fā)、測試

• Lyssa - 逆向工程、工具開發(fā)、測試

其他貢獻

• SpCreatePackaedLicense - 工具開發(fā)、測試

• 5 月 - 代碼格式化、構(gòu)建設置

特別鳴謝

• BetaWiki - 記錄用于逆向工程的泄露測試版

• Rairii - 協(xié)助初始逆向工程工作

• Microsoft - 有趣的挑戰(zhàn)