Разработка защиты серийными номерами

CALG_MD5

 

У меня 98-ая, я переделал 2 dword-а в хидере (5->4) и пока работает - почему только в XP ?



У меня просто нет под рукой Win98, на работе и дома, везде стоит Win2003. Не могу протестировать прогу на линейке Win9x, поэтому от греха подальше воткнул в PE header OS_VERSION=5, хотя может на Win98 все будет работать нормально

 

jangle

Гм ... давайте сразу 5 дигиманей, а то зашифрую кусок кода, а ключ(серийник) не дам (правилами это не запрещено) ломайте наздоровье , хотя бы начните с этого TEA

http://www.wasm.ru/forum/files/1440081727__xtea.exe

 

_Chingachguk_

Да, только первых пять байт, думаешь можно попробовать, а смысл?

Вот процедура расшифровки:

Код (Text):

1.          xor     ecx,ecx
2.          xor     edx,edx
3.          mov     esi,table
4.          mov     ebp,sizeof.data
5.          mov     edi,data
6.          mov     cl,byte ptr [esi+100]
7.          mov     dl,byte ptr [esi+101]
8.          test    ebp,ebp
9.          je      exit
10. @@:      inc     ecx
11.          mov     ebx,0FF
12.          and     ecx,ebx
13.          xor     eax,eax
14.          mov     al,byte ptr [esi+ecx]
15.          add     edx,eax
16.          and     edx,ebx
17.          xor     ebx,ebx
18.          mov     bl,byte ptr [esi+edx]
19.          mov     byte ptr [esi+ecx],bl
20.          mov     byte ptr [esi+edx],al
21.          add     al,bl
22.          mov     bl,byte ptr [edi]
23.          mov     al,byte ptr [esi+eax]
24.          xor     bl,al
25.          mov     byte ptr [edi],bl
26.          inc     edi
27.          dec     ebp
28.          jnz     @B
29. exit:

Т.е. ключ строится на основе 5 байт хеша, интересно ключ это и есть table или таблица ещё строится на основе ключа? Я RC4 никогда не разбирал, но если мы догадываемся, что на месте data должен быть стандартный MZ заголовок, то можно попытатся ускорить "подбор"

 

bogrus



Да, только первых пять байт, думаешь можно попробовать, а смысл?



Ну я когда-то баловался этими 5-тью байтами:



http://www.wasm.ru/print.php?article=1023002



Там делается что-то типа RC4_Key=f(5 bytes(MD5(Key))) и далее обычный RC4.



Смысл... только побаловаться... я не люблю все защиты... показать разве что принципиальную возможность за конечное время получить серийный номер (кстати, если это действительно тот самый Office97, то скорее всего найдется Key отличный от Key'я автора )



Кстати, как ты ускоришь перебор на основе знания части шифрованного текста (PE-хидера) ?



Позже посмотрю еще внимательнее, если будет время.



masquer



Биг сенькс.

 

Код (Text):

1. a = x + y     ; x (1-й байт хеша), y(2-й байт хеша)
2. b = table + a
3. c = a + b
4. d = table + c
5. d = 33        ; 7E(1-й байт шифра) xor 4D(ожидаемый результат) = 33

Не, я врядли такие уравнения смогу решить, нам известно только d

 

Код (Text):

1. 33 = 2(table + x + y)

 

Кстати, как ты ускоришь перебор на основе знания части шифрованного текста



Все намного проще, как мне кажется, из TextPAD.exe нам известно:



1) Алгоритм шифровки.

2) Смещение и размер зашифрованного блока кода.

3) CRC32 - расшифрованного кода.

4) Известны первые 2 байта зашифрованного кода - "MZ"



Алгоритм RC4 примерно в 10 раз быстрее , чем DES.

Утверждается, что алгоритм устойчив к дифференциальному и линейному криптоанализу, что в нём нет никаких коротких циклов, и что он в высокой степени нелинеен. RC4 может находиться в ,примерно, 2^1700 возможных состояниях.



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

Однако все не так страшно, поскольку нам известны первые два байта – “MZ”.

И собственно их надо и расшифровывать,



1) Помещаем в переменную X первые два байта зашифрованного кода



2) В цикле перебираем все ключи от 1 до “разумного предела”



3) Расшифровываем два байта в переменной X этим ключом.



4) Если расшифрованный текст = “MZ” значит это жжжж неспроста, переходим в процедуру глобальной расшифровки (6)



5) Закрываем цикл.



6) Расшифровываем весь блок, и проверяем его CRC32, если он совпадает со значением из TextPAD.exe выводи сообщение – “Ключ найден!” , если CRC32 не совпадает, то возвращаемся к пункту 5.





Поскольку в цикле идет расшифровка только 2 байтов, перебор ключей будет идти быстро, и найти “нужный” ключ можно за ограниченное время.

 

jangle Это и ежу понятно, я сейчас от фига делать пытаюсь понять, сколько это может занять времени, вот весь брутфорсер (оптимизнутый, но ещё недоделанный, пока там примерный перебор k1, т.е. инкремент k1, перегенерация таблицы и сверка)

Код (Text):

1. ;=====================================================
2. ;                   k1,k2,k3,k4,k5
3. key         db      0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
4. table:      times   256 db %-1
5. encrypted   file    'encrypted' ; MZ header
6. ;=====================================================
7. entry       $
8.             mov     ebx,table
9. align 16
10. @1:         mov     ebp,0-256
11.             add     byte [key],1
12.             xor     ecx,ecx
13.             xor     eax,eax
14. align 16
15. @@:         movzx   edx,byte [ebx+ebp+256]    ; p2
16.             and     ecx,0Fh                   ; p01
17.             add     al,dl                     ; p01
18.             add     al,byte [key+ecx]         ; p01\p2
19.             movzx   ecx,byte [ebx+eax]        ; p2
20.             mov     byte [ebx+ebp+256],cl     ; p3\p4
21.             mov     byte [ebx+eax],dl         ; p3\p4
22.             inc     ebp                       ; p01
23.             mov     ecx,ebp                   ; p01
24.             jnz     @B                        ; p1
25.             movzx   eax,byte [ebx+1]
26.             add     al,byte [ebx+eax]
27.             mov     al,byte [ebx+eax]
28.             cmp     al,33h
29.             jnz     @1
30. ; k1: 6Fh,8Ch
31. ;=====================================================

Ну польза все-равно будет, от оптимизации RC4 надо будет топик по нему создать

 

jangle



Это все и так ясно, вопрос не в этом



Речь про то, чтобы написать стопроцентный подбиратель для любого серийника. Основанием для возможности существования такого подбирателя служит тот факт, что в офисе97 использовалось 40-битное шифрование, это связано с экспортным законодательством США, изменным в 2000г. Если в твоем коде серийник используется именно так, как он используется в офисе97 - а именно:



RC4_Key=f(5 bytes(MD5(серийник, etc))),



то это можно делать, причем перебирать надо не сам серийник, а именно эти 5 bytes.



Если же серийник используется как ключ для RC4 или же нет обрезания до 5-ти байт (например, в xp), то это выливается в прямую атаку на RC4 и это особого интереса не представляет.



bogrus



Вот мой вариант оптимизации RC4 - из статейки про Excel:

Код (Text):

1. ; Подпрограмма - расшифровать байты по таблице подстановок RC4.
2.  
3. ;*** EDX=len of buff, ecx=offset RC4 Table, stack = buff_addr
4. P309AD416 proc
5.   push ebp         
6.   mov  ebp,esp
7.   push ebx
8.   push esi
9.   push edi         
10.   mov  edi,[ebp+8] ; edi=Адрес буффера
11.   lea  ebp,[edi+edx] ; buff_addr+len_buff
12.   xor  ebx,ebx
13.   xor  edx,edx
14.   mov  bl,[ecx+100h] ; Q1
15.   mov  dl,[ecx+101h] ; Q2
16. @LOOP:
17.   xor  eax,eax
18.   inc  bl
19.   mov  al,[ecx+ebx] ; S[Q1]
20.   add  dl,al
21.   mov  ah,[ecx+edx] ; S[Q2]
22.   mov  [ecx+edx],al
23.   mov  [ecx+ebx],ah
24.   add  al,ah
25.   and  eax,0FFh
26.   mov  al,[ecx+eax]
27.   xor  [edi],al ; xor buffer[edi],gamma
28.   inc  edi
29.   cmp  edi,ebp
30.   jl   @LOOP
31.   mov  bh,dl
32.   mov  [ecx+100h],bx    ; Запомнить счетчик 1,2
33.   pop  edi
34.   pop  esi
35.   pop  ebx
36.   pop  ebp  
37.   ret  4
38. P309AD416 endp

 

jangle

Ну CRC32 тут совсем не поможет, а вот известно скорее больше чем "MZ", стандартный заголовок сильно не отличается, а далеко от его начала брать не надо, там в RC4 итак все повязано-перевязано с самого первого байта, если совпадут хоть первых 5 байт это уже попадание, и _Chingachguk_ прав, скорее серийник возможен не один



_Chingachguk_ k1,k2,k3,k4,k5 из моего кода это 5 байт хеша (всего 128 бит, но для создания таблицы используется только 40 (остальное нули), больше никаких замуток, расшифровка реализовывается тоже в пару тактов)

 

bogrus



Ты точно смотрел, что для создания ключа для RC4 передаются только 5 байт ? В случае с Excel было не так:



RC4_Key=MD5(~5_bytes(MD5(Key))).

 

Передается 16 байт (11 из них нулевые)

k1,k2,k3,k4,k5,0,0,0,0,0,0,0,0,0,0,0



з.ы. MD5 там используется один раз для получения этих пяти байт k1...k5, но MD5 нам нафиг вообще не нужен (разве чтобы из наденого хеша подобрать серийник), главное это подобрать состояние таблицы (она тоже создается всего один раз, так работает ф-ция CryptDeriveKey)

 

Ну CRC32 тут совсем не поможет, а вот известно скорее больше чем "MZ", стандартный заголовок сильно не отличается, а далеко от его начала брать не надо, там в RC4 итак все повязано-перевязано с самого первого байта, если совпадут хоть первых 5 байт это уже попадание



С добавлением каждого байта, время расшифровки увеличивается по экспоненте, 2 байт это уже много! А 5 байтов вообще не реально дождаться при жизни, все таки хоть RC4 и быстрее DES, все равно для такой атаки, работает слишком медленно

 

Это как???



Если у нас есть три байта плэйнтекста, то мы будем в два раза дольше расшифровывать чем при двух известных чтоли??



40 бит (5 байт) вполне перебираемо сегодня. Я пару лет назад считал статистику для RC4 с короткими ключами -- перебирал все 2**40 ключей + для каждого генерировал 1024 байт гаммы + считал вероятности символов. Тогда это заняло около 2-х неедль на 8xP3-800.

 

Дописал уже до 4 байт брутфорс, за 3 минуты понаходил 6 подходящих хешей, которые дают "MZ?0", 3-й байт я пока не учитывал (для него и 5-го нужно собрать статистику по PE заголовкам, 4-й равен нулю), пара хешей:

30,2A,97,01,00

AE,0E,18,02,00

 

а зачем? знаем первый, второй, четвертый. Делаем брутфорс и проверяем на этих. Подходящих хешей будет порядка 2^16 (два "свободных" байта). Вот эти 2^16 хэшей можно перепробовать все и проверять CRC-32 от расшифрованного кода.

 

Это как???

Это я с ключами попутал, вот таблица из книжки по криптографии. Правда они для алгоритма DES, но думаю с RC4 примерно сопоставимо.



Количество возможных ключей в зависимости от ограничений на символы ключевой последовательности



Печатные ASCII символы (95):



3 байта - 2,3*10^7 ключей

4 байта - 8,2*10^7 ключей

5 байтов - 7,8*10^9 ключей

6 байтов - 7,5*10^11 ключей

7 байтов - 7,1*10^13 ключей

8 байтов - 6,7*10^15 ключей





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



Печатные ASCII символы (95):



3 байта - 5 минут

4 байта - 15 минут

5 байтов - 220 часов

6 байтов - 860 дней

7 байтов - 230 лет

8 байтов - 2110 лет





Судя по этим таблицам, перебор ключа до 5 байтов имеет смысл

 

Печатные символы тут не причем, после MD5 их небывает

 

В аттаче пока такой, на скорую ногу брутфорсер, включаю на ночь и лажуся спать

Ищет ключ для 3-х популярных PE заголовков:

Код (Text):

1. 'M','Z',90h,0h,03h
2. 'M','Z',80h,0h,01h
3. 'M','Z',0Ah,0h,02h

Кто желает, можете выбрать себе диапазон перебора

Код (Text):

1. k5 = 0      ; начальное значение (минимум 0)
2. _k5 = 255   ; конечное значение  (максимум 255)

2084018713__bruteforce.zip