Есть классический внедренец (инжектор) который внедряет dll-ку в некий процесс А. При помощи kerberos'а и иды был выявлен алгоритм инжекта:

И все казалось бы хорошо, но библиотека в конечном результате работает и делает свое черное дело, но вот в списке модулей загруженных А ее нет. Есть варианты почему?

ЗЫ Правда при более тщательном разборе полета оказалось, что третья строка выглядит так:
, где UserName - имя текущего и единственного юзеракомпа.

Это сообщение отредактировал(а) ASGDeveloper - 15.12.2007, 20:54

А как ты его получаешь ?



Перехват API ?

Смотрю в Process Explorer.

Попробуй использовать менее известную программу или получать список вручную,
желательно парой различных способов.

Пробовал и менее известную. И сам через ModuleFirst-ModuleNext (вроде так они называются) Но сразу говорю, по идее dll-ка скрываться не должна.

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



У тебя есть исходники и ее и "инжектора", что ты можешь утверждать что они делают, а чего нет ? 

Нить это поток?



С идой я могу утверждать. 

Да, причем не обязательно именно тот же, который загружал библиотеку.



Кто такая "идоа" ?

Что показала попытка удаления файла библиотеки после инжекта ?

IDA


Это сообщение отредактировал(а) bartram - 16.12.2007, 15:36

Спасибо. Буду знать.

P.S.
 Просто из любопытства: 
  неужели с ее помощью можно получить уверенность, что знаешь все фокусы, которые
  подопытный процесс может выкинуть ?  (Не положив пару лет на его изучение   )

Файл кто-то держит и он не удаляется. Анлокер (unlocker) не видит.


Мы с идочкой выделили несколько основных процедур и ее возможности позволяют дойти до таких вот подробностей:


Это сообщение отредактировал(а) ASGDeveloper - 16.12.2007, 16:53

Ну вот видишь. А ты говорил "не прячется"   

Теперь, когда все встало на свои места, осталась только техника.

Получаем "не хакнутый" список модулей, находим нужный, пробуем анлоадить
его и смотрим, что получится   

Как например? 

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

Попробую на словах.

1. Мапим файл DLL в которой находится интересующая нас функция ( Почти всегда это NtDll.dll ).
2. В замапеном образе пробегаемся по его IMAGE_EXPORT_DIRECTORY.
    и находим интересующую нас функцию.
3. Сравниваем "адреса" (плохое название, но не знаю как обозвать.  м.б. смещения ?),  
    того что возвращает GetProcAddress и ф-ии из замаплиного образа.
4. Различаются - мы "хакнуты". Вызываем функцию, используя полученный нами "адрес" из мапа.
    Она и даст нам искомое.

Сумбурно получилось, но надеюсь понятно   

Я знаю как это делать  Но похоже одним из условий здесь является невмешательство в процесс "потерпевшего" приложения. Может есть еще какие варианты?

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

Как без "вмешательства" не знаю.
Может перед стартом инжектора залезать только в него, перехватывать 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.
 Сам инжектор может внедрять только в один, а дальше она сама со всем справиться.
 Вариантов миллион