Здравствуйте!
Есть пара вопросов по работе с памятью и о памяти. Они, кончено, к крэкингу имеют весьма посредственное отношение, но надеюсь, вы все же поможете разобраться

Дж. Рихтер "Создание эффективных WIN32-приложений с учетом специфики 64-разрядной версии Windows" цитата:
При запуске загрузчик операционной системы выполняет следующие операции:
1.Загрузчик операционной системы создает виртуальное адресное пространство для нового процесса и проецирует на него исполняемый модуль.
2. <...>

Интересует следующее:
...создает виртуальное адресное пространство для нового процесса и проецирует на него исполняемый модуль.

Я как понимаю...
Предположим у нас машина с ОЗУ 512 Мб. 512 Мб свободно.
Запускаем somefile.exe размером 10 Мб.
Создается процесс. У него виртуальная память 4 Гб. Вся свободная.
В ней выделяется 10 Мб адресного пространства под код и данные того же размера.

Вопрос: сколько ОЗУ памяти будет свободно после запуска? 502 Мб и файл somefile.exe будет переписан непосредственно в ОЗУ?
Или 512, а 10 Мб с винчестера(содержащие exe-файл) будут использоваться как будто они в ОЗУ памяти?

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

alex78rus пишет:
Вопрос: сколько ОЗУ памяти будет свободно после запуска? 502 Мб и файл somefile.exe будет переписан непосредственно в ОЗУ?
Хз. Как винда решит. У нее же есть возможность свопить RAM. Т.е. часть exe может попасть в RAM, а другая часть в swap-файл.

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

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

Hexxx пишет:
Хз. Как винда решит. У нее же есть возможность свопить RAM. Т.е. часть exe может попасть в RAM, а другая часть в swap-файл


Файл подкачки служит "продолжением" оперативной памяти. Если одновременно запустить несколько приложений, занимающих большой объем оперативной памяти, то может получиться так, что физического объема установленной оперативки не хватает для всех программ. Тогда Windows переносит данные неактивных программ из оперативной памяти в виртуальную. При обратном переходе данные из файла подкачки переносятся в оперативку.

-----
Что один человек сделал , другой всегда сломать может...

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

окей. тада конкретезирую вопрос.

я так понимаю программа может запустится по одному из трех сценариев:
1. Непосредственно из ОЗУ.
2. Из файла подкачки(возможно, что это будет не конкретно он, а проекция файла) - с помощью механизма проекции на виртуальную память.
3. Часть - в ОЗУ, часть в страничном файле.

(...это так или я ошибаюсь?)

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

Hexxx пишет:
Хз. Как винда решит. У нее же есть возможность свопить RAM. Т.е. часть exe может попасть в RAM, а другая часть в swap-файл.
+1

alex78rus
Есть проги, отслеживающие потребление различных ресурсов в real-time. К примеру, Norton System Doctor из пакета NU.


PM=Physical Memory=RAM
SFU=Swap File
Как видно, в приведенном примере винда полностью сидит в RAM и не юзает своп.

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

2 0xy
У мя сча стоит TuneUp Memory Optimizer (из TuneUp Utilities) - там тож есть возможно просматривать состояние ОЗУ/свап-файла в реал-тайме(хотя это не основная задача данного приложения). Мне важна не загруженность ресурсов моей системы, а количество ресурсов потребляемых отдельной программой. Norton System Doctor, как я понял, такого анализа не дает...

И все же мне так никто и не дал ответа на вопрос:
как подготавливается к запуску загрузчиком ехе-файл?
1. целиком он загружается в ОЗУ? или постепенно представлениями?
2. можно ли запустить программу если она проецируется(MapViewofFile) в память с винчестера? (т.е.
находится в свапе)

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

тоже раньше заинтересовал даный вопрос, т.к. был у меня файл установки (setup.exe, inno setup) на полтора гига. если запускал его, установка так и не начиналась (озу у меня гиг). наверное винда его старалась целиком в оперативу засунуть и потом пустить, но памяти не хватало и она его сразу же пихала у свап, что и тормозило процес загрузки (хотя по моему setup.exe както сама должна была бы определить, стоит ли ей целиком грузиться или нет).
но если переделать установку и сделать отдельно загрузчик устанвки setup.exe (~ полмега) и отдельно архивы (setup-x.bin) то установка идет нормально.
но как мне кажеться винду можно настроить так, чтоб например целый полторагиговый файл не закидывался в озу целиком, а по мере необходимости. етим наверное и занимаються сторонние утилиты (у меня стоит O&O CC).

может кто-то сможет пролить свет на ето дело?

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

alex78rus пишет:
1. целиком он загружается в ОЗУ? или постепенно представлениями?
Все секции которые должны быть в памяти (по атрибутам) будут загружены и память под них будет выделена. Часть уйдёт в swap но это дело memory manager-а, более высокие подсистемы об этом не знают - и плевать. Архетиктура специально аостроена таким образом.

alex78rus пишет:
2. можно ли запустить программу если она проецируется(MapViewofFile) в память с винчестера?
Выше я уже ответил. Если какх-то страниц виртуального пространства нету в реальной памяти то происходит исключение и memory manger их подгружает с диска.

Evol пишет:
тоже раньше заинтересовал даный вопрос, т.к. был у меня файл установки (setup.exe, inno setup) на полтора гига. если запускал его, установка так и не начиналась (озу у меня гиг)............
Несмотря на то что файл на гиг, одна (или более) секции это данные и они могут не грузиться в память. То есть, для них не указан vitual address. Такие данные прога будет читать с диска.

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

По дизайну ОС, программа может запуститься только по одному сценарию - из exe файла на диске создайтся объект ОС "секция" (в терминах Win32 - Memory Mapped File; см. "проецирует ... исполняемый модуль"). На этом этапе чтение файла с диска не происходит. Данные будут считаны (в выделенную прозрачно для пользователя физ. память) при попытке чтения из адресов куда отмаплена секция. При нехватке физической памяти такие данные не сохраняются в своп, а просто отбрасываются, при необходимости читаются опять из оригинала. Это очень важный момент, поэтому не стоит паковать исполняемые файлы. Если данные образа модифицируются то ОС вынуждена сохранять их в файл подкачки. На эту тему была статья f0dder (на русском ищи "перевод" Касперски, что-то о вреде упаковки).

Hexxx пишет:
Хз. Как винда решит.
Это не совсем так. См. Process Working Set & VirtualLock

Evol пишет:
был у меня файл установки (setup.exe, inno setup) на полтора гига. если запускал его, установка так и не начиналась (озу у меня гиг). наверное винда его старалась целиком в оперативу засунуть и потом пустить, но памяти не хватало
А что писала винда? Не хватает _виртуальной_ памяти?

s0larian пишет:
Несмотря на то что файл на гиг, одна (или более) секции это данные и они могут не грузиться в память. То есть, для них не указан vitual address. Такие данные прога будет читать с диска.
С оверлеем не перепутал?

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

Вопрос очень интересный, сам до конца не разобрался в нём.. Вот если ПЕ отобразился в оперативку, а под скажем последние 2 секции не хватила места, то ОС сбрасывает их в своп. Допустим ПЕ начинаецо с адреса (линейного в оперативке) 0xXXXXXXXX и места хватило только для его куска размером в 0x60000000. Образ ntdll.dll и kernel32.dll нопремер уйдут в своп? А при вызове апей код будет читацо с диска и исполянцо или все же страница спроецируецо куда-то в оперативку? Ведь насколько я понял, когда например создаём мапенг MapViewOfFile, то файл сам по себе становицо свопом, но образ занимает реальное место в оперативке при этом, а какой-то механизм ОС записывает все изменения из отображенного образа на диск.. %))

з.ы. дайте ченить почитать внятное по сабжу

-----
invoke OpenFire

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

Ice-T пишет:
Вот если ПЕ отобразился в оперативку, а под скажем последние 2 секции не хватила места, то ОС сбрасывает их в своп.
Прочитай внимательно выше. При отображении физпамять не выделяется. Выделяется только при доступе - то есть возможно, что некоторые страницы вообще никогда не будут считаны с дистка. Если при доступе к "последним 2м секциям" не окажется свободных страниц, то менеджер памяти освободит (возможно выгрузит) страницы к которым не быдо доступа долше других. Про работу MMF должно быть у того же Рихтера.

Ice-T пишет:
места хватило только для его куска размером в 0x60000000
Если нет непрерывного свободного места по ImageBase (и образ нерелоцируем) то секция не будет создана и PE image не будет загружен.

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

S_T_A_S_ пишет:
Если нет непрерывного свободного места по ImageBase

При создании процесса подготавливается его собственное виртуальное адресное пространство. Поэтому разумный адрес ImageBase всегда будет доступен. Вот в случае dll это может быть не так. Мне кажется, что загрузка процесса скорее станет невозможна в случае полного израсходования хэндлов GDI, или входов PTE, или будет достигнут конец верхней границы в swap файле и его расширение невозможно.

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

Кароче нихера не понятно. Не поверю, что при отображении не выделяецо ни байта физ. памяти.

-----
invoke OpenFire

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

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

-----
invoke OpenFire

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

S_T_A_S_ пишет:
Evol пишет:
был у меня файл установки (setup.exe, inno setup) на полтора гига. если запускал его, установка так и не начиналась (озу у меня гиг). наверное винда его старалась целиком в оперативу засунуть и потом пустить, но памяти не хватало
А что писала винда? Не хватает _виртуальной_ памяти?

в 32-разрядной Windows виртуальная память 4 Гб, из которой под пользовательские приложения выделяется 2 Гб.

s0larian пишет:
Все секции которые должны быть в памяти (по атрибутам) будут загружены и память под них будет выделена. Часть уйдёт в swap но это дело memory manager-а, более высокие подсистемы об этом не знают - и плевать. Архетиктура специально построена таким образом.Если какх-то страниц виртуального пространства нету в реальной памяти то происходит исключение и memory manger их подгружает с диска.

пока это самое толковое, что написано тут по сабжу по-моему, примерно понятно, спасибо!

Вот тока что обязательно подгружеатся в память первым? "Порция" кода определенного размера? Или определенная функция целиком?

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

S_T_A_S_ пишет:
А что писала винда? Не хватает _виртуальной_ памяти?
если бы) файл подкачки у меня на 1,5 гига (только что пробовал и при 512 мег, еффект тот самый - запуск через 3-5 мин). когда запускаю setup.exe то он не залолняеться. на вкладке "Быстродействие" в диспетчере задач в групе "Физическая память" можно наблюдать как значения "Доступно" и "Системный кэш" постоянно увеличиваються (причем "Доступно" то увеличивается то уменьшается). запуск происходит когда значения >700000.
файл подкачки остаеться не тронут и занимает гдето в районе 247 мег (а вот сейчас при запущеной опере он 406 мб, а значения "доступно" 559024 и "сис. кэш" 517412 и постоянно колеблятся).

ну мне вроде стало понятно с секциями, но все же, как я говорил раньше, не мойму почему если файл setup.exe большой он запускається дольше чем если малого размера, ведь секции, которые должны быть загружены в память одинаковые (или ето не так?).

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

Evol пишет:
был у меня файл установки (setup.exe, inno setup) на полтора гига
Уверен, что львиная доля файла - это оверлей. Инсталлеры походу хранят все необходимые данные для установки именно там.

S_T_A_S_ пишет:
По дизайну ОС, программа может запуститься только по одному сценарию - из exe файла на диске создайтся объект ОС "секция" (в терминах Win32 - Memory Mapped File; см. "проецирует ... исполняемый модуль"). На этом этапе чтение файла с диска не происходит. Данные будут считаны (в выделенную прозрачно для пользователя физ. память) при попытке чтения из адресов куда отмаплена секция. При нехватке физической памяти такие данные не сохраняются в своп, а просто отбрасываются, при необходимости читаются опять из оригинала. Это очень важный момент, поэтому не стоит паковать исполняемые файлы.
+1
Именно на этом и устроена защита ПЕПа раздутием секции - если программа запускается без помощи отладчика, то этот "галл" вообще не присутствует в оперативной памяти. Если же мы юзаем отладчик и заставляем систему реально создавать эти страницы, то как раз начинаются лаги из-за нехватки памяти.

s0larian пишет:
Несмотря на то что файл на гиг, одна (или более) секции это данные и они могут не грузиться в память. То есть, для них не указан vitual address. Такие данные прога будет читать с диска.
Не проецируется только та часть файла, которая не захватывается SizeOfHeaders и каждой из секций.

sss пишет:
Поэтому разумный адрес ImageBase всегда будет доступен.
Не совсем - непосредственно до маппинга основного модуля грузится модуль ntdll, который занимает свое место в адресном пространстве процесса.

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

alex78rus пишет:
Вот тока что обязательно подгружеатся в память первым? "Порция" кода определенного размера?

Весь код! Сам ведь выделил: "Все секции которые должны быть в памяти (по атрибутам) будут загружены и память под них будет выделена". Надо добавить "будут загружены в виртуальную память". А вот размером скользящего окна физической памяти будет управлять VMM.
Получить значения этого параметра - GetProcessWorkingSetSizeEx(). Надоело писать, вырежу прямо из MSDN:

The "working set" of a process is the set of memory pages currently visible to the process in physical RAM memory. These pages are resident and available for an application to use without triggering a page fault. The minimum and maximum working set sizes affect the virtual memory paging behavior of a process.

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

HoBleen пишет:
Не совсем - непосредственно до маппинга основного модуля грузится модуль ntdll, который занимает свое место в адресном пространстве процесса.

Я долго думал выделить жирным слово разумный или нет...

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

alex78rus пишет:
Вот тока что обязательно подгружеатся в память первым?
ИМХО по логике:
1)Хидер
2)Таблица импорта
3)Таблица релоков
4)Тлс табличка
5)Страница кода с ЕР

Evol
А что за инсталлер такой странный?) Можешь скопипастить таблицу секций?

sss пишет:
Я долго думал выделить жирным слово разумный или нет...
Я думал ты имеешь ввиду нижние 2 гигабайта...

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

HoBleen пишет:
А что за инсталлер такой странный?) Можешь скопипастить таблицу секций?
та думал, что стандартный Inno Setup, т.к. разпаковывается innounp. правда почемуто нету свойств файла (таких как в нормальных inno setup установках). при выборе файла в PE Editor (LordPE) выдает ошибку: "Couldn't map file ! Maybe there's not enough memory available !". скопировал из ольки (грузилось 5 мин гдето)) Memory Map (то что относится к установке). еще можно глянуть в exescope))
еще попробую сам инсталятор собрать и потестить. может ето в нем проблема

829e_09.01.2008_CRACKLAB.rU.tgz - pack.zip

попробовал собрать большой инсталятор сам - получается тоже самое: нету значка и свойств файла (от чего бы ето). если создать инсталятор с отдельным setup.exe и архивами то запускаеться нормально. видимо ето у меня что-то с системой

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

alex78rus пишет: 2. можно ли запустить программу если она проецируется(MapViewofFile) в память с винчестера? (т.е. находится в свапе) можно, если спроецировано с флагом PAGE_EXECUTE...что само собой говорит о том что файл проецируется не "на винчестер"

-----
продавец резиновых утёнков

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

S_T_A_S_ пишет:
s0larian пишет:
Несмотря на то что файл на гиг, одна (или более) секции это данные и они могут не грузиться в память. То есть, для них не указан vitual address. Такие данные прога будет читать с диска.
С оверлеем не перепутал?
Ээээ, приврал я тут. В виндах адресное пространство процесса состоит из секций файла, явно импортированных dlls, и, ессно, виндовских dll-ок.

В ELF структуре debug инфа живёт в секции, которая не является частью адресного пространства и не имеет виртуального адреса. Но, это никого не парит, т.к. не в эту тему

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

HoBleen пишет:
Не совсем - непосредственно до маппинга основного модуля грузится модуль ntdll, который занимает свое место в адресном пространстве процесса. -не факт. В первой структуре загрузчика PEB_LDR_DATA->InLoadOrderModuleList.Flink сначала идет указатель на структуру описывающую процесс, только затем ntdll, и далее по порядку на загруженные модули процесса. Таким образом сначала проецируется исполняемый модуль, а только затем все остальное. Рихтер как всегда прав.

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

sss пишет:
загрузка процесса скорее станет невозможна в случае полного израсходования хэндлов GDI
Не пробовал, да и сложно при этом запустить процесс - у эксплорера сносит крышу Но сталкивался с тем что 200Mb exe не запускался на 2К со старым СП.

alex78rus пишет:
в 32-разрядной Windows виртуальная память 4 Гб, из которой под пользовательские приложения выделяется 2 Гб.
Ну это максимальный. А размер свопа какой? ;) Он нужен что бы выгрузить (чужие) модифицированные страницы при нехватке физических страниц для текущего процесса.

Evol пишет:
файл подкачки остаеться не тронут и занимает гдето в районе 247 мег
Минимальный и максимальный размер задаются и могут быть одинаковыми.

HoBleen пишет:
Уверен, что львиная доля файла - это оверлей.
Похоже что так, поэтому и пауза при его чтении.

PS вот нашел оригинал стотьи f0dder.reteam.org/packandstuff.htm

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

К предыдущему посту: пример отображающий по-порядку кто за кем был загружен призагрузке программы загрузчиком винды:

3016_10.01.2008_CRACKLAB.rU.tgz - Loader_order.exe

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

S_T_A_S_ пишет:
Минимальный и максимальный размер задаются и могут быть одинаковыми.
причем тут ето? у меня и мин. и макс. размер равны 1536 мег, и ето означает только то что таким он останеться на диске.

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

Обычно большие инсталяторы хранят свой большие данные как Extra Данные, т.е. они не прописаны
как маппируемая секция, а как привязка к хвосту файла, WINDOWS на них не обращает внимания.
Загрузчик смотрит только маппируемые секции, идущие подряд.
Вообще при загрузке Windows (с NT) проверяет (видел в дебрях кода) размер маппируемых секций,
т.к. они идут одна за одной, на предмет размера порядка 472 МБайта.
Для провеерки делал файлы больше 512 МБайт (естественно, маппируемые секции).
На доступных мне ОС и SP загрузчик "тихо" умирал.
Иногда даже без посмертной инфы.
Работа ОС продолжала быть нормальной.
Т.е. прога игнорировалась.
Т.е. эта цифра близка к РЕАЛЬНО РАСЧИТЫВАЕМОЙ и используемой виртуальной памяти с учетом ОЗУ.
Виртуальная память >= 1,5 размера ОЗУ

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

Система всегда сама увеличивает файл подкачки, чего бы вы не задавали. Размер свопа ограничивется только размером диска. Если своп вообще запретить, система создаст его при нехватке оперативки в корне диска, где установлена винда. Если ты задаешь размер свопа то он создается именно в таком размере сектора, которые пока не используются забивается нулями.

-----
продавец резиновых утёнков

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

HiEndsoft

Cистема мелкомягких содержит слишком много казусов, не опыысываемых логикой.
Например, загрузчик ОС проверят расстояние до NTHEADERs по $3C DOSHEADER.
И оно не может быть больше 256 Мбайт(???).
Т.е. следуя логике мелкомягких РЕ-файл МОЖЕТ содержать примерно 256 МБайт
между DOS и NT хидерами!!!
Вопрос, будет ли маппироваться вся эта область????
Обычно весь DOS + NT Headers укладываются в пределы 4 - 8 Кбайт.
Как будет маппироваться (и будет ли) весь NTHRADERS с табличками???
Вопрос: будет ли работать так постоенный РЕ-файл
Ответ - будет!
И ОС наплевать на всю инфу до NT Headers !!!
Для него "настоящий" РЕ файл на диске начнётся с NTHeaders , ну а дальше уже по
неписанным правилам мелкомягких.
Что делает система с виртуальной памятью В ДЕЙСТВИТЕЛЬНОСТИ при раскрутке нового
процесса, я не нашёл нигде.
Но мы сами можем во всю использовать виртуальную память в своих программах,
выделяя её (все функции Virtual...) после старта своей программы.

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