Bonjour,
j'ai déja posté les informations sur un post précédent (en anglais) j'était tanné d'avoir des problèmes avec mes SSA et devoir passer par la version 8 pour uploader les scènes standalone.
Après des mois et des mois de recherche, j'ai finalement confié à Claude Ai d'analyser le code. Le bogue d'upload du standalone est HYPER simple à régler (et vraiment surement qu'une petite erreur d'inattention de la part des développeurs)
J'aimerais pouvoir entrer en contact avec vous pour discuter de la solution à ce bogue hyper frustrant (et vous envoyer le fichier patché si vous croyez en avoir besoin... ce n'est que 1 octet de différence, une fois patché!!)
J'ai aussi trouvé et réglé le problème avec les Firmware de BOX et SSA vs les controlleurs USB 3.x, mais je crois à ce niveau que vous avez choisi de ne pas continuer à les supporter. Dommage, il aurait été possible de fournir un utilitaire d'update de firmware assez facilement.
Bref, svp envoyez moi un message privé pour que je puisse vous envoyer le fichier efk_hardware.dll corrigé
Bogue trouvé et patché SSA Standalone v9.4.7
Re: BOGUE TROUVÉ ET PATCHÉ SSA Standalone v9.4.7 (besoin d'informer un dev)
...il a quand même fallu plusieurs dump de mémoire des chips 24c256 à l'intérieur, et d'essai aves toutes les versions V8, V9 32bits, v964, avec plusieurs versions de Windows pour en arriver là..!!
Re: BOGUE TROUVÉ ET PATCHÉ SSA Standalone v9.4.7 (besoin d'informer un dev)
Veuillez SVP suivre ici : https://forum.thelightingcontroller.com ... 624#p34624
The Lighting Controller
Re: Bogue trouvé et patché SSA Standalone v9.4.7
Merci, je comprends que le support *matériel* n'est plus pris en charge, mais le bogue qui empêche l'upload standalone est un problème *logiciel* qui, à ma compréhension, affecte aussi les 1024 rack (votre nouveau modèle, le plus dispendieux, toujours en vente à l'heure actuelle!!). Les scènes ne se rendent pas en raison du logiciel qui ne les lis pas... Je ne parle pas du problème de communication avec les controlleurs USB3, celui là est en effet complexe à déployer. Je parle bien d'un bogue logiciel dans la V9.
Re: Bogue trouvé et patché SSA Standalone v9.4.7
voici l'output de ClaudeAi pour votre référence. très clair et concis. Très facile à réparer, et démontre que le bogue vise aussi les Rack1024
A. LE PROBLÈME CORRIGÉ (version courte)
---------------------------------------
Dans l'onglet « Standalone » de la V9.4.7, le bouton « Upload data »
envoie les scènes à la SSA, mais sur les MAUVAIS boutons. Exemple vécu
avec 3 scènes prévues pour les boutons 1, 2 et 3 :
- le bouton 1 de la SSA reste vide ;
- la scène du bouton 3 arrive sur le bouton 2 ;
- la scène du bouton 2 est recopiée sur les boutons 3 à 14 ;
- la scène du bouton 1 n'est jamais envoyée ;
et les scènes qui étaient déjà dans la SSA sont effacées.
Avec cette DLL, chaque scène arrive sur son bouton (comme dans la V8),
et les boutons sans scène restent vides.
B. UN SEUL FICHIER POUR TOUTES LES MARQUES
------------------------------------------
Les versions SweetLight, TLC, Chauvet ShowXpress et QuickDMX de la
V9.4.7 utilisent le même fichier efk_hardware.dll : la correction est donc
la même pour toutes.
Il existe une DLL pour la version 32 bits du logiciel et une pour la
version 64 bits :
32bit\efk_hardware.dll -> logiciel V9.4.7 en 32 bits
64bit\efk_hardware.dll -> logiciel V9.4.7 en 64 bits
(Dans le Gestionnaire des tâches, la version 32 bits de
TheLightingController.exe est indiquée « (32 bits) ».)
Vérification de la DLL d'origine (MD5) - ouvrez une invite de commandes :
certutil -hashfile efk_hardware.dll MD5
Valeurs attendues pour la DLL d'ORIGINE V9.4.7 :
32 bits : 69b56a1bfe51e57c64325079f9c78b01
64 bits : 03e7bdac193dc1a2f6b9083de80690b8
Si votre DLL d'origine a une autre somme, ne la remplacez pas. Il ne
s'agit pas de la version visée ici.
=====================================================================
PARTIE TECHNIQUE (pour développeur)
=====================================================================
C. SYMPTÔME ET ANALYSE
----------------------
Test de référence : 3 scènes simples (Yellow / Blue / Mauve) sur les
boutons 1, 2, 3 de la SSA, pilote WinUSB 2024 (V9.4.7) contre pilote
EFKusb 2017 (V8 8.2.28). Captures USB (USBPcap), images reconstruites de la
banque mémoire 2 (24C256) et lecture directe de la puce.
V8 : table de pointeurs = [Yellow, Blue, Mauve, vide x11] (correct)
V9 : table de pointeurs = [vide, Mauve, Blue x12]; Yellow absent.
Le transport USB (WinUSB) est sain : toutes les pages (40 octets : en-tête
04 02 AH AL 00 00 00 00 + 32 octets) sont écrites, et les enregistrements
de scène (26 octets) sont identiques octet pour octet à ceux de la V8.
L'image reconstruite à partir de la capture V8 est identique octet pour
octet au contenu de la puce 24C256 de la SSA (relevé direct).
Le défaut n'est donc PAS le transfert mais le CHOIX DU FICHIER .sce lu
pour chaque bouton, dans la routine d'envoi SSA de efk_hardware.dll.
Cause (efk_hardware.dll V9.4.7) :
La routine boucle sur les 14 boutons de la SSA ; pour chacun elle construit
le nom <dossier>StandAlone/scenes/button<N>.sce (littéraux UTF-16 :
L"StandAlone/scenes/button" et L".sce"), appelle le chargeur de scène
(0x1000AF44 en 32 bits), puis range l'enregistrement dans l'image mémoire.
Le numéro N est lu dans la MAUVAISE variable locale :
- Le compteur de la boucle des boutons est à [esp+0x44] (32 bits)
lorsque la pile est « à plat ».
- Au moment de construire le nom, 3 temporaires (chaînes) sont empilés :
le même compteur est donc à [esp+0x50]. Or le code lit [esp+0x44], c'est-à-dire
l'emplacement de base+0x38 : une variable de travail partagée,
réutilisée comme compteur par plusieurs autres boucles de la fonction
(remise à zéro de la table des types, reprise après échec de
chargement, boucle sur les étapes de la scène chargée...).
- Valeur de cette variable : 14 après la boucle de remise à zéro (-> la
première itération demande button15.sce, inexistant -> scène vide par
défaut), puis valeur finale de la boucle interne de l'itération
précédente. Séquence de fichiers demandés compatible avec les
observations : button15, button3, button2, button2, ... (les valeurs
3 puis 2 sont déduites du résultat observé ; l'origine exacte de ces
deux valeurs n'a pas été vérifiée plus loin).
- La séquence ne dépend donc pas des boutons que l'utilisateur a assignés
(même résultat dans deux essais de configurations différentes).
Comparaison V8 : EFK_upload_data_Ssa (V8) lit [esp+0x50] au même endroit,
pile identique (compteur de boutons en [esp+0x44] à plat) : correct.
Dans la DLL V9, les deux autres routines qui construisent un nom
buttonN.sce (0x10007E0F et 0x1000D714) lisent le bon emplacement
(compteur + 3 dwords) : elles ne sont pas affectées. Seule la routine SSA
(0x100016A3 - 0x10003041 en 32 bits) a la faute.
D. CORRECTION APPORTÉE (1 octet par DLL)
----------------------------------------
Instruction à corriger : « mov eax, [pile + compteur] » juste avant
« cdq / +1 » (conversion du numéro en texte).
32 bits (image base 0x10000000, section .code)
VA 0x10001C18 : 8B 44 24 44 mov eax,[esp+0x44]
-> 8B 44 24 50 mov eax,[esp+0x50]
Octet modifié : offset fichier 0x101B (VA 0x10001C1B) : 0x44 -> 0x50
64 bits (image base 0x180000000, section .code)
VA 0x18000223B : 4C 8B BC 24 B0 00 00 00 mov r15,[rsp+0xB0]
-> 4C 8B BC 24 C8 00 00 00 mov r15,[rsp+0xC8]
Octet modifié : offset fichier 0x163F (VA 0x18000223F) : 0xB0 -> 0xC8
(0xB0 + 3 push de 8 octets = 0xC8)
Sommes MD5 (avant -> après) :
32 bits : 69b56a1bfe51e57c64325079f9c78b01 -> 244996a366a4c9502acda84021f39b3c
64 bits : 03e7bdac193dc1a2f6b9083de80690b8 -> 06939b021e4ed9712f1c7c87c0c8319f
Les DLL ne sont pas signées (pas de répertoire de sécurité PE) : aucune
signature n'est invalidée. L'outil patch_efk_hardware.py (Python 3) refait
la même modification en cherchant le motif d'octets (motif unique), et
refuse de toucher une DLL qui ne correspond pas.
E. PISTES POUR LE CODE SOURCE
-----------------------------
1. Correction directe : utiliser la variable de la boucle des boutons
(celle qui indexe le tableau d'entrées, pas de 0x3C octets) pour
composer le nom : "button" + str(i + 1) + ".sce".
2. Éviter de réutiliser une même variable de travail (j/k/tmp) comme
compteur de plusieurs boucles dans une longue fonction ; déclarer
chaque compteur localement à sa boucle. Le défaut vient de là.
3. Dans cette fonction, l'écriture de la table des types (valeur 0..3
déduite du type 2/3/4 de chaque bouton) est aussi indexée par cette
variable de travail et non par l'indice du bouton, en V8 comme en V9.
Sans effet visible dans les essais V8 : à vérifier si cette table est
lue plus loin.
4. Un .sce manquant ou illisible est remplacé silencieusement par une
scène vide par défaut et l'envoi se poursuit (effaçant le bouton). Mieux :
ignorer ce bouton, ou signaler le nom du fichier absent, ou annuler
avant d'écrire dans l'appareil.
5. Les valeurs de retour du transfert USB ne sont jamais testées : le
message « problème d'envoi » ne s'affiche que pour certains codes de
retour du packer (dépassement/mémoire). Vérifier au moins l'état USB de
chaque page écrite.
6. Test de régression simple : envoyer N scènes de couleurs différentes sur
des boutons non contigus (ex. 1, 5, 14) et comparer la table de
pointeurs/tailles de l'image mémoire au résultat attendu.
7. Observations annexes : la SSA a 14 boutons alors que l'interface en
montre 16 ; la V9 ne crée que button1..button18.sce .
F. STATUT DE VALIDATION
-----------------------
Correction établie par désassemblage des DLL V8 et V9, comparaison des
deux routines et explication complète des résultats observés. Le test de
la DLL corrigée sur matériel SSA est à confirmer par l'utilisateur
(résultat attendu : Yellow / Blue / Mauve sur les boutons 1 / 2 / 3, boutons
4 à 14 vides, comme en V8).
A. LE PROBLÈME CORRIGÉ (version courte)
---------------------------------------
Dans l'onglet « Standalone » de la V9.4.7, le bouton « Upload data »
envoie les scènes à la SSA, mais sur les MAUVAIS boutons. Exemple vécu
avec 3 scènes prévues pour les boutons 1, 2 et 3 :
- le bouton 1 de la SSA reste vide ;
- la scène du bouton 3 arrive sur le bouton 2 ;
- la scène du bouton 2 est recopiée sur les boutons 3 à 14 ;
- la scène du bouton 1 n'est jamais envoyée ;
et les scènes qui étaient déjà dans la SSA sont effacées.
Avec cette DLL, chaque scène arrive sur son bouton (comme dans la V8),
et les boutons sans scène restent vides.
B. UN SEUL FICHIER POUR TOUTES LES MARQUES
------------------------------------------
Les versions SweetLight, TLC, Chauvet ShowXpress et QuickDMX de la
V9.4.7 utilisent le même fichier efk_hardware.dll : la correction est donc
la même pour toutes.
Il existe une DLL pour la version 32 bits du logiciel et une pour la
version 64 bits :
32bit\efk_hardware.dll -> logiciel V9.4.7 en 32 bits
64bit\efk_hardware.dll -> logiciel V9.4.7 en 64 bits
(Dans le Gestionnaire des tâches, la version 32 bits de
TheLightingController.exe est indiquée « (32 bits) ».)
Vérification de la DLL d'origine (MD5) - ouvrez une invite de commandes :
certutil -hashfile efk_hardware.dll MD5
Valeurs attendues pour la DLL d'ORIGINE V9.4.7 :
32 bits : 69b56a1bfe51e57c64325079f9c78b01
64 bits : 03e7bdac193dc1a2f6b9083de80690b8
Si votre DLL d'origine a une autre somme, ne la remplacez pas. Il ne
s'agit pas de la version visée ici.
=====================================================================
PARTIE TECHNIQUE (pour développeur)
=====================================================================
C. SYMPTÔME ET ANALYSE
----------------------
Test de référence : 3 scènes simples (Yellow / Blue / Mauve) sur les
boutons 1, 2, 3 de la SSA, pilote WinUSB 2024 (V9.4.7) contre pilote
EFKusb 2017 (V8 8.2.28). Captures USB (USBPcap), images reconstruites de la
banque mémoire 2 (24C256) et lecture directe de la puce.
V8 : table de pointeurs = [Yellow, Blue, Mauve, vide x11] (correct)
V9 : table de pointeurs = [vide, Mauve, Blue x12]; Yellow absent.
Le transport USB (WinUSB) est sain : toutes les pages (40 octets : en-tête
04 02 AH AL 00 00 00 00 + 32 octets) sont écrites, et les enregistrements
de scène (26 octets) sont identiques octet pour octet à ceux de la V8.
L'image reconstruite à partir de la capture V8 est identique octet pour
octet au contenu de la puce 24C256 de la SSA (relevé direct).
Le défaut n'est donc PAS le transfert mais le CHOIX DU FICHIER .sce lu
pour chaque bouton, dans la routine d'envoi SSA de efk_hardware.dll.
Cause (efk_hardware.dll V9.4.7) :
La routine boucle sur les 14 boutons de la SSA ; pour chacun elle construit
le nom <dossier>StandAlone/scenes/button<N>.sce (littéraux UTF-16 :
L"StandAlone/scenes/button" et L".sce"), appelle le chargeur de scène
(0x1000AF44 en 32 bits), puis range l'enregistrement dans l'image mémoire.
Le numéro N est lu dans la MAUVAISE variable locale :
- Le compteur de la boucle des boutons est à [esp+0x44] (32 bits)
lorsque la pile est « à plat ».
- Au moment de construire le nom, 3 temporaires (chaînes) sont empilés :
le même compteur est donc à [esp+0x50]. Or le code lit [esp+0x44], c'est-à-dire
l'emplacement de base+0x38 : une variable de travail partagée,
réutilisée comme compteur par plusieurs autres boucles de la fonction
(remise à zéro de la table des types, reprise après échec de
chargement, boucle sur les étapes de la scène chargée...).
- Valeur de cette variable : 14 après la boucle de remise à zéro (-> la
première itération demande button15.sce, inexistant -> scène vide par
défaut), puis valeur finale de la boucle interne de l'itération
précédente. Séquence de fichiers demandés compatible avec les
observations : button15, button3, button2, button2, ... (les valeurs
3 puis 2 sont déduites du résultat observé ; l'origine exacte de ces
deux valeurs n'a pas été vérifiée plus loin).
- La séquence ne dépend donc pas des boutons que l'utilisateur a assignés
(même résultat dans deux essais de configurations différentes).
Comparaison V8 : EFK_upload_data_Ssa (V8) lit [esp+0x50] au même endroit,
pile identique (compteur de boutons en [esp+0x44] à plat) : correct.
Dans la DLL V9, les deux autres routines qui construisent un nom
buttonN.sce (0x10007E0F et 0x1000D714) lisent le bon emplacement
(compteur + 3 dwords) : elles ne sont pas affectées. Seule la routine SSA
(0x100016A3 - 0x10003041 en 32 bits) a la faute.
D. CORRECTION APPORTÉE (1 octet par DLL)
----------------------------------------
Instruction à corriger : « mov eax, [pile + compteur] » juste avant
« cdq / +1 » (conversion du numéro en texte).
32 bits (image base 0x10000000, section .code)
VA 0x10001C18 : 8B 44 24 44 mov eax,[esp+0x44]
-> 8B 44 24 50 mov eax,[esp+0x50]
Octet modifié : offset fichier 0x101B (VA 0x10001C1B) : 0x44 -> 0x50
64 bits (image base 0x180000000, section .code)
VA 0x18000223B : 4C 8B BC 24 B0 00 00 00 mov r15,[rsp+0xB0]
-> 4C 8B BC 24 C8 00 00 00 mov r15,[rsp+0xC8]
Octet modifié : offset fichier 0x163F (VA 0x18000223F) : 0xB0 -> 0xC8
(0xB0 + 3 push de 8 octets = 0xC8)
Sommes MD5 (avant -> après) :
32 bits : 69b56a1bfe51e57c64325079f9c78b01 -> 244996a366a4c9502acda84021f39b3c
64 bits : 03e7bdac193dc1a2f6b9083de80690b8 -> 06939b021e4ed9712f1c7c87c0c8319f
Les DLL ne sont pas signées (pas de répertoire de sécurité PE) : aucune
signature n'est invalidée. L'outil patch_efk_hardware.py (Python 3) refait
la même modification en cherchant le motif d'octets (motif unique), et
refuse de toucher une DLL qui ne correspond pas.
E. PISTES POUR LE CODE SOURCE
-----------------------------
1. Correction directe : utiliser la variable de la boucle des boutons
(celle qui indexe le tableau d'entrées, pas de 0x3C octets) pour
composer le nom : "button" + str(i + 1) + ".sce".
2. Éviter de réutiliser une même variable de travail (j/k/tmp) comme
compteur de plusieurs boucles dans une longue fonction ; déclarer
chaque compteur localement à sa boucle. Le défaut vient de là.
3. Dans cette fonction, l'écriture de la table des types (valeur 0..3
déduite du type 2/3/4 de chaque bouton) est aussi indexée par cette
variable de travail et non par l'indice du bouton, en V8 comme en V9.
Sans effet visible dans les essais V8 : à vérifier si cette table est
lue plus loin.
4. Un .sce manquant ou illisible est remplacé silencieusement par une
scène vide par défaut et l'envoi se poursuit (effaçant le bouton). Mieux :
ignorer ce bouton, ou signaler le nom du fichier absent, ou annuler
avant d'écrire dans l'appareil.
5. Les valeurs de retour du transfert USB ne sont jamais testées : le
message « problème d'envoi » ne s'affiche que pour certains codes de
retour du packer (dépassement/mémoire). Vérifier au moins l'état USB de
chaque page écrite.
6. Test de régression simple : envoyer N scènes de couleurs différentes sur
des boutons non contigus (ex. 1, 5, 14) et comparer la table de
pointeurs/tailles de l'image mémoire au résultat attendu.
7. Observations annexes : la SSA a 14 boutons alors que l'interface en
montre 16 ; la V9 ne crée que button1..button18.sce .
F. STATUT DE VALIDATION
-----------------------
Correction établie par désassemblage des DLL V8 et V9, comparaison des
deux routines et explication complète des résultats observés. Le test de
la DLL corrigée sur matériel SSA est à confirmer par l'utilisateur
(résultat attendu : Yellow / Blue / Mauve sur les boutons 1 / 2 / 3, boutons
4 à 14 vides, comme en V8).
Last edited by Piobee on 06 November 2026, 21:45, edited 1 time in total.