Сейчас на форуме: UniSoft, zds, ManHunter, rmn (+5 невидимых)

 eXeL@B —› Программирование —› Загрузка DLL в память
Посл.ответ Сообщение

Ранг: 1.2 (гость)
Активность: 0=0
Статус: Участник

Создано: 17 марта 2012 10:29 · Поправил: krait
· Личное сообщение · #1

Приветствую.

Интересует следующий вопрос:
Насколько я понимаю, каждая DLL находится в физической памяти в единственном экземпляре. Потом для каждого процесса, который использует эту DLL, виртуальные адреса проецируются на физические, чтобы имитировать присутствие копии в АП данного процесса (ну про copy on write - это понятно).
Вопрос в том, как загрузчик образа DLL определяет, что DLL уже присутствует в памяти, как он находит этот участок в физической памяти и как принимается решение о загрузке DLL в физическую память в случае ее отсутствия?

Буду благодарен, если кто разъяснит, или хотя бы ткнет в название файла в сорцах Win2k.

p.s. Прошу извинить меня, если запостил не в тот раздел.



Ранг: 617.3 (!), 677thx
Активность: 0.540
Статус: Участник

Создано: 17 марта 2012 10:46 · Поправил: Vovan666
· Личное сообщение · #2

Вот тут что-то есть
http://www.rsdn.ru/article/baseserv/dlluse.xml
кажется еще что-то было на WASM
А лучше создать проект, где подряд идут 2 одинаковых LoadLibrary и отреверсить второй LoadLibrary.




Ранг: 2014.5 (!!!!), 1278thx
Активность: 1.340.25
Статус: Модератор
retired

Создано: 17 марта 2012 10:50
· Личное сообщение · #3

http://blogs.msdn.com/b/larryosterman/archive/2004/07/19/187752.aspx и по ссылкам походить.

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

Ранг: 1.2 (гость)
Активность: 0=0
Статус: Участник

Создано: 17 марта 2012 11:09 · Поправил: krait
· Личное сообщение · #4

Vovan666 пишет:
А лучше создать проект, где подряд идут 2 одинаковых LoadLibrary и отреверсить второй LoadLibrary.


Мне кажется, что в случае загрузки одной и той же DLL в одно и то же адресное пространство алгоритм будет несколько иным и более простым, т.к. проверить наличие DLL в АП текущего процесса, вероятно, проще, чем делать то же в глобальных масштабах физической памяти/объектов ядра. Можно, наверное, просмотреть некий список модулей, принадлежащих данному процессу.
Возможно я и ошибаюсь, проверю.

Vovan666
Archer

Спасибо за ссылки, почитаю.




Ранг: 2014.5 (!!!!), 1278thx
Активность: 1.340.25
Статус: Модератор
retired

Создано: 17 марта 2012 16:38
· Личное сообщение · #5

В пределах одного процесса просто счётчик увеличивается, там совершенно другой механизм, нежели 2 разных процесса.

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

Ранг: 309.8 (мудрец), 21thx
Активность: 0.170
Статус: Участник

Создано: 18 марта 2012 14:02 · Поправил: SLV
· Личное сообщение · #6

LdrAddRefDll если быть точным и суть этого - безопасность при многопоточности. FreeLibrary будет декриментить этот каунтер то тех пор пока там не будет 0 (при нуле выгрузка из АП).

-----
Shalom ebanats!




Ранг: 481.4 (мудрец), 109thx
Активность: 0.180
Статус: Участник
Тот самый :)

Создано: 19 марта 2012 12:29 · Поправил: Hexxx
· Личное сообщение · #7

Это все не то немного. То что описано выше, это пример того как в пределах ring-3 решается проблема повторной загрузки модулей. А человек спросил про физическую память. Это нужно смотреть MiMapViewOfImageSection() и MmLoadSystemImage() - там суть.

-----
Реверсивная инженерия - написание кода идентичного натуральному


| Сообщение посчитали полезным: krait
 eXeL@B —› Программирование —› Загрузка DLL в память
:: Ваш ответ
Жирный  Курсив  Подчеркнутый  Перечеркнутый  {mpf5}  Код  Вставить ссылку 
:s1: :s2: :s3: :s4: :s5: :s6: :s7: :s8: :s9: :s10: :s11: :s12: :s13: :s14: :s15: :s16:


Максимальный размер аттача: 500KB.
Ваш логин: german1505 » Выход » ЛС
   Для печати Для печати