Wie kann ich meine C # -App vor einer Person schützen, die ihren Prozess über Taskman oder programmgesteuert beendet?
Hier ist mein Szenario:
App A ist eine MFC-App, die von einem anderen Team entwickelt wurde. Es hat eine unveröffentlichte textbasierte Remote-Schnittstelle, die über eine Hintertür aktiviert wird.
Ich entwickle App B, eine C # WinForms-App, die mit A interagiert. B ermöglicht A's Hintertür, wenn es Remote-Zugriff benötigt, schließt es, wenn es fertig ist (oder bei einem Fehler).
Ich untersuche, wie Benutzer B missbrauchen können, um Zugriff auf die verborgene Funktionalität von A zu erhalten, z. B. den Prozess von B zu beenden, nachdem die Remote-Schnittstelle von A aktiviert wurde. Ich hätte gerne eine letzte Chance für B, A's Hintertür zu schließen, wenn das passiert.
B verwendet localhost, um mit A zu interagieren, also mache ich mir keine Sorgen wegen des Power-Down-Szenarios.
Ich suche nach einer Lösung, die A nicht ändert.
Ich erwarte nicht, Dark Tangent stoppen zu können (obwohl das ein Bonus wäre), aber im Moment könnte ein Script-Kiddie seinen Weg mit diesem Design finden:)
Diese Apps laufen unter Windows XP, werden aber bald auch Vista & amp; 7.
Vielen Dank im Voraus, Jim
Ich bin bereit, die App herunterzufahren, wenn sie es versuchen, aber zuerst einige Dinge tun müssen.
Die notwendigen Schritte beim Herunterfahren des Programms führen zu zerbrechlichen Programmen, die leicht kaputt gehen. Selbst wenn Sie jemanden daran hindern könnten, Ihr Programm über den Task-Manager zu beenden, können Sie nicht verhindern, dass sie den Computer ausschalten oder sogar das Kabel aus der Wand ziehen. Welche Aufgabe auch immer so wichtig war, wird verloren gehen. Und was, wenn es einen Stromausfall gibt? Wieder wird Ihre Aufgabe nicht abgeschlossen und Ihr wichtiger Bereinigungscode wird nicht ausgeführt.
Stattdessen sollten Sie Ihr Programm an jedem Punkt robust gegenüber Fehlern machen. Verwenden Sie Transaktionen und speichern Sie den Status immer atomar - stellen Sie sicher, dass Sie immer mindestens eine gültige Kopie Ihrer Daten haben. Überschreibe wichtige Dateien nicht so, dass sie vorübergehend ungültig werden.
Schließlich können Sie Ihrem Programm ein Dialogfeld hinzufügen, das beim Schließen des Programms darauf hinweist, dass das Programm ordnungsgemäß heruntergefahren werden muss. Wenn Sie Ihr Shutdown schnell machen, wollen Benutzer es nicht beenden und lassen es ordnungsgemäß beenden. Wenn das Herunterfahren ewig dauert, werden die Leute versuchen, es zu töten. Wenn Sie mit Ihren Benutzern nett sind, werden sie auch nett zu Ihnen sein.
Wenn Sie schnell herunterfahren, bedeutet das, dass der Benutzer einige nicht abgeschlossene Arbeiten verliert, und warnen Sie ihn davor. Geben Sie ihm die Möglichkeit, auf den Abschluss der Aufgabe zu warten, aber wenn er Ihr Programm wirklich beenden möchte, lassen Sie es beenden.
Kurze Antwort: Sie können nicht und sollten nicht.
Lange Antwort: Sie können versuchen, einen zweiten "Helfer" -Prozess zu starten, der alle x Sekunden überprüft, ob Ihre App noch läuft. Wenn nicht, startet es neu.
Wenn Sie möchten, dass ein Prozess für eine lange Zeit ausgeführt wird, vertrauen Sie den Benutzern nicht, dass sie weiterhin ausgeführt werden. Betrachten Sie Windows-Dienste. Sie sind dafür ausgelegt.
Ich denke, jeder hat den Punkt verpasst. Wenn ich es richtig gelesen habe (nach Ihrer Bearbeitung), möchten Sie wissen, wann Sie "getötet" werden, damit Sie elegant herunterfahren können?
Der Punkt des "Tötens" ist, dass Sie es nicht stoppen können. Es gibt natürlich Workarounds wie die Verwendung einer zweiten App, um eine getötete App wiederzubeleben, aber das hat nichts damit zu tun, einfach in der Lage zu sein, elegant herunterzufahren.
Der beste Ansatz besteht darin, entweder als Dienst auszuführen (damit Sie nicht getötet werden können, nur heruntergefahren werden müssen) oder die Funktionsweise Ihrer App so zu strukturieren, dass sie vorher nicht "aufräumen" muss es hört auf. Wenn eine App beendet wird, werden die meisten Ressourcen, die sie enthält, automatisch bereinigt, sodass Sie nur Ihre eigenen Daten sauber schließen müssen. Ansätze, die Sie ausprobieren könnten, sind:
Um zu verhindern, dass Ihre Anwendung beendet wird, führen Sie Ihre Anwendung als anderer Benutzer ( dh als Dienst oder als einen anderen Dienst aus Benutzerkonto) und beschränken Sie die Benutzer auf Standardbenutzer .
Auf diese Weise können keine böswilligen Benutzer Ihren Prozess beenden, da nur Administratoren sie töten können, und das ist ein Privileg, dem Sie anscheinend niemandem trauen.
Es hat den Vorteil, dem beabsichtigten Design des Betriebssystems zu folgen.
@Jim
Wenn App A Änderungswünsche erhalten kann
Vorzugsweise würde ich eine Architektur verwenden, in der alle App B beim Öffnen der Hintertür registriert sind und App A mit der Registrierung in einem Intervall pingen müssen, damit App A ihre eigene Hintertür schließen kann, nachdem App B sie nicht informiert hat dass es noch Zugriff benötigt. Dies ist immer noch nicht vollkommen sicher, aber App A sollte nicht mit einer solchen Schnittstelle ohne irgendeine Art von Selbstregulierung für "sichere" Kommunikationsmittel strukturiert sein.
Oder Sie können vorschlagen, dass App A geändert wird, um nach gültigen Prozessen zu suchen, und wenn keine gefunden werden, während die Hintertür offen ist, wird sie geschlossen (dies ist gefälscht, da sie nach verarbeiteten Namen abläuft).
Ansonsten klingt es so, als würde App B die Hintertür so oft wie möglich schließen, wenn sie nicht sofort Zugriff benötigt.
Eine App B zu verlangen, um die Sicherheit des Zugriffs auf App A zu gewährleisten, ist in der Tat ein armes Modell.
Soweit ich weiß, kannst du es nicht, und selbst wenn du es könntest, solltest du es wirklich nicht tun. Stellen Sie sich vor, wie ärgerlich es wäre, wenn Sie keine Anwendung zwingen könnten.
Wenn es wichtig ist, dass Ihre Anwendung weiter läuft, können Sie immer einen Windows-Dienst erstellen, der die Anwendung "pingt", um sicherzustellen, dass sie läuft (Sie könnten Named Pipes, Sockets, PID-Dateien usw. verwenden). Wenn der Dienst erkennt, dass der Prozess beendet wurde, kann er ihn einfach neu starten. Das ist wahrscheinlich die beste Wahl.
Wenn die Anwendung zum ersten Mal gestartet wird, können Sie nicht einen dritten Prozess ausführen, der im Hintergrund ausgeführt wird und versucht, App B jedes Mal zurückzurufen. Wenn App B geschlossen ist, kann App C sehen und führt eine Prozedur aus, um die Hintertür von App A zu schließen.
Damit App B erfolgreich über die vorgesehene Schließen-Schaltfläche geschlossen wird, wird App C nicht mehr überprüft. App B funktioniert immer noch einwandfrei ...
Im Moment bin ich nicht wirklich der Beste mit C #, aber wenn ich auf dein Problem schaue, ist das wahrscheinlich eine der Möglichkeiten, wie ich es versuchen würde.
Auch wenn App B App C ebenfalls überprüft, dann wenn App C heruntergefahren wurde App B schließt die Hintertür, wenn es möglich ist.
Wie die anderen sagen, ist das vielleicht keine gute Idee, tho.