Veuillez aider à identifier le système de codage de caractères multi-octets sur ASP Classic page

Question

Je travaille avec un système de traitement des paiements tiers (Commidea.com) et l'un des paramètres envoyés avec le résultat du traitement est un champ "signature" . Ceci est utilisé pour fournir un hachage SHA1 du message de résultat enveloppé dans une enveloppe cryptée RSA pour fournir à la fois l'intégrité et le contrôle d'authenticité. J'ai l'API de Commidea mais elle ne donne pas de détails sur l'encodage et utilise des signatures créées artificiellement dérivées de chaînes Base64 pour illustrer les exemples.

J'ai du mal à trouver quel encodage est utilisé pour ce paramètre et j'espérais que quelqu'un pourrait reconnaître le motif tout à fait particulier. J'ai d'abord pensé que c'était UTF8 mais après avoir regardé les caractères individuels je suis moins sûr.

Voici un court extrait du contenu qui a été créé par le code suivant où je suis Boucler dans chaque « octet » dans la chaîne:

sig = Request.Form("signature") 
For x = 1 To LenB(sig) 
    s = s & AscB(MidB(sig,x,1)) & "," 
Next 
' Print s to a debug log file 

Quand je regarde dans le journal que je reçois quelque chose comme ça :

129,0,144,0,187,0,67,0,234,0,71,0,197,0,208,0,191,0,9,0,43,0,230,0,19,32,195,0,248,0,102,0,183,0,73,0,192,0,73,0,175,0,34,0,163,0,174,0,218,0,230,0,157,0,229,0,234,0,182,0,26,32,42,0,123,0,217,0,143,0,65,0,42,0,239,0,90,0,92,0,57,0,111,0,218,0,31,0,216,0,57,32,117,0,160,0,244,0,29,0,58,32,56,0,36,0,48,0,160,0,233,0,173,0,2,0,34,32,204,0,221,0,246,0,68,0,238,0,28,0,4,0,92,0,29,32,5,0,102,0,98,0,33,0,5,0,53,0,192,0,64,0,212,0,111,0,31,0,219,0,48,32,29,32,89,0,187,0,48,0,28,0,57,32,213,0,206,0,45,0,46,0,88,0,96,0,34,0,235,0,184,0,16,0,187,0,122,0,33,32,50,0,69,0,160,0,11,0,39,0,172,0,176,0,113,0,39,0,218,0,13,0,239,0,30,32,96,0,41,0,233,0,214,0,34,0,191,0,173,0,235,0,126,0,62,0,249,0,87,0,24,0,119,0,82,0 

Notez que toute autre valeur est un zéro, sauf de temps en temps où il est 32 (0x20). Je suis familier avec UTF8 où il représente les caractères au-dessus de 127 en utilisant deux octets mais si c'était le codage UTF8 alors je m'attendrais à ce que la valeur "32" soit plus comme 194 (0xC2) ou (0xC3) que 0x80. Finalement, ce que j'essaie de faire est de convertir ce paramètre de signature en une chaîne codée en hexadécimal (par exemple "12ab0528 ...") qui est ensuite utilisée par la fonction RSA/SHA1 pour vérifier que le message est intact. Cette partie fonctionne déjà mais je ne peux pas pour la vie de moi comprendre comment obtenir le paramètre de signature décodé.

Pour des raisons historiques, nous devons utiliser ASP classique et les fonctions SHA1/RSA sont basées sur JavaScript.

Toute aide serait grandement appréciée. Cordialement, Craig.

Mise à jour: J'ai essayé d'examiner l'encodage UTF-16 sur Wikipedia et d'autres sites. Je ne trouve rien pour expliquer pourquoi je ne vois que 0x20 ou 0x00 dans les positions (supposées) d'octets d'ordre supérieur. Je ne pense pas que ce soit plus pertinent car l'exemple ci-dessous montre d'autres valeurs dans cette position d'ordre élevé.

Essayé d'ajouter du code pour consigner les valeurs en utilisant Asc au lieu de AscB (Len, Mid au lieu de LenB, MidB aussi). J'ai des résultats surprenants. Voici un nouveau flux de caractères octets suivi du flux équivalent de mots (si vous voyez ce que je veux dire).

21,0,83,1,214,0,201,0,88,0,172,0,98,0,182,0,43,0,103,0,88,0,103,0,34,33,88,0,254,0,173,0,188,0,44,0,66,0,120,1,246,0,64,0,47,0,110,0,160,0,84,0,4,0,201,0,176,0,251,0,166,0,211,0,67,0,115,0,209,0,53,0,12,0,243,0,6,0,78,0,106,0,250,0,19,0,204,0,235,0,28,0,243,0,165,0,94,0,60,0,82,0,82,0,172,32,248,0,220,2,176,0,141,0,239,0,34,33,47,0,61,0,72,0,248,0,230,0,191,0,219,0,61,0,105,0,246,0,3,0,57,32,54,0,34,33,127,0,224,0,17,0,224,0,76,0,51,0,91,0,210,0,35,0,89,0,178,0,235,0,161,0,114,0,195,0,119,0,69,0,32,32,188,0,82,0,237,0,183,0,220,0,83,1,10,0,94,0,239,0,187,0,178,0,19,0,168,0,211,0,110,0,101,0,233,0,83,0,75,0,218,0,4,0,241,0,58,0,170,0,168,0,82,0,61,0,35,0,184,0,240,0,117,0,76,0,32,0,247,0,74,0,64,0,163,0 

Et maintenant, le flux de données mot-sage:

21,156,214,201,88,172,98,182,43,103,88,103,153,88,254,173,188,44,66,159,246,64,47,110,160,84,4,201,176,251,166,211,67,115,209,53,12,243,6,78,106,250,19,204,235,28,243,165,94,60,82,82,128,248,152,176,141,239,153,47,61,72,248,230,191,219,61,105,246,3,139,54,153,127,224,17,224,76,51,91,210,35,89,178,235,161,114,195,119,69,134,188,82,237,183,220,156,10,94,239,187,178,19,168,211,110,101,233,83,75,218,4,241,58,170,168,82,61,35,184,240,117,76,32,247,74,64,163 

Notez la seconde paire de caractères sage octet (83,1) semblent être interprétés comme 156 dans le flux de mots sage. Nous voyons aussi (34,33) comme 153 et (120,1) comme 159 et (220,2) comme 152. Cela donne-t-il des indices comme encodage? Pourquoi ces 15 [2369] valeurs sont-elles apparemment traitées différemment des autres valeurs? Ce que j'essaie de comprendre, c'est si je devrais utiliser les données octets et effectuer un post-traitement pour revenir aux valeurs prévues ou si je devrais faire confiance aux données par mot avec tout décodage implicite il est apparemment performant. Pour le moment, ni l'un ni l'autre ne semblent me donner une correspondance entre le contenu des données et la signature, je dois donc changer quelque chose.

Merci.

Answer 1

Une observation rapide me dit que vous avez probablement affaire à UTF-16. Commencez à partir de là.