всё про "обратную трассировку"

слыхал что у GDB из под консоли можно сделать шаг назад у отлаживаемой программы
у Visual Studio 2017-2019 тоже появилась эта функция в C# (но там полное ГГ в 99% случаев она вобще не работает непонятно почему)
А что еще может так откатывать шаги отлаживаемой программы? пожалуйста с недостатками.

Слыхал что что-то даже сделали аппаратно. А кок там тогда сохраняется/отслеживается память?

 

Команда backtrace в gdb не про шаг назад, а про цепочку вызовов, которая разматывается об адреса возврата и стековые аргументы.

 

а какой-нибудь ещё откат есть?

как я понял отладка не такая совершенная... как вы тогда программы отлаживаете/изучаете ??? (если прогу хоть как-то защитили то jamp reg+reg вобще не отследишь)

 

VaVa, свои патчи, свои загрузчики. У Инди свой визор. Шаг назад радар может, но предварительно надо включить сохранение стэйтов. В гдб это можно путем скрипта. В любом случае это эмитация шага назад. Просто восстановление стэйта.

 

Свои собственные программы примерно так и отлаживаю: произошло исключение, смотрю в стеке адреса возврата и какие-нибудь узнаваемые конструкции, позволяющие найти это место в исходнике. И чужие программы обычно примерно так же, но в каждой ситуации можно разные способы применять, выбираю обычно интуитивно, часто сразу правильный. Нередко приходится вообще по-спортивному в статике что-то изучать. Твой вожделенный шаг назад можно по прямой трассировке делать, но это никакая не вундервафля, которая до смешного все упростит, если будет.

 

а он в этом стейте изменённую память отслеживает?

--- Сообщение объединено, 2 мар 2020 ---

как я понял тока по стеку ?

а какие ещё трудности при изучении подсовывают?

 

VaVa,

Если при трассировке сохранить контекст и области изменяемой памяти(куда происходит запись и какой длины выборка), то можно сделать шаг назад и посмотреть в логе на эти изменения. Но они локальны для текущего потока(задачи), так например может быть общий ресурс у потоков и назад уже ничего не откатишь, аналогично как и системных вызовов. Только если слепок всей системы сделать в вирт машине, на это нужны были бы огромные обьёмы памяти. Главное что не понятно зачем это нужно.

 

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

 

Да вобще про принципиальные возможности отладки чужих программ хотелось узнать (изучать досконально на готовых продуктах - слишком долго)

--- Сообщение объединено, 2 мар 2020 ---

Да в курсе что с потоками всё сложнее но это вроде решаемо перехватом системных вызовов...
мне даже с одним потоком интересно, тока трассировка назад не до указанной точки, а с указанной и назад по очереди...

КАК??? что-то вобще не понял...

--- Сообщение объединено, 2 мар 2020 ---

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

 

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

 

а если без стека ... jmp eax+[ebx] например?

 

Что делать с обфусцированным кодом обычно решают исходя из особенностей протектора. Он нетипичен и типичных приемов для него тоже нет.

 

VaVa,

> тока трассировка назад не до указанной точки, а с указанной и назад по очереди...

Что бы лог снять нужно трассировать вперёд. Обратная трассировка это фишка отладчика, проход по журналу событий.

> возможности отладки чужих программ хотелось узнать

Проблема не в отладке, все норм протекторы морфят код как минимум(без вирты), а что бы даже эти примитивы свернуть нужны сложные инструменты, которые графы строят-парсят-изменяют-собирают. Если какой то семпл не поддаётся отладке, то его механизмы будут реверсить и так же отлаживать, пока не обойдут, это обычно очень быстро решается. Другое дело когда там морф или вирт, на деморф/девирт нужна куча времени и ручной работы. А поэтому это и есть лучшая защита.

 

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

 

savoyard,

Пин поделка бесполезная, во первых там трассировки нет, там бинарная трансляция, не пригодно для трассировки https://exelab.ru/f/?action=vthread&forum=1&topic=25888&page=1#4

Все эти dbi лежат только в виде сурков на gh, реально это куча мусора с которым не ясно что делать и что под ним вообще работает.

 

Нет.

Иными словами ты не понял как ими пользоваться, поэтому они куча мусора.

 

f13nd,

Не по этому, там нечего понимать. Просто там нет задачи разбить блок, он транслируется, тоесть при этом нет единичной инструкции. Можно делать вставки, разбивая блоки, но это не главное. Во всех визорах крайне кривая системная обработка, это полный анстаб. Я могу для примера пяток семплов привести с крэклаба, которые дием крутил сегодня, причём успешно, а вот ты пример приведи пином или drio

 

Пин и Юникорн - это немного разные вещи, Пин - аналог Динаморио и Дининста (фреймворк для бинарной инструментализации), а Юникорн - фреймворк для эмуляции. Как инструменты они вполне себе применимы, но для немного других задач.

 

Инди, а может вы просто когда-то недостаточно глубоко вникли, а в настоящее время у вас предвзятый подход? Пользуясь случаем хочу сказать вам спасибо за то, что вы когда-то на exelab'е упомянули SDE, я заинтересовался, немного разобрался и пришел к выводу что для меня это нужная вещь. Хотя, выдает на гора "килотонны" гигабайт лог файла. С 1 мб. ехе-файла выдает 14Gb!!! лог файл. Ну, куда деваться - издержки производства.

 

savoyard,

> может вы просто когда-то недостаточно глубоко вникли

А во что вникать, если я его отлаживал и видел как он транслирует код. О чём вы говорите. Просто таких как ты очень много всегда толпами, которые хотят халявный мощный тулз. Не ты случайно на кл мне вопрос сегодня задал ?

И что я ответил, где твоя проведённая работа