Сейчас на форуме: zds, tyns777, JustLife, 2nd, morgot, Rio, CDK123 (+4 невидимых)

 eXeL@B —› Программирование —› Процесс защищенный от WriteProcessMemory/ReadProcessMemory
Посл.ответ Сообщение

Ранг: 2.2 (гость)
Активность: 0=0
Статус: Участник

Создано: 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. Сейчас пойду пытаться снять криптор.




Ранг: 138.1 (ветеран)
Активность: 0.090
Статус: Участник
Одепт ЭкзэЛаба

Создано: 18 января 2009 16:09
· Личное сообщение · #2

По поводу как прога хукает без драйвера, ну хуки в юзер моде еще никто пока не отменял. По поводу что олька с фантиком ловится, ну так наверняка юзается очередной багес ольки/фантика. Сори если офтоп.



Ранг: 2.2 (гость)
Активность: 0=0
Статус: Участник

Создано: 18 января 2009 16:42
· Личное сообщение · #3

если юзер моде то тогда нужно во всех процессах хукать, а она этого не делает....
падение оли вызванно криптором - вм протектором, во второй проге execryptor как раз и ловит олю на ее ошибке. не у кого нету хорошей оли от ехекриптора??? я пробуй от Bronca олю. если есть лучше скажите...



Ранг: 500.5 (!), 8thx
Активность: 0.230
Статус: Участник

Создано: 18 января 2009 17:39
· Личное сообщение · #4

Можно просто выставлять атрибут read only на секцию кода в потоке, если запись туда самой прогой не ведется.

-----
"Пусть видят, что мы не шутим. Стволы для понта, ножи для дела" Lock, Stock & Two Smoking Barrels




Ранг: 2.2 (гость)
Активность: 0=0
Статус: Участник

Создано: 18 января 2009 17:53
· Личное сообщение · #5

не а, он повсему адрессному простанству не дает это сделать. ради эксперимента, а нписал сейчас прогу которая бы так делала c VirtaulProtect - нифига.
у этой есть залезть в ProcessExplorer, и на закладке String, попытаться что-то считать из памяти, то он просто ничего не выдает. Хотя если например драйвером хукать NtOpenProcess, он хоть пишет Cant open process.

от отладчика, такое чувство что отбивается при помощи ZwClose c не пойми каким параметрами...

в софтине - _http://dump.ru/file/1444187 я ошибся, там НЕ Execryptor. я немогу понять что вней. может кто поможет попробовать ее распоковать? или хотяб определить что за криптор?



Ранг: 255.8 (наставник), 19thx
Активность: 0.150.01
Статус: Участник
vx

Создано: 18 января 2009 18:01
· Личное сообщение · #6

MmSecureVirtualMemory для этих целей служит. Когдато ковырял теневые сервисы, заметил что один позволяет это из юзермода заюзать, тока не помню какой, тогда не придал этому никакого значения.




Ранг: 2014.5 (!!!!), 1278thx
Активность: 1.340.25
Статус: Модератор
retired

Создано: 18 января 2009 18:09 · Поправил: Archer
· Личное сообщение · #7

Какое-то сумбурное описание проблемы. Накрыто протом-дык ясный красный смотреть надо чистую уже без прота. Ну хотя бы без конверта. И что-то сомневаюсь, что чистая софтина без прота долго прокорячится без драйвера.

аддед: СекурМемори для дрова, а чел без него пытается, вроде как. Через напрямую вызовы системные не есть айс обычно.



Ранг: 255.8 (наставник), 19thx
Активность: 0.150.01
Статус: Участник
vx

Создано: 18 января 2009 18:11
· Личное сообщение · #8

Кстати товарищ Smon прав насчёт секций. Если секция(обьект секция) спроецирована только на запись, то не получится изменить её атрибуты доступа никакими сервисами. Механизм прост:
> Создаём секцию необходимого размера не связанную с файлом(что в свопе хранилась).
> Проецируем её с доступом на запись в текущий процесс.
> Копируем в эту проекцию блок данных из участка памяти, которую следует защитить.
> Освобождаем защищаемый блок памяти.
> На его место, с того же адреса проецируем секцию с доступом на чтение.
> Закрываем хэндл секции, дабы нельзя было её спроецировать есчо раз.
Теперь писать в эту память не получится, также не будет работать NtProtectVirtualMemory. Для записи в этот блок данных используем запись в первую прокцию, память разделяемая и данные из первой проекции отображаюьтся во второй проеции.




Ранг: 990.2 (! ! !), 380thx
Активность: 0.680
Статус: Модератор
Author of DiE

Создано: 18 января 2009 20:23
· Личное сообщение · #9

Clerk

хоть прогу смотрел? или опять лекции.

umka60

мало того, что это г. запаковано ломанной версией, т.к. не хило палиться ав дык ещё и не запускается на виртуалке :D

-----
[nice coder and reverser]




Ранг: 255.8 (наставник), 19thx
Активность: 0.150.01
Статус: Участник
vx

Создано: 18 января 2009 20:50
· Личное сообщение · #10

Hellspawn
Нее, не смотрел, даже пост автора не читал. Насчёт лекция хорошая шутка , матчасть



Ранг: 107.5 (ветеран)
Активность: 0.150
Статус: Участник

Создано: 18 января 2009 23:01
· Личное сообщение · #11

да ладно вы хоть это дерьмо запакованное (сорри если обидел кого) пробовали через собственные дрова артманей хакнуть ? самому просто. если это возможно то никакая это не защита.

-----
Md5 fcbb6c9c9a5029b24d70f2d67c7cca74




Ранг: 2.2 (гость)
Активность: 0=0
Статус: Участник

Создано: 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(цифры по очереди разумеется). тоже гдет када то читал, что отладчики на этом летят. продолжаю копать дальше....



Ранг: 255.8 (наставник), 19thx
Активность: 0.150.01
Статус: Участник
vx

Создано: 19 января 2009 00:07 · Поправил: Clerk
· Личное сообщение · #13

umka60
Это ThreadHideFromDebugger.
Сбрасывай в ETHREAD.CrossThreadFlags флажёк PS_CROSS_THREAD_FLAGS_HIDEFROMDBG и парси сервис, просто занопь кодес, который этот бит взводит, открывай ядерным отладчиком.
NtClose при не валидном хэндле возвращает управление в юзермод на KiRaiseUserExceptionDispatcher, в обход отладчика, а там изза TF генерируется исключение. Оля видимо с этим не справляется.
А не, код говно, я то по привычке подомол про Int2e, в таком случае раз по тупому через экспорты юзоется просто можно и олей пропатчить кодес.



Ранг: 2.2 (гость)
Активность: 0=0
Статус: Участник

Создано: 19 января 2009 01:01
· Личное сообщение · #14

ды занопить то я догадался
int 2eh тоже юзается.
голова кипит, но каким то макаром я прошел сквозь всю эту антиотладку вставлением jmp и нопов.
дальше началась какая-то свистояпляска: VirtualAlloc, в это место пишется какой-то код, выполняется, в этом выполняемом опять VirtualAlloc, раскодировка кода. на этому пока повис. инетересно чем это раскручивание кончиться. там тоже какая-то антиотладка, какая, я еще непонял.



Ранг: 2.2 (гость)
Активность: 0=0
Статус: Участник

Создано: 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
:: Ваш ответ
Жирный  Курсив  Подчеркнутый  Перечеркнутый  {mpf5}  Код  Вставить ссылку 
:s1: :s2: :s3: :s4: :s5: :s6: :s7: :s8: :s9: :s10: :s11: :s12: :s13: :s14: :s15: :s16:


Максимальный размер аттача: 500KB.
Ваш логин: german1505 » Выход » ЛС
   Для печати Для печати