Здрасте.

Меня некоторое время небыло, за это время я немного" покопался в протекторах.

Задача:
Определение критерия EP после криптования.

Задача весьма сложна, даже очень сложна.

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

Так например themida, privexeprot etc используют загрузчик - первый образ, он не является исходным.

Решение искалось из абстрагированной идеи что происходит загрузка двух идентичных модулей, это далее позволит возможно найти решение. События загрузки таких копий могут быть обнаружены лишь по адресным лимитам, те образ как единое целое не релоцируем, данные от кода не отличимы, а значит невозможно внедриться в промежуток между ними - декриптор может быть дописан лишь в конец образа, за пределы секций code/data. И таким образом может быть как то можно по последовательности выборок в память определить передачу управления на второй модуль(EP). Но это всё не точно.

Нужен свежий взгляд.

-----
vx

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

reversecode пишет:
на EP изменение энтропии
вычисляется динамически на большой выборке

Отчетливо тянет каким-то бредом.
Изменение энтропии по сравнению с чем?

-----
http://ntinfo.biz

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

ClockMan

> потом опять в тело прота

Не соотвествует реальности, вот лог:



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

Добавлено спустя 39 минут
Я поразмыслил немного, аналитически ничего по задаче не вытянуть. Ясно только следующее:

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

- В пределах образа есть абсолютная адресация, её не может быть за пределы образа.

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

Тогда получается следующее. Сама AI выборка может дать пределы образа. Запуск нового модуля определиться по передаче управления за пределы первого образа. Но на основе выборки их видимо никак не различить(первый образ может настраивать второй). Есчо возможна ситуация, когда сам протектор выполняется по исходным адресам пе, затем выходит в буфер и формирует и запускает оригинальный образ.

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

У Руссиновича есть простая добрая тулза, это монитор рабочих наборов(vmmap). Через этот инструмент можно посмотреть деление на области, которые не показывает отладчик.

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

Изначально я подобное пытался реализовать, но закинул. Получилось что ядро нт не имеет интерфейса для быстрого дампа выделенной памяти. Можно запросить только рабочий набор. Тоесть сервис вернёт список страниц к которым произошла выборка и эти страницы добавлены в WS. Но не дёргать же это на каждой инструкции, если это вызывать после каждого сервиса, то если страница будет выделена, но небыло выборки - такое событие не будет в логе WS, память будет утеряна.

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

-----
vx

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

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

Первый образ выполняется в тех же пределах регионов, что и второй, если так помечать память то все события скипаются почти всегда. Если помечать страницы, уже выполненные, это уменьшает число событий, но их всё равно очень много. Случайно из за не доработки лог уменьшился - отсеялись почти все события.
Получилось следующим образом. Реализовал простеший монитор памяти, он строит массив областей, атрибуты(nt-protect) которых отличаются, просто листая память. Из фильтров Alloc/Protect массив сбрасывается, без какой либо обработки. Оказалось это почти всегда чистит лог от не нужных событий. Причина этому - депротект памяти образа перед его вызовом. Лог по накоторым имеющимся(имеющим свой образ).

ENIGMA:


OBSIDIUM


THEMIDA:


- своего образа не имеет.

SAFEENGINE генерит тьму событий.

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

Далее появилась идея посмотреть на доступ к заголовку исходного модуля.

ENIGMA:


Последние события походу после старта 2-го образа. Настраивает в памяти хидер.

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

Наверно нужно снять лог с имеющихся протов на доступ к пе шапке и вывести поля. Они там все копаются. Обычное апп(не прот) в хидер не пишет, это не нужно.

-----
vx

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

ARMA не заводится, что то пошло не так после дня тестов, видимо нужно загружаться во второй процесс
(DebugActiveProcess CopyMem2

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

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

ClockMan

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

Увидел свет в теме. Так как два образа не отличимы по активности от одного, то есть лишь один способ их различить - по родителю, так как образы разные, то и их загрузка будет разделена временем(активностью). Это видимо и есть решение задачи, только пока абстрактное.

Задавать тут вопросы походу совершенно бессмысленно.

-----
vx

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

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

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

SReg

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

> Первый процесс это отладчик для второго процесса

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

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

Без обид, это лишь рациональный ответ.

-----
vx

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

difexacaw пишет:
Очевидно что процесса два, спец инструмент для этого не нужен. Первый процесс видимо как то образ обрабатывает, раз он был в логах. Но это минутное дело впрыснуть мотор в потомок, сервисы мониторятся, DebugActiveProcess() не нужен, я не использую отладчик.)
DebugActiveProcess
Запускаются 2 процесаа один из них под отладчиком
CopyMem2
в отлаживаемом приложении кода как такового нет при исключении заполняется часть кода
В арме есть ещё Nanomit и Codesplice
Nanomit
за место условных и безусловных прыжков используются in3 исключения
Codesplice
часть кода украдена и вынесена за пределы модуля

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

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

ClockMan

Единственная проблема с процессами - нужно править дебаг вывод, что бы он не сливался воедино. Тоесть нужно пофиксить дебаг вывод, добавив PID в макро, те изменить несколько строк.

На счёт остального - у меня нет мнения и мне нечего сказать. У вас древний подход к задаче, вы думаете что обычные помехи для отладчика имеют значение. Это не верно. Потому что отладчик не используется, для вас не привычно.

> арме есть ещё Nanomit и Codesplice

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

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

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

Срабатывает ловушка, ядро передаёт управление на Ki*Entry. С этого места происходит вход в визор и с этого места апп выполняется в контролируемой среде. Таких событий четыре(обратный ядерный вызов, за исключением сервисного) - исключение, гуй_калбэк, апк и инвалид_хэндл. Входа(Ki*) патчит визор. Заложен механизм подмены выборки, тоесть попытка чтения вернёт исходные данные. Я это использовал лишь для поля антидебага(PEB[2]). Никакой проблемы нет скрыть мод кода нэйтив по адресам ki этим же способом.

Но видимо я тех деталями увлёкся. Про саму задачу очевидно нет смысла говорить.

-----
vx

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

difexacaw пишет:
проты используют свой образ, то задача сводится к выделению нескольких образов

По каким критериям разделяешь, есть образ или нет ?!

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

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

mak

2.6 + AI-df.

Добавлено спустя 1 час 50 минут
Тема закрыта, в связи с ожидаемым баном. Вернусь но не сюда, когда я найду решение.

-----
vx

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