• XSS.stack #1 – первый литературный журнал от юзеров форума

Статья Малварка под микроскопом - Donut

Отслеживать
Пожалуйста, обратите внимание, что пользователь заблокирован
DildoFagins сказал(а):
держишь секцию кода, как данные в зашифрованном виде, копируешь по инструкции в исполняемый буффер
сначала надо построить графы переходов, см. тему Индия указатель в описатель.
 
Пожалуйста, обратите внимание, что пользователь заблокирован
evilcore сказал(а):
сначала надо построить графы переходов, см. тему Индия указатель в описатель
Да не обязательно, я думаю. Ты можешь расшифровывать инструкции по одной в то место, где они и должны были быть (в секцию текста). А перед ней и после нее добавлять код сохранения и переключения контекста потока. После исполнения затирай и инструкцию и пролог/эпилог менеджмента контекстов рандомными байтами. Переходы можно обработать отдельно, каждый отдельно от другого, без графа. Если ты будешь использовать те же IDebug* интерфейсы, то многие вещи в этом плане за тебя сделает подключенный отладчик.
 
Последнее редактирование:
А если под отладчиком менять instruction pointer, а без отладчика просто выход.
А для данных, например, сделать SDK на уровне сорцов, для того, чтобы самому задавать, какие указатели надо запротектить, сделав высокоуровневый интерфейс для удобства, а под капотом пару фейк-тру передавать через какую-нибудь шаред память отладчику(процесс-родитель, который стартует ОП), он на фейк адреса(к которым изначально в сорце будет обращение) поставит хардварные бряки и в коллбеке при эксепшене на доступ к фейк адресам, подменит их на тру. Или бред?:)
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Haunt сказал(а):
А если под отладчиком менять instruction pointer, а без отладчика просто выход.
А смысл? Что это даст?

Haunt сказал(а):
сделать SDK на уровне сорцов, для того, чтобы самому задавать, какие указатели надо запротектить
Если на уровне сорцев, то имхо лучше их морфить , либо кодить VM . Визоры все эти хороши, когда работать с бинарником, т.е. для крипторов или еще какого софта, который тяжело переписать.
 
Quake3 сказал(а):
А смысл? Что это даст?
Ну тут скорее разговор про ситуацию, когда имеем 2 бинаря. Один является дебаггером второго. В таком случае, смена IP будет происходить дебаггером, без него - второй бинарь будет невалид, либо же, будет идти по легитимной ветке исполнения. Как вариант - вешаем хардварный брейк, через установку контекста потока, в DR0-DR3 пишем адрес legal_func, которая вызывается в main и которая является по своей сути обыкновенным выводом строки hello world. В программе-отладчике ловим дебаг исключение, меняем IP, либо же просто подменяем адрес legal_func на mal_func. Ну то есть по разному можно придумать вообще, как это обыграть. И это в простейшем случае. Такая штука есть частным случаем индеклава на исполнение. В аввм произойдёт вызов legal_func, либо же вообще не валид указателя, который мы поместим в сорц, то есть создадим ситуацию, когда изолированное от системы апп под эмуляцией аввм просто крашнет или пойдёт по легитимной ветке исполнения. Почему в эмуляторе не произойдёт фикса? Представим, что мы имеем практически нулевые знания об устройстве аввм. У нас есть только логика и предположения. Можно предположить, что обойдём эмуль по той причине, что адреса в эмуляторе смещены и HWBP будет установлен по другим адресам, на которые НЕ установлен дебаг коллбек в нашем отладчике. А даже если и с этим справятся, то каким образом наш юм отладчик сможет переписать память в аввм, которая, предположительно, исполняется в км? Практически аналогично работает защита памяти от дампа. Ты интересовался когда-то:)
Ставим HW брейки на несуществующие указатели, которые сами же помещаем в сорц, к примеру.
Далее, когда процессор, исполняя поток, обращается к ним, перед обращением генерируется исключение и отладчик производит фикс адреса на существующую память и поток продолжает исполнение. Если реверсер перезапишет DR0-DR3 регистры в своём отладчике - то наша программа-отладчик не словит дебаг коллбек на обращение к N/A памяти и программа, которая должна быть под нашим отладчиком - крашнется, фикса выборки не произойдёт. Под листингом - по этим адресам так же данных нет. Резольвинг правильного адреса, по которому есть данные, произойдёт через обработку исключения нашим отладчиком в момент, когда процессор, исполняя поток, наткнётся на адрес, который мы поместили в DR0-DR3. Это уже индеклав на RW выборки. Плюс эти две программы смысла друг без друга не несут никакого, то есть как-либо анализировать их можно только совместно. Тот же слив на ВТ по отдельности любой из них ничего не даст, в разрыве друг от друга это просто невалид бинари.

Quake3 сказал(а):
Визоры все эти хороши, когда работать с бинарником, т.е. для крипторов или еще какого софта, который тяжело переписать.
Инди вроде писал, что невозможно, для произвольного бинаря это сделать.
 
Последнее редактирование:
Пожалуйста, обратите внимание, что пользователь заблокирован
Если хочется работать непосредственно с бинарщиной (опкодами), а когда они уже уложены в PE-файл, копаться в них сложно. То можно попробовать делать обработку на уровне объектных файлов (до их линковки). В это время нет жестко прописанных адресов и смещений, будет проще работать с кодом. Не знаю, есть ли готовые и удобные библиотеки для этого, но что-то мне подсказывает, что какой-нить LIEF или libradare2 должны с этим справиться.
 
Пожалуйста, обратите внимание, что пользователь заблокирован
DildoFagins сказал(а):
Не знаю, есть ли готовые и удобные библиотеки для этого
Нет, ты же сам искал такое на васме года 3 назад - посоветовали gcc и все. Мы тоже думали в этом направлении, но разве что самому кодить инструменты (РЕ парсеры почти все писали для обучения, ну и тут также).

Haunt сказал(а):
что невозможно, для произвольного бинаря это сделать.
Для произвольного мб и нельзя, но обычная малварка, без SEH и прочего.. он на тестах запускает dbgview , вполне работает прога.

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

Все решается просто
Route as flow, eg:

1. NtContinue
A. Return from service(failure).
B. Load context and run.

One of two CME is IDLE.

2. NtCallbackReturn
A. Return from service.
B. Return to NT.

CME for service is IDLE in case B.
 
Пожалуйста, обратите внимание, что пользователь заблокирован
https://mohamed-fakroud.gitbook.io/red-teamings-dojo/playing-around-com-objects-part-1 - не знаю, что будет в следующих частях, но в этой неплохо описаны азы COM, если вдруг описания из сабжевой моей статьи кому-то не хватило. Ну и да, к сожалению на английском, но, может, кто-нибудь хороший из местных захочет перевести для комьюнити.
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Kernel32dll сказал(а):
Но что делать с абсолютно открытым импортом в inmem_pe.c и inmem_dotnet.c? Закрывать с помощью GetProcAddress? Видел форк пончика на прямых сисколлах на гитхабе от одного парня, но он почему то детектит 64 битный натив ехе как VBScript…И скомпилировать эту версию пончика под x86 не получается, надо прототипы сисколлов менять походу
Зачем сисколлы в процессе загрузки дотнет образа? Там же через COM интерфейсы всё взаимодействие с дотнетом происходит, может я чего то не понимаю
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Скрытие импорта бесполезная тема, хз зачем его скрывать вообще, плюсов нет, разве что файл будет выглядеть подозрительно
 
admin


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх