@renesenses : merci, je n'ai pas forcément les outils IA suffisant.
Mais en utilisant Whireshark, j'ai un peu avancé..
A voir ici :
https://chatgpt.com/share/6a2c4e71-5b48-...52ef553b90
Et avec une autre IA (mais pas validée..) :
? Investigation Technique : Protocole Propriétaire HQP (HQLink)
Cible : HQP Desktop Server
Port identifié : 4321/TCP
Statut : Protocole binaire propriétaire avec enveloppe XML, fonctionnant en mode "Push" asynchrone.
1. ARCHITECTURE DU PROTOCOLE
Le protocole n'est
pas une API Requête/Réponse classique (type HTTP/REST). C'est un flux binaire persistant.
- Transport : TCP brut.
- Encodage des données : XML UTF-8.
- Encapsulation : Chaque message XML est précédé d'un en-tête binaire de 6 octets et suivi d'un caractère de fin de ligne (0x0A).
Structure d'une trame :
Code :
[ HEADER 6 OCTETS ] + [ PAYLOAD XML ] + [ 0x0A (LF) ]
- Octet 1 : Constant 0x0F.
- Octets 2 à 5 : Variables (ex: B4 C8 42 00).
Hypothèse forte : Il s'agit d'un ID de session, d'un timestamp, ou d'un checksum généré aléatoirement à chaque connexion. C'est le point de blocage actuel. Le serveur rejette silencieusement les paquets avec un en-tête invalide.
- Octet 6 : Souvent 0x00.
2. SÉQUENCE DE CONNEXION (HANDSHAKE)
Pour qu'une session soit valide, le client doit respecter une séquence stricte. L'envoi direct de commandes est ignoré.
- Établissement TCP : Connexion sur le port 4321.
- Commande d'Initialisation (Obligatoire) :
Le client doit envoyer en premier une commande <GetJunkFilters>.
Cette commande contient la liste des filtres supportés (20k, 30k, 2x, 4x, etc.).
Note : Sans cette commande, le serveur n'accepte aucune requête ultérieure.
- Synchronisation d'État :
Le client doit ensuite envoyer un paquet <Status> COMPLET.
Ce paquet doit contenir tous les attributs d'état (volume, position, mode, filtres, etc.). Un `<Status/>` vide ou partiel est ignoré.
- Mode "Push" (Flux) :
Une fois la séquence d'init validée, le serveur ne répond pas aux requêtes.
Le serveur envoie spontanément des paquets `<Status>` mis à jour uniquement lorsqu'un événement se produit (changement de piste, Play/Pause, changement de volume).
⚠️ Contrainte majeure : Le serveur semble gérer
une seule connexion active à la fois. Si le client officiel est connecté, il bloque les autres connexions (ou empêche l'envoi de flux vers les nouveaux clients). Il faut impérativement fermer le client officiel pour tester un script tiers.
3. EXEMPLES DE TRAMES (HEXADÉCIMAL)
A. Commande d'Init (`GetJunkFilters`)
Code :
0F B4 C8 42 00 00 3C 3F 78 6D 6C ... (<?xml version="1.0"...)
... 3C 47 65 74 4A 75 6E 6B 46 69 6C 74 65 72 73 3E ... (<GetJunkFilters>...)
... 0A
Contient les métadonnées : Titre, Artiste, Album, Bitrate, Position.
Code :
<Status ... state="2" song="Titre de la piste" artist="Artiste" ...>
<metadata bitrate="9216000" mime="audio/flac" ... />
</Status>
4. POINTS DE BLOCAGE & PISTES POUR LA SUITE
- Génération de l'En-tête (Prioritaire) :
Nous n'avons pas l'algorithme pour générer les octets 2 à 5 de l'en-tête. Ils changent à chaque connexion.
Piste d'investigation : Capturer 3 connexions successives avec Wireshark et comparer les 6 premiers octets pour trouver la logique (incrément, timestamp, ou aléatoire).
- Analyse du Binaire Client :
Si l'algorithme est trop complexe, examiner l'exécutable du client HQP (`HQPClient.exe`) avec un outil comme Ghidra ou IDA Pro pour extraire la fonction de calcul de l'en-tête.
- Contournement Web :
Vérifier dans la configuration du serveur si une option "Web Interface" ou "Remote API" peut être activée sur un port HTTP (80/8080). Ce serait beaucoup plus simple à implémenter.
? Outils utilisés : Wireshark, PowerShell (.NET Sockets), Analyse Hexadécimale.
Conclusion : Le protocole est robuste mais "fermé". Il est possible de lire les flux (vol de connexion) si l'on parvient à simuler l'en-tête binaire valide et à envoyer la séquence d'init complète, mais le serveur reste muet si la moindre étape est incorrecte.
