Juste une idée totalement farfelue... Est ce que le programme en EPROM du microcontroleur serait capable de s'automodifier ??? Beaucoup de microcontroleurs peuvent désormais être programmés via USB au travers d'un chargeur (1) spécifique : on pourrait imaginer que les fonctionnalités de ce chargeur soient détournées pour écrire la valeur du compteur dans la zone mémoire du code.
Incidemment :
- quelle est la procédure qui permet de reconnaître initialement une télécommande ?
- en cas de changement de pile, est ce que les mêmes trames sont rejouées ?
Sur un PIC qui tourne on peut écrire à la volée dans la FLASH qui stocké le programme et utiliser cette zone mémoire comme on le ferait avec de l'EEPROM. Je ne sais pas si le tien le permet, mais ca marche bien. Il suffit d'écrire les fonctions de R/W puis de les appeler.
Et au sujet du sujet de ce thread ... le reverse engineering partirait des séquences Tx/Rx ou d'un dump du code ASM du PIC pour remonter aux équations du générateur sous-jacent.
Il me semble que le 12C509 n'est pas EEPROM, mais uniquement EPROM, donc pr ogrammable via un programmateur externe, avec la tension de Programmation a déquate. Pas de technique du "bootloader" possible avec ce chip donc ;)
Au changement de pile, la télécommande est toujours reconnue, sans devo ir faire de reprogrammation : Cela exclue donc l'hypothèse que le µC re ste alimenté...
La procédure pour faire reconnaitre une nouvelle telecommande est assez s imple : appuyer sur le bouton du récepteur, appuyer sur l'émetteur, fin i...
J'ai à ma disposition une centaines de trames capturées, toutes consé cutives, c'est a dire : appui sur le bouton 1/2 seconde, relachement, appui 1/2 secondes, relachement, etc...
J'ai d'ailleurs pu remarquer qu'en appuyant pendant par exemple 20 secondes sur le bouton, la même trame est jouée pendant ces 20 secondes, pas de "nouvelles" trames durant le même maintient d'un bouton.
Le vendredi 23 novembre 2012 22:23:07 UTC+1, Jean-Christophe a écrit :
Ce qu'il me semble vraiment important de vérifier est si les trames sont identiques après une coupure de pile, pour déterminer si le uC (quelle est d'ailleurs sa référence exacte ? parce que vos articles donnent soit 508 soit 509) repart du même état. Par ailleurs je vois mal comment ce microcontroleur pourrait générer de l'aléa (sauf à imaginer qu'il numérise une entrée analogique "en l'air").
Je ne me souviens pas, de mémoire, si c'est un 12C508 ou 509. Ceci dit, c ela importe peu, car la seule différence entre le 508 et 509 est la capac ité RAM et ROM. Ni l'un ni l'autre n'ont d'EEPROM, et sont programmables uniquement sur un programmateur attitré...
J'ai écrit un "programme", qui relié à un récepteur sur mon port pa rallèle, est capable de lire les trames reçues, je vais donc m'amuser à faire 1 heure de lecture de trames, pour les statistiques, ainsi que de s trames "piles neuves" si on peut les nommer ainsi ;)
La suite demain !!
Le lundi 26 novembre 2012 15:19:05 UTC+1, Dominique MICOLLET a écrit :
Dans une des réponses précédentes vous évoquiez la présence de transistors sur les boutons "servant à alimenter le uC".
Serait-il possible d'envisager que le uC soit alimenté en permanence, basculé en mode stand-by et que les transistors aient pour effet de titiller une broche pour réveiller le uC, ou simplement alimenter l'emetteur ?
La consommation en mode standby est donnée inférieure à 1 uA, ce qui pour une pile AAA (capacité = 400 mAh) donne une durée de vie de 45 ans .
Peut-être que ce code est géré par des polynômes cycliques ( trés faciles à implémenter avec des décalages et des XOR ) Connaissant le polynôme générateur, ainsi que les rangs des bits rebouclés en XOR, d'après la trame recue on recalcule une clé puis on vérifie si elle correspond à ce qui est attendu.
L'opération inverse (retrouver d'après les trames le polynôme générateur ET les rangs des bits rebouclés) est en général bien plus difficile à implémenter, mais je sais que c'est possible (d'après mon souvenir d'un ancien article paru dans Dr.Dobbs)
Peut-être que cela vaut un post sur fsm, où sévissent quelques redoutables théoriciens ...
Le lundi 26 novembre 2012 17:16:47 UTC+1, snipped-for-privacy@gmail.com a écrit :
:
dit,
a
e transistors
itiller
qui pour
s .
ort
amuser à
des
!
Alors j'ai tenté plusieurs captures : Principalement, je me suis acharn é sur "j'enleve la pile, j'appuie plein de fois, et je regarde ce que ca donne"...
ET ca donne ca :
0000100000001111100010000100100000001110111110011 : 04.03.71.04.40.03.73 x
3
0000100000001111100010000100100000001011100101101 : 04.03.71.04.40.02.02 x
3
0000100000001111100010000100100000000111110000001 : 04.03.71.04.40.01.01 x
4
0000100000001111100010000100100000000110001001000 : 04.03.71.04.40.18.48 x
4
0000100000001111100010000100100000001110111010111 : 04.03.71.04.40.03.57 x
4
0000100000001111100010000100100000000101011110101 : 04.03.71.04.40.15.75 x
4
0000100000001111100010000100100000000111100010011 : 04.03.71.04.40.01.13 x
4
0000100000001111100010000100100000001001101001100 : 04.03.71.04.40.26.04 x
4
0000100000001111100010000100100000001001111011110 : 04.03.71.04.40.27.05 x
4
0000100000001111100010000100100000001110011000011 : 04.03.71.04.40.39.43 x
4
A chaque fois que j'enleve la pile et que je remets la pile, les 10 premier s appuis sont CEUX CI DESSUS ! Donc, c'est effectivement reproductible ! Ce que je peux en déduire, c'est que ces 10 premieres trames doivent corr espondre au compteur de 0 à 10, donc il doit etre déjà plus facile de retrouver la "clé de cryptage" !?
Maintenant que je sais que le compteur est remis à zero au retrait de la pile, il me reste à faire un enregistrement de 0 à 200 par exemple, mem e si ca va etre un peu plus fastidieux ! J'ai manqué de temps pour ce fai re ce soir !
Le lundi 26 novembre 2012 17:43:02 UTC+1, Jean-Christophe a écrit :
Peut être que tu as raison, mais je n'ai rien compris à ce que tu as di t ;) Globalement je sais ce qu'est un XOR, un décalage, mais un polynome cycli que, ca dépasse mon vocabulaire ;)
Le mardi 27 novembre 2012 08:02:24 UTC+1, Dominique MICOLLET a écrit :
ppui
Effectivement, un appui maintenu envoi toujours la même trame.
De plus, mes essais d'hier soir ont mis en évidence que c'est bien un com pteur qui est conservé tant que la pile est en place : dès lors que l'o n retire la pile, le compteur repart de zero.
Dans mon précédent post, j'ai soumis des trames "faussement décodée s".
Voici donc le bon décodage, avec des mots de 7 bits :
Cela semble confirmer que le uC est alimenté en permanence par la pil e : je parie un chocolat chaud qu'il est endormi à la fin d'une émission de trames pour économiser l'énergie, qu'il est réveillé par l'appui sur u n bouton et que ce dernier active aussi l'emetteur (radio ?) uniquement pendant cet appui.
....
Il y a donc 16 bits extraits des n bits du générateur pseudo-aléa toire : ce que j'ai compris du système keeloq est qu'il use de 32 bits, ce qui s emble l'écarter. Pour déterminer n, il faut plus de trames afin de détecter la rép étition du cycle. Toutefois la statistique réalisée à coup de "sort", "uniq" et "w c" sur la séquence postée hier permet de faire l'hypothèse que ce cycle est court. Ceci écrit, ça ne garantit pas qu'on puisse retrouver le codage.
Par curiosité, j'aimerai bien savoir si chaque télécommande fourn it ou non la même séquence de démarrage au "reset pile" : j'imagine bien qu 'elle dépende du code d'identification.
pas forcement, si on "compte" le temps entre deux appuis. ca implique de laisser le µC sous tension et vu les conso en IDLE, ca va tenir pas mal de temps. pendant qu'aucuns boutons n'est appuyé, un reveil toutes les 0,001s et la mise a jour d'un compteur qui doit durer pas plus de quelques µs, ca va pas tuer la pile en 2 minutes :-)
Ahhhh mais là ça change tout..... Ça c'est un timer qui compte pendant qu'on _n'_ appuie _pas_ sur le bouton. C'est totalement différent de la proposition initiale :-).
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.