wanted tool: point_in_trace --> call_graf / stack_trace

Malfoy
Для чего в трассе, а не в коде раскрывать обратные ссылки? Они и так раскрыты.
А вопрос весь в том, в чём вопрос у ТСа - ему нужен stack-backtrace или control flow трасса?
То и другое можно получить из его трассы. Без графов. Именно сканя трассу назад.

 

samuraishowdown
Нет никаких ссылок, вы сказали что это не граф. Вот например нужно пройти назад от Line2 до Line1. Если просто енуми назад описатели в трасе, то будет раскрыта процедура с конца. Короче я не знаю что кому нужно.

 

Не могли бы вы подсказать. где в деталях о подобных возможностях можно почитать? Что вообще можно делать с трассировщиком, с тем, что и как он делает?
Я сохраняю трассу выполнения с пом. IDA. Дальше я текстовый файл обрабатываю (легкое форматирование + выбрасывание инструкций внутри системных библиотек + выбрасывание некоторых известных мне и не нужных для рассмотрения циклов) и после этого начинаю разбирать - врубаться в логику и искать то, что мне в конечном итоге нужно найти.

По ходу у меня много пожеланий и претензий к тому, что и как пишется трассировщиком. Можно ли это как-то подправить? И то, _что_ пишется в трассу, и то - _как_ пишется.

Что мне нужно - я выразил в топике предельно ясно - последовательность вызовов, в результате которой мы приходим к некоторой заданной точке в трассе.

 

mrCyber
Попробуйте юзать ida-x86emu, придется некоторое допилить , и много чего не учитывает, но простых кодесов думаю подойдет, вам понадопится допилить обрабоку колов. В смысле что и где вам и куда писать. ИМХО самое простое и рабочий вариант. Так сказть все уже есть, осталось месаджбокс написать

 

mrCyber
В виндбг, который можно юзать из IDA, можно немного настраивать подробности логгирования трассы:
.prompt_allow -reg -src +ea +sym +dis - вот так будет, дизасм, адреса и символы.
Думаю в лог можно писать всё что угодно: t "а здесь ваш скрипт, который будет выполняться после каждой инструкции".
А вот сами скрипты - это нечто.

Вот как-то так выводим имена длл, при их загрузке:
bp KERNELBASE!LoadLibraryExW "as /mu ${/v:MA} poi(@esp+4); .block { .echo MA }; ad MA; gc"

Ну ещё можно многое с трассировкой намутить, если плагин к отладчику на C писать.

меня смутило слово стэкТрэйс в первом посте. Этим словом называют не то, что нужно вам.

 

Вот те на...... А чем же то, что хочу я - так принципиально отличается от того, что можно увидеть в окне стэкТрэйс в рантайме под дебагером?

 

Последовательность вызовов можно понимать как вся последовательность вызовов (ну тупо ВСЕ вызовы функций). стектрейс - это последовательность вызовов от текущей точки с определённым NL до функи с которой стартанул поток (функи по очереди с NL-1, NL-2, NL-3, ...), но 2-х функций с одним NL в этом стэктрейсе нет.
И почему принципиально stack-backtrace именно из трассы получать, а не из отладчика?

 

samuraishowdown
Я понял, что вы имеете в виду. Очень странная вещь - я о таком даже не подумал. Это..... это тогда и есть трасса - все, что было сделано, вызвано до того, как мы попали в точку Х. А мне нужна последовательность вызовов..... именно в том смысле, который синонимичем стэкТрэйсу. Мне даже и в голову не пришло, что мое хотение может быть истолковано неоднозначно. Сорри.

Почему не в рантайме, почему из трассы - это можно понять из этой темки:
http://www.wasm.ru/forum/viewtopic.php?id=43699

Если совсем коротко, то.....
Есть PST файл - гугл расскажет, что это.
Есть утилита (scanpst.exe), которая работает с ним.
Есть своя либа, которая строит PST.
Есть проблема - самодельный PST не воспринимается утилитой.
Требуется - найти где что и как в своем PST реализовано не так. И единственный ключ, зацепка - это разобраться, что и как с моим файлом делает утилита. Для этого есть трасса ее работы на правильном файле и на моем. Далее анализирую, что происходит во время этой работы, в чем отличия.

 

Колстек никаким боком не относится к логу, полученному при трейсе. Комуто нужно немного матчасти изучить. Существует две цепи - SFC(Stack Frame Chain) и SEH. Первая формируется за счёт локальных стековых фреймов, это цепь аналогичная второй - сех цепи. У них разные методы определения начала цепи и перечисления фреймов. Хотя в общем это односвязанный список в обоих случаях. Существуют правила, которые определяют чётко свойства и возможное поведение обеих цепей. SFC зависит от NL. Маршрутизацию потоковую можно выполнить только на нулевом уровне вложенности. Эта цепочка определяет только ссылки на адреса возврата из процедур, она не описывает их код, поймите.

 

Malfoy
Нет ни малейшего желания с вами спорить. Я подозреваю, что тут возникло какое-то непонимание на уровне терминологии.
Для себя еще в середине первой страницы этого топика получил ответ на заданный вопрос. А дальше я не оч. понимаю, о чем тут спорят.... Вроде все настолько прозрачно, что и говорить не о чем.
И этот пост по ликбезу - это вообще к чему и в ответ на какой вопрос или противоречие???

ИЧО?...... А я что, где-то утверждал обратное?

Эт вы не погорячились???
Глядя на колСтэк я могу понять, что A вызвала B, B вызвала С, С вызвала D, D вызвала E в теле процедуры Е я сейчас и нахожусь, к примеру. По трассе можно увидеть все то же самое, просто форма представления другая.

О чем спор - не понимаю.

 

mrCyber
Я с вами спорить не собирался, не собираюсь и не буду. Как я могу спорить с тем, кто не знает матчасти ?

Вы можите товарищ только у меня спрашивать. Если я говорю что вы не правы или не туда смотрите то так и есть. Почему - потому что я много лет потратил и знаю сию науку досконально. Далее решайте вы свою проблему как хотите, но вы должны научится спрашивать и слушать. Иначе вы ничего не достигните.

 

А чё тебе в ИДОвом трассировщике не устраивает? Сравнивай Идовые. Цыклы не писать разве это правильтно для трассы? Цыклы всякие бывают, заковыристые, к тому же они не мешают при кампарации.
Или он глючит? (Сам не пользуюсь деб ИДОй)

 

artkar
Циклы да, они разные бывают. Но я сказал, что не выбрасываю все подряд, а лишь те, о кот. я все знаю и от которых ничего интересного не жду. Например, подсчет контрольной суммы или шифрование/расшифровка блока данных. Мне достаточно знать, что эту процедуру позвали. А что там внутри - скучная математика. Она на логику не влияет в данном конкр. случае. Зато вот трассу засоряет просто дико. И последующее сравнение тоже заметно усложняет.

Трассировщик форматирует текст не самым для меня понятным образом - где-то спэйсы, где-то табы. Зачем-то в конце строк куча пробелов. Где-то идут просто адреса, где-то адрес+смещение. Одна и та же процедура может упоминаться как loc_subXXXX, а может как 'near ptr unk_subXXXX'. Может кто знает - от чего все эти мелочи зависят? Или я не улавливаю какие-то знаки, подсказки и проч. крайне полезную информацию?

 

Дык там ведь будут одинаковые трассы в не зависимости от объёма? (ЦРЦ) А если нет то идеальных трасс нет, чё ты хочешь любой метод не идеальный. Обламать с методом трассировки тебя может куча причин, напр всё наладил запустил а лог у тебя выйдет гигов на 100!!! Заи*ешься его анализировать или там какая-нибудь событийная модель, то же трассировка как метод отваливаеться.

ХЗ не могу помочь как работает ИДОвский трасер не знаю, потыкайся там должны быть настройки, хотя ИДА да! любит самодеятельность, попробуй взять другой дебаггер - Ольгу ту же, хотя работает адски медленно, мне иной раз приходилось её на несколько дней оставлять и в итоге она падала (но там можно не заходить в системные функции!!! что тебе наверно хочеться)