Есть лист из либы:



как правильно выгрузить данную либу?

Заранее спс

| Сообщение посчитали полезным:

FreeLibrary

| Сообщение посчитали полезным:

Не катит FreeLibrary, проверил

Var
LibaHandle : Cardinal;
Begin
Libahandle := GetModuleHandle ('MyDll.Dll');
FreeLibrary (LibaHandle);
End;

| Сообщение посчитали полезным:

Выгружаю либу, только непонятно вот тут:

FreeLibrary (Ca);
FreeLibrary (Ca);
FreeLibrary (Ca);



66d9_22.05.2009_CRACKLAB.rU.tgz - Dll.rar

| Сообщение посчитали полезным:

а может
Ca := LoadLibrary('MyDll.Dll');

вот у тебя написано

Ca := GetModuleHandle ('Din.Dll');
LoadLibrary ('Din.Dll');

а GetModuleHandle возвращает хендл загруженного модуля, тоесть в твоём случае возвращаеца 0.

-----
zzz

| Сообщение посчитали полезным:

FreeLibrary прекрасно подходит, но, как говорил Рихтер, тут есть одно но - т.к. количество потоков в приложении, в которое данная либа была внедрена, не всегда (далеко не всегда) равно нулю, это приводит к тому, что для выгрузки из адресного пространства такого процесса данной библиотеки код, её выгружающий, должен выполниться столько раз, сколько потоков имеет процесс. Т.е. проверяем через GetModuleHandle, присутствует ли либа, если возвращается валидный хэндл, то выполняем FreeLibrary, и так столько раз, сколько будет нужно. Так проще, т.к. не нужно вычислять, сколько на данный момент потоков у процесса.

-----
Stuck to the plan, always think that we would stand up, never ran.

| Сообщение посчитали полезным:

ARCHANGEL
Потоки непричём. Существует счётчик загрузок(LDR_DATA_TABLE_ENTRY.LoadCount). Это значение увеличивается каждый раз при вызове функций загружающих модуль и уменьшается при попытках выгрузить соответственно. Если значение станет равным нулю модуль быдет выгружен. Тоесть туда нужно единицу запихать а потом уже выгружать(для статически прилинкованных не прокатит).

| Сообщение посчитали полезным:

плюс к выше сказанному, увеличение идёт функцией LdrAddRefDll.

-----
Shalom ebanats!

| Сообщение посчитали полезным:

Как подсчитать, скока раз надо вызвать FreeLibrary?

| Сообщение посчитали полезным:

50Hz_220B_1200W, может msdn поставишь и избавишь себя и людей от этих вопросов?

| Сообщение посчитали полезным:

качаю сейчас русс. MSDN, потом не буду этих задавать вопросов
______________________________________________________
Лучше плохой учитель, чем хорошая книга

| Сообщение посчитали полезным:

50Hz_220B_1200W пишет:
Как подсчитать, скока раз надо вызвать FreeLibrary?
- через список структур загрузчика как выше написал клерк


| Сообщение посчитали полезным:

Внимательно прочитав Рихтера, нашёл:


На самом деле LoadLibrary и LoadLibraryEx лишь увеличивают счетчик числа поль-
зователей указанной библиотеки, a FreeLibrary и FreeLibraryAndExitThread его умень-
шают. Так, при первом вызове LoadLibrary для загрузки DLL система проецирует об-
раз DLL-файла на адресное пространство вызывающего процесса и присваивает еди-
ницу счетчику числа пользователей этой DLL. Если поток того же процессу вызывает
LoadLibrary для той же DLL еще раз, DLL больше не проецируется; система просто
увеличивает счетчик числа ее пользователей — вот и все.
Чтобы выгрузить DLL из адресного пространства процесса, FreeLibrary придется
теперь вызывать дважды: первый вызов уменьшит счетчик до 1, второй — до О. Обна-
ружив, что счетчик числа пользователей DLL обнулен, система отключит ее. После
этого попытка вызова какой-либо функции из данной DLL приведет к нарушению
доступа, так как код по указанному адресу уже не отображается на адресное простран-
ство процесса.
Система поддерживает в каждом процессе свой счетчик DLL, т. е. если поток
процесса А вызывает приведенную ниже функцию, а затем тот же вызов делает поток
в процессе В, то MyLib.dll проецируется на адресное пространство обоих процессов,
а счетчики числа пользователей DLL в каждом из них приравниваются 1.
HINSTANCE hinstDll = LoadLibrary("MyLib.dllT1);
Если же поток процесса В вызовет далее:
FreeLibrary(hinstDll);
счетчик числа пользователей DLL в процессе В обнулится, что приведет к отключе-
нию DLL от адресного пространства процесса В. Но проекция DLL на адресное про-
странство процесса А не затрагивается, и счетчик числа пользователей DLL в нем
остается прежним.
Чтобы определить, спроецирована ли DLL на адресное пространство процесса,
поток может вызвать функцию GetModuleHandte;
HINSTANCE GetModuleHandle(PCTSTR pszModuleName); •
Например, следующий код загружает MyLib.dll, только если она еще не спроеци-
рована на адресное пространство процесса:
HINSTANCE hinstDll = Get Mod uleH arid le( "MyLib"); // подразумевается расширение .dll
if (hinstDll == NULL) {
hinstDll = LoadLibraryC'MyLib"); // подразумевается расширение .dll

Так что не стоит использовать какие-то не очень документированные структуры, когда документированные просты и понятны.

-----
Stuck to the plan, always think that we would stand up, never ran.

| Сообщение посчитали полезным:

по-моему проще анмепнуть секцию модуля (NtUnmapViewOfSection) и пофигу все эти ссылки

| Сообщение посчитали полезным:

only
Если я правильно понял, то тогда не выполнится код, который должен выполняться по Dll_Process_detach. А это - не есть гуд.

-----
Stuck to the plan, always think that we would stand up, never ran.

| Сообщение посчитали полезным:

ARCHANGEL
ну да.
хуки и подобный мусор конечно снять нужно, перед анмэпом.

| Сообщение посчитали полезным:

> Система поддерживает в каждом процессе свой счетчик DLL, т. е. если поток
процесса А вызывает приведенную ниже функцию, а затем тот же вызов делает поток
в процессе В, то MyLib.dll проецируется на адресное пространство обоих процессов,
а счетчики числа пользователей DLL в каждом из них приравниваются 1.

Полнейший бред, написанный кемто не понимающим что есть поток и процесс. Адресное простнаство не зря называется виртуальным, изолированность это главное требование безопасности.
> NtUnmapViewOfSection
Проекция модуля перестанет существовать в памяти, ссылки на неё останутся, все будут думать что модуль есть, код не выполнит необходимые действия например при выгрузке. В конце концов приведёт к эксцепшину и краху в простейшем случае лоадера.

| Сообщение посчитали полезным:

ARCHANGEL пишет:
На самом деле LoadLibrary и LoadLibraryEx лишь увеличивают счетчик числа поль-
зователей указанной библиотеки, a FreeLibrary и FreeLibraryAndExitThread его умень-
шают. Так, при первом вызове LoadLibrary для загрузки DLL система проецирует об-
раз DLL-файла на адресное пространство вызывающего процесса и присваивает еди-
ницу счетчику числа пользователей этой DLL. Если поток того же процессу вызывает
LoadLibrary для той же DLL еще раз, DLL больше не проецируется; система просто
увеличивает счетчик числа ее пользователей — вот и все.
Чтобы выгрузить DLL из адресного пространства процесса, FreeLibrary придется
теперь вызывать дважды: первый вызов уменьшит счетчик до 1, второй — до О. Обна-
ружив, что счетчик числа пользователей DLL обнулен, система отключит ее. После
этого попытка вызова какой-либо функции из данной DLL приведет к нарушению
доступа, так как код по указанному адресу уже не отображается на адресное простран-
ство процесса.
Истена, файло отдельно проецируется на адресное пространство каждого процесса, иначе завалились бы при первом же сплайсе, счётчики количества LoadLibrary/FreeLibrary реально есть - только что проверил ради интереса, для каждого процесса свой счётчик, считал ранее что для получения адреса загруженной библиотеки не обязательно юзать GetModuleHandleA, можно обойтись и LoadLibrary, а там вон какая фишка

-----
"Пусть видят, что мы не шутим. Стволы для понта, ножи для дела" Lock, Stock & Two Smoking Barrels

| Сообщение посчитали полезным:

Clerk
Проекция модуля перестанет существовать в памяти, ссылки на неё останутся, все будут думать что модуль есть, код не выполнит необходимые действия например при выгрузке. В конце концов приведёт к эксцепшину и краху в простейшем случае лоадера.
скорее всего это верно только для модуля который статически прилинкован.
если иначе, то какие такие необычные ссылки могут быть на модуль(с учетом например того, что все хуки в коде и данных, возможно установленные и данным модулем, сняты, и ссылка на модуль удалена из области памяти лоадера)?
может конечно имеются ввиду потоки которые быть созданы кодом из модуля и могли исполнять код модуля в момент удаления его проекции
тогда можно ловить все без разбора исключения для данного процесса и удалять потоки в контексте которых eip указывает на область памяти модуля
хотя и свои потоки могли оказаться в таком же положении (тоже ведь можно придумать что-то - они все-таки "свои")

| Сообщение посчитали полезным:

Этот текст написан для винды 9х, где либы были 1 на все процессы. Изменение либы в 1 месте, меняло её везде. Поэтому текст не совсем бред, просто старый и уже неактуален.

| Сообщение посчитали полезным:

only
> какие такие необычные ссылки могут быть на модуль
Запись в лдр. Любая функция из Ldr* юзает проверку валидности хидера к примеру, RtlImageNtHeader(), хотя и заключена в сех чтоб не упала, но это общее состояние загрузчика нарушит. Как же импорт/экспорт - другие модуля будут обращаться в никуда, а внутренние хэши, нотификаторы и пр.

| Сообщение посчитали полезным: