Hallo.
Wenn Du es nicht selber machen möchtest, weil Du Spass daran hast, schau mal hier. <---- DA
Aber das was Du da vor hast ist eine gute Idee. Ich habe mich mal mit dem sog. Kioskmodus auseinander gesetzt. War echt hart. Aber gut. Also mach weiter.
Also ich hätte ja eine versteckte Systemdatei verwendet, statt die Datei einfach offen hinzulegen, das zum einen. Zum anderen ist Aufgabenplanung weder sonderlich sinnvoll für sowas, noch extrem zuverlässig, da hier - wie auch bei Diensten - nur eine minimale Prüfung stattfindet, ob dein Script überhaupt noch läuft oder in eine Exception gelaufen ist. Die einzige sinnvolle Möglichkeit über die Aufgabenplanung ist aus meiner Sicht das Prüf-Script minimal zu halten und es nur "durchlaufen" zu lassen und es wieder - z.B. nach 5 Minuten - neu aufrufen zu lassen. Das andere Script, welches den Login-Zeitpunkt ausließt hingegen ist an einer der AutoStart-Locations. Vorzugsweise natürlich in der Registry.
Problem hättest du nur mit dem Logout, den du ja mitnehmen wolltest. Den bekommst du eigentlich nur vernünftig, wenn du die Zeit in der Textdatei durchgehend aktualisierst. Aber egal wie gut die versteckt ist, man wird sie problemlos finden, wenn sie derart häufig aufgerufen wird - außer, die Datei hat zusätzlich zu ihren Attributen noch einen Namen der nach Systemdatei klingt...
Es ist absolut unnötig den Prozess oder die Logdatei durch irgendwelche Fakenamen tief im System zu verstecken und davon mal ab ist das auch kein Schutz, sondern einfach nur die Hoffnung, dass der Benutzer zu blöd ist das Programm zu finden. In den meisten fällen trifft das wohl auch zu, dennoch bietet einem Windows seit Jahren sehr viel bessere Möglichkeiten Prozesse vor einfachen Benutzern zu schützen.
Das Script muss einfach nur über einen anderen Benutzeraccount gestartet werden (Stichwort: Windows Aufgabenplanung). Jenachdem was das Script alles tun soll benötigt dieser Account entsprechende Rechte, sei es Schreibberechtigung für einen bestimmten Dateipfad oder in der Registry, Rechte das System herunterzufahren oder Benutzerkonten zu sperren usw. Sofern man seine Logdaten im Dateisystem ablegt muss man eben noch sicherstellen, dass dort nur der Account Schreibrechte besitzt unter dem das Script läuft.
Der Benutzer selbst arbeitet ohne Administrator Account. Dadurch ist das Thema dann auch erledigt, denn ohne Adminrechte kann man weder die Prozesse anderer Accounts beenden noch kann man evtl. gefährliche Software installieren. Genau das was man braucht um den PC vor unerfahrenen Anwendern zu schützen.
Was Bioshade uns mit seiner Kritik zur Windows Aufgabenplannung sagen wollte ist mir nicht wirklich klar. Wenn die Software voll mit Bugs ist und abstürzt kann Windows da auch nichts dafür. Das passiert genauso wenn das Script im Kontext des angemeldeten Benutzers läuft, nur dass der Benutzer den Absturz der Software dann halt mitbekommt und mit der Nase drauf gestossen wird, dass hier irgendwas diletantisch programmiertes unsichtbar im Hintergrund läuft/lief.
Über die Aufgabenplanung kann man wunderbar auf An- und Abmeldungen am System reagieren, was ideal wäre um die Nutzungszeiten zu protokollieren.
ah ok du hast unterschiedliche zeiten für das wochenende...script sieht gut aus....sollte so passen 
man könnte halt alles in ein Script packen...ist aber geschmackssache...
Was Bioshade uns mit seiner Kritik zur Windows Aufgabenplannung sagen wollte ist mir nicht wirklich klar. Wenn die Software voll mit Bugs ist und abstürzt kann Windows da auch nichts dafür. Das passiert genauso wenn das Script im Kontext des angemeldeten Benutzers läuft, nur dass der Benutzer den Absturz der Software dann halt mitbekommt und mit der Nase drauf gestossen wird, dass hier irgendwas diletantisch programmiertes unsichtbar im Hintergrund läuft/lief.
Bioshade hat in ihrer Kritik zur Windows Aufgabenplanung zu bedenken geben wollen, dass AutoIt bei weitem nicht die stabilste Scriptsprache ist, wenn es um einen pseudo 24/7-Betrieb geht. Teilweise hast du dann das Problem, dass das Script einfach mal eben "hung" ist, oder einfach abgeschmiert ist oder sonst etwas. Jeder, der hier im Forum bereits einmal einen Windows-Service in AutoIt geschrieben hat weiß ganz genau: Egal wie simpel das Programm gehalten ist ... man hat ganz schnell einen Memory-Overflow erschaffen oder das Programm läuft - wie bereits erwähnt in eine Exception.
Was du an ihrer Kritik allerdings nicht verstanden hast ist die Tatsache, dass es nicht darum geht, ob das Script im Nutzerkontext oder in dem eines anderen Benutzers beispielsweise über die Aufgabenplanung gestartet wird. Es geht rein darum die Ausführungszeit des Scriptes so minimal wie möglich zu halten. Alles andere ist unzuverlässig, egal ob nun Aufgabenplanung oder in Form eines Dienstes. Bei den oben beschriebenen 60 Minuten mag das noch nicht - oder nicht häufig - zu einem Problem werden, was Dinge wie den Memory Overflow betrifft. Bei häufigen Interaktionen mit empfindlichen Ressourcen und schlechter Weiterverarbeitung würde sich in den 60 Minuten maximal ein Overflow von 150 MB ergeben - erfahrungsgemäß. Das killt einen Rechner noch nicht, aber je weiter man die Zeit skaliert, desto problematischer wird das Ganze.
RegWrite ("HKEY_CURRENT_USER\Software\timer", "Datum", "REG_SZ", @YEAR & "-" & @MON & "-" & @MDAY)Das ist eine vermeidbare drastische Reduzierung der Lebenszeit der SSD ... Diese Zeile wird komplett ohne Bedingungen immer wieder in die Registry geschrieben. Bei 0.5 Sekunden pro Schleifendurchlauf sind das stolze 7200 Schreibaktionen, die nicht notwendig sind...
GerhardSchr: Stimmt schon, die beiden Routinen (Meldungen) sind ja auch noch unten drin, allerdings wäre es tatsächlich verhältnismäßig einfach, das Skript während der Meldung über den Tastmanager ausfindig zu machen und zu beenden. So läuft es einfach weiter, ganz unabhängig davon, ob die Meldung mit ok bestätigt wird, selbst nach 20 Sek. verschwindet oder durch den Taskmanager abgeschossen wird. Zumindest eine kleine Sicherheit, wenn auch nicht elegant. Wer lieber nur ein Skript verwendet, kann ja in Zeile 47 und 55 die Func wieder aktivieren und den Rest dort rausschmeißen.
Ich habe allerdings noch nicht getestet, ob ich es via Taskplaner auf Adminkonto laufen lassen könnte, damit wäre das Skript komplett gesichert und externe Funktionen unnötig. Mache ich mal bei Gelegenheit, vermutlich wird dann der Pfad in HKEY_CURRENT_USER\Software\timer\ ein anderer sein, da anderer User... Falls ich allerdings eine simple GUI mache, die mir die Zeiten für die verschiedenen Tage in die Reg schreibe (mit #RequireAdmin), dann sollte es wieder passen. Wäre nur schlecht, wenn das Skript dann greift, sobald ich mich normal am admin-Konto anmelde 
Runa: ist mir nicht ganz klar - das Skript schläft doch immer 1 Minute zwischendurch, wie sollte es zu den vielen Schreibzyklen kommen? Ich habe mir auch die Regwerte angeschaut während der Laufzeit und abgewartet, da passiert jeweils eine Minute lang gar nichts, wenn ich irgendwelche Werte ändere. Daher kann ich den Zyklus mit 0,5 sek nicht nachvollziehen.
Mit den Konten habe ich noch nicht genug Erfahrung, muss ich noch testen. Prinzipiell ist mir das normale Benutzerkonto am liebsten (dafür reicht die RUN in der registry), dann gibt es keine Konflikte. Dass natürlich ein Skript, das durchgehend läuft, eher gefunden oder beendet werden kann als eines, das irgendwie anders getriggert wird, kann ich mir schon vorstellen. Prinzipiell wird der große zeitliche Rahmen allerdings sowieso durch meine Anwesenheit 
und durch die Windows Jugendschutz-Einstellung gesetzt. Wenn da mal was schief geht, wäre das nicht wirklich schlimm... Wenngleich ich es eher für unwahrscheinlich halte...
Jeder, der hier im Forum bereits einmal einen Windows-Service in AutoIt geschrieben hat weiß ganz genau: Egal wie simpel das Programm gehalten ist ... man hat ganz schnell einen Memory-Overflow erschaffen oder das Programm läuft - wie bereits erwähnt in eine Exception.
Hmm, soll ich mir jetzt Sorgen machen, dass 1 Skript seit 2 Jahren und 3 Monaten (da wurde der PC zuletzt neu gestartet) ohne Murren als Dienst 24/7 arbeitet? 
Auch ein neuer Dienst, installiert Anfang August, weigert sich bisher beharrlich Schwierigkeiten zu machen. 
Ich denke, man sollte nicht pauschal urteilen. Mir persönlich ist es noch nie passiert, dass ein (endgültig fertiggestelltes) Skript den Overflow-Tod gestorben ist.
Hmm, soll ich mir jetzt Sorgen machen, dass 1 Skript seit 2 Jahren und 3 Monaten (da wurde der PC zuletzt neu gestartet) ohne Murren als Dienst 24/7 arbeitet?
Ich denke, man sollte nicht pauschal urteilen. Mir persönlich ist es noch nie passiert, dass ein (endgültig fertiggestelltes) Skript den Overflow-Tod gestorben ist.
Ich urteile nicht pauschal. Ich sage bloß, dass es sehr schnell passieren kann. Es kommt ja auch an, welche Funktionen man verwendet. Das mit dem Overflow hatte ich zum Beispiel bei häufigen FileWrites. Und das obwohl ich Handles verwendet habe und die immer wieder geschlossen habe... 
Es kann schnell passieren, muss es aber nicht. Man sollte es aus meiner Sicht dennoch nicht schlicht ignorieren. Natürlich kenne ich meine "Pappenheimer" mittlerweile auch. Es ist schnell klar, welche Funktionen da so bescheuert sind.
@Mokkaschnitte: Gehe ich zu Hause noch mal drauf ein. Von unterwegs ist das sehr nervig.
@Bisohade,
also ich sprech nun auch mal mit meien Scripten die seit Monaten laufen und sich beharrlich weigern abzustürzen. Aber vielleicht liegt da daren, dass ich nur einfachen Code schreibe Ich schließe mich BugFix an !!!!!!
@ misterspeed
ich möchte mal wissen wie man eine tief im Sytem verankertes Scribt mit Trivialnamen finden soll? --- > Gar nicht !
Bei der Masse von System Dateien! Denk mal darüber nach wie groß alleine eine cleane win Installation ist - ist das nahezu unmöglich. Gleiches gilt für Reg Einträge. Ich halte da einen zusätzlichen Account schon für auffälliger. Von Einträgen im Taskplaner will ich mal gar nicht reden.
Ich hatte es weiter oben schon mal -- warum einfach wenn es auch kompliziert geht?
Gruß
Peter
Runa: ist mir nicht ganz klar - das Skript schläft doch immer 1 Minute zwischendurch, wie sollte es zu den vielen Schreibzyklen kommen?
Ich habe genau eine Bedingung überlesen gehabt, die wirklich dazu führt dass in der Regel eine Minute geschlafen wird. Alles gut.
@peter S. Taler: Muss man dich darauf hinweisen, dass dein Post ziemlich deutlich aussagt, dass du entweder meinen letzten Post nicht gelesen hast, oder ihn schlicht nicht verstanden hast?
wenn man sich anschaut, wieviele sachen in 1-3sekunden in der registry gelesen und geschrieben werden....oh man
Könntest auch ne kleine Gui mit transparents schreiben, die Aktiviert voll sichtbar wird und auf dem Desktop liegt und die verbleibende Zeit anzeigt. Wäre auch noch nen schönes kleines Script zum üben
Ich hab sowas mal als Notizfenster geschrieben, mit Alarm (Counter), der dann Musik abspielte,...
oder wenn die letzen minuen angebrochen sind mit ToolTip arbeiten....
dann sehen die kids es auch im game (denke ich zumindestens)
Kommt drauf an. Alle Games, die über OpenGL, DirectX,... Arbeiten und im Vollbild laufen, sind im Vordergrund. Dort funktioniert auch WinSetOnTop nicht... Tooltips werden vermutlich auch nicht funktionieren. Die MsgBox aber auch nicht. Dort in den Vordergrund zu kommen ist schwer. Eventuell das Spiel minimieren, oder ähnliches (ALT+TAB).
@ misterspeed
ich möchte mal wissen wie man eine tief im Sytem verankertes Scribt mit Trivialnamen finden soll? --- > Gar nicht !
Bei der Masse von System Dateien! Denk mal darüber nach wie groß alleine eine cleane win Installation ist - ist das nahezu unmöglich. Gleiches gilt für Reg Einträge. Ich halte da einen zusätzlichen Account schon für auffälliger. Von Einträgen im Taskplaner will ich mal gar nicht reden.
Ich hatte es weiter oben schon mal -- warum einfach wenn es auch kompliziert geht?Gruß
Peter
Zu deiner ersten Frage wie man auffällige Prozesse identifiziert:
1. In einem 64bit Betriebssystem laufen alle Systemprozesse normalerweise als 64bit Version. Macht man den Fehler sein "getarntes" Script als 32bit Script zu kompilieren sticht einem das im Taskmanager sofort ins Auge.
2. Systemdienste wie die svchost.exe laufen normalerweise im Kontext SYSTEM, LOKALER DIENST oder NETZWERKDIENST und nicht im Kontext eines Benutzers.
3. Windowssystemdateien haben einen definierten Speicherort im System. Liegt dein Script aufgrund des identischen Dateinamens woanderst (selbst wenn es in den Untiefen des Windowsordners versteckt ist) stimmt etwas nicht. Über den Taskmanager kann man den Dateipfad eines jeden Prozesses öffnen.
4. Microsoft Software ist signiert. Die Dateieigenschaften deines Scriptes veraten dich sofort.
5. Virenscanner werden gerne hellhörig wenn man derartiges tut. Natürlich kannst du eine "unauffällige" Ausnahmeregel dafür anlegen, sofern nötig.
6. Auffällig hohe Prozessorlast oder atypischer RAM Verbrauch des Prozesses fallen ebenfalls auf.
Man kann diese Liste sicher noch endlos fortsetzen. Von alternativen Taskmanagern die weitaus mehr Infos liefern und über diverse andere Analysetools brauch ich wohl nicht sprechen.
Zu deiner Frage "warum einfach wenn es auch kompliziert geht?"
Vielleicht hast du mich auch nur nicht verstanden. Etwas zu verstecken und zu hoffen, dass es niemand findet ist kein Schutz, sondern einfach nur "einfach". Punkt!
Man braucht soetwas überhaupt nicht verstecken. Durch die Infomeldungen wird der Benutzer ohnehin über die Existenz eines Überwachungsprozesses informiert, bzw. schon zuvor durch seine "Vorgesetzten" aka Eltern. Ich kann das Script also genausogut direkt auf dem Benutzerdesktop platzieren. Das Einzige was ich tun muss ist es dafür zu sorgen, dass der Benutzer keine Rechte hat das Script zu löschen und zu beenden. Das selbe gilt für die Rechte zum Verändern der Konfiguration und der Daten des Programmes. Dafür braucht man nichts anderes als einen weiteren Benutzeraccount und die Windows Boardmittel zum setzen von Dateiberechtigungen (und der Registryberechtigungen). Eine simple (einfache um bei deinen Worten zu bleiben) administrative Aufgabe die mit wenigen Mausklicks erledigt ist und sich sogar per Installationsscript oder 3-4 Batchcodezeilen automatisieren lässt.
Eine rechtetechnische Absicherung ist sowieso notwendig wenn man nicht möchte, dass die unbedarften Kinder den PC mit Viren und sonstigen Softwareinstallationen verseuchen.
Ich bin im Übrigen als hauptberuflicher Administrator immer wieder erstaunt und dankbar darüber wie diletantisch sich diverse Schadsoftware zu verstecken versucht. 
Unglaublich was das Thema "Kindersicherung" für Emotionen freisetzt
Ich denke wir (ich eingeschlossen) denken viel zu Kompliziert. Das was Mokkaschnitte gemacht hat ist schon ein sehr gute Tool. Ich bin mir sicher er wird es bis "zur Markteinführung" optimieren.
Die Mythten und Ängste das ein selbstgeschriebens Script den Rechner "dicht" macht, hängt nur vom Scripter ab. Wenn ich schlammpig Programmiere wird auch in die Hose gehen - andersrum laufen bei anderen und bei mir AutoIT Scripts als Serverdienste und die im 7/24 Stunden Betrieb! Und nix hängt und nix verbracht viel Speicher!
Auch die Aussage das auf einen 64Bit Windows (egal ob Client oder Server) nur 64 Bit-Programme laufen ist falsch - siehe Taskmanager - da gibt es genug Prozesse von MS die noch 32Bit sind (warum auch nicht). Meistens hat man auch das eine oder andere Programm / Applikation installiert und die gibt es oft nur (oder noch) als 32Bit Version.
Die Belastung einer SSD mit Regkey lesen und schreiben ist egal da es sowieso vom Betriebsystem eine Zeitlang gecachet wird bevor es dann wirklich auf die Disk kommt. Abgesehen davon sind vom BS und Programme so viele permanente Zugriffe in die Registierung da kommt es auf ein paar mehr oder weniger auch nicht an!
Zum Thema "Prozess beenden": Hat der User nur Userrechte wird er es nicht schaffen einen Systemprozess oder einen Prozess eines anderen Benutzers zu killen.
Ob das Hauptprogramm als Admin oder System gestartet wird ist geschmacksache. Mein Vorschlag war halt für die Aufgabenplanung (ist ja auch eine Aufgabe). Aber wie heißt es so schön: viele Wege führen nach Rom
lg
Racer
