привет! разбираясь с работой pe лоадера, наткнулся на статью x64 http://rsdn.ru/forum/src/3202881.1.aspx. В сорцах присутствуют функции с префиксом Kmlib, по названиям некоторых можно предположить что она делает. x64 , не мог ли бы вы объяснить работу пару функций: KmlibProcessFindModule и KmlibVirtualProtectInProcess ?
В таком случае, если ты загружаешь только одну .dll в процесс в момент, когда основные модули уже загружены, то всё просто, потому что вместо KmlibProcessFindModule() ты можешь использовать GetModuleInformation() или LoadLibrary() и её варианты с флагами. Ну а KmlibVirtualProtectInProcess() можно заменить на VirtualProtect() или VirtualProtectEx(). Но если ты загружаешь более одного модуля собственным загрузчиком, или если ты загружаешь вообще все модули с самого начала, то всё чуть сложнее, ибо использовать сервисы системного загрузчика будет проблематично, придётся вести собственный список модулей и самостоятельно реализовать такие функции как GetProcAddress(), GetModuleHandle(), FreeLibrary() и т.д. Ну и ещё скажем, что для ядра будет своя специфика. Это вкратце, будут конкретные вопросы - спрашивай.
возможны ли замены? KmlibCreateUnicodeStringFromAnsiString -> RtlAnsiStringToUnicodeString KmlibPathCombine -> не совсем понятно, вроде как создается путь к импорту KmlibDeleteUnicodeString - > RtlZeroMemory
Да, конечно, только немного не так: По сути, да, только идея была в том, чтобы KmlibCreateUnicodeStringFromAnsiString() ещё и память сама выделяла под новую строку. Освобождается такая память в KmlibDeleteUnicodeString(), соответственно. Память выделяется из пула через ExAllocatePool(). Это мой ядерный аналог функции PathCombine(). Тут нет ничего особенного, кроме того, что нужно не забыть учесть все возможные ситуации. Нет, эта функция освобождает выделенную ранее строку обратно в пул через ExFreePool(), ну и обнуляет указатель *ppusUnicodeString = NULL, - это для предотвращения повторного использования/освобождения этой же строки. Все функции освобождения памяти библиотеки построены по этому принципу: сначала освобождаем пул, виртуальную или физическую память, затем обнуляем указатель. Соответственно, на вход не *, а ** подаётся. А остальные функции библиотеки все параметры проверяют на != NULL, таким образом полностью исключаются некоторые виды ошибок.
Здравствуйте, Господа. Хотел бы прояснить несколько вопросов насчет статьи. Использовать код буду в драйвере. Обязательно ли при этом использовать PsCreateSystemThread? Как мне известно эта функция создает системный поток. Верно ли это? И еще... Код берет образ ДЛЛ из памяти т.е. перед манипуляциями нужно загрузить ДЛЛ из файла. Озвучиваю предполагаемую программу действий: 1)Загрузить ДЛЛ в АП управляющего процесса(Желательно чтобы ul_reason_for_call<>DLL_PROCESS_ATTACH или вообще без вызова DllMain). Можно осуществить с помощью HideLoadLibrary by SLESH только без флага DLL_PROCESS_ATTACH. 2)Дать команду драйверу на присоединение к АП управляющего процесса. 3)Выделить пул с помощью ExAllocatePool. 4)Скопировать образ ДЛЛ из АП процесса в пул.(Как понимаю производить копирование можно как из процесса так и из драйвера? ) 5)Отсоединиться от АП управляющего процесса. 6)Вызываем LdrLoadImage. pRawImage = Адресс который получили в ExAllocatePool. 7)Шлю APC ShellCode который выполняет процедуру по адресу pEntryPoint с соответствующими параметрами (push 0; push DLL_PROCESS_ATTACH; push ImageBase; call [pEntryPoint] ). Что то нужно исправить? Есть замечания? P.S. Спасибо x64 за замечательную статью.
Не знаю, зависит от того, для чего тебе всё это надо. Ну ещё бы! Это обёртка над NtProtectVirtualMemory(), адрес брать из SDT. Да, только RegionSize можно установить в 0, тогда блок будет освобождён целиком. Тут ничего хитрого, разберёшься. Это тупой поиск модуля по имени в базе загрузчика модулей в PEB процесса. Это тупо освобождение пула, ничего более. Ну почему же сразу из файла, можешь её хоть в секцию данных драйвера зашить. Не понял, зачем вообще предварительно загружать .dll с диска? Что за ересь? Весь тот код, о котором ты говоришь, именно для этого и предназначен, а ты, судя по всему, собираешься загрузить .dll дважды. На хрена? Ну типа того, можно APC, можно поток или ещё что-нибудь экзотическое, зависит от цели.
Цель такая: Загрузить в АП определеного процесса dll в обход юзермодных хуков. Хуки не дают возможности загрузить DLL в определенный процесс. DLL хукает пару функции(методом изменения значения виртуальных таблиц). Не малварь. Читы.(Да я совсем еще ребенок ) Драйвер - инжектор, так что ни чего криминального. Схема такая: 1)Запускаю приложение которое грузит драйвер(управляющий процесс). 2)Падаю параметры ДЛЛ(путь) и target ProcessID в который нужно подгрузить DLL. 3)Единожды инжектит DLL.(Без выгрузки) Дело в том что DLL задает юзер. Пункт 7 готов. (Начал с конца). Забыл в цель добавить что DLL не должна числиться в списках загруженных модулей. Поэтому выбрал маппить ДЛЛ вручную из ядра. (Ударим по тараканам ядерной бомбой ^^)
