1) Можно ли в С++ (msvc2008) узнать размер и VA секции кода на этапе компиляции
2) Есть модуль с функциями, можно ли на этапе компиляции узнать адреса функций с наименьшим и с наибольшим адресами в исполняемом модуле? 
и вообще, можно ли както отслеживать\влиять на на размещение функций в секции кода, есть ли какие то правила по которым компилятор их размещает?

Это сообщение отредактировал(а) GoldFinch - 1.12.2008, 21:50

смотри #pragma там что-то есть
и в параметрах компилятора/линкера тоже вроде что-то было

Это сообщение отредактировал(а) J0ker - 30.11.2008, 21:42

и как это соотносится с "узнать на этапе компиляции" ?
мне надо параметры в функцию передать, типа
Func(CodeSectionVA,CodeSectionSize)

pragma позволяет разместить код в определенной секции
на этапе компиляции адрес функции узнать нельзя, т.к он будет известен только на этапе линковки.
так-же на этапе компиляции нельзя узнать размер секции - он будет вычеслен на этапе линковки
для решения подобной задачи вам надо разобраться с форматом PE и парсать файл либо его отображение в памяти

нда.... яву есть яву... этапы компиляции... этапы линковки... понакрутили _всякого_
впринципе можно 1 раз вбить константой расположение PE-заголовка и брать rva и filesize 1й секции.
способ кривоват малость, минусы присутствуют, но для большинства случаев покатит 

я так понимаю в msvc2008 нельзя получить\повлиять_на расположение PE заголовка? развечто стаб указать линкеру - так этот стаб еще и вместе с проектом таскать надо
значит надо либо компилить одним и тем же линкером, чтоб размер стаба забитый в код не менялся, либо получать смещение PE-заголовка динамически

можно хоть в шестой версии:
1. пишешь эксплоит, который извлекает VA из образа,
2. открываешь свойства проекта: PreLink-Post Build, размещаешь тут вызов на свой эксплоит, передаешь ему имя файла образа
3. теперь при компиляции проекта, этот эксплоит будет поставлять в проект необходимую тебе информацию, для которой ты его и написал


обмен данными между эксплоитом и программой осуществляешь через файл образа, т.е. зашиваешь эти адреса в какие-нить статические переменные


по той-же схеме, узнать можно все, что тебе требуется

компоновщик может только выровнять сегменты кода, а вот поменять местами, отсортировать - это уже внешнее воздействие на секции в объектных файлах, если знаком с COFF форматом, то понимаешь, что секции можно двигать в любом направлении.

вобщем-то, из всего, что я сейчас написал, "на этапе компиляции" возможным будет только модификация расположения секций и поиск VA через эксплоит, а остальное - получение VA через стат. переменные - это уже всетаки ран-тайм

Добавлено через 10 минут и 46 секунд
я тут немножко перемешал PE и COFF, поэтому для ясности:
COFF сформирован на этапе PreBuild
PE сформирован на этапе PostBuild
на этапе PreLink, еще ничего не сформировано

поэтому, можно на этапе компиляции вклиниться в процесс сборки, например, если перехватить PreBuild и модифицировать какой-нибудь COFF, то на этапе PostBuild эти изменения уже будут включены в образ

в COFF обычно каждая функция имеет свою секцию, либо, по крайней мере, уникальный FPO, поэтому я и объединил понятия функция и секция, т.е. перемещение этих секций в COFF отразится на расположении в образе

GremlinProg, слишком сложно
все VA можно извлечь непосредственно в программе - ничего вызывать не надо - хэндл возвращаемый GetModuleHandle(NULL) численно равен абсолютному адресу расположения отображения файла - далее парсаем и получаем все что нужно

естественно, HMODULE - указатель на образ в памяти, 
вопрос-то стоит иначе:

отсюда и ответ

GremlinProg, все это хорошо, только мне при расшаривании кода к нему сплоет цеплять?


-------------------------
По теме: rva 1й секции = 0x1000, его определять не нада

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

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

вот с этой точки зрения, вполне логично использовать какой-нить уже готовый эксплоит, делов-то - только прописать параметры его запуска и в нашем любимом C/С++ появляется набор каких-нить высокоуровневых инструментов над COFF и/или PE (каких- не знаю, сейчас фантазия выключена, но, по крайней мере, можно значительно расширить к примеру __declspec, который, на самом деле, соответствует спецификации только по нескольким пунктам)



не понял, что значит расшарить код? кому расшарить?

GremlinProg, расшарить - это от слова share, т.е. поделиться с народом.

если кому интересно, то получилось вот так:

не вижу логики, ты же не задаешься вопросом как тебе расшаривать инструменты
MSVC стоит у каждого, кто принимает участие в разработке
эксплоит - тот же инструмент и так же инсталируется на месте

так или иначе, разработка дополнения к компилятору для решения подобной задачи, не соответствует масштабу самой задачи.
кроме того, это дополнение к компилятору будет работать только под конкретную версию конкретного компилятора, что весьма неинтересно. проще тогда уж обрабатывать получившийся PE-файл отдельной прогой.

) я просто выделил самые пустые заявления



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

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

давай разбираться с самого начала, просто спрашивай, какое слово непонятно

GremlinProg, поясни что подразумеваешь под словом "эксплоит"

эксплоит - небольшая консольная программа

> эксплоит - небольшая консольная программа 

вот оно как...  
а зачем обязательно консольная? в чем сакральный смысл больших пустых черных окон?

а при чем тут MSVC? обрабатывать PE-шку я могу и не в IDE, запуская .bat например, тоже кстати консольный о_О
можно вообще прогу не делать, а например скрипт для WinHEX написать, его сразу и запускать...

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

Не будет у тебя никаких черных окон. На этапе сборки проекта весь вывод идет в output, причем без всяких специальных усилий. Именно поэтому и консольная - на кой тебе лишний ГУИ при сборке? Но если хочешь, то бога ради, ограничений нет.
И вообще, ты хочешь, чтобы все твои проблемы тут решили, о которых ничего не говоришь? Ты сам сказал: на стадии компиляции. Строго говоря, это вообще до всяких COFF, т.к. компиляция это и есть преобразование текста в obj. А дальше уже по другому называется. Может, ты диагноз неправильно поставил, и на самом деле можно по-другому, без обработки PE-файла? Не очень понимаю, почему для того, чтобы в функцию передать адрес и размер, нужно их на стадии компиляции узнавать - кто мешает свой образ прямо в процессе выполнения просматривать?

GremlinProg, слово "эксплойт" меня тоже немного напрягло, но поскольку принцип ты хорошо растолковал, то понятно, что ты имел в виду...

Да и искать не надо: dumpbin (из VS) + perl (например ActivePerl)

Earnest, правильно объяснила,
и на счет "на стадии компиляции" - тоже верно, просто в основном в эту формулировку вкладывают смысл: без ран-тайм вычислений, т.е. при сборке. 
GoldFinch вообще путает линковку и компиляцию, причем явно путает, уже несколько раз линковщик называл компилятором, и игнорирует мои поправки

Вот это вообще странно, такие заявления, на самом деле, просто пугают в том смысле, что для них нужно хотя бы понимать, что сборка - это многоуровневый процесс, о чем я уже говорил, а MSVC - набор "левых" инструментов, которые изначально собирают образ не в одной программе, а цепочкой, которую девелопер может, а порой и должен модифицировать (должен, по крайней мере знать о ее существовании)

вобщем, GoldFinch, тон общения у тебя несколько агрессивный, почем без явных на то причин, будь проще, мы ведь все понемногу учимся друг у друга

Добавлено через 13 минут и 9 секунд
xvr, на сколько я понимаю, DUMPBIN - вивер, т.е. он выдает инфу из образа, но не управляет обратной связью, т.е. не модифицирует COFF "символамы", по крайней мере я сейчас не помню из него ни одной команды "на запись"

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

perl - командный интерпретатор, но есть ли там набор API для работы с образом?

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

DumpBin+Perl? Это *типа удобный способ* чтоли? "Удобно" - это скрипт для WinHEX, место патча искать по сигнатуре и патчить - 3-4 строчки скрипта. 
Смысл использования DumpBin мне вообще непонятен, если уж писать программный код, то чем парсить вывод дампбина проще прочитать значения из PE заголовка

Насчет путаницы компиляции и линковки - мне больше нравится рассматривать ИДЕ как черный ящик, когда я пишу код, загружаю его в ИДЕ, жму "сконпелить" и забираю готовый бинарник. Как именно и в сколько этапов компилится исходник меня мало интересует, это детали реализации ИДЕ, лишь бы результат был хорошим.

ладно, за интересную тему, будет тебе плюс к репутации, я больше не буду тебя мучить )

О да, действительно. Т.е. проблемы на самом деле вообще не было.

GremlinProg, добрый ты стал какой-то  Стареешь?   

Вопрос был "можно ли получить размер и размещение кода во время компиляции(линковки) средствами языка C++ / ИДЕ MSVC"
выяснилось, что нельзя, нужно привлекать левые программы

собственно все что остальное - это какойто флейм не по теме о том как написать эту левую прогу и заставить ИДЕ выполнять ее при перекомпиляции(линковке)

) ну так а как их еще стимулировать?
тема на самом деле интересная, только в ней мало участников, все разговоры вокруг, да около
было бы еще интересней, если собрать набор задач для нее, т.с. почву для обсуждения, а то простой расчет VA - слабый аргумент
я, конечно могу вспомнить RTTIExploit, но круг его примернений тоже мал, а мороки было много

RTTIExploit - програмка, которая берет имя класса, декорирует его, как надо и извлекает в проект список смещений всех потомков класса, причем как полиморфных, так и простых т.е. это была замена dynamic_cast, которая обходит всякий раз в ран-тайме список дескрипторой полиморфного класса, а эксплоит 1 раз при сборке проекта это делает, передавая готовый список в проект.

Вот я как-то спрашивал на форуме про модификатор volatile, так это было как раз для эксплоита.

есть к примеру интерфейс:

и этот интерфейс принимает участие в архитектуре класса неоднократно

где I - предок для B и для C одновременно, т.е. существует 2 vmt интерфейса I в классе А.
если, к примеру, стоит задача вызвать по порядку все func класса A, то в ран-тайме это сделать невозможно, а RTTIExploit может собрать все такие общие точки в вектор и сохранить статически в шаблоне, типа такого:

тогда будет достаточно пройтись по всем вхождениям так:

ну я тут просто схематически набросал код (сейчас точно не помню), думаю будет понятно.
конечно, в проекте не задается list<A,IFace>::array, она инициализируется эксплоитом при сборке проекта,
причем эксплоит точно знает за каким шаблоном ему следить, поэтому, при обращении в коде к  list<A>::array, эксплоит его сразу обнаружит и назначит ему нужный адрес

смысл всего этого в том, что можно статически упорядочивать динамическую архитектуру класса, а сам класс list<A,I> - директива препроцессору линковщика, подобная __declspec, которую эксплоит как раз и вводит.

вот реальная задача для эксплоита

Это сообщение отредактировал(а) GremlinProg - 2.12.2008, 15:24

может для этого новую тему создать %)
мне-то всего-то надо было получить кусок секции кода содержащий нужный мне код чтобы разрешить туда запись

будет спрос, будет и предложение

я не хочу объяснять довольно специфические вещи самому себе, это не интересно

Да, с его помощью можно извлечь необходимую информацию (смещение и размер секции)
perl я предлагал для обработки вывода от dumpbin'а, что бы получить необходимые числа в явном виде (а не в виде нескольких строк в простыне дампа   )
API для работы с образом у него нет, но записать в образ он в принципе может, куда писать тоже можно найти из вывода dumpbin'а (наверное   )

Вообще то эта связка предлагается для пакетной работы (как post build step в проекте), а не для интерактивной

xvr, а сразу из PE-загололовка значения взять несудьба? зачем через такую ж**у-то?

чой-то я стормозил немного, какой еще набор API ) достаточно наличия инструментов для работы с файлом, т.е. для этого пойдет любой интерпретатор

ps: ну есть, конечно набор DbgHelp (Dbghelp.h/Dbghelp.lib) + их OLE интерпретация, но эти наборы немного ограничены, по крайней мере декорированием + для некоторых функций требуется подгружать образ в память, ничего лучше прямой работы с файлом образа я так и не нашел

эксплоит - от слова exploitation - эксплуатация, злонамеренное использование - код, который использует недостатки системы для выполнения неспецифичных для этой системы функций
к "консольной программе" это имеет весьма опосредованное отношение

ерундой вы, господа, занимаетесь
вопрос ведь просто решается:
1. Можно ли на этапе компиляции блаблабла? - НЕЛЬЗЯ
2. А вообще можно? - МОЖНО
3. А как? - а) на этапе выполнения парсать свой собственный образ; б) распарсать утилитой и записать в файл, который потом читать; в) распарсать утилитой и записать в .data секцию (или другую инициализированную секцию данных) на место статических переменных, которые потом и использовать

J0ker, если понимаешь, что тема к вредителям не относится, то можно вполне конкретно понять и смысл слова, значение которого "эксплуатация", т.е. не создание, а использование готового.

парсинг сюда ни как не припишешь, поскольку никакая грамматика ни PE, ни COFF не сопоставляется, для них существует легальный формат данных, который переводить ни куда не нужно, если уж подбирать нужное слово, то "чтение" - само то.

даже если читать собственный образ, то записать результат будет проблематично, поскольку из образа все символы обычно удаляются, т.е. анализ нужно проводить именно над COFF, который имеет локальный, относительный характер, т.е. в рамках одного COFF (или архива) еще можно использовать обратную связь, в рамках же PE - по крайней мере проблематично

Это вы показали как вы умеете в мсдн апишки искать?
Размер секции кода читается из заголовка ,если известен размер стаба, например 0x40, то получать его можно прямо по адресу [hModule+0x40+0x18+0xE0+0x10]
Начало секции кода  = hModule+0x1000
Зачем использовать АПИ чтобы это получить??

Более того, теоретически, если настроить релоки, база модуля будет добавляться сама. (хз как это сделать с С++)

-----------------
В 1м посте было 2 вопроса - во 2м спрашивалось "2) Есть модуль с функциями, можно ли на этапе компиляции узнать адреса функций с наименьшим и с наибольшим адресами в исполняемом модуле?"

если компилятор(линкер) не меняет порядок функций в модуле - то достаточно использовать адреса 2х функций которые гарантированно не удалятся

GoldFinch, не перебарщивай с таким кодом, мы все просто закрваем на него глаза, учитывая, что ты его указываешь только в схематических целях

существует простой, понятный и легальный способ получить PE-заголовок: ImageNtHeader
эта функция делает все, чего требует спецификация, и  в случае ее изменения, будет всегда корректироваться
зачем велосипед изобретать?
если уж изобретать, так трансформер, а не одноколесный самокат

GremlinProg, а что не так-с кодом-то?
Структура ImageNtHeader не может поменяться впринципе
а как именно получается значение размера 1й секции достаточно понятно описано в выражении
hModule+0x40+0x18+0xE0+0x10
база+смещение_PE+размер_файлового заголовка+размер_опц_заголовка+смещение_поля_размера
вместо 0x18+0xE0  можно еще записывать 0xF8 - размер PE-заголовка, но это менее правильно с точки зрения формата PE

ну, если ты меня не понял, то лучше объяснить я уже не смогу, обратись к кому-нибудь еще, а лучше, почитай спецификацию PE, там все "черным по белому", особенно в первой ее части:

GremlinProg, в "спецификации" ПЕ истине соответствует около половины. ее лучше не читать.
Формат ПЕ файла не может измениться впринципе, до тех пор пока существуют программы его использующие. Вот когда 32-разрядный PE-формат умрет, так же как и умер 16-разрядный MZ-формат, а произойдет это лет этак через 10, вот тогда мне потребуется пересчитать смещения в заголовках.
А пока вместо нелогичного многострочечного использования полей структур с длиииинными именами, я использую смещения в 1строчку

GoldFinch, в "спецификации" ПЕ пока истине соответствует абсолютно все, если бы ты ее читал, а самое главное - использовал
лучше не спорь в вещах, которые не понимаешь

ps: до этого я вежливо просил тебя не сыпать голословными заявлениями

GremlinProg, единственное чему следует доверять при работе с PE-форматом  - это алгоритмам работы системных загрузчиков в разных версиях винды.
Вот например в msdn написано:
IMAGE_FILE_HEADER.SizeOfOptionalHeader
    The size of the optional header, in bytes. This value should be 0 for object files.
А на самом деле поле SizeOfOptionalHeader - это смещение начала таблицы секций относительно начала OptionalHeader, и размер OptionalHeader тут совершенно ни при чем...

Про выравнивание секций там далеко не все написано... Даже если в msdn и была бы написана только истина, там не написано и 10% того что есть на самом деле.

Хотя, если писать на С(++) этого может и незаметно)))

ЗЫ: я тоже когда-то думал что знаю ВСЕ о ПЕ формате. Потом оказалось что это не так, а потом еще пару раз оказывалось так что я не все о нем знаю)

Это сообщение отредактировал(а) GoldFinch - 3.12.2008, 17:27

Ну вот видишь , Earnest, собственно, бог дал - бог взял, закон равновесия видимо работает
GoldFinch, репутацию, ты сам себе и подпортил, а ведь все так хорошо начиналось, смотри, как бы в минуса не уйти

формулировка: за неоднократные попытки ввести в заблуждение участников и игнорирование предупреждений

SizeOfOptionalHeader означает именно размер OptionalHeader'а
Optional присутствует в названии именно потому, что заголовок имеет переменную длину
после заголовка следует таблица секций, что и подтверждает SizeOfOptionalHeader
про выравнивание секций там написано гораздо больше, чем это реализуют инструментальные средства, так что опять же - безпочвенные наезды, а причина - неграмотность и неуважение.

по этому поводу, я уже делал комментарии, читай форум

GremlinProg, я уже поняла, что вы не договоритесь.
GoldFinch пока не въехал в то, как оно у нас тут на форуме. Огрызается, в бутылку лезет и прочая... Даст бог, со временем обживется, помягчеет...
GoldFinch, ты это, собственное представление о программировании не абсолютизируй, ладно? У всех у нас разный взгляд на вещи и разный опыт, к которому, ей богу, стоит прислушаться...

Жаль, что у меня на этом форуме недостаточно прав, а то закрыла бы тему, пока вы совсем не поругались...
Вы уж постарайтесь жить дружно   

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

Добавлено через 1 минуту и 29 секунд

это называется парсинг
не надо изобретать собственный словарь

Добавлено через 3 минуты и 37 секунд

именно поэтому я предлагал использовать отдельные секции кода

Добавлено через 12 минут и 25 секунд


5 - это смещения числа 5 относительно нуля
а то, что это 5 тут совершенно не при чем
       
я плАчу 

ок, какие предложения?

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

вариант, конечно, но к примеру, в задаче, которую я описал парой страниц раньше, таких секций может получиться очень много, а в COFF:
1. они легально сливаются (независимость от средств разработки)
2. корректно работает встроенная оптимизация (уменьшение кода и т.п.)
3. увеличивается избирательное свойство COFF (для сборщика: слить секции, удалить дупликаты и т.п.)
4. оптимизация на размере конечного образа (меньше секций - меньше хвостов от выравнивания)
5. хоть какая-то защита от вредителей (секции-то сливаются)

выходит, плюсов больше

Earnest, я так-то стараюсь не ссориться, просто, как чувствовал, он сам себя же и подцепит, не думал, правда, что это будет так быстро


да ладно, не надо так его расстраивать, он и сам это поймет

GremlinProg, 
Earnest, 
J0ker, 
Вы когданибудь видели 97-байтный exe pe файл?
Он состоит из 2-байтной сигнатуры MZ выровненной до 4х байт, PE заголовка размером 120 байт (виртуально)), таблицы секций и кода, размещенных внутри PE заголовка. Что характерно значение IMAGE_FILE_HEADER.SizeOfOptionalHeader, там гораздо меньше 97байт, и уж никак не равно размеру опционального заголовка. Я не проверял, но поидее SizeOfOptionalHeader может быть отрицательным, вроде бы ничто не запрещает размещать таблицу секций до PE заголовка)

Вы можете иметь какие угодно "представления о программировании", но далеко не факт что они согласуются с действительностью.

UPD: к сожалению файл с отрицательным SizeOfOptionalHeader неработает
(видимо дело в том, что SizeOfOptionalHeader - это word, а в загрузчике используется movzx, поэтому знак не сохраняется и переполнения не происходит

Это сообщение отредактировал(а) GoldFinch - 3.12.2008, 19:33

J0ker, под парсингом обычно понимается разбор, интрепретация. А бинарные файлы просто тупо читают подряд - потому что у них заранее известный строго определенный формат - иначе не прочитаешь. Можно, конечно, заявить, что вот если первый байт равен 11, то дальше идут данные AAA, а если там 22, то это BBB.  Но назвать это "разбором" -  это уж как-то чересчур...


У меня вообще такое чувство, что тебе нимб жать должен...  

Добавлено через 2 минуты и 16 секунд
GoldFinch, 
ИСКЛЮЧИТЕЛЬНО БЛАГОДАРЯ ТЕБЕ  Я ПРОЗРЕЛА: Я НИЧЕГО НЕ ПОНИМАЮ В ПРОГРАММИРОВАНИИ, И ВООБЩЕ В ЖИЗНИ! ПОЙДУ ПОВЕШУСЬ.

Earnest, я пАражаюсь твоей корректности ) мне б такие нервы

называть это как все нормальные люди - tool


http://www.google.com/search?q=portable+executable+parsing
надеюсь аргументов более чем достаточно?
"если слово непонятно - спроси"   


да неужели? ну сделай секцию, скажем "dskjrhglkjdsahglkawjhfpoaehgoigsadfgiasigeoirf"
а теперь вопрос - с чем она сольется?   


не влияет - оптимизация настраивается, выравнивание секций настраивается


не влияет


см. п.2
секция нужна одна - для размещения структуры с данными


ну тут одно из двух - либо вы издеваетесь, либо никогда этим не занимались   


формат PE расписан и там нет никаких неточностей. Просто многие статьи с его изложением не отличаются полнотой. Так что написание кода с магическими числами не оправдывается ленью



ну дык   


неправда
значение одних полей влияет на интерпретацию других - следовательно имеет место быть парсинг


"Можно, конечно, заявить, что вот если первым type-specifier, то дальше идет init-declarator-list, а если там namespace, то это namespace-definition.  Но назвать это "разбором" -  это уж как-то чересчур..."  

Добавлено @ 21:03

это word потому, что это РАЗМЕР, и интерпретируется как РАЗМЕР - что совершенно логично   

Это сообщение отредактировал(а) J0ker - 3.12.2008, 21:11

J0ker > "это word потому, что это РАЗМЕР, и интерпретируется как РАЗМЕР - что совершенно логично"
- это типа шутка?

"формат PE расписан и там нет никаких неточностей. Просто многие статьи с его изложением не отличаются полнотой."
так где он полностью расписан-то, если статьи все неполные?

Кстати, если вы так хорошо знаете формат PE, может объясните одну вещь, почему файл с секцией у которой raw offset = 0  -неработает, а файл с секцией у которой raw offset = 1  -работает? Вроде бы согласно документации raw offset должен быть выровнен по границе 0х200, как в 1м случае, а вот на практике оказывается наоборот.
Или вот еще пример, когда я размещаю директорию импорта в заголовке, если не заполнить IMAGE_DIRECTORY_ENTRY_IAT, файл неработает, хотя нигде не говорится ни о какой связи между размещением директории импорта и IAT.

нет, это типа жестокая реальность нашего мира   
новый анекдот
J0ker -- GoldFinch, а какой у вас размер ноги?
GoldFinch -- -61445
J0ker --   


я вам открою страшную тайну  
все официальные форматы расписаны в соответствующих спецификациях


я не говорил, что хорошо знаю формат
я писал парсер PE, и столкнулся с тем, что многие статьи, даже известных людей, страдают неполнотой
всю интересующую вас информацию вы можете почерпнуть в спецификации, которая, кстати, имеет страниц 50 - так что не все так просто

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

т.е. вы хотите меня убедить, что вы собираете и пересобираете, а про наличие спецификации впервые услышали от меня, затем изучили за.... момент... 15 минут 50 страниц текста и чего-то там не нашли?   

  

я видел круче (точнее я создал)   
78 байт, ELF файл

Присоединённый файл ( Кол-во скачиваний: 2 )
 small 0,08 Kb

Да, спецификацию увидел только сегодня, раньше ее не искал, т.к. по отзывам там ничего полезного. За 5-10минут поиском (ctrl-f) посмотрел ключевые моменты, понял что отзывы не врут, т.к. там в самом деле ничего интересного нет.
Видимо люди писавшие системный загрузчик относились к спецификации спокойно, поэтому он работает не совсем по спецификации. Т.к. де-факто формат файла определяется исключительно алгоритмом обработки этого файла.

MAKCim, на то он и ELF, что не PE
вы бы еще 1байтовый .com в виде примера привели, или пустой php скрипт

Это сообщение отредактировал(а) GoldFinch - 3.12.2008, 22:31

в таком случае вы вправе выразить свои претензии создателям загрузчика, и я даже думаю они вполне могут вам ответить, если вы грамотно все напишете   
однако вы отклонились от темы по поводу различия понятий размер и смещение  

Добавлено через 11 минут и 48 секунд
да, кстати, GoldFinch, вот специально залез в спецификацию и, не поверите, не нашел там никаких "raw offset" в заголовке секций   

это про SizeOfOptionalHeader чтоли? а что там обсуждать-то?

вот именно   

Это сообщение отредактировал(а) J0ker - 3.12.2008, 23:37

как же для такой "tool", среди прочих, выделить принадлежность к процессу линковки и предназначение ее использования именно в пайпе для MSVC?
даже в веб-программировании, простая консолька - CGI-программа.
серое абстрактное название ни как не выделяет ее функционал, все равно, что назвать MSVC программой, или той же tool

среди предложенного списка 2 ссылки относятся к парсингу, остальные к PE, ты быхоть посмотрел для начала список:
в первой ссылке слово парсинг используется 2 раза: в названии и в неграмотном втором предложении
во второй человек спрашивает, собственно, как парсить PE
и я не удивляюсь, почему вопрос так и остался без ответа, поскольку людей, которые писали парсер PE вижу первый раз в жизни:

аргументация, J0ker, по крайней мере, весьма странная
и это тебе второе предупреждение, ты уже ведешь себя как GoldFinch


если в СОFF для символа создаешь отдельную секцию, название не имеет значения, то она сливается в PE в секцию кода или данных вместе со всеми остальными секциями "символов", если в коде линковщику не указан другой путь директивами code_seg, data_seg и т.п.

это уже третье предупреждение, других не будет


чесно говоря, хотел прокомментировать, но ты это уже сделал парой постами выше:

остальные редиректы абсурдны

В принципе, о терминах спорить не конструктивно...  Для кого-то и прыжок со стула - полет...  

GremlinProg,  ребята ведут себя хоть и не взросло, но наказаний, ей-богу, не заслуживают, так что брось (предупреждать).
А насчет нервов... у меня такой опыт борьбы с неадекватными пользователями... это как мускулы - от регулрных упражнений они крепчают.       

Кстати, не напомните, что мы тут обсуждаем?

Earnest, хз что тут обсуждаем, я пометил вопрос как решенный еще на этом посте - 
http://forum.vingrad.ru/index.php?showtopi...t&p=1713820

дальше пошел оффтоп и всякий бред.

Earnest, а я что?
я бы ни слова не сказал, если бы он не комментировал мои посты с указанием на мою квалификацию
если такого больше не будет, я, чесно, ни кого не обижу

GremlinProg, какие посты- такие и комментарии... а о вашей квалификации я не говорил, т.к. незачем, вы о ней своими постами лучше сказали...

GoldFinch, я о тебе упоминал последний раз парой страниц назад, вылезай уже из бутылки

названием


бред
CGI не имеет никакого отношения к "консольки"


наглая ложь
список первых:
1. CodeGuru: Parsing the Portable Executable File Format
2. #475493 - ITP: python-pefile -- Portable Executable (PE) parsing ...
3. Portable Executable - Wikipedia, the free encyclopedia - "Mac OS X 10.5 has the ability to load and parse PE files"
4. Insanely Low-Level » Portable Executable - "But sometimes the tools you use to parse the file don’t do their work well."
5. The Portable Executable File Format - Abstract - отсутствует
6. Pimp My PE: Parsing Malicious and Malformed Executables

из шести - 5 непосредственно упоминают парсинг PE
так-же парсинг упоминается в wiki (3) - и статья викифицированна



это не аргументация
это ответ на вопрос откуда я знаю, что статьи страдают неполнотой
ваши передергивания со мной не прокатят


как минимум для сегмента данных (#pragma data_seg) на линкерах от мелкософта это неправда - линкер создает отдельную секцию
а даже если сие имеет место быть на других линкерах - это не имеет отношение к делу - возможность есть? ЕСТЬ


не улавливаю связи


данное заявление абсурдно   

ЗЫЖ ваши предупреждения проигнорированны как абсурдные  

Добавлено через 12 минут и 16 секунд

а мы не о терминах спорим
мы спорим о применимости термина к действию
пример вполне адекватен - в границах термина "парсинг" не рассматривается природа данных - текстовые, бинарные или вилами на воде писанные
более того, смею утверждать, что даже интерпретация данных с жесткой структурой является парсингом, т.к. структура является вырожденным случаем регулярной грамматики состоящим из единственного терминального символа.