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

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

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

а при чем тут 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 интерпретация, но эти наборы немного ограничены, по крайней мере декорированием + для некоторых функций требуется подгружать образ в память, ничего лучше прямой работы с файлом образа я так и не нашел