Сейчас на форуме: jinoweb (+6 невидимых)

 [email protected] —› Программирование —› Критерий EP.
<< . 1 . 2 .
Посл.ответ Сообщение


Ранг: 338.5 (мудрец), 349thx
Активность: 2.112.42
Статус: Участник

Создано: 01 ноября 2018 19:37
· Личное сообщение · #1

Здрасте.

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

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

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

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

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

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

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

-----
vx





Ранг: 136.0 (ветеран), 360thx
Активность: 0.270.14
Статус: Участник
Qt Developer

Создано: 05 ноября 2018 11:16
· Личное сообщение · #2

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


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

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


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


Ранг: 338.5 (мудрец), 349thx
Активность: 2.112.42
Статус: Участник

Создано: 05 ноября 2018 15:12 · Поправил: difexacaw
· Личное сообщение · #3

ClockMan

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

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

Code:
  1. ...
  2. 7C9466AF    Debug string: DYE: #AV at 0x3AA0ACB to [0x0] as W
  3. 7C9466AF    Debug string: DYE: NtContinue(IP': 0x3AA0AD2, EFL: 0x10246)
  4. 7C9466AF    Debug string: DYE: #AV at 0x3AA0BF5 to [0x0] as W
  5. 7C9466AF    Debug string: DYE: NtContinue(IP': 0x3AA0BFF, EFL: 0x10246)
  6. 7C9466AF    Debug string: DYE: fault STATUS_BREAKPOINT at 0x3A9BCDA
  7. 7C9466AF    Debug string: DYE: NtContinue(IP': 0x3A9BCEB, EFL: 0x246)
  8. 7C9466AF    Debug string: DYE: DF to PEB.Debugged at 0x3A9BD8E
  9. 7C9466AF    Debug string: DYE: DF to PEB.Debugged at 0x3A9BDBA
  10. 7C9466AF    Debug string: DYE: #AV at 0x3A9DA0A to [0x0] as W
  11. 7C9466AF    Debug string: DYE: NtContinue(IP': 0x3A9DA16, EFL: 0x10206)
  12. 7C9466AF    Debug string: DYE: #AV at 0x3A9F569 to [0x0] as W
  13. 7C9466AF    Debug string: DYE: NtContinue(IP': 0x3A9F573, EFL: 0x10246)
  14. 7C9466AF    Debug string: DYE: AI-DF at 0x421828 to [0x43D68C] as R  , dS: 0x7C
  15. 7C9466AF    Debug string: DYE: - BTR: 0x415757 -> 0x421820
  16. 7C9466AF    Debug string: DYE:        CALR AI: 0x0
  17. 7C9466AF    Debug string: DYE: - BTR: 0x3CC015C -> 0x415757
  18. 7C9466AF    Debug string: DYE:        JMPI AI: 0x0


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

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

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

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

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

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

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

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

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

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

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

-----
vx





Ранг: 338.5 (мудрец), 349thx
Активность: 2.112.42
Статус: Участник

Создано: 07 ноября 2018 20:44 · Поправил: difexacaw
· Личное сообщение · #4

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

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

ENIGMA:
Code:
  1. DYE: AI-DF at 0x60F6C1 to [0x610340] as R  , dSTK: 0xA4
  2. DYE: - BTR: 0x703CAB -> 0x60F6A4
  3. DYE:        CALR AI: 0x0
  4. DYE: - BTR: 0x808120 -> 0x703C9E
  5. DYE:        JMPI AI: 0x0
  6. DYE: PE-PROT at 0x7C801A81 as 0x400000: 0x1000
  7. DYE: AI-DF at 0x60B4D0 to [0x6117C0] as R  , dSTK: 0x779D0
  8. DYE: - BTR: 0x60F480 -> 0x60B4C4
  9. DYE:        CALR AI: 0x0
  10. DYE: - BTR: 0x60A3BE -> 0x60F473
  11. DYE:        RET  AI: 0x0
  12. DYE: PE-PROT at 0x7C801A81 as 0x400000: 0x1000
  13. DYE: AI-DF at 0x60B4D0 to [0x6117C0] as R  , dSTK: 0x779D0
  14. DYE: - BTR: 0x60F480 -> 0x60B4C4
  15. DYE:        CALR AI: 0x0
  16. DYE: - BTR: 0x60A3BE -> 0x60F473
  17. DYE:        RET  AI: 0x0
  18. DYE: AI-DF at 0x421828 to [0x43D68C] as R  , dSTK: 0xC8
  19. DYE: - BTR: 0x415757 -> 0x421820
  20. DYE:        CALR AI: 0x0
  21. DYE: - BTR: 0x60F4ED -> 0x415757
  22. DYE:        RET  AI: 0x0


OBSIDIUM
Code:
  1. DYE: AI-DF at 0x4CA279 to [0x4CA26A] as RW , dSTK: 0x8C
  2. DYE: - BTR: 0x4CA0DF -> 0x4CA274
  3. DYE:        RET  AI: 0x0
  4. DYE: PE-PROT at 0x7C801A81 as 0x400000: 0x1000
  5. DYE: AI-DF at 0x4CA279 to [0x4CA26A] as RW , dSTK: 0x78
  6. DYE: - BTR: 0x4CA0DF -> 0x4CA274
  7. DYE:        RET  AI: 0x0
  8. DYE: PE-PROT at 0x7C801A81 as 0x489000: 0x1000
  9. DYE: AI-DF at 0x4C9B80 to [0x4C9A50] as RW , dSTK: 0x74
  10. DYE: - BTR: 0x4C98E5 -> 0x4C9B7F
  11. DYE:        RET  AI: 0x0
  12. DYE: AI-DF at 0x421828 to [0x43D68C] as R  , dSTK: 0x54
  13. DYE: - BTR: 0x415757 -> 0x421820
  14. DYE:        CALR AI: 0x0
  15. DYE: - BTR: 0x3A0A1E5 -> 0x415757
  16. DYE:        JMPR AI: 0x0
  17. DYE: - BTR: 0x3A0A1E0 -> 0x3A0A1E5
  18. ...


THEMIDA:
Code:
  1. DYE: PE-PROT at 0x3DF0E81 as 0x401000: 0x1D000
  2. DYE: PE-PROT at 0x3DF0E81 as 0x400000: 0x1000
  3. DYE: PE-PROT at 0x3DF0E81 as 0x400000: 0x1000
  4. DYE: PE-PROT at 0x3DF0E81 as 0x400000: 0x1000
  5. DYE: PE-PROT at 0x3DF0E81 as 0x400000: 0x1000
  6. DYE: PE-PROT at 0x3DF0E81 as 0x400000: 0x1000
  7. DYE: PE-PROT at 0x3DF0E81 as 0x400000: 0x1000
  8. DYE: AI-DF at 0x421828 to [0x43D68C] as R  , dSTK: 0xE4
  9. DYE: - BTR: 0x415757 -> 0x421820
  10. DYE:        CALR AI: 0x0
  11. DYE: - BTR: 0x54294C -> 0x415757
  12. DYE:        RET  AI: 0x0


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

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

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

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

ENIGMA:
Code:
  1. DYE: PE-PROT 0x400000 x 0x1000:  RW
  2. DYE: DF to PE header at 0x60AD2F to 0x40003C as R  
  3. DYE: DF to PE header at 0x60AD2F to 0x4001FC as R  
  4. DYE: DF to PE header at 0x60AED6 to 0x4001FC as W  
  5. DYE: DF to PE header at 0x60AD2F to 0x400224 as R  
  6. DYE: DF to PE header at 0x60AED6 to 0x400224 as W  
  7. DYE: DF to PE header at 0x60AD2F to 0x40024C as R  
  8. DYE: DF to PE header at 0x60AED6 to 0x40024C as W  
  9. DYE: DF to PE header at 0x60AD2F to 0x400274 as R  
  10. DYE: DF to PE header at 0x60AED6 to 0x400274 as W  
  11. DYE: PE-PROT 0x400000 x 0x1000:   R
  12. DYE: DF to PE header at 0x7C9102D6 to 0x400000 as R  
  13. DYE: DF to PE header at 0x7C9102DD to 0x40003C as R  
  14. DYE: DF to PE header at 0x7C9102EE to 0x4000E0 as R  
  15. DYE: DF to PE header at 0x7C8102EE to 0x400144 as R  
  16. DYE: DF to PE header at 0x7C8102F3 to 0x400140 as R  
  17. DYE: DF to PE header at 0x7C9102D6 to 0x400000 as R  
  18. DYE: DF to PE header at 0x7C9102DD to 0x40003C as R  
  19. DYE: DF to PE header at 0x7C9102EE to 0x4000E0 as R  
  20. DYE: DF to PE header at 0x7C80B7C8 to 0x40013C as R  
  21. DYE: DF to PE header at 0x41560D to 0x4000E0 as R  
  22. DYE: DF to PE header at 0x41561E to 0x4000F8 as R


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

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

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

-----
vx





Ранг: 568.2 (!), 465thx
Активность: 0.550.57
Статус: Участник
оптимист

Создано: 08 ноября 2018 11:15
· Личное сообщение · #5

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

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





Ранг: 338.5 (мудрец), 349thx
Активность: 2.112.42
Статус: Участник

Создано: 08 ноября 2018 19:05 · Поправил: difexacaw
· Личное сообщение · #6

ClockMan

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

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

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

-----
vx




Ранг: 315.1 (мудрец), 631thx
Активность: 0.30.33
Статус: Модератор
CrackLab

Создано: 08 ноября 2018 19:12
· Личное сообщение · #7

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

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

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


Ранг: 338.5 (мудрец), 349thx
Активность: 2.112.42
Статус: Участник

Создано: 08 ноября 2018 19:33 · Поправил: difexacaw
· Личное сообщение · #8

SReg

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

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

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

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

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

-----
vx





Ранг: 568.2 (!), 465thx
Активность: 0.550.57
Статус: Участник
оптимист

Создано: 09 ноября 2018 00:07
· Личное сообщение · #9

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

DebugActiveProcess
Запускаются 2 процесаа один из них под отладчиком
CopyMem2
в отлаживаемом приложении кода как такового нет при исключении заполняется часть кода
В арме есть ещё Nanomit и Codesplice
Nanomit
за место условных и безусловных прыжков используются in3 исключения
Codesplice
часть кода украдена и вынесена за пределы модуля

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





Ранг: 338.5 (мудрец), 349thx
Активность: 2.112.42
Статус: Участник

Создано: 09 ноября 2018 19:53 · Поправил: difexacaw
· Личное сообщение · #10

ClockMan

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

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

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

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

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

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

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

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

-----
vx





Ранг: 673.3 (! !), 400thx
Активность: 0.40.31
Статус: Участник
CyberMonk

Создано: 09 ноября 2018 20:03
· Личное сообщение · #11

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


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

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





Ранг: 338.5 (мудрец), 349thx
Активность: 2.112.42
Статус: Участник

Создано: 09 ноября 2018 20:19 · Поправил: difexacaw
· Личное сообщение · #12

mak

2.6 + AI-df.

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

-----
vx



<< . 1 . 2 .
 [email protected] —› Программирование —› Критерий EP.
Эта тема закрыта. Ответы больше не принимаются.
   Для печати Для печати