Checksum ou CRC pour lecteur carte puce série

Signaler
Messages postés
19
Date d'inscription
mardi 24 juin 2003
Statut
Membre
Dernière intervention
18 juin 2021
-
Messages postés
19
Date d'inscription
mardi 24 juin 2003
Statut
Membre
Dernière intervention
18 juin 2021
-
Bonjour à tous,

Je dois pouvoir lire et écrire des infos sur des cartes à puce de type Siemens SLE 4432/4442 répondant aux normes ISO 7816 à partir d'un lecteur série répondant aux mêmes normes.

Je n'ai aucune doc concernant le lecteur (le cd qui va avec est gentiment retiré d'office par le fournisseur et pas moyen de contacter le constructeur en Chine).

Voici mon problème :

lors de l'envois/réception de trames vers le/du lecteur, le dernier octet correspond à un cheksum ou un crc8 que je n'arrive pas à calculer.

J'ai essayé les algorithmes de modulos 256, crc8 etc sans trouver.

J'espère qu'en donnant des exemples de trames, quelqu'un pourra m'aider à comprendre quel algoritme est utilisé pour calculer le dernier octet envoyé ou reçu (a mon avis, cela doit correspondre à des normes d'autres lecteurs plus connus).

voici des exemples de trames envoyées au lecteur:

en orange : le nombre d'octets envoyés après (sans l'octet final)
en bleu : le nombre d'octets de données attendus dans la réponse
en rouge : l'octet de vérification (cheksum ou autre)

AA B0 00 07 80 00 00 00 00 00 0A 97

Si dans cette trame je change la valeur bleue et rouge de la manière suivante (-2), celà fonctionne et je reçois bien 2 caractères en moins dans la réponse.

AA B0 00 07 80 00 00 00 00 00 08 95

autres exemple de trames qui fonctionnent :
AA 61 00 07 77 00 00 00 20 00 10 8B

AA 61 00 07 77 00 00 00 30 00 30 BB

AA 61 00 07 77 00 00 00 2E 00 01 94

par contre, une mauvaise trame envoyée au lecteur me renvoye comme réponse une trame dont le dernier octet peut-être calculer sur base d'un checksum modulo 256:

55 8A 00 00 DF
(55+8A) mod 256 = DF un hasard ?

J'espère que quelqu'un pourra m'éclairer sur le sujet parce que je ne sait plus par ou chercher.

Merci d'avance.















ALSC

5 réponses

Messages postés
615
Date d'inscription
dimanche 13 août 2006
Statut
Membre
Dernière intervention
13 décembre 2018
3
Salut ALSC,

Si j'ai bien compris (j'ai pas torturé mes neurones en faisant les calculs), tu soupçonnes les 2 premières lignes de tes exemples :

AA B0 00 07 80 00 00 00 00 00 0A 97

de ne pas faire le même calcul que les suivantes;
C'est à dire que ces 2 premières lignes ne suivent pas la règle d'un checksum modulo 256?

Bien à toi

Jean_Jean
Messages postés
19
Date d'inscription
mardi 24 juin 2003
Statut
Membre
Dernière intervention
18 juin 2021

Merci Jean_Jean

En fait je cherchais sur base de trames connues, quel algoritme permettais de définir le dernier octet.

J'ai pensé en premier lieu à un modulo 256 qui donnait des résulats sur certaines trames mais pas d'autres, puis j'ai essayé un CRC8 qui donnait aussi certain résultats mais avec des valeurs d'initialisation différentes.

Et finalement, il s'agit tout bêtement d'un LRC (Longitudinal redundancy Check).

Ce problème étant reglé, après avoir lu et étudié la norme ISO 7816, je n'arrive pas à retrouver dans les trames envoyées au lecteur la partie de la trame correspondant à une trame ADPU.

Bref, je crois que je ne suis pas tres clair parce que je suis occupé la dessus depuis une trentaine d'heures sans dormir.

Je te remercie beaucoup pour ta réponse, je reprendrai le fil après avoir dormis.

Bien à toi,

Alain

ALSC
Messages postés
615
Date d'inscription
dimanche 13 août 2006
Statut
Membre
Dernière intervention
13 décembre 2018
3
Yo,

ça me rappelle le temps ou je bricolais les transmissions séries entre des ordinateurs et des terminaux d'armoires électriques.

IBM nous foutait dedans en nous affirmant que ses terminaux communiquait en 9600 baux alors que c'était 2 fois moins vite. Mais la RS232 était moins compliquée que les normes actuelles!

J'écrivais même un programme de mastermind pour jouer sur les armoires électriques et passer le temps!

Maintenant, t'as même plus le temps de "pisser". Enfin façon de parler, moi ça va, j'ai le temps maintenant...

Je ne sais pas en quoi je t'ai aidé, mais enfin bon merci quand même!

Jean_Jean
Messages postés
19
Date d'inscription
mardi 24 juin 2003
Statut
Membre
Dernière intervention
18 juin 2021

Je n'ai pas fermé le sujet parce que je me doutais bien que j'aurais d'autres problèmes. (Jean_Jean t'as peut-être une idée ?)

Je ne sais pas si je peux continuer ici ou si je dois en créer un nouveau.

Comme cela reste dans le même style, je me dis qu'on peut continuer ici, surtout que 'pseudocode' à l'air de s'y connaitre au niveau des puces Siemens.

Bon voilà...

Suite à la commande 'AA 61 00 07 77 00 00 00 30 00 30 BB' envoyée au lecteur (avec la carte insérée), je reçois la réponse suivante :

'55 00 00 30 2D D4 7C FF 6E DA 46 C9 52 DF 5C 4B 57 D5 02 D0 5D CB 58 D6 FC 7A 5E DC 59 D7 54 B6 57 DF CA 71 7B FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 29'

En rouge: la partie de trame provenant du lecteur (OK)
En orange: la partie de trame correspondant à ce qui a été lu sur la carte.

On peut oublier la partie de la trame envoyée par le lecteur de carte ainsi que la partie de la trame comportant des FF à la fin.

Il reste :
2D D4 7C FF 6E DA 46 C9 52 DF 5C 4B 57 D5 02 D0 5D CB 58 D6 FC 7A 5E DC 59 D7 54 B6 57 DF CA 71 7B

Les valeurs en rouge sont inchangables (2D du début de trame et 7B en fin)

L'avant dernière valeur (71) ressemble à un LRC parce que si on l'augmente de 1 ou de 2 en même temps q'une autre valeur dans la trame, c'est OK, sauf que c'est pas un LRC, mais alors c'est quoi ? .

Je ne vois pas à quoi correspondent les valeurs 'D4 7C' en début de trame.

Je connais les valeurs affichées par les autres champs, mais je n'arrive pas à trouver comment calculer ces valeurs.

Voici le détail :
FF 6E DA 46 C9 = 0510013321 (string)
52 = 01 (Integer)
DF 5C = 0000 (Integer)
4B 57 D5 = 91,9 la façon d'afficher ce champ est modifiée par la valeur CA en fin de trame. (Float)
02 D0 5D = 000050 (Integer)
CB 58 D6 = 000010 (Integer)
FC 7A 5E = 009999 (Integer)
DC 59 D7 = 000000 (Integer)
54 B6 57 = 086400 (Integer)
DF=10

1° les valeurs enregistrées sur la carte ne semblent pas tenir compte du type (string, integer ou float); 0510013321 en string à l'air d'être traité de la même façon que 000050 qui est un Integer.

2° Je ne trouve pas comment traduire ce qui est lu sur la carte et la valeur à obtenir. (ex CB 58 D6=000010 et DC 59 D7=000000).

Si quelqu'un à une idée, pour me mettre sur la voie, ce serais vraiment tres sympa...

Merci


ALSC
Messages postés
19
Date d'inscription
mardi 24 juin 2003
Statut
Membre
Dernière intervention
18 juin 2021

Je renvoies le message car le précédent n'est pas vraiment lisible...

Suite à la commande 'AA 61 00 07 77 00 00 00 30 00 30 BB' envoyée au lecteur (avec la carte insérée), je reçois la réponse suivante :

'55 00 00 30 2D D4 7C FF 6E DA 46 C9 52 DF 5C 4B 57 D5 02 D0 5D CB 58 D6 FC 7A 5E DC 59 D7 54 B6 57 DF CA 71 7B FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 29'

En rouge: la partie de trame provenant du lecteur (c'est OK).
En orange: la partie de trame correspondant à ce qui a été lu sur la carte.

On peut oublier la partie de la trame envoyée par le lecteur de carte ainsi que la partie de la trame comportant des FF à la fin.

Il reste :
2D D4 7C FF 6E DA 46 C9 52 DF 5C 4B 57 D5 02 D0 5D CB 58 D6 FC 7A 5E DC 59 D7 54 B6 57 DF CA 71 7B

Les valeurs en rouge sont inchangables (2D du début de trame et 7B en fin)

L'avant dernière valeur (71) ressemble à un LRC parce que si on l'augmente de 1 ou de 2 en même temps q'une autre valeur dans la trame, c'est OK, sauf que c'est pas un LRC, mais alors c'est quoi ? .

Je ne vois pas à quoi correspondent les valeurs 'D4 7C' en début de trame.

Je connais les valeurs affichées par les autres champs, mais je n'arrive pas à trouver comment calculer ces valeurs.

Voici le détail :
FF 6E DA 46 C9 = 0510013321 (string)
52 = 01 (Integer)
DF 5C = 0000 (Integer)
4B 57 D5 = 91,9 la façon d'afficher ce champ est modifiée par la valeur CA en fin de trame. (Float)
02 D0 5D = 000050 (Integer)
CB 58 D6 = 000010 (Integer)
FC 7A 5E = 009999 (Integer)
DC 59 D7 = 000000 (Integer)
54 B6 57 = 086400 (Integer)
DF=10

1° les valeurs enregistrées sur la carte ne semblent pas tenir compte du type (string, integer ou float); 0510013321 en string à l'air d'être traité de la même façon que 000050 qui est un Integer.

2° Je ne trouve pas comment traduire ce qui est lu sur la carte et la valeur à obtenir. (ex CB 58 D6=000010 et DC 59 D7=000000).

Si quelqu'un à une idée, pour me mettre sur la voie, ce serais vraiment tres sympa...

Merci


ALSC




ALSC