Skyduino:~#
Articles
arduino, Autre, Corrigé, programmation, projet, python

[Hack - partie 2] Reverse engineering des interrupteurs domotique Blyss

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 0×00.
Juste après se trouve un octet de valeur 0×00 ou 0xFF indiquant l’état actuel de l’interrupteur (0×0 -> éteint, 0xFF -> allumé).
A cela s’ajoute une sorte "d’empreinte" invariable : 0×55 0×80 servant à déterminer l’état de l’EEPROM (vierge sortie d’usine, …)
L’octet 0×80 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 ! :)

About these ads

Discussion

32 réflexions sur “[Hack - partie 2] Reverse engineering des interrupteurs domotique Blyss

  1. Excellent hack !

    Publié par CasoTronics | 19 juillet 2012, 17 h 45 min
  2. J’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 min
  3. excellent 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 min
  4. J’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 min
  5. Hey 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 min
  6. bonjour 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 min
    • Ce 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 min
      • Merci 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[] = {0×79, 0x5F, 0×78}; dans le code car j’utilise plusieurs télécommande …

        Note : j’ai tenté :

        RF_KEY[0]= 0×79;
        RF_KEY[1]= 0x5F;
        RF_KEY[2]= 0×78;

        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 min
  7. Edit : La seconde question porte sur la partie spoofer bien-sur :)

    Publié par TchaoPaulo | 10 octobre 2012, 13 h 28 min
    • Merci 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 min
  8. oui les même :S

    Publié par TchaoPaulo | 10 octobre 2012, 20 h 11 min
    • Ajoute #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 min
  9. Super 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 min
  10. Hello,

    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 min
  11. Salut, 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 min
  12. Bonjour,

    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 min

Rétroliens/Pings

  1. Pingback: » Sniffer 433mhz - analyseur logique - 21 novembre 2012

  2. Pingback: Domotiqe Protocole | Pearltrees - 7 février 2013

  3. Pingback: Best | Pearltrees - 27 février 2014

  4. Pingback: Raspberry-Arduino | Pearltrees - 22 mars 2014

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

Archives

Wow. Dogecoin. Amaze.

Laissez un tip en Dogecoin

DMMNFk6WBVTpx2Wu1Z35GL61QXSd6r6WQx

Suivre

Recevez les nouvelles publications par mail.

Rejoignez 715 autres abonnés