2010-11-16 1 views
1

Я работаю с системой обработки платежей третьей стороной (Commidea.com), а один из параметров, отправляемых вместе с результатом обработки, является полем «подпись» , Это используется для предоставления хэша SHA1 сообщения результата, завернутого в зашифрованный конверт RSA, для обеспечения как контроля целостности, так и проверки подлинности. У меня есть API от Commidea, но он не дает подробностей кодирования и использует искусственно созданные сигнатуры, полученные из строк Base64, чтобы проиллюстрировать примеры.Пожалуйста, помогите определить схему кодирования многобайтовых символов на странице ASP Classic

Я изо всех сил пытаюсь определить, какая кодировка используется для этого параметра, и надеется, что кто-то сможет распознать довольно отличительный образец. Сначала я думал, что это UTF8, но, посмотрев на отдельные персонажи, я менее уверен.

Вот краткий пример содержания, который был создан с помощью следующего кода, где я обхвата через каждый «байт» в строке:

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 

Когда я смотрю в журнале я получаю что-то вроде этого :

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 

Обратите внимание, что каждое другое значение представляет собой ноль, за исключением случаев, когда оно равно 32 (0x20). Я знаком с UTF8, где он представляет символы выше 127, используя два байта, но если это была кодировка UTF8, тогда я ожидал бы, что значение «32» будет больше похоже на 194 (0xC2) или (0xC3), а другое значение будет больше чем 0x80.

В конечном итоге то, что я пытаюсь сделать, это преобразовать этот параметр сигнатуры в шестнадцатеричную кодированную строку (например, «12ab0528 ...»), которая затем используется функцией RSA/SHA1 для проверки целостности сообщения. Эта часть уже работает, но я не могу на всю жизнь понять, как получить декодированный параметр подписи.

По историческим причинам мы вынуждены использовать классический ASP, а функции SHA1/RSA основаны на javascript.

Любая помощь будет высоко оценена. С уважением, Крейг.

Обновление: Пробовал искать кодировку UTF-16 в Википедии и других сайтах. Не могу найти ничего, чтобы объяснить, почему я вижу только 0x20 или 0x00 в (предполагаемых) позициях байтов высокого порядка. Я не думаю, что это имеет значение больше, так как приведенный ниже пример показывает другие значения в этой позиции высокого порядка.

Пробовал добавить код для регистрации значений с помощью Asc вместо AscB (Len, Mid вместо LenB, MidB тоже). Получили неожиданные результаты. Вот новый поток байтовых символов, за которым следует эквивалентный поток словесных (если вы знаете, что я имею в виду) персонажей.

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 

А теперь слово мудрого поток данных:

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 

Обратите внимание на вторую пару побайтно символов (83,1), кажется, интерпретируются как 156 в словампереключаете потока. Мы также видим (34,33) как 153 и (120,1) как 159 и (220,2) как 152. Означает ли это какие-либо подсказки как кодирование? Почему эти 15 [2369] значений, по-видимому, обрабатываются иначе, чем другие значения?

Что я пытаюсь выяснить, следует ли использовать байт-мудрые данные и выполнить некоторую пост-обработку, чтобы вернуться к предполагаемым значениям, или если я должен доверять словесным данным с каким-либо неявным декодированием это, по-видимому, выполнение. На данный момент, похоже, мне не кажется совпадением между содержимым данных и сигнатурой, поэтому мне нужно что-то изменить.

Спасибо.

ответ

1

Быстрое наблюдение говорит мне, что вы, скорее всего, имеете дело с UTF-16. Начните оттуда.

+1

Переменные 0-ые предлагают UTF-16LE, но он декодирует тарабарщину. – dan04

+0

Я бы не ожидал, что он будет декодироваться ничем, кроме тарабарщины, потому что это всего лишь RSA-зашифрованный SHA1-хэш из куча текста. Моя функция «проверка» предназначена для проверки того, что хэш SHA1, извлеченный из этой подписи, соответствует ожидаемому значению. Я обязательно буду следить за UFT-16LE. – craig1410