Как обнаружить внедрение через CONTEXT.regEip ?

CrystalIC
2. Я вроде написал, что сделаю ExitProcess. Не успеет.
3. Исчерпано.
4. Тоже исчерпано.

С помощью удалённых потоков делал ровно один раз. И это было создание потока со стартовым адресом на LoadLibrary. Думаю, дальше ясно.
А я делаю инжект либо SetThreadContext (инжект в рабочий процесс) либо подменой контекста на этапе создания процесса внутри перехватчика ZwCreateThread (для глобализации перехвата, например). В обоих случаях предварительно заносится шеллкод в процесс-жертву.

 

CrystalIC, меня всё устраивает, главное скажи как это чичас юзать ? Соорудим пример и на практике посмотрим, а то на словах я как-то туго понимаю
А по поводу ловли удаленных потоков у себя в памяти - blast в #8 посту говорил об этом. Лично у меня реализован метод с KiUserApcDispatcher, и отлично работает

 

CrystalIC

Какой ещё селектор стека? Новый стек - это просто предварительно выделенная область памяти, на конец которой указывает ESP.

 

l_inc
Стек это ведь не только регистр Esp, но есчо и селектор в сегментном регисре Ss(четвёртый дескриптор в GDT с базой ноль). Загрузить не валидный селектор нельзя, но можно загрузить селектор, ссылающийся на страницу памяти недоступную для записи. Тогда бесполезно будет использовать Esp.

Ну да уж, тупее не придумоть. Как и сказал Энди - перехват первой инструкции с которой начнёт исполнятсо поток альтернатива, хотя я реализовал код, который перед созданием потока перенаправлял KiUserApcDispatcher() на внедрённый код.
2. Если завершить процесс, то смысла нет внедрятся. У автора топмка цель всего этого - защита собственных приложений, от отладки, дизасма и тп.
Flasher
Вечером может напишу, время вышло)

 

CrystalIC

За основу берётся контекст потока, контекст которого подменяется (или Вы думаете, что я самостоятельно весь контекст выдумывать буду... делать больше нечего...). Поэтому подменить достаточно только ESP и EIP. По окончании исполнения шеллкода оригинальные EIP и ESP восстанавливаются.

На тот момент это был тестовый пример. После него я отказался от CreateRemoteThread.
2. Пост 36:

Есть смысл внедряться?

 

Предлагаю похучить ZwOpenProcess/ZwGetThreadContext/ZwSetThreadContext во всех процессах. Если это не поможет, то спускаемся в ядро и делаем все там.

 

Osen
Ну так об этом всю ж тему говорим ещё начиная с поста Great #10. А CrystalIC выдумывает экзотические, навороченные, малоэффективные методы.
P.S. Кстати, лучше убрать SetThreadContext и GetThreadContext из списка перехваченных. Т.е. перехватывать только ZwOpenProcess (защищаем csrss, кстати, тоже... либо также перехватываем ZwDuplicateObject) и ZwOpenThread.

 

CrystalIC
создать несколько потоков, взять первый, который будет в списке инфы, понизить его приоритет и заюзать в этом потоке бесконечный цикл Int2A/ZwYieldExecution, который будет замерять интервалы.
Почему int2A это ZwYieldExecution? Как ZwYieldExecution может замерить интервал, если они ничего не возвращает, а просто передает управление свободному потоку? Даже при понижении приоритета ZwYieldExecution в цикле будет занимать половину процессорного времени, если его крутить его бесконечном цикле.

 

Osen

Тема о замерах временных интервалов давно исчерпана. Там был детект трассировки. Это другая тема.

Подозреваю, у Вас двуядерный процессор или по крайней мере HT.
Нет. Это не совсем так. Поток, исполняющий ZwYieldExecution, будет занимать только свободное время процессора.

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

 

Osen
Првет друг!
Давно тебя небыло, где пропадал ?
l_inc
Если чесно, ты меня уже достал своими спорами, вначали пойми потом спорь. Практически всё что ты тут написал полная ерунда, я последний раз тебе отвечаю. Да и вообще, ты только споришь, каждый раз оказывается что я прав, а решения не предлогаешь.

Есчо и Ss нужно изменить, если он будет указывать на дескриптор, пусть даже в лдт, в которов база отлична от нуля, и указывает на область памяти доступную только для чтения, то результат будет темже, как и с невалидным Esp. Поэтому твой инжект вероятно будет обнаружен.
Osen

Int2a возвратит число тиков. Сервис только чтобы разгрузить процессор.

 

CrystalIC
Эх... уходите от сути. Мы по сути разговариваем или оценки друг другу даём?

Эт не сомневаюсь. Когда конструктивная аргументация заканчивается, появляется раздражение.

Споры для того и нужны, чтобы один из спорящих что-то понял.

Ух, как категорично. К тому же неправда.

Решение предложено и неоднократно повторено.

Не конструктивно. Мне, пожалуйста, по каждому пункту, где я неправ.

Какой нафек "если"?! Я что-то не видел, где в Вашем коде создаётся новый дескриптор LDT и выполняется подмена ss. А по умолчанию это 23h, указывающий на дескриптор GDT с нулевой базой. Но если надо, запишу туда опять 23h. Какие проблемы?

 

l_inc

Рабочий код увидит только автор топика и никто больше.)

 

CrystalIC
Ну да... а всё, что сюда на публику, это всё фарс. Так о чём вообще можно спорить? Спор окончен.