Password-Manager/LICENCE-TESTS.md

Système de licences — scénario d'essai

Écrit le 2026-09-05, après la séance qui a posé la vérification hors ligne, le liage au poste et l'écran d'activation.

Ce plan ne cherche pas à montrer que ça marche : il cherche les endroits où ça casserait sans prévenir. Un système de licences échoue de deux façons opposées, et les deux coûtent cher — refuser un client qui a payé, ou ouvrir à quelqu'un qui n'a rien. Chaque essai ci-dessous vise l'une des deux.

Ce que la séance a déjà appris, et qui vaut d'être gardé en tête : l'empreinte du poste dépendait de l'ordre de démarrage. Selon que WMI répondait ou non, la même machine se présentait sous deux identités et refusait sa propre licence. Rien dans une utilisation normale ne l'aurait montré. D'où la série D.

---

Préparation

L'outil de remise à zéro : pose un fichier config.txt à côté de l'exe (n'importe quel contenu, même vide). Un bouton rouge Deactivate (debug) apparaît alors au bas de Settings → Licence : il efface la licence rangée et rien d'autre. Sans config.txt le bouton n'apparaît pas, et la commande sous-jacente est de toute façon inerte — un exe livré ne peut pas être désactivé par ce chemin.

Ne supprime %LOCALAPPDATA%\PMServer\prefs.bin qu'en dernier recours : ça désactive aussi, mais emporte le mode de déverrouillage, le nom retenu et les réglages de sync.

Ce qu'il faut sous la main :

• ta licence valable, liée à ce poste ;
• l'Installation ID de ce poste (Settings → Licence, ou l'écran d'activation) ;
• tools/licence.ps1 et la clé privée.

Ordre : A → B → C → D → E. La série A établit l'état de référence ; les suivantes le cassent volontairement.

---

A. Le chemin normal

1. Coffre déjà activé, lancer l'application. À voir : l'écran d'activation n'apparaît pas. On tombe directement sur l'écran de connexion.
2. Settings → Licence. À voir : Licensed to, Email, Issued et Installation ID remplis. Le nom affiché est celui que tu as tapé à l'émission — il vient de la charge utile signée, pas d'un réglage local.
3. Fermer, relancer. À voir : toujours pas d'écran d'activation. C'est ce qui prouve que la licence est rangée et relue, pas seulement acceptée une fois.

---

B. Ce qui doit être refusé

Chaque essai part de l'écran d'activation (licence effacée).

1. Chaîne quelconque : taper nimportequoi. À voir : This licence key is not valid, en rouge. L'écran reste.
2. Licence tronquée : coller ta licence valable en retirant les dix derniers caractères. À voir : même refus. La signature ne tolère pas un octet.
3. Charge utile trafiquée : prendre ta licence, changer un seul caractère dans la partie avant le point (le nom, l'adresse), coller. À voir : même refus. C'est l'essai qui prouve que le contenu affiché dans Settings ne peut pas être maquillé.
4. Licence d'un autre poste :

   tools\licence.ps1 -For "x@y.z" -Name "Autre" -Machine "AAAA-BBBB-CCCC-DDDD"
   

   coller le résultat. À voir : refus. C'est le cœur du liage — une licence parfaitement signée, mais pas pour cette machine.
5. Licence d'une autre paire de clés :

   tools\licence.ps1 -Init -KeyFile "%TEMP%\faux.key"
   tools\licence.ps1 -For "x@y.z" -Name "Faux" -Machine "<TON ID>" -KeyFile "%TEMP%\faux.key"
   

   coller le résultat. À voir : refus. C'est le cœur de la signature — la bonne machine, la bonne forme, mais pas ta clé. Si cet essai passait, n'importe qui pourrait fabriquer des licences. Puis supprimer %TEMP%\faux.key.
6. Ta vraie licence, pour finir. À voir : l'écran disparaît, on passe à la connexion.

---

C. Ce qui ne doit PAS être refusé

Le risque symétrique, et le plus coûteux commercialement.

1. Coller ta licence avec des espaces avant et après (une sélection à la souris en attrape presque toujours). À voir : acceptée. Le code fait Trim.
2. Coller ta licence avec un retour à la ligne collé au bout. À voir : acceptée.
3. Après activation, redémarrer la machine (pas seulement l'application). À voir : toujours activée. Le port du serveur change à chaque lancement — si la licence avait vécu dans localStorage, elle serait perdue ici. C'est l'essai qui prouve le stockage DPAPI.

---

D. L'empreinte du poste — la série qui a déjà attrapé un défaut

1. Noter l'Installation ID dans Settings → Licence.
2. Fermer, relancer, relire. À voir : exactement le même. Un seul caractère de différence, et toutes les licences de cette machine tomberaient au prochain lancement.
3. Relancer cinq fois de suite, en laissant la machine chargée (ouvrir quelques applications) pour varier les temps de démarrage. À voir : le même à chaque fois. C'est le défaut corrigé le 2026-09-05 : l'empreinte dépendait de l'initialisation de COM par WebView2, donc de la vitesse de démarrage.
4. Démarrage à froid : redémarrer Windows, lancer l'application en premier. À voir : le même.

---

E. La portée de l'activation

1. Autre compte Windows sur la même machine : ouvrir une session différente, lancer l'application. À voir : l'écran d'activation réapparaît, avec le même Installation ID. Comportement voulu : la licence est rangée par utilisateur (DPAPI), l'empreinte est celle de la machine. Ta licence y sera acceptée.
2. Copier l'exe dans un autre dossier et le lancer. À voir : toujours activée. La licence ne vit pas à côté de l'exe.
3. La mise à jour — le cas qu'on vivra réellement. Remplacer l'exe d'une installation existante par une nouvelle version, lancer. À voir : toujours activée. C'est l'essai le plus utile de la série : si une mise à jour désactivait, il faudrait réémettre une licence à chaque livraison, et on ne s'en apercevrait qu'au premier client mécontent.

---

Résultat de la première campagne — 2026-09-05

A B C D E2 E3 passés. Rien à corriger : la campagne n'a rien trouvé, ce qui n'était pas acquis — la séance qui l'a précédée avait déjà sorti trois défauts (empreinte dépendante de l'ordre de démarrage, message d'erreur en cyan au lieu de rouge, licences flottantes acceptées).

E1 (autre compte Windows) n'a pas été joué — faute d'un second compte sous la main. Ce que le code dit qu'il donnerait : écran d'activation de retour, même Installation ID, licence acceptée telle quelle. À éprouver le jour où un client le signale, ou avant de vendre à quelqu'un qui a plusieurs sessions.

Deux observations de la campagne, gardées parce qu'elles se reproduiront :

• C3 a été plus probant que prévu. Le port avait été changé à la main entre les deux lancements (8766 → 51812), donc l'origine du navigateur a réellement changé — exactement ce que l'essai veut prouver, mais pour de bon.
• Un port éphémère dans le journal sans ligne de repli n'est pas un défaut : c'est port=0 ou un config.txt absent. Le repli, lui, écrit toujours « Port N unavailable » avant de se déplacer.

---

Ce qu'aucun de ces essais ne prouve

À dire clairement, pour ne pas se croire protégé de ce qu'on ne l'est pas :

• Rapiécer l'exe pour sauter la vérification reste possible. C'est vrai de tout schéma hors ligne. La signature empêche de fabriquer des licences, pas de contourner le code qui les lit.
• Il n'y a pas de révocation. Une licence émise vaut pour toujours sur sa machine. La seule annulation possible est de régénérer la paire et de réémettre — ce qui casse toutes les autres.
• Le brouillage des blocs embarqués n'est pas du chiffrement. L'onglet Memory de Process Explorer, un débogueur ou la réponse HTTP rendent toujours le frontend en clair.

Le défaut à reconnaître sans le provoquer

Si $ObfSecret (BuildAssets.ps1) et AssetObfSecret (PM.EmbeddedAssets.pas) divergent, la magie PMA1 tombe et le serveur refuse de servir : /index.html en 404, fenêtre vide. Ce n'est pas une panne de licence, c'est un désaccord de build. Symptôme à ne pas confondre.