Auf Dateien zugreifen die gerade in Gebracuh sind (?)

[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 ;).