I have little knowledge of the details of the activation, but if private keys are impossible to crack is it possible to exchange the certificates in the client?
The certificate is built in system executables, not in a separate replaceable file/registry. So one would need to patch important system files. From the point of view of a battle of wits between attackers and protectors, the patching means admitting defeat. From the practical point of view, the patching comes with a lot of drawbacks. Less importantly, winlogon.exe/licdll.dll have a number of internal checks to protect the important data, including the certificate, so one would either need to patch out those as well, or be extra careful to make a replacement certificate with the same checksum as the original one (which might be possible). More importantly, patching a system file automatically means problems with system protection mechanisms like SFC, with updates, with antiviruses, with WGA checker, leaves easily detectable traces of intrusion. It could work if it would be the only way to go (IIRC some early anti-WPA hacks did patch winlogon.exe, although not in this way), but it makes no practical sense in presence of other anti-WPA methods that won't provide a validatable activation in this concrete way but do provide a better solution of the problem as a whole.
Well, I don't think cracking an RSA-1024 key is a realistic outlook. But then again I haven't found any recent numbers on the computation cost. So the two options left is either to find a flaw in the client logic so that it will accept stuff signed with a fake key or to steal the keys from Microsoft.
Please read the forum rules, especially 3.3 and 3.6. Thank you. https://forums.mydigitallife.net/threads/forum-rules.18562/
I've looked into DPCDLL122Func() a bit more and wish to adjust the struct and enum. Code: enum LicenseType : DWORD { // matches the license type field in DigitalProductId3 LT_RETAIL, LT_UPGRADE, LT_OEM, LT_VOL, // volume license (previously Microsoft Select) LT_MLP, // Microsoft License Pack for stuff like CALs probably? LT_MOLP, // Microsoft Open License Program LT_MSDN }; struct Lic { DWORD dwIndex; // index into the license index struct BlessedLic { // BlessedLic is signed DWORD dwId; // always same as dwIndex in practice DWORD dwBinkId; // ID of the relevant BINK DWORD dwMinSiteId; // minimum channel/site ID DWORD dwMaxSiteId; // maximum channel/site ID LicenseType dwLicenseType; // type of license DWORD dwDaysToActivate; // time to activate before OS stops working, 0x7fffffff for no activation needed DWORD dwTrialDays; // time for a trial installation before it disables itself } blessed; DWORD dwSignatureLength; // signature length in bytes CONST BYTE *pabSignature; // signature }; HRESULT WINAPI DPCDLL122Func(DWORD dwBinkId, DWORD dwSiteId, DWORD dwBuildId, struct Lic *pLic); The license type enum actually matches what's in use with pidgen.dll. The Lic struct has a signature. The "blessed" sub-struct is signed. The signature uses RSA-1024 with PKCS#1 padding and SHA1. The public key is stored as a CryptoAPI blob in winlogon.exe, which also makes it the apparently only caller that I know of. To save you some trouble, here's an example taken from XP volume license dpcdll.dll (same signing key used for other languages as well; not sure if retail shares the same key or even the entire struct list, but it probably shares both; not sure if 2003 shares the same key, but it probably doesn't): Code: #!/usr/bin/env ruby # frozen_string_literal: true require 'base64' require 'openssl' # winlogon.exe @ 0x1016cb8, converted from blob to PEM PUBKEY = <<EOK -----BEGIN PUBLIC KEY----- MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCsKGLtQ8bUveKs8GYDs+/b+Vs2 tG3btT2g/ZSI9ExWXZCTyrnsxdMIoiyEFovYulodzu60QReEree3szKnpobay04c qpqr4n3IfFUaWpOYCFtdKosgQrCsKoXNN+w3rqz4UxAAE0LEZvci0+Qo22/VRKSo sOX+w8C+8ss1KhxsJwIDAQAB -----END PUBLIC KEY----- EOK # This is the data of a struct Lic. # The pointer to the signature is 0x012d89b0 for demo. # # struct Lic { # .dwIndex = 0x0e, # .blessed = { # .dwId = 0x0e, # .dwBinkId = 0x28, # .dwMinSiteId = 5, # .dwMaxSiteId = 110, # .dwLicenseType = 3, // LT_VOL # .dwTrialDays = 14, # .dwTrialDays = 125 # }, # .dwSignatureLength = 0x80, # .abSignature = 0x012d89b0 # }; lic = Base64.decode64('DgAAAA4AAAAoAAAABQAAAG4AAAADAAAADgAAAH0AAACAAAAAsIktAQ==') signed = lic[4...(4+(7*4))] signature_encoded = <<EOSIG KhS4yXIrs9bISyve8GadyYtfvE5G2ynvxJbFPfuUbMGi7VqC5wBoQpw1N9/F c4g9lkPDl0UbtnPDgMAalRs4BJ667yscrOI8bocE3NB96FiyqB0lfIEKJeWU kZbQbCfYcxi7/P4WLDLbMjJAE9CPx78TBfkt74XjXFON1TOHa1w= EOSIG # reverse the bytes in the signature because OpenSSL uses big-endian numbers, # but OpenSSL uses little-endian signature = Base64.decode64(signature_encoded).reverse rsa = OpenSSL::PKey::RSA.new(PUBKEY) puts(rsa.verify('SHA1', signature, signed)) # true You won't be able to sign your own dpcdll.dll structs. Breaking RSA-1024 is computationally infeasible (Schnorr's recent paper has been debunked).
I’ve taken a minute to read through this entire thread, and given how old XP is (and out of support), one would’ve figured that all the product key, activation, etc would’ve been cracked and keygens would be commonplace. However, with my limited understanding of cryptography the larger the bit count, the harder it is to decrypt. (Again limited understanding), so I might not see MS legacy products keygens in my lifetime by the looks of it.
what do you mean by that? nowadays we can crack the private keys of the bink resources of pidgen.dll in a matter of twenty minutes (for Windows 98FE/SE, ME, 2000, XP, server 2003, pre- and early post-reset Longhorn/Vista) with which we can reliably generate a product key. (if you cannot figure out how, ask sk00ter) furthermore, the phone activation procedure (for non vlk copies of Windows XP and Server 2003) has also been cracked (see diamondggg's keygen, available on request). This allows us to keygen telephone activation for all non-vlk copies of Windows between Windows XP build 2600 (pre-RTM builds of Windows XP do not work woth said keygen, I already tried it) and early Windows Vista post reset builds (including Server 2003, XP 64-bit/x64 and pre-reset Longhorn) Sure, there is no fully publicly known method (that I know of) to crack phone activation except that one closed source tool of unknown origin from diamondggg, but I would confidently say that Windows XP's and Server 2003's WPA is pretty busted. And that is before I even talk about AntiWPA. Adressing some misinformation that I may have spread in this thread: I would like to add that the Windows XP/2003 keygen from github that I mentioned indeed does not compile a working binary on Linux, however it does in MinGW32 and MSYS2's MinGW64 under Windows. I do not actually know the cause of this, but I suspect that the default compiler options of gcc in ubuntu and manjaro mess something up. Also, I claimed once that pidgen code was not included in the source code leak last year. That is kinda true for Server 2003, but not for the Windows XP SP1 build tree where it was included.
Well… I learn something new every day. I will be sending appropriate requests to the people involved to get copies of the appropriate keygens . @diamondggg; would be the person for the phone actuation keygen I wonder who the appropriate person would be for the keygen for just the product keys? Further, what I meant by my comment is somebody mentioned an RSA-1024 encryption key involved with the phone activation… My basic understanding is that RSA is rather hard to crack, and with that many bits one would figure that there would be so many possibilities… That one would have to keep counting Ansari eventually breaks. Again, this is probably due to very outdated knowledge as I am not familiar with the capabilities of much modern hardware, it could also be pure misunderstanding on my side.
I believe you can activate these legacy products now with telephone activation because microsoft has altered the telephone system. I don't think it actually cares anymore what product key you use, it just spits out an Confirmation ID that will activate the product, no questions asked and not because the so called keygens produce valid (valid in the sense that MS believes them to be valid) product keys.
Is it the following one? Code: CRC-32: 0fb1bab6 MD5: db8dfc80e136a28655d148a077e72205 SHA-1: 26632479f9bdde172f47d23902c3e7caaabe2b4f SHA-256: 5a4bcac5a50eb5113dd6a2f88c35ebdb709c4df8a792c71ad03ea347afaced52 Tagging @LostED as well.
Why do we have to use retail & OEM XP in 2023？ Shouldn't VL mode be better? Although you uploaded a bunch of activations, the crack program is used to activate xp.... In other words, Microsoft will not be so stubborn. I believe that in the era when XP was released, Microsoft's download center provided an official tool that could authorize conversion, only for XP
I believe there are some that still use it ... now I downloading ... this iso. to check the new tool en_windows_xp_professional_with_service_pack_3_x86_cd_x14-80428.iso I think most of the guys maybe forget this tool exists. from the old era...