Доступ к оригинальному коду приложения защищенного любым протектором до недавнего времени выполнялся довольно просто - любой дебагер с защитой от антидебага и далее дело техники, поиск ОЕП, бряк и дамп.
Сейчас же протекторы сделали шаг вперед и вся защита от антидебага уже не действует. Конкретный пример, вмпрот версии 3.2 + x64dbg + ScillaHide дает отрицательный результат что при прямом старте, что при аттаче. Драйверный же TitanHide на Windows 10 вообще не удается установить. Пока найдено такое решение вопроса - запуск приложения, дамп его процесса, загрузка в дебаг/дизасм и реверс кода. Довольно хорошая утилитка для этого имеется, например --> Process Dump <--. Но с восстановлением импорта в ней имеются недоработки, местами ломает код самого приложения, но решение тоже имеется - делать два дампа, один с импортом для дизасма, а второй без импорта для дебагера. Всё прекрасно и всё работает, основная задача получить доступ к оригинальному коду для его исследования решена. Но есть одно но, в данном случае теряется начальная инициализация статических переменных, а их первоначальное значение важно для правильного реверса кода. Вопрос, имеются ли какие либо инструменты позволяющие запуcтить приложение и остановить его на указанном адресе?
Была тут одна интересная тема от Инде по поиску ЕП, но он её закрыл. В принципе, я думаю, эту задачу его визору решить по силам, только нужно изменить формулировку, не искать ОЕП, т.к. в общем случае её может и не быть, а довести приложение до заданного адреса.

-----
Everything is relative...

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

hash87szf пишет:
вин10х54
Инде, насколько я понимаю, использует Windows XP.
То, что Инде пишет немножечко некроссплатформенный код, накладывает некоторые ограничения, но нельзя исключать и глючности самого x32dbg.
Не на винде этот код вообще не работает, например.

P.S. речь об инструменте dye4, который разрабатывает Инде ака Клерк.

-----
EnJoy!

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

Jupiter

> чтобы ускорить, можно выкинуть лишние варианты и оставить только твою Windows XP (SP3) x86.

Я ведь так и сделал, только не скриптом. На асме это занимает пол сотни инструкций всего, на коленке" написанных за десять минут.

- инклуд если кому нужно. Сервисы индексируются, тоесть номер строки и есть сервисный номер, +0x1000 разумеется.

Довольно не удобно, что масм не может линковать бинарный дамп. Фасм етц все умеют.

324d_26.11.2018_EXELAB.rU.tgz - w2k.7z

ClockMan

> Ваша пои*ень работает на уровне ring0 или ring3

Из км такое нельзя реализовать по этой причине --> Link <--

Из за разнице в режиме, нельзя будет отследить подмену выборки, юзер код будет анклавом. Придётся впрыскивать юзер код в приложение, а тогда и км лишь надстройка и не нужен. Это не решается в кернел.

Jupiter

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

Jupiter

> Инде, насколько я понимаю, использует Windows XP.

Это не так, точнее не совсем так. Я рассматриваю от xp до 10-ки, просто у меня рабочая система 8-ка, тоесть всё тестится и там. 10 есть лишь в виде модулей. Любой механизм как всегда изучается на всей линейке. Вот например недавняя проблема(мелкая):

--> Link <--

- как всегда интерфейсы я смотрел под всю линейку.

Для отладки я использую xp. Есть и например 7-ка на варе. Потому что там я помню очень много всяких адресов и тп. В другой версии время отладки будет значительно больше.

Мне например небыло нужды выше создавать все таблицы для версий ос, если я это запускаю в конкретной.

Если у того товарища что то падает, это не означает что это не работает. Оно и должно падать, во первых точка останова(дебаг же билд), а во вторых нужно настройки защиты менять. Со всеми включёнными нельзя даже rwe область выделить, это защита зарубит - это ведь dbi тулз, активность как у эксплойтов. Тоесть нужно не просто запустить, а разобраться. А он хотел кликнуть апп(без отладчика) и не получить крэш.
А есчо XP я выбрал по причине опенсорсности, под неё есть сурки(wrk, w2k).

Добавлено спустя 43 минуты
Кстате тут при редактировании сообщений вместо ссылок появляется какой то хтмл-треш, я не нашёл почему то темы, где про это можно написать.

-----
vx

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

А есчо XP я выбрал по причине опенсорсности
Между прочим на ХП описанная мной проблема с Вмп3.2 имеет решение и даже оно будет работать на любой 32х разрядной оси, но для меня актульно решение на Вин10 х64
А на ХР исследуемые проги уже не стартуют, а скоро и х86 вариантов уже не будет...

-----
Everything is relative...

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

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

Здесь: --> Предложения по улучшению форума <--

-----
EnJoy!

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

Vamit

Ваша проблема совершенно не понятна, вы её не понимаете, иначе описали бы чётко. Как какая то версия ос может иметь решение для задачи дби, тоесть монитора апп ?

В самых новых билдах судя по всему реализован некий визор, Ionescu про это писал, у него был пример. Я это запомнил только из за мизерного размера сборки(десяток кб), видимо в самых последних билдах ос реализован подобный механизм на уровне ос. Хотелось бы глянуть, но такой возможности у меня нет.

Но даже если это так, то это как обычно не имеет обратной совместимости. И если приложение запущено под монитором, это не значит что он всё мониторит(есть события которые нельзя из иного режима отслеживать).

-----
vx

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

vmp использует микс архитектур (вызов x64 кода из x32 и наоборот). Анализ как динамический и статический очень сильно затруднен в таком случае (см. статью https://scrammed.blogspot.com/2014/10/code-obfunscation-mixing-32-and-64-bit.html). Может у кого есть идеи как анализировать такое?

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

Нет тулз таких. Только Ида скриптом. Ловить в полёте (pin) известные switch трюки или ставить на них бряки до старта и обрабатывать новый код на остановке.

Под Иду есть два (3...) плага шо делали подобное, но без dbi типа pin,
funcap и DIE

фанкэп ставил бряки на брэнчи в дисасме Иды и Ф9, на бряках анализ,
была опция d.code_discovery = Тру, шо ловила генерированный код в вставляла но только надо было сэмпл остановить до выхода, и/или делать mem snapshot в дебаг меню Иды.

DIE теперь для пиратов тож робит так как он под Ида68. У него тоже есть "new func anal", но я хз робит или нет

Короч, pin тул как дебагер в Ида - проблема детекта
По этому видать только локальный Вин дебагер в Иде, СкилаХайд, ставить бряки на трюк, рипать код из фанкэп/ДАЙ как вставить new code, Ida set_segm_attr, set_segm_addressing, ???, профит.

Жду паблик тулзы :>

edit

Если код генериться и там свич, то кроме допиливания Ида pin плага и hider'a нет альтернатив.
frida.re? Тож детект

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

difexacaw

Честно сказать, я думаю лог из поста - --> Link <-- выглядит весьма странно, может это какой-то минимальный набор, ты наверное запаковал, но без виртуализации, в таком случае не ясно, почему у тебя детектится отладчик. NtUserQueryWindow ты должен тоже обработать и посмотреть, будет ли детект, но самого главного в твоём логе нет, мне так кажется. Нужен другой тестовый пример

-----
RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube

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

mak пишет:
но самого главного в твоём логе нет
И не будет если вм прот полностью тащит сиськи под вм,
mak пишет:
в таком случае не ясно, почему у тебя детектится отладчик
скорее всего и за dbg принтора
p.s
Я уже писал в другой теме чтобы победить отладку вм прота нужно писать дровину которая будет обрабатывать системные вызовы программы, но на паблике вы их не увидите так-как вм прот чекает все загруженные дрова в память программы и один взмах пера и ваша дровина в чёрном списке

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

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

шта ? вмпрот детектит не пабедимый гпЕ ?? дерматолог в своем уме ??? может он тогда и td.exe внесет в черный список а то мало ли

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

ClockMan пишет:
mak пишет:
но самого главного в твоём логе нет
И не будет если вм прот полностью тащит сиськи под вм,
mak пишет:
в таком случае не ясно, почему у тебя детектится отладчик
скорее всего и за dbg принтора
p.s
Я уже писал в другой теме чтобы победить отладку вм прота нужно писать дровину которая будет обрабатывать системные вызовы программы, но на паблике вы их не увидите так-как вм прот чекает все загруженные дрова в память программы и один взмах пера и ваша дровина в чёрном списке

Слишком сложно, китайцы в своём декомпиле в привате обошли новую проверку за час без драйвера

-----
RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube

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

> я думаю лог из поста - --> Link <-- выглядит весьма странно

Этот линк битый. У меня это не открывается. Дайте другую ссылку.

> NtUserQueryWindow ты должен тоже обработать и посмотреть

Через этот сервис и раньше олли искали. Я ведь говорил что не смотрел подробности, более того я его пометил в логе.

> но самого главного в твоём логе нет, мне так кажется.

Чего именно ?
Утеря управления просто невозможна. Все обратные вызовы ядра пропатчены и отслеживаются c первой инструкции. С самой передачи управления из км запускается монитор. Даже если первая инструкция при передачи из км в юм вызывает фаулт(вы можите установить TF, что приведёт к трапу), то поток исполнения начинает отслеживаться. Изначальная задача и стояла отслеживать OP, те передачи управление не корректные. Можно всё адресное пространство протектить от исполнения - что бы на уровне железок исключить спонтанный выход из под монитора. Но я уверен что такое невозможно.

* почините ссылки, они глючат и портят сообщение при редактировании.

-----
vx

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

difexacaw пишет:
Чего именно ?

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

-----
RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube

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

ClockMan

> чтобы победить отладку вм прота нужно писать дровину которая будет обрабатывать системные вызовы программы

Если человек тупой или твердолобый", то уже ничего не поможет, имхо. Сказано ведь чётко - изоляция данных в ином режиме. VMP варится в юм. Какие нафиг драйвера.)

Добавлено спустя 9 минут
mak

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

Добавлено спустя 14 минут
mak

> в оригинале порядок вызова функций защиты выглядит иначе, может и есть другие варианты, но я не встречал других логов, а в твоём логе слишком всё просто

А что это значит ?

Монитор выводит то что есть, утеря данных невозможна(была включена обработка гуя).

И что за оригинал", я простое апп обработал, тем что вы дали. Вероятно это у вас ошибки, фейлят ваши инструменты. Для калибровки я могу ваше любое апп запустить и дать вам лог.

-----
vx

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

Хотя бы того, что в оригинале порядок вызова функций защиты выглядит иначе
Ещё наличие определенных функций и порядок их вызова зависит от операционки под которой запущено приложение, вмпрот их все анализирует.

-----
Everything is relative...

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

difexacaw Можно на Ты, я не такой старый

difexacaw пишет:
Я запустил то что ВЫ предоставили.
Так это сам протектор, нужно было пример самостоятельно смастерить, а потом запротектить. x64 приложения твой двиг сможет просмотреть? Или хотябы х86 но на Win 10?!

difexacaw пишет:
А что это значит ?
Это значит, что антидебаг вызывается под вмкой в определённом порядке, которого в твоём логе нет, как и функций антидебага базовых, в "оригинале" означало в стандартном виде функций антидебага. Отсюда вопрос, как ты хочешь найти новый антидебаг трюк, если у тебя голый пример П.С. могу на Вы к тебе, мне не сложно.

-----
RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube

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

mak

Не знаю о чём вы говорите, он же палит отладчик, сообщение выводит. Я хотел посмотреть на днях лог по апи, что бы сервисы не перебирать, так проще.

> Или хотябы х86 но на Win 10?!

Теоретически да. Точнее нет причин что бы он не работал в 10-ке, за исключением защиты(rfg/cfg/etc) - разумеется это нужно выключить. А есчо это не тестилось в 10-ке, тк её не имеется в наличии. Если вы захотите потестить на 10-ке, то мне это тоже нужно. Даже если не заводится то ошибку просто найти по стартап логу, тк это всё нэйтивное.

-----
vx

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

Почему бы не взять Вин10, отключить на ней patchguard и проверку подписей, скомпилить под неё тулы для сокрытия дебаггера (которые, как я понял, на хр работают) и радоваться?

-----
Stuck to the plan, always think that we would stand up, never ran.

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

ARCHANGEL

А какие тулы" ?
Был лишь один, сайд, в нём участвовал ваш модер, которого вы выгнали. Но это ядерное и старое, оно не совместимо с 10-кой.

Штатный dbi это набор костылей", им только хеловорды анализить, оно всё не рабочее. Не говоря уже про запуск протекторов в их среде.

Один лишь есть вариант, это мой тулз завести или портировать на 64, в принципе оно весьма малое, так что времени много не займёт.

А есчо как вариант можно просто допилить олли/плагины. Но это очень плохой способ.

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

-----
vx

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

А есчо как вариант можно просто допилить олли/плагины.
Первая Олька на Вин10 не работает, а вторая глючит с протекторами, я это описывал в теме декомпилятора вм.
Поэтому и перешел с олек на x32/64dbg, они на Вин10 работают нормально.

-----
Everything is relative...

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

mak

> Речь не о твоём двиге, а о примере который ты выбрал для тестов.

Я использовал dbgview от sysinternals. Это минимальное гуй апп. Выбрал по простой причине - оно может выводить дебаг принты. А есчо я хотел посмотреть произойдёт ли деадлок при отладочном выводе, что произойдёт. Но он почему то дебаг принты не выводит, я не разбирался пока.

Добавлено спустя 4 минуты
Vamit

> Первая Олька на Вин10 не работает

Почему не работает ?

-----
vx

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

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

-----
Everything is relative...

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

Vamit
Всё публиковать не стоит, только по защите, но я в в теме свипера уже писал про антиотладку,ну можете просто ради рекламы свипера выложить листин если вам так нужно....

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

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

Эх, оно-то, конечно, интересно. Однако чтобы там что-то разбирать, нужна подготовка. А её нет.

-----
Stuck to the plan, always think that we would stand up, never ran.

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

Однако чтобы там что-то разбирать, нужна подготовка.
Прибедняешься, не верю что у тебя нет подготовки для разбора чистого кода на асме.

Всё публиковать не стоит, только по защите, но я в в теме свипера уже писал про антиотладку
То что ты писал - это частично и сидит оно далеко и глубоко, после микст кода, и это далеко ещё не всё, а разбирать код в середине вм не зная ни истинных регистров, ни инструкций способны только мозахисты. Это как пальцем в небо попал, не попал...
И листинг это мягко сказано, чистый код первой функи на ЕП содержит около 2500 асм инструкций и из неё вызывается порядка 40 функций, а сколько ещё из них пока неизвестно.

-----
Everything is relative...

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

Vamit
Ну ок, какой план? Что будет конечной целью разбора?

-----
Stuck to the plan, always think that we would stand up, never ran.

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

Что будет конечной целью разбора?
Я думаю ответ понятен, обход защиты вмпрота, а каким образом и что обходить выяснится в процессе разбора.

-----
Everything is relative...

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

Оказывается для pin микc архитектур не проблема:
pin [pin-option]... -t64 <64-bit toolname> -t <32-bit toolname> [tool-options]...

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

gggeorggge

Покажи как под пином работает вмп.

-----
vx

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

difexacaw пишет:
Покажи как под пином работает вмп.
Да пожалуйста. Фрагмент трасировки vmp до переключения в x64.--> Link <--

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