Здравствуйте!

Необходимо снять дамп и заставить его работать. Всё усложняется наличием упаковщика, который перепаковал исходный код, да и свой код распаковки тоже запаковал. Проверки на отладчик и виртуальные машины тоже имеются.
Первый этап был заставить запускаться (без исключений) код под OllyDbg (в качестве отладчика). Это было достигнуто поиском подходящих функций из ядра, на которых можно "остановить" распаковку, а после этого патч отдельных проверок на отладчик. Благодаря ODbgScript всё это автоматизируется.

Теперь есть упакованная программа, которая остановлена в некоторый момент, когда основной код уже распакован. Снятый дамп не запускается, поскольку некоторый блок инициализации оказался "разрушен". Блок найти удалось, но там ещё видны следы протектора (возможно виртуальная машина) и при запуске вылетает...



Вопрос довольно общий: как "очистить" дамп?
Если говорить на понятийном уровне, то одинаковые команды должны давать одинаковый результат, если применяются к одинаковым данным. Отсюда следует, что в "плохом" дампе нарушена последовательность команд и/или "повреждены" данные. Если считать, что при съёме дампа данные были одинаковые, то причиной "кривизны" данных могут стать особенности загрузки файлов при запуске программы.

Сейчас у меня параллельно (в двух окнах OllyDbg) загружается исходная программа и дамп. При вызове некоторой функции значения в стеке одинаковые. А вот результат разный. Для каждого вызова причина определяется долго и нудно...

Есть ли инструменты, позволяющие сравнивать поведение и память программ?
Может быть есть плагины для OllyDbg, которые "копируют" память, чтобы потом проанализировать разницу во влиянии команд?
Существуют ли утилиты, которые показывают, по каким адресам программа считывала данные, а по каким адресам записывала?
Что используете для "чистки" и снятия дампов?

| Сообщение посчитали полезным:

Изложение вопроса какое-то специфическое,академическое я бы сказал,поэтому, возможно, я не все понял

>>Что используете для "чистки" и снятия дампов?

Понятия "чистки", в Вашем понимании, не существует. Дамп делается еще не инициализированного кода. Если код на OEP украден, то его либо восстанавливают наугад(эвристически так сказать),либо восстанавливают оригинальный код из недр протектора.

Дамп можно делать PeTools - но что-то мне подсказывает,что Вам это известно

| Сообщение посчитали полезным:

coolangel пишет:
Понятия "чистки", в Вашем понимании, не существует. Дамп делается еще не инициализированного кода. Если код на OEP украден, то его либо востанавливают наугад(эвристически так сказать),либо востанавливают оригинальных код из недр протектора.
Опыта у меня нет, а готового решения для снятия протектора тоже не нашёл, поэтому действую сразу во всех направлениях с переменным успехом.
В идеале, конечно, в некоторый момент протектор отпускает код и с помощью JMP делает переход на распакованный код, но боюсь, что не всё так просто. С другой стороны, когда программа работает, то весь её код распакован (случаев с распаковкой лишь отдельных исполняемых блоков не беру), поэтому и хотел подойти с этого конца. В любом случае, программно сравнить поведение исходной программы и дампа значительно проще, чем руками всё это делать.

OEP байты украдены - факт
Предыдущие попытки восстановления пока успехов не принесли.

UPD. У меня два независимых источника указали на одинаковую точку OEP, но там не хватает пролога.

Можете ли посоветовать хорошие статьи по восстановлению "украденного кода из OEP"?
Компилятор Visual C++ 9.0 (Visual Studio 2008).
(Пока читаю вот эти www.cracklab.narod.ru/doc/u_oep.htm и www.cracklab.narod.ru/doc/u_oep2.htm )

| Сообщение посчитали полезным:

valot
А что за прот?

| Сообщение посчитали полезным:

SReg
пишут, что [!] VM Protect v1.60 - v2.05 (or newer) detected !
Это точно он, а вот версию не знаю.

| Сообщение посчитали полезным:

valot пишет:
С другой стороны, когда программа работает, то весь её код распакован (случаев с распаковкой лишь отдельных исполняемых блоков не беру), поэтому и хотел подойти с этого конца.

Выложите саму программу,может повезет и кто глянет. Если протектор навешан правильно,то OEP не просто украдено,оно виртуализовано,т.е. команды из OEP выполняются в виртуальное машине,и обычно это не 3-5 команд. Более того,прыжки в виртуальную машину могут быть и посередине программы.

Также пока нигде не фигурирует импорт,он что,нетронутый?

На форуме есть тема с --> тулзой <--,которая помогает декомпилировать код для ВМ vprotect'а.

В общем,схема такая:
1)Берете любую версию vmprotect'а и пакуете блокнот с минимальной защитой
2)Находите любой тутор по снятию vmprotect'а и пробуете снять защиту
3)Потом увеличиваете опции защиты и пробуете снять.
4)Когда получится снять хоть что-то, можно пробовать учится девиртуализовать код из OEP ранее запакованого блокнота с помощью готовой тулзы
5)Возвращаетесь к своей программе

P.S. Предполагается, что upx вручную Вы снимаете с закрытыми глазами

| Сообщение посчитали полезным:

coolangel
Есть объективные причины, по которым программу выложить не могу.

Что-то не открывается у меня предложенная тема. Смотрел http://exelab.ru/f/action=vthread&forum=3&topic=17506 - показывает, но пока не разбирался, что с этим дальше делать.

Импорт почти весь собирается в одном месте, поэтому через impRec удаётся добавить.
Академический пусть "с блокнотом и калькулятором" не вполне подходит, поэтому полагаюсь на высокую удачу и критические попадания. (Да и научиться в реальном бою значительно проще...)


В соседней ветке рассказали про трассировку в Olly, поэтому теперь многое упростилось. Благодаря ей смог отловить моменты выхода из кода распаковщика в код исходной программы. Увидел, что вначале программа выполняет __security_init_cookie, потом начинает что-то дораспаковывать, а потом уже CRTStartup и переход к основному блоку. Между ними полностью (кроме пары нулей) достраивается таблица импорта.
На пустом месте сделал CALL и JMP на инициализацию, подключил импорт. Пока что-то не заработало...

Внутри кода идут вызовы в "распаковщик", видимо, использование виртуальной машины.
Сейчас не хватает какой-нибудь "грубой силы", чтобы рассказала, чем отличается выполнение исходной программы (по вызовам) от моей...

| Сообщение посчитали полезным:

>>Сейчас не хватает какой-нибудь "грубой силы", чтобы рассказала, чем отличается выполнение исходной программы (по вызовам) от моей...

Это заблуждение, "вера в чудо"
Конечно,можно допустить,что вмпротект навешан в режиме пакера, а Вы просто не там копаетесь и на самом деле все там просто, но вероятность этого невелика

| Сообщение посчитали полезным:

Runner
Пусть и заблуждение, главное, чтобы работало.

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

По сути, нужна автоматизация выполнения пошаговой отладки (трассировки). Вначале снимается "правильная" последовательность команд, а после этого запускается дамп, в котором проверяется, чтобы все команды банально совпали со своими параметрами (исключения - ресурсы, выделяемые системой, например, handle файла при открытии).

Если для распаковки знаете работающий без озарения вариант, то чем от "грубой силы" будет отличаться, а если любая распаковка - это озарение, то чем не "вера в чудо"?

P.S. В качестве примера вспомнился ArtMoney - программа, которая банально сравнивает дампы памяти и помогает увеличить золото в играх и т.п.

| Сообщение посчитали полезным:

valot пишет:
Считаю, что при начальной одинаковой инициализации памяти и стека, программы должны выполняться одинаково.

О сложностях такого подхода --> тут <--

| Сообщение посчитали полезным:

Я вот этим forum.tuts4you.com/showtopic=24390 делал дамп, более-менее работает, виртуализацию конечно не обойдешь, но хоть с анпаком не приходится ипацо

| Сообщение посчитали полезным:

Runner пишет:
О сложностях такого подхода --> тут <--
есть подозрение, что это метод "грубой силы", а значит более устойчивый к изменениям защиты и не требующий озарения


Airenikus пишет:
Я вот этим --> Link <-- делал дамп, более-менее работает, виртуализацию конечно не обойдешь, но хоть с анпаком не приходится ипацо
пока нужен только работающий дамп, а виртуальная машина пусть работает - не мешает;

Возник вопрос по настройке на скриншоте 20 (прикрепил к сообщению). Это какой плагин?

5199_02.02.2011_CRACKLAB.rU.tgz - 20.png

| Сообщение посчитали полезным:

valot на картинке(в аттаче) это опции утилиты PE Tools.

-----
все багрепорты - в личные сообщения

| Сообщение посчитали полезным: