2010-02-19 7 views
5

Das ist seltsam. Früher, mit Windows 7 x64, hatte ich Probleme beim Aufruf des Win32 OpenProcess gegen 64-Bit-Prozesse. Etwas herumgegoogelt und zu dem sinkenden Schluss gekommen, dass das einfach nicht passieren würde.OpenProcess auf x64 Bilder von Win32 App

Dann ist eine lustige Sache passiert. Ich versuchte es gegen die Prozess-ID für explorer.exe und heiligen Karpfen, es hat funktioniert! Habe angefangen, andere Prozess-IDs darauf zu werfen, und es ist nur ein verdammtes Crapshoot.

Wie sich herausstellt, kann ich Open gegen eine gute Anzahl von x64 Prozesse nennen - Explorer, ITYPE, ipoint, taskhost, cmd, mstsc, ... usw.

Und andere Pop-5 (Zugriff wird verweigert) - winlogon, csrss, services, svchost, mdm, ...

Ich bestätige die "Bitness" und Prozess-ID mit Process Explorer. Darüber hinaus schlägt das Aufrufen von GetModuleFileNameEx für 64-Bit-Prozesse immer fehl, so dass das eine Überprüfung für 32/64 bietet.

Dies ist der Code:

' 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 

Nichts Besonderes. Ich möchte nur die Prozesse für Dinge wie Dateiname oder Prozesszeiten abfragen. Hat jemand eine Idee, was unterscheidet zwischen denen, die ich öffnen kann und denen, die ich nicht kann?

Zusätzliche Informationen: Laufender Prozess als Administrator. UAC wurde deaktiviert. Ja, es ist eine 32-Bit-App. Ich hatte keine besseren Ergebnisse mit PROCESS_QUERY_LIMITED_INFORMATION.

Dank ... Karl

Antwort

4

Die Prozesse, die Sie zitiert (winlogon, csrss, etc.) sind wichtige Systemprozesse und Dienstleistungen. Sie laufen unter einem anderen, privilegierten Konto. Obwohl Sie als Administrator ausgeführt werden, sind Sie nicht der Eigentümer dieser Prozesse und Sie erhalten daher keine Rechte in ihrer ACL. Wenn versucht wird, geöffnet zu werden, wird der Zugriff verweigert.

Mitglieder der Gruppe Administratoren haben jedoch SeDebugPrivilege. Dies ist im Grunde eine Überschreibung für OpenProcess und OpenThread, mit der Sie für alle Zugriffe öffnen können, auch wenn Sie keine Berechtigung in der ACL erhalten.

SeDebugPrivilege ist offensichtlich ein sehr gefährliches Privileg - Sie können Zugriffsprüfungen umgehen und die Prozesse anderer Benutzer ändern oder prüfen. Obwohl es standardmäßig in einem Token eines Administrators vorhanden ist, ist es standardmäßig nicht aktiviert. Sie müssen diese Berechtigung aktivieren, bevor Sie OpenProcess aufrufen.

Diese MSDN article gibt Beispielcode zum Aktivieren und Deaktivieren von Berechtigungen in Ihrem Token.

+0

Autsch. Ja, das war's, in Ordnung. Das hat GetProcessTimes auch mal aktiviert. Ich sehe, dass Process Explorer mit dieser Einstellung ausgeführt wird. Also, wenn ich das unter einem privilegierten Benutzerkonto ausführen würde, könnte es das auch nicht tun? Wie auch immer, danke! :-) –

+1

Wenige Gruppen haben SeDebugPrivilege standardmäßig, im Grunde nur SYSTEM und die Gruppe Administratoren. Am wenigsten privilegierte Benutzer tun das definitiv nicht. Wenn dies der Fall wäre, wäre die Erhöhung auf volle Berechtigungen trivial, da Sie Code injizieren können, der in einem privilegierten Prozess ausgeführt werden soll. – Michael

+0

Bevor ich zu diesem Post kam, dachte ich, dass ich separate Builds in meinem Szenario machen müsste, aber dank SeDebugPrivilege kann ich openprocess jetzt aus einem 32bit Prozess aufrufen und einen 64bit Prozess laden, der lsass laden kann. – Syler

Verwandte Themen