accord, https://wasm.in/threads/strannosti-raboty-psgetcontexthread-v-jadre.29878/#post-359610 Точно, не получится походу. Тогда NtOpenThread/NtGetContextThread просто и для юзер треда ничего другое не нужно, конечно если в ядре античит не сидит. Не нужны эти извраты, да есчо и в другом процессе(аттач изменяет как раз apc механизмы, а контекст через них и получается)
Вообщем тему закрыть можно проблему решил PspGetContextThreadInternal надо вызывать тк в PsGetContextThread проверка какаета на то что контент в драйвере нельзя хранить
accord, Интересно что получится после вызова dll-EP. Контекст ведь асинхронно получается и из dll будет с вероятностью 99.8% деадлок. Хотя античит и не запалит
Зависнет весь процесс при попытке повторно использовать ресурс. Если же ресурс не до конца изменён, при изменении был прерван и использован, то процесс упадёт. По этой причине никогда загрузка и не использовалась через get/set-ctx ps: под ресурсом понимается некоторый обьект, который обычно имеет синхронизации.
Через что можешь посоветовать тогда загрузить длл мейн беспалевно? в юзер моде я юзал setwindowhook но сейчас на кернел моде делаю инжектор
accord, Я говорил ведь что задачу нужно пересматривать, так как не известно что, как и зачем загружать. А есчо всё усложняет античит, который тоже не известно как работает и что контролирует. Во первых когда должна происходить загрузка, когда процесс уже работает ? Точнее более важно что делает длл при инициализации. Что бы вызвать длл поток должен быть остановлен после освобождения ВСЕХ ресурсов, всех синхронизаций. Можно обождать пока поток покинет загрузчик. Но может быть рекурсия по апи, тоесть обождали выход из функции, а она вызвана из другой функции.. Затея гиблая, универсально и стабильно такое работать не будет. Так как потоки создавать нельзя, то получается лишь один возможный способ. Вызвать(загрузить) длл до передачи управления на код приложения(тоесть когда загрузчик передаёт управление на exe после инициализации процесса). Нужно это событие отследить и передать управление на загрузочный стаб, он загрузит либу и вернёт управление. Инжект на exe-EP в простейшем случае.
Я тут наверняка чего то не понимаю, тк никогда читы не писал, но если античит будет палить потоки, которые не принадлежат коду игры, то зачем что-то грузить в процесс игры. То есть все равно постоянно висеть поток не сможет, тк спалится. Если нужно сделать какую-то единовременную операцию (типа чтение или запись виртуальной памяти), то почему это просто не сделать из ядра без всяких инжектов? Или предполагается, что это тоже будет палиться античитом? Может тогда можно обойтись apc, или это тоже спалится?
ну ты наверно просто не смотрел какие читы бывают) ну например чтобы отрисовать вх сдеалть авто наводку и другое надо хукать present и игровые функции а вот apc это херня туда грузятся ток доверенные библеотеки и он мне не подходит тк можно сдампить длл на изи
Rel, Наверно часть чита в виде длл должна так подгружаться, либо какая то часть апп не загруженная до загрузки чита.
Я на юзер моде когда делал инжектор я использовал SetWindowHook но я не знаю доконца как он работает я писал шелл код на загрузку длл свой и через эту функцию через аргумент передавал адрес шелл кода но я хз как сет вин хук работает в ядре
accord, Механизм win-hooks и предназначен для загрузки длл. Как и инжект на EP это всё требует предварительной подготовки, включение некоторых механизмов. Тебе же нужно в произвольный момент впрыснуть модуль в приложение. Rel, > То есть все равно постоянно висеть поток не сможет, тк спалится. Новый поток нужен для загрузки модуля в произвольный момент. Так как при запуске потока все ресурсы свободны и можно безопасно вызвать EP. Но в чите это нельзя использовать. --- Сообщение объединено, 12 фев 2020 --- accord, Я покапался в загрузчике 10ки, вот тебе метод. Ловишь любое загрузочное событие в ядре, imagenotify или есчо что, не суть важно. В ядерном обработчике получаешь юзер стек текущего потока(из контекста). На дне стека лежит контекст(который далее вызывает косвенно exe-EP: NtContinue). Выше будет процедурный фрейм с адресом возврата: LdrpInitialize.. -> экспортная LdrInitializeThunk(). Изменяешь указатель на свой стаб. Когда поток покинет загрузчик управление получит стаб, который подгрузит чит. Посылать APC или трогать сам контекст не следует, античит запалит.
Эмм, так а почему ты не можешь руками из ядра загрузить шелл или длл без необходимости запуска дллмейн и тлс колббеков (выделить память, настроить таблицы импорта и релоки и тд) с обработчиками функций, и затем руками из ядра разместить хуки (наверняка же сплайсинг будешь использовать для хуков), таким образом тебе не нужен будет поток в юзер-моде.
UbIvItS, Каких схем, например ? Античит это антируткит - он находит аномальную активность апп и изменения в статике. Поэтому читы не что иное как руткиты. И детектить их можно как обычную малварь.
чит можно спрятать на локальной машине иль его может даже не быть физически на клиентской машине, но результат его работы виден на сервачах онлайн гамиса == чит, к примеру, может даже работать сугубо в правилах игры, но уже скорость реакции юзверя (кол-во команд в минуту) -- это палево.
Смешно но нет ты не доконца понимаешь как работают читы но частично прав но в моем случае я не отправляю не какие команды на сервер да и функции игры я вываю которые не отсылаются на сервера да в любом случае на любую защиту найдется обход
Главное не забыть восстановить управление. Можно просто перехватить NtContinue, сохранить оригинальный контекст, вызвать дллмейн и далее восстановить контекст. Важно обойтись без патчей, античиты спалят модификацию страницы, даже после восстановления оригинального кода. Можно еще подменить указатели TLS/CFG на этом этапе. А вообще Rel прав, стадию инициализации чита можно полностью выполнить из ядра, конечная цель ведь - надежная установка перехватчиков. ТС, сюда тоже стоит глянуть https://github.com/odzhan/injection