CSRSS - это кусок подсистемы win32, напрямую связанный с ее реализацией в ядре - win32k.sys. Он напрямую участвует в выводе на экран этого MessageBox. Естественно, никто при разработке не планировал, что туда полезет пользователь.
А с админскими правами можно даже диск отформатировать, железо программно попортить....странно, да?
При написании программы, целью которой было спрятаться куда подальше от глаз пользователя, я сделал так, чтоб она пряталась в другом процессе. Для отладки созданный поток выводил сообщение с его PID и TID MessageBox'ом.
Когда программа уже была готова, я решил, что пора бы ей брать привилегию отладчика, дабы прятаться и в системых процессах (а-ля winlogon, svchost, etc). Сказано - сделано. Однако, забыв о том, что системному процессу вряд ли разрешено использовать GUI, а если и разрешено, то он может быть на другом десктопе, отладочные сообщения я не убрал. При первом же запуске вывалился BSOD.
В результате выяснил, что машина падает при вызове MessageBox в csrss.exe (стоит отметить, что это не первый BSOD, вызываемый этим процессом).
Избавиться от этой "возможности" можно, убрав права отладки
(secpol.msc -> Local Policies -> User Rights Assignment -> Debug Programs)
Исходник прилагается, для сборки использовался Visual C 6.
CSRSS - это кусок подсистемы win32, напрямую связанный с ее реализацией в ядре - win32k.sys. Он напрямую участвует в выводе на экран этого MessageBox. Естественно, никто при разработке не планировал, что туда полезет пользователь.
А с админскими правами можно даже диск отформатировать, железо программно попортить....странно, да?
для коллекции преимущественно28.12.04 17:29 Автор: dl <Dmitry Leonov>
Человек прислал пример кода, мне он показался любопытным и поучительным, я попросил оформить как статью. Если у кого-то из посчитавших этот пример слишком очевидным найдется время и желание расписать нечто более обобщенное, я буду только рад.
с debug priveleges можно и из своего процесса bsod вызвать.27.12.04 09:29 Автор: r4dx Статус: Незарегистрированный пользователь
с debug priveleges можно и из своего процесса bsod вызвать.
например сделать WriteProcessMemory на winlogon'овсий eip (GetThreadContext+OpenThread) :P
ну или даже просто завершить winlogon (любой другой необходимый для нормальной работы сервис). даже сорс мой старый могу дать...
.data
token_priv dd 1
p_luid dq ?
szdp db "SeDebugPrivilege",0
p_token dd ?
szwin db "NDDEAgnt",0
dpid dd 0
.code
start:
invoke GetCurrentProcess
invoke OpenProcessToken, eax, 20h, o p_token
dec eax
jnz exit
invoke LookupPrivilegeValueA, eax, o szdp, o p_luid
dec eax
jnz exit
invoke AdjustTokenPrivileges, p_token, eax, o token_priv, 10h, eax, eax
invoke FindWindow, o szwin, 0
invoke GetWindowThreadProcessId, eax, o dpid
invoke OpenProcess, PROCESS_ALL_ACCESS, FALSE, dpid
invoke TerminateProcess, eax, 0
exit: invoke ExitProcess, 0
end start
Согласен, еще один способ - SetContext27.12.04 12:31 Автор: amirul <Serge> Статус: The Elderman
> С его помощью можно установить ядерный контекст в котором > винда уже не будет разбираться с виртуальной памятью и > выпадет в бсод неправда!
нельзя установить еip в context, больший чем максимальный адрес user-mode режима.
тока щазз сорс написал - не работает (все ф-ии возвращают GetLastError=0)
.data
a dd 1
lu dq 0
aaaa db "SeDebugPrivilege",0
.code
kern: jmp $
start:
xor esi, esi
push esi
callx CreateThread, esi, esi, o kern, esi, CREATE_SUSPENDED, esp
mov edi, eax
call GetCurrentProcess
callx OpenProcessToken, eax, 20h, esp
pop ebx
dec eax
jnz exit
callx LookupPrivilegeValueA, esi, o aaaa, o lu
dec eax
jnz exit
callx AdjustTokenPrivileges, ebx, esi, o a, 10h, esi, esi
or eax, eax
jz exit
sub esp, sizeof(CONTEXT)
callx GetThreadContext, edi, esp
mov [esp+CONTEXT.regEip], 0FFFFFFFFh
callx SetThreadContext, edi, esp
callx ResumeThread, edi
exit: callx ExitProcess, esi
end start
кстати - может быть будет интересно узнать (я это узнал в ходе написания этого незаурядного сорца), что advapi ф-ии требуют, чтобы их аргументы, принимающие данные находились в секции данных (не в стэке и не в секции кода с атрибутом w), а ф-ии Get/SetThreadContext, чтобы данные были в стэке %)
да уж на правду что-то непохоже03.02.05 10:32 Автор: z0 <z0> Статус: Member
> кстати - может быть будет интересно узнать (я это узнал в > ходе написания этого незаурядного сорца), что advapi ф-ии > требуют, чтобы их аргументы, принимающие данные находились > в секции данных (не в стэке и не в секции кода с атрибутом > w), а ф-ии Get/SetThreadContext, чтобы данные были в стэке > %)
бред. кусок рабочего исходника - параметры и в стеке и в коде (/SECTION:.text,erw конечное)
.code
priv_name db 'SeDebugPrivilege',0
lib_name db '\test.dll',0
kernel_name db 'kernel32',0
proc_name db 'LoadLibraryA',0
подробно о проекте
Анализ криптографических сетевых... 
