I have [valid] reasons to believe that MGAdiag may not always output the correct PK, and concurrently the reliability of Legit*.dll may be affected.
Based on preliminary tests performed on well known black-listed VLK , the result of the actual key entered, as well as several official third party tools [used to parse the PK] pruduced identical output, whereas MgaDiag produced another... (ie: completely different product key!) However the PID was consistent across all sessions.
As a quick demonstartion of the actual PID/PK: PID: xxxxx-648-xxxxxxx-23xxx PK: xxxxx-xxxxx-xxxxx-xxxxx-PRXDB
And MgaDiag.exe produced: Windows Product Key: *****-*****-xxxxx-xxxxx-GH71H
Note: When the relevant offset(s) is decrypted under 'DigitalProductId' value in the registry, the result coordinated with the aforementioned steps/tools - with the exception of MgaDiag!
It should make no difference whether the volume was Genuine/[non], whether the key was made by non-Microsoft sanctioned keygen, or if the PID is blocked (as reported.)
The actual product key should have been reported , but was not! None of the last 15 chars reported by MGA matched the "actual" key!
I'd hate to think of the consequences for *everyone involved, especially genuine users/volumes being told they have certain PK, yet they have another... (ie: genuine being misinterpreted as invalid ) -- which I've yet to reproduce (in this context)
