Тема про DBI. Эти инструменты не используют или про них не говорят. Тему я создал по двум причинам - утверждения что локальные визоры годные инструменты --> Link <-- и есчо я потиху собираю крэкми --> Link <--, разумеется такое не пройдёшь трассировкой и через эти визоры.

Хвалёные всеми визоры, кучи их pin, dynamorio etc. Пин это вообще говно, с него жыр потёк, я для теста взял этот --> Link <-- DIO.

Штатный тест на пачке протекторов:

UPX отвалилось.
ASPACK тоже.
OBSIDIUM вываливается с ошибкой сам визор, олли как jit отваливатеся тоже.
PELOCK крэш.
SAFEENGINE крэш.
THEMIDA и есчо два подобных протектора запущены одновременно, jit и при завершении jit отвалились все.
NICE/MPRESS вываливается с jit.

На этом достаточно, не рабочий тулз. Зато копирайты VMWARE & MS

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

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

Для примера в аттаче простейший код, который не сможет пройти ни один из локальных визоров(DBI).

А не получится это сделать из общих, давно известных принципов --> Link <--

Напомню кратко если кто не знает суть. Приёмник и источник данных связаны механизмом, это выборка данных; если её нет, это эмуляция. Атом - источник данных, для которого нет их выборки, это обьект в вирт машине. Анклав - мод механизма выборки; если выборки нет, то данные не доступны(для вм) и любой попытке доступа.

Для меня важно не дать закрутить будущий семпл автоматикой. Сейчас крэкми уже решаются в пару кликов мышем --> Link <--

-
Интересно рассмотреть такую идею.

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

f315_23.09.2019_EXELAB.rU.tgz - AVI.7z

-----
vx

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

Тема годная, если не скатится в непредсказуемый оффтоп (как 90% тем Инде) будет хорошо.
Также можно сразу скипануть обсуждение детекта DBI, ибо это достаточно просто, но мы потеряем нить беседы

Про пин согласен, рио стабильнее, но тоже часто валится от банальных вещей, что впрочем не мешает использовать его алго частично, дергая нужное из сырков. Как доп источники можно поюзать сырки VBox и ReactOS и в целом задача выполнимая в рамках получения "разумных результатов".

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

VOLKOFF пишет:
но мы потеряем нить беседы

VOLKOFF, я предлагаю вести две паралельные нити. В одной Инди будет твердить, что DBI - это дерьмо, а в другой все остальные будут обсуждать их достоинства и недостатки. Тут самое главное не дать Инди сбить нас с толку и с нити.

Инди - руки прочь от DBI !!!

От себя вношу свою одну копейку.
Я тут немного с SDE поэкспереметировал, мне у него детальность и подробность лога трассировки понравилась. Гораздо подробнее, чем у PIN'а внутри ИДЫ, но размер лога, конечно, впечатляет с 1 Мб ехе-файла --> 14 Gb размер лога!!!

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

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

-----
Give me a HANDLE and I will move the Earth.

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

difexacaw
1. AVI.asm (упражнение с локальными адресами, рабочим набором и стеком) в твоей реализации существует под 64 бит?
2. В какой момент спотыкаются те визоры (DBI), которые ты тестировал?
3. Не помешало бы более-менее подробное описание собственно тестирования, чтобы не нужно было гадать, где конкретно падают те или иные инструменты.
4. Если выкинуть работу с рабочим набором (ZwQueryInformationProcess с ProcessWorkingSetWatch), будет ли тот же эффект?
6. Если DBI реализует свои вызовы к функциям типа ZwQueryInformationProcess, реализует поддержку управления информацией о рабочих наборах, то за исключением требований к ресурсам (памяти), цель мне кажется вполне достижимой.
7. Тут скорее вопрос, чего не хватает текущим реализациям DBI, чтобы справляться с таким кодом (AVI.asm). Исходя из того, что ты утверждаешь, могу предположить, что этим DBI не хватает, как минимум:
- работы с замороченным стеком (в твоём примере - участок L0 - L3)
- поддержки полноценной эмуляции информации о процессе, включая рабочие наборы (в частности, используемый тобой ProcessWorkingSetWatch)
- оптимизации используемых ресурсов (хранение только нужной для данного сэмпла инфы)
- настройки ограничений использования ресурсов (как в данном случае: фокусировка на стеке и рабочих наборах)

sty
VOLKOFF
Постарайтесь без дальнейшего флуда и обсуждения личности инде, господа. Тему в оффтопе, где можно порезвиться, сами знаете.

-----
EnJoy!

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

Jupiter

Это просто тестовый пример. Смысл в том, что визоры скрывают выборку, в данном случае её фиксирует система как монитор наборка. Если выборка пройдёт через механизм ловушек, то её отфильтрует любой визор. Так адрес исключения всегда корректируется на исходные адреса(eg фаулт в буфере -> faultIp + дельта баз буфера и текущего кода).

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

Вопрос в том, как на этом реализовать защиту, анклав к примеру, те полноценное решение, а не одноразовое как этот пример

> твоей реализации существует под 64 бит?

Я написал только на 86, в 64 разница в названии регистров

> В какой момент спотыкаются те визоры (DBI), которые ты тестировал?

Нет смысла тестировать, всё прозрачно, известно как они устроены и что получится. Дио возвращает 40102F, так как нет адреса в наборе. На пине тоже самое. Аналогично получится и на дий. Пин и дио могут загружать код блоками в буфера, если его выполнить в буфере, то адрес найден не будет(он фиксирован).

> Тут скорее вопрос, чего не хватает текущим реализациям DBI

Они сделаны по типу POC, вроде бы написано и отлажено, вот только на реальных семплах оно не работает. Толщина приводит к анстабу.

Слева dio, справа pin, dye и семпл.



- видно что дио и дий выполнили в буфере, пин разбил блок.

-----
vx

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

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

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

Потому что оно исключительно для линей.

-----
vx

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

difexacaw пишет:
Потому что оно исключительно для линей.

Known Issues
Windows 64-bit mode is not yet supported
Linux rewriter mode for 32-bit, statically linked binaries does not support binaries with .plt, .rel, or .rela sections.

Значит, исходя из логики, Windows 32-bit mode - поддерживается, да и с Linux, вроде как, не совсем все гладко.
Видимо, поэтому и уступает в популярности ПИН и РИО.

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

есть еще вот такое --> Link <--
статья на хабре --> Link <--
презентация --> Link <--
но надо время, разбираться, где и как это можно заюзать.

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

dma

В его сурках отсутствует нт обработка. А это основная часть, толку с одного только дизасма никакого.

-----
vx

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

Я немного потестил. Если тот семпл с антидебаг крутить SDE, то пин его успешно проходит при выключенных 3-х проверках. Первая это fpu.lastip, возвращается текущее положение в буфере пина. Я не смотрел подробно, но скорее всего в буфер выгружаются на исполнение большие блоки кода, поэтому пин не фиксит адрес, так как он не видит инструкцию из за блоков. Вторая проверка это впрыснутые образы пин, они обнаруживаются при проверке памяти. Третья проверка это тайминг, запуск больше лимита по времени. В общем если такой антидебаг дикий для отладчика, то для визоров он бесполезен(не хватает извратов с исключениями и самопроверок, собственно почему на протекторах и не работает), если конечно ровно реализованы.

С набором пока идея следующая.
Выборка связывает источники данных, она получается как лог WS(тоесть это проверка целостности выборки). Это давно описано как частный способ, но можно видимо реализовать как общий для произвольного кода. Принцип то же что и при обнаружении ориентированных атак(DUI" --> Link <--). Там кстате трассу тоже пином снимали и ссылка ведёт сюда --> Link <--

Для WS три механизма: снятие текущего набора, снятие лога добавленных страниц и лог записи. Адреса инструкций возвращает только второй механизм, но в зависимости от версии ос ограничение. На XP доступна ядерная выборка, на 7-ке только юзермод(при записи почему то и ядерные, наверно какой то баг). Выше врядле км доступно, так как это inform.disclosure в ядре. Третий механизм решает проблему со сбросом набора(что бы убрать область из WS), это происходит автоматически, иначе нужно лочить всю память(NtLockVM) или на каждой итерации сбрасывать набор(интересно снять профайл ).

Вероятный метод:
A. Создаём отображение RW(V1)/RW(V2). Если изменить данные в первом образе, второй не добавляется в набор.
B. Создаём область writewatch(V1). Нельзя мониторить через ww отображения.

Инструкция выбирает данные(eg пишет переменную) V1. Выборка отслеживается каким то образом, не важно как. Получаем линейный адрес выборки, раскодируя инструкцию или через ловушку.

A: Проверяем WS(V1) область должна отсутствовать в наборе. Пишем данные в V2, таким образом реализуя анклав. Запись из текущего процесса будет в мониторе набора(адрес инструкции), из другого процесса ядерная и лог будет пуст, но при этом область добавится в набор.

B: WSW(V1), запись будет из текущей страницы. Так же проверяем пишущий код на наличие записей(WSW). Так как необходим анклав, то пишем во вторую область WSW, читаем из неё и пишем в V1, либо можно сделать через проекцию(как в A).

Вариант A надёжнее, но сложнее из за необходимости сброса набора(могут быть подводные камни). Возможны разные вариации, например сделать V1 только R(так как проекция).

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

-----
vx

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

Почему никто ничего не отвечает

Дайте мне что нибудь.

-----
vx

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

difexacaw пишет:
Почему никто ничего не отвечает

Так тема-то непростая. Может ее сначала чуть упростить, а потом двигаться в сторону усложнения?
Для начала, например, можно снять трассу после нажатия кнопки равно.
А там глядишь и народ подтянется, поскольку будет конкретный и понятный пример.

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

dma

Ты уже год почти пытаешься это сделать..

Зачем и главное что делать с этой трассой ?

-----
vx

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

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

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

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

ARCHANGEL пишет:
ну это может пару часов, если очень много кода
чисто из любопытства. много это сколько?
Максимальный размер страницы 256 мб, "влазит" в неё не больше 75 лямов инструкций (х64). по времени для трассера ( не самого шустрого) это 10 мин.\
ARCHANGEL пишет:
по хэндлерам прыгать как-то мало смысла.
ну так "знакомство" с этого и начинается. не уверен, что таблицы читаются проще чем линейный код.

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

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

ARCHANGEL пишет:
Снять трассу после нажатия кнопки - ну это может пару часов, если очень много кода.

Ну это если в SDE делать очень детализированную трассировку. Но ведь детализацию можно и уменьшить, если ты точно знаешь, что у тебя будет трассироваться нужный участок кода. SDE ведь сделан на базе ПИНа, а ПИН, по идее, должен быть очень гибкой штукой. Я только еще немного "не догоняю" в его гибкости. Инди, по-моему, тоже в ПИНе не особо разбирается, ну или "темнит", а может и то и другое.

ARCHANGEL, может вы поможете прояснить ситуацию? Задача получить трассу от точки А до точки B (начало и конец обработчика события). Я, конечно, понимаю, что есть документация и все такое, но тогда это получается достаточно времязатратно, нежели когда тебе подскажет опытный человек. Я не имею в виду, что все нужно сделать за меня, но хотя бы общий алгоритм и какие АПИ то ПИНа использовать, чтобы получить нужный результат. Кстати, может еще кто-нибудь из опытных людей подскажет как лучше решить мою задачу?

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

sim_19

> тоже в ПИНе не особо разбирается

Мне не нужно знать его интерфейсы, вообще этот инструмент нужен не для снятия трассы, а вроде бы как для мониторинга некоторых событий. Тоесть теоретически он может отправить всю кодовую секцию в буфер и одно место там нужное поправить, когда этот блок получит управление вам придёт нотифи. Это основной принцип работы пина - встроить вызов в произвольный код. Более того пин это не нэйтив, он требует что бы его развернули", он запускается как тяжёлое апп(подобно как и WOW-слой, без полноценного развёртывания всей среды это не может работать). Нельзя его просто загрузить и задать адрес на трансляцию, это так не работает.
У меня есть свой визор(дий), проект закрыт так как улучшать больше нечего. Решать задачу на профайл --> Link <-- не имеет практически смыла, это на порядок поднимет профайл, но при этом вызовет анстаб и есчо на это нужно овер дофига памяти. Сборка блоков на лету ничему хорошему не приводит. Нет смысла портить усложняя то, что и так идеально работает.

По теме я поработал сегодня, пока ничего нет. Я могу только привести пример по анклавам, может это чем то поможет..

Тех детали.
WW - аллокация памяти только в reserved области. Это значит что если в пределах 0x10000(или какая гранулярность?) региона была аллокация, то создать область WW не получится. Её можно создать только в области, которая не зарезервирована. Тоесть нельзя секцию WW в проекции пе разместить

WSW монитор вернёт IP:VA выборки. Для её подтверждения нужно отследить софтверную выборку, это не проблема. Но WSW механизм однократный, если проверка пройдёт и отладчик к примеру станет на инструкции после записи(добавления в WSW), то запись далее останется не замеченной(так как ядерная).

Критерий детекта визора:

1. Не соответствие WSW/WS текущей выборке.
2. Появление новых записей в WS между двумя выборками.

Пока это всё что есть.

-----
vx

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

difexacaw DIY не выложите потестировать?

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

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

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


ARCHANGEL пишет:
Против виртуализированного кода всё равно неприкольно

ARCHANGEL, а вы не могли бы добавить немного подробностей для вышеприведенной цитаты.
Может это намек на инструменты типа: Unicorn, QEMU или BOCHS?
Так же интересно мнение и других форумчан на этот счет.

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

sim_19

Это скорей про VMProtect, ASProtect и прочие подобные

-----
IZ.RU

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

Попробовал простой семпл потестить, отладчик отлично палит, но не заводится ни на dio, ни на пине.

f68e_29.09.2019_EXELAB.rU.tgz - ws.7z

Добавлено спустя 13 часов 31 минуту
Видос как это работает --> Link <--

Забавный эффект - после скана памяти происходит блокировка сервиса, он будет возвращать всегда ошибку не зависимо от набора, так как лог не влазит в буфер

-----
vx

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

Между делом детект procmon через набор.

Это работает через ядерный бэктрейс - ядро вызывает RtlWalkFrame.. это можно обнаружить в юм. На младших версиях можно создать ловушку через PG.

4981_03.10.2019_EXELAB.rU.tgz - PM.7z

-----
vx

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

так что касательно вашего дия ? где его найти потестить

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