насколько я помню проблема обратного дизассемблирования так и не была решена а обратное исполнение еще посложнее будет
infern0 Да, я тоже помню такое. И как интересно это было реализованно...Явно ограниченная в возможностях вещь.
Имхо, тут надо просто сохранять инфу при каждой выполненной инструкции (контекст и etc.). Иначе ничего не получиться. Это же не просто выполнение команд наоборот, а изменение EIP на инструкцию плюс востановление предыдущего контекста (т.е. контекста до выполнения последней команды).
Невозможно по определению. Обратное выполние программы - к изменению EIP отношение имеет ооочень далекое...если не сказать, что не имеет никакого отношения в принципе. Разворачивать нужно не комманды, а алгоритмические шаги... А чтобы разложить программу на алгоритмические составляющие - это вам не ахти. Даже ида этого не умеет. Человек это не всегда умеет...даже проф. реверсыры часто сталкиваются с проблемами на этом шаге. Более того, нужно не просто разложить программу на составляющие, но и найти неделимые блоки. к примеру push offset szSomeLib call LoadLibraryA это неделимый блок... если начать исполнение функции, а закончить доставанием параметра из стека - это приведет к исключениею. Уже видно, что задача не из тривиальных Но и это еще не все. Мало того, что нужно разложить программу на алгоритмические шаги, и неделимые блоки, но и найти "обратное действие". А это не всегда возможно. Чаще - это просто невозможно. Даже для элементарных действий add, xor, sub не всегда можно найти обратное. xor eax,eax sub eax, eax add eax, dword ptr [ebp+14] - а регистр ebp задается как правило в начале функции и тут у нас возникает бааальшая трабла. А вот обратные действия к АПИ - это вообще на грани искуственного интеллекта. И написать таблицу обратных функций апи - это не выход. ) пример: hLib=LoadLibraryA("MyLib.dll") ...1-2 мегабайта кода.... xFunc=GetProcAddress(hLib, "MyFucntion") ....1-2 мегабайта кода.... x=xFunc(3, 1,4, someparameter) ... еще мегабайты кода x = x+Rsult; return x; И каким образом это выполнить в обратном порядке? Мы можем только выполнять программу в прямом порядке, но сохранять данные.. Не более... Толко смотреть на результаты работы ....
мне нравятся подобные заявления, несмотря на фактическое существование подобной вещи. ппц просто... ты _лично_ попробовал как работает это в td386 и чем оно ограничено прежде чем что-либо заявлять ?
infern0 Я не знаю td386 и никогда с ним не работал. Но поиском находится следующее: Команда Back Trace Если вы выполняете трассировку программы,то данная команда изменяет порядок выполнения на обратный. [...] отслеживаются только инструкции, ко- торые выполняются по команде Trace Into (Трассировка вглубь) или Instruction Trace (Трассировка инструкций). Обратную трассировку вызова прерывания выполнять нельзя. Обратная трассировка инструкций, работающих с портами, не действует [...] Ну и так далее.. То есть обрати внимание, что речь идет на самом деле всего лишь о пошаговой отмене результатов трассировки. И даже она не всегда возможна. Думаю, что при трассировке после каждой инструкции просто сохраняется снимок контекста (инкрементально) и при необходимости восстанавливается. К обратному выполнению программы эта функция не имеет естественно никакого отношения. Как уже несколько раз было замечено выше, обратное выполнение невозможно.
nitrotoluol давайте определимся с определениями 1) запоминание контекста(состояние регистров, памяти, портов тд) перед выполнением инструкции - это одно, вполне реально. при отладке может быть очень полезно 2) нахождение и выполнение алгоритма обратного некоему алгоритму - ну бывает реально, бывает challenge, бывает невозможно теоретически. любимая таска кейгенов. частный случай - алгоритм обратный самому себе (например xor) 3) выполнение программы "обратным образом". то есть вот она выполнялась-выполнялась, потом остановилась и "пошла назад" по шагам восстанавливая прошлое. Невозможно теоретически, инструкции без потери информации - скорее исключение чем правило. Да и не нужно такое наверное никому?
infern0 а расскажи кстати как оно работает и чем ограничено реально "выполняются назад" инструкции? я чеcтно говоря очень мало турбо-дебаггер мучал, мне больше нравился тогда QA
да. Кстати было очень полезно когда при трассировке случайно вылетел за пределы цикла и не просек условие или данные. Отмотал на десяток инструкций назад - и вот оно.
Мда, нет слов. td386 это не сумасбродная игрушка, а отладчик, который позволяет именно отматывать\откатывать назад, т.е. получать точно такое же состояние регистров\памяти каким оно было до исполнения заданной инструкции. А это ес-но возможно только при трассировке с сохранением в логе изменений после каждой инструкции и обратном пошаговом восстановлении регистров\памяти без всякого исполнения. Козе понятно, чтобы откатить инструкцию add eax,ecx без сохранения лога нужно выполнить не ее саму, а обратную ей sub eax,ecx. Козе также понятно, что есть необратимые операции типа xor eax,eax, и т.д. и т.п. Но великий infern0 ес-но не коза, и ему как всем великим свойственно ошибаться и верить в чудеса ) (чур без обид
Tid0Wlas А почему бы и нет. Только вот памяти для сохранения контекста нужно оочень много, но задравый смысл в этом есть, но для OS с несколькими уровнями привелегий будет проблематично, теоретически все реально...
Если бы этой записью контекста еще и управлять можно было бы ну что-то типа: "list cmp ?,? ; test ?,?" за последнюю минуту по всем потокам хочу! а размеры памяти и скорость выполнения - не пугают, на нас работают лучшие умы международных корпораций ))
Вот вы говорите об обратном исполнении, пусть инструкции, которая обратима. Как мы узнаем операцию обратную данной? В таблице будем хранить соответствия? Кароч ИМХО, вполне очевидно, что обратное исполнение не только невозможно (из-за необратимых операций), но и нафик никому не нужно.
Mental_Mirror Поддерживаю, ибо проблема не только в контексте. А если программа выделила память и изменила ее? А если программа работала с файлами? Сохранять после каждой ассемблерной инструкци дамп всей памяти и винта??? Поддерживаю вопрос "зачем это нужно???"!
