PD>>Ты отдаешь себе отчет, что ты пытаешься выгрузить DLL из своего процесса , а вовсе не из процесса, который ты открыл, причем с правами только чтения ?
R>Но почему то этот подход применим не ко всем dll.
Есть куча проблем которые вызовет выгрузка user32.dll. Просто говоряпросто очень изощренный способ лишить себя ноги.

R>Я хочу сделать процесс свободный от всех ненужных мне системных dll ,а также dll которые нагружаються извне.
R>Хочу защитить свою программу от внешних хуков.
R>Может я иду не тем путём?
Я так делал: при запуске процесса, дабы избавиться от всех инжектов,
1) Запускал процесс в suspended состоянии, "удаленно" перехватывая в нем CsrClientConnectToServer — вешая на нее trampoline который LdrLoadDll'ем загружал мою длл, которая зависела только от ntdll, и делала следующие вещи, уже в контексте дрочернего процесса (и это не опечатка ):
2) Киляла все треды свренр процесса кроме текущего
3) unmap-ла все длл кроме ntdll и себя
4) вычитывала с диска секцию кода и секцию RO данных ntdll и _перезаписывала_ текущий образ ntdll тем что вычитал из диска
5) приводила структуры связанные PEBом процесса к виду, в котором он выглядит на момент запуска
6) перезапускала загрузчик процесса вызовом LdrInitializeThunk
Разумеется код на 80% основывался на результате детального реверсинга поведения ntdll, и всех деталей я сейчас не упомню. Скажу лишь например, что параметры LdrInitializeThunk разнятся от винды к винде, как и структуры, относящиеся к PEB'у.

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

PD>>Ты отдаешь себе отчет, что ты пытаешься выгрузить DLL из своего процесса , а вовсе не из процесса, который ты открыл, причем с правами только чтения ?
R>Но почему то этот подход применим не ко всем dll.
Есть куча проблем которые вызовет выгрузка user32.dll. Просто говоряпросто очень изощренный способ лишить себя ноги.

R>Я хочу сделать процесс свободный от всех ненужных мне системных dll ,а также dll которые нагружаються извне.
R>Хочу защитить свою программу от внешних хуков.
R>Может я иду не тем путём?
Я так делал: при запуске процесса, дабы избавиться от всех инжектов,
1) Запускал процесс в suspended состоянии, "удаленно" перехватывая в нем CsrClientConnectToServer — вешая на нее trampoline который LdrLoadDll'ем загружал мою длл, которая зависела только от ntdll, и делала следующие вещи, уже в контексте дрочернего процесса (и это не опечатка ):
2) Киляла все треды свренр процесса кроме текущего
3) unmap-ла все длл кроме ntdll и себя
4) вычитывала с диска секцию кода и секцию RO данных ntdll и _перезаписывала_ текущий образ ntdll тем что вычитал из диска
4.1) Тоже самое проделывала с образом исполняемого файла.
5) приводила структуры связанные PEBом процесса к виду, в котором он выглядит на момент запуска
6) перезапускала загрузчик процесса вызовом LdrInitializeThunk
Разумеется код на 80% основывался на результате детального реверсинга поведения ntdll, и всех деталей я сейчас не упомню. Скажу лишь например, что параметры LdrInitializeThunk разнятся от винды к винде, как и структуры, относящиеся к PEB'у.

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