Reverse-engineering d'un code tournant

hello, chercher l'AN714 chez microchip devrait eclaircir le sujet

Cordialement,

?e.

acle (ou

es ? "rolling code".

la faire

?mes t?l?commandes, pour

es, et j'ai r?cup?r? ca :

mmande (ce qui

e suis incapable de

je n'ai pas

? contre la copie

onc je peux "dumper" un

mais

sir ?

=1824&appnote=en011726

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

rt sur

r...

=1824&appnote=en010992

Bonjour !

Hier, j'ai eu un flash en cherchant de la doc sur le rolling code et le kee loq : 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'EEPR OM. Ca veut donc dire que si la télécommande veut conserver sa valeur de co mpteur, le 12C508 doit etre alimenté en permanence, ce qui n'est pas le c as. 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éce ssaire de refaire une programmation de la télécommande sur le récepte ur.

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 c ette partie de la trame serait en fait générée aléatoirement !

Bonjour,

snipped-for-privacy@gmail.com a écrit :

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

Cordialement

Dominique

Le mercredi 14 novembre 2012 09:38:17 UTC+1, Dominique MICOLLET a écrit  :

EEPROM.

ou

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

snipped-for-privacy@gmail.com a ecrit

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

snipped-for-privacy@gmail.com a écrit :

Il y a des "One Wire EEPROM" qui ressemblent furieusement à des transistors. Voir par exemple :

Cordialement

Dominique

harvest a écrit :

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

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.

Dominique MICOLLET a ecrit

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

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)

pareil

Rebonjour,

harvest a écrit :

...

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.

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.

Rebonjour,

harvest a écrit :

...

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.

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 faire. Ceci écrit, je ne suis pas très versé en cryptologie.

Cordialement

Dominique.

Dominique MICOLLET a ecrit

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

Le mercredi 14 novembre 2012 13:38:37 UTC+1, Dominique MICOLLET a écrit  :

Pas

tors.

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

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

Le mercredi 14 novembre 2012 15:00:38 UTC+1, harvest 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 e t moi-même sommes tout à l'écoute d'une explication en bonne et due f orme ;)

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 ?

Bonsoir

Le 14/11/2012 22:47, snipped-for-privacy@gmail.com a écrit :

celle qui consiste à:

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

Bonjour,

JP a écrit :

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

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

Ainsi, à chaque trame reçue, on est capable de dire si l'émetteur fai t 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 co mpte 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 p ropre ID, il n'y a pas de possibilité de stocker de compteur...

Le lundi 19 novembre 2012 10:22:42 UTC+1, Dominique MICOLLET a écrit :

et que

ompteur