Вывести трассу вызовов DLL?

q2e74,

> Rel, Как это должно работать? Общая схема?

Он не знает. Он постарел в интересах за последние несколько лет.)

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

Это полноценные обычно виртуальные машины.

DBI - это урезанные версии визоров на основе трансляции или софтверной эмуляции(как и любая AV-VM).

У всех этих из за смены мода есть огромные проблемы https://wasm.in/blogs/softvernye-anklavy.548/ etc.

Норм визор для локальных задач должен выполняться в том же режиме что и апп.

-- как это работает:

В основе лежит бесконечный цикл для каждой задачи(потока) из которого штатными средствами выйти невозможно.

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

Как это с системой работает.
В ядро есть в ход и выход. Выходы из него контролируются, путём патча памяти. Это способ не хороший, но идинственно возможный в юм. Локально память может быть восстановлена(idp) при выборки из под визора(те локально, не из ядра).

Как это запускается.
Это всё нэйтивное, поэтому юзер оболочка не нужна. В самом простом случае инжектится модуль на EP, при этом будет пропущена куча событий(dll/tls/etc). При необходимости это можно сделать до того, как какой то юзер код получит управление(те до выполнения юзер нотификаций, до загрузки пользовательской среды) изменив способ запуска.

Как с этим работать.
Нужно понимать как всё устроено. Тогда работа проходит в компилере налету. Снимается какой то лог, визор пересобирается и апп перезапускается. Это делается десятки/сотни раз за час при активном анализе семпла. В этом нет кнопок что бы нажимать, нужно думать и собирать.

 

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

 

UbIvItS,

Вызовы(ваши call's) как и любые прочие события нужно найти выполнив апп под монитором. Есть и возможность в статике, это сборка модуля с /cfg опцией, когда в бинарь будет вставлена карта с началом всех процедур. Это очень годная фишка, но она лишь для последних сборок ос используется.

 

всё проще, просто работа.

--- Сообщение объединено, 5 фев 2019 ---

Один блок или одна инструкция?

Беру(гипотетически) какой-нибудь екзешник, создаю в нем секцию, (кладу туда что именно из архива?), и меняю entry point на первую инструкцию твоего кода в дописаной секции, как найти место выхода из твоего кода, что бы отправить eip на старт текст-секции екзешника? Судя по длльке вариантов достаточно, что бы я промахнулся.

 

q2e74,

В данной сборке исполнение не пакетное. Так как нужна адресная трансляция. В предыдущих сборках была пакетная обработка - линейный блок выполнялся, но там не нужна была выборка.

> как найти место выхода из твоего кода, что бы отправить eip на старт текст-секции екзешника?

Вопрос не ясен. Как только визор получает управление, то апп начинает мониторится. Монитор не прекращается, точнее есть условия когда он прекратит трассировку"(динамическую эмуляцию), но такие условия специально нужно определить. По дефолту такие условия не определены, монитор никогда не прекратится.

 

Логично. В принципе, раз екзешник мой, значит свой код то я точно найду условиями на регистры, или я обломаюсь из-за визора?

 

q2e74,

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

--- Сообщение объединено, 5 фев 2019 ---

q2e74,

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

 

За дополнение огромное спасибо, а про не узнает.... если использовать не напрямую RDTSC, а допустим три куска из своего кода разной длины, и отношения этих замеров друг к другу. Правильная цифра при правильном округлении - криптоключ. Визор не попортит такой ключик?

 

q2e74,

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

А во вторых каким образом вы получите время, если все счётчики под вз тикают в симуляции для обхода таких детектов ?

 

очень громкое заявление, Инди. к примеру, прога бежит в два потока и на каждом потоке можно прикрутить счётчик == сравнивая дельту меж счётчиками, получаем детект аномальной тормозухи того иль иного потока. короче, от многопоточек очень сложно скрыть работу визоров/дебагеров/вирт.

 

UbIvItS,

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

 

Indy_, ты в цикл сколько угодно СВОИХ (на коленке слабанных) счётчиков можешь впихнуть..

while
******
x++;
*******
y++;
*********
end while
потом сравниваешь сколько в х, у набежало в потоке №1,2..n можно высчитать среднестатистические перекосы меж потоками. а вот дебажная активность начинает приводить к весьма заметным аномалиям.

 

UbIvItS,

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

А вы что, обходы строите этого всего, зачем ?

 

Твои слова верны лишь для идеального варианта..

1. на каждом потоке висит своя копия визора.
2. у всех копий одни и те же настройки.
3. визоры пашут сугубо в пассиве (режиме наблюдения), то бишь не ставят в потоках бряки.
======
но из пассивом не всё так чисто: работа визора даёт оверхед на использование памяти и главным узким местом становится кэш процессора == оптимаза под кэш является тонкой штукой и работа хуков визора даже в самом тихом режиме неминуемо даст перекосы. + можно соорудить тесты на валидность адресов вызова.

просто смотрю возможные варианты.. любопытства ради

 

TermoSINteZ, 2013 год..

Имхо софтварно это все делать бред. Профита нету. Решать сферические задачи, даже сложные без выхлопа в виде чего-то (продукта).

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

Более того как все и сказали - нету задачи где оно нужно. На кл и без этого всё ломают. Там тред есть где посоны на базе куему все делают и норм. Не совсем оно так как у инде, но оно работает, анпакает и решает крайне сложные задачи.

Так что канет эта штука в историю на яндекс диске.

 

TermoSINteZ, не, я имел ввиду, что уже 6 лет эта технологи есть и робит.

 

UbIvItS,

> в самом тихом режиме неминуемо даст перекосы. + можно соорудить тесты на валидность адресов вызова.

Что значит валидность адресов, если что то не валидно, то улетает в крэш.

Это понятно что есть разница по профайлу, но как это узнать, те снять профайл, счётчики то в симуляции. Я даже не могу предположить как такое провернуть. Кэши вы упомянули и перекосы как не давние атаки, но там счётчиками и снимался профайл.

TermoSINteZ,

> Вы просто включаете режим процессора.

Зайдите на ресурс где народ занимается реальными вещами, тот же кл. Такое посоветуйте и вас обольют дерьмом вообще все. Технология заложенная в железо никакого отношения не имеет к задаче, которую она решеает вне среды вендоров. Хорошо в железке есть некий механизм IPT, для этого нужно пилить драйвера, изучать, отлаживать, привлекать людей кто в теме; при этом не ясно вообще как это будет работать.. И это совет для решения тривиальных задач, которые отлично решаются в юм. Это практически слоники в сферическом вакууме". Ты есчо посоветуй загрузочный eprom перешить с smb, что бы цвет окна поменять
Я думал что ты адекватен в таких вопросах. Впрочем давай посмотрим реально и практически, сколько тебе нужно времени что бы допустим найти вводимую строку в блокнот, через эти ipt etc ?