Unfortunately the algorithm or binary position are wrong, entered 3 Office 2010 CD-Keys today in 3 new Laptops we bought and tested this code but all 3 were displayed wrong. Anyone is confident enough with OllyDbg to find the function address that office uses to "encode" the key in registry?
see this: http://forums.mydigitallife.net/thr...tal-Product-ID?p=462428&viewfull=1#post462428 MAK keys will NOT be displayed they are wiped from registry. You will get BBBBBBBBB or a KMS key.
Algorithm seems to be wrong I didn't use MAK or KMS keys. As I mentioned we got 3 nice plastic boxes which contained 3 DIFFERENT Office keys. When running the "decryption" code , I see a key which is completely different than the one just entered to activate Office.
That worked. Thank you CODYQX4 and Josh Cell! For posterity: The location was HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\14.0\Registration\{90140000-110D-0000-1000-0000000FF1CE}. In the code that Josh Cell posted above, change strKeyPath = "SOFTWARE\Microsoft\Office\14.0\Registration\{90140000-0011-0000-0000-0000000FF1CE}" to strKeyPath = "SOFTWARE\Microsoft\Office\14.0\Registration\{90140000-110D-0000-1000-0000000FF1CE}" Since I did not have any [real] Office Apps installed I was getting a vbscript 800a0009 subscript out of range error on line 13...because the array was empty because I wasn't pointing to the right location. Simply editing as I noted above resolved the issue and displayed the key. Nice work guys!
I posted the source code to the keyfinder (MSKEY) I originally wrote in 2007. I have since updated it to find Keys for Windows XP, Vista, 7, Office 2000, XP, 2003, 2007, and 2010. It is true though that if you originally have a KMS installation, and then update the product key to MAK, it will NOT be in the registry. I wrote my code to supplement a GUI version I made that works on remote hives (which is giving me issues atm), and therefore it will get the keys INDEPENDENT of operating system architecture, for BOTH 64bit and 32bit. The code is in this post Hopefully that helps you guys out. And with some luck, maybe someone can shed some light on the tokens.dat, or other locations for the activation information of Office 2010.
It's wierd, I used the Office 2010 offsets (808-822) to decrypt the 'DigitalProductId4' in LocalMachine\Sofware\Microsoft\Windows NT\CurrentVersion and it returned the same Product Key used to install my Windows. The same one using offsets (52-67) for the Windows DigitalProductId.
There are no "Office offsets" and "Windows offsets". There are 2 types of Product ID structures in Microsoft software: DigitalProductID and DigitalProductID4. The DigitalProductID4 structure is more complex and contains more data. I'm not sure why but Office uses only DigitalProductID4 structure to keep registration data but it is stored in value called (sic!) DigitalProductID instead of "proper" DigitalProductID4. This is a bit weird but you can just read Office's DigitalProductID value like you do with Windows' DigitalProductID4 - It's the same procedure, with the same "offsets" but with different value names. I suggest using only 808-822 offsets to read both Windows and Office keys but using different value names - this is the simpliest and shortest way to do it.
I know this thread has been inactive for quite some times but just in case an expert can provide information … I have developed a tool, probably based on code provided in this thread, that decodes the Windows/Office product id https://forums.mydigitallife.net/threads/kmspico-official-thread.65739/page-389#post-1460049. It works fine for Windows 7 / 8 /10 (x64 or x86) or Office 2010 / 2013 / 2016 (x64 or x86) products but is broken for Office 2019 Seems that Office 2019 uses a very different key structure in the registry. Actually, I did a search on DigitalProductID in the registry and could not found anything related to Office 2019. Does anybody knows where this key has been moved and a more generally where can I find a description of the key structure in the registry for Office 2019. May be this is related to the fact that installation is now based on C2R instead of MSI?