Sku v43.5-tools - notes de version - installateur 5.2 et outil de connexion 3.4, pas de nouvelle version de l'addon

Aperçu

Nouveautés

Changements

Corrections

Outil de connexion 3.4 : le contrat social de Blizzard est accepté automatiquement

Simple : Les nouveaux comptes - et tous les autres dès que Blizzard modifie le texte - voient un « contrat social » sur l'écran de sélection du personnage. La fenêtre avale toutes les touches, « Accepter » reste verrouillé tant que le texte n'a pas été défilé jusqu'au bout à la souris, et « Refuser » quitte le jeu. L'outil restait muet devant, ou disait au mieux « écran inconnu ». Il annonce maintenant que le contrat social est ouvert, fait défiler le texte jusqu'à la fin, appuie sur Accepter, vérifie que la fenêtre a disparu, puis construit la liste des personnages comme d'habitude. Il en va de même si le contrat réapparaît en cours de session. En cas d'échec, l'outil dit ce qu'une personne voyante doit faire une fois, et réessaie après une minute. Refuser n'est jamais pressé.

Technique : La fenêtre est SocialContractFrame (Blizzard_GlueXML\SocialContract.xml/.lua), déclenchée par le SERVEUR (C_SocialContractGlue.GetShouldShowSocialContract -> SOCIAL_CONTRACT_STATUS_UPDATE) ; aucune CVar ni aucun réglage n'existe, on ne peut donc ni la provoquer ni y répondre à l'avance. L'ancien code ne pouvait pas fonctionner sur le client Anniversary : le test de l'assistant exige le logo jaune assombri, que l'écran BC n'a pas, et son troisième point de mesure tombe au milieu du texte du contrat - test faux, écran « unknown », l'outil n'entrait jamais en mode connexion ; la partie clic était un balayage aveugle de 34 clics. Nouveau : huit points Sc* dans data.ini (déduits du XML : cadre 510x632, boutons à ui y 706..728, PAS un DefaultScaleFrame), plus IsSocialContract, AcceptContract et HandleSocialContract dans flows.ahk et deux branches CheckMode dans menu.ahk - sans recompiler l'assistant. Vérifié avec /validate, zéro faux positif sur toutes les captures de référence et détection sur des images synthétiques du contrat à trois résolutions. Pas encore testé sur la vraie fenêtre, qu'on ne peut pas faire apparaître sur commande ; chaque tentative écrit ses mesures dans log.txt (lignes « SocialContract: »).

Outil de connexion 3.4 : avertissements hardcore et JcJ à toutes les résolutions, avertissement JcJ de création nouveau

Simple : L'avertissement hardcore de la liste des royaumes, les règles hardcore à la création d'un personnage et les avertissements JcJ sont des fenêtres que Blizzard garde à la même taille en pixels réels. Leur position dépend donc de la résolution, et les points de mesure fixes de l'outil n'étaient justes que sur les grands écrans (à partir de 1200 pixels de haut). Sur un écran 1080p courant, ou dans une petite fenêtre, l'outil serait resté muet devant les règles hardcore. Il cherche maintenant ces fenêtres lui-même et les trouve à toutes les résolutions. S'y ajoute l'avertissement JcJ à la création d'un personnage sur un royaume JcJ : il est lu, Entrée accepte, Échap refuse. L'avertissement JcJ de la liste des royaumes a exactement l'aspect de l'avertissement hardcore et était donc déjà lu.

Technique : HardcorePopUpFrame (240 et 580 de haut) et RealmWarningPopUpFrame (240 et 360 de haut) héritent de DefaultScaleFrame et sont mis à l'échelle par GetDefaultScale() - une fonction du client sans source Lua. Mesuré en jeu avec /wdeval : 0,64 en 2880x1800, là où 768/hauteur donnerait 0,43 ; il existe donc un plancher, et le 1080p donnerait sans doute 0,71. Au lieu de supposer l'échelle, GlueDialogScan (flows.ahk) la trouve : dans les quatre formes, les deux boutons sont sur une droite partant du centre de l'écran, et seule la distance dépend de l'échelle. Une capture (nouvelle classe ScreenGrab dans ui.ahk, 1000 pixels en 16 ms), puis échelle 0,60..1,25 par hauteur : rouge sur trois colonnes, pas de rouge dans l'interstice ni juste à l'extérieur, noir au point de fond. Les points fixes restent le premier test, le balayage le second. Les clics (GlueDialogClick) et les zones de texte OCR (GlueDialogBand) suivent l'échelle trouvée. Vérifié avec un portage Python sur 66 fenêtres synthétiques (6 résolutions, 3 hauteurs, 4 échelles) : hauteur toujours juste, échelle à 0,012 près, zéro faux positif. Pas encore testé sur de vraies fenêtres ; chaque détection est consignée dans log.txt (ligne « GlueDialog: » avec l'échelle).

Outil de connexion 3.4 : sélection de voix vide corrigée, la première configuration ne reste plus bloquée

Simple : Sur certaines machines, Windows ne peut pas fournir la liste des voix installées alors que la synthèse vocale elle-même fonctionne - par exemple après une voix tierce mal désinstallée ou à moitié installée. Depuis la 3.3, l'outil ne plante plus dans ce cas, mais « Séléctionner la voix » était alors vide : la flèche droite ne faisait rien, et comme la première configuration ne passe à la langue qu'après le choix d'une voix, on ne la traversait jamais. L'outil lit désormais lui-même les voix dans le registre Windows dans ce cas. S'il n'en trouve pas non plus ainsi, le menu contient l'entrée « Aucune voix trouvée, appuyez sur Entrée pour garder la voix du système » - Entrée conserve la voix avec laquelle l'outil parle, et la configuration continue.

Technique : Le paquet de journaux de l'utilisateur contenait quatre fois « GetVoices FAILED, voice list empty: (0x80045039) », puis « SwitchToSetup ». Ce n'est pas un jeton isolé qui était illisible (le cas de la 3.3) : sap.GetVoices() ou .Count lève lui-même SPERR_NO_MORE_ITEMS, alors que sap.Voice.GetDescription() fonctionne. Nouveau : RegistryVoiceTokens() dans sapi.ahk construit un SAPI.SpObjectToken par clé sous Speech\Voices\Tokens (HKLM et HKCU) via SetId - uniquement en cas d'échec. Seules les entrées ayant un nom et un CLSID sont listées, car une entrée défectueuse ne lève rien ici, GetDescription() renvoie simplement "". AddVoiceNodes() dans menu.ahk remplace les trois boucles identiques et ajoute l'entrée de secours quand la liste est vide. Vérifié avec un banc d'essai qui charge le vrai sapi.ahk et fait lever exactement cette erreur à GetVoices : mêmes voix que par la voie normale, toutes utilisables, deux entrées volontairement défectueuses ignorées. La panne réelle n'a pas pu être reproduite ; pas encore testé sur la machine de l'utilisateur.

Outil de connexion 3.4 : une voix défectueuse ne peut plus rendre l'outil muet

Simple : Une voix dont le programme a été supprimé mais dont l'entrée est restée dans Windows figure toujours dans la liste des voix. La choisir était accepté par Windows sans aucune erreur - et l'outil était ensuite muet, et même définitivement depuis le menu principal, car le choix est enregistré. L'outil essaie désormais chaque voix de façon inaudible avant de l'accepter. Si elle ne fonctionne pas, tout reste en l'état et l'outil dit « Cette voix ne fonctionne pas, choisissez-en une autre ». Au démarrage non plus, une voix enregistrée qui ne parle plus n'est pas appliquée ; la voix par défaut de Windows reste en place.

Technique : Mesuré avec un enregistrement ayant un nom et un CLSID mais pas de moteur : sap.Voice := token est accepté, seul Speak lève 0x80040154 (classe non enregistrée). VoiceWorks() dans sapi.ahk parle donc sur un SpVoice séparé dans un SpMemoryStream, 16 à 31 ms, sans jamais toucher à la voix en cours. SetSapiVoiceByName et SetToolVoiceByName renvoient maintenant le succès, VoiceSelectAction et ApplyToolVoice en tiennent compte. SAPI2SR est exempté : le pont transmet le texte au lecteur d'écran quel que soit le flux de sortie, l'essai serait donc audible. Une voix qui se charge mais ne produit que du silence n'est pas détectée.

Installateur 5.2 : le paquet de journaux liste toutes les voix Windows

Simple : « Collecter les journaux » dans l'installateur ajoute désormais un fichier voices.txt au paquet. Il nomme chaque voix enregistrée dans Windows et indique si le programme correspondant existe encore. En cas de problème de voix dans l'outil de connexion ou dans le jeu, on voit ainsi tout de suite quelle entrée est défectueuse. Livré avec l'installateur 5.2.

Technique : LogCollector.WriteVoiceRegistrations lit Speech\Voices\Tokens, Speech\Voices\TokenEnums et Speech_OneCore\Voices\Tokens dans les vues 64 bits et 32 bits du registre (l'outil de connexion est en 64 bits et ne voit pas les voix uniquement 32 bits) ainsi que dans HKCU, plus DefaultTokenId. Par entrée : nom, CLSID, la DLL InprocServer32 avec vérification qu'elle est enregistrée et présente sur le disque, VoicePath/LangDataPath et les attributs.

Installateur 5.2 : mesures contre les fausses alertes de Windows Defender

Simple : Quelques joueurs ont signalé que Windows Defender avait supprimé l'installateur fraîchement téléchargé comme dangereux. L'installateur n'est pas dangereux ; notre propre analyse Defender, avec des signatures à jour, n'y trouve rien. Deux choses qui rendaient le fichier plus suspect que nécessaire sont corrigées : ses propriétés disent maintenant ce qu'il est et de qui il vient (produit « Sku Installer », société « Sku », auteur JeanStiletto, lien vers le projet) au lieu d'être vides, et un fichier du pont NVDA fourni ne porte plus une signature qui venait du PC du développeur et ne signifiait rien sur une autre machine. Pour être honnête sur la limite : l'installateur n'est toujours pas signé avec un certificat acheté. Chaque nouvelle version démarre donc sans réputation de téléchargement, et Defender peut encore la retenir pendant ses premiers jours. Si cela arrive : ouvrir Sécurité Windows, Historique de protection, choisir l'entrée et autoriser ou restaurer le fichier - et nous envoyer le nom de la détection, s'il vous plaît.

Technique : SkuInstaller.exe n'était pas et n'est pas signé Authenticode ; release.ps1 n'a aucune étape de signature, seules les DLL du pont sont signées, sur la machine de l'utilisateur, par sku-nvda-voice-sign.ps1. Un exe non signé n'a qu'une réputation cloud par hash, et l'exe de la v43.5 avait un jour et neuf téléchargements au moment des signalements. L'analyse locale (moteur 1.1.26080.3, signatures 1.459.278.0) est propre pour l'exe, la charge utile du pont et l'AutoHotkey fourni : le verdict vient donc du cloud/ML ou de l'analyse comportementale, pas d'une signature statique. Modifié : Company, Product, AssemblyTitle, Description, Authors et Copyright dans SkuInstaller.csproj (tous les champs disaient « SkuInstaller », copyright vide). Et x86\sapi2sr_engine.dll dans payload\sapi2sr-payload.zip avait été recopiée depuis le dossier Program Files du développeur et portait encore la signature jetable de cette machine (partout ailleurs « signé par une racine non approuvée ») ; c'est maintenant la DLL nue, 123320 -> 115712 octets. Le hash PE Authenticode exclut la signature, les deux empreintes du script de signature correspondent toujours (5A76A572... x64, 1281E2B9... x86) et la signature sur la machine de l'utilisateur est inchangée. dev\rework-docs\nvda-voice-signing\strip_payload_signature.py fait ce retrait pour la prochaine mise à jour de la charge utile. Non modifié, et toujours ce que voit une analyse comportementale : exécution avec élévation, exécutables embarqués, regsvr32 /s, un PowerShell caché qui ajoute un certificat de signature de code au magasin racine de la machine, auto-remplacement.