/*500A1D3E*/ XOR ESI,ESI
/*500A1D40*/ XOR EAX,EAX
/*500A1D42*/ TEST AL,1
/*500A1D44*/ JE SHORT lol.500A1D5B
/*500A1D46*/ XOR ECX,ECX
/*500A1D48*/ MOV CL,DL
/*500A1D4A*/ SHL ECX,5
/*500A1D4D*/ XOR EBX,EBX
/*500A1D4F*/ MOV BL,AL
/*500A1D51*/ ADD ECX,EBX
/*500A1D53*/ MOVZX ECX,BYTE PTR SS:[ESP+ECX]
/*500A1D57*/ ADD ESI,ECX
/*500A1D59*/ JMP SHORT lol.500A1D6E
/*500A1D5B*/ XOR ECX,ECX
/*500A1D5D*/ MOV CL,DL
/*500A1D5F*/ SHL ECX,5
/*500A1D62*/ XOR EBX,EBX
/*500A1D64*/ MOV BL,AL
/*500A1D66*/ ADD ECX,EBX
/*500A1D68*/ MOVZX ECX,BYTE PTR SS:[ESP+ECX]
/*500A1D6C*/ SUB ESI,ECX
/*500A1D6E*/ INC EAX
/*500A1D6F*/ CMP AL,20
/*500A1D71*/ JNZ SHORT lol.500A1D42
/*500A1D73*/ MOV EAX,ESI
/*500A1D75*/ MOV BYTE PTR SS:[EBP],AL
/*500A1D78*/ INC EDX
/*500A1D79*/ INC EBP
/*500A1D7A*/ CMP DL,8
/*500A1D7D*/ JNZ SHORT lol.500A1D3E

попровьте меня, не ошибся ли я 4то это самопальная надстройка над RC4?

[ESP] - пошифрованый блок от введенного пользователем клю4а

[EBP] - дешифрованый клю4

-----
HOW MUCH BLOOD WOULD YOU SHED TO STAY ALIVE

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

Без кода "базы" определить что там - невозможно.. те. не видно как используется ProTeuS пишет:
дешифрованый клю4
если работа с двумя таблицами по 0х100 байт (перестановки), то в "базе", возможно, и есть RC4.
самому RC4 не важно происхождение ключа.. главное сам ключ и его размерность.


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

вобщем, ситуация такова:

шаг1:
ввожу в проге пароль, он гамируется и переводится в клю4 вида

00A1E7B0 EF 2A BA 75 96 01 00 00 28 5A A1 00 1C 00 00 00 п*єu–
..(ZЎ.... //123456

00A1E7B0 EF 2A BA 75 96 00 4D 00 28 5A A1 00 1C 00 00 00 п*єu–.M.(ZЎ.... //12345

00A220C8 EF 2A BA 75 16 00 00 00 01 00 00 00 07 00 00 00 п*єu...
...... //1234

дальше непосредственно его перестановками создается S-Box на 100h

шаг2: с S-box 8ю циклами по 20 проходов генерируется по одному байту за проход результируещего клю4а

дальше 64байтный клю4 сравнивается с известным эталонным

подмена результата не катит, зада4а - узнать нужный пас под известный коне4ный результат

кто уже имел дело с RC4, просьба истолковать 4то в данном слу4ае будет зашифрованным текстом, а 4то клю4ем(ведь тут юзается шифровка и паралельно дешифровка)

-----
HOW MUCH BLOOD WOULD YOU SHED TO STAY ALIVE

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

ProTeuS пишет:
зада4а - узнать нужный пас под известный коне4ный результат

А это вообще реально? Кроме подбора пока в голову ничего не идет...

-----
-=истина где-то рядом=-

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

вроде как реально, по крайней мере в теории: www.referatcollection.ru/48358.html

а нас4ет брута паролей, то имхо для заданой длинны клю4а и он подойдет (+ 4то RC4 в 10 раз быстрее даже банального DES)

кто 4то посоветует по поводу реализации?

-----
HOW MUCH BLOOD WOULD YOU SHED TO STAY ALIVE

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

ProTeuS пишет:
кто уже имел дело с RC4
Я работал с RС4, но там вроде было все по другому.RC4 - это симметричный шифр, а значит для шифровки и расшифровки используется один и тот же ключ. В моем случае этот ключ "лежал" рядом с шифрованным куском и искать его особо не надо. Обычно Rc4 используется совместно с каким-нибудь ассиметричным алгоритмом, типа RSA (можно и самому что-нить написать). Может у тебя все же не Rc4?

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

[offtop] ProTeuS купи новую клавиатуру [/offtop]

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

>>Может у тебя все же не Rc4?
tar4, уверен 4то именно RC4, т.к. и коли4ество итераций циклов совпадает, и размерность самого S-box и клю4ей.

>>В моем случае этот ключ "лежал" рядом с шифрованным куском и искать его особо не надо. Обычно Rc4 используется совместно с каким-нибудь ассиметричным алгоритмом, типа RSA (можно и самому что-нить написать).
Жаль, но в моем слу4ае клю4а рядом нет, а RC4 юзается только для визуального сокрытия данных в программе, а не для стойкости в со4етании с RSA и другой ассиметрией.

Тоесть результат шифрования сравнивается с эталонным (проге тоже известным), и при подмени джампа всеравно показывается зашифрованные данные, но логи4но, 4то они расшифровываются с совершенно другим клю4ем (поскольку отображаются кракозяблы вместо моей информации)

В моем слу4ае остается только написать брутер, но я пока не представляю как, поскольку таблица на 256 элементом создается не по стандартному алго RC4


{
unsigned char swapByte;
unsigned char index1;
unsigned char index2;
unsigned char* state;
short counter;

state = &key->state[0];
for(counter = 0; counter < 256; counter++)
// S заполняется последовательными значениями от 0...255
state[counter] = counter;
key->x = 0;
key->y = 0;
index1 = 0;
index2 = 0;

for(counter = 0; counter < 256; counter++)
{ // каждый очередной элемент S обменивается местами с элементом
index2 = (key_data_ptr[index1] + state[counter] + index2) % 256;
//номер которого определяется элементом ключа key
//самим элементом и суммой номеров элементов, с которыми происходил об
//мен на предыдущих итерациях.
swap_byte(&state[counter], &state[index2]);
index1 = (index1 + 1) % key_data_len;
}
}


а в перемешку с гаммированым вводимым пасом, тоесь входной клю4евой информацией (логи4но, 4то для каждого разного введенного паса и S-box будеи разный, как и 8быйтный сравниваемый с эталоном результат шифрования)

-----
HOW MUCH BLOOD WOULD YOU SHED TO STAY ALIVE

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

to ProTeuS
ProTeuS пишет:
и размерность самого S-box и клю4ей.
ок, еще раз и по-порядку: в "классическом" RC4 нет понятия "размерность ключей" .. те. нет совсем..
на ключ (который единственный!) нет ограничений. Ограничение на "стойкость" пока не рассматриваем.
Другими словами, ключем считается то, что будет использоваться при заполнении второй таблицы (или S-box), размер и второй и первой (где будет развернута последовательность 0х00 - 0хFF) таблицы 0x100
ProTeuS пишет:
он гамируется и переводится в клю4 вида
00A1E7B0 EF 2A BA 75 96 01 00 00 28 5A A1 00 1C 00 00 00 п*єu–
..(ZЎ.... //123456
00A1E7B0 EF 2A BA 75 96 00 4D 00 28 5A A1 00 1C 00 00 00 п*єu–.M.(ZЎ.... //12345
00A220C8 EF 2A BA 75 16 00 00 00 01 00 00 00 07 00 00 00 п*єu...
...... //1234
дальше непосредственно его перестановками создается S-Box на 100h

ProTeuS пишет:
дальше непосредственно его перестановками создается S-Box на 100h

если в заполнении S-box используется вся гамма то это несколько странно. если все же так и есть на самом деле, то это какая-то доморощенная модификация.. - мутант-с!
хотя вполне понятно, что самым важным элементом является получаемый S-box (точнее его уникальность) и развернутый из него sub-key.. а уж как он (sub-key) получен - не столь важно.

tar4 пишет:
RC4 - это симметричный шифр, а значит для шифровки и расшифровки используется один и тот же ключ. соврешенно верно!

ProTeuS пишет:
В моем слу4ае остается только написать брутер, но я пока не представляю как, поскольку таблица на 256 элементом создается не по стандартному алго RC4

я тоже склюняюсь к мысли, что это некий мутант от RС4.
Основной вывод от этого не изменится - обратить или реконструировать развернутый Sub-key - невозможно.
Но в мутанте есть слабость - заполнение S-box {если я все правильно понял}.
Тогда возможно это позволит сократить размерность входного потока для перебора с максимального 0х100 до может быть какого-то разумного (10-15 элементов). Тут есть шанс на успех. Это зависит от алго заполнения S-box в мутанте.
а если известен или прогнозируется формат
ProTeuS пишет:
в проге пароль
то задача существенно упрощается!
тем более, что для перебора не интересен алго, важен - результат

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

Вроде, то что ты пишешь, похоже на Rc4. Но многое остается непонятным и поэтосму трудно дать какой-нибудь дельный совет.
ProTeuS пишет:
Дальше 64байтный клю4 сравнивается с известным эталонным
Зачем? Если шифрованный блок расшифрован не верно, то зачем что-то потом сравнивать? В помощь крякеру?
ProTeuS пишет:
дальше 64байтный клю4 сравнивается с известным эталонным
8быйтный сравниваемый с эталоном результат шифрования)

Т.е. шифрованный блок размером 8 байт? Или 64 байта?
Подключ Rc4 - 100h. Еще должен на вход подаваться ключ, предварительно обработанный какой-нить хэш-функцией. Ты ее нашел?

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

tar4 пишет:
ProTeuS пишет:
Дальше 64байтный клю4 сравнивается с известным эталонным
Зачем? Если шифрованный блок расшифрован не верно, то зачем что-то потом сравнивать? В помощь крякеру?
да, это место требует пояснений.
на мой взгляд - проще или весь код показать или таргер озвучить ...
можно в РМ.. если есть какие-то публичные противопоказания.

tar4 пишет:
Еще должен на вход подаваться ключ, предварительно обработанный какой-нить хэш-функцией. Ты ее нашел?
это не обязательно - как один из способой достяжения "уникальности" ключа -> S-box -> Sub-key - соглашусь. но как обязательное требование - это перебор


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

DMD, tar4, сенкс за советы

DMD, видимо ты таки прав.
на мысли о мутанте RC4 наводит как минимум заполнени сбокса не индексами первона4ально (как в оригинале), а с помощью инвертированного гамированного пароля с конца (от 255ого и до 0ого байта) и разницы в коли4естве проходов (+ 4то сбокс только один?).

проблема в том, 4то реверсить довольно объемный код (просто так рипнуть не удасться, код разветвленный, замусоренный делфовым компилером и FPU-операциями) сложновато и долго(видимо авторы не ставили себе цель юзать конкретно RC4, а на основе него сделали 4то-то другое, возможно думая 4то это затруднит криптоанализ\реверсинг функции шифрования\брут), так же как и непосильно по трудозатратам для данного шифра найти статисти4еские закономерности для "уменьшения" разрядности сбокса дл минимально брутимой.

Пока4то напрашивается только 1 самый логи4ный и быстрый выход, в результати реверсинга конкретной проги инжектнуть в процесс формирования гаммы по клю4у либой, которая будет брутить все возможные варианты паса и передавать упарвление на mutanted_RC4(brutable_pass), сравнивая подс4итанное зна4ение с эталонным
>>Еще должен на вход подаваться ключ, предварительно обработанный какой-нить хэш-функцией.
(он генерится именно по введенному пароля), инициализации таблицы шифра, шифрования и проверки с эталоном
>>Зачем? Если шифрованный блок расшифрован не верно, то зачем что-то потом сравнивать? В помощь крякеру?
дело в том, 4то проверка хоть и есть, но всеравно сравнивает только эталлонный коне4ный клю4 и дешифрованный. тоесть даже при подмене результатов расшифровка нужной инфы происходит, но, 4то логи4но, никаких 4итабельных буков там нет, поскольку при дешифровки их использовалась не соответствующая эталонному паролю S-box

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

-----
HOW MUCH BLOOD WOULD YOU SHED TO STAY ALIVE

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

ProTeuS пишет:
разницы в коли4естве проходов (+ 4то сбокс только один?).
в "классике" есть две таблицы по 0х100 и 0х100 "проходов"
Sub-key - разворачивается в одной из таблиц и всегда один.

ProTeuS пишет:
в результати реверсинга конкретной проги инжектнуть в процесс формирования гаммы по клю4у либой, которая будет брутить все возможные варианты паса и передавать упарвление на mutanted_RC4(brutable_pass), сравнивая подс4итанное зна4ение с эталонным
инжект + перемещение по коду + почти наверняка под отладчиком = огромные потери времени.
проще или рипнуть или переписать самому мутанта + гаммирование + сравнение.. + брут.
и пользительно и быстрее получится!

ProTeuS пишет:
так же как и непосильно по трудозатратам для данного шифра найти статисти4еские закономерности для "уменьшения" разрядности сбокса дл минимально брутимой.
это есть заблуждение.
я уже показывал возможную слабость мутанта. Но есть "НО"..

если есть более-менее явная проверка разрядности пароля или анализ гаммирования покажут размерность ключа > ~10 символов, то об буте можно просто забыть (хотя.. все нужно пробовать!.. :s1.
при размерности от 12-15 разрядов и словаре english letters + цифры перебор может потребовать время сравнимое с геогическим. Вопрос будет в алгоритме обработки.. точнее, времени его выполнения. те. "в довесок" вопрос оптимизации брута и, возможно, мутантского алго...
Можешь быть я и несколько утрирую, но можешь примерный случай полюбопытствовать сам:
http://exelab.ru/art/?action=view&id=258

Паралленьные вычисления, конечно, никто не отменял, но где взять столько компов или найти помощников?!

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

DMD пишет:
инжект + перемещение по коду + почти наверняка под отладчиком = огромные потери времени.
проще или рипнуть или переписать самому мутанта + гаммирование + сравнение.. + брут.
и пользительно и быстрее получится!

брутер написал, но вот незада4а, 4то несмотря на мой код брутера в 20байт, говонокод делфового компилера и ОГРОМНОЕ коли4ество неопимального кода с подфункциями для генерации клю4а в исследованой проге, брутиться не больше 500-1000 комбинация в секунду (да и брутимая прога вылетает от переполнения ресурсов после перебора нескольких десятком тыся4 пасов).

>>http://exelab.ru/art/?action=view&id=258
реверсинг алго я сразу же откинул(не в премер проге по ссылке), увидив объем реверсируемого код (за разумное время имхо его не обратить((( ).

>>Паралленьные вычисления, конечно, никто не отменял, но где взять столько компов или найти помощников?!
по моим расс4етам пары недель будет достато4но, если еще 3 машины под рукой будет, то этол мизерное время (останется только побороться с переполнением ресурсов брутимой проги, 4тобы не рестартовать ее с последенй брутимой позиции руками каждый раз)

-----
HOW MUCH BLOOD WOULD YOU SHED TO STAY ALIVE

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

ProTeuS пишет:
брутер написал, но вот незада4а, 4то несмотря на мой код брутера в 20байт, говонокод делфового компилера и ОГРОМНОЕ коли4ество неопимального кода с подфункциями для генерации клю4а в исследованой проге, брутиться не больше 500-1000 комбинация в секунду (да и брутимая прога вылетает от переполнения ресурсов после перебора нескольких десятком тыся4 пасов).

На АСМ нужно писать.. да и трудно поверить в корректный брут в 20байт кода... Лично мне, такое даже при таком объеме алфавита при неизвестной длине еще не удавалось.
Код не покажешь? ПРосто интересно..

Совета никто не спрашивал, но я все же выскажусь: я бы поработал с алго гаммирования и формирования второй таблицы в мутанте (надеюсь, таблица индексов {0х00-0хFF} в наличии и без "мутаций")..
И алго раскрытия sub-key тоже требует убедиться в его "чистоте".
И уж потом брался бы за брут...

Но это сугубо личное дело ..

Успехов!

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

DMD пишет:
На АСМ нужно писать.. да и трудно поверить в корректный брут в 20байт кода... Лично мне, такое даже при таком объеме алфавита при неизвестной длине еще не удавалось.
Код не покажешь? ПРосто интересно..

004031E4 8B3D B0F11200 MOV EDI,DWORD PTR DS:[12F1B0] ;буфер с брутимым пасом
004031EA 8D1D 7D8B4900 LEA EBX,DWORD PTR DS:[498B7D] ;буфер с чарсетом
004031F0 0FB607 MOVZX EAX,BYTE PTR DS:[EDI]
004031F3 D7 XLAT BYTE PTR DS:[EBX+AL]
004031F4 3C 00 CMP AL,0
004031F6 74 04 JE SHORT bruted.004031FC
004031F8 8807 MOV BYTE PTR DS:[EDI],AL
004031FA EB 04 JMP SHORT bruted.00403200
004031FC D7 XLAT BYTE PTR DS:[EBX+AL]
004031FD AA STOS BYTE PTR ES:[EDI]
004031FE ^74 F0 JE SHORT bruted.004031F0

дамп таблицы
00498B7D 61 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F aabcdefghijklmno
00498B8D 70 71 72 73 74 75 76 77 78 79 7A 30 31 32 33 34 pqrstuvwxyz01234
00498B9D 35 36 37 38 39 00 00 00 00 00 00 00 00 00 00 00 56789...........
00498BAD 31 32 33 34 35 36 37 38 39 00 00 00 00 00 00 00 123456789.......
00498BBD 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00498BCD 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00498BDD 00 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 .bcdefghijklmnop
00498BED 71 72 73 74 75 76 77 78 79 7A 30 00 qrstuvwxyz0.

самый отпимальный цикли4еский брут, быстрее уж никак


>>Совета никто не спрашивал, но я все же выскажусь: я бы поработал с алго гаммирования и формирования второй таблицы в мутанте (надеюсь, таблица индексов {0х00-0хFF} в наличии и без "мутаций")..
И алго раскрытия sub-key тоже требует убедиться в его "чистоте".
И уж потом брался бы за брут...

2 таблицы нет ) видимо когда запущу брут на паре машин при нали4ии времени какрас буду расбираться с реверсингом самого кариптоалго, мож 4то и выйдет (

-----
HOW MUCH BLOOD WOULD YOU SHED TO STAY ALIVE

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

ProTeuS пишет:
2 таблицы нет )
Стоп! а как тогда.. точнее, с чего это вдруг, речь пошла о RC4?!

Я, конечно, могу предположить что процесс происходит примерно так:
неким самопальным образом формируется таблица N-размера из гаммы пассворда, которую обозвали S-box.. {отсутствие второй таблицы размером так же N существенно ослабляет стойкость всего алгоритма расшифровки даже для мутанта RC4}
с помощью этой таблицы расшифровываются данные (длиной K, причем <N и это существенно!),
алго расшифровки напоминает финальную (третью) часть RC4.
что-то с чем-то сравнивается.. если совпало - good! нет - out.

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

В любом случае, брутить вышепредложенным способом неверно.
Напоминаю о контроле длины пассворда.. как намек о неизвестной длине пассворда => код брута будет куда как сложнее. С учетом увеличения длины пасворда при исчерпании очередной разрядной сетки + новое гаммирование.

Так что, мой совет - внимательно посмотри алго гаммирования пассворда, определи размер условного S-box`а, какие данные расшифровываются , с чем сравниваются (насколько данные для сравнения стабильны).
И особо алго собственно расшифровки..
Без этого пробовать брут - бесполезно и совершенно напрастная потеря времени.

Ну а там видно будет!

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

ProTeuS

гм.. даже для 2001 года "свежести" должно быть стыдно приводить чей-то горячечный бред:

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


Рассматриваемый нами криптоалгоритм RC4 относится к классу потоковых
шифров, которые в последнее время стали популярными благодаря высокой
скорости работы. Потоковые шифры преобразуют открытый текст в шифротекст по
одному биту за операцию. Генератор потока ключей (иногда называемый
генератором с бегущим ключом) выдает поток битов: k1, k2, k3, ..., ki. Этот
поток ключей и поток битов открытого текста, p1, p2, p3, ..., pi,
подвергаются операции “исключающее или", и в результате получается поток
битов шифротекста.
ci =pi ^ ki
При дешифрировании операция XOR выполняется над битами шифротекста и
тем же самым потоком ключей для восстановления битов открытого текста.
pi = ci ^ ki
Безопасность системы полностью зависит от свойств генератора потока
ключей.

Криптогенератор функционирует независимо от открытого текста.
Генератор имеет подстановочную таблицу (S-бокс 8 х 8): S0, S1, . . ., S255.
Входами генератора являются замененные по подстановке числа от 0 до 255, и
эта подстановка является функцией от ключа изменяемой длины. Генератор
имеет два счетчика i и j, инициализируемых нулевым значением.
Для генерации случайного байта гаммы выполняются следующие операции:
i = (i+1) mod 256
j = (j+Si) mod 256
swap (Si, Sj)
t = (Si+Sj) mod 256
K = St


и далее по тексту.. даже описание - и то .. гм.. простите - хреновое..

обратить RC4 просто невозможно - алгоритмическое восстановление потребует:

в каждом элементе S-box возможно FF+1 вариантов ветвлений {без учета выполнения проверочных действий!}, в общем случае получаем дерево с 0х100 ветвями в КАЖДОЙ ТОЧКЕ ветвления (за счет потери переноса)

Время потребуется: ~сравнимо с возрастом Большой Вселенной! (без какой-либо иронии)

так что.....

ps/ а что такое "внутренняя память RC4"?

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

>>если все так, то - да, есть некоторые основания говорить о мутанте. но пока не известно так ли это ?
так и есть

-----
HOW MUCH BLOOD WOULD YOU SHED TO STAY ALIVE

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

ProTeuS пишет:
>>если все так, то - да, есть некоторые основания говорить о мутанте. но пока не известно так ли это ?
так и есть

тогда - Успехов!

по косвенным признакам брут не должен быть сложным по коду.... а вот о времени - это как звезды станут!


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