защита процесса от самого себя

Clerk

а еще KiIntSystemCall, так?

 

Да и эта тоже.

 

Народ. Предлагаю вам следущий вариант на обозрение. Если предполагается защита dll на своей машине в процессе, то можно пртбегнуть к использованию WinAPI, предназначенных для работы с отладкой. Смысл в том, что такой подход дает возможность полностью скрыть код своей DLL в процессе. Единственной проблеммой при использовании подобного API является скрытие присутствия отладчика в контексте процесса, в котором мы скрываем DLL. Как показывает опыт, большинство приложений пытаются обнаружить присутствие отладчика с помощью IsDebuggerPresent(). В соответствии с предлагаемой схемой, будет два процесса:
-1- отлаживаемый процесс (ОП) - процесс, в котором скрываем свою dll
-2- процесс-отладчик(под управлением которого происходит скрытие DLL с её кодом) (ПОД)
ПОД запускает ОП, внедряет DLL по какому либо событию (к примеру CREATE_PROCESS_DEBUG_EVENT). После чего он удаляет инфу из _PEB.BeingDebugged (установкой в 0х00) о присутствии отладчика и инфу о самой библиотеке подобно тому, какэто описал Flasher.
Присутствие оладчика дает нам возможность обрабатывать исключение в первую очерель (раньше, чем обработчики в SEH в процессе). Используя это преимущество, мы проверяем адрес и код исключения (которые генерируются кодом нашей DLL). Далее думаю все понятно. либо расшифровываем код отладчиком через ReadProcessMemory и WriteProcessMemory.

 

Ваших преложений ?
1. К отладчику можно подключить отладчик.
2. Удаление записи о модуле из загрузчика не как не связано с сокрытием кода модуля.

 

Во-первых, если отлаживаемый процесс запущен с ограниченными правами, то вряд ли он подключит свой отладчик к отладчику (к ПОД-у).
Во-вторых, а кто сказал, что в библиотеке будет присутствовать весь код???? я такого не говорил. Код в библиотеке всего лишь генерирует исключение, обрабатывая которое отладчик принимает решение о том, записать(расшифровать) или нет некоторый полезный код (который нужно скрыть) в адрессном пространстве процесса и передать ему управление. В свою очередь, если код отладчиком был расшифрован и ему было передано управление, то этот записанный(расшифрованный) в конце своей работы вновь генерирует исключение, по которому отладчик затирает(зашифровывает) полезный код.

 

Разумеется твоё дело, это всеголишь мой взгляд на подобную "защиту". Дебугапи это средство отладки приложений без какойлибо защиты от отладки, например ты легко можеш отключить отладчик от своего процесса. Подобное всегда решается нормальным ядерным дебаггером.

 

Тема раздела насколько я помню касается покерного бота. Следовательно, бот (он же ПОД) работает на одной ОС вместе с покерным клиентом и управляет им с помощью заинжектенной в клиент dll-ки. Я не думаю, что разработчик бота даст покерному клиенту права администратора. Именно по этому схема с использованием WINAPI для работы с отладкой имеет смысл в плане сокрытия кода в dll в в процессе бота. Хотел бы я посмотреть на покерного клиента покер-рума, поднимающего ядерный отладчик

 

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

 

В общем решили сделать так: будет небольшой драйвер, который заменяет таблицу прерываний для процесса (клиента ), перехватывает int2E и sysenter, в обработчике будем отлавливать функции, которые могут спалить нашу dll внутри процесса (типа zwQuerySystemInformation) и подменять возвращаемые результаты.
Клиент будет запускаться с помощью CreateProcessAsUser для того, чтобы запретить ему читать нашу dll с диска.
Также после того, как dll загрузилась, но до запуска потоков клиента, редактируем PEB - скрываем присутствие библиотеки (в процессе работы dll просматриваем PEB на наличие хэндлов, если есть, то убираем инфу о них).
В PEB убираем инфу о том, кто является родительским процессом, точнее подменяем на explorer.exe, к примеру.
Может быть будем затирать PE заголовок (пока еще не знаем, нужно ли это).
Защиту от дампа хотим реализовать либо копи/пастом, либо шифрованием. Шифровать будет драйвер после возникновения исключения:

Код (Text):

1. void Proc()
2. {
3.   // вызываем исключение, драйвер определяет из какого места произошло и расшифровывает от Marker1 до Marker2
4.   __asm{
5.     xor eax,eax
6.     mov [eax],0
7.   }
8.  
9.   Marker1:
10.   // шифрованный код
11.   ...
12.  
13.   // зашифровываем обратно
14.   Marker2:
15.   __asm{
16.     xor eax,eax
17.     mov [eax],0
18.   }
19. }

Как-то так...

Интересует вопрос: какие еще следы оставляет dll после загрузки, например откуда она промапена?