Reverse-engineering d'un code tournant - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From French to

Threaded View
Re: Reverse-engineering d'un code tournant
On 23 nov, 10:56, Dominique MICOLLET

Quoted text here. Click to load it

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.

Re: Reverse-engineering d'un code tournant
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 :
Quoted text here. Click to load it


Re: Reverse-engineering d'un code tournant
Le lundi 26 novembre 2012 13:49:12 UTC+1, snipped-for-privacy@gmail.com a écrit :
Quoted text here. Click to load it
programmable via un programmateur externe, avec la tension de Programmation
 adéquate.  
Quoted text here. Click to load it
voir faire de reprogrammation : Cela exclue donc l'hypothèse que le µC  
reste alimenté...
Quoted text here. Click to load it
 simple : appuyer sur le bouton du récepteur, appuyer sur l'émetteur, f
ini...
Quoted text here. Click to load it
écutives, c'est a dire : appui sur le bouton 1/2 seconde, relachement, ap
pui 1/2 secondes, relachement, etc...
Quoted text here. Click to load it
es 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.
Quoted text here. Click to load it
:
Quoted text here. Click to load it

Je vais tout de même refaire des captures, pour prendre des trames avec u
n 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....

Re: Reverse-engineering d'un code tournant
Bonjour,

snipped-for-privacy@gmail.com a écrit :
Quoted text here. Click to load it

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

Re: Reverse-engineering d'un code tournant
Le 26/11/2012 15:10, Dominique MICOLLET a écrit :

Quoted text here. Click to load it

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


Re: Reverse-engineering d'un code tournant
Bonjour,  

??? a écrit :
Quoted text here. Click to load it

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.



Re: Reverse-engineering d'un code tournant
Le mardi 27 novembre 2012 08:02:24 UTC+1, Dominique MICOLLET a écrit :
Quoted text here. Click to load it
ppui  
Quoted text here. Click to load it

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 :

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 !

Re: Reverse-engineering d'un code tournant
Le mardi 27 novembre 2012 08:53:31 UTC+1, snipped-for-privacy@gmail.com a écrit :
Quoted text here. Click to load it
:
Quoted text here. Click to load it
'appui  
Quoted text here. Click to load it
ompteur qui est conservé tant que la pile est en place : dès lors que l
'on retire la pile, le compteur repart de zero.
Quoted text here. Click to load it
ées".
Quoted text here. Click to load it
élécommande : avec une autre télécommande, ce mot est différent.
Quoted text here. Click to load it
s boutons (il y en a 4 en tout), des bits sur cet octet viennent s'ajouter.
Quoted text here. Click to load it
même séquence à chaque changement de pile !

La même séquence avec seulement les 2 derniers octets, traduits en bina
ire 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

Re: Reverse-engineering d'un code tournant
Le 27/11/2012 08:02, Dominique MICOLLET a écrit :

Quoted text here. Click to load it

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

Re: Reverse-engineering d'un code tournant
Bonjour,

???? a écrit :
Quoted text here. Click to load it

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



Re: Reverse-engineering d'un code tournant
Le 27/11/2012 14:33, Dominique MICOLLET a écrit :
Quoted text here. Click to load it

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


Re: Reverse-engineering d'un code tournant
Le mardi 27 novembre 2012 14:12:08 UTC+1, laurent a écrit :
Quoted text here. Click to load it
'appui
a  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it

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


Re: Reverse-engineering d'un code tournant
Le 27/11/2012 14:35, snipped-for-privacy@gmail.com a écrit :
Quoted text here. Click to load it
10 minutes ou 2 secondes entre deux appuis: la séquence semble rester la même !
Quoted text here. Click to load it

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


Re: Reverse-engineering d'un code tournant
snipped-for-privacy@gmail.com a écrit :

Quoted text here. Click to load it
..

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.

Re: Reverse-engineering d'un code tournant
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 :
Quoted text here. Click to load it
es sont  
Quoted text here. Click to load it


Re: Reverse-engineering d'un code tournant
snipped-for-privacy@gmail.com a écrit :

Quoted text here. Click to load it


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 .

Quoted text here. Click to load it

  
Quoted text here. Click to load it

OK.

Cordialement

Dominique.

Re: Reverse-engineering d'un code tournant
Le lundi 26 novembre 2012 15:45:23 UTC+1, Dominique MICOLLET a écrit :
Quoted text here. Click to load it
t,
transistors  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
iller  
Quoted text here. Click to load it
i pour  
Quoted text here. Click to load it
.
t
user à
Quoted text here. Click to load it
s

C'est effectivement envisageable !!

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

Re: Reverse-engineering d'un code tournant
Le lundi 26 novembre 2012 17:16:47 UTC+1, snipped-for-privacy@gmail.com a écrit :
Quoted text here. Click to load it
:
Quoted text here. Click to load it
dit,
a
e transistors  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
itiller  
Quoted text here. Click to load it
qui pour  
Quoted text here. Click to load it
s .
ort
amuser à
Quoted text here. Click to load it
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 !

Re: Reverse-engineering d'un code tournant
On 26 nov, 13:49, l.lemari... :

Quoted text here. Click to load it

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

Re: Reverse-engineering d'un code tournant
Le lundi 26 novembre 2012 17:43:02 UTC+1, Jean-Christophe a écrit :
Quoted text here. Click to load it

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

C'est quoi "FSM" ?

Site Timeline