Tausche mal
StringInStr($line3[0], "Bevollmächtigter des Erzeugers")
gegen
StringInStr($line3[0], 'Bevollmächtigter des Erzeugers')
und teste dann noch mal.
Das macht in AutoIt absolut keinen Unterschied da beide Zeichen gültige Stringliterale darstellen.
Hier kann ich dann abfragen ob die Funktionsrückgabe "Fehler" lautet und wenn nicht dann rechne mit dem Rückgabewert.
Hier kommt immer entweder eine Zahl inklusive 0 Komma und -Vorzeichen oder eben Fehler(Falls keine Zahlen enthalten sind) heraus.
Rückgabewerte zu mischen ist kein guter Code da du ambivalente Typen hast. Return lieber eine 0 und setz @error.
Du könntest mit WinAPI SetParent auch ein normales IE-Fenster erstellen und es als Embedded aussehen lassen wenn du wirklich die Funktionalitäten des neuesten Browsers brauchst.
Und wieso löscht du deinen Beitrag? Du hättest ihn einfach editieren können bzw. die Lösung extra posten damit andere Nutzer in der Zukunft sie lesen können.
Du verwendest Spezialausdrücke die für Send/ControlSend und derlei Konsorten gedacht ist, was du brauchst ist das Makro @TAB.
Du könntest mit einer entsprechenden XML-UDF direkt die Blöcke rausholen die du brauchst.
Ansonsten kannst du uns ja mal deinen Code zeigen mit dem du den die benötigten Blöcke mit _StringBetween unterteilst.
Du siehst den Wald vor lauter Bäumen nicht.
Du kannst das Fenster dorthin verschieben und dann maximieren.
Man könnte demnach :
1. PROG1.exe - z.B. ein FreeBasic-Programm :
- enthält das verschlüsselte Passwort und eine Decodefunktion zum entschlüsseln
- den Hash des 'kompilierten' AutoIt-Skriptes
- einen Aufruf des 'kompilierten' AutoIt-Skriptes- nur falls der Hash stimmt, Übergabe des Passwortes
- zusätzlich könnte man den Code 'aufblasen', indem man irgendwelche Funktionen 'reinkopiert.
Das Programm dient quasi nur als 'Launcher' für PROG2.2. PROG2.exe - ein kompiliertes AutoIt-Skript :
Dieses erhält das Passwort von PROG1 und macht die eigentliche Arbeit.
Grundsätzlich schon, aber dann müsstest du deine Exe vom RAM (Stichwort: Run PE from Memory) direkt ausführen bevor du sie auf die Platte dumpst oder als separate Exe mitlieferst.
Dumpst du sie nämlich kannst du die direkt disassemblen und die Abfrage rausschmeißen.
In deinem Fall ist das schwächste Glied der Kette Prog2 da dieses nur eine If-Abfrage hat um zu ermitteln ob das Passwort korrekt ist oder nicht.
Wäre der Quellcode an sich noch verschlüsselt, wäre das ganze schon kniffliger.
Am besten ist ein Sicherheitssystem, dass wenn man eine Schraube verstellt direkt 20 weitere rausfliegen, so dass man nicht einfach eine If-Abfrage lahmlegen kann und funktioniert.
Da gibt es sehr sehr sehr viele Ansätze.
Aber wenn man die Entschlüsselungsroutine geknackt hat kann man sich ein Tool zum dumpen schreiben und schwupps hat man den originalen Quellcode.
Hackshields aus MMOs bspw. erkennen wenn man einen Thread suspended, da diese untereinander kommunizieren. Wird ein Mechanismus lahmgelegt beendet sich direkt das ganze Spiel.
Diese können sogar so tief eingebaut sein, dass die eigentliche Spielmechanik (Spiellogik etc.) nicht funktionsfähig ist wenn der Hackshield deaktiviert ist.
Unterm Strich gilt:
Willst du nicht, dass jemand in deinen Quellcode schauen kann, dann outsource die Programmierlogik und stelle nur ein Interface (abgesichert, natürlich) mit Ein-/Ausgabe zu Verfügung.
Auch diese lassen sich dekompilieren, aber wie hoch ist der Aufwand für- , bzw. sind die Know-How-Anforderungen an die ausführende Person ?
Naja, C/C++ Decompiler sind eine ganz andere Hausnummer als ein AutoIt-Decompiler. Bei der AutoIt-Variante gelangt man an den tatsächlichen Quellcode, da dieser dem Interpreter angehangen wird wie du es bereits selber gesagt hast.
C/C++ hingegen wird in Maschinencode kompiliert und da gibt es alleine schon bei der Menge an Compilern und Optimierungsverfahren keinen Weg an den ursprünglichen Quellcode ranzukommen.
Es gibt zwar Decompiler aber die spucken Code aus der dem Quellcode nicht mal ansatzweise ähnlich sieht.
Du kannst solche Kompilate aber disassemblen, also den Maschinencode anschauen und dennoch eine gute Einsicht in den Code zu bekommen.
Das ist zwar sehr aufwendig aber du siehst exakt welche Instruktionen ausgeführt werden.
Wenn du nun das ganze auf einer höheren Ebene betrachtest (also nicht jede Instruktion einzeln) sondern Funktionsaufrufe, Sprünge etc. kriegst du auch relativ schnell, je nach Kenntnisstand, Einblick in den Code.
Ist eine kompilierte .exe-Datei so gesehen 'sicherer' als eine AutoIt-.exe ?
Ja definitiv (im Rahmen des Normalusers). Wie bereits erwähnt ist es nicht möglich den ursprünglichen Quellcode auf Punkt und Komma genau zu bekommen.
Der 0815-User wird ohne Reverse Engineering Kenntnisse sich daran die Zähne ausbeißen wohingegen es bei AutoIt regelmäßig Decompiler gibt die einem das Skript auf dem Silbertablett präsentieren.
Aber nach wie vor gilt: Wenn jemand an deinen Code kommen möchte, dann wird er das auch schaffen. Immerhin muss die CPU ja irgendwelche Anweisungen ausführen damit dein Programm arbeiten kann, spätestens dort (also beim Disassembling) hat man volle Einsicht, die man natürlich, mit den entsprechenden Tools, noch weiter verschleiern kann.
kann mir da noch jemand was zu sagen, mit der Aussage aus der Hilfe kann ich nichts anfangen
Du änderst den Status des PicControls auf disabled, also sind Interaktionen (Events) damit nicht möglich, folglich gehen die Klicks die du auf das Bild sendest mehr oder weniger "durch" egal ob nun das Bild zuerst erstellt oder danach erstellt wurde.
was muss ich machen das ich trotz Bild die Maus verwenden kann?
Du musst den State von dem PicControl auf $GUI_DISABLE mit GUICtrlSetState setzen.
unsymmetrische
Unsymmetrisch ist hier wohl das falsche Wort, unausgewogen, wie du es danach genannt hast, passt besser.
hab mehrmals nachgesehen, ob das passt. ich brauch nen größeren Bildschirm (11") :D:D
Du kannst die Schriftart in deinem Editor größer stellen.
Temporär indem du Strg hälst und mit dem Mausrad in SciTE scrollst, permanent wenn du Strg+1 drückst und die Standardschriftart für AutoIt in SciTE anpasst.
Letzteres ist nur möglich wenn du SciTE4AutoIt.exe installiert hast.
Sag uns doch um was für einen Screenshot es sich handelt, in welchem Programm du herumklicken möchtest.
Ich garantiere dir, dass es bessere Wege gibt als mit ImageSearch.
Das kann unmöglich dein ganzes Skript sein, das ist so nicht lauffähig.
Sag uns doch erstmal was du genau machen willst, es gibt nämlich 1000 bessere Methoden dein Problem anzugehen als ImageSearch zu verwenden, wenn du uns genau schilderst was du wo erreichen willst können wir dir eine bessere Lösung präsentieren.
Mein USB2 Stick ist ja schneller als die von Dir o.a. USB3-Sticks
.
Sicher, dass die nicht in einem USB2 Port stecken
?
Das dachte ich mir auch, ein USB 3.1 Stick der auf 17 MB/s läuft ist einfach, sofern er von einer vernünftigen Firma hergestellt wurde, nur denkbar, wenn man viele kleine Dateien schreibt.
Aber nicht bei wenigen großen, da hab ich auf meinem 3.0 Stick ja wesentlich mehr.
Mein 3.0 Stick:
Schreibe Datei: "d:\temp\0001.ft"
Zeit: 54819 ms
Schreibrate: 19.6 MB/s
Schreibe Datei: "d:\temp\0002.ft"
Zeit: 40053 ms
Schreibrate: 26.8 MB/s
Schreibe Datei: "d:\temp\0003.ft"
Zeit: 25294 ms
Schreibrate: 42.4 MB/s
Schreibe Datei: "d:\temp\0004.ft"
Zeit: 25300 ms
Schreibrate: 42.4 MB/sWarum sollte das schneller sein? Ich denke FileMove tut es immer.
Meine Vermutung wäre, dass beim FileMove die Dateien nach dem Verschieben direkt gelöscht werden, das reduziert die Geschwindigkeit, da die Platte nicht am Stück verschiebt.
Liegen die Daten unfragmentiert hintereinander ist es viel einfacher im Dateisystem einfach alle gleichzeitig zu löschen (einfach den entsprechenden Bereich als gelöscht markieren) als alle Bereiche separat zu löschen.
Das macht sich selbstverständlich nur bei vielen Dateien und nicht bei wenigen großen Dateien bemerkbar.
//Edit, ich hab das Tool nicht gesehen aber ich vermute mal es löscht die Daten direkt? Dann gilt meine Vermutung natürlich nur wenn man im Nachhinein alles löscht.
Beim FileMove auf der selben Platte sollte das ganze offensichtlich sein, dass es schneller ist, denn die Dateien werden nicht verschoben, sondern es wird im Dateisystem (je nach Dateisystem, FAT, NTFS, inodes) einfach nur die Dateipointer restrukturiert anstatt erstmal alles zu duplizieren und dann zu löschen.
Was versuchst du denn hier zu messen? Laufwerke haben unterschiedliche Performancedaten. Sequentiell, Random 4K, IOPs.
CrystalDiskMark gibt mir ganz andere Werte aus (500+ für Seq, und 280/290 für Random 4K)
ASM-Code-Size: 34 Bytes
Schreibe Datei: "c:\temp\0001.ft"
Zeit: 444 ms
Schreibrate: 2416.7 MB/s
Schreibe Datei: "c:\temp\0002.ft"
Zeit: 2124 ms
Schreibrate: 505.4 MB/s
Schreibe Datei: "c:\temp\0003.ft"
Zeit: 3514 ms
Schreibrate: 305.5 MB/s
Schreibe Datei: "c:\temp\0004.ft"
Zeit: 3339 ms
Schreibrate: 321.6 MB/sZu : StringRegExp($sLogFile ...
Liegt die max. Länge eines Strings nicht bei 2,147,483,647 ?siehe : https://www.autoitscript.com/autoit3/docs/a…itsDefaults.htm
Das ist kein Problem, angenommen die Zeichenkette könnte mittendrin auftauchen, kann man das ganze so lösen.
Das ist jetzt kein wirklich guter Code, ich hab den so aus dem Kopf im Browser getippt aber die Idee kommt denke ich rüber.
Datei öffnen, max. Länge einlesen und parsen, wenn nichts gefunden wird und wir nicht am Ende sind, -13 Zeichen zurückspringen (falls es wir genau in der Mitte abgeschnitten haben) und neuen Teil parsen.
Local $hFile = FileOpen("log.txt")
Do
FileSetPos($hFile, -13, 1)
$sCurrent = FileRead($hFile, 2^31 - 1)
$iError = @error
$aRegEx = StringRegExp($sCurrent, "pattern", 3)
Until UBound($aRegEx) or StringLen($sCurrent) = 13 or $iError = -1 ; -1 = EOF reached
If UBound($aRegEx) Then
;gefunden
Else
;nicht gefunden
EndIfWenn es wirklich immer die letzten 13 Zeichen sind dann sollte man hier komplett auf StringRegExp verzichten, FileOpen + FileSetPos müsste hier einfach am schnellsten sein.
Dafür kannst du reguläre Ausdrücke verwenden, bspw. mit StringRegExp.
Du übergibst ein Muster wonach gesucht werden soll und es werden dir die entsprechenden Funde zurückgegeben.
Hier mal ein kleines Beispiel: https://regex101.com/r/zFIXiC/1/
Nichtsdestotrotz wird hier die gesamte Datei durchgescannt werden, in welchem Größenbereich bewegst du dich denn, dass du dir Sorgen darüber machst?
Wenn sich der Teil den du suchst immer am Ende befindet (das konnte ich aus deiner Beschreibung nicht ganz nachvollziehen), dann kannst du auch einfach die Datei mit FileOpen öffnen, mit FileSetPos an die entsprechende Position springen und dort einfach auslesen, das geht rasend schnell.