Beiträge von alpines

    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.

    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.

    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 =O .

    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:

    Warum 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)

    Zu : StringRegExp($sLogFile ...


    Liegt die max. Länge eines Strings nicht bei 2,147,483,647 ?

    siehe : https://www.autoitscript.com/a…pendix/LimitsDefaults.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.

    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.

    Nicht wirklich, sowas wird meistens im blauen Forum diskutiert.

    Wenn du über Änderungen bei den verschiedenen Versionen den Überblick behalten möchtest kannst du dir immer die Changelog History anschauen, dort steht was über die Versionen hinweg verändert wurde und ob das dein Skript so verändert, das es nicht mehr lauffähig ist. http://www.autoitscript.com/autoit3/docs/history.htm


    Oder du schaust mal im Bugtracker vorbei, dort wird sowas auch diskutiert.

    Hätte nicht gedacht, daß Regex so langsam ist. Wenngleich es mir merkwürdig vorkam hier Regex zu verwenden statt einfach die rechten 3

    wie in deinem Tipp jetzt.

    Ist zwar ein wenig OT aber mit Regex schießt du hier mit Kanonen auf Spatzen.

    Wenn du immer dreistellige Nachkommazahlen hast kannst du die Stringfunktionen verwenden, das ist wesentlich schneller, da der Interpreter nicht erst die RegEx-Maschine anschmeißen und alles in deinem Pattern durchparsen muss. Auch bei Zahlen ohne drei Nachkommastellen kannst du mit StringInStr nach dem Dezimalkomma suchen und ab dort abschneiden, wäre auch viel schneller.