[C#] Calculating an Office Product Key By Advanced PID

Discussion in 'Mixed Languages' started by CODYQX4, Jan 30, 2011.

  1. CODYQX4

    CODYQX4 MDL Developer

    Sep 4, 2009
    4,803
    45,234
    150
    We have key checkers and they return lots of info.

    One thing I noticed is that when checking keys (sample output)

    Product Key: CENSORED
    Validity: Valid
    Product ID: 82503-566-0042044-48650
    Advanced PID: 82503-00096-566-004204-03-1033-7601.0000-0292011
    Activation ID: fdf3ecb9-b56f-43b2-a9b8-1b48b6bae1a7
    Product Description: RTM_ProPlus_MAK
    Edition Type: ProPlusVL
    Edition ID: X16-08116
    Key Type: Volume:MAK
    Eula: ltMAK

    is that the Product ID: part can vary, but the Advanced PID Part is ALWAYS the same. There is also convenient WMI function in OSPPSVC that returns Advanced PID's for all your installed keys.

    I need to be able to tell what keys are installed (All 25 digits not 5) to be able to implement a new backup/restore system that could work after a reformat as it involves reinstalling the keys. There has to be some kind of process to convert this to a 25 digit key given its uniqueness and doing so would be of great use.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  2. Calistoga

    Calistoga MDL Senior Member

    Jul 25, 2009
    420
    198
    10
    I don't know how to decode the Advanced PID, but would it be an alternative solution to decode the DigitalProductId's?

    1. Get all entries under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\
    2. Match all the entries against regex \d{2}\.\d (eg. 10.0 (Office XP) or 12.0 (Office 2007) etc.)
    2. a) All matched entries represents an Office version, for each of them ...
    3. Open key > eg. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\Registration\[GUID]\DigitalProductId
    3. a) You could just use a regex to check if it's a GUID, or you could hard code the GUID constants.
    4. Decode the DigitalProductId for each product.

    This approach would even be WMI independent :smilie1:
     
  3. CODYQX4

    CODYQX4 MDL Developer

    Sep 4, 2009
    4,803
    45,234
    150
    This is how regular Key Checkers work (I actually have code that does this). The problem is that this DigitalProductId is not reliable. It can be deleted or not up to date (matter of fact, the only time it gets updated is if you install keys via office setup, so scripts and stuff don't update it (this means if you installed VL KMS and installed MAK via any means other than setup.exe, that the key will still be KMS according to key checker).

    I had hoped the Advanced PID was what got the key, but there is a value there stored in base 24 that is the key, so all the PID's are useless for our purposes.

    We'll just have to prompt for keys, as if we could detect the key by means I planned, then the way MS provides to make keys undetectable (by clearing from the registry) would be useless. Maybe it's possible that the keys are stored in tokens or trusted Store but this stuff is probably encrypted if so anyway.

    ... and the use for WMI was to get all Advanced PID's for installed keys, with the hope that you could get the product key from it. WMI isn't needed to read DigitalProductId at all.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...