Крякми однако :)

Сейчас на форуме: vsv1, NIKOLA, r0lka, johnniewalker (+4 невидимых)

Посл.ответ	Сообщение
BlackCode Ранг: 71.5 (постоянный), 95thx Активность: 0.1↗0.38 Статус: Участник	Создано: 27 июля 2019 12:51 · Поправил: BlackCode · Личное сообщение · #1 Всем привет. Попался тут мне интересный крякми. Судя по последнему изменению файла (31 ‎января ‎2010 ‎г) ему уже почти 9 лет. Задача создать файл ключа, который расшифрует кусок кода вместе с символьной строкой (сообщение об успешном решении). Забегу немного вперед. После анализа кода, а его в крякми не так много, склоняюсь к мнению, что решения не существует. Т.е. алгоритм расшифровки кода не обратим. Возможно я заблуждаюсь, хотя вряд ли. Далее. Крякми консольный, упакован UPX 1.90. При запуске открывается окно созданное GetOpenFileNameA для выбора файла ключа. На OEP в стек записывается 55 байт, которые в последствии должны быть преобразованы для расшифровки кода методом перекторивания. Code: <004010E0h> sub esp, 1ACh push 15Ch lea eax, ss:[esp+54h] push 0h push eax mov byte ptr ss:[esp+10h], Ch mov byte ptr ss:[esp+11h], 1Fh mov byte ptr ss:[esp+12h], 1Bh mov byte ptr ss:[esp+13h], 4h mov byte ptr ss:[esp+14h], 17h mov byte ptr ss:[esp+15h], 1Ah mov byte ptr ss:[esp+16h], 7h mov byte ptr ss:[esp+17h], 2Ah mov byte ptr ss:[esp+18h], 1Ch mov byte ptr ss:[esp+19h], 34h ; ======== skiped ======= В стеке это выглядит так Code: 0019FDCC 0C 1F 1B 04 17 1A 07 2A 1C 34 02 30 35 32 14 15 ........4.052.. 0019FDDC 0F 03 10 28 36 26 05 31 2D 11 01 19 0D 27 23 29 ...(6&.1-....'#) 0019FDEC 21 1E 2F 24 12 1D 09 06 20 2C 13 18 22 2E 0B 25 !./$.... ,.."..% 0019FDFC 08 0E 16 2B 33 0A 00 Преобразование этих данных происходит путем перестановки байт относительно второго массива данных размером 192 байта Code: 00404000 00 00 1E 2B 00 2C 2D 0A 00 21 00 00 00 0D 2E 24 ...+.,-..!.....$ 00404010 00 2F 10 30 03 2D 00 2A 27 13 00 06 00 00 00 16 ./.0.-.'....... 00404020 30 09 00 33 19 36 0C 27 00 26 25 1C 00 0F 00 00 0..3.6.'.&%..... 00404030 00 1F 36 12 00 35 22 34 15 25 00 28 2B 01 00 18 ..6..5"4.%.(+... 00404040 00 00 00 04 34 1B 00 31 07 2E 1C 15 00 14 13 0C ....4..1........ 00404050 00 1D 00 00 00 0B 01 1E 00 02 0A 03 24 07 00 08 ............$... 00404060 09 10 00 23 00 00 00 11 1B 22 00 1A 12 19 1D 28 ...#.....".....( 00404070 00 29 2A 0B 00 20 00 00 00 0E 31 23 00 32 11 33 .).. ....1#.2.3 00404080 02 2C 00 29 26 14 00 05 00 00 00 17 2F 08 00 32 .,.)&......./..2 00404090 1A 35 1F 18 00 17 16 0F 00 20 00 00 00 0E 04 21 .5....... .....! 004040A0 00 05 0D 06 00 00 00 00 00 00 00 00 00 00 00 00 ................ 004040B0 4E E6 40 BB B1 19 BF 44 20 05 93 19 00 00 00 00 Næ@»±.¿D ....... Данные файла ключа, в процессе модификации первого массива играют роль управляющих перестановкой байт. Размер данных ключа максимально 200 байт. Данные ключа, судя по коду, считываются по 2 байта, т.е. 1 байт управление, 2 байт типа флага (проверяется символ "=") Как пример, 1=2=3=4=5... или отличный от "=" символ, к примеру "+", может получиться что-то в виде этого 1=2+3=4+5+6=... и т.д. После преобразования первого массива, считаться CRC этого массива. Я свернул, алго CRC, ибо он в оригинале в 8 раз больше) Code: CRCMod proc* uses ebx ecx edx esi edi lpBuffer,dwSize or ebx,-1 mov edx,dwSize mov esi,lpBuffer .repeat lodsb movzx eax,al xor ebx,eax dec edx mov edi,8 .repeat .if bl & 1 shr ebx,1 xor ebx,0EDB88320h .else shr ebx,1 .endif dec edi .until !edi inc ecx .until !edx return ebx CRCMod endp Как видно,что в алго используется константа 0EDB88320h из CRC32Table находящейся в середине таблицы. Далее, значение CRC и данные из первого преобразованного массива перексориваются с данными зашифрованного кода. Code: 00401000 CC 11 76 6E ED BF 14 43 9E EF 19 20 57 F1 DF B0 Ì.vní¿.C.ï. Wñß° 00401010 6F 3D 14 CD 65 0E 2D 1A CD 79 20 F3 38 E0 17 84 o=.Íe.-.Íy ó8à.. 00401020 C5 C8 22 7A DE F1 22 21 28 CD 16 05 1C 98 E9 D5 ÅÈ"zÞñ"!(Í....éÕ 00401030 4E B7 15 A3 83 7F 53 C3 F6 35 63 27 50 C7 FC 2C N·.£..SÃö5c'PÇü, 00401040 B7 19 2F 48 7D AF 6E 3C B8 90 7A 2B 32 24 46 3E ·./H}¯n<¸.z+2$F> 00401050 90 2E A1 D3 61 45 EA 39 0A 6A 96 D9 A9 23 BD 61 ..¡ÓaEê9.j.Ù©#½a 00401060 41 33 E6 82 F7 50 57 F7 73 6A 94 18 08 2E 06 AB A3æ.÷PW÷sj.....« 00401070 47 4A 8A D6 3C 87 38 05 FD D6 AC E8 1F 66 49 05 GJ.Ö<.8.ýÖ¬è.fI. 00401080 7C BB 1A E0 AA D3 FB 02 4D 69 74 3D FA A0 57 D4 \|».àªÓû.Mit=ú WÔ 00401090 14 E9 92 DA C4 0A 11 D7 AB AF 7B C7 66 8D 95 E7 .é.ÚÄ..×«¯{Çf..ç 004010A0 5E 1E 8F F6 1E F7 7E EC ED 83 B5 E6 BB 9E 7F D8 ^..ö.÷~ìí.µæ»..Ø 004010B0 43 EC 65 D1 37 26 2F D1 F5 9C 79 F1 C0 84 A8 53 CìeÑ7&/Ñõ.yñÀ.¨S 004010C0 D4 39 16 46 5C C7 0E 0F 42 7A 86 DE 0E 5B 11 8F Ô9.F\Ç..Bz.Þ.[.. 004010D0 54 35 0E 91 <- Это эталонный CRC В крадце, перексор выглядит так... Code: <0040159Bh> mov edx, 401000h ; <- Указатель на расшифровываемый код @L00000001: mov ebx, dword ptr ss:[esp+ecx4h+10h] ; <- Выборка из массива преобразованного выше и от которого был посчитан CRC xor* ebx, edi ; <- В edi значение рассчитанного CRC xor ebx, dword ptr ds:[edx] inc ecx mov edi, ebx mov dword ptr ds:[edx], edi cmp ecx, Dh jb short @L00000002 xor ecx, ecx @L00000002: add edx, 4h sub eax, 1h ; <- счетчик jne short @L00000001 После преведенного цикла расшифровки, от полученного кода считается CRC тем же алго, что привел выше. И сравнивается с эталонным CRC 910E3554h. Если CRC совпадает, то происходит переход на расшифрованный код. Code: <0040165Fh> cmp eax, dword ptr ds:[edx] jne short @L00000001 call 00401010h ; <- call в расшифрованный код jmp short 00401691h @L00000001: push 0h Судя по тому, что call у нас на адрес 00401010= 00401000 (базовый) + 16 байт, предпологаю, что в первых 16 байтах содержиться символьная строка типа "Success...." или "Congratulations..." А сам расшифрованный код должен выглядеть пиблизительно так.. Code: <0040166Ah> push 0h lea eax, ss:[esp+48h] push eax push 403064h ; <- Указатель на строку call dword ptr ds:[lstrlen] push eax push 403064h ; <- Указатель на строку push FFFFFFF5h call dword ptr ds:[GetStdHandle] push eax call dword ptr ds:[WriteFile] ret После всего описанного, у меня только одна мысль - брут ключа, но учитвывая факт размера ключа (200 байт) и алгоритм подсчета CRC (в силу простоты алго вероятность коллизии очень высока), задача вряд ли выполнимая вообще. Сам крякми аттачу ниже. Заранее спасибо за советы, соображения. 17f0_27.07.2019_EXELAB.rU.tgz - vcrckme1.exe

bartolomeo Ранг: 42.8 (посетитель), 16thx Активность: 0.02↗0.06 Статус: Участник	Создано: 27 июля 2019 17:48 · Поправил: bartolomeo · Личное сообщение · #2 в файле должны быть байты от 0х21 до 0х38 - и длина не более 100 символов я думаю должна быть какаято подсказка о содержимом на выходе, иначе действительно невозможно \| Сообщение посчитали полезным: BlackCode
UniSoft Ранг: 52.0 (постоянный), 146thx Активность: 0.03↗0.08 Статус: Участник	Создано: 27 июля 2019 21:44 · Личное сообщение · #3 Думаю данный крякми не решаем... если только нет намеренно введенных скрытых уязвимостей, и длинна ключа не маленькая. Ничего особого нет, обычное симметричное шифрование на базе XOR. Пермутация ключа дешифровки зависит от входных данных из файла key.key. Длинна ключа дешифровки 55 символов (последний всегда 0). итого имеем fact(54) = 2,3084369733924138047209274268303e+71 комбинаций, перебрать такое не реально... Восстановить код (208 байт) по crc32, также не реально. Так что, мне кажется это не решаемо (точнее может уйти не реально много времени на брут, а если key.key содержит 100 символов?), Но все это хрень полная, как только станет известна хоть одна составляющая, то все сразу разворачивается. Если станет известно: - содержимое key.key то дальнейшие действия не требуются. - ключ дешифровки, то по нему можно воссоздать key.key - из дешифрованного кода можно восстановить ключ дешифровки, а следовательно и key.key И зачем нужно было так заморачиваться, можно было взять стандартный алго шифрования (RC5, Aes, Des, TEA, XTEA), зашифровать код, а ключ положить в key.key, результат был бы ровно тот же. восстановленный исходник в аттаче, может кто что заметит, чего я пропустил ;) fa2c_27.07.2019_EXELAB.rU.tgz - src.c \| Сообщение посчитали полезным: BlackCode
BlackCode Ранг: 71.5 (постоянный), 95thx Активность: 0.1↗0.38 Статус: Участник	Создано: 27 июля 2019 22:49 · Личное сообщение · #4 UniSoft bartolomeo Вот и я так и не понял, какой смысл в этом крякми? Всегда думал, что пишут их, как минимум, для того чтобы на них учились. Для развития мышления. И сколько я видел крякмисов, даже сложных, у них всегда было решение. Мне не понятна мотивация кодера, который это написал.
UniSoft Ранг: 52.0 (постоянный), 146thx Активность: 0.03↗0.08 Статус: Участник	Создано: 27 июля 2019 23:57 · Поправил: UniSoft · Личное сообщение · #5 [del] была идея но не прокатила...
-=AkaBOSS=- Ранг: 150.3 (ветеран), 175thx Активность: 0.16↘0.07 Статус: Участник	Создано: 28 июля 2019 02:31 · Поправил: -=AkaBOSS=- · Личное сообщение · #6 UniSoft криптоанализ? По сути, код поксорен дважды: один раз по двойным словам - правильным црц ключа второй раз блоками по 0x34 байта - побайтово одним из байтов ключа: 0x00..0x36 без повторов А вот как дальше быть чёт не соображу. Похоже что некоторые байты в перестановках не участвуют.
UniSoft Ранг: 52.0 (постоянный), 146thx Активность: 0.03↗0.08 Статус: Участник	Создано: 28 июля 2019 05:31 · Личное сообщение · #7 -=AkaBOSS=- пишет: криптоанализ? Да как-то лень глубоко вникать... думаю такой код в реальной жизни не встретишь. -=AkaBOSS=- пишет: один раз по двойным словам - правильным црц ключа второй раз блоками по 0x34 байта - побайтово одним из байтов ключа: 0x00..0x36 без повторов Если ориентируетесь на восстановленный мной исходник, то я там скосячил в ксоре... Code: idx = 0; while (size-- > 0) { crc = crc ^ pcode ^ pkey[idx]; pcode++ = crc; if (++idx >= 13) idx = 0; } \| Сообщение посчитали полезным: -=AkaBOSS=-
-=AkaBOSS=- Ранг: 150.3 (ветеран), 175thx Активность: 0.16↘0.07 Статус: Участник	Создано: 28 июля 2019 07:29 · Поправил: -=AkaBOSS=- · Личное сообщение · #8 UniSoft ну я в основном на перестановки смотрел, так что да - алго читал по исходнику получается, что хэшем ксорится только первый дворд, а дальше используются расшифрованные данные предыдущего блока. первое что думал утром проверить, и обломался: Если в оригинале на первых 16 байтах действительно лежит ASCII строка, то в ней каждый старший бит будет снят. В ключе все байты < 0x36, тоесть два старших бита шифруются только за счёт хэша. Однако что-то так не получается... CC11766E 11001100 00010001 01110110 01101110 EDBF1443 11101101 10111111 00010100 01000011 9EEF1920 10011110 11101111 00011001 00100000 57F1DFB0 01010111 11110001 10111111 10110000
UniSoft Ранг: 52.0 (постоянный), 146thx Активность: 0.03↗0.08 Статус: Участник	Создано: 28 июля 2019 08:53 · Личное сообщение · #9 множество коллизий... Code: Found: "2-8-3-5-1-1-3-2-5-4-8-!" Found: "2-8-3-5-1-1-3-2-5-8-4-!" Found: "2-8-3-5-1-3-1-2-5-4-8-!" Found: "2-8-3-5-1-3-1-2-5-8-4-!" Found: "2-8-3-5-3-1-1-2-5-4-8-!" Found: "2-8-3-5-3-1-1-2-5-8-4-!" Found: "3-1-7-7-5-9-1-6-1-3-7-!" Found: "3-1-7-7-5-9-1-6-1-7-3-!" Found: "3-1-7-7-5-9-1-6-3-1-7-!" Found: "3-1-7-7-5-9-1-6-3-7-1-!" Found: "3-1-7-7-5-9-1-6-7-1-3-!" Found: "3-1-7-7-5-9-1-6-7-3-1-!" Found: "3-1-7-7-6-2-5-9-1-3-7-!" Found: "3-1-7-7-6-2-5-9-1-7-3-!" Found: "3-1-7-7-6-2-5-9-3-1-7-!" Found: "3-1-7-7-6-2-5-9-3-7-1-!" Found: "3-1-7-7-6-2-5-9-7-1-3-!" Found: "3-1-7-7-6-2-5-9-7-3-1-!" Found: "3-1-7-7-6-2-9-5-1-3-7-!" Found: "3-1-7-7-6-2-9-5-1-7-3-!" Found: "3-1-7-7-6-2-9-5-3-1-7-!" Found: "3-1-7-7-6-2-9-5-3-7-1-!" Found: "3-1-7-7-6-2-9-5-7-1-3-!" Found: "3-1-7-7-6-2-9-5-7-3-1-!" Found: "3-1-7-7-9-5-1-6-1-3-7-!" Found: "3-1-7-7-9-5-1-6-1-7-3-!" Found: "3-1-7-7-9-5-1-6-3-1-7-!" Found: "3-1-7-7-9-5-1-6-3-7-1-!" Found: "3-1-7-7-9-5-1-6-7-1-3-!" Found: "3-1-7-7-9-5-1-6-7-3-1-!" Found: "3-7-1-7-5-9-1-6-1-3-7-!" Found: "3-7-1-7-5-9-1-6-1-7-3-!" Found: "3-7-1-7-5-9-1-6-3-1-7-!" Found: "3-7-1-7-5-9-1-6-3-7-1-!" Found: "3-7-1-7-5-9-1-6-7-1-3-!" Found: "3-7-1-7-5-9-1-6-7-3-1-!" Found: "3-7-1-7-6-2-5-9-1-3-7-!" Found: "3-7-1-7-6-2-5-9-1-7-3-!" Found: "3-7-1-7-6-2-5-9-3-1-7-!" Found: "3-7-1-7-6-2-5-9-3-7-1-!" Found: "3-7-1-7-6-2-5-9-7-1-3-!" Found: "3-7-1-7-6-2-5-9-7-3-1-!" Found: "3-7-1-7-6-2-9-5-1-3-7-!" Found: "3-7-1-7-6-2-9-5-1-7-3-!" Found: "3-7-1-7-6-2-9-5-3-1-7-!" Found: "3-7-1-7-6-2-9-5-3-7-1-!" Found: "3-7-1-7-6-2-9-5-7-1-3-!" Found: "3-7-1-7-6-2-9-5-7-3-1-!" Found: "3-7-1-7-9-5-1-6-1-3-7-!" Found: "3-7-1-7-9-5-1-6-1-7-3-!" Found: "3-7-1-7-9-5-1-6-3-1-7-!" Found: "3-7-1-7-9-5-1-6-3-7-1-!" Found: "3-7-1-7-9-5-1-6-7-1-3-!" Found: "3-7-1-7-9-5-1-6-7-3-1-!" Found: "3-7-7-1-5-9-1-6-1-3-7-!" Found: "3-7-7-1-5-9-1-6-1-7-3-!" Found: "3-7-7-1-5-9-1-6-3-1-7-!" Found: "3-7-7-1-5-9-1-6-3-7-1-!" Found: "3-7-7-1-5-9-1-6-7-1-3-!" Found: "3-7-7-1-5-9-1-6-7-3-1-!" Found: "3-7-7-1-6-2-5-9-1-3-7-!" Found: "3-7-7-1-6-2-5-9-1-7-3-!" Found: "3-7-7-1-6-2-5-9-3-1-7-!" Found: "3-7-7-1-6-2-5-9-3-7-1-!" Found: "3-7-7-1-6-2-5-9-7-1-3-!" Found: "3-7-7-1-6-2-5-9-7-3-1-!" Found: "3-7-7-1-6-2-9-5-1-3-7-!" Found: "3-7-7-1-6-2-9-5-1-7-3-!" Found: "3-7-7-1-6-2-9-5-3-1-7-!" Found: "3-7-7-1-6-2-9-5-3-7-1-!" Found: "3-7-7-1-6-2-9-5-7-1-3-!" Found: "3-7-7-1-6-2-9-5-7-3-1-!" Found: "3-7-7-1-9-5-1-6-1-3-7-!" Found: "3-7-7-1-9-5-1-6-1-7-3-!" Found: "3-7-7-1-9-5-1-6-3-1-7-!" Found: "3-7-7-1-9-5-1-6-3-7-1-!" Found: "3-7-7-1-9-5-1-6-7-1-3-!" Found: "3-7-7-1-9-5-1-6-7-3-1-!" Все CRC сходятся но код не верно дешифрован...
SDK Ранг: 54.0 (постоянный), 49thx Активность: 0.72↗1.1 Статус: Участник	Создано: 28 июля 2019 10:20 · Личное сообщение · #10 это не крекми это больше похоже на часть коммерческого ПО ,у Лейбаратории Касперского были похожие проверки ,для устройства к ним в штат.может это одна из них?

Для печати