eXeLab
eXeL@B ВИДЕОКУРС !

ВИДЕОКУРС ВЗЛОМ
обновлён 2 декабря!


УЗНАТЬ БОЛЬШЕ >>
Домой | Статьи | RAR-cтатьи | FAQ | Форум | Скачать | Видеокурс
Новичку | Ссылки | Программирование | Интервью | Архив | Связь

Русский / Russian English / Английский

Сейчас на форуме: SDK, ZX3000GT1 (+1 невидимый пользователь)
 · Начало · Статистика · Регистрация · Поиск · ПРАВИЛА ФОРУМА · Язык · RSS · SVN ·

 eXeL@B —› Крэки, обсуждения —› Крякми однако :)
Посл.ответ Сообщение


Ранг: 55.6 (постоянный)
Статус: Участник

Создано: 27 июля 2019 12:51 · Поправил: BlackCode New!
Цитата · Личное сообщение · #1

Всем привет.
Попался тут мне интересный крякми.
Судя по последнему изменению файла (31 ‎января ‎2010 ‎г) ему уже почти 9 лет.
Задача создать файл ключа, который расшифрует кусок кода вместе с символьной строкой (сообщение об успешном решении).
Забегу немного вперед. После анализа кода, а его в крякми не так много, склоняюсь к мнению, что решения не существует.
Т.е. алгоритм расшифровки кода не обратим. Возможно я заблуждаюсь, хотя вряд ли.
Далее.
Крякми консольный, упакован UPX 1.90. При запуске открывается окно созданное GetOpenFileNameA для выбора файла ключа.
На OEP в стек записывается 55 байт, которые в последствии должны быть преобразованы для расшифровки кода методом перекторивания.
Code:
  1. <004010E0h>
  2.          sub esp, 1ACh
  3.          push 15Ch
  4.          lea eax, ss:[esp+54h]
  5.          push 0h
  6.          push eax
  7.          mov byte ptr ss:[esp+10h], Ch
  8.          mov byte ptr ss:[esp+11h], 1Fh
  9.          mov byte ptr ss:[esp+12h], 1Bh
  10.          mov byte ptr ss:[esp+13h], 4h
  11.          mov byte ptr ss:[esp+14h], 17h
  12.          mov byte ptr ss:[esp+15h], 1Ah
  13.          mov byte ptr ss:[esp+16h], 7h
  14.          mov byte ptr ss:[esp+17h], 2Ah
  15.          mov byte ptr ss:[esp+18h], 1Ch
  16.          mov byte ptr ss:[esp+19h], 34h
  17. ; ======== skiped =======


В стеке это выглядит так
Code:
  1. 0019FDCC   0C 1F 1B 04 17 1A 07 2A 1C 34 02 30 35 32 14 15  .......*.4.052..  
  2. 0019FDDC   0F 03 10 28 36 26 05 31 2D 11 01 19 0D 27 23 29  ...(6&.1-....'#)
  3. 0019FDEC   21 1E 2F 24 12 1D 09 06 20 2C 13 18 22 2E 0B 25  !./$.... ,.."..%
  4. 0019FDFC   08 0E 16 2B 33 0A 00 


Преобразование этих данных происходит путем перестановки байт относительно второго массива данных размером 192 байта
Code:
  1. 00404000   00 00 1E 2B 00 2C 2D 0A 00 21 00 00 00 0D 2E 24  ...+.,-..!.....$  
  2. 00404010   00 2F 10 30 03 2D 00 2A 27 13 00 06 00 00 00 16  ./.0.-.*'.......
  3. 00404020   30 09 00 33 19 36 0C 27 00 26 25 1C 00 0F 00 00  0..3.6.'.&%.....
  4. 00404030   00 1F 36 12 00 35 22 34 15 25 00 28 2B 01 00 18  ..6..5"4.%.(+...
  5. 00404040   00 00 00 04 34 1B 00 31 07 2E 1C 15 00 14 13 0C  ....4..1........  
  6. 00404050   00 1D 00 00 00 0B 01 1E 00 02 0A 03 24 07 00 08  ............$...  
  7. 00404060   09 10 00 23 00 00 00 11 1B 22 00 1A 12 19 1D 28  ...#.....".....(
  8. 00404070   00 29 2A 0B 00 20 00 00 00 0E 31 23 00 32 11 33  .)*.. ....1#.2.3  
  9. 00404080   02 2C 00 29 26 14 00 05 00 00 00 17 2F 08 00 32  .,.)&......./..2  
  10. 00404090   1A 35 1F 18 00 17 16 0F 00 20 00 00 00 0E 04 21  .5....... .....!  
  11. 004040A0   00 05 0D 06 00 00 00 00 00 00 00 00 00 00 00 00  ................  
  12. 004040B0   4E E6 40 BB B1 19 BF 44 20 05 93 19 00 00 00 00  N&#230;@»±.&#191;D .......

Данные файла ключа, в процессе модификации первого массива играют роль управляющих перестановкой байт.
Размер данных ключа максимально 200 байт.
Данные ключа, судя по коду, считываются по 2 байта, т.е. 1 байт управление, 2 байт типа флага (проверяется символ "=")
Как пример, 1=2=3=4=5... или отличный от "=" символ, к примеру "+", может получиться что-то в виде этого 1=2+3=4+5+6=... и т.д.

После преобразования первого массива, считаться CRC этого массива.
Я свернул, алго CRC, ибо он в оригинале в 8 раз больше)
Code:
  1. CRCMod proc uses ebx ecx edx esi edi lpBuffer,dwSize
  2.  
  3.          or ebx,-1
  4.          mov edx,dwSize
  5.          mov esi,lpBuffer
  6.     .repeat
  7.         lodsb
  8.         movzx eax,al
  9.          xor ebx,eax
  10.          dec edx
  11.          mov edi,8
  12.          .repeat
  13.             .if bl & 1
  14.                   shr ebx,1
  15.                   xor ebx,0EDB88320h
  16.             .else
  17.                 shr ebx,1
  18.             .endif
  19.         dec edi
  20.         .until !edi
  21.          inc ecx
  22.     .until !edx
  23.     return ebx
  24.  
  25. CRCMod endp

Как видно,что в алго используется константа 0EDB88320h из CRC32Table находящейся в середине таблицы.
Далее, значение CRC и данные из первого преобразованного массива перексориваются с данными зашифрованного кода.
Code:
  1. 00401000   CC 11 76 6E ED BF 14 43 9E EF 19 20 57 F1 DF B0  &#204;.vn&#237;&#191;.C.&#239;. W&#241;&#223;°
  2. 00401010   6F 3D 14 CD 65 0E 2D 1A CD 79 20 F3 38 E0 17 84  o=.&#205;e.-.&#205;y &#243;8&#224;..
  3. 00401020   C5 C8 22 7A DE F1 22 21 28 CD 16 05 1C 98 E9 D5  &#197;&#200;"z&#222;&#241;"!(&#205;....&#233;&#213;
  4. 00401030   4E B7 15 A3 83 7F 53 C3 F6 35 63 27 50 C7 FC 2C  N·.&#163;..S&#195;&#246;5c'P&#199;&#252;,
  5. 00401040   B7 19 2F 48 7D AF 6E 3C B8 90 7A 2B 32 24 46 3E  ·./H}&#175;n<&#184;.z+2$F>
  6. 00401050   90 2E A1 D3 61 45 EA 39 0A 6A 96 D9 A9 23 BD 61  ..&#161;&#211;aE&#234;9.j.&#217;©#&#189;a
  7. 00401060   41 33 E6 82 F7 50 57 F7 73 6A 94 18 08 2E 06 AB  A3&#230;.&#247;PW&#247;sj.....«
  8. 00401070   47 4A 8A D6 3C 87 38 05 FD D6 AC E8 1F 66 49 05  GJ.&#214;<.8.&#253;&#214;¬&#232;.fI.
  9. 00401080   7C BB 1A E0 AA D3 FB 02 4D 69 74 3D FA A0 57 D4  |».&#224;&#170;&#211;&#251;.Mit=&#250; W&#212;
  10. 00401090   14 E9 92 DA C4 0A 11 D7 AB AF 7B C7 66 8D 95 E7  .&#233;.&#218;&#196;..&#215;«&#175;{&#199;f..&#231;
  11. 004010A0   5E 1E 8F F6 1E F7 7E EC ED 83 B5 E6 BB 9E 7F D8  ^..&#246;.&#247;~&#236;&#237;.µ&#230;»..&#216;
  12. 004010B0   43 EC 65 D1 37 26 2F D1 F5 9C 79 F1 C0 84 A8 53  C&#236;e&#209;7&/&#209;&#245;.y&#241;&#192;.&#168;S
  13. 004010C0   D4 39 16 46 5C C7 0E 0F 42 7A 86 DE 0E 5B 11 8F  &#212;9.F\&#199;..Bz.&#222;.[..
  14. 004010D0   54 35 0E 91 <- Это эталонный CRC


В крадце, перексор выглядит так...
Code:
  1. <0040159Bh>
  2.          mov edx, 401000h ; <- Указатель на расшифровываемый код
  3. @L00000001:
  4.          mov ebx, dword ptr ss:[esp+ecx*4h+10h] ; <- Выборка из массива преобразованного выше и от которого был посчитан CRC
  5.          xor ebx, edi ; <- В edi значение рассчитанного CRC
  6.          xor ebx, dword ptr ds:[edx]
  7.          inc ecx
  8.          mov edi, ebx
  9.          mov dword ptr ds:[edx], edi
  10.          cmp ecx, Dh
  11.          jb short @L00000002
  12.          xor ecx, ecx
  13. @L00000002:
  14.          add edx, 4h
  15.          sub eax, 1h ; <- счетчик
  16.          jne short @L00000001


После преведенного цикла расшифровки, от полученного кода считается CRC тем же алго, что привел выше.
И сравнивается с эталонным CRC 910E3554h.
Если CRC совпадает, то происходит переход на расшифрованный код.
Code:
  1. <0040165Fh>
  2.          cmp eax, dword ptr ds:[edx]
  3.          jne short @L00000001
  4.          call 00401010h ; <- call в расшифрованный код
  5.          jmp short 00401691h
  6. @L00000001:
  7.          push 0h

Судя по тому, что call у нас на адрес 00401010= 00401000 (базовый) + 16 байт, предпологаю, что в первых 16 байтах содержиться
символьная строка типа "Success...." или "Congratulations..."
А сам расшифрованный код должен выглядеть пиблизительно так..
Code:
  1. <0040166Ah>
  2.          push 0h
  3.          lea eax, ss:[esp+48h]
  4.          push eax
  5.          push 403064h ; <- Указатель на строку
  6.          call dword ptr ds:[lstrlen]
  7.          push eax
  8.          push 403064h ; <- Указатель на строку
  9.          push FFFFFFF5h
  10.          call dword ptr ds:[GetStdHandle]
  11.          push eax
  12.          call dword ptr ds:[WriteFile]
  13.         ret


После всего описанного, у меня только одна мысль - брут ключа, но учитвывая факт размера ключа (200 байт)
и алгоритм подсчета CRC (в силу простоты алго вероятность коллизии очень высока), задача вряд ли выполнимая вообще.

Сам крякми аттачу ниже.

Заранее спасибо за советы, соображения.


{ Атач доступен только для участников форума } - vcrckme1.exe

Ранг: 36.5 (посетитель)
Статус: Участник

Создано: 27 июля 2019 17:48 · Поправил: bartolomeo New!
Цитата · Личное сообщение · #2

в файле должны быть байты от 0х21 до 0х38 - и длина не более 100 символов

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

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



Ранг: 50.4 (постоянный)
Статус: Участник

Создано: 27 июля 2019 21:44 New!
Цитата · Личное сообщение · #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, результат был бы ровно тот же.

восстановленный исходник в аттаче, может кто что заметит, чего я пропустил ;)

{ Атач доступен только для участников форума } - src.c

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



Ранг: 55.6 (постоянный)
Статус: Участник

Создано: 27 июля 2019 22:49 New!
Цитата · Личное сообщение · #4

UniSoft
bartolomeo
Вот и я так и не понял, какой смысл в этом крякми?
Всегда думал, что пишут их, как минимум, для того чтобы на них учились.
Для развития мышления.
И сколько я видел крякмисов, даже сложных, у них всегда было решение.
Мне не понятна мотивация кодера, который это написал.


Ранг: 50.4 (постоянный)
Статус: Участник

Создано: 27 июля 2019 23:57 · Поправил: UniSoft New!
Цитата · Личное сообщение · #5

[del]
была идея но не прокатила...


Ранг: 149.7 (ветеран)
Статус: Участник

Создано: 28 июля 2019 02:31 · Поправил: -=AkaBOSS=- New!
Цитата · Личное сообщение · #6

UniSoft криптоанализ?
По сути, код поксорен дважды:
один раз по двойным словам - правильным црц ключа
второй раз блоками по 0x34 байта - побайтово одним из байтов ключа: 0x00..0x36 без повторов

А вот как дальше быть чёт не соображу. Похоже что некоторые байты в перестановках не участвуют.


Ранг: 50.4 (постоянный)
Статус: Участник

Создано: 28 июля 2019 05:31 New!
Цитата · Личное сообщение · #7

-=AkaBOSS=- пишет:
криптоанализ?

Да как-то лень глубоко вникать...
думаю такой код в реальной жизни не встретишь.

-=AkaBOSS=- пишет:
один раз по двойным словам - правильным црц ключа
второй раз блоками по 0x34 байта - побайтово одним из байтов ключа: 0x00..0x36 без повторов

Если ориентируетесь на восстановленный мной исходник, то я там скосячил в ксоре...
Code:
  1.   idx = 0;
  2.   while (size-- > 0)
  3.   {
  4.     crc = crc ^ *pcode ^ pkey[idx];
  5.     *pcode++ = crc;
  6.     if (++idx >= 13) idx = 0;
  7.   }

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



Ранг: 149.7 (ветеран)
Статус: Участник

Создано: 28 июля 2019 07:29 · Поправил: -=AkaBOSS=- New!
Цитата · Личное сообщение · #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


Ранг: 50.4 (постоянный)
Статус: Участник

Создано: 28 июля 2019 08:53 New!
Цитата · Личное сообщение · #9

множество коллизий...
Code:
  1. Found: "2-8-3-5-1-1-3-2-5-4-8-!"
  2. Found: "2-8-3-5-1-1-3-2-5-8-4-!"
  3. Found: "2-8-3-5-1-3-1-2-5-4-8-!"
  4. Found: "2-8-3-5-1-3-1-2-5-8-4-!"
  5. Found: "2-8-3-5-3-1-1-2-5-4-8-!"
  6. Found: "2-8-3-5-3-1-1-2-5-8-4-!"
  7. Found: "3-1-7-7-5-9-1-6-1-3-7-!"
  8. Found: "3-1-7-7-5-9-1-6-1-7-3-!"
  9. Found: "3-1-7-7-5-9-1-6-3-1-7-!"
  10. Found: "3-1-7-7-5-9-1-6-3-7-1-!"
  11. Found: "3-1-7-7-5-9-1-6-7-1-3-!"
  12. Found: "3-1-7-7-5-9-1-6-7-3-1-!"
  13. Found: "3-1-7-7-6-2-5-9-1-3-7-!"
  14. Found: "3-1-7-7-6-2-5-9-1-7-3-!"
  15. Found: "3-1-7-7-6-2-5-9-3-1-7-!"
  16. Found: "3-1-7-7-6-2-5-9-3-7-1-!"
  17. Found: "3-1-7-7-6-2-5-9-7-1-3-!"
  18. Found: "3-1-7-7-6-2-5-9-7-3-1-!"
  19. Found: "3-1-7-7-6-2-9-5-1-3-7-!"
  20. Found: "3-1-7-7-6-2-9-5-1-7-3-!"
  21. Found: "3-1-7-7-6-2-9-5-3-1-7-!"
  22. Found: "3-1-7-7-6-2-9-5-3-7-1-!"
  23. Found: "3-1-7-7-6-2-9-5-7-1-3-!"
  24. Found: "3-1-7-7-6-2-9-5-7-3-1-!"
  25. Found: "3-1-7-7-9-5-1-6-1-3-7-!"
  26. Found: "3-1-7-7-9-5-1-6-1-7-3-!"
  27. Found: "3-1-7-7-9-5-1-6-3-1-7-!"
  28. Found: "3-1-7-7-9-5-1-6-3-7-1-!"
  29. Found: "3-1-7-7-9-5-1-6-7-1-3-!"
  30. Found: "3-1-7-7-9-5-1-6-7-3-1-!"
  31. Found: "3-7-1-7-5-9-1-6-1-3-7-!"
  32. Found: "3-7-1-7-5-9-1-6-1-7-3-!"
  33. Found: "3-7-1-7-5-9-1-6-3-1-7-!"
  34. Found: "3-7-1-7-5-9-1-6-3-7-1-!"
  35. Found: "3-7-1-7-5-9-1-6-7-1-3-!"
  36. Found: "3-7-1-7-5-9-1-6-7-3-1-!"
  37. Found: "3-7-1-7-6-2-5-9-1-3-7-!"
  38. Found: "3-7-1-7-6-2-5-9-1-7-3-!"
  39. Found: "3-7-1-7-6-2-5-9-3-1-7-!"
  40. Found: "3-7-1-7-6-2-5-9-3-7-1-!"
  41. Found: "3-7-1-7-6-2-5-9-7-1-3-!"
  42. Found: "3-7-1-7-6-2-5-9-7-3-1-!"
  43. Found: "3-7-1-7-6-2-9-5-1-3-7-!"
  44. Found: "3-7-1-7-6-2-9-5-1-7-3-!"
  45. Found: "3-7-1-7-6-2-9-5-3-1-7-!"
  46. Found: "3-7-1-7-6-2-9-5-3-7-1-!"
  47. Found: "3-7-1-7-6-2-9-5-7-1-3-!"
  48. Found: "3-7-1-7-6-2-9-5-7-3-1-!"
  49. Found: "3-7-1-7-9-5-1-6-1-3-7-!"
  50. Found: "3-7-1-7-9-5-1-6-1-7-3-!"
  51. Found: "3-7-1-7-9-5-1-6-3-1-7-!"
  52. Found: "3-7-1-7-9-5-1-6-3-7-1-!"
  53. Found: "3-7-1-7-9-5-1-6-7-1-3-!"
  54. Found: "3-7-1-7-9-5-1-6-7-3-1-!"
  55. Found: "3-7-7-1-5-9-1-6-1-3-7-!"
  56. Found: "3-7-7-1-5-9-1-6-1-7-3-!"
  57. Found: "3-7-7-1-5-9-1-6-3-1-7-!"
  58. Found: "3-7-7-1-5-9-1-6-3-7-1-!"
  59. Found: "3-7-7-1-5-9-1-6-7-1-3-!"
  60. Found: "3-7-7-1-5-9-1-6-7-3-1-!"
  61. Found: "3-7-7-1-6-2-5-9-1-3-7-!"
  62. Found: "3-7-7-1-6-2-5-9-1-7-3-!"
  63. Found: "3-7-7-1-6-2-5-9-3-1-7-!"
  64. Found: "3-7-7-1-6-2-5-9-3-7-1-!"
  65. Found: "3-7-7-1-6-2-5-9-7-1-3-!"
  66. Found: "3-7-7-1-6-2-5-9-7-3-1-!"
  67. Found: "3-7-7-1-6-2-9-5-1-3-7-!"
  68. Found: "3-7-7-1-6-2-9-5-1-7-3-!"
  69. Found: "3-7-7-1-6-2-9-5-3-1-7-!"
  70. Found: "3-7-7-1-6-2-9-5-3-7-1-!"
  71. Found: "3-7-7-1-6-2-9-5-7-1-3-!"
  72. Found: "3-7-7-1-6-2-9-5-7-3-1-!"
  73. Found: "3-7-7-1-9-5-1-6-1-3-7-!"
  74. Found: "3-7-7-1-9-5-1-6-1-7-3-!"
  75. Found: "3-7-7-1-9-5-1-6-3-1-7-!"
  76. Found: "3-7-7-1-9-5-1-6-3-7-1-!"
  77. Found: "3-7-7-1-9-5-1-6-7-1-3-!"
  78. Found: "3-7-7-1-9-5-1-6-7-3-1-!"

Все CRC сходятся но код не верно дешифрован...


Ранг: 81.8 (постоянный)
Статус: Участник

Создано: 28 июля 2019 10:20 New!
Цитата · Личное сообщение · #10

это не крекми это больше похоже на часть коммерческого ПО ,у Лейбаратории Касперского были похожие проверки ,для устройства к ним в штат.может это одна из них?
 eXeL@B —› Крэки, обсуждения —› Крякми однако :)

Оригинальный DVD-ROM: eXeL@B DVD !

Вы находитесь на форуме сайта EXELAB.RU
Проект ReactOS