information via

joecut

DZSatien Expert
Inscrit
30/7/08
Messages
1 036
bonjour je vous met une discution d'un autre forum sa devrai aider pour reactiver quelque modele je pense j'ai enlever les pseudo des post mais si les personne concerné veulent que je les site qu'elle le fasse savoir

La lecture de l'ATR ne pose pas de problème car elle est faite avec les paramètres de communication par défaut du lecteur mais après l'ATR on peut constater que le démo envoie à la carte une trame du Protocole de négociation PTS (Protocole Type Selection) :
'FF 10 18 F7'.
La carte valide cette requête et renvoie la même trame au démo :
'FF 10 18 F7'.
Cela à pour effet de changer les paramètres de la com, ce qui explique pourquoi les données logguées deviennent illisibles.
Que ce soit l'analyse de TA1 de l'ATR ou de PTS1 de la requête PTS, la valeur 18h ne permet pas de retrouver la configuration de la communication car F = 0001 (soit 372) mais on n'a pas calculer la vitesse d'horloge car D = 1000 (soit RFU - c'est à dire : réservé pour un futur usage).
A ce stade, je suis également dans une impasse ...
Salut,
avec la phoenix , après la requête "FF 10 18 F7" , la dialogue carte passe à 115200 bauds.
@++
Bonsoir,
J'ai effectivement vu ce type d'init de port dans les scripts - soit 9600 pour l'ATR et 115200 après (x 12) ;
mais si pour mon Xsat 410 on a un vitesse par defaut de 8861 bauds (au lieu de 9600 ou 11500) alors à 106 332 bauds, je n'ai pas de résultat.

c'est effectivement la valeur qu'il fallait trouver
souvenez vous du message de dom21, un bit environ 7µs
1/7µs = 142857 sachant qu'il existe proche de cette valeur; la vitesse 115200 bauds. un test à cette valeur permettez de voir apparaitre des
CA 88 des CA f0 plutot que des 36 b6 00 ff
1/115200 = 8.68µs
Le log est fesable avec une carte sat et univiacam comme plugin.
J'ai pris un serie au hasard et voila.
8D70209003032821A919396139831000000000000000000000 00000000000000000000
8E702CE876190000A20080C10A10100428884C400E11288000 6802340A09880302238820000004C983A79CEBD37723
8D -> table_id
7020 -> EMM-GH packet length 32 bytes
9003 ...> Nano 90 (SOID) length 3 bytes
032821 ...> Service Operator [ 032820 ] using Key [ 01 ]
A919 ...> Nano A9 (DATES + CUSTWD) length 25 bytes
39613983100000000000000000000000000000000000000000 ...> Subscription period by Class
3961 -> Beginning Date (BD): 1.11.2008
3983 -> Finishing Date (FD): 3.12.2008
100000000000000000000000000000000000000000 -> CUSTWD [ A4 ]
8E -> table_id
702C -> EMM-S packet length 44 bytes
E87619 -> Shared Address
00 -> fixed format
(9E20) ...> Nano 9E (ADF) length 32 bytes
00A20080C10A10100428884C400E112880006802340A098803 02238820000004 ...> Adress Field
---- 02 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 1D -- -- --
-- -- 23 -- -- -- 27 28 29 -- -- -- 2D -- -- -- 31 -- -- -- -- -- -- 38 39 -- -- -- -- -- -- --
-- -- 43 -- -- -- 47 48 -- -- 4B -- -- -- -- -- 51 -- 53 -- -- -- -- -- -- 5A -- 5C 5D -- -- --
61 -- -- -- -- -- -- -- -- -- 6B -- 6D 6E -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 7F --
-- -- 83 -- 85 -- -- 88 -- -- -- 8C -- -- -- -- 91 92 93 -- -- -- -- -- -- -- -- -- -- 9E -- --
-- A2 A3 -- -- A6 -- -- -- -- AB -- -- -- AF -- -- -- B3 -- B5 -- -- -- -- BA -- -- -- -- -- --
-- -- -- C4 -- -- -- -- -- -- -- CC -- -- -- -- D1 -- D3 -- -- -- -- D8 -- -- -- -- -- DE DF --
-- -- -- -- -- -- E7 -- -- -- -- -- -- -- -- -- F1 -- -- -- F5 -- F7 -- -- -- -- -- -- -- --
(F008) ...> Nano F0 (HASH) length 8 bytes
C983A79CEBD37723 ...> Signature
ah au fait j'ai oulier PID EMM 0308 hex !
Bonjour
Toutes les via3.0 s'activent effectivement de la même manière, une ECM et les droits full pour 10 jours.
Par contre les droits mensuels passent toujours par des EMM.
En ce qui concerne la valueur des données, comme sur mon xsat 410 la valeur standard pour lire l'ATR est de 11520 bauds, je soupçonne fortement que la vitesse des données soit 12 fois supérieure(12*11520=138240 bauds) et donc dépasse le 120.000 bauds des max232.
De plus les drivers wiondows pour les ports com ne montent guère à cette vitesse.
Il faut donc deux éléments pour logguer :
- un port RS232 capable de passer autre chose que du 128.000 bauds
- des composants remplaçant le max 232 des season par des produits tenant au mini 200.000 bauds, par ex le max 232A.
J'attends de recevoir les miens pour finir et avaliser les tests par season
Pour ceux qui ont des demos qui tournent en standard en 9600 bauds et qui peuvent le rester après l'envoi de la vitesse de dialogue , ceux là pourront continuer à faire , je pense , le log en season, il semble par ex que ce soit le cas des anciens demos TPS de marque Thomson.
Sur une Dreambox , on doit pouvoir aussi limiter la vitesse de dialogue.
Je n'ai malheureusement ni l'un , ni l'autre pour pouvoir faire ce type d'essais, je n'ai qu'un xsat410 et unecam viacess rouge qui présentent les mêmes problèmes.
salut
Salut,
petit exemple de log emm pid stream via3.0 sur le PPUA E87748?? :
trame entête 8E70:
8E70 2C
E8774800
00000000000000000000000004000000000000000000000000 00000000000000
D3D04A9F10E5315B
suivi d'une trame entête 8C70 ou 8D70:
8D70 1C 9003032821
A915396139830800000000000000000000000000000000
(une trame entête 8C70 ou 8D70 a souvent plusieurs trames 8E70 qui la précède).
Conversion :
CAA4040003 032820 ;selection provider
CAF0000122 ;Longueur de CAF0=$2C-$0A=$22
9E 20 00000000000000000000000004000000000000000000000000 00000000000000
CA18010121 ;Longueur de CA18=$1C+($A-5)=$21
A915396139830800000000000000000000000000000000
F008
D3D04A9F10E5315B
c'est normal qu'il y ai autant d'emm pour 1 ppua
g environ 20 emm pour le meme ppua
autre question la cle utilisé et bien juste apres le provider
8D70 1C 900303282 ->1 c bien ce chiffre la
Oui le dernier bit designe la cle utilisée

Salut,
il y a plusieurs emm par groupes d'abonné,c'est le CAF0 qui désigne grâce au Custwapp à qui sera destiné l'emm.
Exemple sur groupe PPUA E87748 :
CA F0 00 01 22
9E 20 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 00 00 10 00 00 00 00 00 00 00 00 00 20 00 00 00
seul les custwapp 1D,6C,9A seront concernés.
Donc cette CAF0 concerne les cartes avec PPUA:
E877481D,E877486C et E877489A
Ces cartes repondront "9000" au CAF0 et au CA18.
Par contre si la carte n'est pas abonné (dernier octet PPUA autre que 9A) elle va bien recevoir le CAF0 mais étant donné qu'elle ne fait pas partie des Custwapps valides,elle va repondre 9100 et le CA18 ne sera pas envoyé.
Merci
comment obtenir les Custwapps
en manu evidemment sans logiciel
Salut,
Dans le champ de donnée qui suit "9E20" ,il y a 32 octets soit 256 bits.
Donc il y a 255 custwapps possibles,de $00 à$FF,on compte à partir de la fin.
Dans cet exemple,
00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 00 00 10 00 00 00 00 00 00 00 00 00 20 00 00 00
L'emplacement de 20 est le 29eme bit ,29=>$1D
L'emplacement de 10 est le 108eme bit,108=>$6C
etc....
Merci
j'avais devinez tout seul
tout est ok environ 6 trames
g des reponse 9040 sur les CA18
quelqu'un sait il d'ou cela peux venir
Merci

y a t il un soft pour logger une 39 avec poor cam ?
merci d'avance
j'ai posté trop vite !
la reponse est univiacam!
a+
peux t on reactiver un provider avec la trame d'un groupe
?
Pour les trames de maj
On cherche la trame 8E qui correspond au ppua puis la premiere 8C ou 8D qui arrive correspond à 8E trouve
Ce n'est pas l'inverse 8C ou 8D et les 8E qui suivent corresponde à la 8C ou 8D precedente



Bonjour
Je croyais en connaitre un bon bout sur le viacess ... et ben non !
en faisant un log sur BIS j'obtiens de temps en temps ce type de trames:
> CA 1C 01 01 29 02/01/2009-16:42:55-Temps Inter ECM: 16 ms
> 92 08 : 8B 35 D6 74 C7 92 B0 77 Unknow
> 81 13 : BF 0C B3 D9 01 FB 99 FD 9E 98 6F 46 A3 46 E3 2B D6 99 C4 Unknow
> F0 08 : 7C FA E4 BC D2 BC 4E B4 (Signature)
< 99 00 BAD -Temps Execution: 155 ms
> CA C8 00 00 02 02/01/2009-16:42:55-Temps Inter ECM: 16 ms
> 00 00
< 90 00 GOOD-Temps Execution: 11 ms
> CA F4 00 01 2C 02/01/2009-16:42:58-Temps Inter ECM: 2096 ms
> 91 08 : 5D 1A 59 31 CA 42 29 25 Unknow
> 9E 20 : 62 12 3C F1 0C 01 53 8F 0B 3F FB B9 E2 1C 15 1E D6 7A 12 43 CF 61 FF 02(Mask PPUA)
ED 65 38 1C 71 3E 61 78
< 91 00
pour moi la réponse 9100 est une occultation géographique (pourtant j'ai le code de la CA AC A6 à FF FF FF FF) et quant à la réponse 9900 mystére ??
De même les ins 1C , C8 , F4 sont pour moi inconnues bien que la CA F4 se rapproche de la CA F0 de mise à jour des droits...


Salut,
c'est exactement la même chose que CAF0 et CA18 mais le champ data qui est en clair normalement est crypté.
Je pense que ce doit être comme ca:
CA F4 00 01 2C
> 91 08 : 5D 1A 59 31 CA 42 29 25 --->Hash de depart (8 octets)
> 9E 20 : 62 12 3C F1 0C 01 53 8F 0B 3F FB B9 E2 1C 15 1E D6 7A 12 43 CF 61 FF 02 ED 65 38 1C 71 3E 61 78 (Mask PPUA Crypté par clef 01)
< 91 00 (Le Custwapp de la carte ne fait pas partie des custwapps du CAF0)
CA 1C 01 01 29
> 92 08 : 8B 35 D6 74 C7 92 B0 77 --->Hash de depart (8 octets)
> 81 13 : BF 0C B3 D9 01 FB 99 FD 9E 98 6F 46 A3 46 E3 2B D6 99 C4
(Champ data du CA18 crypté par clef 01)
> F0 08 : 7C FA E4 BC D2 BC 4E B4
Pour le 9900 j'en sais rien et le demo non plus car il demande un code complementaire avec la commande CAC8 qui precede.
Serai bien de faire des essais sur pc2.3 pour confirmer ou infirmer.

Hello,
en complément à la réponse de

Citation:
Envoyé par




en faisant un log sur BIS j'obtiens de temps en temps ce type de trames:


C'est rigolo... Les cartes suisses utilisent le même genre de trames pour les mises à jour.

Citation:




> CA 1C 01 01 29




et
Citation:




> CA F4 00 01 2C



sont effectivement des ins qui ont le même but que les CA 18 et CA F0. Y'a juste un bit en plus à 1 (4) qui veut dire "crypté". (18 + 4 = 1C et F0 + 4 = F4). C'est bien des EMMs et non des ECMs.
Pour les cartes suisses, dans la CA 1C, on a aussi les nanos 92 et 81, comme tes logs de Bis. Ca contient la mise à jour des droits (à ce que j'ai constaté). Pareil pour la CA F4, avec les nanos 91 et 9E. C'est comme la CA F0, mis à part que le champ d'adresse contenu dans 9E est crypté avec la nano 91.
Pour ce qui est du code de retour 9900, il dit que la carte a une réponse étendue. Elle est ensuite demandée avec la CA C8, et tu reçoit un 9000 qui semble indiquer que tout c'est bien passé.
Voilà ce que j'en ai conclu après avoir analysé un petit peu les logs des mises à jour des cartes suisses.
Par contre, si quelqu'un a une liste des codes de retour avec leur signification, je suis preneur. :)
Bonne Année 2009 à tous.
Merci pour ces réponses je comprends mieux...
Voilà aussi un descriptif des erreurs que j'ai pu récupérer:
*****************************
Deux groupes d'erreur viaccess : 6X YY et 9X YY
le premier octet X :
- 3 bits de poid faibles définissent le code de l'erreur d'exécution de l'instruction :
- contrôle de la position géographique avec l'instruction CAF8
bit0 = 1 si erreur
- opérations PIN avec l'instruction CA24
bit2 = 1 si incorrect PIN
- décodage CW avec l'instruction CA88/CAF8
bit0 = 1 - blocage géographique
bit1 = 1 - HASH non initialisé
bit2 = 1 - erreur sur l'opération
- gestion de la carte avec l'instruction CA18/CA1C
bit0 = 1 - l'opération était déjà accomplie
bit1 = 1 - HASH non initialisé
bit2 = 1 - paramètre erronné
- contrôle de l'authentification avec l'instruction CAC4/CA48
bit2 = 1 - non reconnue
- demande d'information avec l'instruction CAAC
bit2 = 1 - nano-instrucion (P1) non reconnue
Le deuxième octet YY :
bit0 = 1 - défaillance de la carte
bit1 = 1 - erreur de succession, par exemple: pas de CAAC avant CAB8 ou pas de CAC4 avant CA48
bit2 = 1 - structure incorrecte du message-mauvais ordre des données, par exemple CA18: A103 doit être devant EF08
bit3 = 1 - erreur dans les champs des données
bit4 = 1 - erreur ecriture/lecture de l'EEPROM
bit5 = 1 - erreur d'accés (EEPROM/EPROM)
bit6 = 1 - erreur de hash
bit7 = 1 - accès aux données non autorisé
0x60 peut précéder la réponse signifiant qu'il faut plus de temps à la carte (reset du time-out)
************************
- réponses généralement obtenues:
67 00 - longueur incorrecte des données P3.
6B 00 - les significations incorrectes des paramètres P1/P2
6D 00 - instruction inconnue (le deuxième octet)
6E 00 - classe inconnue des instructions (le premier octet)
98-YY - il faut lire le code plus détaillé de l'erreur avec l'aide de l'instruction CA C8 00 00 02
90 00 - OK
90 08 - OK plus le drapeau de la fin des données.
91 00 - l'instruction est rejetée (la tentative du réenregistrement de la clé / données existant, l'adresse non identifiée, etc)
92 00 - dans l'instruction précédente le hash tampon n'était pas initialisé.
94 00 – parfois incorrect PIN
9C 00 - code PIN non entré (CA 24 00 00 09)
90 04 et 90 40 - erreur dans l'instruction donnée
90 06 - erreur d'écriture (EEPROM)
************************
 
Dernière édition:
salut

merci pour l'info
apparament c'est la meme procedure que le seca 3 pour loger les trames
univiacam exit-il pour windows pour loger une carte un viacess ?
 
oui s'est (UVCE.dll) fais une recherche sur google.@+
 
Retour
Haut