Auf Dateien zugreifen die gerade in Gebracuh sind (?)

[buster55]

Hallo Delphi-''Piraxikanten'' :wink:
Meine Frage ist eigentlich ganz einfach, ich möchte mit einem Delphi Programm auf Dateien zugreifen die gerade von anderen Programmen in Benutzung sind.
Windows selbst kann das ja nicht, wenn man eine Datei die gerade beuntzt wird, ausführen oder kopieren will kommt ein Fehler.
In meinem Fall möchte ich die Datei kopieren (wie das mit normalen Dateien geht ist mit natürlich klar).
Unmöglich ist das nicht, es gibt ein Programm (ist bestimmt nicht das einzige) das solche Dateien kopieren, löschen, etc. kann, es nennt dich ''Unlocker'' (siehe: http://www.chip.de/downloads/Unlocker_18414122.html)

Nun meine Frage sollte klar sein :-D

Probiert hab ich schon alles mögliche (Normale Artundweise, Datei in einen Stream laden, etc.) :roll:

Hab echte keine Ideen mehr :coder2:


Grüße
buster
:duck:

[Apollonius]

Ich vermute mal, dass Unlocker dem anderen Programm das Handle unter den Füßen wegzieht. Es gibt keine gute Möglichkeit, dein Problem zu lösen, jedoch eine Reihe von schlechten (folgende Liste ist ohne Anspruch auf Vollständigkeit):
1. CreateFile hooken und FILE_SHARE_READ zum dritten Parameter hinzu-or-en. Du solltest jedoch bedenken, dass sich der Programmierer des "Feind"-Programms etwas dabei gedacht haben könnte, als er dieses Flag nicht gesetzt hat.
2. Einen Thread in das andere Programm injizieren, und von dort aus mit dem entsprechenden Handle lesen. Das funktioniert jedoch nur, wenn im anderen Programm bei CreateFile auch Lesezugriff und nicht nur Schreibzugriff beantragt wurde. Richtig hässlich wird es, wenn die Datei nicht overlapped geöffnet wurde. Dann musst du nämlich manuell den Dateizeiger versetzen. Dabei gibt es dann eine Race Condition.

[taaktaak]

Moin, Moin.
Und wie wäre es, am Dateisystem vorbei, direkt auf die Sektoren der Festplatte zuzugreifen? Das müsste doch möglich sein. Ich meine mich erinnern zu könne das vor langer Zeit, als alles noch viel einfacher war, mal unter TurboPascal gemacht zu haben. Würde aber wohl bedeuten, mit Assembler zu arbeiten, oder?

[Apollonius]

Assembler bräuchtest du dafür nicht. Windows stellt eigentlich für alles entsprechende Funktionen bereit, damit Treiber-Programmierer nicht CPU-abhängig programmieren müssen. Allerdings sind diese speziellen Funktionen im Usermode tabu.
Dennoch hast du Recht. Man kann mit den ganz normalen Dateifunktionen direkt auf das physikalische Laufwerk zugreifen. Dass man dafür Administrator-Rechte benötigt, sollte klar sein. Das größere Problem dürfte allerdings sein, sich auf der Festplatte zurechtzufinden.

[SirThornberry]

Man kann auch ohne Assembler mit entsprechenden Rechten direkt vom Datenräger lesen. Allerdings muss man dann wissen wie das Dateisystem aufgebaut ist und die Dateien sind auch nicht grundlos gesperrt. Angenommen Programmx will 100 Byte in eine Datei schreiben und gerade als es 50 Byte davon geschrieben hat, kopiere ich die Datei. Resultat ist Datenmüll weil ich weder die Ursprüngliche Version der Datei habe noch die neue sondern eine Mischung aus beiden.

[taaktaak]

Interessant.
Aber wie du schon sagst, selbst wenn Windows entsprechende Funktionen bereitstellt: Das Zurechtfinden stelle ich mir sehr aufwendig vor. Kenne mich heute nicht mehr aus, so einfach wie damals mit den FAT's ist es sicherlich nicht mehr. Man müsste doch sicherlich auch selbst auf die verschiedenen möglichen Dateisysteme reagieren, das kann Windows dem Programmierer doch nicht abnehmen?!

// roter Kasten: Ja, das ist natürlich ein absolut überzeugender Hinweis.

[SirThornberry]

Windows nimmt dem Programmierer das ja ab in dem es Funktionen wie OpenFile etc. bereit stellt. Aber eben diese will man ja nicht verwenden weil diese eine Sperrung der Dateien berücksichtigen.

[taaktaak]

That's what I mean!
Ich muss Funktionen verwenden, die direkt auf Sektor xy etc, zugreifen. Die Interpretation der gelesenen Daten ist vom Dateisystem abhängig. Die Informationen muss der Programmierer dann ohne Windows-Hilfe analysieren und verwenden. Oder habe ich Apollonius jetzt falsch verstanden?

[Apollonius]

Mich hast du richtig verstanden. Die Frage ist, ob ich das PSDK richtig verstanden habe. :wink:

[taaktaak]

Nun gut - dann warten wir mal ab, welchen Schluß der TE aus der Diskussion zieht :hi:

[grenzgaenger]

Zitat:

Zitat von taaktaak

Moin, Moin.
Und wie wäre es, am Dateisystem vorbei, direkt auf die Sektoren der Festplatte zuzugreifen? Das müsste doch möglich sein. Ich meine mich erinnern zu könne das vor langer Zeit, als alles noch viel einfacher war, mal unter TurboPascal gemacht zu haben. Würde aber wohl bedeuten, mit Assembler zu arbeiten, oder?

dort brauchte man noch nicht tricksen... der sperrmechanismus kam erst viel später ... für meinen geschmack, viel zu spät ...

möcht aber warnen, das unter den füssen wegziehen, kann ziemlich üble konsequenzen haben... solltest noch mal drüber nachdenken, ob du das wirklich machen willst...

[himitsu]

nja, man könnte sich ja mal sowas wie einen "intelligenten" Unlogger selbst bauen ... statt das gewünschte Filehandle einfach "brutal" zu schließen, könnte man entweder

a) das Filehandle klonen und darüber zugriff bekommen

b) die Zugriffsrechte ändern

[buster55]

schön das schon so viele geantowortet haben,
könnte mir jedoch jemand mal konkretere Codebeispiele geben, da ich mir noch die handels irgendwelcher Dateien aneigen wollte,
was die gefählichkeit angeht, keine Sorge die Sache bezieht sich auf harmlose Mulimedia Dateien

[himitsu]

willst du dir die Dateien nur ansehn, wärend sie andersweitig geöffnet sind (z.B. noch beim Runterladen oder so)?

versuch einfach mal den VLC-Player
(des Schrottteil bringt bei mir zwar fast regelmäßig den PC zum verrecken, aber angeblich soll der ja sooo super sein und der öffnet fast alles)

[runner]

ich habs zwar nicht getestet, aber wenn Du die Datei nur kopieren willst müsste das auch so gehen:

Delphi-Quellcode:

procedure LoadFromFileEX(const FileName, NewFile: string);
var
  Stream: TStream;
  StrBuf: TStrings;
begin
  StrBuf := TStringList.Create;
  Stream := TFileStream.Create(FileName, fmOpenRead or fmShareDenyNone);
  try
    StrBuf.LoadFromStream(Stream);
    StrBuf.SaveToFile(NewFile);
  finally
    Stream.Free;
    StrBuf.Free;
  end;
end;

[buster55]

Delphi-Quellcode:

---------------------------
Debugger Exception Notification
---------------------------
Project Project1.exe raised exception class EFOpenError with message 'Cannot open file "C:\test.xxx". Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird'. Process stopped. Use Step or Run to continue.
---------------------------
OK   Help   
---------------------------

Das sagt wohl alles :wall:
trotzdem Danke :zwinker: :thumb:

Achja das mit dem VLC ist mir schon klar das ist auch mein Standart Player, allerdings geht es mir darum das mein Tool das kann und nicht der VLC (wenn er es könnte) :wink:

Weitere Ideen :stupid: ?

[himitsu]

durch was sind denn die Dateien noch geöffnet?

bzw. wäre es Schlimm, wenn dem anderem Programm sämtlicher Zugriff genommen würde ....... ?

[buster55]

1. Das ist unterschiedlich, in den meisten Fällen ein Browser.
2. nein wäre es nicht!

[buster55]

:spin2: :spin2: :spin2: :spin2: :spin2: :spin2:
:drunken: :dancer: PUSH! :dancer: :drunken:
:spin2: :spin2: :spin2: :spin2: :spin2: :spin2:

[nat]

also ich hab mir das prog ma eben installiert (sowas is manchmal doch ganz praktisch - hatte so ein ähnliches tool schonmal drauf).
wenn man sich die dateien im install-dir ma anguckt, dann sieht das wohl so aus, als ob die n extra treiber dafür verwenden.
scheint also nicht "mal eben so einfach" zu sein ^^
wenn jmd genauer weiß wie das funktioniert würde es mit aber trotzdem interessieren
(eher aus neugier als aus irgendeinem praktikablen grund *g*)

dateiliste:
http://www8.picfront.org/picture/RTK59juw/img/4673.jpg

[nicodex]

Der Treiber löst eines der Hauptprobleme, die im Benutzermodus nicht sauber zu lösen sind. Mittels ObReferenceObjectByHandle, ObQueryNameString und ObDereferenceObject wird der Objektname zu einem Handle ermittelt.

[Fridolin Walther]

Das Ganze lässt sich teilweise auch im Usermode sauber lösen, sofern man nicht versucht die Namen von Handles aufzulösen, die bestimmte Access Flags gesetzt haben. Solang man also aufpasst was man dort tut, ist also auch das kein Problem.

[Luckie]

Zitat:

Zitat von 0xF30FC7

sofern man nicht versucht die Namen von Handles aufzulösen, die bestimmte Access Flags gesetzt haben.

Aber das ist ja Sinn und Zweck der Übung. Was will ich mit irgendwelchen Zahlenkolonen, die mir nichts sagen? Ich mache das ja extra um den Namen zu bekommen.

[Fridolin Walther]

Die Handles mit den entsprechenden Access Flags sind im Normalfall nur Named Pipes. Bedeutet bei "echten" Datei Handles kannst Du die Namen durchaus auflösen. Nur an die Namen von Named Pipes kommst Du halt nicht ran, was im hier gefragten Szenario aber nicht von Bedeutung ist. Und auch bei Named Pipes sind es nur eine gewisse Teilmenge an Handles die Du nicht auflösen kannst.

[Luckie]

Kann man das irgendwie vor der Namesauflösung unterscheiden?

Ich habe hier mal etwas probiert: http://www.michael-puff.de/Developer...leUnlocker.zip Zur Zeit werdenn erstmal nur die Dateiene aufgelistet und bei den obengenannten Fällen, bleibt das Programm hängen. Wenn man das verhindern könnte, in dem man in den Fällen die Namen nicht abfragt, wäre das super.

[Fridolin Walther]

Ja, an den Access Flags wie gesagt. Wenns Dich interessiert ... ich hab das mal implementiert. Kann Dir da einen Sample Code zukommen lassen :).

[Luckie]

Zitat:

Zitat von 0xF30FC7

Ja, an den Access Flags wie gesagt. Wenns Dich interessiert ... ich hab das mal implementiert. Kann Dir da einen Sample Code zukommen lassen :).

Gut. Aber poste das das hier imForum, dannhaben alle was davon und Nico kann auch noch mal drübergucken.

[Fridolin Walther]

Zitat:

Zitat von Luckie

Ich habe hier mal etwas probiert: http://www.michael-puff.de/Developer...leUnlocker.zip Zur Zeit werdenn erstmal nur die Dateiene aufgelistet und bei den obengenannten Fällen, bleibt das Programm hängen. Wenn man das verhindern könnte, in dem man in den Fällen die Namen nicht abfragt, wäre das super.

2 Hinweise:

1. Check ob GrantedAccess beim Handle <> $12019f. File Handles mit der Access Mask 0x12019f sind letztlich die, die dafür sorgen das Du hängst.
2. RemoteCloseHandle ist unvorteilhaft implementiert. Um ein Handle im Zielprozess zu schließen, duplizier das Handle mit dem Flag DUPLICATE_CLOSE_SOURCE. Das sorgt dafür, das das Handle im Remote Prozess geschlossen wirst, sobald Du es in Deinem Prozess schließt.

[Fridolin Walther]

Wie versprochen der Code. Es sollten keine Lock Ups produziert werden. Angezeigt werden alle Object Names aller Handles, sofern diese verfügbar sind. Das sind nicht nur Namen von geöffneten Dateien sondern auch die Namen von Memory Mapped Files, Mutexes, Registry Keys etc.. Wenn man nur eine bestimmte Art von Handle haben möchte, liesse sich das allerdings filtern. Würde den Beispiel Quellcode nur unnötig komplex machen :).

Delphi-Quellcode:

program lon;

{$APPTYPE CONSOLE}

uses
  JwaWinType,
  JwaWinNT,
  JwaWinBase,
  JwaNtStatus,
  JwaNative,
  TlHelp32,
  sysutils;

procedure NTSetPrivilege(Privilege: string; Enabled: Boolean);
var
  Token: THandle;
  TokenPriv: TOKEN_PRIVILEGES;
  PrevTokenPriv: TOKEN_PRIVILEGES;
  ReturnLength: Cardinal;
begin
  if OpenProcessToken(GetCurrentProcess(), TOKEN_ADJUST_PRIVILEGES or TOKEN_QUERY, Token) then
    try
      if LookupPrivilegeValue(nil, PChar(Privilege), TokenPriv.Privileges[0].Luid) then
        begin
          TokenPriv.PrivilegeCount := 1;

          case Enabled of
            True: TokenPriv.Privileges[0].Attributes  := SE_PRIVILEGE_ENABLED;
            False: TokenPriv.Privileges[0].Attributes := 0;
          end;

          ReturnLength := 0;
          PrevTokenPriv := TokenPriv;

          AdjustTokenPrivileges(Token, False, @TokenPriv, SizeOf(PrevTokenPriv), @PrevTokenPriv, @ReturnLength);
      end;
    finally
      CloseHandle(Token);
    end;
end;

procedure ListAllHandleNames;
const
  MaximumHandleCount = 100000;
var
  Buffer : Pointer;
  MemoryNeeded : ULong;
  Unused : ULong;
  HandleInformation : PSystemHandleInformation;
  HandleCount : PULong;
  ObjectName : PObjectNameInformation;
  LocalHandle : THandle;
  ProcessHandle : THandle;
  ObjectString : string;
  i : Integer;
begin

  // Initialisierung
  MemoryNeeded := MaximumHandleCount * SizeOf(TSystemHandleInformation);

  // Handle Liste holen
  GetMem(Buffer, MemoryNeeded);
  if not NT_SUCCESS(NtQuerySystemInformation(SystemHandleInformation, Buffer, MemoryNeeded, nil)) then
    begin
      writeln('NtQuerySystemInformation fehlgeschlagen (Handle Array zu klein?).');
      FreeMem(Buffer);
      Exit;
    end;

  HandleCount := Buffer;
  HandleInformation := Pointer(LongWord(Buffer) + 4);
  for i := 0 to HandleCount^ - 1 do
    begin
      ProcessHandle := OpenProcess(PROCESS_DUP_HANDLE, false, HandleInformation^.ProcessId);
      if ProcessHandle <> 0  then
        begin
          // Spezielle Named Pipes machen Probleme bei der Abfrage. Diese Pipes haben
          // als Access Mask 0x12019F. Entsprechend werden nur Handles abgefragt, die
          // nicht 0x12019F als Access Mask haben.
          if HandleInformation^.GrantedAccess <> $12019F then
            begin
              GetMem(ObjectName, 65536);
              if DuplicateHandle(ProcessHandle, HandleInformation^.Handle, GetCurrentProcess(), @LocalHandle, 0, false, DUPLICATE_SAME_ACCESS) and (ObjectName^.Name.Buffer <> nil)then
                begin
                  if NT_SUCCESS(NtQueryObject(LocalHandle, ObjectNameInformation, ObjectName, 65536, @Unused)) and (ObjectName^.Name.Buffer <> nil) then
                    begin
                      ObjectString := LowerCase(WideString(ObjectName^.Name.Buffer));
                      writeln(Format('Process: %.8x - Handle: %.8x ObjectName: %s', [HandleInformation^.ProcessId, HandleInformation^.Handle, ObjectString]));
                    end;
                  CloseHandle(LocalHandle);
                end;
              FreeMem(ObjectName);
            end;
          CloseHandle(ProcessHandle);
        end;
      inc(HandleInformation);
    end;
  FreeMem(Buffer);
end;

begin
  NTSetPrivilege('SeDebugPrivilege', True);
  ListAllHandleNames;
end.

[EDIT]Memory Leak gefixt.[/EDIT]

[Luckie]

Delphi-Quellcode:

{*******************************************************************************
  Procedure: EnumFileHandles
  Author   : EvilSoft, mp
  Date     : 2008-09-04
  Comment  : List all file handles.
*******************************************************************************}
procedure EnumFileHandles(CallBack: TEnumFileHandlesCB; FilterStr: string = '');
var
  HandlesInfo       : PSYSTEM_HANDLE_INFORMATION_EX;
  FileName          : string;
  r                 : Integer;
  ObjTypeNumberFile : Integer;
  lib               : integer;
  DupHandle         : THandle;
  ProcHandle        : THandle;
  OSVer             : TOSVersionInfo;
label
  log;
begin
  // Load libraries
  lib := LoadLibrary('ntdll.dll');
  if lib = 0 then
    Exit;
  try
    @NtQuerySystemInformation := GetProcAddress(lib, 'NtQuerySystemInformation');
    @NtQueryInformationFile := GetProcAddress(lib, 'NtQueryInformationFile');
    @NtQueryObject := GetProcAddress(lib, 'NtQueryObject');

    if (@NtQuerySystemInformation = nil) or
      (@NtQueryInformationFile = nil) or
      (@NtQueryObject = nil) then
      Exit;

    // Determine ObjectTypeNumber constant for file objects
    //              Windows 95  Windows 98  Windows Me  Windows NT 4.0  Windows 2000  Windows XP
    //Plattform-ID     1           1           1             2              2             2
    //Majorversion     4           4           4             4              5             5
    //Minorversion     0           10          90            0              0             1
    ZeroMemory(@OSVer, sizeof(TOSVersionInfo));
    OSVer.dwOSVersionInfoSize := sizeof(TOSVersionInfo);
    GetVersionEx(OSVer);
    ObjTypeNumberFile := 23; // ???
    if OSVer.dwMajorVersion <= 5 then
    begin
      if OSVer.dwMinorVersion = 1 then
        ObjTypeNumberFile := 28 //XP
      else
        ObjTypeNumberFile := 26; //2K
    end
    else if OSVer.dwMajorVersion >= 6 then
      ObjTypeNumberFile := 25; //VISTA

    // Get all handles
    HandlesInfo := GetInfoTable(SystemHandleInformation);
    try
      if HandlesInfo = nil then
        Exit;
      for r := 0 to HandlesInfo^.NumberOfHandles - 1 do
      begin
        begin
          // Process file handles only
          if HandlesInfo^.Information[r].ObjectTypeNumber = ObjTypeNumberFile then
          begin
            // Get process handle. Needed for DuplicateHandle
            ProcHandle := OpenProcess(PROCESS_ALL_ACCESS, false, HandlesInfo^.Information[r].ProcessId);
            if ProcHandle <> 0 then
            begin
              // Why?
              if DuplicateHandle(ProcHandle, HandlesInfo^.Information[r].Handle, GetCurrentProcess, @DupHandle, 0,
                False, DUPLICATE_SAME_ACCESS) then
              begin
                FileName := GetFileNameByHandle(DupHandle);
                CloseHandle(DupHandle);
              end
              else
                FileName := '';
              if FileName <> '' then
              begin
                if (pos(LowerCase(FilterStr), LowerCase(FileName)) > 0) or (FilterStr = '') then
                begin
                  if Assigned(CallBack) then
                  begin
                    CallBack(HandlesInfo^.Information[r].ProcessId, HandlesInfo^.Information[r].Handle, FileName)
                  end;
                end;
              end;
              CloseHandle(ProcHandle);
            end;
          end;
        end;
      end; // for HandlesInfo^.NumberOfHandles
    finally
      FreeMem(HandlesInfo);
    end;
  finally
    FreeLibrary(lib);
  end;
end;

An dieser Stelle:

Delphi-Quellcode:

// Process file handles only
          if HandlesInfo^.Information[r].ObjectTypeNumber = ObjTypeNumberFile then

müsste ich dann noch deinen Code einfügen:

Delphi-Quellcode:

// Spezielle Named Pipes machen Probleme bei der Abfrage. Diese Pipes haben 
          // als Access Mask 0x12019F. Entsprechend werden nur Handles abgefragt, die 
          // nicht 0x12019F als Access Mask haben. 
          if HandleInformation^.GrantedAccess <> $12019F then

Richtig?

[Fridolin Walther]

Genau :).

[nicodex]

Zitat:

Zitat von 0xF30FC7

Das Ganze lässt sich teilweise auch im Usermode sauber lösen, sofern man nicht versucht die Namen von Handles aufzulösen, die bestimmte Access Flags gesetzt haben.

Die Abfrage auf eine bestimmte Zugriffsmaske halt ich persönlich nicht für eine "saubere" Lösung... aber das ist sicherlich eine Geschmacksfrage :)

Zitat:

Zitat von 0xF30FC7

NtQuerySystemInformation(SystemHandleInformation, [...])

Die WOW64-Implementation von wow64!whNtQuerySystemInformation_SystemHandleInfor mation ist bis zum heutigen Tage nicht brauchbar (die Struktur wird, bis auf NumberOfHandles, nicht gefüllt). Siehe:
http://forum.madshi.net/viewtopic.php?t=1231
http://forum.madshi.net/viewtopic.php?p=16768#16768

Zitat:

Zitat von 0xF30FC7

NtQueryObject([...], ObjectNameInformation, [...])

Sollte man trotz deines Filters doch auf eine Pipe treffen, könnte diese dadurch signalisiert werden. Es gibt einige Programme (zum Beispiel: ATI Control Center, Tobit David, ...), deren Pipe-Kommunikation nicht damit rechnet (AV), dass eine Pipe signalisiert wird, ohne dass Daten zur Verfügung stehen - ist eigentlich deren Problem... aber letztendlich werden normale Nutzer dem "Unlocker"-Programm die Schuld geben.

Gruß Nico

[Fridolin Walther]

Zitat:

Zitat von nicodex

Zitat:

Zitat von 0xF30FC7

Das Ganze lässt sich teilweise auch im Usermode sauber lösen, sofern man nicht versucht die Namen von Handles aufzulösen, die bestimmte Access Flags gesetzt haben.

Die Abfrage auf eine bestimmte Zugriffsmaske halt ich persönlich nicht für eine "saubere" Lösung... aber das ist sicherlich eine Geschmacksfrage :)

Ja klar. Ich geb zu da ein wenig pragmatisch veranlagt zu sein ;). Es hat halt auch noch einige anderen Grenzen. Es reichte für meine Zwecke bislang allerdings immer aus. Es gibt übrigens noch einen zweiten Weg. Wenn Du NtQueryObject in einem Thread ausführst, besteht weiterhin die Möglichkeit den Thread wenn er hängt zu terminieren. Einige "LSOF" Implementierungen, die ich gesehen habe, benutzen diesen Weg. Wenn der Thread der NtQueryObject aufgerufen hat in 50ms nicht beendet ist, wird er platt gemacht. Wahrscheinlich auch keine 100% saubere Möglichkeit, aber durchaus machbar.

Zitat:

Zitat von nicodex

Zitat:

Zitat von 0xF30FC7

NtQuerySystemInformation(SystemHandleInformation, [...])

Die WOW64-Implementation von wow64!whNtQuerySystemInformation_SystemHandleInfor mation ist bis zum heutigen Tage nicht brauchbar (die Struktur wird, bis auf NumberOfHandles, nicht gefüllt). Siehe:
http://forum.madshi.net/viewtopic.php?t=1231
http://forum.madshi.net/viewtopic.php?p=16768#16768

Nunja, das hät ich vielleicht noch erwähnen sollen. Das funktioniert natürlich ausschließlich auf 32bit Plattformen. Allerdings funktioniert eine 64bit Implementation des Codes auch unter 64bit Plattformen. Dagegen ist es mich als Privatperson unmöglich ein Code Signing Certificate zu bekommen um unter 64bit Systemen überhaupt erst in den Kernel Mode zu kommen. Und ich meine mit "unmöglich" an dieser Stelle nicht mal, das ich mir das Zertifikat nicht leisten könnte, sondern das Zertifikate nur auf Firmen ausgestellt werden.

Zitat:

Zitat von nicodex

Zitat:

Zitat von 0xF30FC7

NtQueryObject([...], ObjectNameInformation, [...])

Sollte man trotz deines Filters doch auf eine Pipe treffen, könnte diese dadurch signalisiert werden. Es gibt einige Programme (zum Beispiel: ATI Control Center, Tobit David, ...), deren Pipe-Kommunikation nicht damit rechnet (AV), dass eine Pipe signalisiert wird, ohne dass Daten zur Verfügung stehen - ist eigentlich deren Problem... aber letztendlich werden normale Nutzer dem "Unlocker"-Programm die Schuld geben.

Auch das ist durchaus ein Problem, wobei man natürlich streiten kann ob es mein Problem ist oder ihr. Ich sag ja auch nicht das ein Treiber die schlechtere Alternative wäre, aber wenn man keine Alternative hat (Privatperson und Code Signing Certificates z.B.), ist es durchaus ein praktikabler Weg. Ein wenig unschön evtl. aber praktikabel.

[nicodex]

Zitat:

Zitat von 0xF30FC7

Wenn Du NtQueryObject in einem Thread ausführst, besteht weiterhin die Möglichkeit den Thread wenn er hängt zu terminieren. Einige "LSOF" Implementierungen, die ich gesehen habe, benutzen diesen Weg. Wenn der Thread der NtQueryObject aufgerufen hat in 50ms nicht beendet ist, wird er platt gemacht. Wahrscheinlich auch keine 100% saubere Möglichkeit, aber durchaus machbar.

Einige (Filter-)Treiber mögen das gar nicht :) Ganz davon abgesehen ist TerminateThread schlecht für das "Certified for Windows Vista"-Logo-Programm.
Unter Vista kann man wenigstens CancelIoEx() verwenden, um die Anfrage abzubrechen.

Zitat:

Zitat von 0xF30FC7

Ich sag ja auch nicht das ein Treiber die schlechtere Alternative wäre, aber wenn man keine Alternative hat (Privatperson und Code Signing Certificates z.B.), ist es durchaus ein praktikabler Weg. Ein wenig unschön evtl. aber praktikabel.

Wir sind da offensichtlich einer Meinung. Ich habe nichts gegen "Umwege", solange es keinen anderen Weg gibt :)
Auf einem frischen System gibt es selten Probleme. Die kommen erst, wenn man es mit vielen Kundensystemen zu tun hat. Und dann kommt man um eine "saubere" Lösung nicht herum... (finde ich ;)).

off-topic: Der wievielte Thread zu "offenen Dateihandles" ist das eigentlich ?-)

[Fridolin Walther]

Zitat:

Zitat von nicodex

Einige (Filter-)Treiber mögen das gar nicht :) Ganz davon abgesehen ist TerminateThread schlecht für das "Certified for Windows Vista"-Logo-Programm.
Unter Vista kann man wenigstens CancelIoEx() verwenden, um die Anfrage abzubrechen.

Nunja, was Third Party Treiber angeht, sieht man extrem viel murks. Besonders schlim sind meiner Erfahrung nach alle Treiber die irgend eine Art von Hooking durchführen. Von korrekter Parametervalidierung haben die meisten noch nie was gehört. Aber hey, irgendwie muss man ja auch ohne Code Zertifikat bei x64 Systemen in den Kernel kommen :P.

Zitat:

Zitat von nicodex

Auf einem frischen System gibt es selten Probleme. Die kommen erst, wenn man es mit vielen Kundensystemen zu tun hat. Und dann kommt man um eine "saubere" Lösung nicht herum... (finde ich ;)).

Klar, nem Kunden würd ich so nen Hack nicht zumuten. Aber hier gehts je eher ums Hobby und wie gesagt ... Treiber sind mächtig, aber als Privatperson ist man spätestens bei x64 aus der Treiberentwicklung ausgeschlossen. Klar, man kann sich ein eigenes Zertifikat generieren mit ner selbst erstellten CA und diese CA dann lokal als Vertrauenswürdig einstufen, aber für eine Anwendung die verteilt werden möchte (und selbst wenns nur in nem Board wie die Delphi Praxis ist), ist das keine Alternative.

Zitat:

Zitat von nicodex

off-topic: Der wievielte Thread zu "offenen Dateihandles" ist das eigentlich ?-)

Ich hab keine Ahnung. Bin erst seit kurzem überhaupt aktiv. Der Account selbst besteht länger, weil zum Download brauchst ja nen Account ;). Aber die Frage selbst ist allgemein (auch in C/C++ Boards) sehr beliebt ;).