Reverse-engineering d'un code tournant

[l.lem...@gmail.com]

Bonjour

J'ai un portail motorisé, ainsi qu'une porte de garage motorisée.
Elles sont toutes les deux de marques différentes, mais par miracle (ou pas!), les deux acceptent les mêmes télécommandes à "rolling code".

Par malchance, la carte du portail a rendu l'ame, et comme je suis téméraire, plutot que d'en acheter une neuve, je compte la faire moi-meme (a base d'ATMEGA et autres ...)

L'idée serait, bien entendu, de récupérer les mêmes télécommandes, pour ne pas avoir 1 télco pour le portail, et 1 pour le garage !

J'ai commencé à faire du "hack" des trames émises, et j'ai récupéré ca :

1010100100001100011000111100100000110110101010101
1010100100001100011000111100100000000111100111010
1010100100001100011000111100100000111001100010101
1010100100001100011000111100100000011001110111011
1010100100001100011000111100100000100110000010011
1010100100001100011000111100100000110110101000000
1010100100001100011000111100100000000111100011000
1010100100001100011000111100100001101101010100101
1010100100001100011000111100100001110011010011011
1010100100001100011000111100100001001100000010000

49 bits par trame, j'en déduis donc, 7 mots de 7 bits :

54430C3C415A55
54430C3C401E3A
54430C3C416615
54430C3C40673B
54430C3C411813
54430C3C415A40
54430C3C401E18
54430C3C433525
54430C3C434D1B
54430C3C423010

les 4 premiers mots sont probablement l'ID de la télécommande (ce qui se vérifie avec une autre télécommande), mais je suis incapable de déterminer une suite logique pour les 3 derniers mots...

PS : l'émetteur utilise un bête microchip 12C509, mais je n'ai pas essayé de le dumper, je doute qu'il ne soit pas protégé contre la copie !

J'ai toujours à ma dispo les 4 télécommandes, donc je peux "dumper" un max de trames consécutives, pour essayer d'y trouver une suite, mais mes connaissance en cryptologie sont bien trop minces pour réussir à déduire quelquechose !

[jeanyves]

hello,
chercher l'AN714 chez microchip devrait eclaircir le sujet
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en011726


Cordialement,
--

Jean-Yves.

[l.lem...@gmail.com]

Le lundi 12 novembre 2012 17:38:55 UTC+1, jeanyves a écrit :

> On 2012-11-12 17:17:06 +0100, l.....@gmail.com said:
>
>
>
> > Bonjour
>
> >
>

> > J'ai un portail motoris�, ainsi qu'une porte de garage motoris�e.
>
> > Elles sont toutes les deux de marques diff�rentes, mais par miracle (ou
>
> > pas!), les deux acceptent les m�mes t�l�commandes � "rolling code".

>
> >
>
> > Par malchance, la carte du portail a rendu l'ame, et comme je suis
>

> > t�m�raire, plutot que d'en acheter une neuve, je compte la faire

>
> > moi-meme (a base d'ATMEGA et autres ...)
>
> >
>

> > L'id�e serait, bien entendu, de r�cup�rer les m�mes t�l�commandes, pour
>
> > ne pas avoir 1 t�lco pour le portail, et 1 pour le garage !
>
> >
>
> > J'ai commenc� � faire du "hack" des trames �mises, et j'ai r�cup�r� ca :

>
> >
>
> > 1010100100001100011000111100100000110110101010101
>
> > 1010100100001100011000111100100000000111100111010
>
> > 1010100100001100011000111100100000111001100010101
>
> > 1010100100001100011000111100100000011001110111011
>
> > 1010100100001100011000111100100000100110000010011
>
> > 1010100100001100011000111100100000110110101000000
>
> > 1010100100001100011000111100100000000111100011000
>
> > 1010100100001100011000111100100001101101010100101
>
> > 1010100100001100011000111100100001110011010011011
>
> > 1010100100001100011000111100100001001100000010000
>
> >
>

> > 49 bits par trame, j'en d�duis donc, 7 mots de 7 bits :

>
> >
>
> > 54430C3C415A55
>
> > 54430C3C401E3A
>
> > 54430C3C416615
>
> > 54430C3C40673B
>
> > 54430C3C411813
>
> > 54430C3C415A40
>
> > 54430C3C401E18
>
> > 54430C3C433525
>
> > 54430C3C434D1B
>
> > 54430C3C423010
>
> >
>

> > les 4 premiers mots sont probablement l'ID de la t�l�commande (ce qui
>
> > se v�rifie avec une autre t�l�commande), mais je suis incapable de
>
> > d�terminer une suite logique pour les 3 derniers mots...
>
> >
>
> > PS : l'�metteur utilise un b�te microchip 12C509, mais je n'ai pas
>
> > essay� de le dumper, je doute qu'il ne soit pas prot�g� contre la copie
>
> > !
>
> >
>
> > J'ai toujours � ma dispo les 4 t�l�commandes, donc je peux "dumper" un
>
> > max de trames cons�cutives, pour essayer d'y trouver une suite, mais
>
> > mes connaissance en cryptologie sont bien trop minces pour r�ussir �
>
> > d�duire quelquechose !

>
>
>
> hello,
>
> chercher l'AN714 chez microchip devrait eclaircir le sujet
>
> http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en011726
>
>
>
>
>
> Cordialement,
>
> --
>
>
>
> Jean-Yves.

Bonjour et merci pour ta réponse.

Cependant, la doc de l'HCS200 ne m'aide pas beaucoup, mise à part sur la structure d'une trame, que j'avais déjà pu identifier...

Ce qu'il me manque, et qui n'est pas non plus dans la doc du HCS200, c'est comment passe-t-on du compteur incrémenté à la partie "encodée" du rolling-code !

[jeanyves]

On 2012-11-13 14:10:22 +0100, l.lem...@gmail.com said:

>> hello,
>>
>> chercher l'AN714 chez microchip devrait eclaircir le sujet
>>
>> http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en011726>>>>>>
>> Cordialement,
>>
>> --
>>
>>
>>
>> Jean-Yves.
>
> Bonjour et merci pour ta réponse.
>
> Cependant, la doc de l'HCS200 ne m'aide pas beaucoup, mise à part sur
> la structure d'une trame, que j'avais déjà pu identifier...
>
> Ce qu'il me manque, et qui n'est pas non plus dans la doc du HCS200,
> c'est comment passe-t-on du compteur incrémenté à la partie "encodée"
> du rolling-code !

pardon la TB003 est plus locace sur la partie chiffrage du keeloc
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en010992


--

Jean-Yves.

[l.lem...@gmail.com]

Le mardi 13 novembre 2012 15:11:29 UTC+1, jeanyves a écrit :
> On 2012-11-13 14:10:22 +0100, l.lem...@gmail.com said:
>
>
>
> >> hello,
>
> >>
>
> >> chercher l'AN714 chez microchip devrait eclaircir le sujet
>
> >>
>
> >> http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en011726>>>>>>
>
> >> Cordialement,
>
> >>
>
> >> --
>
> >>
>
> >>
>
> >>
>
> >> Jean-Yves.
>
> >
>

> > Bonjour et merci pour ta r�ponse.
>
> >
>
> > Cependant, la doc de l'HCS200 ne m'aide pas beaucoup, mise � part sur
>
> > la structure d'une trame, que j'avais d�j� pu identifier...

>
> >
>
> > Ce qu'il me manque, et qui n'est pas non plus dans la doc du HCS200,
>

> > c'est comment passe-t-on du compteur incr�ment� � la partie "encod�e"

>
> > du rolling-code !
>
>
>
> pardon la TB003 est plus locace sur la partie chiffrage du keeloc
>
> http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en010992
>
>
>
>
>
> --
>
>
>
> Jean-Yves.

Bonjour !

Hier, j'ai eu un flash en cherchant de la doc sur le rolling code et le keeloq : Pour passer d'une trame à l'autre, la télécommande doit stocker, dans une EEPROM par exemple, le compteur "actuel", entre chaque appui sur un bouton.

Hors, la télécommande en question utilise un 12C508, qui n'a pas d'EEPROM.
Ca veut donc dire que si la télécommande veut conserver sa valeur de compteur, le 12C508 doit etre alimenté en permanence, ce qui n'est pas le cas. Cela se vérifie aussi par le fait que lorsque l'on change la pile (le compteur repartirait à zero dans cette hypothèse), il n'est pas nécessaire de refaire une programmation de la télécommande sur le récepteur.

La deuxième hypothèse, qui se vérifierai assez simplement, serait que la partie "tournante" du rolling-code n'a de rolling-code que le nom, et cette partie de la trame serait en fait générée aléatoirement !

[Dominique MICOLLET]

Bonjour,

l.lem...@gmail.com a écrit :

> Hors, la télécommande en question utilise un 12C508, qui n'a pas d'EEPROM.

Il peut toutefois y avoir une EEPROM externe : certaines n'usent que deux ou
trois fils pour stocker et restituer l'information.

Cordialement

Dominique

[l.lem...@gmail.com]

Sur la platine de l'émetteur, il n'y a que le 12C508, quelques petits transistors, quelques résistances, une diode, des BP, et c'est tout !
Pas d'EEPROM en vue !

[harvest]

l.lem...@gmail.com a ecrit

> La deuxième hypothèse, qui se vérifierai assez simplement, serait que la
> partie "tournante" du rolling-code n'a de rolling-code que le nom, et cette
> partie de la trame serait en fait générée aléatoirement !

ce n'est pas du rolling code mais du hopping code
pas besoin de maintenir une position dans l'emetteur
il suffit que n reception pour n emission reponde à l'algo polynomial

[Dominique MICOLLET]

l.lem...@gmail.com a écrit :

> Sur la platine de l'émetteur, il n'y a que le 12C508, quelques petits
> transistors, quelques résistances, une diode, des BP, et c'est tout ! Pas
> d'EEPROM en vue !

Il y a des "One Wire EEPROM" qui ressemblent furieusement à des transistors.
Voir par exemple : http://datasheets.maximintegrated.com/en/ds/DS2430A.pdf

Cordialement

Dominique

[Dominique MICOLLET]

harvest a écrit :

> ce n'est pas du rolling code mais du hopping code

D'après la wikipedia anglaise, c'est la même chose.

> pas besoin de maintenir une position dans l'emetteur
> il suffit que n reception pour n emission reponde à l'algo polynomial

D'après la fiche caractéristique du circuit intégré HCS301, cité par la
wikipedia anglaise, celui ci utilise une clef à 64 bits.

Il me semble qu'il a été établi par les cryptologues professionnels qu'un
système de codage fondé uniquement sur un algorithme ne résistait pas très
longtemps aux attaques.

Cordialement

Dominique.

[harvest]

Dominique MICOLLET a ecrit
> harvest a ï¿œcrit :

>> ce n'est pas du rolling code mais du hopping code

> D'aprï¿œs la wikipedia anglaise, c'est la mï¿œme chose.

sur le tres long terme oui, mais pas sur la predictibilitￜ en temps
proche

le rolling : tu tape sur une profondeur definie pour verifier la clef
suivante fonction de la derniere clef generï¿œe

le hopping : tu tape sur la verification de n (pseudo profondeur)
trames pour verifier l'algo

>> pas besoin de maintenir une position dans l'emetteur

>> il suffit que n reception pour n emission reponde ￜ l'algo polynomial
> D'aprￜs la fiche caractￜristique du circuit intￜgrￜ HCS301, citￜ par la
> wikipedia anglaise, celui ci utilise une clef ￜ 64 bits.
>
> Il me semble qu'il a ￜtￜ ￜtabli par les cryptologues professionnels qu'un
> systￜme de codage fondￜ uniquement sur un algorithme ne rￜsistait pas trￜs
> longtemps aux attaques.

pa grand chose ne resiste aux attaques ciblï¿œes, tout est une question
de temps et de moyens , mais si le temps d'attaque est >> au temps de
vie du systeme ...

les contraintes de protection de l'ouverture d'une porte de voiture ne
sont pas les memes que la protection de certaines transmissions.

un "conducteur lambda" ne comprendrait pas que sa telecommande n'ouvre
pas SA voiture :')
et dans ces cas "d'utilisation grand public" la robustesse du systeme
n'est pas un critere principal ;o)


> Cordialement
pareil

[Dominique MICOLLET]

Rebonjour,

harvest a écrit :
> sur le tres long terme oui, mais pas sur la predictibilité en temps
...

> trames pour verifier l'algo

Là je ne comprends plus :-).

D'ailleurs la lecture de la wikipedia sur le sujet ne m'a guère éclairé.
Je comprends comment est réalisé un encodage, j'ai plus de mal à réaliser ou
le compteur de trame envoyées s'insère dans le codage, je n'ai pas compris
comment le décodeur validait la trame reçue et comment le comptage est pris
en compte.


> pa grand chose ne resiste aux attaques ciblées, t

Je me suis mal exprimé. Je voulais écrire qu'il me semblait qu'il avait été
établi qu'un système de codage fondé uniquement sur un algorithme plus ou
moins secret sans clef est aujourd'hui voué à être cassé par des méthodes
déterministes très rapides, au contraire d'un systèmes fondé sur un
algorithme public dont la clef nécessite un temps très long pour le casser
par force brute, parce qu'on ne connaît pas de méthode déterministe ce
faire.
Ceci écrit, je ne suis pas très versé en cryptologie.

Cordialement

Dominique.

[Dominique MICOLLET]

Rebonjour,

harvest a écrit :
> sur le tres long terme oui, mais pas sur la predictibilité en temps
...

> trames pour verifier l'algo

Là je ne comprends plus :-).

D'ailleurs la lecture de la wikipedia sur le sujet ne m'a guère éclairé.
Je comprends comment est réalisé un encodage, j'ai plus de mal à réaliser ou

le compteur de trames envoyées s'insère dans le codage, je n'ai pas compris
comment le décodeur validait la trame reçue et comment le comptage de trames

est pris en compte.


> pa grand chose ne resiste aux attaques ciblées, t

Je me suis mal exprimé. Je voulais écrire qu'il me semblait qu'il avait été
établi qu'un système de codage fondé uniquement sur un algorithme plus ou
moins secret sans clef est aujourd'hui voué à être cassé par des méthodes

déterministes très rapides, au contraire d'un système fondé sur un

algorithme public dont la clef nécessite un temps très long pour le casser

par force brute, parce qu'on ne connaît pas de méthode déterministe pour ce

[harvest]

Dominique MICOLLET a ecrit

> Lￜ je ne comprends plus :-).
>
> j'ai plus de mal ￜ rￜaliser ou
> le compteur de trames envoyï¿œes s'insï¿œre dans le codage

pour la conception de la trame emise, cette information "compteur de
trames" est inexistante puisque inutile ;o)

[l.lem...@gmail.com]

Bonsoir

En l'occurence, il y a quatre "composants" en boitier SOT23.
J'en ai donc conclu (peut etre hativement) que chacun était un transistor alimentant le PIC lors de l'appui du bouton accouplé à chaque transistor.

J'ai regardé de plus près, et j'ai pu lire "R25" sur l'un (google me confirme un transistor", et C2B4 sur les trois autres: je serai surpris qu'il y ait alors trois EEPROM ;)

[l.lem...@gmail.com]

Le mercredi 14 novembre 2012 15:00:38 UTC+1, harvest a écrit :
> Dominique MICOLLET a ecrit
>
>
>
> > Là je ne comprends plus :-).
>
> >
>
> > j'ai plus de mal à réaliser ou
>
> > le compteur de trames envoyées s'insère dans le codage

>
>
>
> pour la conception de la trame emise, cette information "compteur de
>
> trames" est inexistante puisque inutile ;o)

Là, pour le coup, je suis comme Dominique, je suis perdu ;)
Effectivement, pour moi, il n'y a/avait qu'une seule sorte de Rolling-code : celle qui consiste à:
- prendre un compteur,
- l'incrémenter,
- stocker la nouvelle valeur en EEPROM,
- encrypter cette nouvelle valeur avec une clé de cryptage
- envoyer le tout, avec un ID identifiant l'émetteur.

- Coté récepteur, on décrypte, on regarde si la trame n'a pas déjà été jouée (compteur reçu > compteur stocké ) et on stocke le nouveau compteur si c'est OK.

Si le "hopping code" ne correspond pas à celà, je pense que Dominique et moi-même sommes tout à l'écoute d'une explication en bonne et due forme ;)

[Nicolas Matringe]

Bonsoir

Le 14/11/2012 22:47, l.lem...@gmail.com a écrit :

> Là, pour le coup, je suis comme Dominique, je suis perdu ;)
> Effectivement, pour moi, il n'y a/avait qu'une seule sorte de Rolling-code : celle qui consiste à:
> - prendre un compteur,
> - l'incrémenter,
> - stocker la nouvelle valeur en EEPROM,
> - encrypter cette nouvelle valeur avec une clé de cryptage
> - envoyer le tout, avec un ID identifiant l'émetteur.
>
> - Coté récepteur, on décrypte, on regarde si la trame n'a pas déjà été jouée
> (compteur reçu > compteur stocké ) et on stocke le nouveau compteur
si c'est OK.
>
> Si le "hopping code" ne correspond pas à celà, je pense que Dominique et moi-même sommes
> tout à l'écoute d'une explication en bonne et due forme ;)

J'imagine que le principe du hopping code c'est d'envoyer une séquence
calculée par un algorithme secret (connu uniquement des émetteur et
récepteur). Le récepteur reçoit une première trame, calcule quelle devra
être la suivante d'après l'algo et la trame reçue etc... Quand il a reçu
n trames conformes il accepte l'action.

Nicolas

[nospam @free.fr JP]

D�sol� si je n'ai pas tout suivi / compris mais si on stocke une valeur de
comptage dans la t�l�commande pour �viter de rejouer la partition et �tre
sur que le r�cepteur n'accepte QUE le code suivant .............. comment
cela fonctionne t'il dans le cas de deux ou plusieurs t�l�commandes ?

[Dominique MICOLLET]

Bonjour,

JP a écrit :
> Comment
> cela fonctionne t'il dans le cas de deux ou plusieurs télécommandes ?

On peut spéculer que chaque télécommande a un identificateur unique et que
le récepteur possède une table associant cet identificateur à son compteur
courant.

Cordialement

Dominique

[l.lem...@gmail.com]

C'est effectivement le mode de fonctionnement des ensembles télécommande-récepteur à code tournant :
Chaque emetteur possède son propre ID (stocké en (E)EPROM), et son propre compteur de "code tournant" (lui aussi stocké en EEPROM).
Le récepteur stocke de son coté une table avec l' ID de chaque émetteur autorisé, et pour chaque émetteur , son compteur courant.

Ainsi, à chaque trame reçue, on est capable de dire si l'émetteur fait partie de ceux autorisés, et si son compteur est bien celui attendu: si un pirate capture une trame et la rejoue, ca ne passera pas, puisque le compte envoyé sera inférieur à celui attendu.

Cependant, dans mon système à "soit-disant" code tournant, il n'y a pas, dans l'émetteur, d'EEPROM, et donc bien que chaque émetteur ait son propre ID, il n'y a pas de possibilité de stocker de compteur...

[Dominique MICOLLET]

Bonjour

Merci pour la confirmation de ma spéculation.

l.lem...@gmail.com a écrit :

> Cependant, dans mon système à "soit-disant" code tournant, il n'y a pas,
> dans l'émetteur, d'EEPROM, et donc bien que chaque émetteur ait son propre
> ID, il n'y a pas de possibilité de stocker de compteur...

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 ?

Cordialement

Dominique.

(1) commmunément appelé "bootloader".

[Jean-Christophe]

On 23 nov, 10:56, Dominique MICOLLET

> Est ce que le programme en EPROM du microcontroleur
> serait capable de s'automodifier ???

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.

[l.lem...@gmail.com]

Il me semble que le 12C509 n'est pas EEPROM, mais uniquement EPROM, donc programmable via un programmateur externe, avec la tension de Programmation adéquate.
Pas de technique du "bootloader" possible avec ce chip donc ;)

Au changement de pile, la télécommande est toujours reconnue, sans devoir faire de reprogrammation : Cela exclue donc l'hypothèse que le µC reste alimenté...

La procédure pour faire reconnaitre une nouvelle telecommande est assez simple : appuyer sur le bouton du récepteur, appuyer sur l'émetteur, fini...

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.

[l.lem...@gmail.com]

Je vais tout de même refaire des captures, pour prendre des trames avec un retrait de la pile entre chaque capture...

Voici un extrait des trames capturées :

04.03.71.04.40.36.05
04.03.71.04.40.26.05
04.03.71.04.40.36.51
04.03.71.05.00.06.23
04.03.71.04.40.19.07
04.03.71.04.40.26.01
04.03.71.04.40.36.43
04.03.71.04.40.07.04
04.03.71.04.40.19.06
04.03.71.04.40.26.06
04.03.71.04.40.36.53
04.03.71.04.40.07.04
04.03.71.04.40.19.06
04.03.71.04.40.26.00
04.03.71.04.40.36.47
04.03.71.04.40.07.54
04.03.71.04.40.19.62
04.03.71.04.40.26.00
04.03.71.04.40.36.05
04.03.71.04.40.07.05
04.03.71.04.40.39.05
04.03.71.04.40.19.07
04.03.71.04.40.26.01
04.03.71.04.40.36.44
04.03.71.04.40.07.04
04.03.71.04.40.39.45
04.03.71.04.40.19.73
04.03.71.04.40.36.05
04.03.71.04.40.07.44
04.03.71.04.40.19.62
04.03.71.04.40.26.00
04.03.71.04.40.36.05
04.03.71.04.40.07.46
04.03.71.04.40.19.06
04.03.71.04.40.26.01
04.03.71.04.40.36.05
04.03.71.04.40.07.45
04.03.71.04.40.39.50
04.03.71.04.40.19.66
04.03.71.04.40.26.12
04.03.71.04.40.36.04
04.03.71.04.40.07.05
04.03.71.04.40.39.05
04.03.71.04.40.19.63
04.03.71.04.40.26.00
04.03.71.04.40.36.41
04.03.71.04.40.07.04
04.03.71.04.40.39.05
04.03.71.04.40.19.07
04.03.71.04.40.26.01
04.03.71.04.40.07.49
04.03.71.04.40.39.58
04.03.71.04.40.19.77
04.03.71.04.40.26.14
04.03.71.04.40.36.04
04.03.71.04.40.07.42

On voit quand meme que l'avant dernier octet revient cycliquement : 19, 26, 36, 07, 39.

Par contre, le dernier octet....

[Dominique MICOLLET]

Bonjour,

l.lem...@gmail.com a écrit :

> Par contre, le dernier octet....

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").

Cordialement.

Dominique

[Dominique MICOLLET]

l.lem...@gmail.com a écrit :

> 04.03.71.04.40.26.05
..
> 04.03.71.04.40.07.42

Je me suis amusé à les trier :
il y en a beaucoup qui sont dupliquées.

Sur les 56 fournies, il n'y a en que 34 de différentes.

Il serait intéressant de faire une statistique pour déterminer si elles sont
vraiment aléatoires .......

Cordialement

Dominique.

[l.lem...@gmail.com]

Je ne me souviens pas, de mémoire, si c'est un 12C508 ou 509. Ceci dit, cela importe peu, car la seule différence entre le 508 et 509 est la capacité 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 parallè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 des trames "piles neuves" si on peut les nommer ainsi ;)

La suite demain !!

[Dominique MICOLLET]

l.lem...@gmail.com a écrit :

> Je ne me souviens pas, de mémoire, si c'est un 12C508 ou 509. Ceci dit,
> cela importe peu, car la seule différence entre le 508 et 509 est la
> capacité RAM et ROM. Ni l'un ni l'autre n'ont d'EEPROM, et sont
> programmables uniquement sur un programmateur attitré...

OK.

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 .

>


> J'ai écrit un "programme", qui relié à un récepteur sur mon port
> parallè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 des
> trames "piles neuves" si on peut les nommer ainsi ;)
>
> La suite demain !!

OK.

Cordialement

Dominique.

[laurent]

Le 26/11/2012 15:10, Dominique MICOLLET a écrit :

> Par ailleurs je vois mal comment ce microcontroleur pourrait générer de
> l'aléa

et un timer interne qui compte tant que tu appui sur le bouton?

si c'est pas de l'alea ca, tu as la "gachette" tres rapide lucky luke ;-)

[l.lem...@gmail.com]

C'est effectivement envisageable !!

Je fais les tests ce soir, pour voir ce que donne chaque nouvel allumage !

[Jean-Christophe]

On 26 nov, 13:49, l.lemari... :

> Il me semble que le 12C509 n'est pas
> EEPROM, mais uniquement EPROM

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 ...

[l.lem...@gmail.com]

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 premiers 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 correspondre 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, meme si ca va etre un peu plus fastidieux ! J'ai manqué de temps pour ce faire ce soir !

[l.lem...@gmail.com]

Peut être que tu as raison, mais je n'ai rien compris à ce que tu as dit ;)
Globalement je sais ce qu'est un XOR, un décalage, mais un polynome cyclique, ca dépasse mon vocabulaire ;)

C'est quoi "FSM" ?

[Dominique MICOLLET]

Bonjour,

??? a écrit :

> et un timer interne qui compte tant que tu appui sur le bouton?

C'est le moyen classique pour ce faire.

Il me semble toutefois que la trame est émise continument _pendant_ l'appui
du bouton, ce qui invaliderait cette possibilité.


Cordialement

Dominique.

[l.lem...@gmail.com]

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 compteur qui est conservé tant que la pile est en place : dès lors que l'on retire la pile, le compteur repart de zero.

Dans mon précédent post, j'ai soumis des trames "faussement décodées".

Voici donc le bon décodage, avec des mots de 7 bits :

04.03.71.04.40.3B.73
04.03.71.04.40.2E.2D
04.03.71.04.40.1F.01
04.03.71.04.40.18.48
04.03.71.04.40.3B.57
04.03.71.04.40.15.75
04.03.71.04.40.1E.13
04.03.71.04.40.26.4C
04.03.71.04.40.27.5E

Remarques :
- Le mot comprenant les 4 premiers octets (04.03.71.04) est l'ID de la télécommande : avec une autre télécommande, ce mot est différent.
- Le 5ième octet comprend l'état des boutons: si j'appuie sur d'autres boutons (il y en a 4 en tout), des bits sur cet octet viennent s'ajouter.
- Les deux derniers octets sont la partie tournante. On retrouve bien la même séquence à chaque changement de pile !

[l.lem...@gmail.com]

La même séquence avec seulement les 2 derniers octets, traduits en binaire et en décimal :

3B.73. 01110111110011 7667
2E.2D. 01011100101101 5933
1F.01. 00111110000001 3969
18.48. 00110001001000 3144
3B.57. 01110111010111 7639
15.75. 00101011110101 2805
1E.13. 00111100010011 3859
26.4C. 01001101001100 4940
27.5E. 01001111011110 5086

[Dominique MICOLLET]

Bonjour,

l.lem...@gmail.com a écrit :

>> - Les deux derniers octets sont la partie tournante. On retrouve bien la
>> même séquence à chaque changement de pile !

Cela semble confirmer que le uC est alimenté en permanence par la pile : 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 un bouton et
que ce dernier active aussi l'emetteur (radio ?) uniquement pendant cet
appui.



> 3B.73. 01110111110011 7667
....
> 27.5E. 01001111011110 5086

Il y a donc 16 bits extraits des n bits du générateur pseudo-aléatoire : ce
que j'ai compris du système keeloq est qu'il use de 32 bits, ce qui semble
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 "wc" 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 fournit ou non
la même séquence de démarrage au "reset pile" : j'imagine bien qu'elle
dépende du code d'identification.

Cordialement

Dominique.

[Dominique MICOLLET]

Dominique MICOLLET a écrit :

> Bonjour,
>

....
> Cordialement
>
> Dominique.

J'ai rompu le fil original parce que je ne parvenais plus à poster de
réponse.

Cordialement

Dominique

[laurent]

Le 27/11/2012 08:02, Dominique MICOLLET a écrit :

> C'est le moyen classique pour ce faire.
>
> Il me semble toutefois que la trame est émise continument _pendant_ l'appui
> du bouton, ce qui invaliderait cette possibilité.

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 :-)

[Dominique MICOLLET]

Bonjour,

???? a écrit :

> pas forcement, si on "compte" le temps entre deux appuis.

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 :-).

Je retiens l'idée.

Cordialement

Dominique

[l.lem...@gmail.com]

Je rejoins Dominique : a priori, aucun changement sur les trames si j'attends 10 minutes ou 2 secondes entre deux appuis: la séquence semble rester la même !

[l.lem...@gmail.com]

Je suis arrivé à bien automatiser le programme de décodage, qui fait aussi la mise en forme des trames.

Ce soir, j'essaie de faire une capture de 200 ou 300 appuis consécutifs, avec la même télécommande.
Je vais aussi essayer une autre télécommande remise à zero, voir si la séquence est identique ou non ;)

[laurent]

ce n'etait pas pour faire avancer le schmillliiliblic, c'etait juste une
idee pour faire de l'aleatoire :-)

[laurent]

la premiere idee c'etait juste pour le principe :-)

[laurent]

Le 27/11/2012 14:36, l.lem...@gmail.com a �crit :
> Le mardi 27 novembre 2012 13:06:14 UTC+1, Dominique MICOLLET a �crit :

>
> Je suis arriv� � bien automatiser le programme de d�codage, qui fait aussi la mise en forme des trames.
>
> Ce soir, j'essaie de faire une capture de 200 ou 300 appuis cons�cutifs, avec la m�me t�l�commande.
> Je vais aussi essayer une autre t�l�commande remise � zero, voir si la s�quence est identique ou non ;)

j'ai trouv� ca sur le net:
http://www.emsec.rub.de/media/crypto/attachments/files/2011/03/africacrypt2009_keeloq.pdf

avec l'asm en pic pour le decodage, c'est deja ca.

[l.lem...@gmail.com]

> Par curiosité, j'aimerai bien savoir si chaque télécommande fournit ou non
> la même séquence de démarrage au "reset pile" : j'imagine bien qu'elle
> dépende du code d'identification.

Effectivement, la séquence est différente sur deux télécommandes !
On peut donc déduire que l'ID télécommande doit entrer en jeu pour l'obtention du code.

J'ai extrait 89 trames d'une même télécommande hier, et sur ces 79 trames, seules 70 trames uniques. Parfois, la même trame peut revenir après 5 appuis.

J'ai donc fortement envie de déduire qu'il s'agit d'un hash (ou un cryptage irréversible), et que le récepteur ne décode pas la trame reçue, mais "construit" une trame attendue et compare cette "trame attendue" avec la trame reçue (un peu comme les mots de passe hashés en MD5 : lorsque l'utilisateur saisis son mot de passe, on le hash en MD5 et on le compare à celui stocké) !

[Dominique MICOLLET]

Bonjour,

l.lem...@gmail.com a écrit :

> On peut donc déduire que l'ID télécommande doit entrer en jeu pour
> l'obtention du code.

Elle peut tout simplement servir d'initialisation du générateur aléatoire,
ou être "xorée" avec la sortie d'un générateur commun à toutes les
télécommandes.

>
> J'ai extrait 89 trames d'une même télécommande hier, et sur ces 79 trames,
> seules 70 trames uniques. Parfois, la même trame peut revenir après 5
> appuis.

Seulement 89 ? Y a pas un bambin dans le coin qui serait ravi de pouvoir
s'amuser avec la télécommande ? :-)

>
> J'ai donc fortement envie de déduire qu'il s'agit d'un hash (ou un

..
> à celui stocké) !

C'est une possibilité.

L'autre possibilité que j'entrevois est un LFSR à nombre de bits >> 16 et
dont seul 16 bits sont utilisés : dans ce cas, la réapparition rapide d'un
code sur 16 bit n'est pas improbable.

Y a plus qu'à mettre en place un appui automatique du bouton pour récuperer
un très grand nombre de trames et voir si le code du générateur peut être
cassé.

Cordialement

Dominique.

[l.lem...@gmail.com]

> > J'ai extrait 89 trames d'une même télécommande hier, et sur ces 79 trames,
>
> > seules 70 trames uniques. Parfois, la même trame peut revenir après 5
>
> > appuis.
>
>
>
> Seulement 89 ? Y a pas un bambin dans le coin qui serait ravi de pouvoir
>
> s'amuser avec la télécommande ? :-)

Le souci, c'est que l'extraction n'est pas encore completement automatisée : il faut que je passe par un soft pour enregistrer les trames, et une ligne de commande pour les décoder.
Et le premier soft , lorsqu'il emmagazine trop d'informations, devient moins précis sur les trames enregistrées, et elles ne sont plus décodables.
Il me faudrait 1 ou 2 heures pour pondre un petit programme en C pour enregistrer tout ca de façon automatique, mais Madame m'a donné d'autres priorités pour l'instant ;)