Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Основная";
Текущий архив: 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.036 c
1-1081571033
zsv
2004-04-10 08:23
2004.04.25
Запуск chm и hlp файлов


14-1080795363
Иксик
2004-04-01 08:56
2004.04.25
Как меня сегодня кинули!!! И главное с утра пораньше.


14-1080855099
Knight
2004-04-02 01:31
2004.04.25
Вроде мелкий тест... а в точку


1-1081429340
Russko
2004-04-08 17:02
2004.04.25
Количество файлов в каталоге


14-1080823543
kaif
2004-04-01 16:45
2004.04.25
Почему опять разогнали правительство???





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский