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

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

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

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

-----
Everything is relative...

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

Vamit пишет:
С 3ей версии прота много что изменилось
ну был косяк в скиле, на дебаг флагах ловили, так что скила с перепугу пид дебагера сливал, ну так пофиксили.
а так чтобы там что серьёзное пока не встречал. демку гавнопрота х64 запускал.

-----
Чтобы юзер в нэте не делал,его всё равно жалко..

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

Прошла неделя разборок с OllyDbg 2.01 на Вин10, можно подвести итоги (всё в сравнении с Олькой 1 на ВинХР):
1. Разработка плагинов
Практически все АПИ функции изменены, документация имеется только на 1/4 часть всех фунок, остальное - догадайся сам. Но это не беда, если писал плаги для первой Ольки, если же нет, то тут делать нечего.
Многие нужные АПИ функции вообще отсутствуют - нет вызова функций из её меню, но можно извратиться и через оконное SendMessage вызвать то что имеет shortcut, а все остальное недоступно. Управление анализом из плагов недоступно. Callback функции записи/чтения в udd файл имеются, но они не вызываются. Функа PluginMaimLoop реагирует только на события отладки, а раньше она реагировала на любое событие, позволяла Ольке перерисовку своего окна и возврат управления в плагин. Сейчас всё что делает плагин производится втихую, за исключением сообщений в окно статуса - оно работает так же как и раньше. С созданием своих окон не разбирался, там все так изменено - что можно понять только методом тыка и многочисленных проб.
Все строки теперь полностью на юникоде, даже весь asm, но это не беда, только быстродействие падает за счет перекодировок. Поддержкой асма х64 и не пахнет.
В общем Свипер я перенес, даже втихую он декомпилит нормально.
2. Отладка защищенных программ.
А вот здесь полная Управление ASLR при загрузке отсутствует, приходится править бит в хидере реального файла, грузить его в Ольку и затем у же в ней изменять его руками обратно - иначе вмпрот это ловит. Модули защищенного файла "слипаются" в один, что исключает анализ секций файла из плагинов, но удалось найти плаг, который правит это дело. Но основная беда в другом, отсутствует основной исполняемый код проги после того как отработал распаковщик вмпрота. Бряки на пустом месте не работают. В результате имеем запущенный образ проги в системе, но вне Ольки. При закрытии её окна этот тред не убивается, можно грохнуть его только системным диспетчером.
Итого: Как ни прискорбно, а данный инструмент можно отправить в помойку и забыть что он есть. А жаль, первая Олька была хорошим помощником.

-----
Everything is relative...

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

Vamit

А можите показать семпл, простое приложение накрытое. Только 32-х у меня на варе.

-----
vx

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

difexacaw
--> Link <--

Отладчик - данная опция препятствует отладке защищенного файла. Существуют 2 типа отладчиков: User-mode (отладчики пользовательского режима: OllyDBG, WinDBG и т.п.) и Kernel-mode (отладчики режима ядра: SoftICE, Syser и т.п.). Обнаружение отладчика происходит до передачи управления оригинальной точке входа в программу. В случае обнаружения отладчика будет показано соответствующее сообщение с прекращением дальнейшего выполнения программы.

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

difexacaw пишет:
Только 32-х у меня на варе.
А при чем тут это, на 32 разрядной системе и первой Ольки достаточно, нефиг туда вторую совать. А исследуемая прога 32 разрядная и первая Олька на ВинХР с ней справляется без проблем, хоть в варе, хоть без))
Интерес представляет только работа дебагеров с защищенными протами прогами на 64 разрядной Вин10.
Хотите знать причину? Пожалуйста - Свипер приходится постоянно развивать и доработывать (с отладкой разумеется) и всё это на ХР, а все ВизуалСтудии после 10 там уже не работают, а делать всё это на старье уже тошнит...
Если интересно покопаться, то пример дали выше.

Gideon Vi пишет:
Обнаружение отладчика происходит до передачи управления оригинальной точке входа в программу.
Ну и что, дело не в этом - Ольку 2 вмпрот не видит, Сцилла норм работает.

-----
Everything is relative...

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

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

-----
Чтобы юзер в нэте не делал,его всё равно жалко..

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

Gideon Vi

Спасибо!

Vamit

> А при чем тут это, на 32 разрядной системе и первой Ольки достаточно

Запустить под локал супервизором хочу, что бы трекнуть всю апликуху. Посмотреть что получится.

Пока не получается, валится тут. У меня на битовых инструкциях реализован коммандный интерфейс(с номером бита >32), так как предполагалось что такие инструкции не юзаются, оказывается юзаются

fe3d_14.02.2017_EXELAB.rU.tgz - fail.png

-----
vx

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

difexacaw пишет:
так как предполагалось что такие инструкции не юзаются
У вмпрота всё юзается, даже невалидные инструкции - а предугадать это при эмуляции не представляется возможным. Отсев всего этого дерьма возможен только по перезаписи результата, тогда вся эта гадость хакается пачками.

-----
Everything is relative...

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

Vamit

Запустилось под супервизором https://yadi.sk/i/7CGEjCZB3E5sH6

Там в лог выводятся сервисы и стоят ловушки на rdtsc, cupid. Получается что при запуске тайминг напрямую не снимается и немного сервисов для детекта отладчика юзается. Хотя может это всё после детекта отладчика происходит далее, это я есчо не смотрел.

-----
vx

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

difexacaw пишет:
Хотя может это всё после детекта отладчика происходит далее, это я есчо не смотрел.
Я уже устал говорить, что прот не детектит дебагер со Сциллой. Если код проги не поломан, то все эти rdtsc, cupid пошли нафиг, на них организована проверка целостности кода и антидампинг.

-----
Everything is relative...

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

зря так сурово, супервизор тема интересная, доков правда мало по самим обработчикам, но комплект событий для vm_exit довольно солидный.
difexacaw, на каком событии можно взять под контроль распаковку образа, и передачу управления на этот код ?

-----
Чтобы юзер в нэте не делал,его всё равно жалко..

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

Bronco

Выборка данных/исполнение из не тронутых ранее блоков ?
А если распаковка происходит частично, тогда окончание распаковки как таковое не будет существовать.

Vamit

> Если код проги не поломан, то все эти rdtsc, cupid пошли нафиг

Как же так
Если к примеру rdtsc можно забанить настройкой железа(мср), то cpuid так не получится трекнуть. Вообще то эта инструкция фактически сигнатура, а для детекта их нужно покрыть всё приложение целиком, каждую его инструкцию. Иначе нельзя никак обнаружить к примеру ту же cpuid или появление в памяти в произвольный момент какой то строки.

-----
vx

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

difexacaw пишет:
то cpuid так не получится трекнуть
Я говорю не про детект, а про использование их протом, посмотри начало листинга на предыдущей странице, пост #12, там понятно как он юзается.

-----
Everything is relative...

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

Vamit пишет:
Ну и что, дело не в этом - Ольку 2 вмпрот не видит, Сцилла норм работает.

это описание из официально хелпа для выложенного мною архива. Типа, почему файлы так называются и в чем различие.

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

difexacaw пишет:
А если распаковка происходит частично,
хз..может в связке с сенселоком такое и есть, но данных за пределами образа, гавнопрот вроде не держит.
Понятно что распаковка частями, по разделам образа. не помню инит иат до или после секции кода
Но атрибуты Executable, не у всех же разделов. Тут вроде бы задача до этого кода комфортно добраться.

-----
Чтобы юзер в нэте не делал,его всё равно жалко..

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

Vamit

#13 - не понятно. Вас спрашивали там ниже про DEADC0DE. Когда вызывается NtClose возникает исключение под отладчиком. Не долго после этого события вызывается конструкция: popfd/rdtsc/nop/..., причём на стеке TF. Затем через сех управление передаётся прямо на апи аллокатора. Это так и должно быть ?

Bronco

> Тут вроде бы задача до этого кода комфортно добраться.

Нужно полный стартап лог снять и посмотреть что там и как юзается. У меня пока слетает на событии выше.

-----
vx

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

difexacaw пишет:
У меня пока слетает на событии выше.
ок...мы с тобой разные сабжи ...ой....семплы...смотрим, но суть везде пока одна..))
с первой тлц, не прерываясь на еп загрузчика, с хайдами сцилы полёт семпла под дебагерами, проходит "....бЭз щуму пыли и гаму.."
Что дальше пока не вникал, занят другими качелями..

-----
Чтобы юзер в нэте не делал,его всё равно жалко..

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

Bronco

Антидебаг я прошёл, если его конечно есчо нет после окна с детектом вари. А как детект вари обойти, я обнаружил что вызывается cpuid и за ней выдаётся окно с детектом(в аттаче первый cpuid). Я вернул значения в регистрах, взятые из под реал системы(x64), прошла есчо серия вызовов rdtsc и cpuid в виде popfd/cpuid/nop.. Так понимаю это нужно фиксить. Этот евент только отладчиком обнаружить не просто

7014_15.02.2017_EXELAB.rU.tgz - cpuid.png

-----
vx

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

Gideon Vi пишет: это описание из официально хелпа для выложенного мною архива
Извини, не так понял
Bronco пишет: но данных за пределами образа, гавнопрот вроде не держит
Точно там ничего нет.
Bronco пишет: не помню инит иат до или после секции кода
Раньше был после, счас наверно так же.
difexacaw пишет: #13 - не понятно
В 13 нет ничего интересного. А 12 вы не поняли, это код реальной виртуализованной функи, исключений тут нет. Этот код норм работает на образе распакованном протом с его секциями в памяти. Если же сделаете дамп и попробуете его запустить, то получите DEADCODE.
difexacaw пишет: Затем через сех управление передаётся прямо на апи аллокатора. Это так и должно быть ?
Это к проту отношения не имеет, реальный сех, куда программер скажет туда он и пойдет))
difexacaw пишет: Нужно полный стартап лог снять и посмотреть что там и как юзается
Это совсем не просто сделать. Пытался Свипером декомпилить стратап код прота, падает где-то в конце на распознавании соответствия регистров + имеется пара десятков недевиртуализованных инструкций. Но Свипер его декомпилит около 2х часов. Статистика: 50тыс инструкций по промкоду, это около 1млн чистых значимых инструкций или около 5млн. с мусором. 375 разновидностей обработчиков примитивов. Поправишь пару строк в Свипере и ждешь 2часа чтоб проверить как сработало. Можно конечно и руками восстановить регистры и недевиртуализованные инструкции, но это дня 3 работы, не меньше...
Bronco пишет: Что дальше пока не вникал, занят другими качелями
Тут всё довольно просто. Есть 2 варианта размещения прота:
1. Оригинальная прога не юзает TLS. Стартап прота сидит на ЕП, а в TLS прот проверяет антидебаг.
2. Прога юзает TLS. Стартап прота располагается в TLS выше, там же и его антидебаг, что на ЕП в таком случае не интересовался, т.к. тут ни ЕП ни ОЕП не нужны, достаточно ставить бряк на 2ой TLS и вуаля - весь код распакованного имиджа у нас в кармане)
difexacaw пишет: А как детект вари обойти
А вот с этим на виртуалке с ХП проблема, антиантидебаг его не правит, и решений толковых для HyperV я так и не смог найти - это одна из причин перехода на Вин10 с виртуалки.

-----
Everything is relative...

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

Gideon Vi
акелпад накрыт демкой?

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

Vamit

> Если же сделаете дамп и попробуете его запустить, то получите DEADCODE.

Да нет, после огромного цикла как раз перед выводом окна с детектом вари выполняется дебаг проверка через закрытие этого описателя.

> Это к проту отношения не имеет, реальный сех, куда программер скажет туда он и пойдет))

Там множество таких генераций, если скипнуть происходит детект отладчика.

> около 1млн чистых значимых инструкций или около 5млн. с мусором.

Этот семпл выполняет огромное число итераций, которые занимают много времени, между ними не юзаются сиссервисы етц. У меня супервизор может обрабатывать по одной инструкции или пакетами. При пакетной обработке(что то типо железячной трассировки ветвлений) до вывода окна с детектом выполняется 189M пакетов(линейных блоков), что есть овер дохрена.

> с этим на виртуалке с ХП проблема

Оно юзает небольшое количество сервисов, можно посмотреть подробно их все, скорее всего детект через rdtsc/cpuid.

Посмотрел сейчас, VMXh-бэкдор не вызывается(нет инструкций in eax,dx).

-----
vx

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

r99 пишет:
акелпад накрыт демкой?

retail ultimate v3.0.9 build 695

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

Ещё заметил такую фигню, Свипер на Вин10 с Олькой 2 и на ВинХР с Олькой 1 декомпилят стартап код прота по разному. Нв вин10 доходит почти до конца, а на хп выдает сообщение где-то в начале о неправильном условном переходе. В чем причина пока не пойму, декомп полностью в статике, ни одна инструкция кода не выполняется, остановы системные на TLS. Правда свипер реально читает данные из модулей проги, мож релоки как-то влияют, хотя база загрузки одинакова...
-----------------------------------------------------
Починил, моя ошибка, но странно присутствовала в обоих Свиперах, но один работал, а второй нет.
Вот вам и новые системы, у меня аж глаза вылезли, один и тот же код Свипер на вин10 декомпилит 2часа, а на ХП под виртуалкой того же вин10 за 5 минут. И результаты выдает одинаковые... Чудеса.

-----
Everything is relative...

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

.Vamit пишет:
на вин10 декомпилит 2часа
хз...может из-за конверта в юникод и обратно.

-----
Чтобы юзер в нэте не делал,его всё равно жалко..

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

Bronco, тут только профайлер сурс кода свипера может подсказать, я так думаю.
Конверт буфера в юникод там моментальный практически, если он средствами winapi, даже если их тонной вызывать, единственный косяк конверта - в обратную сторону из юникода, некоторые символы могут быть просто не "переводимы", хотя если буфер динамически выделяется, то тут следить за указателями надо, действительно может быть утечка.
Vamit, может стоит пробежаться, например, статическим анализатором PVS-Studio (кхм кхм кейген на паблике)?

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

Bronco пишет:
может из-за конверта в юникод и обратно.
очень сомнительно, ну до 20% быстродействия может сожрать, в Ольке 2 весь асм на юникоде, но не в 20!!!! же раз. Код Свипера полностью идентичен.
У меня есть подозрение не на Свипер, а на саму Ольку2, мож она там не дает ему работать или на Вин10 - много записей текстовых строк в лог файлы, общий их объем до 100Мег доходит. Причем запись расшаренная со множенством flush в интересных местах, т.к. обработка исключений у меня не реализована и при падении инфу для исправления черпаю из логов, вот и должны они быть полными.
Да, ещё, я в обоих случаях запускал дебаг версию Свипера под отладчиками VS15 на вин10 и VS10 на ХП, может и это влияет, но не в 20 же раз.

-----
Everything is relative...

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

2.0 Олли не юзайте. Это не отладчик, а какое то недоразумение. Он сам ставит точки останова куда захочет, причём скрытым образом - сам их не отображает, но при прямом чтение иногда(от фазы луны зависит) читается из памяти CC, которой там и быть не должно. 2.1 с этим стабильно вроде.

Профайл с семплом весьма странный. Расчётное время выполнения в десятки раз меньше, чем реальное. Почему так не ясно(без отладчика тоже), возможно какие то затыки в памяти, так как коду не известна оптимизация, а циклы огромны. Так как прямой ошибки не возникает. Есчо возможно что число итераций зависит от изначально измеренного тайминга.

-----
vx

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

difexacaw пишет:
2.1 с этим стабильно вроде.
Дак офицально ток есть OllyDbg 2.01, есть ещё от SND 2.3, но эта вообще со Сциллой не работает, а что это за 2.1 версия?

-----
Everything is relative...

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

Vamit

2.00 анстаб. 2.01 хоть точки останова сам не ставит. Сциллу не знаю зачем вообще юзать, там антидебаг примитивен - несколько сервисов юзаются.

-----
vx

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

difexacaw пишет:
Сциллу не знаю зачем вообще юзать, там антидебаг примитивен
да это всё не важно, сцилка время экономит, и часто даже и не вникаешь, что там злодеи при свечах намутили
у тебе же визор пока детектит, а надо чтобы перекрывал. да и дров не многие решаться тыкать, если есть плаг для юзермода.

-----
Чтобы юзер в нэте не делал,его всё равно жалко..

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