Если твой "подопытный" написан грамотным троянописателем   , 
то при выгрузке он должен корректно возвращать обратно все,
 что напакостил в чужом АП.
В этом случае при его анлоаде ничего страшного не должно поизойти.

Как без "вмешательства" не знаю.
Может перед стартом инжектора залезать только в него, перехватывать NtQuerySystemInformation, и не давать ему внедряться во все процессы системы ?

Надо подумать.

Может я не так поняла ? Варианты чего ?
Если получения "настоящего" списка загруженных модулей, то нам никуда внедряться не надо.
Он же сам влез в нас. Прямо в себе и получаем нужное.   

Нет, ситуация такая. Есть приложение "жертва" в которое внедряю сторонний код. Моей проге нужно проверить не сделали чего с "жертвой" и не загрузила ли она кого лишнего.

И проделать это не влезая в жертву ?  
Жестковатые условия   

Можно попробовать так:
Раз он влезает в жертву при помощи LoadLibrary, то в ней есть ее Handle.
Перебираем все открытые Handl`ы жертвы и смотрим их имена (объекты типа "FILE").
Находим имя внедряемой библиотеки - жертва хакнута.

     ?

Нет такого хэндла. Не зря же анлокер не находит. Щас пытаюсь прицепиться к другому варианту. Модуль внедряемый инжектором содержит ряд специфичных строк (вроде Hello World), может тогда попробовать почитать память "жертвы" в поисках этих строк?

Handle`а может конечно и не быть, но дело мне кажется в другом.
Она прячет себя из списка загруженных модулей.
Когда это делаешь, то подправить таблицу открытых Handl-ов - это лишние
пять строчек кода  
Анлокер тоже хакнут. Вот и не видит.
Так что получай "нормальный" список хандлов, методом аналогичным получению 
"настоящего" списка модулей.



Imho некузявый способ  

Вернулись к началу - как получиться нормальный список хэндлов? 

Точно так же как и "не хакнутый" список загруженных модулей.  
Там же не было привязки ни к библиотеке, ни к имени функции.

У Rouse_ на сайте есть пример получения списка всех открытых Handle`ов и их имен.
Чуть его подправить для работы только с одним процессом.

Далее:
Получаем "настоящие" адреса для всех необходимых функций и используем
их в переделанном Rouse_`ском примере, вместо перехваченных функций.  

Не вижу. :(

Sorry.
Прикрепляю его.

P.S.
 Только этому коду "сто лет в обед" будет. 

Добавлено через 4 минуты и 26 секунд
Да. Сейчас увидела: там что-то закоментировано.
Может это я. Не помню.
Но все-равно, под твою задачу его перделать надо, так что не страшно.
Принцип сохранился   

Присоединённый файл ( Кол-во скачиваний: 7 )
 EnumOpenFiles.rar 4,52 Kb

Нету там хэндла этой длл-ки. И файл похоже "жертвой" не открыт (оригинальная утиль его не видит). .похоже чем дальше продвигаемся, тем дальше уходим от решения.

И не должно было быть, если она внедряется во все процессы.  
В этом примере надо использовать функции, полученые не с помощью
GetProcAddress, а "настоящие". Технологией их получения ты владеешь.



IMHO
Т.к. мы знаем что идет внедрение во все процессы, то
самый лучший и простой вариант:
Получить в себе настоящие адреса ф-ий.
С их помощью, в себе же найти эту Dll-ку.
С их же помощью, перебрать все процессы и все модули в них (или Handl-ы).
И выдернуть ее за ушко да на солнышко   

Т.е. "настоящие" адреса надо получать только в себе.

Я так и не поняла, чем этот вариант тебе не нравиться ?

У меня есть почти сорец этого инжектора. Внедрение только в один процесс. И противодействия обнаружению там тоже не вижу. Пока единственный вариант, который я еще не пробовал, это внедрить не модуль (свой) целиком, а только поток, так по идее и сам процесс "жертвы" я почти не трогаю и в теории смогу получить реальные адреса перехватываемых функций.

"Меня терзают смутные сомненья" (с)  
1. Ее никто не видит в списке загруженных модулей 
    (кстати посмотри-ка через Performance Counters. Мне бы было лень их тоже править  )
2. Никто не находит ее Handle, тем не менее файл не уничтожить.
3. Ну и на закуску: как быть с тем, что нашли вы с идочкой в:


?

P.S.
 Сам инжектор может внедрять только в один, а дальше она сама со всем справиться.
 Вариантов миллион