Beiträge von misterspeed

Was erwartest du bitte? Zum einen kennst du bereits alle für dein Vorhaben notwendigen Funktionen...

send(...)
sleep(...)
; while-Schleife

... zum anderen war der Hinweis auf das passende Unterforum ebenfalls angebracht nachdem du offensichtlich selbst zu faul bist die noch fehlenden send() und sleep() Zeilen oben selbst in dein Script einzubauen und dafür lieber 5€ zahlen möchtest.

Mehr gibt es doch eigentlich auch nicht zu sagen. Wo dein Problem hier liegt erschließt sich mir nicht.

Selbst mit runas wirst du da schon Probleme bekommen. Bin mir nicht 100% sicher, aber wenn der User bereits eine Verbindung mit dem SMB Server hat kann dein Script vermutlich keine eigene Verbindung zum networkshare mit einem anderen Account aufbauen. Wie dem auch sei, selbst wenn es geht würde das zwangsläufig bedeuten, dass du in deinem Script Zugangsdaten für den berechtigten User Account hinterlegen musst. Das ist fast genauso als ob du den Anwender gleich in eine Gruppe packst die permanent Rechte auf die betreffende Datei hat. Was spricht da eigentlich dagegen? Offensichtlich gestehst du dem Anwender ja das Recht ein die Datei zu verändern, warum soll er das dann nicht nachweisbar über seine eigenen Zugangsdaten tun dürfen? Wenn du dafür einen allgemeinen Account verwendest kannst du nicht mehr nachvollziehen wer die Datei evtl. böswillig verändert oder gelöscht hat.

Eine wesentlich sicherere Lösung wäre eine Client / Server Anwendung. Den Server lässt du auf einem beliebigen Server System über einen berechtigten Benutzeraccount laufen, der Client schickt seine Daten dann an das Serverscript und lässt dieses die Schreiboperation vornehmen. Vorteil liegt klar auf der Hand. Es werden keine Zugangsdaten an den Client herausgegeben und du kannst im Serverscript sogar zusätzliche Prüfungen einbauen, die sicherstellen, dass die Daten die der Client gerne geschrieben haben möchte korrekt und nicht bösartig sind. Neben dieser Grundfunktion kann dein Serverscript bei Bedarf auch alle Clientscripte über eine Updatefunktion auf gleichen Versionsstand bringen, das erleichtert die spätere Verwaltung bei notwendigen Änderungen am Script.

Zitat von timee000

Hey
Wenn ich das jetzt richtig erkannt hab, hast du die Variablen mit in die " " gepackt. Nur reiner Text wird in " " geschrieben. Variablen werden immer mit

[autoit]

("Nur Text" & $variable)

[/autoit]

eingefügt. Probier es mal mit:

Hast du nicht richtig erkannt! Das was er als "$3 $2 $1"in den Anführungszeichen hat sind keine eigenen Variablen, sondern Backreferences auf die Teiltreffer des RegExp Pattern, also mehr oder weniger temporäre Variablen die die RegExp Funktion verwendet um seine Zwischenergebnisse zu speichern. Durch ansprechen dieser Zwischenergebnisse wird der String umsortiert. Das ist so syntaktisch jedenfalls korrekt und auch beabsichtigt.

Das was er durch eine Variable ersetzen wollte sind die Stringteile "aaa" und "bbb".

Zitat von sanni74

So wie ichs jetzt sehe, kann ich im ersten replace (reiner Textumbau) keine Variablen einfügen.

Bezweifle ich. Ich verwende zwar normalerweise keine RegExp Funktionen aber so sollte das auch in einem Rutsch funktionieren:

$sText = StringRegExpReplace($sText, '(.{3}) (.{4}) (.{5})', $deineVariable & ' $3 $2 $1 konstanter_Text_der_angehängt_werden_soll ' $weitereVariable) ; die Formatierung ändern

Im englischen Forum findet man einen entsprechenden Code. Leider funktionierte der nicht ohne Anpassung in einer deutschen Windows Installation. Unten findest du meine Anpassung, die wir bei uns erfolgreich verwenden. Eine Neuanmeldung ist nicht nötig, die sichtbaren Einträge in Taskbar und Startmenü verschwinden / erscheinen sofort und die zugehörigen Verknüpfungen werden gelöscht / erstellt.

EDIT: Fehler beim "Starmenü lösen" sollte behoben sein...

Dein Beispielscript funktioniert bei mir fehlerfrei, sowohl bei Aktionen innerhalb des Fensters, als auch bei Aktionen zwischen Fenster und anderen Windows Explorer Instanzen.

Autoit: 3.3.6.1
Windows: 7 Pro x64 (aktueller Updatestand)

Hier einige Vermutungen woran es liegen könnte:

1. Autoit Version -> Teste eine der alten bewährten Versionen 3.3.6.1 / 3.3.8.1
2. Unterschiedliche Benutzer(rechte), z.B. wenn du das Script explizit als Administrator oder mit einem anderen Account ausführst.
3. Sonstige Windowseinstellungen -> Teste das Script auf einem sauberen neu installierten System ohne weitere Einstellungen (z.B Gruppenrichtlinien aus eurer Domäne)
4. Virenschutz -> Teste ob das Script bei deaktiviertem Virenschutz funktioniert, wenn ja erstelle entsprechende Ausnahmen für dein Script.
5. Störende Software, z.B. weitere Scripte oder sonstige Programme die mit der Zwischenablage arbeiten oder Maus Interaktionen abfangen (Hook) -> Teste das Script auf einem sauberen neu installierten System ohne weitere Scripte / Software

PS:
Da ich evtl. Verwendung dafür habe... kann man den Explorer auch so einbetten, dass eine Navigation möglich ist? Bei deiner Variante kommt man aus einem Unterordner leider nicht mehr zurück.

Dropbox hat doch jedemenge API's. Du kannst also wunderbar mit der winhttp.au3 arbeiten.

https://www.dropbox.com/developers

Zitat von minx

Wozu wird das Skript gebraucht?

Ist doch ziemlich offensichtlich wofür man so ein Script verwendet...

Aber ausnahmsweise hier einige Anmerkungen, da er ja immerhin eine Frage zur Programmlogik hat:

Fehler 1 wurde ja schon genannt.
Fehler 2 dürfte sein, dass der ELSE Zweig niemals eintritt, weil pixelsearch soweit ich die Hilfe verstehe immer ein Array zurückgibt und im Fehlerfall lediglich @error setzt. Du solltest also den Wert von @error in deiner if Bedingung verwenden, so wie es auch im zugehörigen Hilfebeispiel gemacht wird.
Fehler 3 ist die Abbruch Bedingung der do...until Schleife. Du willst abbrechen wenn die Farbe gefunden wurde, andernfalls willst du es 10 mal probieren und dann abbrechen. Deine Abbruchbedingung ist aber immer schon beim ersten Durchlauf der Schleife erfüllt, weil du abbrichst wenn der Wert kleiner oder gleich 10 ist. Das ist immer der Fall, egal ob du nun den if oder den else Zweig passierst. Der Wert ist entweder 1 oder 10, also beides mal kleiner oder gleich 10. Die Bedingung sollte also wohl größer oder gleich 10 lauten. Alternativ kannst du dir den Kram auch gleich schenken und ein exitloop einbauen sobald die Farbe gefunden wurde und eine for...to Schleife verwenden die maximal 10 mal durchläuft wenn nicht vorzeitig verlassen wird.

Und zu guter letzt lies dir bitte die Forenregeln durch. Spielebots haben hier nichts verloren, dafür gibt es andere Foren.

Kann das bei mir nicht nachvollziehen. Der processexplorer zeitgt mir beim Beispielscript immer nur einen Prozess an, egal ob nun mit UPX oder ohne. Meine Vermutung ist also, dass es entweder mit der neuen Autoit Version zusammenhängt (ich verwende hier noch 3.3.6.1 bzw auf einem anderen System 3.3.8.1) oder aber mit deiner Antivirenlösung. Letzteres könntest du ja mal durch kurzzeitiges Deaktivieren testen.

Hab das zwar nie beobachtet, aber ich würde mal vermuten, dass du UPX verwendest und deswegen ein temporärer Prozess entsteht (eigentlicher Programmcode der exe wird entpackt und danach ausgeführt).
Mehr zu UPX kannst du auch im wiki Artikel lesen: http://de.wikipedia.org/wiki/UPX

Solltest du UPX nutzen kann der Start unter anderem auch länger als normal dauern, weil Virenscanner solches Verhalten als verdächtig ansehen und dann sehr genau prüfen was da eigentlich zur Laufzeit entpackt und ausgeführt werden soll. Einfachste Lösung für deine "Probleme" ist also vermutlich der Verzicht auf UPX.

Die Frage ist aber auch ob man einen KVM Switch zwingend permanent bzw. häufig benötigt. In der Regel sollte doch auch eine Remoteverbindung ausreichen (RDP/SSH/VNC...). Ein physikalisches Umschalten ist eigentlich nur dann nötig wenn man entweder aufwendige graphische Dinge tun will (RemoteFX wäre hier evtl Alternativ noch möglich) oder wenn eben keine Remoteverbindung möglich ist (Bios Zugriff, PreBoot Umgebung...)

Zitat von Tweaky

@ misterspeed
bei deiner Version kommt bei mir ein Fehler (Win 7 pro 64bit SP1)

Sorry lag am altbekannten Forenbug. Hab den Code nun als Dateianhang hinzugefügt.
Stammt aber ohnehin nicht von mir, sondern irgendwo aus dem englischen Forum...

Hier auch noch eine der zahlreichen Varianten um die vorhandene Windows User zu ermitteln:

EDIT:
Script entfernt und als Dateianhang hinzugefügt.
Grund: Forenbug der Backslashes aus dem Quellcode entfernt...

Die Prüfung ob der Acoount vorhanden ist kann dann anschließend einfach mit einem

_arraysearch()

erledigt werden.

Deswegen hatte ich ja auch "der relevanten Stellen" geschrieben Dass hier niemand tausende Zeilen GUI Code oder anderen Code der nichts mit dem Fehler zu tun hat braucht sollte ja klar sein. Aber zumindestens die rekursive Funktion sollte man komplett mitliefern, denn da schlummert der Fehler ja anscheinend.

EDIT:

Andy

Wie gesagt ohne die entfernten Stellen kann man nicht sagen ob er entsprechende Vorkehrungen getroffen hat. Die Variable $sString könnte abhängig von $sTest sein, d.h. bei entsprechender Änderung von $sTest in jeder Stufe kann zum einen stringbetween in der nächsten Stufe erfolgreich sein und zum anderen könnte vorher ein return kommen wenn $string keinen oder einen ungültigen Wert hat. Ohne Code aber alles nur theoretische Annahmen, vermutlich liegst du genau richtig und er hat eben keine entsprechende Abbruchbedingung implementiert.

Zitat von Andy

führt dazu, dass im Fehlerfall der Fehler immer wieder produziert wird, so lange, bis die maximale Rekursionstiefe erreicht wird!

Nicht zwangsläufig. Anhand des gekürzten Quellcodes kann man darüber keine Aussage machen. Die Variable $sTest, welche an den rekursiven Aufruf übergeben wird könnte zuvor geändert worden sein und muss nicht mehr den ursprünglichen Inhalt haben. Somit muss der rekursive Aufruf nicht zwangsläufig ebenfalls zum Fehler führen.

Ansonsten stimme ich den anderen zu. Ohne exakte Fehlermeldung und ungekürzten Quellcode der relevanten Stellen wird hier kaum jemand helfen können.

Warum speicherst du die Daten erst unverschlüsselt und verschlüsselst sie dann im Anschluss? Verwende doch einfach das hier und schreibe gleich den verschlüsselten String in eine Datei:

#include <String.au3>
_stringencrypt()

Du verwendest fileopen / filewrite und fileclose im übrigen falsch.

Filewrite nimmt entweder ein handle einer Datei oder den Pfad zu einer Datei entgegen. Übergibst du nur einen Pfad wird automatisch ein fileopen und ein fileclose durchgeführt, allerdings eben mit der entsprechenden Standardeinstellung für fileopen. Wenn du einen bestimmten Lese oder Schreibmodus erzwingen willst musst du das fileopen selbst durchführen und statt einem Pfad das handle von fileopen an die filewrite Funktion übergeben, in diesem Fall muss das fileclose ebenfalls selbst durchgeführt werden. Fileclose erwartet immer ein file handle und kann garnichts mit Pfaden anfangen. Ein weiterer Grund fileopen und fileclose selbst durchzuführen wäre wenn du mehrmals in die gleiche Datei schreiben willst. Dadurch minimierst du dann die IO Last, da die Datei solange geöffnet bleiben kann bis du fertig mit deinen Schreibvorgängen bist.

Richtig wäre also sowas hier:

$pfad = "C:\test.txt"
$handle = fileopen($pfad,...dein gewünschter modus...)
$schreibergebnis = filewrite($handle,"test")
fileclose($handle)

; oder eben nur so
filewrite($pfad,"test")

Zitat

Kann ich das mit dem Masterpasswort auch anders Lösen? So ist das PW ja in beiden EXE´s. Für einen evtl. Angreifer ja sehr leicht zu durchschauen.

Nunja wie oben erwähnt macht es aus Sicherheitssicht keinen Unterschied ob du dir nun einen abbrichst und das richtige Benutzerpw in einer userspezifischen exe speicherst oder ob du ein masterpw darin speicherst. Beides kann man mit dem nötigen Wissen leicht aus der exe extrahieren. Der Weg über die verschlüsselte Datei macht für den Angreifer nur ein klein wenig mehr Arbeit, schützt aber auch nicht wirklich besser. Dafür ist es aber für dich leichter umzusetzen.

Prinzipiell könntest du das Masterpw aber auch dynamisch erzeugen und so an die HW des PCs binden. Hat jemand nun nur Zugriff auf dein Script und die Datei des Benutzers so benötigt er zusätzlich noch die verwendeten HW Daten die du zur Erzeugung des Masterpw nutzt. Er kann die Datei also sehr wahrscheinlich nur auf dem betreffenden Rechner entschlüsseln, was einen Angriff schwieriger machen dürfte.

Hier mal ein Beispiel wie du einen Masterkey erzeugen kannst der auf jedem Rechner und für jeden angemeldeten Benutzer am Rechner anderst wäre:

$key = @computername & @username & getMAC() & "alles was dir sonst noch an eindeutigen Merkmalen einfällt"
func getMAC()
; google danach wie man die MAC der primären Netzwerkkarte ermittelt
endfunc

Keine Ahnung ob ich eure Situation richtig verstehe, aber die Lösung erscheint mir dann doch etwas seltsam. Zum einen sollte die PW speichern Funktion des Emailclients immer funktionieren, also würde ich zunächst dort ansetzen und prüfen warum das bei manchen eurer User nicht der Fall ist. Zum anderen hat die PW speichern Funktion ja nichts damit zu tun wo nun euer Exchange Server steht oder in welcher Domäne sich der Rechner befindet.

Wie dem auch sei... deine Frickellösung ist nicht nur umständlich sondern auch unsicher. Jeder kann eine Autoit exe Datei leicht dekompilieren. Die Passwörter sind also alles andere als sicher gespeichert, das selbe gilt natürlich auch für die Speicherung im Mailclient. Es gibt genügend Tools um gespeicherte Passwörter in gägnigen Mailclients und Browsern auszulesen. Da deine Lösung also ohnehin unsicher ist würde ich sie zumindestens einfacher gestalten. Wozu soll das PW in der exe selbst gespeichert werden? Schreib einfach dein Automatisierungsscript und speichere bzw. lese das gespeicherte PW in /aus einer verschlüsselten Datei. Passende crypt Funktionen bietet dir Autoit jedenfalls. Ein Angreifer muss dann zunächst deinen Quellcode dekompilieren, das MasterPW und den Verschlüsselungsalgorithmus finden und kann danach erst das gespeicherte PW entschlüsseln. Ist natürlich genauso unsicher und nur minimal mehr Aufwand für den Angreifer, aber wenigstens brauchst du dir selbst keinen Abbrechen um das ganze halbwegs sicher zu realisieren.

Zum Automatisierungsteil deines Scriptes:

Du solltest auf send() verzichten. Zum einen kann es Probleme mit Sonderzeichen geben, zum anderen ist send() langsam und fehleranfällig wenn Benutzerinteraktion dazwischen kommt. Verwende besser contrlsend oder controlsettext und zum bestätigen des Dialogs controlclick. Details zu den Funktionen entnimmst du der Hilfe oder der Forensuche.

Genau. Und für weitere Fensteraktionen auf Basis der Control ID oder anderen eindeutigen Merkmalen kannst du dir grundsätzlich auch die anderen controlXXX Funktionen in der Hilfe anschauen.

Neben dem Scite Tool au3info gibt es im übrigen noch diese Alternativen zur Ermittlung der benötigten Fensterdaten:

https://autoit.de/index.php?page=Thread&amp;threadID=32511

Mal davon ab, dass es mit Sicherheit direktere und einfachere Wege gibt um "termsrv.dll" so zu modifizieren wie gewünscht (google soll da sehr gesprächig sein) wundere ich mich doch ein wenig, warum dieses Thema noch nicht geschlossen wurde. Bei jeder noch so unwichtigen Webseite verweist man sofort auf die AGB und interpretiert was weiß ich für Dinge in eher uneindeutige Formulierungen bezüglich Automatisierung. Wie dem auch sei... hier unterstützt man jedenfalls die Umgehung von Lizenzbedingungen bzw. die Aktivierung von Features welche sicher nicht ganz unabsichtlich den Server Versionen des Betriebssystems vorbehalten sind.

Nettes Tool, ich frag mich grad nur wie einer deiner Anwender sich durch den Helpdesk hangeln soll um "Maus/Tastatur geht nicht" auszuwählen.

Naja was würdest du mit jemandem machen der dir hunderte male und pausenlos den gleichen Satz ins Ohr flüstert? Du würdest dir den Mist sicher nicht lange anhören und entsprechend reagieren.

Das selbe wird auch der Webserver machen... du handelst dir sehr wahrscheinlich einen temporären IP Ban ein damit deine Sinnlosanfragen den Server bzw. dessen DB nicht in die Knie zwingen.