Дамп процедуры/функции

← →
-SeM- (2004-04-06 16:58) [0]

GetProcAddress возвращает адрес начала функции (первого байта). Не подскажут ли уважаемые Мастера как получить адрес последнего байта для получения дампа?

← →
Digitman © (2004-04-06 17:02) [1]

> -SeM-

в общем случае - никак

← →
-SeM- (2004-04-06 17:07) [2]

А если не в общем? ;)

← →
Digitman © (2004-04-06 17:09) [3]

> -SeM-

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

← →
-SeM- (2004-04-06 17:44) [4]

> Digitman © (06.04.04 17:09)

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

Я так и предполагал :)
Деструктивных целей нет, скорее образовательные (исследовательские). Просто нужно показать дамп процедур обработчиков событий.
Одним кодом возврата не обойдешься, потому и спрашиваю.

← →
Тимохов © (2004-04-06 17:48) [5]

Думаю, что как-то теоретически можно - ну типа написать парсер команд intela и начиная с начала процедуры парсить пока не найдешь какой нибудь ret (это я гоню, конечно)...

имхо никак

← →
Digitman © (2004-04-06 17:51) [6]

> процедур обработчиков событий

как это вяжется с экспортируемой точкой входа в ДЛЛ ?
не вижу пока ничего общего между VCL-методом-обработчиком и просто некоей экпортируемой ф-цией/процедурой, которая вполне могла быть создана и не средствами Делфи ...

> скорее образовательные (исследовательские). Просто нужно
> показать дамп

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

← →
Юрий Зотов © (2004-04-06 17:54) [7]

procedure A;
begin
...
end;

procedure WriteA;
var
P: Pointer;
L: integer;
begin
P := @A;
L := Integer(@WriteA) - Integer(P);
with TMemoryStream.Create do
try
SetSize(L);
WriteBuffer(P^, L);
SaveToFile("ProcA.dmp")
finally
Free
end
end;

← →
Тимохов © (2004-04-06 17:56) [8]

> Юрий Зотов © (06.04.04 17:54) [7]

а если между a и writea будет другая процедура...

← →
Digitman © (2004-04-06 17:57) [9]

> Юрий Зотов

речь-то идет о дампе якобы всегда непрерывной (по ошибочному мнению автора) области памяти, занимаемой телом п/программы в составе внешнего РЕ-модуля ... см. упоминание о GetProcAddress()

← →
Игорь Шевченко © (2004-04-06 17:59) [10]

А у MS вообще макаронный код

← →
-SeM- (2004-04-06 18:00) [11]

> Тимохов © (06.04.04 17:48)

В том то и дело, что писать. От этого никуда не убежишь. Если бы еще и асм не поверхностно знать :(

← →
Тимохов © (2004-04-06 18:02) [12]

> -SeM- (06.04.04 18:00) [11]

думаю вы уже передумали за это браться ...

← →
Digitman © (2004-04-06 18:03) [13]

> -SeM-

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

← →
Юрий Зотов © (2004-04-06 18:18) [14]

> Тимохов © (06.04.04 17:56) [8]
То надо вычислять размер по ней. Какие проблемы?

> Digitman © (06.04.04 17:57) [9]
Да, недопонял я вопрос.

← →
-SeM- (2004-04-06 18:20) [15]

> Digitman © (06.04.04 18:03)

Да GetProcAddress взята для примера, для понимания вопроса. VCL-обработчик тоже ведь имеет адрес.

Пока мне важно знать именно адрес конца обработчика, не обращая внимания на безусловные переходы (по структуре PE). При вызове из тела обработчика другой функции/метода возврат будет же назад, даже в случае ошибки.

← →
Тимохов © (2004-04-06 18:22) [16]

> Юрий Зотов © (06.04.04 18:18) [14]

я имел в виду, что универсального решения здесь нет.

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

проблем никаких

← →
WebErr © (2004-04-06 18:26) [17]

> Юрий Зотов © (06.04.04 17:54) [7]

Опа! А если функция одна в ДЛЛ?! Или вообще одна-одинёшенька!
В асме в режиме ДОС энто делается, дай бог памяти, через хрень "$"... В Делфе... боюсь будет облом хотя бы потому, что это режим Винды - здесь можно функции в бараний рог крутить и попав в начало функции, можно оказаться в конце вообще на другом Хард диске - если я не ошибаюсь! :))))

← →
Digitman © (2004-04-06 18:29) [18]

> GetProcAddress взята для примера, для понимания вопроса

ты его, вопрос, только сильно усложнил в понимании упоминанием GetProcAddr() .. потому что подразумеваемое под этим вовсе не является никаким обработчиком ... и ситуация здесь совершенно иная, нежели ситуация с методами-обработчиками, реализованными именно в твоем проекте, а с какими-то "чужими" п/программами, реализованными тем или иным заранее неизвестным тебе способом в заранее неизвестной последовательности

← →
Verg © (2004-04-06 18:29) [19]

Вызвать ее в режиме отлаки и по шагам пройти до точки возврата (восстановления стека).

Это и будет последней иструкцией ПП для данного набора входных параметров.

← →
Digitman © (2004-04-06 18:31) [20]

> -SeM-

то что ты затеял, сродни попытке нахождения ВСЕХ возможных решений для параметрического уравнения с N - 1 неизвестными

← →
WebErr © (2004-04-06 18:32) [21]

> Verg © (06.04.04 18:29) [19]

Ага, а при повторном запуске адрес могёт быть другим! :)

← →
Тимохов © (2004-04-06 18:33) [22]

это мне напоминает обход лабиринта - во всех местах где может быть переход нужно делать ветвление и таким образом найти весь код процедуры.

← →
Digitman © (2004-04-06 18:33) [23]

> Verg © (06.04.04 18:29) [19]

ты ж понимаешь, что этих RET[N] в общем случае м.б. немеряно в теле п/программы ... вход - один, а выходов - куча .. да и вход м.б. не один в частных случаях

← →
Verg © (2004-04-06 18:36) [24]

> WebErr © (06.04.04 18:32) [21]

Могёт, поэтому, я считаю, что понятие "конец процедуры" - это некорректно вообще.
Он может быть за +/- многие сотни килобайт от точки входа. А может вообще отсутствовать, как, например, у ExitThread.
Так что, вообще вопрос поставлен некорректно.
Я так считаю.

← →
-SeM- (2004-04-06 18:36) [25]

> Digitman © (06.04.04 18:29)

> вопрос, только сильно усложнил в понимании упоминанием GetProcAddr

Это я уже и сам вижу. Читать не успеваешь, не то что соображать :)

> Verg © (06.04.04 18:29)

> Вызвать ее в режиме отлаки и по шагам пройти до точки возврата
>

И если файл смапированный, как быть с возможными инициализациями, созданием объектов?

← →
Digitman © (2004-04-06 18:41) [26]

> -SeM- (06.04.04 18:36) [25]

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

еще раз говорю - без полного анализа кода РЕ-модуля задача практически нерешаема

← →
-SeM- (2004-04-06 18:43) [27]

> Verg © (06.04.04 18:36)

> Он может быть за +/- многие сотни килобайт от точки входа.
> А может вообще отсутствовать, как, например, у ExitThread.

Может не все я и видел, но несколько обработчиков в CPU окне среды "прошагал" - все заканчивались RET"ом.
А, кстати, ткните носом - ExitThread чей обработчик?

← →
Digitman © (2004-04-06 18:47) [28]

> -SeM-

многие, например, компиляторы/линкеры генерирую таблицу джампов для точек входов в эксп.ф-ции

представь себе, точкой входа в п/п будет адрес джампа, который прыгает на + десяток мегамайт от своего собственного местоположения, в точке "приземления" стоит ret ... ЧТО, по- твоему, в дан.случае считать телом п/программы ? весь диапазон адресов между инструкцией джампа и инструкцией, следующей за ритурном ? этот же - бред, нонсенс)

← →
Тимохов © (2004-04-06 18:47) [29]

интересный вопрос возникает, зачем это вообще может быть нужно?

← →
Digitman © (2004-04-06 18:52) [30]

> ExitThread чей обработчик?

это вообще не обработчик, это - функция, экспортируемая одной из библиотек ядра

> несколько обработчиков в CPU окне среды "прошагал" - все
> заканчивались RET"ом.

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

или уж как нибудь определись, что тебя интересуют ТОЛЬКО статические п/программы, маш.код которых сгенерирован той же средой. которая производит анализ, т.е. Делфи

> А, кстати, ткните носом - ExitThread чей обработчик?

А при чем тут "обработчик"?

Обработчик, в смысле - это такой метод, который вызывается в результате работы Dispatch? Тогда см. Digitman © (06.04.04 18:47) [28]

лет 15 назад еще на xt я хотел написать искусственный интелект...
не получилось...

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

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

← →
-SeM- (2004-04-06 18:57) [33]

Вижу уже вторую свою оплошность в вопросе - дамп.

> Digitman © (06.04.04 18:47)

> ЧТО, по- твоему, в дан.случае считать телом п/программы
> ?

Анализируем: в точке входа - jmp на ret, т.о. при безусловном переходе ТЕЛОМ п/программы будет 6 байт.
Мне нужен адрес этого ret.

← →
-SeM- (2004-04-06 19:05) [34]

> Verg © (06.04.04 18:54)

> А при чем тут "обработчик"?

> Пока мне важно знать именно адрес конца обработчика
[15]
А пример приводится ExitThread [24]

> -SeM- (06.04.04 19:05) [34]

Где я писал, что ExitThread - это пример обработчика?

Пока я не понимаю - что ты называешь обработчиком, почему ты их выделил в особую "касту"? По каким признакам?

← →
-SeM- (2004-04-06 19:29) [36]

> Verg © (06.04.04 19:07)

> Где я писал, что ExitThread - это пример обработчика?

Я так не говорил, а сказал что в [24] был приведен В ПРИМЕР ExitThread.

> Тимохов © (06.04.04 18:56) [32]

> Должно же быть объяснение потребности в такой задаче...

Короче, при чтении DFM из ресурсов ЕХЕ можно определить есть ли обработчик событий той или иной компоненты. Можно также узнать адрес НАЧАЛА этого обработчика. А вот как узнать адрес последнего байта - так и осталось вопросом.
Что же, значит будем писать свой анализатор кода. Всем спасибо.

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

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

← →
-SeM- (2004-04-06 19:47) [38]

> Тимохов © (06.04.04 19:31)

> на фига нужно знать конец обработчика.

Ну есть не мой (чужой) код для дизасемблирования блока, для которого нужен адрес начала и адрес конца блока

> Если бы еще и асм не поверхностно знать :(
[11]
не использовал бы чужой код. Будем учиться :(

> Ну есть не мой (чужой) код для дизасемблирования блока,
> для которого нужен адрес начала и адрес конца блока

Выкинь

на фиг

← →
-SeM- (2004-04-06 20:09) [41]

-SeM- (06.04.04 20:09)

Не так уж это и сложно. Я правда, не совсем понимаю, зачем ? :))

У ElicZ, кстати, есть довольно компактная процедура определения длины инструкции, если интересно. X86IL.zip

← →
-SeM- (2004-04-07 09:12) [43]

Дамп процедуры/функции Найти похожие ветки