Добрый вечер, уважаемые. Ковыряю одну программку, всё мне, в общих чертах, с ней понятно. Но есть один интересный момент. Попробую его подробно описать.

Дело в том, что программка эта использует CryptoAPI в ходе проверки регистрационного ключа. Если описывать процесс подробно, то всё обстоит примерно так. Вначале программа вычисляет hwid по параметру даты биоса из реестра и GetVolumeInformation, это неважно. Далее эти параметры она, типа, хэширует по какому-то самопальному алгоритму, тоже неважно. Потом начинается самое интересное.

Вначале создаётся объект для работы с md5 хэшем:



Потом, естественно, идёт вычисление хэша md5 от слабого (самопального) хэша.



Далее, как я понимаю, на основе md5-хэша по алгоритму rc2 создаётся сессионный ключ:



Теперь вспомним про то, что мы ведь тоже ввели какой-то серийник, который, собственно и проверяется в ходе регистрации. Так вот, в ходе проверки из этого серийника всегда получается массив длиной в восемь байт. Всегда! Алгоритм проверки реализован без косяков, т.е. на вычиисление длины не влияет, есть ли внутри массива нулевые байты или нет - всё работает, как часы. Ок, идём дальше.

Сейчас у нас есть сессионный ключ, и есть 8-ми байтовый массив. Далее происходит расшифровка массива по сессионному ключу:



И вот здесь - самое вкусное. Расшифровка-то происходит (на месте старых 8-ми байт появляются новые значения), но вот функция CryptDecrypt возвращает FALSE, GetLastError() возвращает NTE_BAD_DATA. Я тут гуглил-гуглил, и нагуглил --> Это <--. Там в комментах кто-то пишет такое:

The typical reason why CryptDecrypt would fail with NTE_BAD_DATA would be that you're decrypting the last block of a block cypher (as you are) and the decrypted padding bytes are incorrect. This can happen if the input is truncated (not all encrypted bytes were saved to the file) or if the key is incorrect.

В общем, если то, что написано, правда, то тут ситуация ясна - key is incorrect стопудово, т.к. откуда ж мне знать его правильный. В связи с этим возникает несколько вопросов.

1. Правда ли, что при неправльном сессионном ключе может возникать такая ошибка? (А то я просто думал, что если ключ для алгоритма расшифровки неверный, то просто будут данные некорректные, но в ходе расшифровки это никак не спалить, это ж не цифровая подпись)
2. Если правда, то как выполнить атаку, чтоб найти правильный?

Спасибо всем, кто осилил сей пост до конца и проникся моими проблемами. Саму программу я не прикладываю, ибо большая, узкоспециализированная и никому сама по себе неинтересна.

Примечание

int, я надеюсь, что &nbsp; снятся тебе каждую ночь.

-----
Stuck to the plan, always think that we would stand up, never ran.

| Сообщение посчитали полезным:

данные не выровняны(да такое иногда требуется на быстроты вычисления итд)

входной буффер для рашифровки 8 байт? ты ключем дешифруешь только 8 байт и уже ошибка?

| Сообщение посчитали полезным:

Судя по описанию тебе не ключ крипты нужно подбирать, а на основании имеющегося ключа подобрать серийник, который бы давал нужные 8 байт - 1 блок RC2.
Собственно, если ты знаешь что после декрипта должно получиться - не вижу проблемы с атакой.

-----
старый пень

| Сообщение посчитали полезным:

reversecode
Возможно, декрипт для последнего блока ожидает неполный блок данных + паддинг с инфой о реальном размере. Вот и валится ошибка. Потому что обработано всего 8 байт, а паддинг+размер не совпадают.

-----
старый пень

| Сообщение посчитали полезным:

reversecode

Однозначно. Размеры буфферов должны учитывать тип алгоритма и выравнивание. Или же алгоритм сводится к своебразному хешированию, примерно того же плана как в RSA используется Mod.

P.S. 8 байт это брутится...

| Сообщение посчитали полезным:

Rainbow

По поводу брутится - если в лоб, то нужно перебрать 255^8 = 17878103347812890625 вариантов. Многовато как-то.

reversecode пишет:
ты ключем дешифруешь только 8 байт и уже ошибка?

Именно, всего 8 байт, там только один вызов CryptDecrypt, параметр Final сразу равен TRUE. И всё - ошибка.

r_e пишет:
Судя по описанию тебе не ключ крипты нужно подбирать, а на основании имеющегося ключа подобрать серийник

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

Собственно, если ты знаешь что после декрипта должно получиться - не вижу проблемы с атакой.

Так я и не знаю. Мне нужно просто, чтоб функция отрабатывала нермально. Хрен его знает, как этого добиться.

Возможно, декрипт для последнего блока ожидает неполный блок данных + паддинг с инфой о реальном размере.

Про паддинг я читал в МСДН, но вот только там не сказано, что он из себя должен представлять. Не подскажете, где бы разжиться инфой об этом?

-----
Stuck to the plan, always think that we would stand up, never ran.

| Сообщение посчитали полезным:

r_e пишет:
Потому что обработано всего 8 байт, а паддинг+размер не совпадают
я это и имел ввиду под выравниванием
если блок 9 байт, а должен быть кратным 8

но кроме паддинга можеть быть еще и варавнивание самого буффера,
это часто используется во всяких крипто ускорителях или обработка видео для оптимзированого доступа к данным , но тогда первый же проход даст уже не верный результат

| Сообщение посчитали полезным:

Самый простой убедиться почему это происходит это скачать символы в pdb-файлах и продебажить внутренности винды.
К примеру, проверьте есть ли вызовы функции:
CryptSetKeyParam с параметрами dwParam=KP_PADDING и pbData=PKCS5_PADDING
Если такое есть, то оно может по паддингу палить что ключ неправильный. Хотя об этом уже сказали выше.

| Сообщение посчитали полезным:

В общем, дебажил я дебажил криптоапи, и пришёл внутрь библиотеки rsaenh.dll, там есть функция BlockDecrypt, внутри этой функции происходит всякая интересная шняга. А конкретно - следующее. Вначале мой буферок расшифровался. Т.е. я получил некие 8 байт (отличные от первоначально зашифрованных). Потом вот здесь:



Последний расшифрованный байт сверяется с длиной буфера. Она у меня была равна 8, помните? Должно быть меньше либо равно 8. Потом этот же байт сравнивается с единицей:



Если у меня последний байтик был больше 1, то дальше начинается проверка моего предпоследнего расшифрованного байта:



Теперь от меня хотят, чтоб байты (последний и предпоследний были одинаковы):



А потом от меня хотят, чтоб последний символ был меньше либо равен двойке (двойка потому, что смотрим сейчас второй с конца символ - там цикл):



Когда мы выходим из этого прекрасного цикла, то оказывается, что последний байт вычитается из входной длины (длины входного буфера, котрая равна 8):



И тогда функа вернёт истину (функа - CryptDecrypt). Это что - документированное поведение?

Добавлено
Сейчас перечитал своё сообщение и понял, что тут же чёрт ногу сломит. А суть всего этого можно уместить в несколько предложений. Паддинг здесь - это такая штука, которая дополняет буфер до нужной длины, если он изначально был короткий. Т.е. у нас буфер длиной в 8 байт, а данных в нём, например, 7 байт. Тогда нужен ещё один байт паддинга. Вот он и приписывается в конце - 01. Если полезных данных не 7, а, скажем, 6 байт, то приписывается два байта с одинаковым значением: 02 02. Если 5 байт, то 03 03 03 и т.д.

-----
Stuck to the plan, always think that we would stand up, never ran.

| Сообщение посчитали полезным:

скорее MS$ сам решил что паддинг у нее такой,
поэтому дешифровка, будет работать паравильно только с ипользованием шифрования этой же енжин

это если действительно дело в паддинге оказалось

| Сообщение посчитали полезным:

ARCHANGEL
>Если полезных данных не 7, а, скажем, 6 байт, то приписывается два байта с одинаковым значением: 02 02. Если 5 байт, то 03 03 03 и т.д.
Такой паддинг зовется PADDING_PKCS5, причем если полезных байт будет ровно по длине блока - например у нас длина блока 8 байт и длина исходного сообщения 8 байт, то добавиться еще один блок с 08 08 08 08 08 08 08 08, а потом зашифруется (если речь идет о зашифровке)

| Сообщение посчитали полезным: ARCHANGEL

bbuc
Совершенно верно. Я об этом и писал =) Видать не достаточно подробно.

-----
старый пень

| Сообщение посчитали полезным:

ARCHANGEL
так все же уточним
криптованый блок был криптован не с помощю крипто апи M$,
и при раскриптовке? M$ декрипт желал видеть пкс5 паддинг в конце который он бы сам добавил в случае если бы криптовал
так?

| Сообщение посчитали полезным:

reversecode
Если верить МСДН, то да, именно так.

Applications that use CryptoAPI need not add padding to their plaintext before it is encrypted, nor do they have to remove it after decrypting.

Сами криптоАПИ не считают паддинг, который получается в буфере при расшифровке, как часть расшифрованного текста (длина паддинга вычитается из выходной длины). Но только кто ж знал, в каком виде паддинг они (криптоапи) желали увидеть - мне ведь нужно было подставить валидное криптованное значение, которого у меня не было, так как не было валидного серийника. Ну а теперь, вроде бы, всё ясно. Пробую кейгенить дальше...

-----
Stuck to the plan, always think that we would stand up, never ran.

| Сообщение посчитали полезным:

я к чему веду,
если к примеру брать 8 байт и пытатся шифровать - это же нормальный размер для твоего случая?
то крипто апи выдаст ошибку о том что буффер маленький?
или расширит буффер до своего паддинга и зашифрует?
тогда это конечно забавно, если подавая навход крипто айпи один размер буффера получать другой, только потому что M$ позаботилась о своих апи

думаю ищет паддинг оно только в включеным флагом "финал"
поэтому в твоем случае можно его выключить, что бы криптоапи думал что есть еще данные
и не ругалось ошибками

| Сообщение посчитали полезным:

reversecode
Это стандарт и касается не только MS.

-----
старый пень

| Сообщение посчитали полезным:

тогда получается пакет который он расшифровывает, зашифрован не постандарту?

| Сообщение посчитали полезным:

reversecode
ARCHANGEL пишет:
мне ведь нужно было подставить валидное криптованное значение, которого у меня не было, так как не было валидного серийника
PS: автор еще rsa на крипто-апи не мучал. вот, где вопросы тоннами

-----
От многой мудрости много скорби, и умножающий знание умножает печаль

| Сообщение посчитали полезным: hors

reversecode
Если там полезная инфа меньше размера блока - то все по стандарту.

-----
старый пень

| Сообщение посчитали полезным:

r_e
Тут ведь видите, в чём вопрос, в МСДН написано, что паддинг должен быть. Но не написано, что он должен из себя представлять. Или, может быть, где-то в недрах МСДН написано, но ссылок со страницы функции CryptDecrypt нет, есть описание ошибки, где говорится, что проблемы могут быть с паддингом, есть определение паддинга, а вот про его структуру ничего не сказано. Вы говорите, что это стандарт, а скажите, в каком стандарте с этой инфой можно ознакомиться?

ajax
Ну, я ж не выбираю, что разбирать. Что авторы в процедуре проверки ключа намутили, то и разбираем.

-----
Stuck to the plan, always think that we would stand up, never ran.

| Сообщение посчитали полезным:

Писали ж выше, PKCS 5 или RFC 1423.
Да это общий дефолтный паддинг, он не привязан к RC или DES.

| Сообщение посчитали полезным:

Archer

Ну, я в гугле вот так написал --> Для наглядности <--

Глянул результат - где вы там увидели RFC 1423, мне неясно, но за название документа спасибо, посмотрю.

Вот, кажись, оно:


The input to the DES CBC encryption process shall be padded to a
multiple of 8 octets, in the following manner. Let n be the length
in octets of the input. Pad the input by appending 8-(n mod 8)
octets to the end of the message, each having the value 8-(n mod 8),
the number of octets being added. In hexadecimal, the possible
paddings are: 01, 0202, 030303, 04040404, 0505050505, 060606060606,
07070707070707, and 0808080808080808. All input is padded with 1 to
8 octets to produce a multiple of 8 octets in length. The padding
can be removed unambiguously after decryption.


Только то ж про DES CBC, а про rc2 там - ни слова. Вот, кстати, --> Сам стандарт <--

-----
Stuck to the plan, always think that we would stand up, never ran.

| Сообщение посчитали полезным:

ARCHANGEL
сейчас не помню, но есть сайт со всеми PKCS - RFC пдфами. последний раз лазил по смарткартам, давно было. да, дотнетовское криптоапи отличается от нативного. это так, на будущее. портов нет -> натив не видел - если кто покажет, буду признателен. рипать туекучу из нетлиб нет желания

-----
От многой мудрости много скорби, и умножающий знание умножает печаль

| Сообщение посчитали полезным:

ajax
да, дотнетовское криптоапи отличается от нативного. это так, на будущее

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

-----
Stuck to the plan, always think that we would stand up, never ran.

| Сообщение посчитали полезным:

Смотрите RFC 2898 (PKCS 5). Можно еще википедию любить.

-----
старый пень

| Сообщение посчитали полезным: ARCHANGEL

r_e

Ну да, вот оно:


4. Concatenate M and a padding string PS to form an encoded
message EM:

EM = M || PS ,

where the padding string PS consists of 8-(||M|| mod 8) octets
each with value 8-(||M|| mod 8). The padding string PS will
satisfy one of the following statements:

PS = 01, if ||M|| mod 8 = 7 ;
PS = 02 02, if ||M|| mod 8 = 6 ;
...
PS = 08 08 08 08 08 08 08 08, if ||M|| mod 8 = 0.

The length in octets of the encoded message will be a multiple
of eight and it will be possible to recover the message M
unambiguously from the encoded message. (This padding rule is
taken from RFC 1423 [3].)


-----
Stuck to the plan, always think that we would stand up, never ran.

| Сообщение посчитали полезным:

ARCHANGEL пишет:
неужто кейген на дотнете у меня замутить не получится?
получится, почему бы нет. только программить на дотнете придется. там паддинг своеобразный

-----
От многой мудрости много скорби, и умножающий знание умножает печаль

| Сообщение посчитали полезным:

ajax
Я не так выразился. У меня софт написан на Borland C++, но там так много гемороя с кейгеннингом, что захотел я себе это дело немного упростить, а потому решил юзать дотнет с С#. Так вот получается, что работу с криптопровайдерами я буду либо реализовывать вручную (DllImport мне в помощь), либо просто не получится реализовать никак. Я правильно вас понимаю?

-----
Stuck to the plan, always think that we would stand up, never ran.

| Сообщение посчитали полезным:

ARCHANGEL
the .net framework crypto adds a random crypto header to it, its more secure. its agains plaintext attacks

-----
От многой мудрости много скорби, и умножающий знание умножает печаль

| Сообщение посчитали полезным:

ajax
Тогда не пойму логики, как же оно может работать. Вот беру я какие-то свои данные, криптую, а оно мне рандомный заголовок туда всунуло, потом я декриптую, а у меня какая-то хрень вместо ожидаемых данных, так что ли? Да ну это ж гон!

-----
Stuck to the plan, always think that we would stand up, never ran.

| Сообщение посчитали полезным: