Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2004.04.25;
Скачать: CL | DM;

Вниз

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

 
-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;
Скачать: CL | DM;

Наверх




Память: 0.57 MB
Время: 0.048 c
14-1081193328
Alex Vitik
2004-04-05 23:28
2004.04.25
Моя прога не работает на другом компе... Че делать?


14-1080908643
syte_ser78
2004-04-02 16:24
2004.04.25
Mustek GSmart mini 2


14-1081057876
SPeller
2004-04-04 09:51
2004.04.25
Посылать нынче некуда...


14-1080488467
Инкогнито
2004-03-28 19:41
2004.04.25
Будущее за киберпанком?!


9-1067583979
Bobrik
2003-10-31 10:06
2004.04.25
Свет в OpenGL