I believe we will not see this time mini-kms, because that the whole traffic between Host & Client is crypted
It was designed by men not by gods Why not, we have both a server and a client, we only need a russonivellian to determine what dll function is encrypting/decrypting. If these two OS's can figure out how to do it without talking to MSFT, it is only a matter of time before someone figures out how the OS is doing it and duplicates it. MSFT seems to say the same thing every few years, this new scheme will never be broken, yada yada yada. It's a sales and marketing gimmick, nothing more.
Everything can be broken. If someone can code it, someone can decode it, its just a matter of time thats all
Behold, to be broken one must cast it into the fires from once it was forged, only then will it be unmade.
Wait! According to this "genius" is here! : I was browsing Microsoft Software Protection Platform Service for about a month now and nothing useful (related to the main function) is there.
Maybe the reason you can't find it in sppsvc.exe is cause they aint in there. My guess is you need to be looking in advapi32.dll. Found this in about 5 minutes. Now we just need access to a server + client + process monitor running on both to figure out what order we need to access them. Do we programatically "getHashParam" first, or CryptCreateHash first, then call CryptSignHashA or what is the order. For all we know, we start with CryptGenKey and go from there. You get my drift, it can be done, and will be much easier once someone has both sides of the equation under microscope takes a look. Code: 00782048 CryptGenRandom ADVAPI32 0078204C CryptAcquireContextW ADVAPI32 00782050 CryptReleaseContext ADVAPI32 00782070 CryptGetHashParam ADVAPI32 00782074 CryptVerifySignatureA ADVAPI32 00782078 CryptSignHashA ADVAPI32 0078207C CryptDecrypt ADVAPI32 00782080 CryptEncrypt ADVAPI32 00782084 CryptImportKey ADVAPI32 00782088 CryptExportKey ADVAPI32 0078208C CryptDestroyKey ADVAPI32 00782090 CryptGenKey ADVAPI32 00782094 CryptDestroyHash ADVAPI32 00782098 CryptHashData ADVAPI32 0078209C CryptCreateHash ADVAPI32
I was thinking more along the lines of front-ending it. SPPSVC.exe is a KMS front-end for lack of a better term. We need a MDLSVC.exe to replace SPPSVC.exe on the server side and it can use built-in MSFT encryption to send the data in the approved format that the client is expecting. Once we know the handshake procedure our middleman service could in theory impersonate a KMS host and send a key for the client to encrypt with (which we could obviously decrypt upon return packet), my assumption is that the key is generated at the server because the server needs to be able to communicate with any random machine that attempts to contact it. Could be nice and neat and run from 127.0.0.1
Why doesn't anyone run the Windows 8 client and the Windows Server in debugged mode to see if that helps?
I'm curious, does a KMS host contact to MS after it's initial activation? I mean, it's possible to have a kms host on a private intranet?
Maybe it is but I read somewhere that kms host contact MS from time to time, just want to know if someone has a little more info and not just a rumor.
Of course it checks for updates as any other Windows system, so at least for that it contacts MS, but i don't think it'd check something special for KMS, anyway it doesn't need internet connection (after activation) and to contact MS in any other way to eternally function as KMS host in local network space.
This looks like a giant step forward in the activation stakes, really hope it can be made smaller and we can run our own vhd
As I understand it: You active the Host as ususal. Then add the KMS service and Host key, which also has to be activate with MS. Then all systems Server and Clients check their activation status as normal (180 days or so) with their Activation Server which in the case of the KMS Host Server may well be MS.
Not entirely true... U activate the OS with the KMS HOST key, once a KMS HOST key is inserted the OS automaticly enables the KMS Service
OK, now things make alittle more sence. So are there different Host keys for OS/KMS Activation and just KMS Activation ? My SVR2008 R2 is activated already and when I tried to install the KMS service it asked for the KMS Host key. Which I guess will change the type of licence its running ???
AFAIK it will only change the type of License which is running if the Host-Key is for running OS. A Host-Key for an other type Licenses will not affect the running Licenses.
A KMS host key for Windows will work as both a license for the OS and enable it to work as a KMS. It will replace the previous OS license, so it doesn't matter if it was activated or not. A host key for Office will be installed as an additional license that only allows it to activate Office KMS clients, and it won't activate the host OS. You can run "slmgr.vbs /dlv all" to view all the available licenses, and it will show the KMS host license as well. It just isn't active and shows up as "not in use" until a KMS host key is entered and activated.
Thats THE crypto library, controlling this, you control the whole m$ crypto system (even the EFS, which catch my attention for awhile till I give up). The KMS 'system' exchange with this dll but it seems its a lil complex, at least to me, understand this dialog. The KMS 'idea' (based on the russians work/hack, like the did with enterprise on 7) seems a good start but in some point has no sense, I mean, you need to run something every 180 days, for the rest of this system life, to validate your system and I want something more definitive.