Beiträge von misterspeed

  • Func innerhalb Func möglich?

    Die Frage ist doch warum du mit dieser GUI interagieren musst und was du genau damit tun willst.

    Eine Methode wäre von Anfang an alle GUI's und deren Controls global zu erzeugen und je nach Programmzustand sichtbar oder unsichtbar zu machen. Das ist die flexiblste Veriante, da du jederzeit auf alle Controls Zugriff hast.

    Eine andere Variante wäre, dass es sich um diese zweite GUI um keine besonders relevante GUI handelt. z.B. nur um einen Einstellungsdialog. Hier kannst du problemlos die GUI temporär in einer extra Funktion jedesmal neu erstellen und die betreffenden Werte die dort hinterlegt oder geändert werden sollen in eine Konfigurationsdatei scheiben bzw. aus dieser lesen.

    Aber vielleicht hilfts auch wenn du dein Programm näher beschreibst.

  • Func innerhalb Func möglich?

    Dafür gibts globale Variablen oder Rückgabewerte die du mit return an die aufrufende Funktion zurückgibst. Bei mehreren Variablen / Werten gibst du eben ein Array zurück.

    Achja und die Antwort lautet "Nein" geht nicht, was du vermutlich selbst schon festgestellt hast.

  • Eigenschaften von allen Buttons ändern

    Da es manchmal auch von Vorteil ist wenn man den Zweck einzelner Buttons anhand des Variablennamens im Quellcode erkennen kann bietet sich neben der Array Variante auch die strukturierte Erstellung der GUI Controls an. dabei kann das nicht sichtbare "dummycontrol" hilfreich sein.

    Beispiel:


    Welche Lösung mehr Sinn macht kommt auf den Anwendungsfall an. Wenn die Controls alle die selbe Aufgabe haben (z.B. ein Schachbrett aus Buttons) ist ein Array mit Sicherheit die sinnvollere Variante. Gerade bei einem Schachbrett oder Vergleichbarem wird die Controlerstellung so auch extremst vereinfacht und verkürzt.

  • Laufzeit Dienststatusabfrage

    Öhm dein Script oben ist fehlerhaft. Du prüfst zweimal die CMD Variante, daher auch identische Ergebnisse.
    Hier die echten Ergebnisse (einmal CMD, einmal WMI):

    Code
    Ergebnis: CMD True t=0.286 s 	 WMI True t=0.065 s
Ergebnis: CMD True t=0.286 s 	 WMI True t=0.055 s
Ergebnis: CMD True t=0.286 s 	 WMI True t=0.054 s
Ergebnis: CMD True t=0.286 s 	 WMI True t=0.055 s
Ergebnis: CMD True t=0.286 s 	 WMI True t=0.053 s

    WMI ist bei mir deutlich schneller, was auch nicht wirklich verwundert, da durch den CMD Aufruf und die Auswertung sehr viel Zeit verloren geht.

  • Laufzeit Dienststatusabfrage

    Code
    Ergebnis: CMD True t=0.286 s 	 WMI True t=0.286 s
Ergebnis: CMD True t=0.286 s 	 WMI True t=0.286 s
Ergebnis: CMD True t=0.287 s 	 WMI True t=0.286 s
Ergebnis: CMD True t=0.286 s 	 WMI True t=0.286 s
Ergebnis: CMD True t=0.286 s 	 WMI True t=0.286 s

    Verwende allerdings noch eine alte Autoit Version und musste dein Return Statement aufgrund der neuen Schreibeweise durch eine if Bedingung ersetzen. Ansonsten aber das selbe Script.

    OS: Win7 Pro x64
    System: i7-4771 3,5Ghz mit SSD als System Festplatte

    Evtl. hat dein aktuelles System eine langsame Festplatte oder der Virenscanner wirkt sich negativ auf die Ausführung aus.

  • Internet Explorer Login -> return success

    Naja wie schon gesagt wurde gibt es keine allgemeine Antwort darauf wie man einen erfolgreichen Login testet. Das muss man individuell für jede Webseite anhand der dort vorhandenen Merkmale entscheiden.

    Eine Methode wäre auf die Fehlermeldungen zu prüfen die bei fehlerhaften Logins erscheinen. Die können aber über die Zeit sehr unterschiedlich ausfallen und du wirst evtl. niemals alle Varianten zu Gesicht bekommen (z.B. Hinweis auf eine temporäre Störung, Datenbank- oder PHP-Fehlermeldung usw.)

    Etwas zuverlässiger ist es wahrscheinlich auf Merkmale zu prüfen die nur im eingeloggten Zustand sichtbar sind. Auf so ziemlich jeder Seite wäre das z.B. ein Link oder Button um sich abzumelden. Ist der im Quelltext aufzufinden kann man davon ausgehen, dass man derzeit angemeldet ist. Meist ändern sich die Links oder bezeichnenden IDs der Buttons auch nicht. Kann aber natürlich trotzdem irgendwann passieren, dass die Seite so umstrukturiert wird, dass deine Prüfung falsche Ergebnisse liefert. Der Vorteil bei dieser Positiv Prüfung wäre aber, dass du sofort mitbekommst wenn deine Prüfung nicht mehr funktioniert und dein Script trotz Login Erfolg permanent der Meinung ist du bist nicht angemeldet.

  • Probleme mit MYSQL Connection - MySQL OBC 3.51 Driver

    Wenn du dir die UDF mal anschaust wirst du evtl. feststellen, dass die Funktion "_Query" ein Objekt zurückgibt (Google Stichwort Resultset). Dieses Ergebnis Objekt muss dann von dir Elemente weise ähnlich wie ein Array durchgegangen werden um alle Ergebnisse zu erhalten. Beispiele wie man das macht kannst du einigen anderen Funktion in der UDF entnehmen, denn einige Funktionen liefern dir anstelle eines Resultsets gleich ein Array oder auch mal nur einen Integer Wert, wie die Anzahl der Spalten.

    Kleiner Hinweis noch zu deinem bisherigen Versuch.... ein Array kann man nicht in einer msgbox ausgeben, dafür verwendet man die Funktion "_arraydisplay"

    EDIT: Achja und natürlich fehlen in deinem Script die Verbindungsdaten der Datenbank. Ich nehme an du hast diese nur für dein Posting hier entfernt?

  • Drag&Drop funktioniert unter Win 10 nicht

    Hab mich aus Neugierde nun doch mal in das Thema eingelesen und wie vermutet hat es Sicherheitsgründe warum bestimmte Window Messages nicht an Fenster/Prozesse mit erhöhten Rechten durchgereicht werden.

    Hier ein paar informative Links zum Thema. Wirklich sehr interessant wie man das ausnutzen konnte (letzer Link):

    http://blogs.msdn.com/b/patricka/arc…l-and-uipi.aspx
    http://www.tenforums.com/general-discus…sing-issue.html
    http://www.net-security.org/article.php?id=162&p=1

    Dem Blog Beitrag von Microsoft zu Folge wäre es wie schon von mir vorgeschlagen eine Lösung die GUI im selben Kontext wie die explorer.exe laufen zu lassen. Eine weitere Möglichkeit ist evtl. auch das hier ChangeWindowMessageFilterEx. ;)

  • .exe mit .exe aufrufen, stapeln sich die Prozesse?

    Ich würde Reboots grundsätzlich solange rauszögern bis es wirklich notwendig wird. Normalerweise kann man problemlos zig Programme und Treiber nacheinander (teilweise sogar paralell, davon rate ich aber ab) installieren und erst ganz am Schluss einen finalen Reboot machen. Sollte ein hartnäckiges Programm dabei sein stellt man dieses ganz ans Ende der Installationsroutine.

    Ich würde ebenfalls darauf verzichten jeden Installationsschritt in eine separate EXE zu verpacken, alleine schon wegen des Verwaltungsaufwandes bei Scriptänderungen. Ich zweifle sogar an, dass es notwendig ist für jedes Programm eine extra Funktion zu schreiben. Die meisten Programme sind als msi Pakete mit "silent" Installer verfügbar. Andere Software hat seine eigenen "silent" Commandline Parameter und nur ganz wenige Setups lassen sich letztlich nur durch GUI Automatisierung installieren. Du brauchst also nur eine Funktion für die Mehrheit aller Setups die evtl. je nach Programm verschiedene Parameter an die Setup.msi/exe übergibt. Am besten packst du diese variablen Dinge sogar in eine editierbare Konfigdatei, dann kannst du unendlich viele Programme hinzufügen ohne auch nur eine Zeile Code in deinem Installationsscript ändern zu müssen. Spezialisierte Funktionen brauchst du dann nur noch für den kümmerlichen Rest.

    Ansonsten ist dein Ansatz doch gut. Schreib in irgendeine Konfigdatei an welcher Stelle dein Script durch einen Reboot unterbrochen werden musste und dann mach da weiter wo du aufgehört hast.

  • begrenzte Nutzungsdauer am PC: Konzeption technisch umsetzbar? (Kindersicherung)

    Zitat von Kanashius

    Naja. Ums jetzt mal noch etwas weiter zu treiben:
    Wenn man einen Boot-Stick/CD erstellt und davon Bootet (z.B. Ubuntu) kann man einfach auf die Festplatte zugreifen und die Dateien löschen/bearbeiten, ob durch Benutzerrechte geschützt, oder nicht. Die absolute Sicherheit gibt es einfach nicht.

    Einfache Lösung: deaktivierter CD/USB Boot im Bios + Bios Passwort + abschließbares Gehäuse ;)

  • begrenzte Nutzungsdauer am PC: Konzeption technisch umsetzbar? (Kindersicherung)

    Zitat von Racer

    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.

    Hab ich ja auch nicht behauptet. Ich sprach von Windows System Prozessen und einfachen Methoden um auffällige Prozesse im Taskmanager zu entdecken. Wer seinen Prozess svchost.exe nennt fällt hier jedenfalls recht schnell auf wenn das Script im Taskmanager als 32bit markiert wird. ;)

    Das alleine ist natürlich noch nicht aussagekräftig, ich würde in solch einem Fall aber genauer nachschauen wenn ich auf der Suche nach einem "lästigen" oder unerwünschtem Programm bin.

  • begrenzte Nutzungsdauer am PC: Konzeption technisch umsetzbar? (Kindersicherung)

    Zitat von Peter S. Taler

    @ 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. :P

  • begrenzte Nutzungsdauer am PC: Konzeption technisch umsetzbar? (Kindersicherung)

    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.

  • truecrypt veracrypt device treiber ?

    Ich kann nur von Truecrypt sprechen, da ich Veracrypt nicht kenne. Soweit ich mich erinnere benötigt man für die Nutzung der Portable Version Administrator Rechte, damit besagter Treiber auf dem System einmalig(?) installiert werden kann und das Mounten virtueller Laufwerke möglich ist. Wenn man Treiberinstallationen von einem Netzlaufwerk anstossen will kommt einem die Benutzerkontensteuerung von Windows Vista und neuer gerne mal in die Quere. Auch Antivirensoftware kann auf sowas sehr allergisch reagieren. Da du keine weitergehenden Informationen über die IT Umgebung lieferst kann man hier aber nur raten woran es scheitern könnte.

    Ich würde empfehlen den Truecrypt Ordner zumindestens temporär auf eine Lokale Festplatte des Zielsystems zu kopieren und dafür zu sorgen, dass der erste Start der Portable Version mit erhöhten Rechten erfolgt (#requireadmin im startenden Script). Beim ersten Start sollte die Treiberinstallation dann durchlaufen und weitere Starts können evtl. auch mit Benutzerrechten direkt von einem Netzlaufwerk erfolgen. Leider ist die Dokumentation von Truecrypt aus dem Netz verschwunden seitdem der Autor die Entwicklung eingestellt hat. Dort waren denke ich Details über erforderliche Rechte in Verbindung mit der Portable Version beschrieben.

    Prinzipiell kann man die Treiberinstallation evtl. auch unabhängig per Windows cmdline Befehle durchführen. Hierfür werden in jedem Fall Administratorrechte benötigt und der Treiber sollte wie gesagt lokal vorliegen und nicht von einem Netzlaufwerk geladen werden.

  • Ich habe gar kein A --> Laufwerk

    Da auf meinen Systemen kein A:\ Laufwerk vorhanden ist und auch nicht von Autoit gefunden wird kann ich dir deine Frage nicht beantworten. Auch Windows XP habe ich gerade keines zur Hand. Allerdings ein Windows 2003, bei welchem ebenfalls kein A:\ Laufwerk gefunden wird.

    Nun wie dem auch sei. Evtl. befindet sich in deiner Registry noch ein verwaister Eintrag eines ehemals vorhandenen Disketten Laufwerks.

    Lies dich hier mal ein und teste evtl. das Löschen des betroffenen Eintrages (sofern einer vorhanden ist)

    http://diddy.boot-land.net/firadisk/files/mounteddevices.htm


    Prinzipiell verstehe ich aber nicht warum das nun ein Problem sein soll. Die Laufwerke A:\ und B:\ sind ohnehin seit Uhrzeiten mehr oder weniger reserviert und haben eine Sonderrolle. Ich würde die beiden Buchstaben grundsätzlich ignorieren und erst ab C:\ anfangen, sofern deine Software nicht mit Disketten hantiert.

  • Drag&Drop funktioniert unter Win 10 nicht

    Ohne es genau zu wissen würde ich einfach vermuten, dass unter Windows 10 die Benutzerkontensteuerung verbessert wurde oder standardmässig in einer höheren Sicherheitsstufe läuft. Das was du beschreibst sieht jedenfalls so aus, als ob Benutzeraktionen (du als einfacher Desktop Benutzer) mit GUI's welche im erhöhten Adminkontext laufen eingeschränkt wurden.

    Ein workaround wäre für mich die Teile des Scriptes zu trennen, sprich den GUI Teil des Scriptes nicht mehr mit erhöhten Rechten laufen zu lassen.

    Dein Hauptscript (GUI) also ohne Requireadmin aufrufen, erstmal unsichtbarer start, dann wird die UAC Abfrage durch den Start des administrativen Teils getriggert und anschließend die GUI sichtbar gemacht. Für den Anwender ist es dann nicht mehr ersichtlich, dass nur ein Workerprozess mit erhöhten Rechten läuft. Die strikte Trennung von GUI und funktionalem Teil erfordert zwar etwas mehr Aufwand, weil die Scripte untereinander kommunizieren müssen, dafür hast du aber auch einen separaten Prozess der dafür sorgt, dass deine GUI stets reagiert und nicht durch Arbeitsprozesse blockiert werden kann.