Code/decode отдельных процедур DLL при вызове

Вот прмитивны вопрос...

хочется сделать небольшую (трудоемкую) защиту

как говорится от непродвинутых юзеров ну например

банальный XOR или OR)) но приминительно к DLL

суть в том чтобы в длл'ке шифровать (ксорить) код

процедурки и при вызове передавать как параметр ключик

ну примерно так себе представляю

Код (Text):

1.  
2. proc TestMessage, nKey, tMessages
3. enter:
4.        mov esi,coded
5. loopz: lodsb
6.        xor eax,nkey
7.        loop loopz:
8.        call coded
9.        return
10. coded:
11.        rb 100h
12.        ret
13. endp
14.  

 

aip

В чем собственно вопрос?

 

aip

А где сохраняется результат, т.е. где stosb?

А где инициализируется ecx? (иначе loop может выйти из под контроля

 

q_q



Вопрос о допустимости работы с секцией кода ДЛЛки

на запись... то есть мой код не вызовет исключения

при попытке записи в секции кода?



Quantum

здесь ни инита eax, ни применения stosb нету ибо

это не код программный а просто для примера примерный

алгоритм )

 

- вызовет. А стек на что?

 

Zufyxe



глуппый вопрос. и как в данном случае использовать стек?

желательно хоть примерчик приблизительный

и как это отразится на DLL'ке

 

- ну, во-первых, если ты заксориш код своей функции прямо в секции принадлежащей своей DLL (сделав предварительно страницы с кодом writable) то есть огромная вероятность, что это работать не будет. Почему? А представь, что в процессе расксоривания тела функции она вызывается, скажем, другим потоком еще раз (и не один), в то время как первый еще не закончил "расшифровку"? Следовательно нужно будет заморачиваться с синхронизацией.

Как вариант (классический)- использование стека: выделяешь место в стеке - расксориваешь туда свою функцию - выполняешь - восстанавливаешь стек. Нет заморочек с защитой от записи и нет проблем с синхронизацией. Единственный минус - ограничен размер процедуры.

 

А смысл передавать в ф-цию ключик? Он ведь будет один и тот же, можно и в самой ф-ции его держать

 

приблизительный примерчик:

Код (Text):

1.  
2. proc TestMessage, nKey
3.        sub esp,200h
4.        mov edi,esp
5.        push edi
6.        mov esi,coded
7.        mov ecx,coded_size  ; < 200h
8. loopz: lodsb
9.        xor eax,nkey ;
10.        stosb
11.        loop loopz:
12.        pop eax
13.        call eax
14.        add esp,200h
15.        ret 04
16. endp
17.  

ну вобщем, что-то типа того ...

 

есть еще один маленький момент - под xp sp2 это не будет работать.

 

И еще один маленький момент - релоки придется из оригинала куда-то переносить и ручками их накладывать после расшифровки. Ну и синхронизация естесно - чтобы два потока по два раза не раскриптовывали одно и тоже. Вердикт: замучаешься =)

 

infern0



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

напрямую XOR в области кода то на XP sp2 илил

2003 есть шанс что будет функционировать?



Zufyxe

Неплохо бы хоть какие нибудь коментарии к примеру

например не совсем понятно следующее

Код (Text):

1.  
2.        add esp,200h ;-?
3.        ret 04      ;-?
4.  

 

bogrus



А смысл передавать в ф-цию ключик? Он ведь будет

один и тот же, можно и в самой ф-ции его держать



Два Варианта

1-й для каждой инсталяции шифровать новым ключиком

EAX- 65535 вариантов и т.д.

2-й вариант ключик шифрования один и тотже но

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

пример в VisualFoxpro функция SYS(2007) контрольная

сумма строки дает число до 100 000.

На уникальной последовательности строк GUID (OLE32.DLL) в

200 000 встречается как минимум два ключа дающих одинаковую

контрольную сумму если сделать выборку на порядок

больше то и ключиков больше

Конечно это ламерская защита... но тем неменее

Ключик можно брать из системы но это уже матметоды

какие то.. там дальше и не XOR, а ГОСТ или DES можно

применять

 

если решить проблему синхронизации при одновременном обращении - то будет. Армадилло например так работает, но там архитектурно-гарантированно что одновременно один и тот-же кусок несколько раз не вызовут.

 

infern0



при вызове можно проверять некий FLAG который выставлять в TRUE только когда дешифруется полностю...

В другом случае не выполнять функцию.. также если применить exe+dll когда гарантировано только твое приложение юзает твою функцию и не запускается дважды.

 

aip

верно. Только флаг должен бать в shared области памяти и все равно придется играться с сериализацией вызовов. Для случая свой exe + dll - никаких проблем.

 

Код (Text):

1. add esp,200h

- это просто для примера, здесь должен быть размер расксориваемой функции выравненый на DWORD.

Код (Text):

1. ret 04

- это я по-запарке, просто привычка всегда задавать/зачищать параметры функции вручную.

- это ты про DEP?

Код (Text):

1.  
2.   sub esp,100h
3.   mov edi,esp
4.   push edi
5.   lea esi,stackcode
6.   mov ecx,stackend-stackcode
7.   rep movsb
8.   pop edi
9.   call edi
10.   add esp,100h
11.   ret
12.  
13.  stackcode:
14.   push MB_OK
15.   push offset caption
16.   push offset text
17.   push 0
18.   mov eax,077d7050bh ;здесь у меня MessageBox
19.   call eax
20.   ret
21.  stackend:

- вот это прекрасно работает у меня под XP SP2, как с DEP включенным "для основных программ" так и с влюченным для всех остальных. Может у меня SP2 неправельный?

 

Какие проблемы сделать секцию writeable, а расшифровку реализовать в DllEntry? А в exe ещё проще (пример), релоков нет, не нужно делать базонезависимый код

 

Типа того

1555762710__xordll.zip

 

bogrus



Спасибо. Попробую разобрать примерчик