SuRun 1.2.0.7

Kommt bei Dir die richtige Sanduhr oder der Programmstart-Zeiger mit Sanduhr?
Vor oder nach dem Erscheinen des sicheren Desktop?

@JAN: Flackert nur SuRun unter Vista bei Dir oder auch UAC (wie bei mir)? ...wenn MS es nicht hin bekommt, kann ich mir das Suchen sparen ;-)

Cosmo wrote: Nach dem Installieren auf der physischen Maschine habe ich (wie bei VB berichtet) beim Einstellungsdialog keine Sanduhr mehr, aber wenn ich den Bestätigungsdialog bekomme, dreht sie sich in alter Weise (das hatte ich unter VB nicht getestet und folglich nicht gesehen).

Ich sehe das auch gerade... dem WatchDog ist das Wurst. Aber irgendwo wird's hängen. Ich sehe mal nach.

Ich hab's gefunden:
Der SuRun-Client-Prozess kann ein Fenster darstellen, deshalb hat Windows den Programmstart-Zeiger dargestellt.
Bei "SuRun /Setup" beendet sich der Client sofort und deshalb verschwindet der Programmstart-Zeiger.
Ansonsten wartet SuRun auf den Dienst und Windumms zeigt, das etwas starten will...

Was man machen muss, um den Zeiger zu verbergen ist unglaublich blöd (vielleicht geht's einfacher, aber ich habe nichts gefunden): Man muss ein Fenster erstellen (unsichtbar ist ok), eine Meldung an das Fenster schicken, diese Meldung abfragen (Das verbirgt den AppStart-Zeiger) und das Fenster wieder zerstören. Oh Mann!!!

Hier ist SuRun 1.2.0.7 Beta 5. Appstart-Zeiger sollten jetzt Geschichte sein.

Vielleicht geht das sogar schneller, als das "Ausführen als..." pro Programm...
Mit "start /wait SuRun /wait ..." hast Du ja wenigstens schon mal Batch-Unterstützung ;-)

Sodele,

ich habe mal mit der Konsole gespielt.

Um Konsolen-Prozesse vernünftig zu benutzen, müsste man ohne Hilfsmittel auskommen. Wenn man SuRun aus der Windows cmd-Shell startet, stellt cmd sofort wieder den Command-Prompt dar. Es wartet nicht, bis SuRun beendet ist, weil SuRun kein Konsolen-Programm ist.

Kein Problem, wenn man ein SuRunC.exe schreiben würde, das ein Konsolen-Programm ist.
Dann würde cmd warten und alles wäre gut.

Es ist möglich, einen Prozess direkt in einer vorhandenen Konsole mit gehobenen Rechten zu starten.
Aber nur, wenn man "CreateProcessAsUser" benutzt und einen Benutzer-Token mit gehobenen Rechten hat.
Diesen Benutzer-Token müsste der SuRun-Dienst an SuRunC.exe übergeben.(Dass der Dienst ein neues Programm startet und diesem die Konsole von SuRunC vererbt, geht nicht.)

Damit hätten wir ein dickes Sicherheitsloch! Ein Admin-Token in einem bekannten nicht-Admin-Programm. Den könnte man leicht (auch als Gast) stehlen und zu bösen Zwecken benutzen. Aber SuRunC würde vollständig in die Konsole integriert funktionieren.

Eine andere Möglichkeit wäre, dass SuRunC die Ein-/Ausgabe des gehobenen Prozesses mit einer Pipe umleitet.
Die Eingabe des gehobenen Prozesses würde von SuRunC mit einer Pipe aus der originalen Standard-Eingabe versorgt und StdOut/StdErr würden von SuRunC gelesen und in dessen SdtOut/StdErr geschrieben werden.
Das hätte verschiedene Nachteile.
* Die gestartete Konsolen-Anwendung würde immer denken, dass ihre Ein- und Ausgabe umgelenkt ist.
* Direkter Zugriff auf die Konsole und das Abfangen von Ereignissen, wie Ctrl+C wäre der gehoben laufenden Anwendung nicht möglich.
* Farbiger Text geht nicht.
* Die Microsoft CRT puffert (cached) die Ausgaben von Programmen bei umgelenkter Ein/Ausgabe. Das führt dazu, dass ein Programm ausgibt: "Text1, Fehler1, Text2, Fehler2..." und dann die Eingabe liest. SuRunC würde anzeigen "<NIX mit blinkendem Cursor>" Benutzer macht eine Eingabe, SuRunC zeigt erst die Benutzereingabe, dann "Text1, Text2, Fehler1, Fehler2..."

...oder mit anderen Worten: Irgendwas ist immer!

Welches Übel wäre dabei das kleine?

Oh, es gibt noch was: Man könnte einen Proxy bauen, der eine komplett neue Konsole tunnelt... aber das ist mit enorm viel Arbeit verbunden. Ich habe das aber noch nicht probiert.

Mik hat einen Fehler im WatchDog gefunden, ich habe ihn behoben. :-D

SuRun 1.2.0.7 Beta 6 vom 05.04.2009
* Das WatchDog-Ereignis wird jetzt in einem Timer und nicht in einem eigenen Thread gesetzt. Dadurch zeigt sich der WatchDog auf jeden Fall; auch, falls nur das GUI blockiert wird. (Comodo IS hat im Paranoia Modus SuRuns GUI blockiert, der WatchDog Thread lief aber munter weiter)
* FIX: Der WatchDog hat sich nicht beendet, falls der GUI-Prozess gekillt wird.

Habe den Quelltext von Console2 mal grob überflogen.
Das Programm startet pro TAB eine verborgene Console und stellt deren Inhalt in einem eigenen Fenster dar.

Damit wäre die halbe Miete für SuRunC erledigt. Wenn ein Programm ohne umgeleitete Ein-/Ausgabe mit gehobenen Rechten gestartet werden soll, könnte man so ähnlich den Bildschirminhalt in die nicht-admin-Console übertragen.

Was neu werden müsste:
* Console2 setzt einen Hook mittels CreateRemoteThread(LoadLibrary("ConsoleHook.dll")). Das funktioniert wahrscheinlich nicht in Windows Vista und auch nicht wenn ein 64Bit Console-Prozess gestartet wurde. HIPS und Virenscanner werden wahrscheinlich Alarm schlagen, weil CreateRemoteThread definitiv als böse eingestuft wird. Dafür müsste ich mir was anderes einfallen lassen. Zwei SuRunC-Prozesse, die miteinander kommunizieren, wären wohl die beste Lösung. Einer läuft als Dauser, einer verborgen als Admin. Der verborgene SuRunC-Prozess startet dann den eigentlichen Consolen-Prozess in der eigenen (versteckten) Console.
* Zum Datentransfer benutzt Console2 "Shared Memory" in Form von Memory Mapped Files. Das müsste ich auf Pipes umschreiben. So kann ich verhindern, dass jemand böses mitlauscht oder fernsteuert.
* Das "Pipen" von StdEin-/StdAusgabe/StdFehler und die Rückgabe von ExitCode-Werten unterstützt Console2 nicht. Das muss ganz neu programmiert werden. (Habe ich aber schon fast fertig)

Erstmal Vereinfachung für Kommandozeilengeplagte... :-D

SuRun 1.2.0.7 Beta 7 vom 26.04.2009
* SuRun setzt und entfernt keine Anführungszeichen mehr in den Kommandozeilenparametern der zu startenden Programme. (Hoffentlich habe ich dabei nichts in Mitleidenschaft gezogen.) Das automatische Neubasteln der Kommandozeile hat offensichtlich mehr Schaden angerichtet, als Gutes getan.