Régler le volume de mes écouteurs Bluetooth
(blog.ornx.net)- Les sons système des écouteurs Tozo T6 lors de l’appairage, de la connexion et de la déconnexion étaient trop forts ; le problème a été résolu en réduisant directement le gain des fichiers audio dans le firmware
- Le chipset a été supposé appartenir à la famille Airoha AB1562, et l’application AirReps156X a permis de confirmer la possibilité d’obtenir des informations de diagnostic et de téléverser un firmware modifié
- Le trafic de vérification des mises à jour de l’application Tozo a été intercepté avec mitmproxy, ce qui a permis de récupérer, dans la réponse de
/api/v1/getOtaVersionV3, les liens vers les binaires de firmware des écouteurs - Le firmware était composé de deux FotaPackage et de deux FileSystemImage pour les écouteurs gauche et droit ; les fichiers mp3 se trouvaient tels quels dans l’image du système de fichiers à modifier
- Après avoir réduit uniquement le gain de -19,5 dB avec
mp3gain, sans réencoder les mp3 ni en changer la durée, les octets internes de l’image ont été remplacés puis flashés ; l’appareil fonctionne normalement et le son est bien plus faible
Sons système trop forts et hypothèses initiales
- Les écouteurs Tozo T6 jouaient un son à chaque appairage, connexion et déconnexion, et ce son était trop fort par rapport au niveau préféré par l’utilisateur
- Baisser toutes les bandes de quelques dB dans l’égaliseur ne résolvait pas le problème, et après un e-mail envoyé à Tozo, l’entreprise a répondu qu’elle ne pouvait rien faire
- L’objectif était de modifier le firmware exécuté sur l’appareil afin de réduire le volume du fichier sonore concerné
- Au départ, l’approche reposait sur plusieurs hypothèses
- Il est possible de trouver en ligne un binaire de firmware pour l’appareil
- Le firmware pourrait avoir une structure binaire facile à comprendre, comme ELF
- Le fichier audio est inclus dans le firmware et peut être modifié si l’on connaît son offset et sa longueur
- L’audio pourrait être dans un format simple comme PCM
- Le firmware modifié peut être flashé avec un outil destiné à l’appareil ou au chipset
- En pratique, plusieurs de ces hypothèses se sont révélées fausses, et la mise en place d’une infrastructure d’analyse comme un proxy, ainsi que la recherche de chemins de contournement, ont pris plus de temps que la rétro-ingénierie elle-même
Identification de l’appareil et du chipset
- Les appareils électroniques bon marché impliquent généralement plusieurs acteurs et couches
- Le vendeur qui commercialise le produit sous sa marque est ici Tozo
- Il existe un chipset, le matériel central qui exécute le firmware
- Le chipset peut utiliser une ISA dérivée de technologies de base comme ARM ou MIPS
- Des fonctions pour des coprocesseurs supplémentaires ou des interfaces matérielles peuvent être intégrées
- En désassemblant l’application Android de Tozo, des références à l’Airoha SDK, à un modèle précis de puce et à des fonctions de base communiquant avec l’appareil ont été trouvées
- La communauté Reddit
/r/airreps, consacrée aux clones d’AirPods, a fourni des informations sur la direction à suivre, et l’application AirReps156X a également été examinée - L’application AirReps156X utilise l’Airoha SDK et pouvait fournir des informations de diagnostic sur les appareils Airoha
- Une fois l’appareil connecté à cette application, la chaîne de diagnostic
QW_1562U_SDK1.5.1s’est affichée ; sur cette base, le chipset de l’appareil a été identifié comme appartenant à la série Airoha AB1562 - L’application AirReps156X dispose aussi d’une fonction permettant de flasher un nouveau firmware, ce qui remplissait une condition essentielle pour téléverser un firmware modifié sur l’appareil
Trouver l’URL du firmware dans le trafic de l’application Tozo
- Lorsqu’elle se connecte aux écouteurs, l’application Tozo affiche la version actuelle du firmware et indique si elle est à jour
- En partant de l’idée que l’application communiquait avec un serveur pour vérifier les informations sur le dernier firmware, l’objectif était de trouver l’URL réelle du fichier de firmware pendant la vérification de mise à jour
- Plutôt que de lire jusqu’au bout le code décompilé dans une analyse statique, le choix s’est porté sur une analyse dynamique en observant directement les requêtes réseau
- Un proxy d’interception a été mis en place avec une carte réseau sans fil,
hostapdetmitmproxy - L’APK Tozo a été patché avec
apktooletuber apk signerafin de faire confiance au certificat TLS mitmproxy du magasin de CA utilisateur- Les applications Android ne consultent souvent par défaut que le magasin de CA système
- Le patch de l’APK permettait d’utiliser aussi le magasin de CA utilisateur, puis de le resigné pour qu’il s’exécute sur Android
- La configuration du proxy comprenait le paramétrage de l’AP, la redirection du trafic 80/443 vers le port de mitmproxy avec
iptables, ainsi que la configuration du NAT - Lorsque l’application affichait « current » à côté de la version du firmware, elle envoyait une requête vers l’endpoint
/api/v1/getOtaVersionV3, et la réponse contenait les liens vers les binaires de firmware nécessaires
Structure et analyse des fichiers de firmware
- Le firmware obtenu se composait au total de 4 fichiers
- Un
FotaPackagepour chacun des écouteurs gauche et droit - Un
FileSystemImagepour chacun des écouteurs gauche et droit
- Un
- Les deux images de système de fichiers étaient identiques ; les fichiers uniques étaient donc les deux FotaPackage gauche/droit et une image de système de fichiers, soit 3 fichiers au total
file,strings,hexdumpetbinwalkont été utilisés pour tenter d’identifier le format et les fichiers intégrés- Dans l’image du système de fichiers, certaines chaînes correspondant à des noms de fichiers étaient visibles, mais
binwalkn’a pas détecté les fichiers mp3 attendus - Les mp3 ne disposent pas de magic number ou de footer clairement définis, ce qui rend difficile la détermination de l’offset et de la longueur dans un binaire arbitraire
- Le début peut être
0xFFFFou0xFFFE - Aucun des deux n’est suffisamment distinctif comme identifiant de fichier
- Le début peut être
- En supposant que connaître la structure de l’image du système de fichiers permettrait de déterminer le début et la fin de chaque fichier, l’analyse s’est orientée vers la compréhension du format de l’image
Analyse d’entropie et ROFS
- L’analyse d’entropie est utile pour visualiser quelles parties d’un fichier ressemblent à des constantes, à du bruit aléatoire ou à du texte ASCII, ainsi que les points de transition
- L’image du système de fichiers présentait une structure visible, mais les fichiers FotaPackage semblaient compressés ou chiffrés
- Les FotaPackage gauche et droit ne différaient que sporadiquement sur une partie de leur en-tête, leur corps était presque identique, puis les quelque 7 Ko de fin divergeaient complètement
- La signification exacte de cette différence n’a pas été identifiée, mais une transformation opaque semblait appliquée, rendant difficile l’obtention d’informations utiles sans effort important
- L’image du système de fichiers commence par la chaîne ASCII
ROFS - Aucune documentation publique ni information de format correspondante n’a été trouvée pour
ROFS, et l’Airoha SDK découvert plus tard contenait une implémentation d’interface permettant de lire cette image - Une piste consistant à déchiffrer les FotaPackage a été tentée un temps, mais elle n’a permis que de vérifier que le SDK ne transformait pas le firmware avant l’envoi, sans autre résultat
Réduire le volume sans réencoder les mp3
- Le fait que les fichiers soient des mp3 était initialement un facteur de risque
- Les encodeurs mp3 ont beaucoup d’options, et un décodeur inconnu peut ne pas gérer certains fichiers pourtant valides
- Si l’audio joué juste après la connexion provoque un problème, l’appareil peut planter avant de se reconnecter, le rendant irrécupérable
- Réencoder les mp3 pouvait changer la longueur des fichiers, ce qui aurait probablement nécessité de modifier avec précision les informations de longueur dans l’image du système de fichiers
- Heureusement, il était possible d’ajuster le gain des mp3 sans réencodage, sans changement de longueur et sans modification des métadonnées
- Cela ressemble à une modification d’une partie de la structure interne des données, comme lorsqu’on peut faire pivoter un JPEG sans le réencoder
Indices décisifs obtenus dans le SDK
- Une recherche sur le nom du chipset a permis de trouver une copie de l’Airoha SDK, qui contenait des fichiers
.mp3identiques à ceux entendus sur l’appareil - Un petit programme Python,
bincontains.py, a été écrit pour vérifier quels fichiers étaient inclus tels quels dans un autre binaire - Il a été vérifié que les fichiers mp3 du SDK se trouvaient tels quels dans l’image du système de fichiers
- Ils n’étaient pas compressés
- Ils n’étaient pas découpés en blocs
- Il était donc possible de calculer leur offset et leur longueur dans l’image
- Le code du SDK lié à ROFS a été brièvement examiné, et aucun symbole ne suggérant fortement la présence d’une somme de contrôle n’est apparu
- À ce stade, les conditions nécessaires à la modification étaient réunies sans rétro-ingénierie supplémentaire
- Les fichiers de firmware et la méthode de flash étaient disponibles
- La position et la longueur des mp3 dans l’image étaient connues
- Le gain des mp3 pouvait être ajusté sans changer leur longueur
- Il était supposé que modifier seulement une plage d’octets dans un fichier ne casserait pas les métadonnées du système de fichiers
Modification de l’image du système de fichiers et flash
- Un script Bash parcourait les fichiers mp3 du SDK et cherchait ceux inclus dans l’image du système de fichiers
- Le mp3 inclus était copié dans un fichier temporaire, puis son gain était réduit avec
mp3gain - La valeur d’ajustement utilisée était de -19,5 dB
- Après avoir vérifié que la taille du mp3 modifié était identique à l’original, les octets étaient écrasés avec
ddà l’offset correspondant dans l’image du système de fichiers - Dans le diff binaire, l’image de firmware finale ne présentait, comme prévu, que quelques octets modifiés
- Le firmware modifié a été flashé sur l’appareil ; celui-ci a fonctionné normalement et les sons système étaient beaucoup plus faibles qu’au départ
Résultat et limites
- Il n’a pas été nécessaire de casser le chiffrement du firmware ni de comprendre entièrement le format de système de fichiers
ROFS - En pratique, une grande partie du temps de rétro-ingénierie a été consacrée à des pistes de contournement qui n’étaient pas directement nécessaires à la solution finale
- Si le réglage du volume des sons système avait été une fonction de base de l’appareil, cette modification n’aurait pas été nécessaire
- Pour un appareil qui lit de l’audio, il serait plus approprié que l’interface propose un contrôle du volume s’appliquant à tous les sons émis par l’appareil
- Dans ce cas, réduire uniquement le gain des mp3 à l’intérieur de l’image de firmware a suffi à créer un contournement satisfaisant
1 commentaires
Avis de Hacker News
J’aimerais bien que quelqu’un corrige aussi mon masque de sommeil Bluetooth comme ça
Dans l’ensemble il est plutôt bon, mais quand la batterie est faible ou qu’il est sur le point de s’éteindre, il l’annonce au volume maximum
Dans un masque de sommeil
J’ai eu un réveil avec un défaut similaire, qui avait une fonction de synchronisation horaire radio MSF
Sauf qu’à chaque resynchronisation avec le signal horaire MSF, il émettait pendant 2 à 3 secondes le même son que l’alarme, sans possibilité de le désactiver
Ça sonnait toujours vers une heure horrible, genre 3 h du matin, donc j’ai fini par l’ouvrir et couper l’antenne MSF, et j’ai mieux dormi en sachant que l’horloge serait toujours un peu décalée
Pendant ce temps, j’essaie de rattraper ce que mon interlocuteur a dit pendant quelques secondes, sans grand succès
Cette notification est bien pire que ne rien faire. Sans avertissement, le pire scénario serait que le son se coupe et que je rate ce que l’autre personne dit ; le clip d’oreille recrée délibérément exactement cet effet, mais plus tôt
Il n’y a aucune raison de ne pas l’intégrer au flux audio existant sous forme de motif de bips discret, par exemple. Ça prendrait moins d’une seconde et ne créerait pas soi-même le problème que c’est censé éviter
Autre comportement Bluetooth catastrophique difficile à imaginer : quand on utilise un chat vocal, tout l’audio normal de l’ordinateur disparaît. Si le chat vocal utilise l’entrée micro, l’appareil Bluetooth passe en mode « casque », ce qui transforme la stéréo en mono et devient la seule sortie autorisée tant qu’une entrée audio est fournie, ou susceptible de l’être
Les applis qui n’utilisent pas l’entrée audio continuent alors à jouer vers un périphérique casque Bluetooth qui n’existe plus, et ne peuvent donc plus produire de son
Je ne comprends pas pourquoi il faut plusieurs modes de périphérique. Je ne vois pas pourquoi je voudrais perdre des fonctionnalités comme effet secondaire du fait de parler à ma famille. Je ne vois pas ce qu’il y a de si difficile à lire simultanément deux signaux audio différents dans chaque oreille simplement parce que le micro pourrait être activé. Les appareils non Bluetooth gèrent ça, et ce n’est même pas considéré comme une fonctionnalité notable. Pourquoi « le casque ne s’éteint pas pendant qu’on utilise le micro » devrait-il être quelque chose de spécial ?
Super ! Bravo à l’auteur original d’être allé jusqu’au bout
Puisqu’on parle d’écouteurs trop forts, j’ai peut-être le problème inverse. Sur un tapis de course, j’utilise mes écouteurs de sport Bose à un niveau que je trouve confortable et prudent, mais mon iPhone m’envoie une notification disant que le volume est trop élevé et que je suis en train d’abîmer mon audition
Le téléphone a-t-il raison ? Si oui, je suis prêt à sacrifier un peu de plaisir pour la santé de mes oreilles. Mais il existe aussi une autre hypothèse plausible : à réglage de volume identique, ces écouteurs produisent un volume physique réel nettement plus faible que les autres produits que j’ai essayés, et la modélisation paresseuse d’Apple pourrait générer de fausses alertes comme celles que je reçois
Si Apple a créé une base de données qui associe les modèles de produits et les réglages de volume au volume physique réel, je lui tirerais mon chapeau. Mais les notifications et la description de la fonctionnalité ne donnent aucun détail, donc je n’ai pas confiance, et je n’ai pas envie de rendre mes séances de sport moins agréables simplement parce qu’Apple aurait mis dans un vrai produit un modèle digne d’un devoir universitaire
Quelqu’un sait si la data science derrière ces alertes est sérieuse ?
Premièrement, sur iOS, le volume minimum de mes écouteurs Bluetooth est trop élevé. Ça a été le cas avec tous les casques tiers que j’ai essayés, et les plaintes en ligne durent depuis 10 ans. L’UE a même adopté une loi pour faire corriger ça, mais spoiler : ça n’a servi à rien
S’il vous plaît, le volume minimum de l’interface devrait être mappé sur l’entier de volume matériel 1
Deuxièmement, les applis tierces ne peuvent pas exposer de la musique ou des podcasts dans le menu de navigation média Bluetooth de la voiture. Sur Android, c’est possible
Du coup, sur Android, je peux écouter des podcasts et streamer Tidal avec la molette de la voiture, mais pas sur iOS
J’ai aussi d’autres griefs contre le Bluetooth. Pourquoi mon Apple Watch met-elle l’autoradio sur liste noire ? Le Bluetooth des versions iOS N et N-1 est vraiment bourré de bugs
C’est simplement une fonctionnalité manifestement idiote. Si seulement je pouvais le rooter, je pourrais sûrement désactiver l’interrupteur correspondant dans un fichier de configuration quelque part, mais je n’y suis jamais arrivé sur le Samsung Galaxy J1 (2016)
Mon Bose se comporte aussi différemment selon le chipset Bluetooth. Sous Linux, je dois mettre le volume à 150 % pour entendre correctement quoi que ce soit
Mais il n’y a aucune raison de croire qu’ils l’aient fait. Ce serait intéressant si les fabricants de casques indiquaient leur plage en dB lors de la connexion Bluetooth pour rendre ce genre de fonction possible, mais je n’ai jamais entendu parler de ça. Contrairement au jack 3,5 mm, le Bluetooth est bien un domaine où ce genre de fonction pourrait être rendu possible
Avec la réduction de bruit, on peut garder le volume sous les 20 % tout en ayant une écoute confortable sans malmener ses oreilles
Dans mon cas, après de longues séances de sport il y a quelques années, j’ai commencé à avoir mal aux oreilles, donc je pense que les alertes d’Apple avaient probablement raison. Depuis que j’utilise la réduction de bruit, ça a complètement disparu
J’adore ce genre de travail. Soudain, ce modèle d’écouteurs me paraît assez intéressant.
Au passage, les sons système émis par les appareils Bluetooth font partie des éléments qui différencient le plus fortement les produits. Certains sont carrément horribles : https://youtu.be/J2wPsH64JEM
Pourtant, je n’ai jamais vu une review ou une page produit indiquer quels sons l’appareil émet. Alors qu’on doit les entendre plusieurs fois par jour, sans moyen de les désactiver.
Rien que permettre de modifier ces sons serait sans doute un moyen assez simple de se différencier.
C’est parfait quand je porte des bouchons d’oreille dans un atelier bruyant, mais dans un bureau calme, quand je mets la musique à faible volume pour me concentrer, c’est gênant et ça me fait sursauter.
Je ne comprends pas pourquoi les sons système ne suivent pas le réglage du volume.
Ce serait bien que le téléphone sache si le casque connecté est un ensemble d’enceintes, des in-ear monitors, un casque à conduction osseuse, etc.
Quand on utilise un ensemble d’enceintes classique et qu’on veut volontairement monter le son pour l’entendre partout dans la maison, la notification « volume trop élevé » est agaçante.
Avec un casque à conduction osseuse, il faut un volume assez élevé pour bien entendre, donc c’est deux fois plus agaçant.
Heureusement que c’est une cible Airoha sans chiffrement du firmware.
Pour les curieux, il existe aussi un template 010 Editor pour le format du firmware.
https://github.com/ramikg/airoha-firmware-parser
Le niveau technique est impressionnant, mais c’est dommage qu’il faille autant d’efforts pour faire quelque chose d’aussi basique que modifier légèrement le volume de lecture d’un fichier.
On ne devrait pas avoir à se donner autant de mal pour faire en sorte qu’un outil se comporte comme on le souhaite.
Ce n’est pas « compréhensible ». On a payé le produit, et c’est un problème produit qui doit être corrigé.
Après avoir lu cet article, j’ai acheté des Tozo T6 d’occasion ; ils semblaient pourtant avoir été fabriqués assez récemment, mais je n’ai pas réussi à reproduire le résultat.
L’application officielle Tozo ne reconnaissait même pas le casque, et je n’ai pas pu confirmer qu’il utilisait un chipset Airoha, qui se serait identifié par la prise en charge de l’AAC. Le mien ne prend en charge que le SBC.
Soit j’ai acheté une contrefaçon, soit il y a eu des changements internes après l’achat de l’auteur.
Certains fichiers audio ressemblent à ceux inclus dans un SDK Airoha partiel disponible sur Internet, mais il lit aussi d’autres nouveaux fichiers vocaux.
Si vous voulez vérifier ce résultat de manière indépendante ou bricoler avec, des faux AirPods pourraient être une meilleure piste.
J’aimerais que davantage de gens se plaignent des sons système forts et mauvais.
Mes Sony WH-1000XM4 ont exactement le même problème, mais Sony semble chiffrer la charge utile du firmware et la déchiffrer sur l’appareil.
J’ai failli les démonter presque entièrement pour tout dumper et explorer, mais mes mains tremblent et le risque de les casser est trop élevé.
Je serais prêt à payer assez cher pour un casque à réduction de bruit bidouillable.