![]() |
eXeL@B —› Программирование —› Процесс защищенный от WriteProcessMemory/ReadProcessMemory |
Посл.ответ | Сообщение |
|
Создано: 18 января 2009 15:54 · Личное сообщение · #1 Здравствуйте. уж незнаю в какой раздел мне писать. наверно в этот, т.к. меня инетересует как написать подобное. Знаю многим интересно как можно сделать так, чтобы в процесс ничего не могло попасть, чтобы нельзя было сломать программу. Топиков на эту тему здесь было много. И статей. Для блокировки функций WriteProcessMemory/ReadProcessMemory и прочего антидампинга как правило используется драйвер в нулевом кольце, который там уже перехватывает NtOpenProces/NtWriteProcessMemory/NtReadProcessMemory. С эти все понятно, расисанно очень много. но недавно я наткнулся на софтину. назначени софтины врядли будет кому инетересно - античит для игрушки. сама софтина сайт _http://ucp-anticheat.ru/ ссылка на бинарник _http://ucp-anticheat.ru/client/ucpclient21.zip вот эта штука, значит, делает свой процесс недоступным для выше приведенных функций. ПРИЧЕМ НЕ ЛЕЗЕТ ДРАЙВЕРАМИ В РИНГ0!!!!! КАК ОНА ЭТО ДЕЛАЕТ??? понимаю что автор конечно не расскажет, но чтож у нас есть дизасемблеры ![]() поэтому я начал ковырять, уж очень инетересно знать КАК она это делает, я думаю многим будет тоже. прога запакованна VMProtect'ом последних версий. хороший конечно криптор.... распоковать у меня не получается, да и это не важно, главное подглядеть как она это делает. я смог залезть в дизасм этой проги с олей. вообще олю она все время кикает, в вмпротекте антиотладка есть. (кстати тоже не смог понять как так сделанно, что обнаруживает олю, хотя на ней плугин фантом стоит) чтобы залезть мне пришлось сделать так: в главном процессе ucp.exe SuspendThread (при помощи ProcessExplorera), он там один егошний. кикаем нафиг процесс ucp.exe, который дочерний, т.е. игрушку. атачим дебугер к оставшемуся процессу ucp.exe что очень интересно! - при заторможенном треде в ucp.exe на него действует WriteProcessMemory/ReadProcessMemory. стоит только запустить тред и пипец. Он видимо что-то все время подписывает куда-то... какие нибудь контесы процесса/треда... но что и куда? кто знает расскажите пожайлуйста, как такое можно сделать??? или давайте кыврять вместе! так же нашел аналогичную поделку, ее еще мало ковырял, помоему тогоже автора. _http://dump.ru/file/1444187 помоему менее совершенна в плане защиты, но принципе тотже. зажата ExeCryptorom. Сейчас пойду пытаться снять криптор. ![]() |
|
Создано: 18 января 2009 16:09 · Личное сообщение · #2 |
|
Создано: 18 января 2009 16:42 · Личное сообщение · #3 |
|
Создано: 18 января 2009 17:39 · Личное сообщение · #4 |
|
Создано: 18 января 2009 17:53 · Личное сообщение · #5 не а, он повсему адрессному простанству не дает это сделать. ради эксперимента, а нписал сейчас прогу которая бы так делала c VirtaulProtect - нифига. у этой есть залезть в ProcessExplorer, и на закладке String, попытаться что-то считать из памяти, то он просто ничего не выдает. Хотя если например драйвером хукать NtOpenProcess, он хоть пишет Cant open process. от отладчика, такое чувство что отбивается при помощи ZwClose c не пойми каким параметрами... в софтине - _http://dump.ru/file/1444187 я ошибся, там НЕ Execryptor. я немогу понять что вней. может кто поможет попробовать ее распоковать? или хотяб определить что за криптор? ![]() |
|
Создано: 18 января 2009 18:01 · Личное сообщение · #6 |
|
Создано: 18 января 2009 18:09 · Поправил: Archer · Личное сообщение · #7 Какое-то сумбурное описание проблемы. Накрыто протом-дык ясный красный смотреть надо чистую уже без прота. Ну хотя бы без конверта. И что-то сомневаюсь, что чистая софтина без прота долго прокорячится без драйвера. аддед: СекурМемори для дрова, а чел без него пытается, вроде как. Через напрямую вызовы системные не есть айс обычно. ![]() |
|
Создано: 18 января 2009 18:11 · Личное сообщение · #8 Кстати товарищ Smon прав насчёт секций. Если секция(обьект секция) спроецирована только на запись, то не получится изменить её атрибуты доступа никакими сервисами. Механизм прост: > Создаём секцию необходимого размера не связанную с файлом(что в свопе хранилась). > Проецируем её с доступом на запись в текущий процесс. > Копируем в эту проекцию блок данных из участка памяти, которую следует защитить. > Освобождаем защищаемый блок памяти. > На его место, с того же адреса проецируем секцию с доступом на чтение. > Закрываем хэндл секции, дабы нельзя было её спроецировать есчо раз. Теперь писать в эту память не получится, также не будет работать NtProtectVirtualMemory. Для записи в этот блок данных используем запись в первую прокцию, память разделяемая и данные из первой проекции отображаюьтся во второй проеции. ![]() |
|
Создано: 18 января 2009 20:23 · Личное сообщение · #9 |
|
Создано: 18 января 2009 20:50 · Личное сообщение · #10 |
|
Создано: 18 января 2009 23:01 · Личное сообщение · #11 |
|
Создано: 18 января 2009 23:23 · Личное сообщение · #12 короче я решил кыврять маленькую прогу, а потом сам античит с ВМПротектом. Там методы походу одинаковые. в это идчеёнжере нашел покрайне мере две антиоталадочные хитрости: 1) в отдельном треде крутиться 00405DE5 833D 15104000 0>CMP DWORD PTR DS:[401015],0 00405DEC 75 17 JNZ SHORT 00405E05 00405DEE 64:A1 18000000 MOV EAX,DWORD PTR FS:[18] 00405DF4 8B40 30 MOV EAX,DWORD PTR DS:[EAX+30] 00405DF7 8A40 02 MOV AL,BYTE PTR DS:[EAX+2] 00405DFA FEC8 DEC AL 00405DFC 24 99 AND AL,99 00405DFE 04 1E ADD AL,1E 00405E00 B9 9A3B0000 MOV ECX,3B9A 00405E05 3081 4A224000 XOR BYTE PTR DS:[ECX+40224A],AL 00405E0B ^ E2 F8 LOOPD SHORT 00405E05 00405E0D C705 15104000 1>MOV DWORD PTR DS:[401015],16 00405E17 31D2 XOR EDX,EDX 00405E19 64:A1 30000000 MOV EAX,DWORD PTR FS:[30] 00405E1F 8A40 68 MOV AL,BYTE PTR DS:[EAX+68] 00405E22 24 70 AND AL,70 00405E24 3C 70 CMP AL,70 00405E26 75 0D JNZ SHORT 00405E35 00405E28 52 PUSH EDX 00405E29 68 88130000 PUSH 1388 00405E2E FF15 90904000 CALL DWORD PTR DS:[<&kernel32.Sleep>] ; kernel32.Sleep 00405E34 5A POP EDX 00405E35 6A 00 PUSH 0 00405E37 6A 00 PUSH 0 00405E39 6A 11 PUSH 11 00405E3B 6A FE PUSH -2 00405E3D FF15 04914000 CALL DWORD PTR DS:[<&ntdll.ZwSetInformat>; ntdll.ZwSetInformationThread 00405E43 09D2 OR EDX,EDX 00405E45 ^ 74 E1 JE SHORT 00405E28 00405E47 C3 RET 00405E48 0000 ADD BYTE PTR DS:[EAX],AL т.е. все время вызывает invoke ZwSetInformationThread,-2,11h,0,0 попробовал я это написать, олю от этого всего просто кантузит.... этот код переодический встречается и без треда на оле кантузия провялется, что она не показывает нифига адрессное простанство модуля, просто как будто память не выделенна. 2) CloseHandle 11h, 12h, 18h,19h,1ah(цифры по очереди разумеется). тоже гдет када то читал, что отладчики на этом летят. продолжаю копать дальше.... ![]() |
|
Создано: 19 января 2009 00:07 · Поправил: Clerk · Личное сообщение · #13 umka60 Это ThreadHideFromDebugger. Сбрасывай в ETHREAD.CrossThreadFlags флажёк PS_CROSS_THREAD_FLAGS_HIDEFROMDBG и парси сервис, просто занопь кодес, который этот бит взводит, открывай ядерным отладчиком. NtClose при не валидном хэндле возвращает управление в юзермод на KiRaiseUserExceptionDispatcher, в обход отладчика, а там изза TF генерируется исключение. Оля видимо с этим не справляется. А не, код говно, я то по привычке подомол про Int2e, в таком случае раз по тупому через экспорты юзоется просто можно и олей пропатчить кодес. ![]() |
|
Создано: 19 января 2009 01:01 · Личное сообщение · #14 ды занопить то я догадался ![]() int 2eh тоже юзается. голова кипит, но каким то макаром я прошел сквозь всю эту антиотладку вставлением jmp и нопов. дальше началась какая-то свистояпляска: VirtualAlloc, в это место пишется какой-то код, выполняется, в этом выполняемом опять VirtualAlloc, раскодировка кода. на этому пока повис. инетересно чем это раскручивание кончиться. там тоже какая-то антиотладка, какая, я еще непонял. ![]() |
|
Создано: 19 января 2009 02:34 · Личное сообщение · #15 кажется разобрался, что это за прыганья такие. вообщем это все выглядит примерно так: invoke VirtualAlloc,0,6000h,00003000h,40h; и сразу переносим туда ниже следующий код ;jmp куда выделили invoke UnmapViewOfFile,00400000h;- освобождаем модуль invoke VirtualFree,00400000 ,msize 00008000h invoke VirtualAlloc, 00400000,msize,00003000h,40h; - на тот же адресс ;грузит хедер ехешника ;грузит дата в ехешник ;создает таблицу импорта ; push 00410000 ; jmp VirtualFree, на кусок где был временный код, т.е. после выхода оказываемся в 00410000 хотя в самой проге 00410040h оказалось. короче говоря Clerk похоже был прав. сейчас тоже самое попробую написать з.ы. я даже смог собрать ехешник почти работающий (где в далеке кода выбрасывается), из новой секции, мож где еще куски памяти были где он что нибудь хранил. ![]() |
![]() |
eXeL@B —› Программирование —› Процесс защищенный от WriteProcessMemory/ReadProcessMemory |