2010-02-19 17 views
5

Esto es extraño. Anteriormente, al ejecutar Windows 7 x64, tuve problemas para llamar al Win32 OpenProcess contra los procesos de 64 bits. Busqué un poco en Google y llegué a la conclusión de que esto no iba a suceder.OpenProcess en imágenes x64 desde la aplicación Win32

Luego sucedió algo gracioso. Lo intenté contra la identificación del proceso para explorer.exe, y holy carp, ¡funcionó! Comencé a arrojar otros ID de proceso en él, y es solo un zurrón maldito.

Como resultado, puedo llamar OpenProcess contra un buen número de procesos x64 - explorador, tipoi, ipoint, taskhost, cmd, mstsc, ..., etc.

Y otros pop a 5 (Acceso denegado) - winlogon, csrss, servicios, svchost, mdm, ...

Estoy confirmando el "bitness" y el ID del proceso usando Process Explorer. Además, llamar a GetModuleFileNameEx en procesos de 64 bits siempre falla, por lo que ofrece una doble verificación para 32/64.

Este es el código:

' Get a handle to the process. 
hProcess = OpenProcess(PROCESS_QUERY_INFORMATION Or PROCESS_VM_READ, 0, ProcessID) 
If hProcess Then 
    ' Grab the filename for base module. 
    nChars = GetModuleFileNameEx(hProcess, 0, Buffer, Len(Buffer)) 
    ' If running in x64, http://winprogger.com/?p=26 
    If Err.LastDllError = ERROR_PARTIAL_COPY Then 
     nChars = GetProcessImageFileName(hProcess, Buffer, Len(Buffer)) 
    End If 
    ' Truncate and return buffer. 
    If nChars Then 
     GetProcessFileName = Left$(Buffer, nChars) 
    End If 
    Call CloseHandle(hProcess) 
Else 
    Debug.Print "LastDllError:"; Err.LastDllError 
End If 

No es nada especial. Solo quiero consultar los procesos para cosas como nombre de archivo o tiempos de proceso. Alguien tiene alguna idea de lo que diferencia entre los que puedo abrir y los que no puedo?

Información adicional: proceso en ejecución como administrador. UAC apagado. Sí, es una aplicación de 32 bits. No obtuve mejores resultados con PROCESS_QUERY_LIMITED_INFORMATION.

Gracias ... Karl

Respuesta

4

Los procesos que usted citó (winlogon, csrss, etc.) son los procesos y servicios críticos del sistema. Se ejecutan bajo una cuenta diferente y privilegiada. Aunque se ejecuta como administrador, no es el propietario de esos procesos y, por lo tanto, no se le otorgan derechos sobre su ACL. Intentar abrir dará como resultado el acceso denegado.

Sin embargo, los miembros del grupo de administradores tienen SeDebugPrivilege. Esto es básicamente una anulación en OpenProcess y OpenThread que le permitirá abrir todos los accesos, incluso si no se le concede ningún permiso en la ACL.

SeDebugPrivilege es, obviamente, un privilegio muy peligroso: puede omitir las comprobaciones de acceso y modificar/inspeccionar los procesos de otros usuarios. Si bien está presente en un token de administrador de forma predeterminada, no está habilitado de forma predeterminada. Debe habilitar este privilegio antes de llamar a OpenProcess.

Este MSDN article proporciona un código de muestra sobre cómo habilitar y deshabilitar los privilegios en su token.

+0

Ouch. Sí, eso fue todo, está bien. Eso también permitió GetProcessTimes veces. Veo que Process Explorer se está ejecutando con esa configuración, también. Entonces, si tuviera que ejecutar eso en una cuenta de usuario menos privilegiada, ¿no podría estar haciendo esto tampoco? De todos modos, gracias! :-) –

+1

Pocos grupos tienen SeDebugPrivilege por defecto, básicamente solo SYSTEM y el grupo de administradores. Los usuarios menos privilegiados definitivamente no lo hacen. Si lo hicieran, elevar a privilegio total sería trivial ya que puede inyectar el código que desea ejecutar en un proceso privilegiado. – Michael

+0

Antes de llegar a esta publicación, pensé que tendría que hacer compilaciones por separado en mi escenario pero gracias a SeDebugPrivilege, ahora puedo llamar a openprocess desde un proceso de 32 bits y cargar un proceso de 64 bits en mi caso sin poder cargar lsass. – Syler

Cuestiones relacionadas