[INFO] Tout (ou presque) sur les clefs de produits Microsoft, et script VIEWPK pour afficher ces clefs
34 réponses
Jean-Claude BELLAMY
Hello World!
Je me suis "plongé" dans les clefs de produits Microsoft (Windows, Office,
FrontPage, Visio,..) afin de mieux comprendre :
- les subtilités entre ProductID, ProductKey, RAWkey,
- les endroits où elles sont stockées (dans la BDR)
- les liens entre elles.
- comment les retrouver/calculer
C'est une partie de Windows qui n'est pas du tout documentée par Microsoft
...
(RIEN dans le MSDN , y compris sa version DVD complète)
La seule doc un peu explicite que j'ai pu trouver à ce sujet sur le NET est
cet unique document :
http://www.licenturion.com/xp/fully-licensed-wpa.txt
A cet effet, j'ai conçu un script VIEWPK.WSF, lequel, en ligne de commande,
détermine, à partir des clefs "...\...\DigitalProductID", la valeur de la
"ProductKey" (clef de produit) sous la forme 5x5 :
xxxxx-xxxxx-xxxxx-xxxxx-xxxxx
Chaque caractère fait partie de l'ensemble BCDFGHJKMPQRTVWXY2346789
Par défaut il examine le "DigitalProductID" de Windows, mais il est capable
de trouver et analyser ces clefs pour tous les produits Microsoft. (Office,
FrontPage, Visio, ...)
Ce script affiche aussi la "RAWkey" correspondante (valeur binaire, exprimée
en hexadécimal, en notations "little endian" et "big endian")
Inversement, il sait aussi convertir une RAWKey en ProductKey.
Enfin il sert à calculer (partiellement) le ProductID à partir de la
ProductKey ou de la RAWkey (pour Windows).
http://www.bellamyjc.org/fr/vbsdownload.html#viewpk
(il fonctionne sous W2K PRO/W2K SRV/XP HOME /XP PRO/W2K3, et même sous NT4
mais avec un intérêt réduit vu qu'il n'y a pas de ProductKey sous NT4)
Certains d'entre vous vont peut-être se demander ce qu'il apporte par
rapport à :
- "Everest" (ex "Aida32") (maintenant payant! la version
gratuite ne donne plus les clefs!)
http://www.lavalys.hu/index.php?lang=en
- "KeyFinder",
http://www.magicaljellybean.com/keyfinder.shtml
- sans oublier "WinInfoKeys" de Pierre TORRIS...
http://www.ptorris.com/index.htm?prgscod.htm&winfokeys
Et bien :
- il fonctionne A DISTANCE
- il affiche ProductKey, RAWKey, ProductID,...
- il permet de tester des ProductKey en calculant
leur ProductID (nombres centraux)
- il est en français
- il a surtout un intérêt PÉDAGOGIQUE, car étant un script
WSF, son code est accessible immédiatement, et est
donc MODIFIABLE/AMÉLIORABLE très facilement par
l'utilisateur si le besoin s'en fait sentir.
J'ai donc écrit sur mon site un paragraphe sur ces Clefs de produits, où
j'expose les principaux algorithmes utilisés, ...
Mais il existe encore des zônes d'ombre !!!
(p.ex. l'algorithme donnant le ProductID à partir de la ProductKey pour MS
Office, qui n'est pas celui pour Windows)
Bonne lecture...
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
Jean-Claude.Bellamy@wanadoo.fr * JC.Bellamy@free.fr
Bonjour j'ai tester pour moi ça marche bien Par contre j'ai essayé de l'intégrer dans un autre script pour cheker tous les ProductID de mon reseau et rediriger le resultat dans un fichier log pour l'importer dans excel et voir s'il y a des doublons mais le >> n'est pas pris en compte qqu peut il me donner une solution
Euh... je vais peut-être dire une connerie, mais je me lance...
La redirection (>) dans une commande (pour les scripts je suis pas sûr) impose un espace avant et un espace après le signe ">". D'autre part, le signe ">" va créer un nouveau fichier. Si le fichier existe déjà, et qu'on veut ajouter quelque chose à ce fichier, on le double (>>).
Donc : - le fichier n'existe pas encore : VIEWPK.WSF /e:T /c:%computer% > monfichier.txt
- si le fichier existe déjà et qu'on veut l' "augmenter" : VIEWPK.WSF /e:T /c:%computer% >> monfichier.txt
Dernière chose : il est possible que cette action ne puisse être faite sur un fichier présent sur le réseau (problème de droits d'accès pour une commande de script ?)
Der des ders : c'est bien sharereseau le nom de l'ordi où tu veux stocker le résultat ? Il faut pas indiquer un nom de partage de dossier ? (même si le dossier c'est la racine ? sharereseauCmonfichier.txt ?)
-- Ypoons [MVP] Ne vous approchez jamais d'un ordinateur en disant ou même seulement pensant "Je vais faire ça très vite !" Pour m'écrire : http://www.cerbermail.com/?Qw7yVJONCF Ne me mettez pas dans votre carnet d'adresse ! Je suis spammé !
Bonjour
j'ai tester pour moi ça marche bien
Par contre j'ai essayé de l'intégrer dans un autre script pour cheker tous
les ProductID de mon reseau et rediriger le resultat dans un fichier log
pour l'importer dans excel et voir s'il y a des doublons mais le >> n'est
pas pris en compte
qqu peut il me donner une solution
Euh... je vais peut-être dire une connerie, mais je me lance...
La redirection (>) dans une commande (pour les scripts je suis
pas sûr) impose un espace avant et un espace après le signe ">".
D'autre part, le signe ">" va créer un nouveau fichier. Si le
fichier existe déjà, et qu'on veut ajouter quelque chose à ce
fichier, on le double (>>).
Donc :
- le fichier n'existe pas encore :
VIEWPK.WSF /e:T /c:%computer% > monfichier.txt
- si le fichier existe déjà et qu'on veut l' "augmenter" :
VIEWPK.WSF /e:T /c:%computer% >> monfichier.txt
Dernière chose : il est possible que cette action ne puisse être
faite sur un fichier présent sur le réseau (problème de droits
d'accès pour une commande de script ?)
Der des ders : c'est bien sharereseau le nom de l'ordi où tu veux
stocker le résultat ? Il faut pas indiquer un nom de partage de
dossier ? (même si le dossier c'est la racine ?
\sharereseauCmonfichier.txt ?)
--
Ypoons [MVP]
Ne vous approchez jamais d'un ordinateur en disant ou même
seulement pensant "Je vais faire ça très vite !"
Pour m'écrire : http://www.cerbermail.com/?Qw7yVJONCF
Ne me mettez pas dans votre carnet d'adresse ! Je suis spammé !
Bonjour j'ai tester pour moi ça marche bien Par contre j'ai essayé de l'intégrer dans un autre script pour cheker tous les ProductID de mon reseau et rediriger le resultat dans un fichier log pour l'importer dans excel et voir s'il y a des doublons mais le >> n'est pas pris en compte qqu peut il me donner une solution
Euh... je vais peut-être dire une connerie, mais je me lance...
La redirection (>) dans une commande (pour les scripts je suis pas sûr) impose un espace avant et un espace après le signe ">". D'autre part, le signe ">" va créer un nouveau fichier. Si le fichier existe déjà, et qu'on veut ajouter quelque chose à ce fichier, on le double (>>).
Donc : - le fichier n'existe pas encore : VIEWPK.WSF /e:T /c:%computer% > monfichier.txt
- si le fichier existe déjà et qu'on veut l' "augmenter" : VIEWPK.WSF /e:T /c:%computer% >> monfichier.txt
Dernière chose : il est possible que cette action ne puisse être faite sur un fichier présent sur le réseau (problème de droits d'accès pour une commande de script ?)
Der des ders : c'est bien sharereseau le nom de l'ordi où tu veux stocker le résultat ? Il faut pas indiquer un nom de partage de dossier ? (même si le dossier c'est la racine ? sharereseauCmonfichier.txt ?)
-- Ypoons [MVP] Ne vous approchez jamais d'un ordinateur en disant ou même seulement pensant "Je vais faire ça très vite !" Pour m'écrire : http://www.cerbermail.com/?Qw7yVJONCF Ne me mettez pas dans votre carnet d'adresse ! Je suis spammé !
Gloops
Salut,
Dans une session en ligne de commandes, je viens de taper DIR>LIST.TXT TYPE LIST.TXT Et j'ai bien vu le répertoire défiler.
Donc, je dirais bien que les espaces ne sont pas obligatoires autour du caractère de redirection.
Il est permis de penser que le programme n'écrit pas sur la sortie standard, mais sur la sortie d'erreur, ou encore directement à l'écran par un procédé plus sophistiqué.
Certains systèmes (Unix je crois) permettent de rediriger la sortie d'erreur, par une syntaxe du style
commande 1>standard.txt 2>erreur.txt
Je n'affirmerais pas avoir vu ça dans la doc Windows, mais si je tape dans une session ligne de commandes DIR 2>erreur.txt
je vois bien défiler le répertoire, et un fichier vide erreur.txt est créé. Si je tape DIR 2, aucun fichier n'est listé. ça laisse entendre que la syntaxe est reconnue.
Je n'ai pas à l'esprit là tout de suite une commande qui écrive dans la sortie d'erreur, enfin bon, "p'us qu'à" essayer ... En espérant que le programme visé écrive bien dans la sortie d'erreur. _____________________________________ Ypoons a écrit, le 13/10/2005 03:34 :
Bonjour j'ai tester pour moi ça marche bien Par contre j'ai essayé de l'intégrer dans un autre script pour cheker tous les ProductID de mon reseau et rediriger le resultat dans un fichier log pour l'importer dans excel et voir s'il y a des doublons mais le >> n'est pas pris en compte qqu peut il me donner une solution
Euh... je vais peut-être dire une connerie, mais je me lance...
La redirection (>) dans une commande (pour les scripts je suis pas sûr) impose un espace avant et un espace après le signe ">". D'autre part, le signe ">" va créer un nouveau fichier. Si le fichier existe déjà, et qu'on veut ajouter quelque chose à ce fichier, on le double (>>).
Donc : - le fichier n'existe pas encore : VIEWPK.WSF /e:T /c:%computer% > monfichier.txt
- si le fichier existe déjà et qu'on veut l' "augmenter" : VIEWPK.WSF /e:T /c:%computer% >> monfichier.txt
Dernière chose : il est possible que cette action ne puisse être faite sur un fichier présent sur le réseau (problème de droits d'accès pour une commande de script ?)
Der des ders : c'est bien sharereseau le nom de l'ordi où tu veux stocker le résultat ? Il faut pas indiquer un nom de partage de dossier ? (même si le dossier c'est la racine ? sharereseauCmonfichier.txt ?)
Salut,
Dans une session en ligne de commandes, je viens de taper
DIR>LIST.TXT
TYPE LIST.TXT
Et j'ai bien vu le répertoire défiler.
Donc, je dirais bien que les espaces ne sont pas obligatoires autour du
caractère de redirection.
Il est permis de penser que le programme n'écrit pas sur la sortie
standard, mais sur la sortie d'erreur, ou encore directement à l'écran
par un procédé plus sophistiqué.
Certains systèmes (Unix je crois) permettent de rediriger la sortie
d'erreur, par une syntaxe du style
commande 1>standard.txt 2>erreur.txt
Je n'affirmerais pas avoir vu ça dans la doc Windows, mais si je tape
dans une session ligne de commandes
DIR 2>erreur.txt
je vois bien défiler le répertoire, et un fichier vide erreur.txt est
créé. Si je tape DIR 2, aucun fichier n'est listé. ça laisse entendre
que la syntaxe est reconnue.
Je n'ai pas à l'esprit là tout de suite une commande qui écrive dans la
sortie d'erreur, enfin bon, "p'us qu'à" essayer ...
En espérant que le programme visé écrive bien dans la sortie d'erreur.
_____________________________________
Ypoons a écrit, le 13/10/2005 03:34 :
Bonjour
j'ai tester pour moi ça marche bien
Par contre j'ai essayé de l'intégrer dans un autre script pour cheker
tous les ProductID de mon reseau et rediriger le resultat dans un
fichier log pour l'importer dans excel et voir s'il y a des doublons
mais le >> n'est pas pris en compte
qqu peut il me donner une solution
Euh... je vais peut-être dire une connerie, mais je me lance...
La redirection (>) dans une commande (pour les scripts je suis pas sûr)
impose un espace avant et un espace après le signe ">".
D'autre part, le signe ">" va créer un nouveau fichier. Si le fichier
existe déjà, et qu'on veut ajouter quelque chose à ce fichier, on le
double (>>).
Donc :
- le fichier n'existe pas encore :
VIEWPK.WSF /e:T /c:%computer% > monfichier.txt
- si le fichier existe déjà et qu'on veut l' "augmenter" :
VIEWPK.WSF /e:T /c:%computer% >> monfichier.txt
Dernière chose : il est possible que cette action ne puisse être faite
sur un fichier présent sur le réseau (problème de droits d'accès pour
une commande de script ?)
Der des ders : c'est bien sharereseau le nom de l'ordi où tu veux
stocker le résultat ? Il faut pas indiquer un nom de partage de dossier
? (même si le dossier c'est la racine ? \sharereseauCmonfichier.txt ?)
Dans une session en ligne de commandes, je viens de taper DIR>LIST.TXT TYPE LIST.TXT Et j'ai bien vu le répertoire défiler.
Donc, je dirais bien que les espaces ne sont pas obligatoires autour du caractère de redirection.
Il est permis de penser que le programme n'écrit pas sur la sortie standard, mais sur la sortie d'erreur, ou encore directement à l'écran par un procédé plus sophistiqué.
Certains systèmes (Unix je crois) permettent de rediriger la sortie d'erreur, par une syntaxe du style
commande 1>standard.txt 2>erreur.txt
Je n'affirmerais pas avoir vu ça dans la doc Windows, mais si je tape dans une session ligne de commandes DIR 2>erreur.txt
je vois bien défiler le répertoire, et un fichier vide erreur.txt est créé. Si je tape DIR 2, aucun fichier n'est listé. ça laisse entendre que la syntaxe est reconnue.
Je n'ai pas à l'esprit là tout de suite une commande qui écrive dans la sortie d'erreur, enfin bon, "p'us qu'à" essayer ... En espérant que le programme visé écrive bien dans la sortie d'erreur. _____________________________________ Ypoons a écrit, le 13/10/2005 03:34 :
Bonjour j'ai tester pour moi ça marche bien Par contre j'ai essayé de l'intégrer dans un autre script pour cheker tous les ProductID de mon reseau et rediriger le resultat dans un fichier log pour l'importer dans excel et voir s'il y a des doublons mais le >> n'est pas pris en compte qqu peut il me donner une solution
Euh... je vais peut-être dire une connerie, mais je me lance...
La redirection (>) dans une commande (pour les scripts je suis pas sûr) impose un espace avant et un espace après le signe ">". D'autre part, le signe ">" va créer un nouveau fichier. Si le fichier existe déjà, et qu'on veut ajouter quelque chose à ce fichier, on le double (>>).
Donc : - le fichier n'existe pas encore : VIEWPK.WSF /e:T /c:%computer% > monfichier.txt
- si le fichier existe déjà et qu'on veut l' "augmenter" : VIEWPK.WSF /e:T /c:%computer% >> monfichier.txt
Dernière chose : il est possible que cette action ne puisse être faite sur un fichier présent sur le réseau (problème de droits d'accès pour une commande de script ?)
Der des ders : c'est bien sharereseau le nom de l'ordi où tu veux stocker le résultat ? Il faut pas indiquer un nom de partage de dossier ? (même si le dossier c'est la racine ? sharereseauCmonfichier.txt ?)
Jean-Claude BELLAMY
Dans le message :434e0852$0$5366$, Gloops a pris la peine d'écrire ce qui suit :
Salut,
Dans une session en ligne de commandes, je viens de taper
LIST.TXT TYPE LIST.TXT
Et j'ai bien vu le répertoire défiler.
Donc, je dirais bien que les espaces ne sont pas obligatoires autour du caractère de redirection.
Il est permis de penser que le programme n'écrit pas sur la sortie standard, mais sur la sortie d'erreur, ou encore directement à l'écran par un procédé plus sophistiqué. Pas du tout !
Mon script effectue des "wscript.echo" tout ce qu'il y a de plus basiques, dont sortie sur "StdOut" parfaitement standard. Vériife bien la syntaxe de ta commande, les droits d'accès au serveur, et aussi à Microsoft AntiSpyware (s'il est installé, bien sûr) car ce dernier arrêt tout nouveau script !
La redirection fonctionne très bien avec viewpk.wsf, je l'ai expérimentée..
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org ou http://jc.bellamy.free.fr
Dans le message :434e0852$0$5366$8fcfb975@news.wanadoo.fr,
Gloops <gloops@niark.fr> a pris la peine d'écrire ce qui suit :
Salut,
Dans une session en ligne de commandes, je viens de taper
LIST.TXT
TYPE LIST.TXT
Et j'ai bien vu le répertoire défiler.
Donc, je dirais bien que les espaces ne sont pas obligatoires autour
du caractère de redirection.
Il est permis de penser que le programme n'écrit pas sur la sortie
standard, mais sur la sortie d'erreur, ou encore directement à l'écran
par un procédé plus sophistiqué.
Pas du tout !
Mon script effectue des "wscript.echo" tout ce qu'il y a de plus basiques,
dont sortie sur "StdOut" parfaitement standard.
Vériife bien la syntaxe de ta commande, les droits d'accès au serveur, et
aussi à Microsoft AntiSpyware (s'il est installé, bien sûr) car ce dernier
arrêt tout nouveau script !
La redirection fonctionne très bien avec viewpk.wsf, je l'ai expérimentée..
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - Jean-Claude.Bellamy@wanadoo.fr
http://www.bellamyjc.org ou http://jc.bellamy.free.fr
Dans le message :434e0852$0$5366$, Gloops a pris la peine d'écrire ce qui suit :
Salut,
Dans une session en ligne de commandes, je viens de taper
LIST.TXT TYPE LIST.TXT
Et j'ai bien vu le répertoire défiler.
Donc, je dirais bien que les espaces ne sont pas obligatoires autour du caractère de redirection.
Il est permis de penser que le programme n'écrit pas sur la sortie standard, mais sur la sortie d'erreur, ou encore directement à l'écran par un procédé plus sophistiqué. Pas du tout !
Mon script effectue des "wscript.echo" tout ce qu'il y a de plus basiques, dont sortie sur "StdOut" parfaitement standard. Vériife bien la syntaxe de ta commande, les droits d'accès au serveur, et aussi à Microsoft AntiSpyware (s'il est installé, bien sûr) car ce dernier arrêt tout nouveau script !
La redirection fonctionne très bien avec viewpk.wsf, je l'ai expérimentée..
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org ou http://jc.bellamy.free.fr
Gloops
Bonsoir,
J'avoue que j'ai eu la flemme de remonter le fil pour voir d'où venait le script : j'en suis resté à des généralités. Si maintenant l'auteur du script en personne intervient, je n'ai plus qu'à m'éclipser sur la pointe des pieds :) __________________________________________________ Jean-Claude BELLAMY a écrit, le 13/10/2005 11:38 :
Dans le message :434e0852$0$5366$, Gloops a pris la peine d'écrire ce qui suit :
Salut,
Dans une session en ligne de commandes, je viens de taper
LIST.TXT
TYPE LIST.TXT Et j'ai bien vu le répertoire défiler.
Donc, je dirais bien que les espaces ne sont pas obligatoires autour du caractère de redirection.
Il est permis de penser que le programme n'écrit pas sur la sortie standard, mais sur la sortie d'erreur, ou encore directement à l'écran par un procédé plus sophistiqué.
Pas du tout !
Mon script effectue des "wscript.echo" tout ce qu'il y a de plus basiques, dont sortie sur "StdOut" parfaitement standard. Vériife bien la syntaxe de ta commande, les droits d'accès au serveur, et aussi à Microsoft AntiSpyware (s'il est installé, bien sûr) car ce dernier arrêt tout nouveau script !
La redirection fonctionne très bien avec viewpk.wsf, je l'ai expérimentée..
Bonsoir,
J'avoue que j'ai eu la flemme de remonter le fil pour voir d'où venait
le script : j'en suis resté à des généralités. Si maintenant l'auteur du
script en personne intervient, je n'ai plus qu'à m'éclipser sur la
pointe des pieds :)
__________________________________________________
Jean-Claude BELLAMY a écrit, le 13/10/2005 11:38 :
Dans le message :434e0852$0$5366$8fcfb975@news.wanadoo.fr,
Gloops <gloops@niark.fr> a pris la peine d'écrire ce qui suit :
Salut,
Dans une session en ligne de commandes, je viens de taper
LIST.TXT
TYPE LIST.TXT
Et j'ai bien vu le répertoire défiler.
Donc, je dirais bien que les espaces ne sont pas obligatoires autour
du caractère de redirection.
Il est permis de penser que le programme n'écrit pas sur la sortie
standard, mais sur la sortie d'erreur, ou encore directement à l'écran
par un procédé plus sophistiqué.
Pas du tout !
Mon script effectue des "wscript.echo" tout ce qu'il y a de plus basiques,
dont sortie sur "StdOut" parfaitement standard.
Vériife bien la syntaxe de ta commande, les droits d'accès au serveur, et
aussi à Microsoft AntiSpyware (s'il est installé, bien sûr) car ce dernier
arrêt tout nouveau script !
La redirection fonctionne très bien avec viewpk.wsf, je l'ai expérimentée..
J'avoue que j'ai eu la flemme de remonter le fil pour voir d'où venait le script : j'en suis resté à des généralités. Si maintenant l'auteur du script en personne intervient, je n'ai plus qu'à m'éclipser sur la pointe des pieds :) __________________________________________________ Jean-Claude BELLAMY a écrit, le 13/10/2005 11:38 :
Dans le message :434e0852$0$5366$, Gloops a pris la peine d'écrire ce qui suit :
Salut,
Dans une session en ligne de commandes, je viens de taper
LIST.TXT
TYPE LIST.TXT Et j'ai bien vu le répertoire défiler.
Donc, je dirais bien que les espaces ne sont pas obligatoires autour du caractère de redirection.
Il est permis de penser que le programme n'écrit pas sur la sortie standard, mais sur la sortie d'erreur, ou encore directement à l'écran par un procédé plus sophistiqué.
Pas du tout !
Mon script effectue des "wscript.echo" tout ce qu'il y a de plus basiques, dont sortie sur "StdOut" parfaitement standard. Vériife bien la syntaxe de ta commande, les droits d'accès au serveur, et aussi à Microsoft AntiSpyware (s'il est installé, bien sûr) car ce dernier arrêt tout nouveau script !
La redirection fonctionne très bien avec viewpk.wsf, je l'ai expérimentée..
