Сейчас на форуме: (+9 невидимых) |
eXeL@B —› Протекторы —› Декомпилятор ВМ |
<< . 1 . 2 . 3 . 4 . 5 . 6 . 7 . 8 . 9 . 10 ... 23 . 24 . >> |
Посл.ответ | Сообщение |
|
Создано: 03 марта 2010 12:33 · Личное сообщение · #1 Вашему вниманию предлагаются наработки по декомпиляции ВМ. Проект на сегодняшний день для меня завершен, но жаль если результат "ляжет на полку", может кому-нибудь и пригодится. Предлагаю сначала ознакомиться с обзором, и если будет интерес то могу выложить и сам плагин, или здесь или в личку заинтересованным лицам, каким образом, пока ещё не решил... Но если кто-либо ожидает увидеть "автоматическое чудо", то сразу скажу - его нет. Для того чтобы получить результат нужна ручная предварительная работа: - с исследуемой программы должна быть снята упаковка - точки входа в ВМ находятся вручную - возможно неоднократное "жамкание" клавиш в OllyDbg, а возможно и модификация кода, чтобы попасть в нужное место, в зависимости от защищенной функции - необходимо вручную прицепить к программе требуемый секцию - запись результатов в файл это тоже ручная работа, но уже более приятная Не всё гладко обстоит с определением реализаций ВМ, на сегодняшний день примерно каждая третья реализация автоматом не определяется, приходится под неё модернизировать плагин, т.к. не могу сразу предусмотреть все случаи "издевательств" ВМ с кодом примитивов. Лучше дела с восстановлением "исходного" кода защищенных функций - 70% нормально восстанавливается, хотя во многом это зависит от самой структуры функции. Таким образом, если будет заинтересованность и помощь в нахождении подобных ситуаций, то проект может быть доведен до релизной стадии. ЗЫ: Речь идет об Ореановских машинах. Нигде специально не упоминал. 9c41_03.03.2010_CRACKLAB.rU.tgz - VMSweeperLst.rar ----- Everything is relative... |
|
Создано: 23 января 2011 12:11 · Поправил: Vamit · Личное сообщение · #2 Очередная версия VMSweeper 1.4 beta 6. Добавлено: 1. Полная логическая реструктуризация промкода на основе карты пикода. Имеется возможность просмотра в графическом виде карты пикода. Для этого используется конвертер PMBtoGDL.exe (отдельная благодарность Ultras'у за его создание), который преобразовывает файл pmb (picode map binary) в графический формат, который может быть просмотрен прогой aiSee3. Карты пикода строятся Свипером до и после реструктуризации для проверки её правильности. 2. Обработчики FPU примитивов. Обработчики добавлены не все, а только те, которые мне встретились в последних версиях вмпрота при анализе вм участвующих в распаковке/защите файла. Промкод с FPU инструкциями пока не строится, т.к. виртуализация FPU мной не была встречена. 3. Много мелких, но полезных изменений. Тестируйте, по крайней мере, Свипер должен доходить до шага a12 final, но не всё в нем ещё красиво - работа продолжается... 0ba5_23.01.2011_CRACKLAB.rU.tgz - VMSweeper14beta6.rar ----- Everything is relative... | Сообщение посчитали полезным: ClockMan, _ruzmaz_, SReg, huckfuck, m0bscene, [Nomad], Yotun, daFix, Gideon Vi |
|
Создано: 24 января 2011 06:36 · Личное сообщение · #3 |
|
Создано: 24 января 2011 09:13 · Личное сообщение · #4 |
|
Создано: 24 января 2011 10:15 · Поправил: ARCHANGEL · Личное сообщение · #5 |
|
Создано: 24 января 2011 10:39 · Личное сообщение · #6 |
|
Создано: 24 января 2011 14:08 · Личное сообщение · #7 |
|
Создано: 26 января 2011 17:10 · Поправил: Vamit · Личное сообщение · #8 Вмпротект при виртуализации своих протекторов/распаковщиков часто использует следующую комбинацию: Code:
pushfd приведено схематично, для упрощения выражения, на самом деле это регистр вм содержащий флаги CPU (push rvm_xx). В наборе инструкций Интела ничего подобного нет. Вопрос, что бы это могло значить, т.е. какой реальной инструкцией можно заменить результат этой виртуализации или вообще её скипать за ненадобностью? ----- Everything is relative... |
|
Создано: 27 января 2011 08:55 · Личное сообщение · #9 Раз ответа нет, приведу свой вариант объяснения, надеюсь он правильный. Так как вмпрот использует два алгоритма виртуализации инструкций CPU - флаговый (флаги CPU полностью эмулируются) и безфлаговый (эмуляция флагов отсутствует), то приведенная выше конструкция устраняет побочные флаговые эффекты для безфлагового режима виртуализации. Значит её нужно скипать за ненадобностью в реальном коде. ----- Everything is relative... |
|
Создано: 27 января 2011 12:02 · Личное сообщение · #10 Vamit единственно что меня смущает(если я не ошибся) это младший бит в 7ке. если не ошибаюсь это поднятие флага трассировки ru.wikipedia.org/wiki/%D0%A0%D0%B5%D0%B3%D0%B8%D1%81%D1%82%D1%80_%D1%84%D0%BB%D0%B0%D0%B3%D0%BE%D0%B2 ----- Наша работа во тьме, Мы делаем, что умеем. Мы отдаем, что имеем, Наша работа во тьме.... |
|
Создано: 27 января 2011 12:27 · Личное сообщение · #11 |
|
Создано: 27 января 2011 12:47 · Поправил: PE_Kill · Личное сообщение · #12 |
|
Создано: 27 января 2011 14:17 · Личное сообщение · #13 |
|
Создано: 27 января 2011 16:20 · Личное сообщение · #14 VodoleY пишет: до поддержки инструкций мат. проца руки не дошли ж? Дошли, но частично , вот список распознаваемых вм обработчиков: wait, fld, fild, fstp, fadd, fcomp, fstsw. Другие пока не встретил, но созданный из них промкод декомпилироваться не будет, т.к. такие обработчики есть, а пока не используются. Дописываю по мере встречи с ними... ----- Everything is relative... |
|
Создано: 27 января 2011 17:54 · Личное сообщение · #15 |
|
Создано: 27 января 2011 18:05 · Личное сообщение · #16 |
|
Создано: 28 января 2011 15:41 · Личное сообщение · #17 Очередная версия VMSweeper 1.4 beta 7. Добавлено: 1. Опция AntiAntiDebug. 2. Опция Break on TLS. 3. Первоначальная обработка AntiDump. 4. Девиртуализация инструкции retn xx. 5. Девиртуализация инструкции sub без флагов. 6. Восстановление скрытого вызова процедуры (типа push xx; retn) 7. Коррекция смещений при адресации стека через esp. 8. Улучшено распознавание начала цикла вм в CodeVirtualizer. Исправлено: 1. Реструктуризация промкода. Иногда прямая ветка после условного перехода шла в середину следующего блока. 2. Коррекция указателя esp при декомпиляции mov esp, [esp] 3. Восстановление косвенных вызовов процедур. 4. Распознавание соответствия регистров CPU и ВМ на инструкциях pop xx. 5652_28.01.2011_CRACKLAB.rU.tgz - VMSweeper14beta7.rar ----- Everything is relative... | Сообщение посчитали полезным: huckfuck, SReg, ClockMan, daFix, m0bscene, r_e, _ruzmaz_, Errins, Bronco, Yotun, Gideon Vi, Nightshade, stas_02, stub |
|
Создано: 01 февраля 2011 12:20 · Личное сообщение · #18 Vamit Здравствуйте! Пытаюсь разобраться с одной программой, накрытой, думаю последним, VMProtect. Запустил VMSweeper14beta7 на OEP - определила адреса использованных функций. Перестроить таблицу импорта не предлагала, но она уже почти вся и так была собрана. Нажал F1 на первой - сгенерировала 300 файлов. Теперь вот сижу в раздумьях, что же дальше со всем этим делать. В соседней теме есть ссылка на инструмент http://exelab.ru/f/action=vthread&forum=3&topic=17506 . Он позволяет пошагово пройтись по командам VM и посмотреть за изменениями регистров и памяти (= дизассемблер на уровне виртуальной машины). Там же есть список всех инструкций VM, но с генерируемыми VMSweeper не смог сразу соотнести. Подскажите, пожалуйста, как на основе полученных trc и log файлов проще всего сгенерировать asm (без VM) или максимально изолировать отдельные функции для сборки дампа? |
|
Создано: 01 февраля 2011 14:30 · Личное сообщение · #19 valot пишет: Нажал F1 на первой - сгенерировала 300 файлов. Этого не может быть... Большое кол-во файлов генерится Свипером при Analyze all VM references, но они никакого отношения к декодировке защищенных функций не имеют, поэтому все эти файлы после анализа можно удалить, если он прошел успешно. Желательно сохранить окно найденных ссылок в файл, чтобы потом можно было бы ориентироваться в защищенных функциях, т.к. это окно "одноразовое". При декомпиляции защищенной функции по F1 создаются два основных файла c именем адреса декодируемой области, на котором нажали F1, и расширениями log и trc. Трейс файл содержит следующую последовательную информацию: 1. Асм код с трассировкой значений от точки старта до начала цикла вм, по этому куску распознается тип вм. 2. Сегменты кода и вм заданные юзером или автоматически определенные Свипером. 3. Асм код с трассировкой значений цикла вм до вызова обработчика. 4. Трассировка обработчиков вм от Start Virtual Machine до Stop Virtual Machine. В конце этой секции находится карта шагов по реструктуризации промкода - Pimap: step 1 и т.д. 5. Созданный промкод. Это последовательность обработчиков примитивов представленная чистым асм кодом. Далее этот код декомпилируется и если декомпиляция успешна (создается файл логов), то на точке старта создается инструкция jmp промкод. Можно осуществить переход в него и походить по нему Олькой. 6. Дальнейшие секции файла от Adjust block 000 до Optimized text a12 final отображают шаги декомпиляции промкода и интереса для юзера не представляют. Лог файл содержит следующую последовательную информацию: 1. От Section 000 до Section 005 разбивка промкода на логические блоки и их группировка. 2. Section a00 - представление значимых инструкций промкода 3. Section a01 code - аналогично, только адреса регистров вм заменены аббревиатурой rvm_xx, где хх - смещение регистра вм в блоке регистров. 4. Список зон изменения соответствий регистров вм и CPU. 5. Шаги декомпиляции зон промкода. От Section a02 (zone х) до Section a07 remove rvm2 (zone x), где х - номер зоны промкода. Что производит Свипер с кодом на этих шагах можно понять из названия секции и сравнения кода в ней с кодом предыдущей секции. 6. Section a08 svm - секция объединяющая все декомпилированные зоны промкода с последующим поглощением стековых переменных вм - svm_xx 7. Список зон изменения соответствий регистров вм и CPU с учетом девиртуализации инструкций. 8. Section a11 reg - первоначальная замена регистров вм регистрами CPU. 9. Список зон изменения соответствий регистров вм и CPU с учетом выполненной замены. 10. Section a11 resolve reg - окончательная замена регистров вм регистрами CPU. 11. Section a12 final - текстовое представление декомпилированного промкода. 12. Section asm - окончательно восстановленный асм код функции. Информация с блока 8 и до конца часто может быть недостоверной, т.к. пока 100% восстановить соответствие регистров вм и CPU удается далеко не всегда. До блока 8 информация достоверна, но может быть избыточной ввиду того, что некоторые инструкции кода не девиртуализовались по разным причинам. Так же ещё создаются порядка десятка map файлов - карты ресурсов вм и промкода, содержимое их должно быть понятно из названия. Он позволяет пошагово пройтись по командам VM и посмотреть за изменениями регистров и памяти Пробовал, не понравилось, берет только одну секцию вм до выхода из неё, а реально в кодированной функции может быть несколько десятков взаимоувязанных секций... На более конкретные вопросы могу ответить конкретно... ----- Everything is relative... | Сообщение посчитали полезным: valot |
|
Создано: 01 февраля 2011 19:09 · Поправил: valot · Личное сообщение · #20 Vamit пишет: На более конкретные вопросы могу ответить конкретно... Спасибо за подробные пояснения. У меня почти во всех файлах заканчивается описание на секции 02 и лишь в некоторых 04 с перечнем VM примитивов. Буду работать над файлом дальше. Хотел узнать, есть ли пример программы (лучше всего, конечно, с VMProtect), для которой "правильно" декомпилируется vm, чтобы можно было "сравнить со здоровой"? Или хотя бы можете выложить пример файлов с полной расшифровкой секций, чтобы представлять, куда стремиться? |
|
Создано: 01 февраля 2011 19:34 · Личное сообщение · #21 Одну из предыдущих версий я выкладывал с тестовым примером, который 100% декомпилируется. Смотри ----- Everything is relative... |
|
Создано: 04 февраля 2011 14:23 · Поправил: Vamit · Личное сообщение · #22 Очередная версия VMSweeper 1.4 beta 8. Добавлено: 1. Улучшено распознавание транзитных меток. 2. Улучшено распознавание условных переходов. 3. Улучшено распознавание использования переменной при её частичном переприсвоении. 4. Удаление декодирования адреса безусловного перехода. 5. Второй алгоритм подсчета CRC для VMProtect версии выше 2.0 6. Защита DRx регистров (аппаратных точек останова) от VMProtect. 7. Обработка прямого вызова АПИ после кодированного выхода из ВМ. Исправлено: 1. Реструктуризация промкода. Иногда прямая ветка после условного перехода шла не на следующий блок. 2. Реструктуризация промкода. Для невырожденного безусловного перехода добавляется зона метки. 3. Распознавание использования регистра ВМ в строке с его инициализацией. 4. Девиртуализация инструкции retn xx теперь не зависит от кол-ва переменных вм в стеке. 5. Метка вырожденного перехода не удаляется если на неё идут другие переходы. 6. Устранено переполнение стека и исключение при поиске соответствия регистров вм и CPU в цикле. 7. При автоматическом рестарте программы не активировалась опция AntiAntiDebug. Так как на сегодняшний день Свипер практически является самодостаточным (встроены все необходимые средства защиты от ВмПротекта) и самостоятельным (анализ, восстановление и декомпиляция почти всех возможностей ВмПротекта, но в разной пока мере, а также изучение его методов защиты файлов - декомпиляция загрузчиков/протекторов и TLS кода), то приведу несколько советов в дополнение к сказанному в хелпе (всё для ВмПротекта): 1. Во избежании конфликтов (двойной инлайн патчинг) нужно отключить опции защиты в других плагинах, стоящих рядом со Свипером, или вообще убрать их, в первую очередь это относится к Стронгу и Фантому. 2. При начале работы с новой прогой делаем останов на ЕП, запускаем Analyze all VM references, на пустое окно ссылок не обращаем внимание и декомпилируем ЕП. 3. В секции а12 лог файла находим ОЕП, её видно практически невооруженным взглядом в версиях вмпрота выше 2.0. Если же код на ОЕП сожран протектором, то придется декомпилировать несколько последовательных вызовов вм, адрес каждой последующей вм виден в логе предыдущей. Последняя вм будет содержать сожранный кусок кода с ОЕП до первой вызываемой функции. 4. Если интересно содержание TLS, то можно остановиться на нем и декомпилировать, но там ничего полезного для дальнейшей работы с файлом нет. 5. Ставим НВР на ОЕП. Если протектор имеет защиту от дебага, то в Ольке ставим системный стоп и включаем опцию антиантидебага в Свипере. Рестартуем прогу. 6. Давим F9 и мы на ОЕП. Запускаем Analyze all VM references, проверив значения сегментов предложенные Свипером и, если нужно, корректируем их. Сохраняем найденный список в файл. Выбираем интересующий кусок кода накрытый вм и ставим на него обычный бряк. Делаем реанализ кода, если он не был сделан Свипером, например, при восстановлении импорта. 7. Выходим из Ольки. Нужно для того, чтобы вся собранная Свипером инфа сохранилась в UDD файле проги, иначе при вылете на декомпиляции будет потеряна часть нужной инфы и п.6 придется выполнять заново. 8. Загружаем прогу, доходим до ОЕП, активируем бряк на выбранной функе, достигаем его - а далее всё было описано ранее... f632_04.02.2011_CRACKLAB.rU.tgz - VMSweeper14beta8.rar ----- Everything is relative... | Сообщение посчитали полезным: ClockMan, SReg, Nightshade, huckfuck, m0bscene, Yotun, _ruzmaz_, r_e, daFix, Gideon Vi, v00doo |
|
Создано: 05 февраля 2011 10:26 · Личное сообщение · #23 Vamit либо я чет недопонимаю, либо в 8ой бэтке стало больше багов (проверил на 2ух компах) почемуто перестал в подопытной проге находит точки входа в ВМ, (предыдующий находил). Если его тыкать в анализ руками, после рестарта останавливается и при попытке любого действия орет, что анализ уже запущен при этом ниче не делает. ----- Наша работа во тьме, Мы делаем, что умеем. Мы отдаем, что имеем, Наша работа во тьме.... |
|
Создано: 05 февраля 2011 11:02 · Поправил: Ultras · Личное сообщение · #24 |
|
Создано: 05 февраля 2011 11:24 · Личное сообщение · #25 |
|
Создано: 05 февраля 2011 18:51 · Личное сообщение · #26 VodoleY пишет: мне Vamit лично указывал, правда несколько месяцев назад , и с прошлыми версиями свипера было все путем Много воды утекло с тех пор... что-то ушло, но больше добавилось... Если точка в вм не определяется Свипером,то: 1. Если она есть в списке ссылок, но имеет не postponed статус, то это ошибка Свипера. 2. Если она в списке отсутствует, то смотрим куда идет переход из этой точки, если в сегмент вм с заданными границами, то это ошибка Свипера, если мимо сегмента вм, то это ваша ошибка - расширьте границы сегмента вм и повторите анализ. ----- Everything is relative... |
|
Создано: 05 февраля 2011 20:57 · Поправил: VodoleY · Личное сообщение · #27 Vamit я руками ставлю на начало ВМ на певую инструкцию=ОЕП вобщем как надо. прошлый билд очень чудесно хавал, хоть и ругался (читайте асю) НО тут полезли баги. Причем разнообразные. с прошлым билдом с этой же прогой такого не было З.Ы. по опыту общения... мы мне проще отправить ехе шник.. сами посмотрите, ОН ТоТ же . у мну просто не доходят руки до этого проэкта.Но он показательный. З.Ы.Ы. Я не ругаюсь, и не привередничаю, простите мастер. Просто глюк есть. Может быть ток в моем случае. Ибо ВАШ продук я лиш на одной проге и катаю. ----- Наша работа во тьме, Мы делаем, что умеем. Мы отдаем, что имеем, Наша работа во тьме.... |
|
Создано: 07 февраля 2011 09:23 · Поправил: Vamit · Личное сообщение · #28 VodoleY пишет: прошлый билд очень чудесно хавал, хоть и ругался (читайте асю) НО тут полезли баги. Нужно было ещё давно, вроде с версии 1.3 beta xx, удалить удд файл и отрезать секцию .vm от файла, а ещё лучше взять оригинальный файл, т.к. секция .vm ломает CRC файла и вмпрот это ловит... и провести анализ кода заново, он должен пройти успешно. Но, в твоем случае, декомпиляция ЕП не прошла бы, т.к. конкретно в этом файле собран почти весь набор ФПУ обработчиков, их за выходные я уже реализовал, так что увидеть это будет можно в следующей версии. ----- Everything is relative... |
|
Создано: 07 февраля 2011 09:46 · Личное сообщение · #29 |
|
Создано: 15 февраля 2011 10:00 · Поправил: Vamit · Личное сообщение · #30 Раскопал ещё одну защиту ВмПротекта: Code:
этот код втыкается протектором в начало каждой защищенной им функции. Вопрос: что это такое может быть? Реализаций такого кода может быть несколько - вместо bswap могут использоваться любые инструкции сдвига. ----- Everything is relative... |
|
Создано: 15 февраля 2011 10:07 · Личное сообщение · #31 |
<< . 1 . 2 . 3 . 4 . 5 . 6 . 7 . 8 . 9 . 10 ... 23 . 24 . >> |
eXeL@B —› Протекторы —› Декомпилятор ВМ |