Так как процесс никак не может поймать момент выделения памяти, единственный способ найти стороннюю память - вести список всех аллокаций, которые делал процесс, и периодически пробегаться по всем выделенным регионам и сравнивать со списком. Чтобы поймать все аллокации, процесс может перехватить NtAllocateVirtualMemory и NtMapViewOfSection. Перебрать всю память можно через VirtualQuery (NtQueryVirtualMemory). Если нашли память, которая не прошла через наш хуки и при этом исполняемая - её выделили не мы. Но как быть с памятью, которая уже была выделена до момента, когда мы поставили перехваты? А никак, всю её надо делать доверенной, так как мы ничего не знаем о её происхождении. Однако, если мы знаем, что наш процесс никогда не выделяет исполняемую память, а такая память нашлась до установки хуков - вероятно, эта страничка тоже не наша. Подобным образом ловятся потоки и доставка APC: мы ловим их на создании и смотрим, действительно ли процесс их создавал. С угоном контекста сложнее, но с некоторыми оговорками поймать можно и его. У меня на гитхабе есть библиотечка для антиинжектов, которая детектит все описанные выше способы (даже чуть больше), можешь подсмотреть там: https://github.com/HoShiMin/Avanguard Win32Api, завтра накидаю примерчик.
Так у Рихтера есть же пример как раз с VirtualAllocEx и WriteProcessMemory. При желании даже без VirtualAllocEx можно сделать. Делаем выполнение одним из вышеописанных способов (в оригинале CreateRemoteThread) на LoadLibrary, а в качестве параметра передаём указатель на строку в целевой процессе с именем dll. Это классика.
Удивительно, ты так топишь за Цэ, но при этом не можешь сам собрать один простой пример инжекта с интернетов, что за тебя еще и батник нужно приготовить...
Накидал код, но у меня нет MinGW и MSYS, чтобы собрать под gcc - это уже сами, я ими ни разу не собирал. Скорей всего, будет что-то подобное: Код (Text): g++.exe -std=c++2a ./Injector.cpp -o ./Injector.exe g++.exe -shared ./Library.cpp -o ./Library.dll Собирал в студии с C++20, пробовал на Win11. Собираем 32х-битный билд для инжекта в 32х-битные процессы, собираем 64х-битный билд для инжекта в 64х-битные. Также не будет инжектить в UWP-процессы (не даст песочница), но будет в их RuntimeBroker'ы. Если надо инжектиться в привилегированные процессы - инжектор запускаем или под админом, или встраиваем ему манифест. А, ещё момент, путь указываем полный, т.к. целевой процесс ничего не знает про пути относительно инжектора.
Эму нужен мануал страниц на 1500, чтобы у него все пробелы в знаниях закрыть, которые он не хочет сам изучать. Мануал, который ему и про процессы объяснит, и про виртуальную память, и будет включать краткий справочник по его любимому Цэ, и чтобы еще можно было батником собрать, самое главное - батником собирать.
Да, Хошимин, иди обтекай и без батника, который вообще все соберет и вообще все калькуляторы на вообще всех линейках проинжектит не возвращайся)
Неа, не увидим. В UWP'шный софт я заинжектить не сумею. Независимо от того, напишет тебе кто-нибудь батник для MinGW или нет, ты всё равно скажешь, что условие не выполнено, ведь в калькулятор (а ещё в новый блокнот) не заинжектить.
Даже если он снизойдет и поменяет условие на, скажем, explorer, то все равно будет тестить с каким-нибудь антивирусом и, получив access denied или прибитие процесса, начнет кричать, что обход антивируса при инжекте тоже предполагался, или что-то в этом духе.
Ну в общем, получилось внедриться в UWP, но без мессаджбоксов: в таких приложениях нельзя вызывать API напрямую, всё общение с системой идёт через процесс-брокер (в данном случае поток просто повисает где-то в ядре в win32k). Это особенности песочницы, от инжекта это не зависит, и ты ничего с этим не сделаешь. Однако, можно вызвать что-то несложное, типа OutputDebugString. Обычный инжект, как я написал в примере выше, не будет работать, т.к. песочнице запрещено загружать либы извне. Чтобы обойти это ограничение, пришлось развернуть дллку вручную: выделить в процессе исполняемую память, подготовить образ (заполнить импорты и поправить релоки), записать в выделенную память и натравить на точку входа новый поток. В таком ключе работает. Код в аттаче, но это Proof-of-Concept: маппер не поддерживает TLS, исключения, отложенные и связанные импорты, импорты по ординалам, а также ограничен импортами ТОЛЬКО из ntdll, kernel32, kernelbase и user32 (которые во всех процессах грузятся по одинаковым адресам). В общем, что получилось набросать за пару часов.
Win32Api, вроде чота получилось: Код (Text): g++.exe -static -static-libgcc -static-libstdc++ -std=c++2a -DUNICODE -D_UNICODE -municode .\Injector.cpp -o .\Injector.exe g++.exe -static -static-libgcc -static-libstdc++ -shared .\Library.cpp -o .\Library.dll Однако, несмотря на статики, бинарники всё равно зависят от msvcrt. Хз, как влинковать его статически. Поправил ещё инжектор, чтобы скомпилился с gcc.
Win32Api, Come bat, батяня, батяня, come bat, Ты сплоет припрятал от инф'оцыганят. Шеллкодес им в душу, шеллкодес им в рот,- Конпелит одептов Икс Кот. --- Сообщение объединено, 26 дек 2023 --- Come bat, батяня, батяня, come bat, За нами те, кто всё равно будет рад. Бэктрейс, хэккеран, оверфлоу и макток Come bat заинжектил в поток.
те же яйца, только в профиль да, тут даже дело не в технической сложности, а в дороговизне некоторой (атака на железку может приводить к физ деградации иль даже фатальной поломке цпу/гпу/ссд/..)