Собственно, сабж. Интересует программная реализация сего действа. Наверняка кто-то делал, подскажите, плиз.
Свои ключи ExeCryptor в разделе HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Shell Extensions\Approved. Проблема в том, что они "скрытые" и обычниыми API их не удалить - RegDeleteKey и SHDeleteKey...
Bobs Возможно нет прав. Попробуйте стать владельцем ключа - right click -> permissions. Или они невидимые?
Bobs Сказал ведь, используй натив. Винапи не может работать с такими строками, например если в конце два нуля, поэтому регэдит и не отображает.
Bobs Я так понял, адрес ключа известен, вот только удалить его даже с правами админа не удаётся. Попробуй воспользоваться стандартным планировщиком с правами system, который позволяет просматривать и модифицировать все ветви реестра без исключения, защищенные в том числе.
netuser Ключ этот можно удалить и посредством программы Registry Trash Keys Finder, она находит ключи этого протектора, и даже позволяет просматривать содержимое ключей и удалять такие ключи. У меня же появилась необходимость реализовать это в своей программе, и я не знаю как это сделать, если только не писать драйвер.
Это многих вводит в заблуждение, думою следует обьяснить. Это сервисы, не правильно говорить о них как об экспортах, правильно говорить как об идентификаторах. NtOpenKey подразумевает под собой ID сервиса, а это число посредством которого он и будет вызван(индекс в таблице дескрипторов), например для вызова тогоже NtOpenKey мы можем использовать код: Код (Text): mov eax,0x77 mov edx,esp int 0x2e Сдесь 0x77 это и есть идентификатор сервиса NtOpenKey. Также подразумевать под NtOpenKey функцию будет не совсем верно, так как функция имеет некоторую модель вызова, поэтому её конвенция вызова относительна. Относительно экспорта она будет одной, относительно шлюза совсем другой. В юзермоде экспортируются переходники(заглушки, стубы) для вызова сервиса Zw* и Nt*, они имеют общую точку входа. Ядерные хэндлеры сервисов имеют сответственно имена Nt*. Также неверно говорить про соответствие имени хэндлера сервиса в ядре и экспортируемого стуба в юзермоде. Некоторые считают что для для хэндлера сервиса в ядре(Nt*) соответствующий стуб в ntdll будет иметь имя Zw*, это не верно, например в некоторых версиях сервис NtSuspendProcess не имеет соответствующего стуба ZwSuspendProcess, но имется экспортируемый стуб с именем NtSuspendProcess. Обычно если говорят про сервис, то говорят имя его ядерного обработчика Nt* и для юзермода подразумевают его индекс. Думою понятно обьяснил.
Код (Text): .text:7C929C87 public RtlpNtOpenKey .text:7C929C87 RtlpNtOpenKey proc near .text:7C929C87 .text:7C929C87 arg_0 = dword ptr 8 .text:7C929C87 arg_4 = dword ptr 0Ch .text:7C929C87 arg_8 = dword ptr 10h .text:7C929C87 .text:7C929C87 mov edi, edi .text:7C929C89 push ebp .text:7C929C8A mov ebp, esp .text:7C929C8C mov eax, [ebp+arg_8] .text:7C929C8F test eax, eax .text:7C929C91 jz short loc_7C929C97 .text:7C929C93 and dword ptr [eax+0Ch], 0FFFFFFCFh .text:7C929C97 ; Вызов ZwOpenKey .text:7C929C97 loc_7C929C97: ; CODE XREF: RtlpNtOpenKey+Aj .text:7C929C97 push eax .text:7C929C98 push [ebp+arg_4] .text:7C929C9B push [ebp+arg_0] .text:7C929C9E call ZwOpenKey .text:7C929CA3 pop ebp .text:7C929CA4 retn 10h .text:7C929CA4 RtlpNtOpenKey endp ; Вызывает следующее .text:7C90DD3C public ZwOpenKey .text:7C90DD3C ZwOpenKey proc near ; CODE XREF: RtlOpenCurrentUser+43p .text:7C90DD3C ; sub_7C91D18E+F1p ... .text:7C90DD3C mov eax, 77h ; NtOpenKey .text:7C90DD41 mov edx, 7FFE0300h .text:7C90DD46 call dword ptr [edx] .text:7C90DD48 retn 0Ch .text:7C90DD48 ZwOpenKey endp Clerk Код (Text): mov eax,0x77 mov edx,esp int 0x2e почему такой вызов? и не sysenter
Coderess Этот универсальнее, впрочем какая разница. По адресу 0x7FFE0300 указатель на KiFastSystemCall, а она загружает в Edx указатель на стек и юзоет сервис посредством Sysenter, если процессор её не поддерживает то будет вызов через прерывание.
