Помогите определить тип защиты, ну или алгоритм шифрации) все такое короче..

[kolr]

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

[mira]

дизасемблировал 2кб начиная с начала функции сендпакет в защищенном
и не защищенном процессе. затем выполнил сравнение файлов через UEdit вообще запуталса как так может быть
call и nop местами переставлены, адреса никакие не изменены.
гдето ниже основной процедуры в коде местами call по другим адресам.

такое ощущение как будто разные версии файла, тем не менее адрес процедуры тотже, да и engine.dll таже

[mira]

Сообщение от kolr

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

можно тока смысл. Ему нужен оог режим. Или предлагаеш прикрутить к пх сср))
я бы ваще валялса - бот с защитой от ботов!

[supernewbie]

госпади, вот я все хочу узнать, я один кто не понял не строки из этого кода?
3 203C68CA: 56 push esi
3 - ну это строка, наверное.
но что мать вашу идет дальше? какая-то херня в интеджере? или в чем?
56? тут я даже предположить боюсь, но зачем он толкает еси? нет ребят. с этим надо что-то делать

[mira]

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

Добавлено через 18 часов 3 минуты
осталось проверить пару процедур в сендпакете. Остальные вызовы проверил.
Там все стандартно. Шифрует пакет 2 или 3 или 4 call дальше вызов в core.dll и send в сокет.
1 вызов создает в стеке буфер и возможно компилит в нем пакет

[mira]

такс.
Как узнать что за метод networkhandler лежит в VMT по смещению 7C ?
Дизасамблер уменя прикурил на дизасемблирование 25мб дампа енгине.длл ))

[supernewbie]

кстати, не подскажешь что за дизасемблер юзаешь?

[mira]

для файлов windasm или встоеный в peexplorer. Сначало нада сделать дамп какимнить petools ибо файл как он есть для дизасма непригоден

Добавлено через 6 минут
для просмотра кода прямо в исполняющемся процессе у меня в проге команда /asm addr size name
addr адрес
size размер. Если не указан 64 байта
name если указан имя файла куда сохранить результат

Добавлено через 4 часа 34 минуты
203C68C0: B800800000mov eax, 00008000h
203C68C5: E8A6A9DAFFcall 20171270h                // создает стековый кадр (буфер для компиляции пакета) размером $8000
203C68CA: 56        push esi
203C68CB: 8BB42408800000mov esi, [esp+00008008h]
203C68D2: 83BE1C91000000cmp [esi+0000911Ch], 00000000h
203C68D9: 0F8529010000jnz 203C6A08h
203C68DF: 837E3800  cmp [esi+38h], 00000000h
203C68E3: 0F841F010000jz 203C6A08h
203C68E9: 57        push edi
203C68EA: 8DBED8900000lea edi, [esi+000090D8h]
203C68F0: 57        push edi
203C68F1: 90        nop 
203C68F2: E809A7535Ccall 7C901000h                // EnterCriticalSection ntdll.dll
203C68F7: 8B842410800000mov eax, [esp+00008010h]
203C68FE: 85C0      test eax, eax
203C6900: 0F84FA000000jz 203C6A00h
203C6906: 53        push ebx
203C6907: 8D8C2418800000lea ecx, [esp+00008018h]
203C690E: 51        push ecx
203C690F: 50        push eax
203C6910: B9FE7F0000mov ecx, 00007FFEh
203C6915: 8D442416  lea eax, [esp+16h]
203C6919: E852C5FFFFcall 203C2E70h                // типа компилирует пакет в буфере
203C691E: 8BD8      mov ebx, eax
203C6920: 83C408    add esp, 00000008h
203C6923: 85DB      test ebx, ebx
203C6925: 0F849D000000jz 203C69C8h
203C692B: 807C240ED0cmp byte ptr [esp+0Eh], FFFFFFD0h
203C6930: 750F      jnz 203C6941h
203C6932: 8B4C240F  mov ecx, [esp+0Fh]
203C6936: 56        push esi
203C6937: E8F4C7FFFFcall 203C3130h  2016DBE9     call addr [20476FE0] и понеслась
203C693C: 668944240Fmov [esp+0Fh], ax
203C6941: 8B54240E  mov edx, [esp+0Eh]
203C6945: 52        push edx
203C6946: 56        push esi
203C6947: E8B4C8FFFFcall 203C3200h           // возвращает объект из массива А[0..209] содержащий параметр Б(byte)
203C694C: 83C302    add ebx, 00000002h
203C694F: 8844240E  mov [esp+0Eh], al
203C6953: 8BC3      mov eax, ebx
203C6955: C1F808    sar eax, 08h
203C6958: 83BEF490000000cmp [esi+000090F4h], 00000000h
203C695F: 885C240C  mov [esp+0Ch], bl
203C6963: 8844240D  mov [esp+0Dh], al
203C6967: 7419      jz 203C6982h
203C6969: 8B16      mov edx, [esi]
203C696B: 8B527C    mov edx, [edx+7Ch]
203C696E: 8D43FE    lea eax, [ebx-02h]
203C6971: 50        push eax
203C6972: 8D8EF8900000lea ecx, [esi+000090F8h]
203C6978: 51        push ecx
203C6979: 8D442416  lea eax, [esp+16h]
203C697D: 50        push eax
203C697E: 8BCE      mov ecx, esi
203C6980: FFD2      call edx                   // UNetworkHandler::ServerExPacketCountStart(void)
203C6982: 83BE18A0000000cmp [esi+0000A018h], 00000000h
203C6989: 754E      jnz 203C69D9h
203C698B: 90        nop                        // TSingleton<class L2Configuration>::m_pObject
203C698C: E89FB3C4F4call 15011D30h             // core ?m_pObject@?$TSingleton@VL2Configuration@@@@0PAVL2Configuration@@A
203C6991: 83784800  cmp [eax+48h], 00000000h
203C6995: 6A00      push 00000000h
203C6997: 53        push ebx
203C6998: 7413      jz 203C69ADh
203C699A: 8B4E38    mov ecx, [esi+38h]
203C699D: 8D442414  lea eax, [esp+14h]
203C69A1: 50        push eax
203C69A2: 51        push ecx
203C69A3: E8086FDCFFcall 2018D8B0h  --->2018E4A0 --->send socket
203C69A8: 83C410    add esp, 00000010h
203C69AB: EB0F      jmp 203C69BCh
203C69AD: 8B4638    mov eax, [esi+38h]
203C69B0: 8D542414  lea edx, [esp+14h]
203C69B4: 52        push edx
203C69B5: 50        push eax
203C69B6: E86CE26E51call 71AB4C27h             // SOCKET WS2_32.dll send
203C69BB: 90        nop 
203C69BC: 019E78890000add [esi+00008978h], ebx
203C69C2: 019E7C890000add [esi+0000897Ch], ebx
203C69C8: 57        push edi
203C69C9: E812A7535Ccall 7C9010E0h            // leave critical section Kernel32.dll
203C69CE: 90        nop 
203C69CF: 5B        pop ebx
203C69D0: 5F        pop edi
203C69D1: 5E        pop esi
203C69D2: 81C400800000add esp, 00008000h
203C69D8: C3        ret 
203C69D9: 90        nop

Добавлено через 4 минуты
вот в том вызове пакет мутирует)
антиотладочный трюк с RDTSC и процедура превращаетса в вереницу джампов с парой действий)

Добавлено через 8 минут
ах да ))) тот код который там идет не попадает в адрессное пространство не одной из загруженных длл)
ппц меня задолбали эти джампы когда же будет логический конец процедуры))))

[mira]

вощем ненашол где че и как. но весь раскалбас начинаетса там с
call [20476FE0] engine.dll
в защищенном и незащищенном клиенте этот адрес различен.
их объединяет только то что там начинаетса очень мутный и запутанный код

Добавлено через 11 часов 57 минут
понял) с этогого адреса начинаетса код прошедший обфускацию темидой.
Все как в ее описании...

Процедура нарезаетса на кусков так 25 посредством джампов и перемешиваетса с тонной пустово говнокода.

Во время каждой сессии темида мутирует процедуру по разному.
И как быть с этим полиморфиком?)

[supernewbie]

из всего этого я понял что происходит что-то жутко х*евое)

Во время каждой сессии темида мутирует процедуру по разному.

а зачем нам это? нам вроде надо только 1 раз посмотреть алгоритм шифрации) или я совсем нихрена не понимаю?