-
> Вот именно для этого ты и вызываешь PostThreadMessage(tid,
> 0, 0, 0) сразу после вызова ф-ции, устанавливающей хук.
Я имел ввиду и все остальные сообщения вместе взятые...
> Т.о., если эти условия заведомо не выполняются, но хук-модуль
> с какого-то перепугу исчезает из АП "жертвы", то это уже
> паранойя)
Видимо так... Ладно, отдам сотрудникам на тестирование... если пойдёт без ошибок, то просто забью....
-
> вызывается DLLEntryPoint с параметром DLL_PROCESS_DETACH
А как ты этот факт определил ?
-
> А как ты этот факт определил ?
мну там логирующая процедура
-
> мну там логирующая процедура
>
А про возможности встроенного отладчика ты, конечно, ничего не слышал ?
-
> А про возможности встроенного отладчика ты, конечно, ничего
> не слышал ?
Ну, давай, апостол, затронь мою душу... :)
-
Отладчиком по душе - это ж не серпом по фаберже) ..
-
> Отладчиком по душе - это ж не серпом по фаберже) ..
главное Ctrl+F2 не нажимать х_х..
вот я и использую логи, ибо при создании серверной части надо было отслеживать поведение внедряемой чати в рантайме.
Ну и получается красиво.. парами... Загрузился-выгрзился, зугрузился- выгрузился....
-
> использую логи, ибо при создании серверной части надо было
> отслеживать поведение внедряемой чати в рантайме
И чем же отладчик не угодил ?
-
> И чем же отладчик не угодил ?
Ничего плохого про него сказать немогу.
Ну пишеться лог:
библеотека в такой то процесс внедренна
...
содержимое перехваченного
...
разные там библиотеки подгруружены в рантайме
...
библеотека в из такого-то процесс извлечена
и что сдесь такого крамольного?
Тем более что по ним можно отследить работу и на других машинах..
-
> что сдесь такого крамольного?
А где лог колбэка ?
Он ведь д.б. вызван аккурат между загрузкой и выгрузкой хук-модуля ..
> по ним можно отследить работу и на других машинах
Ты на своей-то разберись, прежде тыкать свой код, в логике работы которого ты пока еще ничерта не разобрался, на чужую машину)
-
> Ты на своей-то разберись, прежде тыкать свой код, в логике
> работы которого ты пока еще ничерта не разобрался, на чужую
> машину)
Это как это я не разобрался в логике СВОЕГО кода? все логично - страдает концепция, то бишь проект.
> А где лог колбэка ?
зачем? Что в нем может быть интересного?
там же вообще ничего интересного не происходит..
ЗЫ
тестеры ошибок не нашли, за что ещё раз спасибо!
-
> как это я не разобрался в логике СВОЕГО кода? все логично
да уж куда кж логичней - в протоколе фигурирует выгрузка модуля, а модуль при этом как был так и остался в АП)
-
> да уж куда кж логичней - в протоколе фигурирует выгрузка
> модуля, а модуль при этом как был так и остался в АП)
в прошлой "версии" с CreateRemoteThread так оно и было... все выгражалось.. один раз... последний.. )
Но м сйчас он тоже ТОЧНО не останется в АП жертвы после вызова UnHook'а.
-
> сйчас он тоже ТОЧНО не останется в АП жертвы после вызова
> UnHook'а.
да я не об этом)
Вот твои слова:
> библиотека почти сразу выгружется
Как я понял, UnHook ты не вызываешь, но модуль с какого-то перепугу выгружается при заведомо работающем процессе "жертвы", и при всем этом ты видишь, что модуль присутствует в его АП.
Вот ведь кудеса-то !) И ты не разобравшись в них отдаешь свое творение в эксплуатацию, пусть и тестовую ..
-
> Как я понял, UnHook ты не вызываешь, но модуль с какого-
> то перепугу выгружается при заведомо работающем процессе
> "жертвы", и при всем этом ты видишь, что модуль присутствует
> в его АП.
нет, все интереснее, даже, можно сказать, лучше чем я предпологал:
библеотека сама внедряется в процесс когда идут сообщения, а как только они прекращаюся она сам выгружается.... А потом снова как только пойдут сообщения она опять загружается и т. д. Поэтому наличие её потстоянного нахождения в АП жертвы я установить не могу. Только по результатам успешной работы перехватчика...
-
> как только они прекращаюся она сам выгружается.... А потом
> снова как только пойдут сообщения она опять загружается
Быть того не может)
> по результатам успешной работы перехватчика
Если он успешно у тебя работает, то это означает только одно - твой модуль присутствует в целевом АП и никуда он не "выгружался".
Где и какую ты там "выгрузку" узрел - ума не приложу ..
Продолжай разгребать чудеса)
-
где-нибудь дополнительную тестовую запись в лог-файл воткнул с тем же текстом. Текст поменяй в нужном месте и посмотри результат.
-
> Быть того не может)
Может мне глаза врут?
Вот метод обработки
procedure DLLEntryPoint(Reason: DWORD);
begin
case Reason of
DLL_PROCESS_ATTACH:
begin
InitSharedFile;
sg_hwndServer := @sm_lpSharedRec^.m_phwndServer;
sg_bHookInstalled := @sm_lpSharedRec^.m_pbHookInstalled;
sg_hwndTarget := @sm_lpSharedRec^.m_phwndTarget;
sg_bSendMsg := @sm_lpSharedRec^.m_SendResults;
sg_hHookHandle := @sm_lpSharedRec^.m_HookHandle;
DisableThreadLibraryCalls(HINSTANCE);
g_pModuleScope := TModuleScope.GetInstance(
sg_hwndServer,
sg_bHookInstalled,
sg_hwndTarget,
sg_bSendMsg,
sg_hHookHandle
);
g_pModuleScope.ManageModuleEnlistment();
end;
DLL_THREAD_ATTACH:
begin
end;
DLL_THREAD_DETACH:
begin
end;
DLL_PROCESS_DETACH:
begin
g_pModuleScope.HookAll := true;
g_pModuleScope.ManageModuleDetachment();
ReleaseShredFile;
end;
end;
Вот на DLL_PROCESS_ATTACH и DLL_PROCESS_DETACH пишутся соответсвующие сообщения в лог. Строго парами. вот и получается у меня такое впечатление.
-
> // Чтоб потоки не звали ни на что больше не риагировал
> DisableThreadLibraryCalls(HINSTANCE);
а зачем тогда кейсы DLL_THREAD_ATTACH и DLL_THREAD_DETACH в твоем коде фигурируют, раз ты заведомо не хочешь получать эти извещения ?
> g_pModuleScope.HookAll := true;
Что у тебя происходит при этом присвоении ?
-
> а зачем тогда кейсы DLL_THREAD_ATTACH и DLL_THREAD_DETACH
> в твоем коде фигурируют, раз ты заведомо не хочешь получать
> эти извещения ?
Как это..... Reserved... так обычно пишут :)
> Что у тебя происходит при этом присвоении ?
ничего поле присвается а прямую и используется тоько в серверной чати библиотеки при её выгрузке