1.comment Utiliser Un Unlooper

Voir le sujet précédent Voir le sujet suivant Aller en bas

1.comment Utiliser Un Unlooper

Message  KIFFANSAT le Lun 9 Fév - 0:42

A première vue, l'unlooper vendu par Electronica Suiza est un KT mais je ne sais pas 'il porte les modifs nécessaires. .

1.- A quoi ça sert ?

A la base, ce que fait un unlooper c'est provoquer des dysfonctionnements du processeur de la carte pendant l'exécution d'une certaine instruction. Celle-ci nous renvoie alors quelques octets intéressants pour le but de nos recherches.

Cela est possible en modifiant l'entrée du courant (Glitch sur VCC) ou le signal d'horloge de la carte (Glitch d'horloge).

Les Glitches de tension et d'horloge peuvent être utilisés sur certains processeurs dans le but d'affecter le processus de cryptage de certaines données et l'exécution d'instructions individuelles. Chaque Glitch, ses trajectoires de connexion agissent comme un élément de RC avec son temps de latence propre. La fréquence max permise pour un processeur est déterminées par le retard max permis entre ses élements. Chaque flip-flop a un laps de temps propre (quelques picosecondes).

Ce laps de temps peut se situer à n'importe quel moment du cycle spécifique du flip-flop mais il est FIXE pour un dispositif individuel avec une tension et une température donnée.

2.- De quoi avons-nous besoin ?

Dans un premier temps, nous avons besoin du fichier à programmer dans l'ATMEL et qui permettra de faire les différentes tentatives de Glitches via l'unlooper.

Il y a plusieurs types de fichiers en fonction de la carte visée(WT2,WTX,UL4S,SU_2...). Ce dernier (SU_2) avec une modif mineure est celui que nous allons utiliser. Il s'agit de celui de HomeAlone (HA) utilisé sur la V4.1.

Nous avons aussi besoin du logiciel Winexplorer 4.6 ou supérieur et le scrïpt qui va avec (en *.xvb). Il y a aussi plusieurs types de scrïpts en fonction de ce qu'on veut dumper. Certains sont publics d'autres pas naturellement. Dans notre cas, nous utiliserons celui de HA.

Nous avons aussi besoin de la liste des commandes du SU_2 afin de savoir comment agit chacune d'entre elles dans le scrïpt et pouvoir le modifier à volonté en fonction de ce que l'on veut avoir. Il est important de connaître ces commandes.

3.- Comment programmer l'AT2313 ou supérieur ?

Il existe plusieurs manières de programmer un Atmel 2313 :

La première est via l'unlooper en in situ. Pour cela, nous avons besoin d'un loader çàd un exe dans lequel sera implémenté la Flash et l'EEPROM interne que l'on va programmer.

La deuxième est avec un programmatteur de type Apollo3 qui a le support nécessaire (vous pouvez vous en faire un assez facilement avec un ancien port LPT comme le préconise le site h**p://col2000.free.fr/avr/avr_indx.htm) et FBPROG 16 où l'on chargera la flash et l'eep_int pour les programmer.

Dans le cas du SU_2 modifié par HA nous n'avons pas le loader. Il faut donc le programmer avec un programmateur de type Apollo3 ou assimilé.

FBPROG 16 est dispo sur DssTrade (h**p://www.dsstrade.com/files.html)

Il y en a d'autres cités ds ce même post.

5.- Comment paramétrer WinExplorer?

Lancer le logiciel et allez à ---> Configuration et ---> Parameters :

Comm #### .-Com1
Data baud .-115200 (si vous le changer il n'y aura pas de com) avec l'unlooper)
Reset baud.-115200
Parity .-None
Rec timeout.-400
Byte Delay.-0
Reset Dela.-0
Stop Bits .-1
Byte de conversion.-Directe

Toutes autres options ne doivent pas être cochées.

Allez dans "Save" et enregistrez la config sous le nom que vous désirez.

Ensuite chargez le fichier *xvb comme tout autre scrïpt Winexplorer comme ceux de h_m.

6.- Que pouvons-nous obtenir ?

Trouver le Glitch correcte signifie avoir compris une partie du fonctionnement de la carte off. Tous les signaux envoyés doivent arriver exactement au même moment après le reset pour chaque test. Il est possible de tester plusieurs Glitches pour chaque cycle d'horloge jusqu'à ce que l'on ai des octets additionnels. Si vous répétez le processus, cela entraînera une décharge de la mémoire restantes qui si nous n'avons pas de peau peut être la clef que nous cherchons.

Autres considérations :

A) L'intervalle de DACs dans lequel un Glitch sur Vcc pourrait entraîner un dysfonctionnement du processeur dépen de l'état de celui-ci. Par exemple, quelques cycles après le reset, çàd lorsque la carte a une consommation d'énergie élevée, les DAC's entre 130 et 180 (en décimal) peuvent provoquer des effets. Par contre, lorsque la conso° de la carte se stabilise dans des valeurs faibles, à partir d'un cycle Atmel de 1000, il est nécessaire de baisser le DAC (jusqu'à 30 ou 40) pour provoquer un dysfonctionnement même si dans ce cas de figure, la marge de maneouvre est faible parce que la carte fit un reset automatique.

b) Le PSW (Program Status Word) est un registre utilisé dans les processeurs basés sur l'architecture 8051 (celle des v4.1 t v6.0). Dans ce programme, sont stockés certains flags comme le CARRY BIT, le Program Counter, etc... Il y a aussi le PWM (Pulse Width Modulator) mais çà c'est autre chose.

c) Tous les firmwares dispo pour les unlopper snt développés pour les cartes DSS Direct TV. Dans ce système, (comme celui du Nagra Numérique) on utilise la convention inverse pour les com° CAM/CARTE. Cela veut dire que les bits sont envoyés en ordre inverse (du plus significatif au moins significatif) et avec ue logique inversée (çàd un 1 est envoyé avec la ligne i/o bas et viceversa). Donc, l'Atmel interprète les octets que lui envoie la carte comme s'ils étaient envoyés dans cette convention (c la même chose pour la transmission). Le système SECA utilise une convention directe et il est donc nécessaire de "traduire" les octes de convention inverse à directe. Telle est la fonction de HexInv(N,L) dans les différents scrïpts : convertir l'entero N (reçu en convention inverse) en héxadécimal traduit en convention directe avec longueur L.

d) Le quartz contrôle aussi bien le CLK dans la communication Atmel<->card que la communication PC <->Atmel. Dans le premier cas, il est hardcodé dans le firmware et en principe, il n'est pas nécessaire de modifier quoi que ce soit car les routines d'attente se basent sur le comptage de cycles et cela ne dépend pas de la fréquence CLK utilisée. Par contre, la com° PC <->Atmel utilise l'UART intégrée dans l'ATMEL, ce qui nécessite la modif de certains paramètres dans le firmware (en le recompilant notamment) pour que celui-ci fonctionne correctement.

Les microprocesseurs de la gamme Infineon sle44/66/88 disposent d'un mode de reset spécial (la ligne i/o renvoie un "high" après 400ms) qui fait entrer la carte dans un loop de commandes si l'on envoie une clef prédéterminée (mask key <> IK). Dans le cas contraire, on a le MId (Manufacturer Id), qui réside dans les premières positions de l'EEPROM. Cela est connu depuis plusieurs années h**p://www.fitug.de/debate/9912/msg00010.html), et est a été problablement HA pour le dump de la ROM 2.0, 3.0 et 4.1Siemens et pas OKI (La 6.0 est un peu spéciale).

Le paquet "09100e09012010008F00" dans une v4.1 renvoie :

MId: 33 12 09 31 FF 22 24 DA 61 19 2C 0E 05 2E 09 03

dans une v6.0 :

MId: 33 FF EB 31 19 08 10 C3 68 01 24 08 01 10 10

Malheureusement, dans une v7, on a un ATR standard !

KIFFANSAT
Admin

Messages : 100
Date d'inscription : 01/10/2008

Voir le profil de l'utilisateur http://kiffan.bbactif.com

Revenir en haut Aller en bas

Re: 1.comment Utiliser Un Unlooper

Message  KIFFANSAT le Lun 9 Fév - 0:43

Bon, je voudrais revenir sur certains éléments que j'ai pu glaner ici ou là sur HSA et notamment des éléments filés par le très bon DANTEC. Encore une fois, les essais sont basés sur l'unlooper KT modifié présenté dans ce forum-même mais les principes restent les mêmes.

Commençons.

Donc, comme on a pu le voir, il y a deux techniques : clock glitch et voltage glitch.

En ce qui concerne le glitch d'horloge, il faut savoir que les nouvelles puces embarquées dans les v7.x et la ROM110 Nagra 2 intégrent des routines de temps aléatoires. Qu'est-ce que çà veut dire ? Ben que la routine d'envoi vers le démo (SendToIRD) appelle une routine qui s'éxécute en un temps aléatoire, et ce, pour éviter l'utilisation de dispositifs d'intrusion de type unlooper et qui se synchronisent pour pointer à un moment spécifique de l'éxécution d'une ins. Etant donné que le temps est variable dans les nouveaux proce', ce genre de dispositifs ne sont plus efficaces. Mais ne désespérez pas, il est possible d'arriver à nos fins et tout est question de persévérance car il suffit juste d'intégrer ce concept de traitement aléatoire.

Regardez ce qui suit :


Citation:
SC Unlooper v1.2 Rev 0
TX Data : 07 6D 01 6E 07 6F BF 00 [ 219ms ]
RX Data : 86 # Octets traités par l'UNLOOPER ( 06 )
RX Data : 1B # Octets reçus de la carte
RX Data : F8 FF 95 00 FF 91 81 71 FE 47 00 44 4E 41 53 50
31 31 30 20 52 65 76 41 30 31 14 [ 0ms ]
RX Data : 01 00 E8 [ 0ms ] Valeur du compteur de cycles
TX Data : 07 6D 01 6E 07 6F BF 00 [ 220ms ]
RX Data : 86 # Octets traités par l'UNLOOPER( 06 )
RX Data : 1B # Octets reçus de la carte
RX Data : F8 FF 95 00 FF 91 81 71 FE 47 00 44 4E 41 53 50
31 31 30 20 52 65 76 41 30 31 14 [ 0ms ]
RX Data : 01 00 6A [ 0ms ] Valeur du compteur de cycles
TX Data : 07 6D 01 6E 07 6F BF 00 [ 225ms ]
RX Data : 86 # Octets traités par l'UNLOOPER ( 06 )
RX Data : 1B # Octets reçus de la carte
RX Data : F8 FF 95 00 FF 91 81 71 FE 47 00 44 4E 41 53 50
31 31 30 20 52 65 76 41 30 31 14 [ 0ms ]
RX Data : 01 00 7F [ 0ms ] Valeur du compteur de cycles
TX Data : 07 6D 01 6E 07 6F BF 00 [ 219ms ]
RX Data : 86 # Octets traités par l'UNLOOPER ( 06 )
RX Data : 1B # Octets reçus de la carte
RX Data : F8 FF 95 00 FF 91 81 71 FE 47 00 44 4E 41 53 50
31 31 30 20 52 65 76 41 30 31 14 [ 0ms ]
RX Data : 01 00 82 [ 0ms ] Valeur du compteur de cycles



Comme vous pouvez le voir, les temps d'envoi du premier octet de l'ATR (octet 3F) est différent, donc inutile de chercher la synchro.

Maintenant les temps totaux d'envoi de l'ATR :


Citation:
SC Unlooper v1.2 Rev 0
TX Data : 06 6D 01 6E 9A 6F 00 [ 210ms ]
RX Data : 86 # Octets traités par l'UNLOOPER ( 06 )
RX Data : 1B # Octets reçus de la carte
RX Data : 3F FF 95 00 FF 91 81 71 FE 47 00 44 4E 41 53 50
31 31 30 20 52 65 76 41 30 31 14 [ 0ms ]
RX Data : 20 00 64 [ 0ms ] Valeur du compteur de cycles
TX Data : 06 6D 01 6E 9A 6F 00 [ 209ms ]
RX Data : 86 # Octets traités par l'UNLOOPER ( 06 )
RX Data : 1B # Octets reçus de la carte
RX Data : 3F FF 95 00 FF 91 81 71 FE 47 00 44 4E 41 53 50
31 31 30 20 52 65 76 41 30 31 14 [ 0ms ]
RX Data : 1F 00 FA [ 0ms ] Valeur du compteur de cycles
TX Data : 06 6D 01 6E 9A 6F 00 [ 207ms ]
RX Data : 86 # Octets traités par l'UNLOOPER ( 06 )
RX Data : 1B # Octets reçus de la carte
RX Data : 3F FF 95 00 FF 91 81 71 FE 47 00 44 4E 41 53 50
31 31 30 20 52 65 76 41 30 31 14 [ 0ms ]
RX Data : 1F 00 04 [ 0ms ] Valeur du compteur de cycles
TX Data : 06 6D 01 6E 9A 6F 00 [ 202ms ]
RX Data : 86 # Octets traités par l'UNLOOPER ( 06 )
RX Data : 1B # Octets reçus de la carte
RX Data : 3F FF 95 00 FF 91 81 71 FE 47 00 44 4E 41 53 50
31 31 30 20 52 65 76 41 30 31 14 [ 0ms ]
RX Data : 1E 00 C9 [ 0ms ] Valeur du compteur de cycles



Comme vous pouvez le constater, il y a une grande différence entre le temps minimum et le temps maximum. IL N'EST PAS POSSIBLE D EN TIRER QUOI QUE CE SOIT donc. Nous avons besoin de valeurs constantes pour pouvoir nous synchroniser.

Une piste les enfants :


Citation:
TX Data : 0A 6D 0E 10 01 07 6E 80 6F 99 00 [ 353ms ]
RX Data : 89 # Octets traités par l'UNLOOPER ( 09 )
RX Data : 1A # Octets reçus de la carte
RX Data : F8 95 00 FF 91 81 71 A0 47 00 44 4E 41 53 50 31
30 31 20 52 65 76 30 30 37 3D [ 0ms ]
RX Data : 00 00 28 [ 0ms ] Valeur du compteur de cycles
TX Data : 0A 6D 0E 10 01 07 6E 80 6F 99 00 [ 432ms ]
RX Data : 89 # Octets traités par l'UNLOOPER ( 09 )
RX Data : 1A # Octets reçus de la carte
RX Data : F8 95 00 FF 91 81 71 A0 47 00 44 4E 41 53 50 31
30 31 20 52 65 76 30 30 37 3D [ 0ms ]
RX Data : 00 00 28 [ 0ms ] Valeur du compteur de cycles
TX Data : 0A 6D 0E 10 01 07 6E 80 6F 99 00 [ 430ms ]
RX Data : 89 # Octets traités par l'UNLOOPER ( 09 )
RX Data : 1A # Octets reçus de la carte
RX Data : F8 95 00 FF 91 81 71 A0 47 00 44 4E 41 53 50 31
30 31 20 52 65 76 30 30 37 3D [ 0ms ]
RX Data : 00 00 28 [ 0ms ] Valeur du compteur de cycles
TX Data : 0A 6D 0E 10 01 07 6E 80 6F 99 00 [ 429ms ]
RX Data : 89 # Octets traités par l'UNLOOPER ( 09 )
RX Data : 1A # Octets reçus de la carte
RX Data : F8 95 00 FF 91 81 71 A0 47 00 44 4E 41 53 50 31
30 31 20 52 65 76 30 30 37 3D [ 0ms ]
RX Data : 00 00 28 [ 0ms ] Valeur du compteur de cycles



Quand vous attendez le Startbit, combien de fois s'est fait le SendToiRD?
Quand vous lisez E+1 octets de l'ATR, combien de fois ça s'est fait vers le SendToIRD?
Est-ce que vous avez fait une autre synchro avec la carte après avoir lu les octets de la carte off?

Petite parenthèse sur la lecture de l'ATR

Le pb de l'ATR incomplet est du au fait que la carte off a pendant l'ATR un compteur de tentatives d'intrusions fixé à 15 fois et à chaque fois que l'on baisse la ligne IO à low, la carte off considère que vous êtes en train de faire une tentative d'intrusion. C'est la raison pour laquelle en passant au protocole T1, vous n'aurez que des zéros de plus car sachant que vous utilisez un unlooper, il ne met plus la ligne IO à low après chaque réception, mais cela implique que les valeurs de GUARD doivent être plus précises car avec le contrôle de la ligne IO en attente, on synchronisait parfaitement sauf que maintenant, nous devrons donner les valeurs réelles.

Regardez plutôt le résultat de scrïpt "HSA Unlooper.xvb"


Code:
Executing scrïpt: D:\Travail\HSA Unlooper.xvb
TX Data : A1
TX Data : B0 80
TX Data : 06 10 0E 10 01 9F 00
RX Data : 05 1B
RX Data : 3F FF 95 00 FF 91 81 71 FE 47 00 44 4E 41 53 50
31 31 30 20 52 65 76 41 30 31 14
TX Data : 02 02 00
RX Data : 02 00
TX Data : A0

3FFF9500FF918171FE4700444E415350313130205265764130

3114

TS = 3F
T0 = FF

TA1 = 95
TB1 = 00
TC1 = FF
TD1 = 91

TA2 = 81
TD2 = 71

TA3 = FE
TB3 = 47
TC3 = 00

TKs = 444E41535031313020526576413031
D N A S P 1 1 0 R e v A 0 1

TCK = 14

Factor Fi = 512
Factor Di = 16
NGuardtime = -1 etus
Programing Vpp = 0 volts
Programing Ipp = 25 mA
Protocol = T1

Assuming Card Clock = 4.608 Mhz
Byte convention = Inverse
ATR parameters = 12387 bauds (14400,o,8,2)
WORK parameters = 144000 bauds (153600,o,8,2)
ETU = 6.94444444444444E-06 sec
BYTEtime (1+8+1+2+N) = 7.63888888888889E-05 sec



En réalité, l'histoire des temps d'éxécution random ne nous complique pas vraiment la vie car ils ne peuvent modifier ce qui a été établi, tels que les protocoles T0 et T1. Par exemple, si l'on veut faire une synchronisation après une lecture, cela "tue" les temps aléatoires:


Code:
...89 200010 0B Bf 00 <- exemple d'un paquet partiel
89 <- lecture de 10 octets
20 0010 <- un delay de 0010 cycles d'AVR
0B <- glitch de voltage (un exemple)
Bf <- lecture de 64 octets
00 <- fin de paquet



Si l'on envoie un paquet comme cela, cela ne servira à rien. Cependant, il y a un MAIS, car ils ne peuvent pas mettre quelque chose de 100% nouveau. De plus, les récepteurs doivent rester compatible ISO7816 !!! Si vous en avez les moyensn, utilisez plutôt un oscillo pour faire un trace des mesures de conso. on appelle çà communément du Power Analysis, analyse de conso du micropro et crypto !!


Citation:
...89 07 200010 0B Bf 00 <- un exemple de paquet partiel
89 <- lecture de 10 octets
07 <- attente ligne IO à low
20 0010 <- delay de 0010 cycles d'AVR
0B <- glitch de voltage (exemple)
Bf <- lecture de 64 octets
00 <- fin de paquet



Avec une ins supplémentaire, on évite le pb des routines aléatoires car nous nous synchronisons avec le STARTBIT de la transmission suivante.

Donc, il suffirait de se synchroniser après avoir mis la ligne I/O en niveau Low commencement du paquet Startbit suivant. Il faut bien sûr avant cela mettre l'unlooper en mode compteur.

Voyons de plus près :


Code:
Start Parity Next

bit <----- 8 data bits -----> bit Start bit

Z ____ ________________________________......______ __

| | | | | | | | | | | | |

I/O | |ba|bb|bc|bd|be|bf|bg|bh|bi| Guardtime | |

|___|__|__|__|__|__|__|__|__|__| |___|_

A : : : :

0 t1 : t10

: :

:<---- (n+/-0.2) etu --->:




Code:
TX Data : 0A 6D 0E 10 01 07 6E 80 6F 99 00 [ 353ms ]
RX Data : 89 # Valeur du compteur de cycles( 09 )
RX Data : 1A # Octets reçus de la carte
RX Data : F8 95 00 FF 91 81 71 A0 47 00 44 4E 41 53 50 31
30 31 20 52 65 76 30 30 37 3D [ 0ms ]



... après un 01 (Reset) nous avons un 07 qui est une attente de l'I/O niveau bas (attente du Startbit). Cette commande, pour des raisons évidentes s'éxécutera dans un laps de temps et ce qu'elle fait c'est la détection du startbit puis en lisant le premier octet perd quelques bits de la synchro.

L'idée est que le Startbit est "absorbé". Quand une routine unlooper utilise la commande "Wait for low" celle-ci a aussi une conso, quand elle termine et qu'elle va à la commande suivante du packet de glitch qui est une lecture d'un octet., cette routine de lecture va chercher un Startbit qui doit être à zéro.

Segments du code d'une carte off seca v6.0 utilisant les routines aléatoires :


Code:
;-------------------------------------------------------------------------------
; Process remaining ins
; verify protected ins, atr and address to corresponding ins routine
;-------------------------------------------------------------------------------
L1BB0: lcall L4CAB ;1BB0 12 4C AB ;comp. offset first free prov.
lcall L51CE ;1BB3 12 51 CE ;comp. current prov. area addr
jc L1BBF ;1BB6 40 07 ;jump if all ok
mov 010h,#090h ;1BB8 75 10 90 ;load status code
mov 011h,#004h ;1BBB 75 11 04 ;load status code
ret ;1BBE 22 ;return
L1BBF: lcall L52B1 ;1BBF 12 52 B1 ;test control records and rng
lcall L5427 ;1BC2 12 54 27 ;set anti snooping counterm.
lcall L4858 ;1BC5 12 48 58 ;random response time routine
mov r0,#07dh ;1BC8 78 7D ;load value
mov a,@r0 ;1BCA E6 ;load ins
lcall L2CDE ;1BCB 12 2C DE ;jump to corresponding routine
;-------------------------------------------------------------------------------


;-------------------------------------------------------------------------------
; Random response time routine
;-------------------------------------------------------------------------------
L4858: mov r0,#0e0h ;4858 78 E0 ;load value
mov a,#001h ;485A 74 01 ;load value
mov @r0,rnd#,a ;485C F1 52 8A ;load random byte
clr a ;485F E4 ;clear
mov r6,a ;4860 FE ;clear
L4861: mov a,06ah ;4861 E5 6A ;load random byte
swap a ;4863 C4 ;swap nibbles
rrc a ;4864 13 ;rotate right with carry
anl a,#007h ;4865 54 07 ;only bits 2,1,0
xrl a,06ah ;4867 65 6A ;xor



Dans un but purement scientifique, on a regardé comment on pouvait se synchroniser et on a découvert çà :


Code:
consomation de cycles aléatoires
envoi de l'octet complet (10 bits, 1 start bit + 8 data + 1 stop)
consomation de cycles aléatoires



Dans certaines cartes off dernière génération, il y a une conso de temps aléatoires avant l'envoi de l'ATR et il est simple de se synchroniser en utilisant l'INS 07 de l'unlooper qui attend que la ligne IO se mette en niveau bas (commencement du Startbit) ainsi, on évite la conso de temps aléatoires et l'on peut arriver à un point spécifique.


Code:
consommation des cycles aléatoires
envoi de l'octet complet (10 bits, 1 start bit + 8 data + 1 stop
Un autre tuto avec photo de Musclor;
http://www.dzup.110mb.com/download.php?file=997546

KIFFANSAT
Admin

Messages : 100
Date d'inscription : 01/10/2008

Voir le profil de l'utilisateur http://kiffan.bbactif.com

Revenir en haut Aller en bas

Voir le sujet précédent Voir le sujet suivant Revenir en haut

- Sujets similaires

 
Permission de ce forum:
Vous ne pouvez pas répondre aux sujets dans ce forum