AutoIt: Passwort verschlüsselt in Skript/Programm ablegen

  • Hallo zusammen,

    AutoIt ist mir seit einigen Jahren bekannt und seit ca. 2 Jahren arbeite ich damit hier und da mal :)


    Aktuell hatte ich die "Herausforderung", in einem Skript "verschlüsselt" ein Kennwort abzulegen.
    Nach langen Verständnis-Problemen, wie man überhaupt Strings ver-/entschlüssselt, habe ich mir nun was zusammengeschrieben.

    Hierbei verwende ich im 1. Programm ein zusätzliches Kennwort, mit dem ich das eigentliche Kennwort verschlüssele und dieses dann die den Hash und verschlüsseltes Kennwort ausgibt.

    Bei Start des 2. Programmes gebe ich das zusätzliche Kennwort an, mit dem geprüft wird, ob der im 2. Programm hinterlegte Hash aus der Ausgabe des 1. Programmes übereinstimmt.
    Wenn ja wird der Hash genommen und zum entschlüsseln des Kennworts verwendet.

    Die Frage ist, ob dies hablbwegs "state of the Art" ist, oder das besser lösbar wäre.
    Ich hatte die funktion "_Crypt_DeriveKey" gesehen, jedoch nicht verstanden, wofür/wie man es verwendet. :/

    Anbei ein Beispiel-Code, um via Kommandozeile das Kennwort zu verschlüsseln:
    Create_Crypted_Password.exe SafePassword123 HeyDuDa456

    Und nachfolgend der Code, indem das Kennwort entschlüsselt wird:
    Decrypt_Password.exe HeyDuDa456

    Für Anregungen wäre ich sehr dankbar :saint::)

    Danke vielmals für ein Feedback und Grüße

    Tralveller

    P.S.: Das Tool "CodeCrypter" hatte ich mir bereits angeschaut, jedoch funktioniert es an diversen stellen nicht, sodass ich dies nicht verwenden würde.

  • Generelle Frage: Warum musst Du im 2. Programm überhaupt ein Passwort speichern und entschlüsseln? Sicher ist das nicht, da Du alle für die Entschlüsselung notwendigen Informationen im Skript speicherst.

    Da der Sourcecode problemlos (wenn auch illegal) aus der Exe zu extrahieren geht, sind Deine Sicherhetismaßnahmen sowieso mit relativ wenig Aufwand umgehbar.

  • Da der Sourcecode problemlos (wenn auch illegal) aus der Exe zu extrahieren geht, sind Deine Sicherhetismaßnahmen sowieso mit relativ wenig Aufwand umgehbar.

    Das ist auch mein derzeitiger Wissensstand !

    Es gibt Möglichkeiten, es dem Angreifer etwas zu erschweren ! Da deine Frage immer mal wieder auftaucht, empfehle ich Dir eine tiefere Suche mit Google, hier und/oder im engl. Forum. Da wurde bereits einiges zu geschrieben.

    Letzten Endes kann jede Abfrage in deinem Skript einfach entfernt werden, gleichgültig ob sie ihre Information aus einem zweiten AutoIt-Skript, einer DLL oder sonst etwas bezieht.

    Auch sogenannte Obfuscator (siehe : https://de.wikipedia.org/wiki/Obfuskation ) erhöhen nur den Aufwand für den Angreifer.

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • Dazu fällt mir dieser Thread hier ein:

    Ja, den Thread hatte ich im Hinterkopf. Ich habe ihn mal erneut durchgelesen, und deine Vorschläge machen es möglichen Angreifern schwerer !

    Eine Kernfrage neben dem 'Wie kann ich verschlüsseln ?' ist, 'Warum will/muss ich verschlüsseln ?'.

    Für das Wie hat Tralveller bereits (s)einen Ansatz gefunden - mit aussagekräftiger Beschreibung und Beispielskripten - dafür allein schon mal :thumbup:.

    Meine Frage an Tralveller ist nun : Warum willst Du verschlüsseln ?

    - möchtest Du Dein Programm (ggf. auch kommerziell) vertreiben ?

    - soll das Programm vor dem Zugriff von Mitarbeitern in der eigenen Firma geschützt werden ?

    usw.

    Abhängig davon gibt es ggf. andere, wirksamere Möglichkeiten, z.B. im Rahmen der Rechtevergabe unter Windows.

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

    Einmal editiert, zuletzt von Musashi (6. Dezember 2018 um 00:00)

  • Habe letztens ein Video gesehen zu einer art "code crack challenge" bei der man volle Einsicht in den Quellcode hat und trotzdem relativ hoher Aufwand betrieben muss um an darin befindliche Daten zu kommen. Im Prinzip läuft das wie ein ziemlich verschachtelter Obfuscator.

    Wenn du also sicher bist dass keine Leute vom Fach dein Programm knacken wollen (z.B. irgendwelche Leute die zwar decompilen können und die "Basics" einer Sprache drauf haben, aber sich nie näher damit befasst haben), schau dir mal das Video an: YoutubeIstDeinFreund

    Selbstverständlich ist das nicht "sicher", aber mit einigen Tricks lässt sich so viel Verwirrung stiften, dass der 0815 Mensch aufgibt bevor er etwas von Hand entschlüsselt hat.

    lg

    M

  • Generelle Frage: Warum musst Du im 2. Programm überhaupt ein Passwort speichern und entschlüsseln? Sicher ist das nicht, da Du alle für die Entschlüsselung notwendigen Informationen im Skript speicherst.

    Da der Sourcecode problemlos (wenn auch illegal) aus der Exe zu extrahieren geht, sind Deine Sicherhetismaßnahmen sowieso mit relativ wenig Aufwand umgehbar.

    water du hast vollkommen recht =O Da bin ich "vor lauter Code-Zeilen" am Ziel vorbeigeschossen ^^

    Weiter unten habe ich noch einmal den Code aktualisiert :)

    Auch sogenannte Obfuscator (siehe : https://de.wikipedia.org/wiki/Obfuskation ) erhöhen nur den Aufwand für den Angreifer.

    Musashi vielen Dank für deine Ergänzung, aber verschleiern macht den Code unleserlich, jedoch wird das Kennwort an sich nicht verschlüsselt, oder habe ich das falsch interpretiert?:/

    Letzlich ist auch bereits Au3Stripper aktiv, was den Code unleserlich macht; auch werden die Kommentar-Zeilen dabei entfernt. :)
    Hier einmal ein Beispiel, welches am Skript-Anfang erweitert wird:

    Code
    #Region ;**** Directives created by AutoIt3Wrapper_GUI ****
    #AutoIt3Wrapper_Run_Au3Stripper=y ; Tool ausführen, um Skript bei Kompilierung zu optimieren; aktive Optionen siehe #Au3Stripper_Parameters
    #Au3Stripper_Parameters=/pe /sf /sv /rm ; Optionen aktiv: /pe=Alle Verweise auf globale Const-Variable durch tatsächlichen Wert ersetzen; /sf=entferne ungenutzte funktionen; /sv=Entferne nicht verwendete Variablen; /rm=Kompilierte Anwendung verkleinern, indem Funktions-/Variablen-Namen verkürzt werden
    #EndRegion ;**** Directives created by AutoIt3Wrapper_GUI ****

    Dazu fällt mir dieser Thread hier ein:

    Script mit Login versehen

    chesstiger Danke für den Link. :thumbup:
    Mir ist aber nicht so ganz klar, aus welchem Grund ich eine gesamte Anwendung verschlüsseln soll, nur um ein Kennwort zu verschlüsseln :/?(

    Für das Wie hat Tralveller bereits (s)einen Ansatz gefunden - mit aussagekräftiger Beschreibung und Beispielskripten - dafür allein schon mal :thumbup:.

    Erstmal vielen Dank dafür :saint: ich dachte mit einem konkreten Beispiel kann man sein Zeil besser darstellen und anderen Suchenden es besser demonstrieren, sodass diese evtl. damit was auch anfangen und ggfs. verwenden können :rock:

    Meine Frage an Tralveller ist nun : Warum willst Du verschlüsseln ?

    - möchtest Du Dein Programm (ggf. auch kommerziell) vertreiben ?

    - soll das Programm vor dem Zugriff von Mitarbeitern in der eigenen Firma geschützt werden ?

    Bei einer Software-Verteilung wollte ich ein Kennwort mitgeben, damit dieses ausgeführt/verwendet werden kann.
    Das Kennwort soll halt nirgendwo im Klartext liegen.

    Abhängig davon gibt es ggf. andere, wirksamere Möglichkeiten, z.B. im Rahmen der Rechtevergabe unter Windows.

    Grundsätzlich ist das ein cooler Ansatz, auf welchen ich auch gestoßen bin.
    Aber bei Software-Installationen geht es (zumeist) um benutzerunabhängige Installationen.
    Bei in meinem kontreten Fall ist das leider nicht möglich X/

    - möchtest Du Dein Programm (ggf. auch kommerziell) vertreiben ?

    Ich war etwas irritiert8|
    Was meinst du damit?
    Die Software darf an sich kommerziell verwendet werden, oder habe ich es hier falsch gelesen/verstanden? =O
    Das Skript wird dann nur für interne Nutzung und NICHT für Verkauf/Vertrieb verwendet.


    Nachdem Hinweis von water habe ich den Code noch einmal aktualisiert. NOCH EINMAL vielen Dank für den Hinweis :theke:


    Create_Crypted_Password.exe ist dabei nur für die Erstellung des verschlüsselten Kennworts angedacht und würde natürlich nicht bekannt/verteilt/veröffentlicht werden.

    Decrypt_Password.exe hat dann nur das verschlüsselte Kennwort, was mit einem Hash eines anderen Passwort verschlüsselt wurde. Nach meinem Verständnis ist es aktuell "nicht ganz so einfach" einen mit aktuellem Algorithmus erstellten Hash zurückzurechnen.^^
    Zudem wird das Passwort nicht im Code, sondern erst bei Aufruf als Parameter mit angegeben. Selbst wenn jemand den Code sich anschaut, sollte das verschlüsselte Kennwort damit nicht enschlüsselbar und hierdurch nicht im klartext lesbar sein.

    Wenn natürlich bereits bei Aufruf der Anwendung die Parameter abgegriffen werden würden, könnte man das Kennwort dann wieder entschlüsseln; aber dann ist bereits schon vorher entweder einiges schief gegangen (Virus?), der Anwender hat Admin-Rechte (WTF???), die NSA hat zu viel langeweile, oder, oder, oder.. aber irgendwo gibt es nun mal ein Limit und das Passwort muss man halt irgendwo mitgeben.:ironie:
    Man kann aber nun hingehen und die kompilierte Anwendung "beruhigt" ablegen, ohne dass das Kennwort direkt im Klartext lesbar ist. (meinem Verständnis nach)
    Natürlich sollte das Passwort nicht dort nebenan in einer Text-Datei mit abgelegt werden :D

    Update: anbei ein Beispiel-Code, um via Kommandozeile das Kennwort zu verschlüsseln:

    Create_Crypted_Password.exe SafePassword123 HeyDuDa456

    Update: und nachfolgend der Code, indem das Kennwort entschlüsselt wird:

    Decrypt_Password.exe HeyDuDa456

    Könnte man so mit dem Thema mit oben genannten Limits arbeiten? :)

    Evtl. ist das für den ein oder anderen Suchenden hilfreich.

    Vielen Dank für die schon erfolgten schnellen Rückmeldungen hierzu :thumbup:

    Viele Grüße

    Tralveller

  • Moment, wenn ich das richtig verstanden habe was du machen möchtest brauchst du einen anderen Ansatz. Gehe immer davon aus, dass ein potentieller Angreifer deinen Quelltext komplett einsehen kann. Wenn du willst, dass das Programm nur mit einem Key richtig funktioniert musst du essentielle Funktionen verschlüsseln, sodass ein Angreifer ohne Schlüssel die Funktionalität nicht mehr feststellen kann (in deinem Beispiel kann er zwar das PW villeicht nicht herausbekommen, aber er kann die Abfrage einfach aus dem Code entfernen und das Programm trotzden nutzen).

    Hier ein Beispiel:

    Dabei werden keine Hashwerte verglichen und so wenig wie möglich offengelegt, wenn man den richtigen Schlüssel nicht hat. Es gibt auch keine If $Passwort = Valid Abfragen (die man einfach auskommentieren oder umschreiben kann wenn man den Code zur Hand hat) oder ähnliches. Es funktioniert mit korrektem Key und sonst nicht und im Code selbst lassen sich keinerlei Hinweise auf den Key finden. Hier wird eine RandomXOR Verschlüsselung benutzt, die kann man sehr leicht durch ausprobieren knacken, soll hier auch nur als Beispiel dienen.

    Edit: Execute ist hier leider der einzige (mir bekannte) Weg Programmcode effektiv mit einem Passwort zu schützen. Um Execute richtig zu verwenden musst du ein bisschen üben. Es gehen z.B. nur Einzeiler, keine Schleifen, usw.

    M

  • Hi Tralveller !

    Da Du recht viele Fragen gestellt hast, werden sich die Antworten möglicherweise überschneiden, oder doppelt hereinkommen ;).

    Musashi - vielen Dank für deine Ergänzung, aber verschleiern macht den Code unleserlich, jedoch wird das Kennwort an sich nicht verschlüsselt, oder habe ich das falsch interpretiert? :/
    Letzlich ist auch bereits Au3Stripper aktiv, was den Code unleserlich macht; auch werden die Kommentar-Zeilen dabei entfernt. :)

    (Vereinfachte Darstellung !)

    Das Prinzip eines Obfuscator basiert darauf den Quellcode so zu verändern, dass er für Menschen 'unleserlich' (genauer : 'schwer leserlich') wird. Für den Rechner/Compiler etc. sind diese Änderungen aber irrelevant.

    Google nach Obfuscator, dann wirst Du VORHER / NACHHER Beispiele finden, wie ein 'obfuscated code' aussehen kann. (Mit viel Freizeit ließe sich ein Obfuscator sogar selbst schreiben :P. )

    Der Au3Stripper hat Funktionalitäten, die man sicher im Bereich Obfuscating ansiedeln kann.

    Das Entfernen von Kommentaren ist z.B. hilfreich, um Angreifern nicht auch noch eine kostenlose Doku mitzuliefern ;).

    siehe : https://www.autoitscript.com/autoit3/scite/…u3Stripper.html

    z.B. :

    - Rename Variables

    - Rename Func names

    usw.

    Du kannst ein Passwort in deinem Quellcode natürlich verschlüsselt eintragen. Möchtest Du aus deinem Skript heraus aber z.B. eine Datenbank (Passwortübergabe erforderlich) abfragen, dann erwartet die DB das Passwort standardmäßig in Klarschrift.

    Du benötigst im Skript also auch die passende Entschlüsselungsmethode, z.B. :

    Das Originalpasswort lautet Rosebud , Du schreibst aber :

    $sPasswortCode = 'Edkyvwq'

    _AbfrageDB(_Decode($sPasswortCode)) ...

    (die Funktion _Decode macht aus 'Edkyvwq' wieder 'Rosebud ')

    Hat jemand aber Deinen Quellcode, könnte er ConsoleWrite(_Decode($sPasswortCode)) ausgeben.

    Das ist natürlich nur ein Primitivbeispiel ! Experten schauen sich das Ganze mit entsprechenden Tools an (näher möchte ich darauf nicht eingehen).

    Du kannst es 0815- und auch etwas besseren Leuten schwerer machen - am Ende ist es aber unsicher !

    Nimm das, was der Au3Stripper Dir bietet, und verwende die Zeit lieber auf das Programm selbst.

    Diese Anmerkungen sind denkbar unvollständig ! Ich bitte die Experten und Dich um Nachsicht ;).

    Ich war etwas irritiert 8| Was meinst du damit?
    Die Software darf an sich kommerziell verwendet werden, oder habe ich es hier falsch gelesen/verstanden? =O
    Das Skript wird dann nur für interne Nutzung und NICHT für Verkauf/Vertrieb verwendet.

    Mit 'kommerziell' meinte ich, ob Du (falls selbstständig) Deine Software an Dritte verkaufen willst !

    Das hast Du mit '... nur für interne Nutzung und NICHT für Vertrieb/Verkauf' beantwortet.

    Über die Nutzungsrechte/Lizenzform entscheidest ja Du bzw. Dein Arbeitgeber/Auftraggeber, je nachdem wie das bei Euch geregelt ist.

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • An die Experten :

    Bei AutoIt werden das Skript und der Interpreter ja zu einer ausführbaren Datei verbunden, nicht im eigentlichen Sinne kompiliert. Daher ist es relativ leicht an den Quellcode zu gelangen.

    Wie verhält es sich mit .exe's, die mittels 'echtem' Compiler erzeugt wurden (C, C++, FreeBasic usw.) ?

    Auch diese lassen sich dekompilieren, aber wie hoch ist der Aufwand für- , bzw. sind die Know-How-Anforderungen an die ausführende Person ?

    Es geht nicht darum wie man es macht, sondern, vereinfacht ausgedrückt, um die Frage :

    Ist eine kompilierte .exe-Datei so gesehen 'sicherer' als eine AutoIt-.exe ?

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • 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.

  • Hi alpines !

    Danke für die schnelle und ausführliche Antwort. Sie entspricht dem was mir bekannt ist, ich wollte aber sichergehen ;).

    Aber nach wie vor gilt: Wenn jemand an deinen Code kommen möchte, dann wird er das auch schaffen.

    Das steht außer Frage, es geht, wie Du auch angemerkt hast, um 0815+ Programmierer.

    Der Sicherheitsgewinn entsteht dadurch, dass höhere Anforderungen an einen potentiellen Angreifer gestellt werden.

    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.

    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.

    Der Quellcode von PROG2 nützt dem Angreifer nun nicht mehr, weil das Passwort als Parameter von PROG1 kommt. Wird PROG2 verändert, dann verändert sich auch der Hash.

    Folge : PROG1 würde PROG2 nicht mehr starten.

    (die Sache mit den Kollisionen bei MD5 lasse ich mal weg - es gibt ja auch andere Hashfunktionen)

    Kleiner Nachteil : Ändert man das AutoIt-Skript, dann muss auch der Hash in PROG1.exe angepasst werden. In der Entwicklungs- und Testphase sollte man die Hash-Prüfung daher abschalten.

    Für versierte Programmierer trotzdem kein Problem, aber eben schwerer als bei AutoIt.

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • 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.

  • Danke an Mars  Musashi  alpines für die Rückmeldungen hierzu:)

    Da sind eindeutig Punkte dabei, die der ein oder andere bei dem Lösungsansatz beachten und abwägen sollte :thumbup::thumbup::thumbup:

    Persönlich habe mir die Punkte angesehen und versucht abzuwägen, ob dies für mein aktuelles Thema so relevant/kritisch ist, dass ich hier mehr zeit investieren sollte. :Glaskugel:


    Dagegen spricht:

    - Au3Stripper verwendet, was "Obfuscator-Funktionalitäten" wie bereits erwähnt im Ansatz beinhaltet

    - Das Kennwort direkt via RunWait() weitergegeben wird

    - es unsicher ist? Das Kennwort ist verschlüsselt im Code abgelegt. Wenn jemand an den Code kommt, muss er dennoch an das Passwort herankommen, was als Parameter mitgegeben wird, folglich erstmal nicht dabei ist.

    - Der Code ohnehin nicht "für die große, weite Welt" gedacht ist

    - Und der Punkt von alpines :

    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, ...

    => Mit genug Aufwand/Energie kann man sicherlich SEHR vieles herausbekommen.

    Dafür spricht, dass die hier genannten potenziellen Schwachstellen ggfs. minimiert werden sollten, was aber unter Umständen zu deutlich höherem Zeitaufwand führt.
    Dann würde sich aber ohnehin die Frage stellen, ob dies dann noch in AutoIt oder aber doch direkt in C++, C#, etc. gemacht werden kann/sollte.:/

    Sicherlich gibt es da mit entsprechendem KnowHow "schönere"/"sichere"/"smartere" Lösungen :thumbup:

    Das kann aber nun jeder für sich entscheiden.

    Das Thema sehe zumindest ich als "erledigt" an.

    Nochmals vielen Dank für die zahlreichen und schnellen Rückmeldungen :saint::)

    Viele Grüße

    Tralveller