| Сейчас на форуме: (+8 невидимых) |
 |
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...  |
|
|
Создано: 03 марта 2010 12:50 · Личное сообщение · #2 выкладывай плуг обзор смотреть не интересно |
|
|
Создано: 03 марта 2010 13:24 · Личное сообщение · #3 Vamit пишет: Речь идет об Ореановских машинах. Из приведенного обзора (описания пикода в частности) видно что речь идет не обо всех Ореановских а только CISC, ну может CISC-2. ----- 127.0.0.1, sweet 127.0.0.1 |
|
|
Создано: 03 марта 2010 14:34 · Личное сообщение · #4 OKOB пишет: не обо всех Ореановских Я и не говорил, что обо всех, реализовал те, которые попались - два типа, а возможно и две разновидности одного типа (различия в кол-ве регистров и опкодов), как нызываются - просто не знаю, вполне возможно и CISC. ----- Everything is relative... |
|
|
Создано: 03 марта 2010 14:39 · Поправил: BoRoV · Личное сообщение · #5 ну ты будешь вылаживать плуг или как? ок, тогда ждем 
----- Лучше быть одиноким, но свободным © $me |
|
|
Создано: 03 марта 2010 14:51 · Личное сообщение · #6 BoRoV пишет: ну ты будешь вылаживать плуг или как? Буду, дайте только Help дописать, а то не разберетесь...
----- Everything is relative... |
|
|
Создано: 03 марта 2010 15:07 · Личное сообщение · #7 Выкладывай будем тестить
----- Чтобы правильно задать вопрос, нужно знать большую часть ответа. Р.Шекли. |
|
|
Создано: 03 марта 2010 16:48 · Личное сообщение · #8 |
|
|
Создано: 03 марта 2010 18:01 · Личное сообщение · #9 Цитата из хелпа: "2. Стартуем OllyDbg, загружаем программу, находим точку входа в ВМ в восстанавливаемой функции (это jmp на секцию с телом ВМ), ставим на него Breakpoint (F2). " Пример полностью подпадающий под вышеприведенный обзор и данный пункт хэлпа. (Themida 2.1.1.0) Code:
однако машина RISC VM и ничего не взлетит, поэтому хорошо бы привести пример жертвы на которой можно опробывать с адресами входа в ВМ или описать как определить именно этот тип ВМ под который заточен плаг. ----- 127.0.0.1, sweet 127.0.0.1 |
|
|
Создано: 03 марта 2010 18:04 · Поправил: mak · Личное сообщение · #10 Интересно, по стилю изложения, по меткам в листингах , похож на автора декомпиляции вм орианс , выложенной в теме на васме Ктонибудь ковырял ВМпротект, это продолжение той работы? Исходники ожидаются? Деобфускация и трассировка флагов процессора , очень интересная тема, очень много новых решений в защите программ... без эмуля не обойтись, хотя он примитивный всеравно будет как в деморфе аспровых команд. Есть план расширить инф. в статью с более детальными коментариями - мыслями , кусками исходного кода , вариантами дальнейшего развития?! ----- RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube |
|
|
Создано: 03 марта 2010 18:08 · Поправил: OKOB · Личное сообщение · #11 mak пишет: похож на автора декомпиляции вм орианс , выложенной в теме на васме Ктонибудь ковырял ВМпротект да это один к одному тот материал (hxxp://www.wasm.ru/forum/viewtopic.php?pid=335280) Ник - VAM, просто ВАСМ пал и все тут проклевываются (в Дневниках и Блогах еще один завсегдатай ВАСМ с My Dos Explorer). ----- 127.0.0.1, sweet 127.0.0.1 |
|
|
Создано: 03 марта 2010 18:44 · Личное сообщение · #12 OKOB пишет: просто ВАСМ пал В последнее время уже нормально работает |
|
|
Создано: 03 марта 2010 19:14 · Личное сообщение · #13 OKOB пишет: однако машина RISC VM и ничего не взлетит Не понял высказывание, да, код похож, а что говорит плагин? Тип ВМ он определит сам, если не способен обработать то сообщит. За свою прогу можете не волноваться ни один байт в файле без вашего участия изменен не будет. mak пишет: это продолжение той работы? Да это таже работа и автор тот же Исходники ожидаются? Нет, используемые алгоритмы задействованы не только здесь, но ещё и в коммерческих проектах. Есть план расширить инф. в статью с более детальными коментариями - мыслями , кусками исходного кода , вариантами дальнейшего развития?! Пока нет, всё зависит от интереса к проекту, если будет дальнейшее развитие проги, то почему бы и не поделиться информацией... OKOB пишет: просто ВАСМ пал и все тут проклевываются ВАСМ не пал, просто активность там низкая и специфика здесь ближе к практике... ----- Everything is relative... |
|
|
Создано: 03 марта 2010 19:28 · Поправил: OKOB · Личное сообщение · #14 Vamit пишет: Тип ВМ он определит сам Да далее нет ожидаемого плагином цикла выбора опкодов, а ... (в продолжение кода приведенного выше) Code:
Доступ к таблице блоков пикода, ожидание освобождения исполнителя и т.д. ----- 127.0.0.1, sweet 127.0.0.1 |
|
|
Создано: 03 марта 2010 20:04 · Личное сообщение · #15 Vamit пишет: Исходники ожидаются? Нет, используемые алгоритмы задействованы не только здесь, но ещё и в коммерческих проектах. Используется что то не стандартное? Или просто комерческая тайна из за комерческого продукта? Про промежуточный код можно поподробнее рассказать? Vamit пишет: сть план расширить инф. в статью с более детальными коментариями - мыслями , кусками исходного кода , вариантами дальнейшего развития?! Пока нет, всё зависит от интереса к проекту, если будет дальнейшее развитие проги, то почему бы и не поделиться информацией... Интерес уже давно у многих есть, но в основном не в готовых решениях а в методах , интерес имеется в виду в плане тестирования? Выложи пожалуста цель , под которой можно посмотреть работу. ----- RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube |
|
|
Создано: 04 марта 2010 09:54 · Личное сообщение · #16 mak пишет: Про промежуточный код можно поподробнее рассказать? Можно, будет конкретный вопрос - будет и ответ, только желательно при вопросе ссылаться на определенную часть Описания ВМ для соблюдения терминологии и взаимопонимания. интерес имеется в виду в плане тестирования? Нет, вернее не только, для меня интерес определяется не тем, что кто-то сказал "мне интересно", а рейтингом темы, если в ней идет диалог - то всё нормально, если больше месяца затишье - интерес кончился. Выложи пожалуста цель , под которой можно посмотреть работу. Легко сказать - сложно сделать, то что "копал" по определенным причинам выложить не могу, а другого просто нет. Могу ответить на этот вопрос OKOB: описать как определить именно этот тип ВМ под который заточен плаг , более подробно детализировать тип ВМ, чем это описано в файле BodyVM.cpp и обозначить ключевые моменты по которым VMSweeper (далее VMS или ВМС) определяет возможность её обработки, если, конечно, это вам нужно... Понимаете, ВМ не сообщает о себе открыто, я такая-то и такая, использую то-то и то-то, поэтому я даже конкретно ответить не могу каким протектором подготовить файл для исследования, могу только сказать, что это одна из последних версий CodeVirtualizer. ----- Everything is relative... |
|
|
Создано: 04 марта 2010 13:34 · Личное сообщение · #17 Vamit > то что "копал" по определенным причинам выложить не могу, а другого просто нет т.е. получается, что тестирование было только на одном примере? ----- EnJoy! |
|
|
Создано: 04 марта 2010 14:20 · Личное сообщение · #18 Jupiter пишет: получается, что тестирование было только на одном примере? Нет, обработано было 6 разных программ одной тематики, в каждом файле по 3 реализации ВМ (двух типов или две разновидности одного типа, не знаю, как правильнее), общее кол-во восстановленных функций > 100. ЗЫ: Приложил подробное описание ВМ 493a_04.03.2010_CRACKLAB.rU.tgz - BodyVMFull.cc
----- Everything is relative... |
|
|
Создано: 04 марта 2010 14:39 · Поправил: mak · Личное сообщение · #19 3. Создание из значимых команд примитивов промежуточного рабочего ассемблерного кода, заменяющего интерпретатор ВМ. и Итог шага: ВМ исключена из работы и заменена декодированным промежуточным рабочим кодом. Этот код является «грязным», т.к. имеет большую степень обфускации, вот его чисткой мы и займемся далее. В дополнение прилагается полный листинг «дизассемблированного» пикода PiCodeVM.rar и полный листинг промежуточного рабочего кода DecodeVM.rar Как формируется промежуточный код ? Какие правила формирования промежуточного кода? Правила синтаксиса? Я так понял , он прогоняется поэтапно , поэтому и спросил , этапы формирования до конечного асм кода, нашел Шаг 2 Дизассемблируем и конвертируем полученный промежуточный код в структуры инструкций (insn_t) и операндов (op_t), позаимствованные у IDA. На это есть две причины. Первое – структуры IDA, описывающие команды ассемблера очень упорядоченные, по сравнению со структурами Olly, в которых, мягко говоря, полный бардак. Второе – дальнейший обработчик кода позаимствован из Декомпилятора С++, который работает с IDA’шными структурами. Создаем карту всех переходов с сохранением/восстановлением состояний трассировки кода в точках возможного разрыва линейного анализа. Например, блоки if … else. Файл карты xRefs.stat есть в приложении logs.rar. Инициализируем структуры всех регистров, стека и памяти. В этой точке мы готовы к статической трассировке промежуточного кода. Трассировку проводим в два прохода. Первый проход линейный, разрывов потоков данных в точках присвоения (их мы ещё и не выявили) не происходит, в местах взаимо исключаемых переходов осуществляется сохранение-восстановление всех данных. На первом проходе: - строятся массивы точек изменения состояний нативных регистров (EMPTY, UNKNOWN, INIT, CHANGE, USE) - строятся массивы всех присвоений ячейкам памяти и изменений значений в памяти - создаются логические блоки следующих типов: CNGFLAG, JMP и JCC, CALL и осуществляется юстировка их границ, если требуется - определяются границы блоков входа и выхода из ВМ (ENTRY/RESTORE) Состояние после первого прохода приведено в логе, секция 000. После первого прохода создаем: - Блоки ENTRY и RESTORE - Блоки всех присвоений и изменений для всех ячеек памяти - ASSIGN (MEM) - Блоки всех присвоений и изменений для всех регистров ВМ - ASSIGN (REGVM), это та же ячейка памяти, только находится по специальному адресу. - Блоки некоторых присвоений и изменений для некоторых нативных регистров - ASSIGN (REG) по специальному алгоритму - Блоки всех присвоений (помещение в стек) для всех аргументов функций - ASSIGN (ARG) Состояние приведено в логе, секция 001. Далее следуют несколько обработчиков созданных блоков, которые вызываются последовательно, в нашем случае, первый обработчик юстирует начальные границы блоков, когда переход идет внутрь блока или на пустое место, которое не принадлежит ни одному блоку, в этом месте создается блок «пустышка» DUMMY. Второй обработчик корректирует начальные границы блоков для исключения разрывов. Состояние приведено в логе, секция 003. Как происходит назначение регистров для формирования асм кода? Меня интеерсует вопрос о универсальности , когда код , разморфлен , а потом переведен в вм вариант , при этом вычисления внутри вм уже идут не по значениям или офсетам настоящей проекции архитектуры х86 , а совершенно беспорядочно , нов даже тут есть порядок , определенный вектор , при смешивании или перестройки регистров , внутри вм , этот вектор не нарушается , если стэковые команды с гемором мы опознаем , то уже другии интерпретации придется прогонять через анализатор и карту распределения регистров , для декомпиляции. Поэтому вопрос заданный выше относится только к твоему коду , все остальное , мысли вслух о других модификациях вм. Данные при перемещении или изменении из/в регистров, ячеек памяти и стека не затирают друг друга, а выстраиваются в логические цепочки выражений. Далее эти структуры выстраиваются в строки (не текстовые), которые составят двусвязный список текста. Результат этого прохода виден в логе, секция а00. Как видно большая часть обфускации кода после этих операций исчезла. Что значит деобфускация исчезла? Если я правильно понял , то это не совсем деобфускация , а лишь одно из следствий применения виртуальной машины как защиты ?! Или? Шаг 3 (заключительный) дальнейшая обработка будет производиться над строками и текстом. Производим деобфускацию констант и корректируем стековые смещения. Лог, секция а04. Принцип построения деобфускатора? Заточен только под конкретную цель ? Далее на шаге три Заменяем регистры ВМ нативными регистрами. Лог, секция а06. Поподробнее можно пожалуста Деобфускация и трассировка флагов процессора Привидите примеры кода из вашей программы защищенной , думаю это ее не скомпрометирует  Сэнкс! П.С. Коменты просто смотрятся по дурацки , совершенно не приятно для чтения , а вот тэги как у кода , белые , очень хорошо. Но такой глюк бывает. ----- RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube |
|
|
Создано: 04 марта 2010 15:14 · Поправил: Vamit · Личное сообщение · #20 mak пишет: Code: А пустые окошки кода - это что? Или глюк скрипта, когда в окошке одна длинная строка, то она накрывается полосой прокрутки, можно пост подправить, пожалуйста... Может в данном случае лучше использовать тег цитаты вместо тега кода. ----- Everything is relative... |
|
|
Создано: 04 марта 2010 15:37 · Личное сообщение · #21 Vamit пишет: А пустые окошки кода - это что? Или глюк скрипта, когда в окошке одна длинная строка, то она накрывается полосой прокрутки а что у тя за браузер? у мну все нормально ----- Лучше быть одиноким, но свободным © $me |
|
|
Создано: 04 марта 2010 16:02 · Личное сообщение · #22 Vamit пишет: Приложил подробное описание ВМ На сегодняшний момент несколько устарело и некоторые куски кода ошибочно отнесены к обфускации. В Фиме 2.1.1.0 это выглядит так как представлено ниже. Максимальное количество хэндлеров (в вашей терминалогии примитивов) 169 для 32-бит ВМ и 201 для 64-бит ВМ. А вообще у вас 168 примитивов из-за большого количества виртуализированого кода. В ВМ вставляются после виртуализации кода только необходимые хэндлеры и их количество прописывается в коде ВМ_Ентри. Code:
Кроме этого новым по сравнению с рассматриваемым вами является "плавающее" (определяется во время сборки ВМ) положение полей контекста (в вашей терминологии 17..19 регистров). В выше приведенном коде константы типа 7EBB0002h..7EBB0005h это идентификаторы полей контекста которые при сборке конкретной ВМ будут заменены на смещения в контексте. ----- 127.0.0.1, sweet 127.0.0.1 |
|
|
Создано: 04 марта 2010 16:51 · Личное сообщение · #23 BoRoV пишет: а что у тя за браузер? IE6 mak Можно задавать по одному - два вопроса, а то на все сразу не ответишь, а в дальнейшем просто затеряются или забудутся. Как формируется промежуточный код ? Вот ответ на этот вопрос, надеюсь полный Code:
OKOB пишет: На сегодняшний момент несколько устарело Устарело чем? Что нет программ накрытых этой ВМ, скажу так, программа 2008г - версия ВМ с 17 регистрами, таже прога следующей версии начало 2009г аналогично, следующая версия - конец 2009г - ВМ с 19 регистрами. некоторые куски кода ошибочно отнесены к обфускации Если речь идет о входе в ВМ до цикла декодирования, то да, скорее это незначимые сроки для данной реализации. А что касается цикла декодирования и примитива, то должно быть правильно, хотя, неважно, мог и ошибиться... ----- Everything is relative... |
|
|
Создано: 04 марта 2010 17:05 · Личное сообщение · #24 не затеряются , у нас и у вас большой ведь интерес! Можно вернуться и прочитать позже) Вообщем повторять не буду , лучше как будет время по порядку напишите вернувшись назад. Тем более часть вопросов у OKOB тоже описываются. Подробное описание ВМ посмотрим) За пример формирования IR кода спасибо , попробую разобраться.
----- RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube |
|
|
Создано: 04 марта 2010 18:40 · Личное сообщение · #25 Для реализации девиртуализации (и не изобретения велосипеда при этом) не плохо бы было взглянуть на процесс виртуализации, что и было сделано (http://www.woodmann.com/forum/showthread.php?p=78770&postcount=23). Файл который в прицепе поста к сожалению уже недоступен и у себя я нашел только результат работы того что было там представлено (позже может найду все). Вкратце, юзаются ДЛЛки вынутые из недр Фимы или КодеВиртуализера (Oreansf1.dll и ОreansX2dllR.dll) и исследуются все этапы виртуализации. 1) исходный код 00040129ch: PUSH EBP 00040129dh: MOV EBP, ESP 00040129fh: SUB ESP, 40 0004012a2h: PUSH ESI 0004012a3h: PUSH EDI 0004012a4h: MOV dword ptr [EBP + 0ffffffe8h], 000000000h 0004012abh: JMP 000401411h 2) код дизассемблированный ореанс feed: section .code base 0000000h code @label1: PUSH EBP MOV EBP, ESP SUB ESP, 40 PUSH ESI PUSH EDI MOV dword ptr [EBP + 0ffffffe8h], 000000000h JMP @label13 @label2: 3) промежуточный пикод 02 00 00 80 03 00 00 00 30 00 00 f0 00 00 00 00 00 00 06 00 00 00 00 00 00 00 00 00 02 00 00 80 03 00 00 00 38 00 00 f0 00 00 00 00 00 00 06 00 00 00 00 00 00 00 00 00 02 00 00 80 03 00 00 00 30 00 00 f0 00 00 01 00 00 00 06 00 00 00 00 00 00 00 00 00 02 00 00 80 03 00 00 00 38 00 00 f0 00 00 00 00 00 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 22 00 00 00 28 00 00 00 00 00 0c 00 00 00 1a 00 00 00 00 00 00 00 00 00 01 00 00 00 1e 00 00 00 00 00 00 00 00 00 02 00 00 80 03 00 00 00 38 00 00 f0 00 00 08 00 00 00 03 00 00 00 04 00 00 00 00 00 01 00 00 00 06 00 00 00 00 00 00 00 00 00 02 00 00 80 03 00 00 00 20 00 00 f0 00 00 00 00 00 00 06 00 00 00 00 00 00 00 00 00 02 00 00 80 03 00 00 00 28 00 00 f0 00 00 00 00 00 00 06 00 00 00 00 00 00 00 00 00 4) декомпилированный промежуточный пикод во мнемокод ; PUSH EBP move addr, f0000030h load dword ptr [addr] ; MOV EBP, ESP move addr, f0000038h load dword ptr [addr] move addr, f0000030h store dword ptr [addr] ; SUB ESP, 40 move addr, f0000038h load dword ptr [addr] load dword 28 sub dword store FLAGS move addr, f0000038h add addr, 00000004h store dword ptr [addr] ; PUSH ESI move addr, f0000020h load dword ptr [addr] ; PUSH EDI move addr, f0000028h load dword ptr [addr] Кстати ОreansX2dllR.dll - виртуализирует под CISC VM a ОreansX3dllR.dll - виртуализирует под RISC VM В прицепе полный файл из которого приведены фрагменты. 6b49_04.03.2010_CRACKLAB.rU.tgz - long.txt
----- 127.0.0.1, sweet 127.0.0.1 |
|
|
Создано: 04 марта 2010 20:30 · Личное сообщение · #26 OKOB пишет: Для реализации девиртуализации (и не изобретения велосипеда при этом) не плохо бы было взглянуть на процесс виртуализации Что-то мы с вами говорим об одном и том-же на разных языках, я правда, больше молчу... Да, приведенные вами примеры ВМ очень похожи на разобранную мной ВМ, даже можно сказать, что в чем-то одинаковы, только что вы хотите этим сказать я так и не понял, хотя за них спасибо. Если то, что ВМС не может их декомпилировать, дак он и не должен, поймите, я писал инструмент не под какие-то существующие типы ВМ, а под то, в чем была необходимость - и это было реализовано. Если будет необходимость, то и приведенные вами типы ВМ будут обрабатывается ВМС по реализованному алгоритму, нужно только описать разновидность ВМ. Определить же тип разобранной мной машины пока тоже никто не смог, но я больше практик, чем теоретик и поэтому могу сказать что для реализации девиртуализации совсем необязательно знать процесс виртуализации - главное понимать как выполняется код, а не как он сделан, и между прочим - это универсальный подход для реализации любых декомпиляторов. Как сделан код нужно знать лишь в том случае, если мы хотим получить после декомпилятора исходник как можно ближе к оригиналу, для декомпилятора ВМ это не нужно, асм он и Африке асм, а вот для декомпилятора С++ нужно знать как из исходника получен асм, иначе лучшего чем в НехРей нам не видать. Но это уже отступление от темы... mak пишет: Как происходит назначение регистров для формирования асм кода? К каким регистрам относится этот вопрос? К этим - - Блоки некоторых присвоений и изменений для некоторых нативных регистров - ASSIGN (REG) по специальному алгоритму? совершенно беспорядочно , нов даже тут есть порядок , определенный вектор , при смешивании или перестройки регистров , внутри вм , этот вектор не нарушается , если стэковые команды с гемором мы опознаем , то уже другии интерпретации придется прогонять через анализатор и карту распределения регистров , для декомпиляции. С регистрами не сложнее чем со стеком - обратите внимание на файлы "имя_регистра".stat в обзоре ( особенно на edx.stat). Каждый нативный регистр в конкретной точке выполнения программы в общем виде всегда имеет одно из 5 состояний: EMPTY - значение регистра не важно, UNKNOWN - значение регистра важно, но неизвестно, INIT - регистру присваивается значение, CHANGE - значение регистра изменяется, USE - значение из регистра используется. На каждой асм команде осуществляется трассировка значений всех регистров, для статического анализа вернее сказать состояний регистров, т.к. содержимое регистров мы не знаем. Фиксируем точки изменения состояний регистров, точка фиксации - адрес асм кода, если регистр в одной команде проходит через несколько состояний, то записываем их последовательно под одним адресом. Далее анализ - определение точек перезагрузок регистра в контексте конкретного логического блока кода. Уже на этом этапе - часть обфускированного кода будет устранена. Пример, показывающий это: имеем цепочку изменения состояний регистра (цифра - номер шага) 1 INIT, 2 CHANGE, 3 CHANGE, 4 INIT, 5 USE и т.д. Отсюда видно, что шаги 1-3 являются обфускацией (избыточны), а 4-5 значимы. ----- Everything is relative... |
|
|
Создано: 04 марта 2010 21:17 · Личное сообщение · #27 ага , это мне понятно , но хорошо что обьяснили повторно , я понял о чем речь , примерно тоже самое что делать регистровую деобфускацию через ССА , очень практичный метод для деморфа и деобфускации. Можно даже граф построить.Я наверное выразился не так , я особо не ковырял орианс , выше вы сказали что есть определенное число регистров , одни служебные , вторые настоящие от процессора , так вот имеется ввиду , известно ли назначение регистров заранее по офсетам и таблицам офсетов ? Или же у орианс регистры типа блэкбокс , где нет точной копии скажем регистра еах , мы вообще не можем определить где какой регистр , мы можем только по логике построить код а потом делать назначение регистров. Тут же спросил , про назначение .... судя по тому как вы описали , каждый регистр и его именной эквивалент для х86 архитектуры известен?! Правильно ? Это собственно последнее что я хотел узнать. Было бы классно уже и под риск адаптировать дллку ... Тип вм чаще всего определяют по входу в саму вм .... ----- RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube |
|
|
Создано: 05 марта 2010 09:35 · Поправил: Vamit · Личное сообщение · #28 mak пишет: известно ли назначение регистров заранее по офсетам и таблицам офсетов ? Заранее известны только регистры для нужд самой ВМ, регистры же для сохранения контекста программы (нативных регистров) неизвестны, известен только блок, в который они поместятся, а какой нативный регистр на какое место неизвестно. В каждой реализации ВМ это место своё. Но это легко вычисляется при создании промежуточного кода следующим образом: при входе в ВМ нативные регистры сохраняются в стеке, далее в логическом блоке ENTRY нативные регистры из стека перегружаются в регистры ВМ и вся дальнейшая работа до выхода из ВМ осуществляется с этими регистрами, т.е. для конкретной реализации ВМ можно выявить жесткое соответствие между нативными регистрами и регистрами ВМ. Вот раскладки регистров ВМ: Code:
часть регистров в разобранных реализациях не используется, поэтому их назначение мне неизвестно. mak пишет: Тип вм чаще всего определяют по входу в саму вм .... Понятно, но каким образом? Вопрос такого плана, подвержена ли точка входа конкретного типа ВМ и само тело ВМ (до цикла интерпретатора пикода) мутации при создании реализации ВМ? OKOB привел пару листингов тел ВМ, в посте №14 - видно что это другой тип ВМ, а вот в посте №22 - тип очень похож на разобранный, но есть небольшие нюансы, вот и хотелось бы знать, может это мутации одного типа, если так, то небольшая доработка ВМС позволит обрабатывать и эту ВМ. ЗЫ: Вопрос не по теме, но важный для меня, здесь пост №9 я спрашивал о типе упаковщика, может кто-нибудь поможет определить его тип? Могу дать наводку - функция tmainCRTStartup накрыта ВМ, т.к. процедуры _setenvp, _cinit и _WinMain вызываются из ВМ, но найти OEP мне не удалось. ----- Everything is relative... |
|
|
Создано: 05 марта 2010 10:17 · Личное сообщение · #29 Vamit пишет: может кто-нибудь поможет определить его тип? Так там тебе ответили вмпротект и версия судя по импорту не очень свежая |
|
|
Создано: 05 марта 2010 10:19 · Личное сообщение · #30 Vamit пишет: Вопрос не по теме, похоже на вм прот, ближе к стабу ничего не нашёл пока 00454150 33C0 XOR EAX,EAX ----- Чтобы юзер в нэте не делал,его всё равно жалко.. |
| . 1 . 2 . 3 . 4 . 5 . 6 . 7 . 8 . 9 . 10 ... 23 . 24 . >> |
|
eXeL@B —› Протекторы —› Декомпилятор ВМ |
Для печати