System-Meldungen "hooken" (IP address conflict, file or directory is corrupt)

[hustbaer]

Gibt es eine Möglichkeit in Windows diverse System-Meldungen zu "hooken"? Also ich würde das System gerne dazu bringen statt die Meldung anzuzeigen irgendwas von mir aufzurufen/auszuführen. Also z.B. eine eigene DLL Funktion oder auch eine .exe rausstarten.
Einfach nur einen Eventlog Eintrag Schreiben wäre auch eine akzeptable Lösung - dann müssten wir halt das Eventlog überwachen.

Das dumme ist: ich hab' keine Ahnung nach was ich da suchen soll. Ich weiss nicht welcher Systemteil diese Meldungen anzeigt, in welchem Service/welcher DLL sie implementiert sind, etc.
Wenn ich das wüsste, könnte ich anfangen sinnvoll zu googeln, aber so finde ich einfach nix.

OS um das es mir primär geht ist Windows XP embedded. Windows Embedded Standard 7 wäre dann in weiterer Folge auch interessant, ist aber erstmal nicht so wichtig.

Die konkreten Meldungen um die es mir geht sind:
* "Windows - System Error" - "There is an IP address conflict with another system on the network"
* "Windows - Corrupt File" - "The file or directory (path) is corrupt and unreadable. Please run the Chkdsk utility."

Wäre über Tips dankbar.

[EOP]

Hab schon ganz schräge dll-injections bei crackmes gesehen.
Mal mit ollydbg nach strings suchen?

IDA geht auch:
http://www.chip.de/downloads/IDA-Pro-Free-Letzte-Freeware-Version_29744270.html

[TopKek]

Also ich würde das System gerne dazu bringen statt die Meldung anzuzeigen irgendwas von mir aufzurufen/auszuführen

Der Kernel von Windows erstellt im Falle solcher Fehler System-Threads, auf die der Zugriff aus dem Benutzermodus kläglich scheitern wird. Man müsste daher den Kernelcode direkt ändern, was mit der WinAPI natürlich ebenfalls unmöglich ist und ohnehin auf jedem Rechner als Virus abgestempelt wird.

Der Benutzer kann Windows über eine als "System Call" bezeichnete Schnittstelle und einem damit verbundenen Index für die sogenannte "Interrupt Descriptor Table" kontaktieren, wobei im Kernel anhand dieser Informationen den entsprechenden Code ausführt. Auch wenn eine Datei (also ein Kernelobjekt) erstellt wird, ist damit stets ein Index verbunden.

Nun kann es passieren, dass während der Ausführung des Codes zur Erstellung des Kernelobjektes ein Fehler auftritt. Windows regiert darauf, indem z.B die von dir beschriebenen Meldungen angezeigt werden.

Die Manipulierung des Kernelcodes geht schon sehr stark in Richtung Rookits und erfordert mitunter beste Kentnisse zur Erstellung von Softwaretreibern.

Auf Windows XP ist die Basisadresse der IDT für Core 0 immer 0x8003F400. Da die Indexer aller entsprechenden Handler sich von System zu System unterscheiden habe ich eine vollständige Liste für alle Windows-Betriebssysteme erstellt. Ein paar weitere Informationen durch Reverse Engineering wirst du allerdings auch dann immer noch benötigen.

Wenn du die Aufgabe wichtig ist,- und sauber erledigt werden muss,- kannst du mich auf Wunsch per E-Mail für die Liste und Code zur Handledumping der IDT kontaktieren.

[Hähnchenkeule]

Gibt es eine Möglichkeit in Windows diverse System-Meldungen zu "hooken"? Also ich würde das System gerne dazu bringen statt die Meldung anzuzeigen irgendwas von mir aufzurufen/auszuführen. Also z.B. eine eigene DLL Funktion oder auch eine .exe rausstarten.
Einfach nur einen Eventlog Eintrag Schreiben wäre auch eine akzeptable Lösung - dann müssten wir halt das Eventlog überwachen.

Auf Windows XP ist das durch Techniken wie "API Hooking" ohne weiteres möglich ;). Anhand deiner Anforderung entnehme ich jetzt einfach mal, dass du die nötigen Kenntnisse im Umgang mit der WinAPI hast. Der Ablauf gestaltet sich dann etwa so:

[] Lokalisiere die Adresse der Zielfunktion (z.B CreateFileW; Kernel32.dll)
[] Sichere ein paar der ersten Funktionsbytes
[] Überschreibe die ermittelten Bytes etwa mit einer JUMP Anwendung (Assemblerbefehl) unter Angabe deiner Ersatzfunktion. Die von dir aufzurufende Funktion muss dabei dieselben Parameter, dieselbe Aufrufskonvention und denselben Rückgabetyp haben!
[] Wenn jetzt CreateFileW von irgendeinem Thread aufgerufen wird führt Windows automatisch den JUMP-Befehl aus und springt damit zu deiner Funktion

Der Mechanismus sollte natürlich auch wieder Rückgängig gemacht werden, darauf aber genauer einzugehen wäre jetzt overkill zumal du dazu eigentlich gute Tutorials finden kannst.

[Mechanics]

Hähnchenkeule schrieb:

... Auf Windows XP ist das durch Techniken wie "API Hooking" ohne weiteres möglich ...

LOL, find ich schon witzig, hustbaer so triviale Tipps zu geben

[hustbaer]

@TopKek

TopKek schrieb:

Nun kann es passieren, dass während der Ausführung des Codes zur Erstellung des Kernelobjektes ein Fehler auftritt. Windows regiert darauf, indem z.B die von dir beschriebenen Meldungen angezeigt werden.

Ich weiss nicht was du genau mit "Kernelobjekt" meinst, aber die beiden Fehler haben nichts damit zu tun dass ein IRP nicht erstellt werden könnte.
Der eine kommt - vermutlich - wenn das File System vom Mass Storage Treiber einen Lesefehler gemeldet bekommt.
Und der andere, naja gut wann ein "IP address conflict" gemeldet wird sollte klar sein.

Was dein Angebot angeht: falls dazu ein Rumspielen im/Patchen des Kernel notwendig sein sollte, dann werde ich lieber die Finger davon lassen. Den Aufwand ist es dann doch nicht wert. Trotzdem danke.

@Hähnchenkeule
Ja, hooking wäre vermutlich ne gute Idee. Nur welche Funktion?
Was die "IP address conflict" Meldung angeht liesse sich das vermutlich noch relativ leicht feststellen, da diese sehr einfach zu reproduzieren ist.
Zumindest wenn, wie ich hoffe, der Thread dem dieses Fenster gehört nicht zum "System" Prozess gehört.

Aber was die "file corrupt" Meldung angeht bin ich einigermassen ratlos, da ich nicht weiss wie ich diese provozieren kann.
Eine Möglichkeit an die ich gedacht hatte wäre nen USB Stick zu opfern (einfach immer wieder den selben Block überschreiben, dann sollte der Block nach ein paar tausend Schreibzugriffen hin sein).
Dummerweise haben billige USB Stick, also die bei denen man davon ausgehen kann dass sie kein Wear-Leveling haben, auch keine brauchbare Fehlererkennung. Und liefern dann beim Lesen von kaputten Flash Blöcken einfach einen Block voll mit 0xFF zurück statt einen Fehler ans OS zu melden.

[hustbaer]

@Mechanics
Ach was, ich bin für Tips durchaus dankbar.
Meine Kenntnisse was diverse Techniken angeht die man grob in die Ecke "Hacking" stecken kann sind doch sehr begrenzt. (Oder sagen wir besser meine Erfahrung, theoretische Kenntnisse sind z.T. vorhanden.)

Nur müsste ich halt wie gesagt wissen welche Funktion man hooken müsste.

Natürlich könnte man es einfach mal mit "MessageBoxW" probieren.

Allerdings hatte ich gehofft dass es hier eine API bzw. einen Mechanismus von Windows gibt wo man sich etwas "offizieller" einklinken kann.
So wie man bei Windows z.B., wenn man WER nicht verwenden will, einfach über ein paar Registry Keys einen Post-Mortem Debugger registrieren kann um Application Crashes zu behandeln.

[hustbaer]

EOP schrieb:

Hab schon ganz schräge dll-injections bei crackmes gesehen.
Mal mit ollydbg nach strings suchen?

IDA geht auch:
http://www.chip.de/downloads/IDA-Pro-Free-Letzte-Freeware-Version_29744270.html

Die Idee nach Strings zu suchen ist mir auch schon gekommen. Hab' ich dann allerdings wieder verworfen, da Windows Strings üblicherweise in Resourcen speichert. Und mich da so weit mit nem Disassembler reinzukämpfen dass ich Stellen finden würde wo auf bestimmte Resourcen zugegriffen wird... der Aufwand steht einfach nicht dafür.

Das ganze ist nicht SO wichtig.
Es wäre gut wenn es mit relativ geringem Aufwand ginge, aber es ist nicht wirklich sehr wichtig. Wie ich Mechanics gerade schon geantwortet habe hatte ich einfach gehofft dass es da einen Punkt gibt wo man sich ohne grossen Aufwand einhängen kann.

ps: Gerade weil MS ja immer wieder Embedded Varianten von Windows macht, und auf Embedded Systems könnte es ja durchaus interessant sein solche Dinge programmatisch zu erfassen und evtl. auch die Message Box zu unterdrücken (oder durch eine eigene Meldung zu ersetzen). Von daher die Hoffnung dass es da einen mehr oder weniger offiziellen Weg gibt.

[happystudent]

hustbaer schrieb:

Aber was die "file corrupt" Meldung angeht bin ich einigermassen ratlos, da ich nicht weiss wie ich diese provozieren kann.
Eine Möglichkeit an die ich gedacht hatte wäre nen USB Stick zu opfern (einfach immer wieder den selben Block überschreiben, dann sollte der Block nach ein paar tausend Schreibzugriffen hin sein).
Dummerweise haben billige USB Stick, also die bei denen man davon ausgehen kann dass sie kein Wear-Leveling haben, auch keine brauchbare Fehlererkennung. Und liefern dann beim Lesen von kaputten Flash Blöcken einfach einen Block voll mit 0xFF zurück statt einen Fehler ans OS zu melden.

Keine Ahnung ob dir das was hilft, aber laut Microsoft (How do I prevent files from becoming corrupted?) passiert das üblicherweise nur während dem speichern?

Also vielleicht einfach eine sehr große Datei speichern (die halt lange für den Speichervorgang braucht) und währenddessen den Stecker ziehen. Ka ob das funktioniert, aber dabei dürfte (bis auf die Datei) zumindest nichts kaputt gehen

[Meep Meep]

hola

wenn bei diesen systemfehlern auch logs in der ereignisanzeige erstellt werden, dann koenntest du dich zu mindest da mal reinhaengen.
hier sowas in der art auf codeproject: http://www.codeproject.com/Articles/4857/A-realtime-event-log-monitoring-tool

Meep Meep

[hustbaer]

@happystudent
Da geht's um eine andere Definition von "corrputed files".
Ich meine welche wo Windows den von mir zitierten Dialog bringt, und der kommt AFAIK nur wenn die Disk einen Lesefehler meldet.

In dem von dir beschriebenen Artikel geht's einfach um Files mit blödsinnigem Inhalt (die aber von der Disk noch korrekt gelesen werden können). Wie man diese erzeugt ist mir schon klar, bringt mir nur nix.

@Meep Meep
Ja, wenn du mir sagst wie & wo ich das umstellen kann so dass die Meldung selbst dann nicht mehr angezeigt wird...

hustbaer schrieb:

Einfach nur einen Eventlog Eintrag Schreiben wäre auch eine akzeptable Lösung - dann müssten wir halt das Eventlog überwachen.

[Meep Meep]

die idee dahinter war jetzt nicht die message zu unterdruecken,
sondern das du ei einem bestimmen ereigniss dann was starten kannst.
naja bissl am thema vorbei

Meep Meep

[hustbaer]

Meep Meep schrieb:

die idee dahinter war jetzt nicht die message zu unterdruecken

Das ist aber leider das was ich brauche
Ich will ja nicht zusätzlich 'was anzeigen sondern die Message ersetzen.

[DarkShadow44]

Kannst du den Fehler bzw. die Meldungen denn reproduzieren wann du willst? Dann könntest du dich eventuell mal mit Ollydebug einklinken und dir den Callstack anzeigen lassen wenn die Nachricht angezeigt wird. Vielleicht hast du ja Glück und da findet sich eine Funktion die du hooken kannst. Brauchst aber eventuell Debugsymbole und wirklich wenig Aufwand ist auch das nicht.
Was für eine Meldung wird denn ausgegeben? MessageBox oder was anderes?
Zumindest wäre das gerade das einzige was mir zu dem Thema einfällt.

[Mechanics]

Die Symbole müsste man eigentlich schon bekommen... Müsste eigentlich WinDbg reichen.

[hustbaer]

@DarkShadow44

DarkShadow44 schrieb:

Kannst du den Fehler bzw. die Meldungen denn reproduzieren wann du willst?

Naja eben nicht, das ist ja u.A. das Problem

hustbaer schrieb:

@TopKekJa, hooking wäre vermutlich ne gute Idee. Nur welche Funktion?
Was die "IP address conflict" Meldung angeht liesse sich das vermutlich noch relativ leicht feststellen, da diese sehr einfach zu reproduzieren ist.
Zumindest wenn, wie ich hoffe, der Thread dem dieses Fenster gehört nicht zum "System" Prozess gehört.

Aber was die "file corrupt" Meldung angeht bin ich einigermassen ratlos, da ich nicht weiss wie ich diese provozieren kann. (...)

Und ja, Symbols sind kein Problem -- sind ja über den MS Symbol-Server verfügbar.

[Chrisi_K]

Diese Funktionalität steht bei den Embedded-Windows-Versionen zur Verfügung:
Meldung automatisch wegklicken:
XP: https://msdn.microsoft.com/en-us/library/aa940743(v=winembedded.5).aspx
WES7: https://msdn.microsoft.com/en-us/library/ff794009(v=winembedded.60).aspx

Eigene Aktion ausführen bei MessageBox:
WES7: https://msdn.microsoft.com/en-US/library/ff794863(v=winembedded.60).aspx
Ob es das bei XP auch schon gibt, weiss ich nicht.

[hustbaer]

Für WES7 werden wir uns vermutlich den Dialog Box Filter mal genauer ansehen.

Die bei XP verfügbare Option ist aber als Werkzeug leider viel zu breit/stumpf, da wir nicht einfach alle Messageboxen automatisiert wegklicken lassen können.

Trotzdem danke!

[essio]

Meep Meeps idee war doch garnicht so schlecht

Wenn man die Dateien im Prozess kennt kann man diese auch am ausführen hindern, oder denke ich da zu einfach?

ansonsten:
Windows: Problem- und Fehlerberichte abschalten
http://praxistipps.chip.de/windows-problem-und-fehlerberichte-abschalten_27141

Start -> Einstellungen -> Systemsteuerung -> System -> Erweitert -> Fehlerberichterstattung

Gehe stark davon aus, dass bis zu einem "gewissen" Punkt, im System, das Gleiche passiert. Da ansetzen..

[hustbaer]

essio schrieb:

Meep Meeps idee war doch garnicht so schlecht

Wenn man die Dateien im Prozess kennt kann man diese auch am ausführen hindern, oder denke ich da zu einfach?

Was für Dateien? Ich hab keine Ahnung wovon du sprichst.

essio schrieb:

ansonsten:
Windows: Problem- und Fehlerberichte abschalten
http://praxistipps.chip.de/windows-problem-und-fehlerberichte-abschalten_27141

Start -> Einstellungen -> Systemsteuerung -> System -> Erweitert -> Fehlerberichterstattung

Gehe stark davon aus, dass bis zu einem "gewissen" Punkt, im System, das Gleiche passiert. Da ansetzen..

Dass man WER (Windows Error Reporting) konfigurieren kann weiss ich. Bringt mir aber nix, da die von mir erwähnten Meldungen keine Crashes sind.