Beiträge von Andy

Nun gut, du hast es nicht anders gewollt!

Zitat

Ja ich habe wohl ne Schraube locker.

Damit fängt alles an

Die Buttons auf dem Controller kannst du per AutoIt alle abfragen!?
Dann kommt es "nur" noch darauf an, dem Spiel des "richtigen" Tastaturcode zu senden. IdR. emulieren die am USB-Port angestöpselten Devices eine Tastatur, dass ist Programmintern am einfachsten abzufangen (Standard-Library)

Schreib dir ein Script, welches alle ausser den dir schon bekannten Tastaturcodes (wichtig!) per

_Send_Virtual_Key($iCode)

an das Programm sendet.
Wenn sich dort dann auf dem Bildschirm "etwas tut", dann hast du einen Treffer gelandet.

Ich wollte jetzt aufs Re-engeneering per Debugger in den Tiefen der Treiber abschwenken, aber es gibt noch eine einfachere Möglichkeit, den "Mouseklick".
Mit der Abfrage des Controllerstatus bekommst du auch die Position des "virtuellen Mauszeigers".
Diese Position könntest du dazu benutzen mit einem

mouseclick()

das Drücken der Taste auf dem Gamepad zu emulieren.

Zitat

Für weitere schwierigkeiten befinde ich mich jetzt wahrscheinlich im falschen Forum.

sagt wer? Frag einfach, im schlimmsten Fall bekommst du keine Antwort^^

Hi,

Zitat

Bei mir unter XP läuft das Prog einwandfrei und deshalb hatte ich eben diese obige Vermutung.

das macht einiges klarer^^

Zitat

Ich muß mal nachschauen, wie und ob ich diesen möglichrn Fehler beim Speichern abfange.

Ich bevorzuge die "OnError"-Variante.
Zunächst einmal wird festegelegt, dass ein Fehler in einem Programm niemals zum Absturz führen kann!
Beispiel, s. hier, Schnuffels Links! Ich habe diese UDF einfach auf meine Bedürfnisse angepasst bzw. umgeschrieben.
Dann gilt es herauszufinden, wo im Script der Fehler auftritt. Wenn man diesen Fehler bzw wenigstens den Ort des Fehlers in einer MsgBox (und in einer Error-Datei) ausgibt, dann kann der User wertvolle Informationen liefern!
Im Prinzip ist das unglaublich einfach, man muss lediglich am Anfang sämtlicher relevanter Programmteile (bspw. Funktionen/Schleifen ) einen Klartext einfügen der die Position bzw ein Vorkommen des Fehlers dokumentiert:

func _blablub()
$errormsg="Funktion _blablub"
...
for $i=1 to ubound($array)-1
$errormsg="Schleife Datenimport Fehler an Position $i=" &$i"
...

Das schlimmste was passieren kann ist ein Absturz oder schlimmer noch ein kryptisches (AutoIt-)Fensterchen mit Inhalt "Error in line-1"

Hi,

Zitat

Es gibt dennoch ein paar Tasten, die vertauscht sind. Für diese Tasten gibt es keinen "Alternativ-Key" am Keyboard oder an der Maus.

OK, mir wäre das ehrlich gesagt auch viel zu viel Aufwand!
Als jemand, der mit einem Lötkolben in der Hand grossgeworden ist, würde ich die "softwareseitige" Umbelegung von Tasten sowieso erst als letzte Lösung wählen...
Mach den Controller auf, und löte mit einigen cm Fädeldraht die Schalter wie gewünscht um!
Das ist in nichtmal 20 Minuten erledigt. Ich will nicht wissen wieviel Zeit und Energie und Frust deinerseits in die Suche nach einer Softwarelösung geflossen sind...

Hi,

Zitat

es ist ein Versuch, da das Prog auf euinem 64bit System anscheinend immer wieder abstürzte. Oder habe ich da irgendwelche Häckchen falsch gesetzt, so dass es nur für 32bit compiled wird?
dlls binde ich gar nicht mit ein.

solange du keine externen 64-Bit-dll´s einbindest oder esoterische UDF´s verwendest, kannst du JEDES Script in X86 kompilieren, es läuft dann auch auf einem 64-Bit-System!
Was mich eher stört, ist

Zitat

es ist ein Versuch, da das Prog auf euinem 64bit System anscheinend immer wieder abstürzte.

Was soll DAS denn?
Wenn dein Script nicht richtig funktioniert, und du meinst diesen "Schrott" damit kompensieren zu können, dass du es für X64 kompilierst, solltest du dir ( oder hier ) komplett andere Fragen stellen als zum Thema " Iexpress"!

Zitat

Oder habe ich da irgendwelche Häckchen falsch gesetzt, so dass es nur für 32bit compiled wird?

Woher sollen wir das denn wissen?
Wie schon von James gesagt, Screenshots FTW!
Und mit Hinweis auf die "Abstürze" erstmal das Script....

"teste" mal

$key = $i_1 ;_ArraySearch ($entries[$i], $categories[$i_1][1])
;~ If $key Then
$val &= $entries[$i][$key][1]
;~ EndIf
EndIf
Next

; MsgBox (0, 0, $val)
$item1 = GUICtrlCreateListViewItem($val, $ctrl_main[2])

damit habe ich sämtliche Einträge aus einer erweiterten Datei dargestellt bekommen

Hi,

Zitat

Andy Die Arrays sind alle richtig befüllt und sämtlicher anderer Kram ist auch getestet.

naja, wenn alles andere getestet ist, dann liegt der "Fehler" bei AutoIt?
Was ist denn an diesen Zeilen

$key = _ArraySearch ($entries[$i], $categories[$i_1][1])
If $key Then
$val &= $entries[$i][$key][1]
EndIf

"getestet"? Schreib einfach einen validen Wert in die Variable $key und guck dir das Ergebnis an!

$key = $i_1 ;_ArraySearch ($entries[$i], $categories[$i_1][1])
If $key Then
$val &= $entries[$i][$key][1]
EndIf

keine Fehlermeldung, also liegt das "Problem" wohl in der Funktion _arraysearch() (wohl eher nicht ^^) oder in DEINEN Parametern!
Mal abgesehen davon, dass es den "Parameter" $entries[$i] garnicht geben kann, da $entries[] 3-dimensional ist....

//EDIT
wenn für das Listview sowieso pipe-getrennte Strings verwendet werden, wieso nimmst du dieses Format nicht direkt für deine "Datenbank" als Textdatei?
NAME|VORNAME|EMAIL|bla|blub

Dann wäre das Lesen der Datei in einer Zeile erledigt, und das Füllen der Listview in 3 Zeilen.
Die Suche wäre incl. Schleife in drei Zeilen erledigt...

Hi,
zu deinem "Besorgungsproblem" kann ich zwar nicht viel beitragen, aber nun weiss ich wenigstens, bei wem ich demnächst OCL-Vergleiche von GPU´s mit "dicken" CPU´s bekomme

Hi,
vorab:
Ich habe selten ein Script gesehen, bei dem ein "Fehler" vom Programmierer erst in diesem Stadium auftaucht
Wenn ich Scripte, dann binde ich reihenweise Debug-Informationen in Form von Kontrollen (Consolewrite, Msgboxen, ab und zu mal Traces usw. ) ein.
So weiss ich jederzeit, nachdem ich auf F5 gehauen habe, was los ist und was mein Script macht / oder nicht macht.
Ist richtig dimensioniert, stimmen die Variablen(inhalte), sind die Arrays richtig ausgefüllt? Wer diese grundlegenden Informationen in seinem Programm nicht kennt, aber fleissig hunderte Zeilen "drauflosprogrammiert", braucht sich im Nachhinein nicht zu wundern...
Btw. ist das "Fehlersuchen" Sache des Programmierers! Wenn DIR "langweilig" ist, dann hast du genug Zeit, in DEINEM Script die von DIR verursachten Fehler zu finden und musst dir nicht hier im Forum andere deine Arbeit machen lassen!

Nun zum "Problem":
Woher weisst du, dass dein 3D-Array richtig ausgefüllt bzw. erstmal richtig dimensioniert ist?
Die AutoIt-Funktionen geben ALLE im Fall der Fälle einen Fehlercode

@error

zurück, im gesamten Script ist nicht ein einziger dieser Fehlercodes ausgewertet!

_arraydisplay()

stellt nur bis 2D dar, soviel steht fest! Hast du ein "Anzeigetool" für 3D- bzw. mehrdimensionale Arrays? Ich hab eins...

ubound()

hat einen 2. Parameter, welcher die Rückgabe der Größe der Dimensionierung beeinflusst!

_arraysearch()

sucht auch nur in 2-dimensionalen Arrays.

Hi,

Zitat

Jede Taste bekommt einen Wert zugewiesen.
Wenn ich start drücke gibt sie "512" zurück.
Bei Select gibt sie "256" zurück. usw.

Wo ist dann das Problem? Denn du sagtest doch

Zitat

Ich schaffe es also Virtual-Key Codes und normale send's auszuführen.

Dann solltest du doch nur noch die Abfrage ändern, oder täusche ich mich?

$select= ;hier gehört der Tastaturscancode für den Selectbutton hin
If $coord[7] = "512" Then ;wenn "Start"-Button vom Gamepad gedrückt
_Send_Virtual_Key($select) ;dann Tastaturkommando an Spiel schicken
EndIf

Wenn es eine Taste gibt, mit der du im Spiel "Select" auswählen kannst, dann findest du ggf Scancodes hier oder hier
Eine kurze Liste der Tastaturscancodes findet man auch in der AutoIt-Hilfe zu

_IsPressed()

Hi,

Zitat

Die _Joystick.au3 von Ejoc - diese bekommt die gets über die Winmm.dll - gibt mir Informationen über gedrückte Buttons.

und was sagt diese dll zu deinen gedrückten Buttons?

Zitat

$coord=_GetJoy($joy,0)

Hi,
gibt es einen Grund, wieso du das AutoIt-Programm nicht als 32 Bit-EXE kompilierst?
Seit es den 64-Bit-Modus gibt habe ich sicher hunderte von Tools für beide Plattformen geschrieben aber noch nicht ein einziges man zwingend 64 Bit benötigt.
Selbst beim Einbinden von dll´s hat man zu 99% die Wahl, eine 32-Bitversion zu verwenden. Andernfalls kompiliert man die dll einfach für x32.

Zitat

Hast Du schon mal ermittelt, ob es sich bei den Zeichen zwischen den Einträgen wirklich um Leerzeichen "chr(32)" handelt?
Mal mit StringToASCIIArray prüfen. Eventuell lässt sich das viel einfacher trennen...

Das geht viel einfacher wenn man sich den String in Scite direkt anschaut. Dort werden die Sonder bzw. Steuerzeichen als einzige nicht im Klartext angezeigt!
Ich bevorzuge aber für diese Fälle trotzdem einen Hex-Editor...

Zitat

Du könntest die Leerzeichen bei den Zahlen mit einem Buchstaben / Zeichen ersetzen was du nicht verwendet hast, dann könntest du auf das gewünschte splitten und am Ende beim Array das Zeichen mit dem Leerzeichen ersetzen.

Wenn das Trennzeichen erkannt ist, wieso soll man es dann noch ersetzen?
Trennzeichen sind dafür da, um die Daten zu trennen, wenn man nicht weiss welches Trennzeichen verwendet wird, dann muss man es eben herausfinden (s. Oscars Post) und nicht "irgendwelche" seltsamen Workarounds finden.

@TE
versuche mal, per TAB oder anderen Tastencodes durch die Liste zu laufen. Ich lese in unserer firmeninternen Software so die Felder aus (gleicher Grund, Datebank war nicht im Zugriff)

Hi,
generiere pro Script einen Aktivierungsschlüssel anhand der vorhandenen Rechnerdaten/Emailadresse.
Diesen Schlüssel hängst du hinten an die EXE.
Wenn dein Script "merkt", dass es nicht auf dem richtigen Rechner läuft, mach ein Fensterchen auf, in dem du den User darüber informierst, dass das Programm bei dir per Email ( ! ) einen neuen Schlüssel aufgrund geänderter Rechner- bzw. Hardwaredaten anzufordert. Per Email schickst du dir nun vom Rechner des Nutzers eine Mail (ggf. versteckt) mit den Rechnerdaten anhand deren du wieder einen neuen Aktivierungsschlüssel erstellst. Diesen schickst du an die Emailadresse des "regulären" Nutzers!

Sollten die Emailadressen nicht übereinstimmen, würde ich den User bitten, eine Email "von Hand" an dich zu schreiben (mit dem Absender, der für die Aktivierung verwendet wurde), und das Programm einfach löschen!
Wenn der User rechtmäßiger Verwender des Programms ist, bekommt er von dir eine email mit dem neuen Freischaltcode, der daraufhin wieder an die EXE angehängt wird. Falls die EXE beim User gelöscht wurde, ist irgendetwas megafaul...dann hat dieser nämlich nicht die Emailadresse vom regulären User, bzw. dieser hat das Programm weitergegeben.
Ergo würde ich dem regulären Nutzer auf die Füsse treten und bei der nächsten "Aktivierung" bzw. Programmstart die Datei auch einfach löschen....
Keine Angst, wenn jemand beim bescheissen erwischt worden ist, wird er den Ball SEHR flach halten!
Denn du hast als "Beweis" sogar die Emailadresse desjenigen, dem dein Programm unrechtmäßig weitergegeben wurde!

Mal ganz ehlich, wenn irgendwann die Jahreszahl "angepasst" worden wäre, dann hätte kein Hahn nach einem neuen Logo gekräht.
Mich stört es so wie es ist jedenfalls nicht, ich finde es schön!

Hi,

Zitat

Sowas soll ja angeblich "unknackbar" sein...

Da muss ich dich enttäuschen, "knackbar" ist mit genügend Aufwand ALLES!
Aber der Reihe nach...

Zitat

PS: Zur not einfach das Programm aus z.B. einem mit einem Passwort geschütztem WinRar Archiv aus öffnen.

Toll, dann hast du eine "sichere" Datei, aber im Speicher steht das Script (Programm) im Klartext

Zitat

Man könnte höchstens jede Funktion die das Programm beinhaltet einzeln abfragen, bzw. in die Abfrage zum start des Programms mit einbeziehen. Das heist, jedes mal wenn man einen Button klickt, wird das Passwort vom Start des Programms abgefragt (ohne dass es es neu eingeben muss.) Aber das wäre erstens ein rießen Aufwand und zweitens ebenfalls knackbar, wenn auch
mit sehr viel mehr aufwand.

Ansich eine gute Idee! Problem ist aber dabei die "Faulheit" des Programmierers, oft genutzte Programmschritte in Funktionen/Calls abzulegen, bspw. CheckPSWD(). Wenn der Einsprungpunkt für diese Funktion einmal gefunden ist, dann reicht idR. ein einfaches RET in der compilierten Datei, um diese Funktion niemals auszuführen...

Allerdings könnte man auch die 20 Zeilen für die Passwortabfrage 100 Mal im Script verteilen, ggf. sogar in verschiedenen Versionen bzw. Programmcodes.
Und wenn man schon dabei ist, könnte man sich ein Script schreiben, dass den Quellcode extrem "aufbläht" mit mehr oder weniger sinnfreien Funktionen. Wenn zwischen 5 aufeinanderfolgenden Scriptzeilen plötzlich 250 Zeilen Code stehen, dann wird es schwierig, da noch durchzublicken.
Obfuscator drüberlaufen lassen und man hat es dem Angreifer seitens Quellcode schonmal schön schwer gemacht... Ob die EXE nun 500KB oder 500MB groß ist, interessiert heute sowieso niemanden mehr

Zitat

Wie schaffen das manche Programme, ihre Passwörter von z.B. einer MySQL Datenbank zu holen, ohne
dass im Code i.welche Angaben zu den Zugangsdaten stehen?

naja, das ist einfach^^, die Passwortabfrage im Programm wird verschlüsselt oder gehashed, und dieser Schlüssel oder Hash wird an die Datenbank geschickt."Passt" der Schlüssel, kommt ein Freischaltcode von der Datenbankanwendung zurück.
Wieso nimmt man dann nicht einfach eine Datei? Weil die Datenbananwendung wiederum ein externes Programm ist, was incl. verschlüsselter Daten wieder "etwas mehr" Sicherheit bietet.

Zitat

Wenn ich ein Passwort z.B. von einem FTP Server hole muss ich ja auch erstmal im Code selbst die Zugangsdaten zu diesem
bereitstellen oder sie aus einer lokalen Datei auslesen.

Richtig, ein FTP-Server (bzw. das Protokoll) ist aber auch so ziemlich das "unsicherste" was es gibt
Bei meinem FTP-Server ist nach dem ersten Login-Fehlversuch EINE STUNDE Pause angesagt...
Bei meiner Bank konnte ich noch im letzten Jahr in dieser Zeit mit Millionen Passwörtern auf mein Konto-Login schiessen Soviel zum Thema "Sicherheit" implementieren!
Die Datenübertragung bei FTP erfolgt ebenfalls im Klartext.
Daher ist das Passwort (bei Onlineabfragen) recht einfach mit einem PHP-Script auf der Serverseite "abzufragen".
Und wenn man schon so weit ist, dann kann man ggf. Berechnungen oder Daten genauso vom PHP-Script rechnen lassen.
Die großen Systemhäuser machen sich diese Mühe schon garnicht mehr, sondern lassen ihre Programme direkt als Web-App laufen, incl. sämtlicher Userdaten in der "Cloud". Wer da noch ernshaft daran glaubt, dass diese "online" verschlüsselten Daten sicher sind , dem ist sowieso nicht mehr zu helfen
Alda, wir müssen deine Daten an sämtlicher Regierungsbehörden weitergeben, und auch an sonst jeden der zahlt, aber dein Passwort wird ehrlich nirgendwo gepeichert, isch schwör!!!

Hi,

Zitat von Herr Bert

Ich weiß zwar nicht ob deine Antwort an mich oder an DaveTDancer gerichtet ist, aber grundsätzlich ist davon abzuraten alle Fragensteller über einen Kamm zu scheren. Denn oft sind die Programme, Funktionalitäten oder Daten nicht, oder nur unzureichend bekannt.

Ich schere hier garnichts, meine Aussage beruht einfach auf der Erfahrung zu diesem Thema. Das wäre übrigens auch deine Erfahrung, wenn du zu diesem Thema in den gängigen AutoIt- Foren (und nicht nur dort) gesucht hättest.
Natürlich wird dieses Thema immer wieder hochgerollt, es könnte ja sein , dass ein Programmier-Messias in den letzten Stunden den ultimativen Hack gefunden hat und die gesamte bekannte Welt Lügen straft...und genau dieser Messias liest genau JETZT den gefühlt vierhundertausendsten Thread zu diesem Thema und gibt dem unbedarft fragenden Jünger die passende Antwort. Wer´s glaubt....

Zitat von Herr Bert

Oft geht es einfach nur darum den Umgang mit AutoIt und seinen Funktionen zu lernen oder das Wissen zu vertiefen und wo sonst, außer hier im Forum, sollte man nachfragen? Trotz dessen danke ich auch dir für deine Antworten.

Kein Thema, aber du gibst gerade die Standard-Antwort der Botter wenn nachgefragt wurde:" Was willst du mit diesem Script überhaupt erreichen? / Was hat das Script für einen Grund?"
Und damit nicht genug, wer bitteschön legt ein wie auch immer zu benutzendes Stück String in einer *.INI-Datei ab?
In eine *.INI (das steht für Initialisierung) gehört so etwas nicht, idR. stehen in solchen Dateien userspezifische und auch von Usern bearbeitete Daten. Ein PW oder sonst ein String gehört entweder ins Programm oder in eine (Passwort) Datei. Diese IniRead()-IniWrite() Mode ist aufgekommen, weil diesbezügliche User nachweisbar nicht in der Lage sind einfachste Dateioperationen durchzuführen. Das ist soweit auch kein Problem, aber suche mal in den einschlägigen Foren danach, wie viele "ProblemThreads" mit dem Thema IniRead/Write() erstellt wurden...wie gesagt, Erfahrungssache^^ //EDIT atm gibt es nur auf AutoIt.de 17.000 (siebzehntausend) Threads mit dem Bezug zu ini-Dateien.

Und wenn ich schon dabei bin, es gehört bei einer Anfrage in einem Forum auch dazu, Daten (bspw. Test.ini mit relevantem Inhalt) zur Verfügung zu stellen, mit denen man dein Script (schnipsel) ausprobieren kann, ansonsten ist das rumgestochere im Nebel (s. die ersten Antworten). Günstigstenfalls ein komplett ausführbares Testscript, so dass man den "Fehler" nachvollziehen kann.

Ich weiss dass definitiv einige "Cracks" dieses Thema gelesen haben und keine Antworten geben, weil sie ihre "Glaskugel" gerade nicht zur Hand haben
Ein Forum ist nämlich nicht dazu da, "nachzufragen" (sich den Arm aus der Sonne legen zu lassen), sondern um sich konstruktiv mit anderen zu bestimmten Themen auszutauschen. Wenn du nicht verstehst was ich damit meine, lies bitte mal die in meiner Signatur verlinkte(n) Seite(n).

Hi,
gerade im Einheitskreis bringt es etwas, den Radius ( =1 ) und den Umfang Pi einfließen zu lassen. Sowohl am Kreis, als auch an der Kurve.
Auch die Beziehungen sin = Gegenkathete/Hypothenuse( =1 ) und cos bzw tan kann man schön darstellen...
Weiterhin wäre es sicher vorteilhaft, wenn man in ein Inputfeld einen Winkel eingeben könnte und sin, cos und tan werden eingezeichnet bzw ausgegeben.

Oscar , so hatte ich es auch bei deinem Hinweis verstanden.
"Etwas" sicher ist sicher besser als "garnicht" sicher
Aber genau wie in diesem Thread werden die Fragen zum "Schutz" von Daten und Dateien meistens von denjenigen gestellt, bei denen meist sowieso nichts schützenswertes an Software und Daten vorhanden ist.
Wer schützenswerte Daten und Dateien erstellt hat, der weiss auch, wie und mit welchen Methoden dieser Schutz zu realisieren ist und auch wo man im Zweifelsfall nachlesen kann

Hi,
der "Fehler" liegt bei dir im System.
Du berechnest einfach den "Abstand" aller Felder zum Start. Das führt dann dazu, dass (s. Bild oben links kurz nach dem Start) das Feld mit dem Wert 3.2 zweimal vorkommt, obwohl der Weg zum 2. Feld mit Wert 3.2 wesentlich länger ist, da man um das geblockte Feld 2.4 herumlaufen muss.

Zitat von Mars

Mich würde dann auch ein vergleich zum A+ Algo interessieren, kann man den da iwie einfach einbauen ? (ohne Diagonalen)

Anbei mein A*-Script, es hat lediglich eine Zeile ergänzt werden müssen, um nur "gerade" zu laufen^^ (Zeile 226 auskommentieren um auch schräge Wege zu gehen)
// EDIT Die Hindernisse müssen in diesem Fall an den Ecken geschlossen sein
// wer mag, kann in Zeile 204 nach dem GuiDtrlSetData() noch ein sleep(100) einfügen, dann kann man nachvollziehen, welchen Weg der Algorithmus läuft

Es werden auf dem Hinweg die "diagonalen" Felder berechnet, allerdings werden auf dem Rückweg nur die geraden Felder zum Laufen herangezogen.
Wenn ich Lust und Laune habe erstelle ich eine "schnelle" Version unter Verwendung einer Struct^^...worauf das dann hinausläuft sollte den üblichen Verdächtigen bekannt sein

//EDIT Habe in meinem Script den "inner Loop" verifiziert. Mit AutoIt dauert die Wegfindung je nach Labyrinthgröße bei 1000 überprüften Feldern ca. 1 Sekunde, also über den dicken Daumen 1-2Millisekunden pro überprüftem Feld mit der Funktion suche_Nachbar(). Mal schauen, inwieweit man das noch optimieren kann. Da die 8 Felder um den Mittelpunkt untersucht werden müssen, bieten sich 2 SSE-Register an.
Btw. wenn man eine universelle A*-Funktion erstellen würde, müsste man nur eine komplette Beschreibung des Labyrinths (als Bitmap?) mit Festlegung von Start und Ziel und den Hindernissen erstellen und diese Bitmap dann incl. kürzestem Weg zurückgeben. Eine Bitmap bietet sich an, da in deren Header schon die Daten des Labyrinths enthalten sind, ausserdem ist sie mit jedem gängigen Programm erstellbar!

Hi,
du solltest dir klarmachen, dass die "sicherste" Möglichkeit der Speicherung von Passwörtern zusammen mit deren Abfrage nicht existiert!
Jeder Anfänger im Knacken von Programmen per Passwortabfrage lernt in der ersten Viertelstunde, wie man per Debugger einen Haltepunkt an der Passwortabfrage setzt, und diese dann einfach überspringt oder auskommentiert.
Für absolute Vollidioten ohne jegliche Ahnung gibt es Youtube-Tutorials, die diese Vorgehensweisen bis ins allerkleinste Vorführen...
Soviel zum "Sinn" einer Passwortabfrage in einem Programm!

Nun dazu, dass man das Passwort (wie auch immer) verschlüsselt im Zugriff des Programms ablegt. Ob das Passwort im Klartext in einer Textdatei, oder nach (wieauchimmer)-Verschlüsselung irgendwoanders abgespeichert ( was unterscheidet eine dll von einer anderen Datei? ) ist, spielt keine Rolle. Vorhanden ist vorhanden und somit "knackbar" oder zumindest verwendbar.

Die Frage ist für den Angreifer einfach. Lohnt es sich für mich, das Paswort zu knacken oder die PW-Abfrage zu umgehen? Wenn die Antwort JA lautet, dann hast du schon verloren...
Wenn die Anwender deines Programms Aufgrund von Seriosität, Support, Updates, KnowHow und Usability an deiner Software festhalten und auch dafür zahlen, dann kann dir der eine oder andere "Raubkopierer" völlig egal sein. Mir ist in den letzten 30 Jahren kein Softwarehersteller bekannt, der aufgrund von Raubkopien Konkurs anmelden musste!

Stell dir einfach die Frage, was dir selbst dein Programm wert wäre und was du freiwillig dafür bezahlen würdest. Dann hast du auch eine Antwort welchen Aufwand du zum Thema "Passwort" treiben musst....

Anhand der Fragestellung zu diesem Thema deinerseits würde ich dir eher raten Energie in das "Programm" zu stecken als in die Passwortabfrage.