Процесс "неваляшка" без драйвера

Совершенно случайно несколько рас удовалось сделать такой процесс который не убивается не диспетчером задач не через rku, сам процесс не нагружает cpu на 100% но давольно интенсивно хавает память. Программа лоадер, проэцирует в память основной модуль игры mu online. Не моя прога, не сама игра драйверы неюзают. При загрузке в игре что-то идет не так, и получается вот такая штука. Фигово что специально эмулировать такую ошибку не удается.

Помниться Clerk писал про gdi сервис при юзании которого блокировалась память потока, возможно есть и что-то подобное при юзании которого в цикле не дает завершить процесс.

Никому про это ничего не известно?

 

Flasher
приатачится дебаггером и подебажить слегка её потоки?

 

а висяк на пайпе не судьба сделать?

 

Наверно это может быть изза блокировки(Process->RundownProtect).
Тут описано про отладчик http://j00ru.vexillium.org/?p=118.

 

В теории следующий код должен захватить блокировку и попытка завершения процесса подвесила бы вызывающий поток:

Код (Text):

1. %APIERR macro
2.     .if !Eax
3.     Int 3
4.     .endif
5. endm
6.  
7. %NTERR macro
8.     .if Eax
9.     Int 3
10.     .endif
11. endm
12.  
13. ProcessWow64Information     equ 26
14.  
15. .data
16. SynchLock       BOOLEAN FALSE
17. RaiseLock       BOOLEAN FALSE
18.  
19. .code
20. LockRoutine proc UserData:PVOID
21. Local ProcessInformation:ULONG
22. @@:
23.     cmp SynchLock,FALSE
24.     je @b
25. ;   %YIELD
26.     invoke ZwQueryInformationProcess, NtCurrentProcess, ProcessWow64Information, addr ProcessInformation, sizeof(ULONG), NULL
27.     %NTERR
28.     mov SynchLock,FALSE
29.     jmp @b
30.     ret
31. LockRoutine endp
32.  
33. WaitRoutine proc UserData:PVOID
34. Local ProcessInformation:ULONG
35. @@:
36.     cmp RaiseLock,FALSE
37.     je @b
38. ;   %YIELD
39.     invoke ZwQueryInformationProcess, NtCurrentProcess, ProcessWow64Information, addr ProcessInformation, sizeof(ULONG), NULL
40.     %NTERR
41.     mov RaiseLock,FALSE
42.     jmp @b
43.     ret
44. WaitRoutine endp
45.  
46. Entry proc
47. Local WaitThreadId:HANDLE
48. Local LockThreadId:HANDLE
49. Local LockThreadHandle:HANDLE
50. Local WaitThreadHandle:HANDLE
51. Local FreezeCount:ULONG
52.     invoke CreateThread, NULL, 0, addr WaitRoutine, 123, 0, addr WaitThreadId
53.     mov WaitThreadHandle,eax
54.     %APIERR
55.     invoke CreateThread, NULL, 0, addr LockRoutine, 123, 0, addr LockThreadId
56.     mov LockThreadHandle,eax
57.     %APIERR
58. Freeze:
59.     mov SynchLock,TRUE
60.     invoke ZwSuspendThread, LockThreadHandle, addr FreezeCount
61.     %NTERR
62.     .if FreezeCount
63.     Int 3
64.     .endif
65.    
66. ;   invoke ZwSuspendThread, WaitThreadHandle, addr FreezeCount
67. ;   %NTERR
68. ;   .if FreezeCount
69. ;   Int 3
70. ;   .endif
71. ;   invoke ZwResumeThread, WaitThreadHandle, NULL
72. ;   %NTERR
73.  
74.     mov RaiseLock,TRUE
75.     invoke Sleep, 100   ; ms
76.     cmp RaiseLock,FALSE
77.     je UnFreeze
78. @@:
79.     int 3
80.    
81. UnFreeze:
82.     invoke ZwResumeThread, LockThreadHandle, NULL
83.     %NTERR
84. @@:
85.     cmp SynchLock,FALSE
86.     jne @b
87.     jmp Freeze
88.     ret
89. Entry endp

Этого не происходит, не понятно почему.

 

Clerk

скинь пожалуйста бинарик, нет возможности собрать, потещу на разных системах.
сам пробуеш наверно на 7 с последними апдейтами, а там мож фиксанули

 

wsd
У меня XP. Многие действия выполняются ядром с захваченными блокировками EPROCESS.RundownProtect и ETHREAD.RundownProtect. Это перечисление потоков и пр. Тотже NtResumeProcess(в семпле я использовал ProcessWow64Information) захватывает блокировку и исполняется на нулевом IRQL, при этом можно доставить суспенд-апк, тоесть это атака типо race condition. Тогда после захвата блокировки поток будет остановлен, другой поток попытавшийся захватить блокировку будет ждать её освобождения. Это и происходит при завершении процесса. Позже посмотрю почему не работает, хотя должно.

 

Clerk
если чё ща могу на xp32sp2, v64sp1, v32sp1 всё без апдейтов

 

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

 

Тоже как то у меня был случай не "убиваемых " процессов.
Вообще программа работала с кучей СОМ портов, и потом в конце работы программы когда она закрывала дексрипторы СОМ порта то на каждые 200-300 закрытий обязательно программа подвисала на CloseHandle(hCOM) .
Ее через диспетчер нельзя было снять и через ProcessExplorer(от Русиновича).
Если программа была под отладкой то и отладчик вис.

Помогала только перезагрузка, или отключение всех устройств от СОМ порта.
Я тогда всю вину свел на драйвера...

Да и где то тут показывал минимальный код который так себя ведет, но помощи так и не было( .
Ага вот он:http://wasm.ru/forum/viewtopic.php?id=32428
Смысл сводится к тому что если открывать/закрывать один СОМ порт то все ок.
Когда открываем/закрываем несколько СОМ портов начинаются подвисания ...

 

wsd
Разобрался. Как оказалось вызов для синхронизации ExAcquireRundownProtection (&Process->RundownProtect) абсолютно бесполезен, изза не верной реализации блокировки.

 

Clerk
а работающий семпл уже есть?

 

wsd
Не нашёл есчо пока способа.
Flasher
Можите больше инфы дать. Или есчо лучше потрейсить NtTerminateProcess ?