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

Не всё гладко обстоит с определением реализаций ВМ, на сегодняшний день примерно каждая третья реализация автоматом не определяется, приходится под неё модернизировать плагин, т.к. не могу сразу предусмотреть все случаи "издевательств" ВМ с кодом примитивов. Лучше дела с восстановлением "исходного" кода защищенных функций - 70% нормально восстанавливается, хотя во многом это зависит от самой структуры функции. Таким образом, если будет заинтересованность и помощь в нахождении подобных ситуаций, то проект может быть доведен до релизной стадии.

ЗЫ: Речь идет об Ореановских машинах. Нигде специально не упоминал.

9c41_03.03.2010_CRACKLAB.rU.tgz - VMSweeperLst.rar

-----
Everything is relative...

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

Может лучше в личку или Аську, чтоб здесь тему не засорять?

Сообщение последнее в строке статуса какое?
Еще-бы знать, где это находится? Или имелся ввиду Олли-дебагер?
Та строка с процентом выполнения погасла, я как-бы просто в Олли нахожусь. На переходнике "push-jmp" в следующую ВМ.

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

Kuzya69 пишет:
Может лучше в личку или Аську, чтоб здесь тему не засорять?

Материалов по практике применения декомпилятора VM очень мало. До многого приходится доходить самому. Поэтому такая открытая переписка может оказаться полезной для всех, кто работает с декомпилятором, и которая показывает, на какие грабли не нужно наступать.

| Сообщение посчитали полезным: plutos, VodoleY, BAHEK, obfuskator

vnekrilov
Если кому-то, что-то непонятно по Свиперу и Вмпроту, то спрашивайте - отвечу.

-----
Everything is relative...

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

Статья Protect&Sweeper содержит основные материалы этой темы по алгоритмам защиты ВмПротекта и методам их устранения Свипером с добавлением эксклюзивного нигде ранее не опубликованного материала.
Будет полезна всем, имеющим дело с декомпилятором и протектором.

-----
Everything is relative...

| Сообщение посчитали полезным: Veliant, schokk_m4ks1k, SReg, daFix, Hugo Chaves, tihiy_grom, Gideon Vi, antipod, -Sanchez-, m0bscene, obfuskator, stas_02, zeppe1in, NikolayD, sivorog, bitgame, Jupiter, BoRoV, MattRoss

Vamit
статья полезная спору нет, только твоя статья вышла 25 марта 2010, за два года с лишним уже произошли изменения в вмпроте! или нету разницы в сроке давности статьи? если я в чем то не прав, поправь меня)

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

schokk_m4ks1k
Конечно не прав, статья вышла сегодня, а к тем пунктам которые изменились в ней имеются Примечания.

-----
Everything is relative...

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

Vamit

Прекрасная работа. Мне очень понравилась. Удачи тебе.

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

Vamit Как всегда респект

-----
Наша работа во тьме, Мы делаем, что умеем. Мы отдаем, что имеем, Наша работа во тьме....

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

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

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

schokk_m4ks1k
Для тех, кто не понял, даты в статье - это хронология постов из этой темы форума.

-----
Everything is relative...

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

А что означает ошибка:
"Decompiled code is too long " ?

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

Kuzya69
Восстановленный Свипером асм код имеет два адреса - начальный (адрес начала декомпиляции, на котором нажали F1) и конечный (адрес конца восстановленного кода). Если последний адрес по каким либо причинам Свипер вычислить не смог и он равен нулю, то и будет выдано это сообщение.

-----
Everything is relative...

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

А не предусмотрено, принудительно задать конечный адрес?

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

Vamit пишет:
то спрашивайте - отвечу
может проще зациклить тех кто часто спрашивает друг на друга в одну группу с единой задачей
в отдельном топике

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

Kuzya69
Нет, этот адрес Свипер вычисляет сам, если не смог, значит есть какие-то ошибки, и принудительность здесь не поможет.

r99
Не думаю...

-----
Everything is relative...

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

Я встречал, когда адрес выхода из call не совпадал и свипер вешался.

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

Все оказалось до банальности просто. Надо быть вниманетельней. Правильно выбирать точку входа и границы областей. У меня свипер даже подменный код сам внедрил в программу. И этот код заработал.
Я восхищаюсь вашим творением, мастер!
Остался правда вопрос, почему подменный код, размером меньше украденного? В одном месте раза в два различие. Это что, чудеса деобсфускации?

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

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

-----
Everything is relative...

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

Ну да, функи мелкие, просто интересовало:
"А не пропустил, ли свипер чего?"


Извините, если вопрос покажется глупым.
А можно декомпиллятор использовать в полуавтоматическом режиме, при помощи вызова из скрипта?
Интересует, можно-ли его вызвать из скрипта?
И если да, то есть-ли какие возвращаемые значения у этого плагина, чтоб их в последствии использовать в скрипте?

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

Kuzya69
Из скрипта вызвать нельзя

-----
Everything is relative...

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

Уважаемый Vamit а можно как-то решить проблему с длиной инструкции вызова импорта? Прошу извинить если уже поднимался вопрос.
до плагина
E8 8D224100 CALL 00863F3B
после плагина
FF15 5C165300 CALL DWORD PTR DS:[53165C] ; user32.DispatchMessageW

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

neprovad
Ну и что здесь неправильно? Импортируемые функции вызываются через IAT.

-----
Everything is relative...

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

Vamit
Инструкция, измененная плагином, длинней предыдущей из-за чего следующая инструкция после CALL искажается на один байт. Хотя, по идее, можно было бы менять в последовательности CALL->JMP API сам JMP API вместо CALL. Сама ситуация меня не напрягает просто чем не идея для последующей доработки плагина?

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

искажается на один байт
этот байт как правило не нужен

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

neprovad пишет:
Хотя, по идее, можно было бы менять в последовательности CALL->JMP API сам JMP API вместо CALL.
Цитата из фильма "Иван Васильевичь меняет проффесию"
Когда вы говорите Иван Васильевичь в печатление такое что вы бредите!
Что FF15 5C165300 CALL DWORD PTR DS:[53165C] или FF25 5C165300 JMP DWORD PTR DS:[53165C] длина комманд одинаковая, или вы хотите может чтоб сразу было JMP user32.DispatchMessageW

-----
Чтобы правильно задать вопрос, нужно знать большую часть ответа. Р.Шекли.

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

Вообще, сдаётся мне, он имеет в виду, что не менять call, а заставить его указывать на jmp [], который указывает на импорт и который уже и менять. И тогда проблем с длиной не будет. Чем его 1 перезаписанный байт не устраивает, я хз. Возможно, тем, что иногда лишний байт после колла, а иногда ДО, и не всегда ситуация распознаётся корректно. Впрочем, с предложенным вариантом, чтобы call указывал на jmp [], тоже не всё гладко. Иногда лишний байт перед коллом-это push reg32, который надо снимать со стека.

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

А когда после CALL DispatchMessage идет вполне осмысленный переход?



то появление POP ES на месте JMP не совсем то чего ждешь.
[quote ]Когда вы говорите Иван Васильевичь в печатление такое что вы бредите![/quote]
Единственное что я хочу чтобы плагин не вносил искажений в код. Вручную я уже все исправил но все же это немного утомляет.

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

neprovad пишет:
чтобы плагин не вносил искажений в код
реальный пример с указанием места ошибки - автору плагина

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

Any update?

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

NeverMore

--> Last one Beta2 <--

-----
...или ты работаешь хорошо, или ты работаешь много...

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