запрет в приложенни remotethread, openprocess

Как это не страшно? Все оч. важные данные находяться в памяти (пароли, пины, коды, еще что нить...)! В любое время можно считать, расшифровать\(а может даже и расшифровывать не придется, если знать где оставить дебагер!). Так что еще как страшно и опасно с точки зрения защиты. Ведь по сущности запись для того и нужна, чтобы в итоге потом прочитать.

Ну зачем же сразу все? Мне чужого не нада! Мне бы своё защитить .
Ну и не совсем ничего не имея... ведь Ring3 имеем

т.е.? я чего то недопонял, то ли я отстал от жизни...

Грустно, товарищи, грустно... это один единственный метод более-менее рабочий. Но толку от него тоже не много!

хммм... как минимум на идею тянет! Респект.

Поле боя - Ring3

 

VirtualFreeEx / ZwUnmapViewOfSection?

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

 

Жаль идею, земля её пухом

 

TermoSINteZ

Вы в курсе что есть APC.. видимо нет. Отлично ловится из юзермода. Особенно если стек уничтожить и юзать иной тред с проверкой потока-ловушки.

 

TermoSINteZ
Так если не шарешь то и не пиши. Да это защитит от APC множеством способом из юзермода.

 

имеется ввиду, что CreateRemoteThread и WriteProcessMemory - это лишь самое простое из того, что можно придумать из под юзера))

под юзером можно запустить драйвер, внедрив код в процесс с правами админа...

а от чего много толку? любая защита обходится, если знать как она организована...

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

 

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

Согласен. Просто inject в этом случае как забор - легче перелезть, чем через дверь войти (гемора много а толку почти совсем нет - защита от дурака)

Тоже не годиться. есть один большой и жирный минус. Используя сторонние библиотеки (к примеру к.н. архиватор с паролем), пароль передается в саму библиотеку - я же не смогу шифровать память которая принадлежит этой либе. Остается только один выход - написать такую либу самому - но порой это не реально, попробуйте переписать к примеру html renderer, ну или к.н. архиватор.
Да и потом перед тем как использовать мои зашифрованные данные я в любом случае их должен расшифровать. Поэтому зная где остановиться, в дабагере, можно с легкостью прочитать защищенные данные.

 

прочитав все посты, можно твердо сказать: "Я люблю тебя Windows!" ))

 

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

мы говорим о разных вещах... человек найдет, а как заставить машину найти?

хех... вы не представляете, насколько вы не правы...

ещё вариант: если была загружена dll с помощью LoadLibrary в контексте вашего потока, то она появится в PEB, там же можно найти базовый адрес загрузки dll и сделать ей FreeLibrary... от LoadLibrary спасет (если успеет), но от внешней самостоятельной загрузки - нет...

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

 

Выходит Rel знает способ как из User mode загрузить драйвер?
А можно примерчик чтобы не спорить\не доказывать, а сразу все обломать!?

 

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

 

А по-твоему драйвера драйверов грузят?
http://wasm.ru/forum/viewtopic.php?id=36236 пост #9

 

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

 

по теме топика: начиная с висты ms ввели новый тип процессов - protected processes (создаются с флагом CREATE_PROTECTED_PROCESS=0x00040000), и вот что пишут по этому поводу:

A typical process cannot perform operations such as the following on a protected process:
+ Inject a thread into a protected process
+ Access the virtual memory of a protected process
+ Debug an active protected process
+ Duplicate a handle from a protected process
+ Change the quota or working set of a protected process

ссылка на доку
тут правда минус есть, приложение должно быть подписано специальным сертификатом windows media :-/

 

Помнится Алекс Ионеску утиль для сброса этого атрибута публиковал когда-то "Introducting D-Pin Purr"

 

RET
Да, было такое дело. Там, как я понял, через драйвер все реализовывалось, так что на 64битке, увы, работать не будет.

 

ну тут не только о висте разговор... начиная с висты не так то просто получить хендл процесса на уровне доверия выше вашего... приходится обходиться VM_READ, VM_OPERATION и QUERY_INFORMATION правами... плюс Data Execution Protection и User Account Control тоже портит жизнь хакерам... надо поставить себе Windows 7, а то ещё не смотрел)))

 

а как и почему связаны слова "драйвер", "x64" и "не будет работать"?))))