Bonjour tout le monde !
Aujourd’hui, j’ai le plaisir de vous présenter la suite (et fin ?) du « reverse engineering » des interrupteurs domotique Blyss.
Comme promis dans mon précédent article je vais aujourd’hui détailler la partie software 😉
—
Introduction :
Avant toute chose je tient à préciser que ce « reverse engineering » est le fruit des efforts de 6 membres du forum arduino.cc ainsi que de moi même, à savoir :
– Artouste (http://arduino.cc/forum/index.php?action=profile;u=49110)
– Al1fch (http://arduino.cc/forum/index.php?action=profile;u=46688)
– Barbudor (http://arduino.cc/forum/index.php?action=profile;u=70207)
– Bunyman (http://arduino.cc/forum/index.php?action=profile;u=131410)
– Trigger (http://arduino.cc/forum/index.php?action=profile;u=56754)
– Bidle (http://arduino.cc/forum/index.php?action=profile;u=123020)
Disclaimer :
Je tiens aussi à préciser que la rétro-ingénierie est autorisée par la loi Française à des fins d’interopérabilité tel que garanti par l’article L122-6-1 du code de la propriété intellectuelle.
Il est ici question de comprendre le fonctionnement d’un système et d’en tirer des connaissances, en aucun cas il n’a été question de concevoir un clone du produit d’origine.
Remarque :
Certaines images utilisées dans mon article ont été récupérées sur le wiki de Barbudor.
Celles ci sont annotées « Crédit image : Barbudor » et sont disponible dans leur contexte d’origine ici :
https://barbudor.wiki.zoho.com/Système-domotique-Blyss-de-Castorama.html
Wiki sur lequel vous trouverez aussi de nombreuses informations complémentaires, comme les différents types de modules émetteur / récepteur.
—
Accrochez vous à votre siège c’est parti 😉
Les informations technique :
Les émetteurs / récepteurs travaillent sur une fréquence porteuse de 433.92MHz, avec une modulation de type ASK (modulation d’amplitude).
Cela signifie qu’il est possible d’utiliser des kits 433MHz low-cost du commerce pour communiquer avec ses modules Blyss.
Remarque: ce hack n’est valable qu’avec les interrupteurs ou « lampe douille » Blyss, pas avec la station météo, le système de caméra, etc qui travaillent sur du 868MHz avec un protocole sécurisé.
—
La trame RF :
Tout d’abord voici à quoi ressemble une trame RF « Blyss » :
Comme on peut le voir celle ci est composé d’un entête, suivit de 52 bits et d’un temps mort séparant deux trames.
Au niveaux des timings, on obtient après mesure :
– 2.4ms pour l’entête,
– 24ms pour le temps mort (footer),
– trame complète : 65ms.
Et au niveau des bits :
– 400us pour un temps bas,
– 800us pour un temps haut
—
Codage d’un bit :
(Crédit image : Barbudor)
Soit T = temps bas, 2T = temps haut.
Un bit est encodé suivant un schéma de type 1/3 2/3, en logique négative.
Cela signifie que :
– Un « 1 » logique = T:LOW + 2T:HIGH
– Un « 0 » logique = 2T:LOW + T:HIGH
(Voir le schéma ci dessus pour un exemple de décodage)
—
Le décodage de la trame RF :
La trame RF est composé d’une série d’informations organisées comme ceci :
- entête 2.4ms HIGH,
- empreinte 0xFE (8 bits),
- canal global (4 bits),
- adresse (16 bits),
- sous canal (4 bits),
- état lumière (état logique) (4 bits),
- rolling code, MSBFIRST (8 bits),
- timestamp incrémentiel (0 ~ 255), MSBFIRST (8 bits),
- footer 24ms LOW
Remarque : comme on peut le voir il n’y a aucune vérification d’erreur (checksum) dans la trame.
Ce manque est compensé par un nombre minimum requis d’émission de la trame (entre 4 et 13), ce qui reste pour le moins bancale comme protocole.
Détail des champs :
Les canaux globaux :
canal A = 0
canal B = 1
canal C = 2
canal D = 3
Les sous canaux :
canal 1 = 8
canal 2 = 4
canal 3 = 2
canal 4 = 1
canal 5 = 3
tout les canaux = 0
Le rolling code :
0x98 -> 0xDA -> 0x1E -> 0xE6 -> 0x67
Note : bien respecter l’ordre de rotation.
Informations complémentaires :
– 4 envois minimum de la trame,
– Incrémentation de +10 pour le timestamp,
– Timing en réception trés approximatif (due au matériel utilisé).
—
Détail du « timestamp » :
Certains pourraient se demander d’où nous est sorti cette idée du compteur s’incrémentant de 0 à 255.
En fait c’est très simple.
Nous avons enregistré des 10ènes et des 10ènes de trames consécutives, puis extrait les valeurs du champ « timestamp » afin d’en comprendre le fonctionnement.
Une étude rapide des données a alors démontré qu’il s’agissait d’une valeur tirée d’un compteur 8 bit comme on peut le voir sur les résultats d’analyse :
Remarquez la régularités des pic et les valeurs min / moy / max, l’utilisation en interne d’un timer 8 bit ne fait aucun doute.
Fichier open-document calc :
https://github.com/skywodd/arduino_blyss_hack/blob/master/Blyss_trame_analyse/others/stats_counter.ods
—
Les utilitaires arduino :
Maintenant que le protocole est entièrement documenté je peux vous présenter les deux codes arduino servant à manipuler des modules « Blyss » :
Le Sniffer : https://github.com/skywodd/arduino_blyss_hack/tree/master/Blyss_arduino_code/RF_Blyss_Sniffer
Le Spoofer : https://github.com/skywodd/arduino_blyss_hack/tree/master/Blyss_arduino_code/RF_Blyss_Spoofer
Description rapide des deux programmes :
– RF_Blyss_Sniffer.ino : Capture et décode les trames RF Blyss « à la volé » (entrée signal RF sur D12 ET D2).
– RF_Blyss_Spoofer.ino : Génère un signal RF compatible Blyss (sortie du signal RF sur D4).
Le sniffer ne fait que lire les trames Blyss qu’il capte et les affichent suivant un format humainement lisible.
Exemple :
RF frame : FE 79 09 E8 11 EC 10
RF footprint : FE - OK
RF global channel : 7
RF adress : 90 9E
RF channel : 1
Light status : OFF
Rolling code : 1E - OK
Timestamp : C1
Trame echo 2
Trame echo 3
Trame echo 4
Trame echo 5
Trame echo 6
Trame echo 7
Trame echo 8
Trame echo 9
Trame echo 10
Trame echo 11
Trame echo 12
Trame echo 13
Au passage le sniffer détecte aussi toute erreur de footprint et/ou de rolling code.
De même celui ci n’affiche qu’un message en cas de trame identique par la suite (la trame décodée étant comptée comme le 1er écho).
—
Le spoofer quand à lui est beaucoup plus complexe et fourni une API très complète pour manipuler et générer un signal compatible Blyss.
Documentation de l’API :
Définition :
– Buffer RF de clef : byte[3]
Ce buffer contient les 3 octets situé après l’empreinte d’une trame RF (0xFE).
Exemple :
byte RF_KEY[] = {
0x79, 0x5F, 0x78 // Micro émetteur @SkyWodd
};
Buffer RF complet : byte[7]
Ce buffer contient l’intégralité des données d’une trame RF.
Fonctions :
void generate_token(byte *data);
Génère un token incrémentielle sur 8 bits (= champ timestamp)
Prend en argument un buffer RF complet.
void generate_rolling_code(byte *data);
Génère un rolling code valide sur 8 bits (= champ « rolling code »)
Prend en argument un buffer RF complet.
inline void set_status(byte *data, byte status);
Change le statut de l’émetteur virtuel (= état de la prise ou de la lampe).
Prend en argument un buffer RF complet et un état logique de valeur ON ou OFF.
void send_buffer(byte *data);
Envoi un buffer RF complet (7 octets) une seul fois.
Prend en argument un buffer RF complet.
inline void send_command(byte *data);
Envoi un buffer RF complet n fois (à définir en début de programme) pour qu’il soit pris en compte par le récepteur.
Prend en argument un buffer RF complet.
inline void set_key(byte *data, byte *key, byte overwrite);
Copie un buffer RF de clef dans un buffer RF complet.
Prend en argument un buffer RF complet, un buffer RF de clef et un mode de copie :
– si overwrite = true, le canal global et le sous canal du buffer complet seront écrasés par les valeurs contenues dans le buffer de clé.
– si overwrite = false, le canal global et le sous canal du buffer complet seront conservés et les valeurs contenues dans le buffer de clé seront ignorées.
inline void set_channel(byte *data, byte channel);
Change le sous-canal d’émission du buffer RF complet.
Prend en argument un buffer RF complet et un sous-canal, de valeur possible : CH_1, CH_2, CH_3, CH_4, CH_5 ou CH_ALL.
inline void set_global_channel(byte *data, byte channel);
Change le canal global d’émission du buffer RF complet.
Prend en argument un buffer RF complet et un canal global, de valeur possible : CH_A, CH_B, CH_C ou CH_D.
—
Annexe A :
L’organisation interne de l’EEPROM des récepteurs (pour les curieux) et les divers scripts et commandes “bus pirate” pour réaliser le dump.
Les commandes « Bus pirate » :
– Dump complet de l’EEPROM :
[0xa0 0x0 [0xa1 r:256]
– Effacement complet de l’EEPROM (pour avoir un EEPROM vierge comme en sortie d’usine) :
[0xa0 0x00 0xff:16]
[0xa0 0x10 0xff:16]
[0xa0 0x20 0xff:16]
[0xa0 0x30 0xff:16]
[0xa0 0x50 0xff:16]
[0xa0 0x60 0xff:16]
[0xa0 0x70 0xff:16]
[0xa0 0x80 0xff:16]
[0xa0 0x90 0xff:16]
[0xa0 0xA0 0xff:16]
[0xa0 0xB0 0xff:16]
[0xa0 0xC0 0xff:16]
[0xa0 0xD0 0xff:16]
[0xa0 0xE0 0xff:16]
[0xa0 0xF0 0xff:16]
Note : L’effacement ce fait par page de 16 octets.
Structure interne de l’EEPROM :
A l’adresse 0xF0 ce trouve un octet égal au nombre de télécommandes stockées en mémoire, suivit d’un 0x00.
Juste après se trouve un octet de valeur 0x00 ou 0xFF indiquant l’état actuel de l’interrupteur (0x0 -> éteint, 0xFF -> allumé).
A cela s’ajoute une sorte « d’empreinte » invariable : 0x55 0x80 servant à déterminer l’état de l’EEPROM (vierge sortie d’usine, …)
L’octet 0x80 revient en fin de chaque adresse stocké en mémoire.
Exemple annoté de dump d’EEPROM :
0x0F 0xE3 0x92 0x1A 0x80 0xFF 0xFF 0xFF 0x0F 0xE7 -> adresse n°1 + octet de vérif + 3 octets inutiles
0x95 0xF7 0x80 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF -> adresse n°2 + octet de vérif + 3 octets inutiles
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0x02 0x00 0x00 0x55 0x80 0xFF 0xFF 0xFF 0xFF 0xFF -> nombre d'émetteurs en mémoire, 0x00, état de l'interrupteur, 0x55, octet de vérif
0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
Fichier de dump de l’EEPROM :
https://github.com/skywodd/arduino_blyss_hack/tree/master/Blyss_trame_analyse/eeprom_dump
—
Annexe B :
Les outils d’analyse des trames capturées via OLS (utiles avant la création du Sniffer arduino, désormais obsolète).
Les utilitaires d’analyse :
– Décodeur automatique de capture OLS (version CLI, avec décodage de trame multiple) :
https://github.com/skywodd/arduino_blyss_hack/blob/master/Blyss_trame_analyse/others/ols2data_cli.py
– Décodeur de capture OLS (version non CLI, sans décodage de trame multiple) :
https://github.com/skywodd/arduino_blyss_hack/blob/master/Blyss_trame_analyse/trame_dump/ols2data.py
Fichiers d’exemple (capture OLS + dump EEPROM + décodage) et utilitaires de traitement par lot :
https://github.com/skywodd/arduino_blyss_hack/tree/master/Blyss_trame_analyse/trame_dump
—
Un récapitulatif des informations énoncées dans cet article est disponible sur le forum ici :
http://arduino.cc/forum/index.php/topic,109892.msg830563.html#msg830563
Pour plus d’informations concernant les différents modules « Blyss » je vous conseille de jeter un oeil au wiki de barbudor :
https://barbudor.wiki.zoho.com/Système-domotique-Blyss-de-Castorama.html
Pour ceux qui voudrait suivre l’intégralité du hack depuis le début, vous pouvez faire un tour sur le topic dédié (attention 20 pages actuellement ) :
http://arduino.cc/forum/index.php/topic,109892.0.html
—
Et la suite ?
Nous sommes en train de réfléchir afin de voir comment créer notre propre « Blyss Box » DIY.
Le hardware serait basé sur un routeur TL-WR703N, avec une carte teensy comme interface RF / Usb et un firmware alternatif linux (OpenWRT ou DD-WRT) faisant tourner un programme de gestion domotique.
Un topic dédié a été crée pour l’occasion :
http://arduino.cc/forum/index.php?topic=110677.0
Pour le moment rien n’est encore décidé, tout reste donc à faire 😉
—
Conclusion :
Voila qui conclut cette formidable aventure dans le monde du « Reverse engineering ».
J’espère que cet article vous aura vous aussi donné l’envie de vous lancer dans l’aventure 😉
Ce fut une incroyable expérience, je remercie du fond du cœur tout les membres du forum arduino.cc qui m’ont aidé, et qui n’ont pas hésité à acheter du matériel dans ce seul but.
Merci à tous pour votre aide !
Ps:
Pour rebondir sur l’actualité web du moment, petit message à l’attention de tout les journalistes, présentateurs et autres kevin du forum 15-18 de JV.com :
Ceci est un hack, un vrai ! Fait par de vrais hackers ayant pour but d’améliorer les choses !
Le jour ou vous comprendrez qu’un hacker n’est pas un ado boutonneux devant son ordinateur, tapant de sombre lignes de commande tel que « ping », « nslookup » ou encore « ipconfig » (Ooo damned !), écrit en vert dans sa console à fond noir (forcément, cliché matrix oblige) l’humanité sera peut être enfin au courant du vrai sens du mot « hacker ».
« Hacker » est un mot d’origine anglo-américain, qui signifie littéralement « bidouilleur ». Dans son sens général, un hacker est quelqu’un qui aime comprendre le fonctionnement d’un mécanisme, afin de pouvoir le bidouiller pour le détourner de son fonctionnement originel. Appliqué à l’informatique, un hacker sait comment bidouiller un programme pour en faire ce qu’il veut.
cf : http://fr.wikipedia.org/wiki/Hacker
Bon bidouillage et bonne fin de journée à tous ! 🙂
Skyduino - Le DIY à la française 
Excellent hack !
Publié par CasoTronics | 19 juillet 2012, 17 h 45 minJ’ai du râter peut-être quelquechose, mais tu ne donne pas d’information sur les 2 modules (émission et reception j’imagine) qui sont en photo sur la carte proto.
Publié par skyr1der59 | 19 juillet 2012, 18 h 30 minoups j’ai dit une connerie.. je n’avais pas compris que c’était les modules blyss
Publié par skyr1der59 | 19 juillet 2012, 18 h 32 minNon c’est pas ça les modules Blyss 😉
Voir mon commentaire juste en dessous et la 1er partie de l’article :
https://skyduino.wordpress.com/2012/07/17/hack-partie-1-reverse-engineering-des-interrupteurs-domotique-blyss/
Publié par skywodd | 19 juillet 2012, 18 h 34 minCe sont de bête module 433MHz low-cost du commerce 😉
Cf 1er point de l’article :
« Les émetteurs / récepteurs travaillent sur une fréquence porteuse de 433.92MHz, avec une modulation de type ASK (modulation d’amplitude).
Cela signifie qu’il est possible d’utiliser des kits 433MHz low-cost du commerce pour communiquer avec ses modules Blyss. »
Publié par skywodd | 19 juillet 2012, 18 h 32 minBonjour,
Je suis demandée de faire du « reverse engineering » pour comprendre une trame qui sert à commander un interrupteur mais dont je ne connais pratiquement rien! juste la forme de la trame d’une action ON et OFF (2 photos prises de l’oscillo) et comme je débute avec le monde du codage et transmission numérique, je souhaite comprendre comment vous faites le choix du code à adopter (NRZ, NRZI, Manchester..) pour comprendre les données contenues dans la trame ???
Publié par perdue | 23 février 2015, 10 h 49 minYa pas de miracle, faut tester toutes les possibilités envisageable, faire des suppositions et voir par déduction ce qui marche et ce qui ne marche pas.
Publié par Skywodd | 10 mars 2015, 7 h 26 minexcellent j’ai tous suivi sur le forum ca tombe bien j’ai un BP et un OLS… j’me tate 🙂
Publié par crash | 19 juillet 2012, 19 h 24 minJ’ai commencé à lire les post sur le forum Arduino mais c’est un peu long….
En tout cas chapeau bas pour ce boulot de fou…
Publié par Peedjy | 20 juillet 2012, 17 h 30 minHey salut,
Je cherchais à trouver un exemple de sniffing RF sur des trames non Manchester et non NRZ avec OLS (genre voir si quelqu’un avait fait un plugin pour décoder les tram en direct sur les waves) et sur dangerousprototypes.com et ils avaient un liens vers ton site! Donc là ,je commence à lire , et me dis… excellent un français… et la EXCELLENT IL FAIT ÇA SUR les modules Blyss! Exactement ce sur quoi j’était en train de me lancer(j’avais déjà dumpé quelques tram et commençais à les analyser…). Donc un Grand merci pour le près-mâchage du travail!
Je vais suivre de près le reste pour la DIY Blyss box sachant que j’ai déjà un petit server low power qui tourne a la maison un ‘dockstar’ avec une Debian, vais peut etre partir sur un Domogik… on vera
Merci pour le travail!
Publié par Sheda | 1 octobre 2012, 0 h 48 min>> Exactement ce sur quoi j’était en train de me lancer(j’avais déjà dumpé quelques tram et commençais à les analyser…). Donc un Grand merci pour le près-mâchage du travail!
On si est mis à six pour renverser le protocole, ça n’as pas était une mince affaire 🙂
Si tu veut avoir la démarche de A à Z tu as le line vers le topic arduino.cc 😉
>> Je vais suivre de près le reste pour la DIY Blyss box sachant que j’ai déjà un petit server low power qui tourne a la maison un ‘dockstar’ avec une Debian, vais peut etre partir sur un Domogik… on vera
Avec le reste de l’équipe du forum ont est parti sur un hardware type « routeur chinois » (WR703N / MR3020) + openWRT.
Pour le software les choses ne sont pas encore décidé.
On as deux topics sur le forum arduino.cc sur le sujet, par contre j’ai plus les liens sous la main.
Publié par skywodd | 1 octobre 2012, 19 h 06 minbonjour Et Bravo pour le boulot 🙂
Je suis nouveau dans le monde Arduino mais l’électronique ne me pose pas grand soucis cependant à la compilation du code j’ai ce message et je tourne en rond pour trouver la solution …
sketch_oct08a.cpp: In function ‘void setup()’:
sketch_oct08a:277: error: ‘digitalPinToBitMask’ was not declared in this scope
sketch_oct08a:278: error: ‘digitalPinToPort’ was not declared in this scope
sketch_oct08a:278: error: ‘portInputRegister’ was not declared in this scope
Si quelqu’un a une idée
Amicalement
Publié par TchaoPaulo | 8 octobre 2012, 17 h 50 minCe sont toute des fonctions bas niveau du « core arduino » …
Tu utilise quel version de l’ide arduino ?
Ya un truc louche …
Ps: tu est sûr d’avoir téléchargé le code depuis mon github ?
Publié par skywodd | 8 octobre 2012, 18 h 41 minMerci pour la réponse sapide 🙂
J’utilise la version 20 c’est un soucis ? toutes mes lib fonctionnent avec celui la :S
Mais ce qui est étrange c’est que comme tu le dis c’est du low level …
Autre petite question : Comment peut on modifier le tableau byte RF_KEY[] = {0x79, 0x5F, 0x78}; dans le code car j’utilise plusieurs télécommande …
Note : j’ai tenté :
RF_KEY[0]= 0x79;
RF_KEY[1]= 0x5F;
RF_KEY[2]= 0x78;
Mais sans sucés :s
Publié par TchaoPaulo | 10 octobre 2012, 13 h 17 min>> J’utilise la version 20 c’est un soucis ? toutes mes lib fonctionnent avec celui la :S
>> Mais ce qui est étrange c’est que comme tu le dis c’est du low level …
Essaye 0023 (dernière version stable de la branche 002x) mais c’est vraiment bizarre …
>> Autre petite question : Comment peut on modifier le tableau byte RF_KEY[] = {0×79, 0x5F, 0×78}; dans le code car j’utilise plusieurs télécommande …
Dans l’exemple tu as 3 clefs de fourni c’est justement pour donner la syntaxe.
(Ps: tu ne peut spoofer qu’une clef à la fois avec le spoofer)
/** Key ID to spoof */ byte RF_KEY[] = { //0x79, 0x5F, 0x78 // Micro émetteur @SkyWodd //0x39, 0x21, 0xA8 // Télécommande @SkyWodd 0x0E, 0xCB, 0xE8 // Détecteur IR @skywodd };Commente ma dernière clef et ajoute la tienne à la suite 😉
Si tu veut pouvoir spoofer plusieurs télécommande regarde du coté du programme « gateway » (voir sur le github du projet).
J’ai pas encore fait l’article dessus mais ça permet de spoofer / sniffer avec une console sur le port série.
Publié par skywodd | 10 octobre 2012, 18 h 10 minEdit : La seconde question porte sur la partie spoofer bien-sur 🙂
Publié par TchaoPaulo | 10 octobre 2012, 13 h 28 minMerci bien pour tes réponses 🙂
>>Commente ma dernière clef et ajoute la tienne à la suite 😉
Ca marche bien mais étant donné que je souhaite changer de canal je dois le modifier dans le programme … :S
>>Si tu veut pouvoir spoofer plusieurs télécommande regarde du coté du programme « gateway » (voir sur le github du projet).
J’ai pas encore fait l’article dessus mais ça permet de spoofer / sniffer avec une console sur le port série.
Nickel c’est exactement ce que je cherchais à faire mais malheureusement :
sketch_oct10a.cpp: In function ‘void setup()’:
sketch_oct10a:62: error: ‘isr_decoding_routine’ was not declared in this scope
sketch_oct10a.cpp: In function ‘void loop()’:
sketch_oct10a:80: error: ‘RF_BUFFER_RX’ was not declared in this scope
sketch_oct10a:80: error: ‘get_data’ was not declared in this scope
sketch_oct10a:83: error: ‘data_analyse’ was not declared in this scope
sketch_oct10a:110: error: ‘RF_BUFFER_TX’ was not declared in this scope
sketch_oct10a:110: error: ‘set_key’ was not declared in this scope
sketch_oct10a:115: error: ‘set_channel’ was not declared in this scope
sketch_oct10a:140: error: ‘set_global_channel’ was not declared in this scope
sketch_oct10a:157: error: ‘set_status’ was not declared in this scope
sketch_oct10a:160: error: ‘generate_rolling_code’ was not declared in this scope
sketch_oct10a:161: error: ‘generate_token’ was not declared in this scope
sketch_oct10a:165: error: ‘send_command’ was not declared in this scope
sketch_oct10a:168: error: ‘send_command’ was not declared in this scope
Je dois quand même bien avoir un soucis avec mon arduino.exe non ?
Publié par TchaoPaulo | 10 octobre 2012, 19 h 43 minNon c’est une stupide erreur de copié / collé que j’ai fait lors de la documentation du code …
J’ai mis à jour le github, merci de m’avoir fait remarquer le bug 😉
Publié par skywodd | 10 octobre 2012, 19 h 59 mintkt pas de soucis 🙂
Par contre je me retrouve toujours avec des erreurs de compil alors que j’ai testé 3 version (20,20,V1) …
Publié par TchaoPaulo | 10 octobre 2012, 20 h 04 minLes mêmes erreurs ?
Publié par skywodd | 10 octobre 2012, 20 h 06 minoui les même :S
Publié par TchaoPaulo | 10 octobre 2012, 20 h 11 minAjoute #include « pins_arduino.h » en haut du programme principal …
Normalement tu devrais pas avoir à la faire (l’ide le fait tout seul) mais je vois vraiment pas ce qui pourrait causer ces erreurs …
Publié par skywodd | 10 octobre 2012, 20 h 43 minSuper tuto. Merci.
Pour ce qui est de la Blyss Box pourquoi ne pas intégrer votre projet dans un projet de « home automation » existant. J’ai réussi á hacker mon thermostat sans fil et compte utiliser « freedomotic » pour gérer mon arduino les senseurs et etc. Freedomotic et vendeur agnostic développé en JAVA et peut intégrer d’autres systemes en parallele avec le systeme Blyss. Vous en pensez quoi?
http://freedomotic.com.
Publié par Marcoelgordo | 2 novembre 2012, 16 h 26 minJ’ai pas vraiment regardé ce qui existait déjà, je veut juste faire un truc simpliste pour le moment 😉
Publié par skywodd | 3 novembre 2012, 17 h 16 minHello, est ce celui de la marque Blyss que tu as réussi à hacker ?
Publié par Clement | 15 janvier 2013, 11 h 19 minHello,
Excellent boulot ! Ca fonctionne parfaitement chez moi.
Petite correction concernant le spoofer :
inline void set_global_channel(byte *data, byte channel) {
data[1] = (data[1] & 0x0F) | (channel & 0xF0);
}
–> il faut décaler le channel de 4 vers la gauche
Petite question : quelqu’un saurait à quoi sert ce global channel ?
Publié par Clement | 3 décembre 2012, 0 h 31 min>> il faut décaler le channel de 4 vers la gauche
Oups effectivement une petite boulette c’est glissé dans le code, c’est réparé .
Merci pour le coup de pouce 🙂
>> Petite question : quelqu’un saurait à quoi sert ce global channel ?
Aucune idée, âpres une rapide mise en relation des références de produit / global channel on c’est rendu compte que certains produits avait un certain channel suivant la série mais à pars ça on sait rien …
Publié par skywodd | 3 décembre 2012, 19 h 53 minSalut, je vois que tu est du genre tenace dans tes recherches, de mon coté je m’interresse aux télécommandes a rolling code de portail, mon site est celui présent dans le retolien sur cette même page.
J’aimerais savoir si tu as des pistes pour essayer de démonter le rolling code, as tu une idée sur une technique permettant de detecter le type de protocole et d’encodage. Quel procédé mathematique pourrait t’on utiliser pour distinguer le type de rolling code.
J’ai lu qu’ont peu mesurer le courant consommé par le microcontroleur et le temps necessaire pour generer le rolling code, ceci afin d’estimer la difficulter du codage.
@+
Publié par cyril | 15 janvier 2013, 2 h 43 min>> J’aimerais savoir si tu as des pistes pour essayer de démonter le rolling code,
Tout dépend du module, le mieux c’est de chercher des similitudes avec d’autre modules d’autre fabricants.
Souvent les chinois ont déjà fait une copie du produit et on peut trouver des doc trainant par ci par là.
L’analyse du hardware aide beaucoup aussi, la première étape c’est de démonter le module et de regarder les références de chaque composants actif.
>> as tu une idée sur une technique permettant de detecter le type de protocole et d’encodage.
Pour détecter le protocole, si c’est pas un CI « classique » le seul moyen de le décoder c’est de faire des acquisitions de trames à l’analyseur logique, plusieurs fois, sous plusieurs « situation » (bouton on, bouton off, …).
Ensuite il faut comparer, qu’est ce qui change, qu’est ce qui change pas entre deux même trames de deux même situation.
Et petit à petit on peut voir comment communique les modules entre eux.
Pour l’encodage au début j’étais parti sur du manchester (niveau encodage il y a pas énormément de solution technique possible), au final ça c’est avéré être une bête modulation au niveau des fronts (1/3 ou 2/3 de temps).
>> Quel procédé mathematique pourrait t’on utiliser pour distinguer le type de rolling code.
On a d’abord récupéré un grand nombre de trame, décodé chaque trame pour avoir son rolling code puis âpres on a fait des statistiques sur les résultats.
Au final on a obtenu un graph en forme de rampe 0 -> 255, qui nous a laissé penser à un timer 8 bits qui s’incrémente.
>> J’ai lu qu’on peu mesurer le courant consommé par le microcontroleur et le temps necessaire pour generer le rolling code, ceci afin d’estimer la difficulté du codage.
On sait pas amusé à faire ce genre de chose 😉
En plus la « difficulté du codage » peut très bien être forte sans que le microcontrôleur ne pompe plus de courant (si ya un périph hardware de calcul de polynômes intégré dans le microcontrôleur par exemple).
Publié par skywodd | 15 janvier 2013, 21 h 15 minBonjour,
Est-ce que quelqu’un aurait essayé de décoder les trames du thermostat sans fil Blyss ?
Publié par Clement | 16 janvier 2013, 17 h 32 minJ’ai moi aussi cette erreur
isr_decoding_routine’ was not declared in this scope
Vous préciser avoir pourtant corriger ?
Aussi
Que faut il faire quand vous dites :
Petite correction concernant le spoofer :
inline void set_global_channel(byte *data, byte channel) {
data[1] = (data[1] & 0x0F) | (channel & 0xF0);
}
–> il faut décaler le channel de 4 vers la gauche
Je ne comprends pas
Merci
Publié par Anthony | 30 août 2014, 1 h 29 minQuestion de nouveau, comment arrivez vous à obtenir la clé de votre appareil sous le format :
0x0E, 0xCB, 0xE8
Car le Sniffer fonctionne mais cela n’est pas sous ce format, désolé je ne suis pas très doué.
J’ai lancé le sniffer, lancer le moniteur série et récupérer des infos de ma télécommande Blyss, super mais en passant ensuite au programme spoofer, comment les intégrer et remplacer les votre dans ce format
Merci?
Publié par Anthony | 30 août 2014, 1 h 51 minBonjour, tout d’abord merci pour ce travail énorme! J’essaye de relier ce que vous avez fait avec un raspberry pi (pour utiliser les prises blyss avec Yana Server). Pour les interactions avec les ports GPIO, j’utilise wiringPi. Cependant, après avoir « converti » le code en C, cela ne marche pas… il ne se passe juste rien.
Je compile, j’exécute et la prise ne bouge pas. (J’ai aussi essayé de passer la prise en mode apprentissage pour détecter que l’émetteur est en train de lui parler).
La seule chose que j’ai supprimé purement dans votre code est le « fast powerring tips ». Est-ce nécessaire? (impossible de toucher les pins VCC et GND sur un RPi).
Si par hasard vous avez un peu de temps, je vous met mon code C que vous pouvez consulter ici. Je comprendrai évidemment que vous n’ayez pas le temps pour y jeter un oeil.
https://drive.google.com/file/d/0B_JQSxtwFt-TVG5MLVRuaG01YUE/edit?usp=sharing
Je précise que l’émetteur fonctionne bien en 433Mhz et qu’il est bien alimenté (la led s’allume pendant l’exécution du programme).
Merci encore pour votre travail!
Publié par Dolé | 25 septembre 2014, 12 h 50 minBonjour Dolé,
J’ai porté le code original de skywodd dans une version orienté objet pour Arduino, puis j’ai finalement décidé de (re-)porter le tout compatible raspberry.
Le tout est disponible à cette adresse : https://github.com/pyrou/BlyssController-raspberry
Il n’y a que la partie « spoofer » pour l’instant, ce n’est donc pas un portage complet. Un Arduino munit d’un récepteur reste donc nécessaire pour obtenir la précieuse RF_KEY de ta télécommande dont tu souhaites te passer.
Concernant le montage j’utilise la GPIO 15, (http://wiringpi.com/pins/) ce qui me permet d’utiliser un bon vieux cable audio de lecteur CDRom (https://www.google.fr/images?q=audio+cable+cdrom), que je rebroche comme il faut pour coller avec l’émetteur 433Mhz (utiliser pour cela un épingle pour sortir les boches)
d’un coté du cable pour le raspberry VCC (rouge) / vide / GND (noir) / data (blanc)
de l’autre coté du cable pour l’émetteur GND (noir) / VCC (rouge) / data (blanc) / vide
Je branche ainsi directement le cable sur les pins 2/4/6/8 du raspberry d’un coté et sur l’émetteur de l’autre, c’est un moyen fort élégant de se passer de breadboard. (Attention : certain émetteur ne respecte pas exactement cet ordre, à vérifier donc)
Publié par pyrou | 22 octobre 2014, 12 h 43 minPas mal le portage POO.
Juste un petit truc qui me fait hurler intérieurement : un atoi() ou un strtoul() sur un élément de argv[] c’est demander le bâton pour se faire battre 😉
Lit la doc de ces deux fonctions et essaye de faire la différence entre « 0 » (entier valide) et « abcd » (tous sauf un entier valide).
Pour traiter une entrée utilisateur il faut obligatoirement passer par sscanf() et tester le code de retour pour s’assurer que le parsing de texte a réussi.
Publié par Skywodd | 22 octobre 2014, 12 h 50 minBonjour,
Auriez vous un fritzing du cablage, parce que la je ne comprend pas trop cette partie:
/* Receiver pinmap */
const byte RF_RX_VCC = 11;
const byte RF_RX_SIG = 12; // don’t forget the wire between this pin and D2 !
const byte RF_RX_GND = 10;
surtout le don’t forget the wire…
Merci
Publié par abys | 17 février 2018, 17 h 03 minMAPing du recepteur FOR MEGA 2560
La 2eme broche de l’emetteur est a connecter sur la D2
const byte RF_RX_VCC = 51;
const byte RF_RX_SIG = 50; // don’t forget the wire between this pin and D2 !
const byte RF_RX_GND = 53;
Publié par abys | 18 février 2018, 16 h 44 minc’est pour cloner la telecommande duportail blyss
https://www.castorama.fr/telecommande-blyss-motorisation/3454975828584_CAFR.prd?pid=%7c250050766798&gclid=Cj0KCQiAwp_UBRD7ARIsAMie3XaIx9QU71RYhg2Gs_902EV_MqX500Pk9V5qNiPa23iBwTB-_V5URv4aAibpEALw_wcB
Publié par abys | 17 février 2018, 17 h 08 minet je dispose d’un atmega 2560 ELEGOO
Publié par abys | 17 février 2018, 17 h 16 min