Форум: "Основная";
Текущий архив: 2004.04.25;
Скачать: [xml.tar.bz2];
ВнизДамп процедуры/функции Найти похожие ветки
← →
-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 далеко_не_рядом
или уж как нибудь определись, что тебя интересуют ТОЛЬКО статические п/программы, маш.код которых сгенерирован той же средой. которая производит анализ, т.е. Делфи
← →
Verg © (2004-04-06 18:54) [31]
> А, кстати, ткните носом - ExitThread чей обработчик?
А при чем тут "обработчик"?
Обработчик, в смысле - это такой метод, который вызывается в результате работы Dispatch? Тогда см. Digitman © (06.04.04 18:47) [28]
← →
Тимохов © (2004-04-06 18:56) [32]лет 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]
← →
Verg © (2004-04-06 19:07) [35]
> -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 из ресурсов ЕХЕ можно определить есть ли обработчик событий той или иной компоненты. Можно также узнать адрес НАЧАЛА этого обработчика. А вот как узнать адрес последнего байта - так и осталось вопросом.
Что же, значит будем писать свой анализатор кода. Всем спасибо.
← →
Тимохов © (2004-04-06 19:31) [37]можно очень многое,
мой вопрос был - на фига нужно знать конец обработчика.
скажите, очень интересно, может я что-то пропустил в своем образовании...
← →
-SeM- (2004-04-06 19:47) [38]
> Тимохов © (06.04.04 19:31)
> на фига нужно знать конец обработчика.
Ну есть не мой (чужой) код для дизасемблирования блока, для которого нужен адрес начала и адрес конца блока
> Если бы еще и асм не поверхностно знать :(
[11]
не использовал бы чужой код. Будем учиться :(
← →
Игорь Шевченко © (2004-04-06 19:58) [39]
> Ну есть не мой (чужой) код для дизасемблирования блока,
> для которого нужен адрес начала и адрес конца блока
Выкинь
← →
Тимохов © (2004-04-06 20:01) [40]на фиг
Страницы: 1 2 вся ветка
Форум: "Основная";
Текущий архив: 2004.04.25;
Скачать: [xml.tar.bz2];
Память: 0.55 MB
Время: 0.034 c