Prozesse oder Anwendungen ermitteln, die eine Datei benutzen

[daPimP]

Habe mir mal die Funktionen von Unlocker
und auch von WhoLockme angeschaut, da beide Programme ähnlich arbeiten. (Links dazu oben)

Habe mal die Funktionen aufgelistet, die beide gemeinsam haben und mir entweder so nichts sagen
oder die speziell mit dem Problem: Welcher Prozess blockt die Datei?, zu tun haben.

Das sind die Parallelen, die BEIDE Programme haben und wohl am Auslesen beteiligt sind.

Delphi-Quellcode:

GetFileAttributes
GetModuleHandle
GetProcAddress

kenn ich nicht - hab ich aber auch noch nicht nachgeschlagen:

Delphi-Quellcode:

DisableThreadLibraryCalls
InterlockedIncrement
InterlockedDecrement

So, hab noch zu tun - aber vielleicht hat ja noch jemand nen Hinweis auf die weitere Bearbeitung des Problems.

[Mackhack]

Hallo,

weis eigentlich jemand genaueres wie dieses Programm funktioniert?

[Zacherl]

GetProcAddress und GetModuleHandle kannst du rauslassen, da sie nur dazu dienen andere Funktionen zu importieren. Somit müsstest du im Debugger genau nachsehen, welche Funktionen das sind. Es können theoretisch alle APIs sein. GetFileAttributes ist denke ich auch keine der Schlüsselfunktionen.

[himitsu]

Die Interlocked-Funktionen fallen auch raus (das sind im Grunde nur die threadsicheren versionen von Inc und Dec)
und DisableThreadLibraryCalls hat nichts Dateien zu tun.

Bleibt dir also wirklich nur mitzuverfolgen welche Funktionen/Prozeduren von GetProcAddress importiert werden.

[EgoFelix]

Hab da was gefunden, was euch vielleicht etwas weiterbringen kann.
Vielleicht setz ich mich auch mal dran

http://www.codeguru.com/Cpp/W-P/file...cle.php/c1287/

Jetzt müsstet ihr noch die Funktion raussuchen, welche die Handles eines Programmes anzeigen kann. Dann könntet ihr diese auch Schliessen.

Kleine Anmerkung:
Wenn ihr es macht, dass ihr die Handles bekommt, dann könnt ihr auch direkt über das Handle die Datei auslesen!

MfG

Felix

[Christian Seehase]

Moin Felix,

erst einmal herzlich willkommen hier in der Delphi-PRAXiS.

Nur mal interessehalber:
Hast Du den Codeabschnitt auf den Dein Link verweist mal unter Vista ausprobiert?
Da dort die Startadressen der DLLs nicht mehr immer an der gleichen Stelle liegen sollen, dürfte es dort eigentlich nicht mehr funktionieren, da sich dadurch ja die Startadresse der Kernel32.dll, und somit auch die der enthaltenen Funktionen verschieben, womit dann die Adresse von CloseHandle im eigenen Prozess eine andere ist als die im Remote-Prozess.

[Olli]

Ich bin sicher sowohl andere Treiber als auch andere Prozesse werden es wirklich schätzen, wenn ihnen der Boden (lies: Handle) unter den Füssen weggezogen wird. Weiter so

Interessanter sind übrigens die Funktionen welche sie nicht gemeinsam haben

[daPimP]

Zitat:

Interessanter sind übrigens die Funktionen welche sie nicht gemeinsam haben

@OLLI: Verstehe deine Anspielung nicht ganz...

Im übrigen ist der Link doch wirklich hilfreich.
Da ich selbst wenig mit C zu tun habe, bin ich nicht in der Lage ihn 1:1 zu übersetzen.

Ich brauche eigentlich nur eine Liste ALLER Dateien (nicht nur die Module...)
vom Prozess XY, die momentan verwendet werden.



Wie gehts weiter?
Ich hab alle PIDs und TIDs und alle Rechte und mir reicht wenn es auf XP läuft.

[daPimP]

Da mir das Thema nicht aus dem Kopf geht, werde ich in geraumer Zeit einige Fortschritte hier posten,
hoffe das wir der Lsg dann Näher kommen.

Ich halte nochmal fest:

ZIEL: eine X-beliebige Datei (nicht nur dll, exe) soll überprüft werden, von welchem Prozess
sie gerade benutzt wird.


AUFGABE: Ermitteln des HANDLE der Datei (und ich rede hier nicht von den Fensterhandles)

Verwirklicht wurde das schon im Programm Unlocker und im C++ SourceCode codeguru.com

Desweiteren ist das bloße Anzeigen des speziellen Handles definiv ONHE Treiberdatei möglich.
(im Gegensatz zu Unlocker)

Es reicht wenn es unter XP läuft.

FORTSCHRITT:
meine Delphi Übersetzung:

Hier soll ein Prozess per PID überprüft werden, und ALLE seine Handleverknüpfungen angezeigt werden.
Ich bekomme auch eine Zahl, die im Bereich der Handles liegt zurück, kann sie aber nicht zuordnen.

Delphi-Quellcode:

(*
Note: 1. SE_DEBUG privilege must be enabled.                   OK
      2. The function works with every kind of HANDLE
      3. It will bother the remote process :)
      4. The handles will be invalid after you closed          OK
         them remotely
*)

function CloseRemoteHandle(processID: DWORD; lpparameter: pointer ):DWORD;
var
  ht :THANDLE;
  rc : DWORD;
  hProcess: THandle;
  hKernel32: cardinal;
begin
 TRY
 lpparameter:= nil;
   ht:=0;
   rc:=0;
   // open the process
   HPROcESS:= OpenProcess(PROCESS_CREATE_THREAD
                                or PROCESS_VM_OPERATION
                                or PROCESS_VM_WRITE
                                or PROCESS_VM_READ, FALSE, processID);
   if  hProcess = 0 then
     showmessage('hprocess ist null'); //tritt nicht ein

   // load kernel32.dll
   hKernel32 := LoadLibrary('kernel32.dll');

   // CreateRemoteThread()
   ht := CreateRemoteThread(
   hProcess,
   0,
   0,
   GetProcAddress(hKernel32, 'CloseHandle'),
   lpparameter,        //////was mach ich hiermit?????
   0,
   rc ); 

    if  ht =0 then begin
     rc := GetLastError();
     showmessage('ht ist null');               //tritt nicht ein
   end;

   case WaitForSingleObject(ht, 2000) of
     WAIT_OBJECT_0:  begin  end;               //OK
   else
     rc := GetLastError();                     //tritt nicht ein
     showmessage('Fehler WaitForSingle:');
   end;
 FINALLY
  result:= rc;      
  showmessage('rc  :'+ inttostr(rc)+'  ht  :'+ inttostr(ht))  //zum Anzeigen der Werte

  CloseHandle(ht);

  //Free up the kernel32.dll
  if  hKernel32 <> 0 then
    FreeLibrary(hKernel32);

  CloseHandle(hProcess);
 END;
end;


procedure Tform1.Button1Click(Sender: TObject);      
var PID: cardinal;
begin
 PID:= ....;
 CloseRemoteHandle(PID, 0);  //die null is auch nicht astrein...
end;

der Original C++ Code

Delphi-Quellcode:

/*
Note: 1. SE_DEBUG privilege must be enabled.
      2. The function works with every kind of HANDLE
      3. It will bother the remote process :)
      4. The handles will be invalid after you closed
         them remotely
*/

//Close a handle in a remote process
DWORD CloseRemoteHandle( DWORD processID, HANDLE handle )
{
 HANDLE ht = 0;
 DWORD rc = 0;

 _tprintf( _T("Closing handle in process #%d ... "),
          processID );

 // open the process
 HANDLE hProcess = OpenProcess( PROCESS_CREATE_THREAD
                                | PROCESS_VM_OPERATION
                                | PROCESS_VM_WRITE
                                | PROCESS_VM_READ,
                                FALSE, processID );

 if ( hProcess == NULL )
 {
  rc = GetLastError();
  _tprintf( _T("OpenProcess() failed\n") );
  return rc;
 }

 // load kernel32.dll
 HMODULE hKernel32 = LoadLibrary( _T("kernel32.dll") );

 // CreateRemoteThread()
 ht = CreateRemoteThread(
  hProcess,
  0,
  0,
  (DWORD(__stdcall *)(void*))GetProcAddress(hKernel32,"CloseHandle"),
  handle,
  0,
  &rc );

 if ( ht == NULL )
 {
  //Something is wrong with the privileges,
  //or the process doesn't like us
  rc = GetLastError();
  _tprintf( _T("CreateRemoteThread() failed\n") );
  goto cleanup;
 }

 switch ( WaitForSingleObject( ht, 2000 ) )
 {
  case WAIT_OBJECT_0:
   //Well done
   rc = 0;
   _tprintf( _T("Ok\n"), rc );
  break;

  default:
   //Oooops, shouldn't be here
   rc = GetLastError();
   _tprintf( _T("WaitForSingleObject() failed\n") );
   goto cleanup;
  break;
 }

 cleanup:
 //Closes the remote thread handle
 CloseHandle( ht );

 //Free up the kernel32.dll
 if ( hKernel32 != NULL)
  FreeLibrary( hKernel32 );

 //Close the process handle
 CloseHandle( hProcess );

 return rc;
}

FRAGE: Ist die Übersetzung soweit in Ordnung? Irgendwelche konstruktiven Anregungen?

[Apollonius]

Warum hast du den zweiten Parameter von einem Handle zu einem Pointer gemacht?