2010-02-19 12 views
5

Questo è strano. In precedenza, eseguendo Windows 7 x64, avevo problemi a chiamare Win32 OpenProcess contro i processi a 64 bit. Ho cercato su Google un po 'e sono giunto alla conclusione che questo non sarebbe successo.OpenProcess su immagini x64 dall'app Win32

Poi è successo qualcosa di divertente. Ho provato contro l'ID di processo per explorer.exe e carpa santa, ha funzionato! Iniziato a lanciare altri ID di processo, ed è solo un dannato crapshoot.

Come si è visto, posso chiamare OpenProcess contro un buon numero di processi x64 - esploratore, itype, iPoint, taskhost, cmd, mstsc, ..., ecc

E altri pop a 5 (Accesso negato) - winlogon, csrss, services, svchost, mdm, ...

Sto confermando il "testimone" e l'ID del processo utilizzando Process Explorer. Inoltre, chiamare GetModuleFileNameEx nei processi a 64 bit non riesce sempre, quindi offre un doppio controllo per 32/64.

Questo è il codice:

' 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 

Niente di speciale. Voglio solo interrogare i processi per cose come il nome del file o i tempi del processo. Qualcuno ha idea di cosa si distingue tra quelli che posso aprire e quelli che non posso?

Ulteriori informazioni: processo in esecuzione come amministratore. UAC disattivato. Sì, è un'app a 32 bit. Non ho ottenuto risultati migliori con PROCESS_QUERY_LIMITED_INFORMATION.

Grazie ... Karl

risposta

4

I processi da lei citato (winlogon, CSRSS, etc.) sono processi e dei servizi di sistema critici. Corrono con un account diverso e privilegiato. Anche se si esegue come amministratore, non si è il proprietario di tali processi e quindi non si concedono diritti nel proprio ACL. Tentare di aprire comporterà l'accesso negato.

Tuttavia, i membri del gruppo degli amministratori hanno SeDebugPrivilege. Questo è fondamentalmente un override su OpenProcess e OpenThread che ti permetterà di aprire per tutti gli accessi, anche se non ti è stata concessa alcuna autorizzazione nell'ACL.

SeDebugPrivilege è ovviamente un privilegio molto pericoloso avere: è possibile ignorare i controlli di accesso e modificare/ispezionare i processi di altri utenti. Sebbene sia presente nel token di un amministratore per impostazione predefinita, non è abilitato per impostazione predefinita. È necessario abilitare questo privilegio prima di chiamare OpenProcess.

Questo MSDN article fornisce codice di esempio su come abilitare e disabilitare i privilegi nel token.

+0

Ouch. Sì, era così, va bene. Questo ha permesso di ottenere tempi di GetProcessTimes. Vedo Process Explorer è in esecuzione con quella impostazione, anche. Quindi, se dovessi eseguirlo con un account utente meno-privato, non potrebbe farlo anche questo? Comunque, grazie! :-) –

+1

Pochi gruppi hanno SeDebugPrivilege di default, fondamentalmente solo SYSTEM e il gruppo degli amministratori. Gli utenti meno privilegiati sicuramente non lo fanno. Se lo facessero, elevare al pieno privilegio sarebbe banale dato che è possibile iniettare il codice che si desidera eseguire in un processo privilegiato. – Michael

+0

Prima di venire a questo post, ho pensato che avrei dovuto creare build separate nel mio scenario ma grazie a SeDebugPrivilege, ora posso chiamare openprocess da un processo a 32 bit e caricare un processo a 64 bit nel mio caso in grado di caricare lsass. – Syler