Размер сегметна код и данных
Как в ручную задать размеры сегментов?
Должны ли они быть кратны 512 для win32?
Должны ли они быть кратны 512 для win32?
В исполняемых файлах PE имеет место понятие секция, а не сегмент. Вручную размеры можно задать, при этом они могут быть любыми, в том числе могут быть сегменты по любому смещению в файле. В заголовке PE по поводу выравнивания есть какие-то переменные.
Надеюсь, я вас правильно понял.
Надеюсь, я вас правильно понял.
в PE файле секции физически должны быть выровнены на границу кластера т.е. 512 или 1024, 2048...., а виртуально на границу страницы т.е. на 4 КБ. мне кажется автору нужно что-то другое.
в Win32 есть 4 сегмента которые полностью охватывают виртуальную память процесса.
1. Сегмент данных с DPL 3
2. Сегмент кода с DPL 3
3. Сегмент данных с DPL 0
4. Сегмент кода с DPL 0
и ещё несколько штук, но они почти не используются
изменить в user mode их нельзя. в kernel mode их изменить можно, вот только это повлечёт за собой BSOD
вопрос пожалуйста конкретнее.......
в Win32 есть 4 сегмента которые полностью охватывают виртуальную память процесса.
1. Сегмент данных с DPL 3
2. Сегмент кода с DPL 3
3. Сегмент данных с DPL 0
4. Сегмент кода с DPL 0
и ещё несколько штук, но они почти не используются
изменить в user mode их нельзя. в kernel mode их изменить можно, вот только это повлечёт за собой BSOD
вопрос пожалуйста конкретнее.......
Цитата: ahilles
в PE файле секции физически должны быть выровнены на границу кластера т.е. 512 или 1024, 2048...., а виртуально на границу страницы т.е. на 4 КБ. мне кажется автору нужно что-то другое.
в Win32 есть 4 сегмента которые полностью охватывают виртуальную память процесса.
1. Сегмент данных с DPL 3
2. Сегмент кода с DPL 3
3. Сегмент данных с DPL 0
4. Сегмент кода с DPL 0
и ещё несколько штук, но они почти не используются
изменить в user mode их нельзя. в kernel mode их изменить можно, вот только это повлечёт за собой BSOD
вопрос пожалуйста конкретнее.......
в Win32 есть 4 сегмента которые полностью охватывают виртуальную память процесса.
1. Сегмент данных с DPL 3
2. Сегмент кода с DPL 3
3. Сегмент данных с DPL 0
4. Сегмент кода с DPL 0
и ещё несколько штук, но они почти не используются
изменить в user mode их нельзя. в kernel mode их изменить можно, вот только это повлечёт за собой BSOD
вопрос пожалуйста конкретнее.......
Мне нужен физический размер
И я так понял exe не может быть меньше 1кб
Может. Можно скомпилировать ассемблером программу без использования API, а затем взять LordPE и над этой программой провести операцию Rebuild PE. Размер уменьшится за счет обрезания ненужных байт в файле.
А чем так страшны API?
Они страшны тем, что из-за них компилятор создает еще таблицу импорта, если уж писать самую маленькую программу то лучше без API делать, и соответственно без таблицы импорта.
Я забил в программе в 2кб поиск kernel32.dll, генерацию таблицы импорта, создание консоли, вывод текста туда, и ожидание нажатия Ctrl+C. Это я еще не оптимизировал ее по размеру, а так она где-то 1.3-1.5кб весила бы.
Я забил в программе в 2кб поиск kernel32.dll, генерацию таблицы импорта, создание консоли, вывод текста туда, и ожидание нажатия Ctrl+C. Это я еще не оптимизировал ее по размеру, а так она где-то 1.3-1.5кб весила бы.
Мне бы ручками (без упаковщика) обрезать код и данные.
Это надо в ПЕ заголовке копаться или средствами ассемблера можно?
Это надо в ПЕ заголовке копаться или средствами ассемблера можно?
Средствами ассемблера можно, только есть взять FASM и все заголовки с помощью переменных прописать ))
Пожалуй проще покопаться в заголовке PE и исправить нужные значения. Ручками обрезать очень быстро задолбаться можно, поэтому проще на каком-нибудь C или C++ прогу написать, тем более что в стандартных win32 заголовках описаны форматы таблиц PE и MZ (не помню точно где)
Пожалуй проще покопаться в заголовке PE и исправить нужные значения. Ручками обрезать очень быстро задолбаться можно, поэтому проще на каком-нибудь C или C++ прогу написать, тем более что в стандартных win32 заголовках описаны форматы таблиц PE и MZ (не помню точно где)
Большое спасибо!
Народ, а я на VSC++ прогу писал с API, которая 700 байт весит. Это я к тому, что нет ничего невозможного ;)
Цитата: Vedrus
Народ, а я на VSC++ прогу писал с API, которая 700 байт весит. Это я к тому, что нет ничего невозможного ;)
В Windows миниматьное выравнивание секций 512 байт, т.к. PE-формат предпологает заголовок, размер которого отнюдь не нулевой, то секция кода начнется как минимум с 512 байта и будет как минимум 512 байт. И того, минимальный размер - 1кб.
Конечно, можно выбросить нули, которые добивают секцию кода до 512 байт, но это будет нарушением формата PE-файлов и не все загрузчики его загрузят.
Т.о. минимальный валидный PE-файл может быть не менее 1кб.
P.S. А невалидный может быть и вовсе равен нулю. :D
Господин, пенсионер, кто Вам сказал, что минимальное выравнивание должно быть 512 байт? Не все загрузчики? Главное чтобы стандартные виндовые грузили, ну а остальные наверное такие же как Вы писали. Кстати, вот вам exe и исходники.
Цитата: Vedrus
Господин, пенсионер, кто Вам сказал, что минимальное выравнивание должно быть 512 байт?
Спецификация формата PE. Слыхали о такой?
http://www.microsoft.com/whdc/system/platform/firmware/PECOFFdwn.mspx?
Цитата:
FileAlignment
The alignment factor (in bytes) that is used to align the raw data of sections in the image file. The value should be a power of 2 between 512 and 64 K, inclusive. The default is 512. If the SectionAlignment is less than the architecture’s page size, then FileAlignment must match SectionAlignment.
Короче на лицо факт путаницы понятий внутрифайловое выравнивание секции и выравнивание секции в памяти! В памяти секции с взаимоисключающими атрибутами должны выравниваться как минимум по границам страниц, а внутри файла так, как взбредет в голову разработчикам формата исполняемых файлов. К слову сказать, формат файлов, используемый сейчас в моей оси допускает побайтовое внутрифайловое выравнивание секции, хотя по опыту могу сказать, что лучше выравнивать секции внутри файла на границу машинного слова - так будет меньше аппаратных издержек при копировании данных из дискового буфера.
Честно говоря я не вижу разницы в файловом выравнивании на 4 и на 1 байт... Все зависит от реализации подпрограммы считывания из дискового буфра. Можно ведь считать сначала тот кусок данных, который не выровнен, а потом считывать по 4/8 байт. А можно считывать по одному байту и никакая оптимизация не поможет..
Прошёл по данной ссылке, и получил следующее сообщание.
We’re sorry, but we were unable to service your request
Если уж ссылаться на MS, то VS тоже они написали. Тогда что же получается MSVC++ генерит exe-шники для инвалидов?
We’re sorry, but we were unable to service your request
Если уж ссылаться на MS, то VS тоже они написали. Тогда что же получается MSVC++ генерит exe-шники для инвалидов?
Хм.. у меня все скачалось.. Красивый документ 1.3 мб, надо будет как-нибудь почитать :)
PS: спасибо за пример :)
PS: спасибо за пример :)
Цитата: Phantom-84
а внутри файла так, как взбредет в голову разработчикам формата исполняемых файлов. К слову сказать, формат файлов, используемый сейчас в моей оси
Мы вообще-то про PE-формат говорили. При чем тут твоя ось? Не вноси "путаницы понятий"
Какая путаница? Phantom-84 говорил про практику, а вы про теорию. Сейчас стоит вопрос по практике: "можно ли руками задать выравнивание?", если кто-то знает реальные границы файлового вырванивания в Windows, скажите плз, а то далеко не всех 512 байт устраивает..
Цитата: disasm
Какая путаница? Phantom-84 говорил про практику, а вы про теорию. Сейчас стоит вопрос по практике: "можно ли руками задать выравнивание?", если кто-то знает реальные границы файлового вырванивания в Windows, скажите плз, а то далеко не всех 512 байт устраивает..
Ты собираешься писать программы для ОС Phantom-84 или под Windows?
Если под Windows и корректные приложения, то смотри спецификацию - 512 байт.
Спецификация - это не теория, а технический документ.
Вот несколько выгрызок из книги Криса Касперски, надеюсь представлять не надо?
Знакомство читателя с PE-форматом не входит в нашу задачу, и предполагается, сто некоторый опыт работы с Пешками у него уже имеется. Существует множество описаний PE-формата, но среди них нет ни одного по-настоящему хорошего. Официальная спецификация (Microsoft Portable Executable and Common Object File Format Specification), написанная двусмысленным библейским языком, скорее напоминает сферического коня в вакууме, чем практическое руководство. Даже среди сотрудников Microsoft нет единого мнения по поводу того, как её толковать, и различные системные загрузчики ведут себя сильно неодинаково. Что же касается сторонних разработчиков, то здесь и вовсе царит полная неразбериха.
Структура PE-файла состоит из заголовка (header), страничного имиджа (image page) и необязательного оверлея (overlay). Представление PE-файла в памяти называется его виртуальным образом (virtual image), или просто образом, а на диске – файлом, или дисковым образом. Если не оговорено обратное, то под образом всегда понимается виртуальный образ
Дисковый файл и его виртуальный образ – это, как говорят в Одессе, две большие разницы.
Цитата:
Знакомство читателя с PE-форматом не входит в нашу задачу, и предполагается, сто некоторый опыт работы с Пешками у него уже имеется. Существует множество описаний PE-формата, но среди них нет ни одного по-настоящему хорошего. Официальная спецификация (Microsoft Portable Executable and Common Object File Format Specification), написанная двусмысленным библейским языком, скорее напоминает сферического коня в вакууме, чем практическое руководство. Даже среди сотрудников Microsoft нет единого мнения по поводу того, как её толковать, и различные системные загрузчики ведут себя сильно неодинаково. Что же касается сторонних разработчиков, то здесь и вовсе царит полная неразбериха.
Цитата:
Структура PE-файла состоит из заголовка (header), страничного имиджа (image page) и необязательного оверлея (overlay). Представление PE-файла в памяти называется его виртуальным образом (virtual image), или просто образом, а на диске – файлом, или дисковым образом. Если не оговорено обратное, то под образом всегда понимается виртуальный образ
Цитата:
Дисковый файл и его виртуальный образ – это, как говорят в Одессе, две большие разницы.
Обратите внимание на выделенное жёлтым шрифтом, и посмотрите и обратите внимание на заголовок 3.4.2. Optional Header Windows-Specific Fields (Image Only)
Т.о. спецификации моя программа не противоречит.
Цитата: disasm
Какая путаница? Phantom-84 говорил про практику, а вы про теорию. Сейчас стоит вопрос по практике: "можно ли руками задать выравнивание?", если кто-то знает реальные границы файлового вырванивания в Windows, скажите плз, а то далеко не всех 512 байт устраивает..
Я на XP пробовал 16 и 32, работает нормально. Конкретных цифр я даже у Криса Касперски не нашёл. Думаю приемлемый способ - поставить виртуальную машину, на неё все возможные ОС, и тестить Пешки на них. Всё заработало – значит пойдёт.
disasm Хотя извиняюсь. Нашёл у Криса Касперски описание проблемы.
В Windows NT существует недокументированная возможность отключения выравнивания, основанная на том, что загрузку прикладных исполняемых файлов/динамических библиотек и системных драйверов обрабатывает один и тот же загрузчик.
Если Section Alignment = File Alignment, то последнее может принимать любое значение, представляющее собой степень двойки (например, 20h).
…
Для создания невыровненных файлов можно воспользоваться линкером от Microsoft, задав ему ключ /ALIGN:32 совместно с ключём /DRIVER. Без ключа /DRIVER ключ /ALIGN будет проигнорирован, и линкер использует кратность выравнивания по умолчанию.
Цитата:
В Windows NT существует недокументированная возможность отключения выравнивания, основанная на том, что загрузку прикладных исполняемых файлов/динамических библиотек и системных драйверов обрабатывает один и тот же загрузчик.
Если Section Alignment = File Alignment, то последнее может принимать любое значение, представляющее собой степень двойки (например, 20h).
…
Для создания невыровненных файлов можно воспользоваться линкером от Microsoft, задав ему ключ /ALIGN:32 совместно с ключём /DRIVER. Без ключа /DRIVER ключ /ALIGN будет проигнорирован, и линкер использует кратность выравнивания по умолчанию.
взято из книги:
Крис Касперски. Компьютерные вирусы изнутри и снаружи.
Спасибо, конечно.. Но тут вопрос о другом. Можно ведь выравнивание руками поставить. Т.е. скомпилировать как обычно, слинковать, а потом в hex редакторе или программой изменить смещение и повыравнивать секции в файле. Вопрос в том, какое граничное выравнивание можно задать, если 1 то это вообще великолепно :)
А в чём смысл его руками выставлять? Объёма это всё равно не уменьшит. Поясни? Директивами /ALIGN и /FILEALIGN можно выравнивание задать. И линкер всё это съест. Правда меньше 4х пока не получилось – выдаёт ошибку “fatal error LNK1164: section 0x4 alignment (4) greater than /ALIGN value”. Вот если бы найти, где выравнивание этой секции задаётся, то и до 1 не далеко ;). Может кто вылечит?
ЗЫ. Ещё у винды пару байт отбил. Пример весит 640 байт.
ЗЫ. Ещё у винды пару байт отбил. Пример весит 640 байт.
Вот. В этом и дело.. Линковщик студии8 уже не хочет понимать директиву /FILEALIGN, да и делать выравнивание через /DRIVER тоже не очень хорошо.. Постараюсь сегодня написать прогу для патчинга файлов с выравниванием на заданную границу (сделать вырванивание в обе стороны)
Господа, а теперь объясните ка, какова же практическая ценность сих манипуляций: мерженья секций и выставления выравниваний? И поняли ли вы последствия онных действий?
PS: Все эти ключеки и методы описаны в DDK/MSDN, и все, кто серьезно пишет драйвера под Windows, да и не только, о них знают.
PS: Все эти ключеки и методы описаны в DDK/MSDN, и все, кто серьезно пишет драйвера под Windows, да и не только, о них знают.
Цитата: disasm
если кто-то знает реальные границы файлового вырванивания в Windows, скажите плз, а то далеко не всех 512 байт устраивает..
выранивание 512 сделано для того чтобы секции в файле были выравнены на границу сектора
Но с учетом того что сектора были на дискетах, а на винтах уже кластеры, можно ставить выравнивание и побольше :)
Ценность? В зависимости от сложности случая можно память серьезно сэкономить. Кроме того метод идеально подходит для уменьшения размера сдампнутых приложений
Ценность? В зависимости от сложности случая можно память серьезно сэкономить. Кроме того метод идеально подходит для уменьшения размера сдампнутых приложений
Green, я лишь подтвердил твою выноску из спецификации по PE, уточнив разницу между внутрифайловым выравниванием и выравниванием в памяти, т.к. до этого в некоторых сообщениях был намек на смешение этих понятий. А свой формат исполняемых файлов я упоминул лишь к слову, как пример того, что внутрифайловое выравнивание в принципе может быть и меньше - все зависит от формата файлов. В эльфе, например, внутрифайловое смещение секции также вполне может быть меньше 512 байт.
Vedrus, на первый взгляд в твоем примере позиция секции кратна 512 байтам, а таблица импорта находится внутри этой секции, что вполне допустимо, на лицо лишь обрезание секции сверху. По поводу внутрифайлового выравнивания секции, меньшего 512 байт, я так и не понял - откуда сведения про 4, 16 и 32 байта? В качестве эксперимента можно действительно проделать то, что предлагает disasm - вручную скомпоновать файл с внутрифайловым выравниванем секций, меньшим 512, позапускать его в разных системах. Если во всех системах загрузчики будут запускать такой файл, то по-моему можно будет сделать вывод, что системы и спецификации к их исполняемым файлам пишут совершенно разные люди, с разным представлением о том, чем допустимо пренебречь, а чем нет.
Крис Касперски пишет (Компьютерные вирусы изнутри и снаружи), что можно любую степень двойки в качестве выравнивания использовать.
В спецификации, например не написано что MZ заголовок может перекрываться с PE заголовком :) Есть примеры, где это так и всё работает. В этом случае PE.база_даных == MZ.указатель_на_PE, в реальности в таблицах можно творить хаос, т.к. многие поля не используются или пренебрегаются...
И еще хотел спросить: есть ли где-нибудь описание полей, идущих за IMAGE_OPTIONAL_HEADER? Можно ли этим простанством пренебречь?
UPD: Нашел уже
UPD: Нашел уже
Цитата: disasm
Ценность? В зависимости от сложности случая можно память серьезно сэкономить. Кроме того метод идеально подходит для уменьшения размера сдампнутых приложений
А теперь стоит подумать еще раз, но уже головой.
В биарнике Vedrus'а есть секция INIT, чья позиция в файле выровнена на 4-байтовую границу (не кратна 512), и есть секция .data, чья позиция кратна 512, но мне кажется лишь потому, что прямо под ней находится таблица секций, т.е. вообще нет свободного места. Кроме того размеры обеих секций внутри файла также кратны четырем. Ха, в том же руководстве прочитал, что оказывается "указатели секций внутри объектников все-таки могут быть выровнены на 4-байтовую границу для улучшения производительности". А в exe-шниках действительно это значение должно быть кратно значению поля FIleAlignment.
Ramon, но речь ведь действительно идет о максимальном уплотнении exe-шника.
И что это дает? уменьшение размеров на диске на Align * (SectionsCount - 1) в лучшем случае, и на несколько страничек в виртуальной памяти, а про структуры создаваеимые операционной системой для каждого процесса, потока и т.д. забываем? Там ваша пара страничек капля в море, а если придираться к каждому байту стоит подумать о том, что неиспоользуемая часть данных или кода не сосвопитцо и будет занимать драгоценные байты на физической странице - ооооо ужоос!!!!! Плюс есть рад последствий о которых здесь никто и думать не хочет или не может. Конечно аццкие вирусописатели это ооооооооооо!!! Вот только всякую дурь надоело читать, и задаватьцо вопросом, что же курит аффтар?
---
Священные места недалеки,
Но нет дорог, ведущих к ним.
Если идти туда, куда укажут вам,
Найдете скользкий,
Покрытый мхом мост.
---
Священные места недалеки,
Но нет дорог, ведущих к ним.
Если идти туда, куда укажут вам,
Найдете скользкий,
Покрытый мхом мост.
Цитата:
Вот только всякую дурь надоело читать, и задаватьцо вопросом, что же курит аффтар?
Да вы батенька, наверно не знаете, кто такой Крис Касперски... Книжки он вирусами назвал, чтобы читателей-чайников отсеять. Там освещены актуальные вопросы по безопасности.
Цитата:
Плюс есть рад последствий о которых здесь никто и думать не хочет или не может.
Ну так просвети. Возможно, это и снизит быстродействие (не тестировал), но тема не об этом, а об уплотнении.
Цитата:
И что это дает? уменьшение размеров на диске на Align * (SectionsCount - 1) в лучшем случае, и на несколько страничек в виртуальной памяти,
Создатели .NET и всякой подобной хрени наверно также и думали... А ещё мне интересно, что они курили, когда сиё творение производили.
А если серьёзно, мне пока не требуется минимальный размер, но мало ли кому надо будет.