Mediaguard -> Bug du système

Bug 3c/3a[/b

[b]Cette section a été objet d'étude de la part du Sat experience group et nous vous reportons nos expériences à la lumière du travail excellent déroulée par le groupe d'étude italienne qui semble ils soient d'un po' au-dessus des collègues européens!

Bug 3C/3A

Le bug en problème est le plus grave de toute Mediaguard il la codifie. Merci à lui il a été possible de réussir à modifier les Smart card officiels et à en lire leur contenu.
Comme nous avons vu dans la section dédiée aux instructions le 0x3C il contient dans sa section le CONTROL WORD codifié d'un canal tu dates et il est ensuite à se considérer comme ECM(Entitlement Control Message. Donc dans sa structure nous remarquons que nous avons un NANO(vedere dans le glossaire, D1 suivi par 16 byte de données que ce sont le control justement word codifié actuellement répété 2 fois parce que pour l'instant le superencription sur les ECM n'a pas encore été implémenté.


Ce Control word que nous appellerons Key elle vient déposée dans la mémoire tampon dans l'attente d'être décodée par la prochaine instruction que c'est le 0x3A. En effet il la décode il arrive seul si l'instruction 0x3C est correct, c'est-à-dire avec de la signature, channel ID et date correcte. Comme nous avons dit L'instruction 0x3A il prélève le Key de la mémoire tampon et il la décode en rendant le 16 byte de la clé décodé.
Jusqu'ici tout normal mais le bug il naît vraiment de cette mémoire tampon qu'il contient le Key. En effet les programmateurs logiciel des card Mediaguard a omis le PETIT particulier de ne pas mettre à zéro la mémoire tampon après qu'une instruction 0x40 est exécuté avec le superencription activé. Celui-ci est très grave en combien si nous envoyons un simple INS aussi 0x40 avec un Key sans la signature celle-ci on positionnera dans la mémoire tampon et nous évidemment il restera mais si nous envoyons un 0x3C spécial et 0x3A successivement nous voyons que ce qui était dans la mémoire tampon viendra pour magie décodée. Ceci signifie qui pouvons exploiter le card x pouvoir décoder n'importe quel Key. Par exemple:


C1 40 00 80 09 XX XX XX XX XX XX XX XX 00
C1 3C 00 0F 08
C1 3A 00 00 08


À la réponse de cette dernière instruction nous obtiendrions quelque chose du genre:

3A YY YY YY YY YY YY YY YY


J'épingle ces YYYY c'est notre key parfaitement décodé avec le Key 00 du provider 00.
Ces modèles sont spécifiés en P1 et P2(vedere Étude de l'il codifie.
Ce petit faute nous a permis de réussir à écrire un beau key dans le provider 00 sans que nous connussions rien du papier.
Comme nous savons l'algorithme de cifratura il n'est pas réversible et pour pouvoir écrire un key dans le provider 00(e dans les autres provider, nous avons besoin pour force d'un commandement que j'aie une signature, signature, valide autrement le papier il n'acceptera jamais notre commandement en répondant 90 02.
Grâce à ce bug nous avons rendu pour ainsi dire l'algorithme réversible et nous pouvons utiliser comme signature chose quelconque que nous voulons, maintenant je vous explique:
Pour pouvoir écrire un MasterKey dans le provider 00 nous avons besoin d'un commandement du genre:


C1 40 00 0X 13 90 5X KK KK KK KK KK KK KK KK 82 SS SS SS SS SS SS SS SS


Voyons-lui ensemble:

C1 = Classe

40 = instruction

00 = P1 spécifie le provider où nous voulons operare(in ce cas le 00,

0X = il spécifie la clé qui voulons utiliser pour signer le comando(ho x mis parce que nous pouvons utiliser n'importe quel key que j'aille depuis 00 à la 09,

13 = longueur totale du commandement en esadecimale, à la partie les premier 5 byte initiales.

90 = nain qu'il indique au papier qui sera écrit

5x = il indique le key qui viendra scritta(ho x mis parce que nous pouvons utiliser n'importe quel key que j'aille depuis 00 au 0F,

KK KK KK KK KK KK KK KK = voilà la clé codifiée avec le key spécifié en P2 qu'il viendra inscription

82 = nain qu'il indique au papier qui tout de suite seront 8 byte de signature(firma après,


Comme nous avons dit si nous ne connaissons aucun key du papier nous ne pouvons pas écrire rien à l'intérieur d'elle
La chose unique à faire est réussir à dénicher la signature apte pour signer le commandement pour que le papier l'accepte.
la signature n'est pas autre qu'une
se levée d'encrypt du corps de notre message juste
Cet encrypt vient espèce 8 byte pour fois:


commandement: C1 40 01 01 XX 10 01 10 02 10 03 10 04 10 05 10 06 10 07 03 82 signatures


comment la signature est calculée par le papier? Ainsi:

1-Criptiamo l'octet premier

DW: 10 01 10 02 10 03 10 04
MK: AA AA AA AA AA AA AA AA
CW = 7C 18 00 65 BF 1A 7D FC

Nous 2-faisons le XOR avec la seconde

op1 = 7C 18 00 65 BF 1A 7D FC
op2 = 10 05 10 06 10 07 03 82
xor = 6C 1D 10 63 AF 1D 7E 7E

3-Criptiamo le résultat

dw: 6C 1D 10 63 AF 1D 7E 7E
mk: AA AA AA AA AA AA AA AA
cw = il FAIT 39 13 0E 85 12 6A 21

s'il y avait autres octets j'irais de cette manière en avant, ici pas nous en
ils sont autres, donc celle-ci ET' LE SIGNATURE de ce message hypothétique

Malheureusement L'algorithme Mediaguard n'est pas réversible et nous ne pourrions pas ensuite faire une brute force sur la signature mais merci note au bug 3c/3a peut le faire, vous me suivies:

Vu l'algorithme nous devons commencer à "écrire notre commandement
du dernier octet, plutôt que du premier comme nous faisons d'habitude, donc il est
bien avoir déjà en esprit de tout de suite le commandement qui voulons envoyer.
Nous envoyons

C1 40 00 00 XX 90 52 11 22 33 44 55 66 77 88 82 signatures


Maintenant nous avons vu que le calcul de la signature procède à octets et lui
il arrête au dernier octet complet, dans ce cas la 82 fin ne viendrait pas
considéré, pour éviter problèmes j'ai considéré que tous les commandements doivent
être longs multiples exigés de huit, donc en mettant en tête au commandement
un échange de ppua la longueur revient à être juste

C1 40 00 00 18 41 00 00 00 00 90 52 11 22 33 44 55 66 77 88 82 <signature>

, Cela vaut pour envoyer le commandement au provider seca évidemment,

alors nous mettons en clair l'algorithme au revers:

1 - signature: caractéristique = répondue au C1 5A 00 00 08, tu vois étude de l'il codifie, == crypt du dernier terme
de l'algorithme "diritto"(noto: "00 00 00 00 00 00 00 00",

En 2-sachant le dernier octet de notre commandement, connu: "22 33 44 55 66 77 88
82" doit tirer l'octet qui, Xorato avec celui-ci nous donne le dernier
terme, connu: "00 00 00 00 00 00 00 00",

Nous révisons le tableau de vérité du Xor:


op1 op2 | ris
0 0 0
0 1 1
1 0 1
1 1 0


voilà que donc pour avoir tous 0 l'octet désiré il doit être égal à
ce de départ.


En effet: 22 33 44 55 66 77 88 82 XOR 22 33 44 55 66 77 88 82 = 00 00 00 00 00 00 00 00

3 - maintenant nous devons décrypter cet autre octet, et celui-ci nous le faisons
grâce à le bug C13C/3A
CW = 22 33 44 55 66 77 88 82 DW = 75 D0 A5 7D FE 25 71 B7, en utilisant pour faire un exemple elle
mk habituel = AA AA AA AA AA AA AA AA,

4 - ce dw joue le même rôle de "00000000000000" d'avant, donc
nous procédons:

5 - nous devons maintenant insérer l'octet avant-dernier de notre message
, connu: "41 00 00 00 00 90 52 11",
comme vous aurez maintenant compris celui-ci il implique qui soit...
41 00 00 00 00 90 52 11 XOR
75 D0 A5 7D FE 25 71 B7 =
----------------------------------------
34 D0 A5 7D FE B5 23 A6

Il y ai presque, il suffit de décrypter cet octet avec le c13c/3a,
dans l'exemple dw devient = 9B 10 00 7B 91 00 65 CB

Et, à ce point, pour notre commandement, le travail est fini!
Le commandement s'est cependant allongé:
C1 40 00 00 20 9B10 00 7B 91 00 65 CB 41 00 00 00 00 90 52 11 22 33 44 55 66 77 88 82 75 25 D4 62 84 00 D3 13

Il s'est ajouté l'otteto qui est sauté pour dernier dehors, (donc le premier, et
que nous devons être sûrs qui ne contienne pas de nanocomandi, qu'autrement
ils seraient exécutés normalement!!!

Cela de l'exemple ne va pas ensuite y bien, en tout ce qu'il contient:
10 00 que ce n'est pas une belle chose exactement
10 06, de celui-ci nous pourrions frotter nous aussi en,
.
Évidemment notre clé, avoir envoyé le commandement n'est pas en l'après
forme 11 22 33 44 55 66 77 88, en combien les clés avant d'être écrite ils viennent
vous décryptez en utilisant le mk indiqué par le commandement, donc pour savoir la valeur
exact vous devez utiliser le bug c13c/3a pour votre clé
dans l'exemple:

cw: 11 22 33 44 55 66 77 88 Decript
mk: AAAAAAAAAAAAAAAA =
-----------------------------------------
dw: EC BE C2 31 29 39 E4 E4 = mk insérés par nous






En pouvant écrire un Mk dans le provider 00 nous sommes apte à pouvoir modifier tout le contenu du card, nous qualifier à tous les paquets offerts par le gérant sans que si j'en m'aperçoive et nous commettrions ensuite un acte illégal qui vous exhorte à ne pas faire.
Ensuite d'un oubli simple ou distraction des ingénieurs Mediaguard le système a simplement été crakkato.
Il ne semble pas malheureusement que l'expérience soit servie aux développeurs du Mediaguard en combien avec la nouvelle version de carte,le 6.0 a enfin enlevé le bug 3C/3A en vidant la mémoire tampon après une instruction 40 cependant je ne sais pas pourquoi ils n'ont pas évalué qu'il n'existe pas seul la 40 comme instruction qu'il soutient le superencription, d'ici voilà qu'une variante du bug naît 3C/3A et au lieu d'une instruction 40 faut envoyer une instruction 38 type:
C1 38 00 80 09 XX XX XX XX XX XX XX XX 00
C1 3C 0F 0F 00
C1 3A 00 00 08


Cela arrive parce qu'en 38 le superencription(si est activé tu remarques le 80, et il laisse ensuite le contenu dans la mémoire tampon qui n'est pas nettoyé comme en 40.
Peut-être si un jour ils résolvent ce bug, je souhaite de lui!

ZZbug

Ce bug est connu depuis temps et il fut découvert par le grand Zztop. Il exploite les imperfections dell 0x3CQuindi avec un commandement formé par l'instruction 0x3C ils peuvent faire choses qu'elles ne seraient pas permises autrement.

Ce commandement est très risqué si exécuté sur un key dont il ne se connaisse pas le contenu en clair

En combien puis il peut modifier de manière irréparable le Smart card.

LE COMMANDEMENT SEMBLE QU'IL AGISSE SEULEMENT SUR SC VERS. 4.1

en envoyant un commandement 3c mélange de cette manière

C1 3C 00 FX 00 où X stà pour key auquel adresser le 3c

de cette manière le sc répond d'une manière anomale qui de mes essais

je peux résumer de cette manière

1)Il comportement du sc est déterminé par les bytes présents dans le key auquel le commandement

mandat vient

2, donc avec le commandement qui maintenant appellerai FX et un key que j'appellerai y je peux écrire sur

un sc

3, le numéro key de y est ininfluente pour le but il peut être un key 00/01/02 et si ailleurs

4, avec certains tu dates dans le key y le sc restituiscie le premier bytes atr c'est-à-dire 3B successivement avec

l'envoi d'un n'importe quel autre commandement restituiscie les bytes restants atr

5, exemple en envoyant le commandement fx sur un key y avec des données en clair> 11 11 11 11 11 11 11 11 il

il écrit un key 05 avec des données en clair> 03 13 E8 15 E8 23 13 E5

et expérimenté par moi que je sois le key écrit soit les indicateur du key ils se répètent exactement si

éprouvées sur un autre sc pourvu que je sois un 4.1

et vous vous retrouverez dumpando, un record ainsi> D2 00 75 FF FF FF FF FF FF FF FF 74 00 80

6, ce key y> 0e 00 00 00 00 00 00 00 portera le sc au niveau 2!!!!

7, pendant que celle-ci est mortelle> 11 1C 00 00 00 00 FF FF portera le sc au niveau que je définirai

inconnu en effet les derniers

4 bytes atr sont 02 00 02 00 le sc elle est mise à zéro complètement de tous les provider. le reste

serial et à n'importe quel commandement il répond 90 24

les instructions qualifiées uniques sont 0e / 0a /7c

8, une autre chose que je dois faire observer et que les key écrits pas an jamais un standard indicateur

comment F0/51 etc... mais valeurs différentes par exemple un key 06 peut avoir un indicateur >16 un key

0f> FF et si ailleurs

Le commandement C1 3C 00 FX 00, mais il est le même pour C1 3C 00 8X 00 ou aussi c1 40..) il définit un superencryption de longueur 0, ILEN = 0.

Et je remarque que le rom pour calculer le numéro de byte de decryptare utilise:

N = ILEN + 0xF8

Qu'il correspond à l'ILEN -8, signarure, à moins de l'overflow beaucoup de chéri aux projeteurs du rom

Le papier s'attend donc de devoir decryptare 0xF8, 248, byte et en théorie il devrait decryptare toute la zone de 0x90 au 0x188, dans le cas 3C.

Mais un autre overflow intervient ici



Le pointeur au byte premier de decryptare est géré avec la location ram 0x33 et avoir decryptato l'octet qui les commence au 0xF8 a l'overflow qui met à zéro 0x33 après

Il commence donc au decryptare en partant de la location 0x00, le début du ram.

Et ils commencent ici les douleurs

L'octet premier est subi critique en tout ce qu'il contient des registres de système (i/o) eeprom..) mais je ne crois pas de cmq qu'il succède rien encore irréparable.

Arrivez-les par contre à la "catastrophe" quand on tente de decryptare l'octet qui commence au 0x28 et qu'il contient les locations 0x2A-0x2D dont le jouissance devrait être connu aux spécialistes les plus attentifs du rom.

En particulier dans la location 0x2D le papier écrit 0x81 (ret) pendant le start-up et type location ne vient pas plus toccatta.

La perte du "ret" fà oui que tous les appels au L02A ne reviennent pas et ils laissent le Program-Counter à errer dangereusement en ram.

En étant les optcode valides pour le ST16 peu plusieurs d'une centaine est évident que le processeur se trouvera bien bientôt au fetchare un optcode illégal

la mémoire tampon des commandements va de 0x88 au 0xe6.

Le bug crypta au-delà de la mémoire tampon qui en implique aussi autres octets mais il ne va pas au-delà 0xFF, 0xf8 est le dernier octet qu'il vient decriptato premier d'inziare de 0x00.

Le decrypt de la zone 0xe7 0xff n'a aucun effet, il l'aurait après sur le superencryption qui continue à la basse tête jusqu'à le 0x2A.

Le contenu de 0x2A premier du decrypt vaut:

F0 00 CF 00 04 81 E0 00, oviamente dépend du commandement qu'il vient envoyé.. 3c, 40, 38..)

et la location 0x2A est exécuté...

L7F05: lda #0c6h / / 7F05 a6 c6

il reste 02ah / / 7F07 b7 2a

jmp L002A / / 7F09 bc 2a



Celui-ci et' un des nombreux points dans lesquels on recourt au $2A pour les opérations habituelles de pointage, mais aussi j'ai toujours été convaincu que la 2A fût exécuté deuxième tout ce qu'a été prévu par l'opcode BC.

Avec la technique habituelle de l'écriture au vol en $2A, $2B $2C et saut suivant au $2A en confiant sur le retour assuré par l'opcode 81, rts, qu'en théorie il devrait être toujours nous au $2D

Et' vrai donc que $2A->$2D est utilisé comme si ce fussent un pointeur logiquement, mais et' plus correct voir ces locations comme une routine dynamiquement modifiée pour charger et 2A est exécuté vous avoir chargé dans l'opcode qui sert sur le moment pour l'adressage voulu après, suivi par l'adresse sur laquelle veux opérer suite à son tour de rts que par contre et' huissier ils en phase d'init une fois pour toutes, si je rappelle bien,

dans la location $2a est mis les instructions:

LDA

IL RESTE

LDX

STX

Les queli poirier' ils lisent le contenu de la location visé par le deux byte qu'ils suivent, 2b et 2c.

Là-dessus' en 2d il peut' être c'est-à-dire' seulement nous la valeur 81 RTS.

À ce point pour les 4.0 il suffirait de réussir à mettre:

$CC $45 $CC pour le niveau 1

et

$CC $45 $F7 pour le niveau 2

Il est ensuite clair que les conséquences du bug sont à l'intérieur de la fonction de SI (L555d) et avoir criptato la zone 0xe7-0xff aurait des conseguense seul à la sortie de la SI.

Telles conséquences sont comparables à un raffeddore je respecte al'iktus que stà pour provocae le decrypt della'erea initial du RAM.

Si le 81 est perdu le processeur il se trouvera bien bientôt au fetchare un optoce illégal..... conséquence....

la zone qui vient decryptata est:

0x90-0xFF et puis

0x00-0x79, la location finale est approximative,

les deux premières locations critiques sont 0x00 et 0x28.

Effectivement le decrypt du RAM arrive qui est mémorisé $90 à partir de jusqu'à $FF, pour puis recommencer de $00.

L'exécution procède tant que le code normalement il est exécuté en L002A qu'il contient

CF 00 2D stx $2D

81 rts

qu'en modification pratique l'instruction de retour avec "quelque chose" différent.

Maintenant nous considérons qu'en $2E il se trouve le dernier caractère reçu par la sériel, et je voudrais exploiter cette caractéristique pour engendrer une instruction de 2 bytes.

L'objectif devrait être ensuite:

x = 0x20, opcode de bra(nch,

dernier caractère reçu = 0x5A, de suite le parce que,

l'instruction obtenue serait:

002D 20 5A bra L0089

c'est-à-dire un saut au byte premier n'utilisé pas de la mémoire tampon de réception en supposant d'envoyer le commandement,

C1 3C 0x Fk 01 5A

que donc il amorce le bug et il laisse le 0x5A en $2E

J'ai volontairement utilisé un INS 34 erronée pour préparer la mémoire tampon

je modifie la séquence de commandements à envoyer, toujours et seulement pour 4.0 et clé E2 00 00 00 00 00 00 00

C1 34 00 00 07 00 CD 60 10 CC 40 1E

vous devriez obtenir: C1 34 00 00 07 34 00 CD 60 10 CC 40 1E 67 00

suivi de

C1 3C 0x Fk 01 5A

je m'attends que C1 donne 3C 0x Fk 01 3C 5A 20 suivi par l'ATR

En pratique le sc devrait exécuter, à cause du bug d'underflow:

JSR 6010

JMP 401E

et c'est-à-dire envoi d'un byte sur la sériel, le contenu de X, et saut au RESET.

Tout ceci nous permet de lire le Ram et l'eeprom, chose le très grave!

Ça suffit donc un 0x3C simple pour acquérir du surgissant des smart card mediaguard version 4, le qu'il met les pirates dans une condition favorable pour réussir au buttar en bas le système.

Je ne reporte pas le struzione qui dumpa la mémoire pour respect aux découvreurs qui se sont seulement montrés avec l'intention d'étudier le système.

Le procédé prévoit de toute façon:

Une écriture d'un key spécial qui sert aux cript spéciaux

Puis on envoie un ins 0x34 avec les opcode du processeur

Avec l'avènement des papiers Mediaguard version 6 le bug du piège ne fonctionnait plus. Alors les hacker du sat trouvèrent son sostituto,il funny bug.

Le scrittura/lettura des clés sur les 6.0 est effectué exécution préalable d'un codifica/decodifica préliminaire. Celle-ci est effectuée en les servant de l'encryption key, différente pour chaque sc, et de l'algo seca. Un égal clé vient crittata de la même façon pour n'importe quel provider et pour n'importe quel index sur le même card mais il change sur card différents. Le checksum est calculé déjà avec les connus critères sur la clé crittata.


Le Funny bug permet d'écrire une "copie" de la clé en autre record, cette copie créée en suivant un "parcours" du code ne prévu pas, elle est écrite sans en effectuer préalablement le cifratura. Nous avons si résolu le problème, en ne restant pas autre à faire qu'utiliser le bug du piège 34/32 pour la lire.

le bug est simple, commandement le plus simple est:

c1 3c 00 00 0a 99 82 signatures

Le 99 on mange tout parce que skippare il y a 9 byte et il n'existe pas comme nain

et il écrit le mk00 de 00 au record 1 de la fiche.

La signature vient vérifiée en allant à la fin du message et en prenant le dernier huit bytes.

Pendant le processing des nains différents, le 82 si rencontré traité il vient pour provoquer la sortie nettoyée par la routine qu'il sortirait autrement seulement pour "épuisement" de l'ILEN, beaucoup de pour entendre nous et' la situation dans lequel la 40 revient 96 xx,

Dans ce cas il y n'a pas nains significatifs pour la 3C, donc le processing continue beau beau jusqu'à le l'épuisement de l'ILEN.

Et chose se les succède voilà il sort pour avoir raggiounto ILEN:

Un beau call à 40F9 Vous routine d'écriture record

J'envoie le commandement:

C1 3C 00 06 0A 99 82 99 E5 D3 D6 4A DE FD 30

Répondue: 90 00

Ridumpo le Card:



Provider 0.

Record 0001 = 56 FF FF FF FF FF FF FF FF 66 00 80

Record 0002 = 00 xx xx xx xx xx xx xx xx xx xx E0

Record 0003 = F0 FF FF FF FF FF FF FF FF xx 00 80

Record 0004 = xx xx xx xx xx xx xx xx xx xx xx D0

Record 0005 = 50 FF FF FF FF FF FF FF FF xx 00 C0

...



Le MK06 est fini copiée en effets sur le Record 0001.

Dump Buggato sur 15 55:



---> C1 34 00 00 03 34 06 15 55 90 00

---> C1 32 00 00 12 32 D2 15 57 xx xx xx xx xx xx xx E0 56 90 A0 B0 00 00 03 90 00

---> C1 32 00 00 12 32 D2 15 68 90 90 90 90 90 90 90 E0 52 DE C7 A0 00 00 03 90 00



- Dans la lecture sur 15 57 se voit la clé en clair juste.

- Dans la lecture sur 15 68 se voit un autotrappolamento du MK02 Criptata du Card

, qu'il devrait être 00x8 s'il n'était pas criptata...)

Dump Buggato sur 2A AA:



---> C1 34 00 00 03 34 06 2A AA 90 00

---> C1 32 00 00 12 32 D2 2A AV. J.-C. xx xx xx E0 56 90 A0 B0 D0 E0 90 A0 00 00 03 90 00



- Aussi dans la lecture sur 2A AV. J.-C. il se voit la clé en clair juste.

Il s'agit de faire juger au sc un 3C avec un nanocomando "sans fondement" en longueur, comme par exemple:

C1 3C 00 00 0C 00 00 FF 82 (signature)

Le résultat est que la clé présente sur la mémoire tampon recorde est archivée sur le record 1. nous Allons pour ordre: nous prenons un commandement semblable à ce sur, nous appliquons la "méthode" pour le marquer, il faut la signature valide avec la clé qui cerclons, et nous l'envoyons au card: nous nous trouverons avec deux clés 0 seca primaires, une au record 1 et l'autre au record 3, d'habitude. Les deux sont égaux apparemment, même checksum, mais sous les FF du record 1 la clé est en CLAIR.

Attention que dans cette situation nous ne pouvons plus appeler la clé 0 pri de seca parce que le card donnera faute, il comprend que dans la clé quelque chose ne va pas,; nous ne pouvons pas l'effacer en outre parce qu'au-delà à la primaire nous effacerons la secondaire aussi. Mais une fois finie de trappolarla nous pourrons envoyer un 3C analogue en écrivant au record 1 une de nos backdoor, que puis provvederemo à effacer avec l'autre backdoor de sûreté, en effet nous ne pouvons plus utiliser la premier à cause de la faute. À la fin de tout nous remettrons à la place le record de startup et le jeu il est fait. Pour la secondaire le discours est analogue. Le problème des inscriptions clé sur le record 1 est qu'ils se trouvent sur le premier record justement, donc sans la possibilité d'écrire valeurs trappolabili sur le précédent record. Les bytes importants sont le troisième et le septièmes de la clé qui se trouveraient à représenter le type de dumpando records avec les valeurs 15 57 et 2A AV. J.-C.. Si le septième est grand de 80 alors nous trouverons 7 bytes de la clé, s'il est non entièrement nous devrons essayer avec le troisième et aussi ici s'il est grand de 80 nous aurons seulement trouvé 3 bytes de la clé. Il y a ensuite le 25% de probabilité de pas trappolare nul. Il pourra succéder de trouver une valeur 8x ou Cx naturellement pour lequel quelques bytes seront masqués par les FF, mais en chaque cas nous aurons au moins 3 bytes de la clé 0. à qui s'ajoute le demi byte. La brute force dans le pire cas sera sur 4 bytes et demi.

Et pour les 6.0 nous sommes à la place. Il reste l'encryption certainement key, mais pour celle-ci le discours est différent, comme la méthode pour l'extraire.

Il fonctionne ensuite

Ensuite pour trappolare la clé qui voulons faut envoyer une 3C avec la signature de cet hiave même.

Mais si nous connaissons non entièrement comme nous faisons à le signer?

Il vient ici y vers le bug 3c/3a pour calculer un pseudosignature(vedi bug 3c/3a,

Vu que nous sommes en présence de card version 6 il faudra envoyer

Un C1 38

C1 3C

C1 3A

Pour les calculer le commandement final qui doit être du type

c1 3c xx yy 18
7x xx xx xx xx xx xx xx = decrypt de, 50 00 00 00 00 00 99 82,
50 00 00 00 00 00 99 82
zz zz zz zz zz zz zz zz = résulté c1 5a xx yy 08

si l'octet premier ne commence pas pour 7 il suffit de développer un 0 de la seconde jusqu'à obtenir 7.

Le trappolamento peut arriver seulement en 75% dellevolte parce qu'on doit présenter le cas qui assument valeurs plus hautes de 80H

nous mettons que nous trouvons 3 bytes de la clé
90 91 92 xx xx xx xx xx
et l'autre non. Le septième byte est inférieur évidemment à 80h, parce que nous aurions trappolato autrement le.
Alors des autres bytes que nous devons trouver avec la brute force nous savons quelque chose en plus et nous pouvons ensuite rétrécir le champ des combinaisons: le quatrième, le cinquième, le sixième et le huitième peuvent assumer valeur quelconque pendant que le septième seulement les valeurs inférieures à 80h.
En forme argotique ils sont 4 bytes et demi, je devrais faire les calculs autrement sur les combinaisons et dire qu'ils sont 256^4 * 128 plutôt que 256^5.

Peut-être si avec le nouveau realase de papiers mediauard ces problèmes seront résolus?

Espérons vraiment de lui!