Kopierschutz

Und was willst du dann mit dem Zusatzprogramm bezwecken? Wie soll das vor Softwarepiraterie schützen?

Ich kann Bugfix auch nur zustimmen. Egal was du machst, dein Script wird immer entschlüsselt werden können (trotz Obulusfaktor) und verändert werden können

Ich frage mich wozu du hier zu diesem Anliegen schon wieder ein neues Thema eröffnet hast ?

Alle Antworten die du hier heute erhalten hast, hast du doch schon sinngemäß in deinem letzten Thema ".exe zurück in .au3 umwandeln?" von gestern erhalten
http://www.autoit.de/index.php?page=Thread&threadID=32071

Kannst du mal im Detail erklärem was du schützen willst ?
Du weisst sicher was Kopierschutz bedeutet, oder ?
Was hat das nun mit SQL zu tun ?
Ein guter Kopierschutz wäre ein Dongle wie z.B. Marx Cryptobox.
Der ist (ziemlich) unknackbar und natürlich total unbrauchbar für AutoIt.

Hi,

ich denke ich verstehe schon, was du erreichen willst.

Gegen das Decompilieren kannst du dich (wie hier im Forum schon zilliardenfach beschrieben) nicht wirklich schützen.

Aber ich denke, dass du das mittlerweile verstanden hast - und wenn es dir darum geht den Programmbenutzer an einen Linzenzcode oder ein Login zu binden (ohne jetzt erstmal Hacker und Cracker ausschließen zu wollen), dann wäre die MYSQL-Sache schon ein Weg. Dann könntest du z.B. beim Programmstart ein Loginfenster bereitstellen, in welches der Benutzer seine Daten eingeben muss (und die werden dann mit dem Server abgeglichen).

Aber wenn die Daten an Dritte weitergegeben werden oder das Ding decompiliert und die Sperre ausgebaut wird, dann bist du halt machtlos.

Gruß
Trainer

Wie hast du denn die Authentifizierung gelöst? Via GET, POST, ganz anders?
Und schickst du die Infos im Klartext rüber, verschlüsselt oder unverschlüsselt?
Hast du auf der PHP-Seite alles richtig escaped bzw. gegen Injections etc. gesichert?

Nicht dass du am Ende eine kleine Tür zu- und 5 große Tore aufgemacht hast ...

Zitat

Soweit bin ich schon. Was ich machen möchte ist, das ein zweites Programm permanent die Verbindung zur Datenbank prüft. Falls diese unterbrochen wird, schließt das Programm.

Das 2te Programm zerlegen und die Datenbankprüfung abschalten ohne dass sich das Programm beendet.
Das dauert knapp 5 Minuten. (Zum Finden der Stelle(n) im Code an die das TRUE muss.)

Wenn der Quellcode offen liegt ist restlos ALLES was darin vorkommt verfügbar.
d.h. man kann jede beliebige Variable anpassen/abfangen.

Es macht also auch keinen Sinn irgendwas zu verschlüsseln was in AutoIt entschlüsselt vorliegen muss.
In dem Fall lasse ich es mir, egal wie unglaublich komplex die verschlüsselung war, einfach in die Konsole schreiben.

Oder eine Verbindung aufrechterhalten.
Dann ändere ich eben eine Variable in TRUE. Die Verbindung steht ab dem Zeitpunkt aus Sicht des Programmes.

usw
usw

Solange der Quellcode einsehbar ist ist nichts sicher.

Verstehe es jetzt bitte.

lg
M

Zitat

Es macht also auch keinen Sinn irgendwas zu verschlüsseln was in AutoIt entschlüsselt vorliegen muss.
In dem Fall lasse ich es mir, egal wie unglaublich komplex die verschlüsselung war, einfach in die Konsole schreiben.

Warum gehst du davon aus, dass alles was verschlüsselt wird in Autoit unverschlüsselt vorliegen muss? Der Schlüssel welcher zur Kodierung der Zugangsdaten verwendet wird, darf natürlich nicht im Quellcode gespeichert sein, sondern muss entweder ebenfalls eingegeben oder (z.B. nach einer aufgebauten SSL-Verbindung) vom Server geholt werden. Da gibt es schon noch Möglichkeiten.

Von daher macht Verschlüsselung schon manchmal Sinn, auch wenn man von der Grundannahme ausgeht, dass der Quellcode NICHT wirklich sicher ist. Es ist dann trotzdem ein mehr an Sicherheit vorhanden.
Alles andere wäre ein wenig schwarz-weiß gemalt, finde ich zumindest.

Gruß
Trainer

Ja aber versteh mal man nimmt das If ... = True raus und schon hat jeder die funktionen.
Das einzige was mögkich wäre: Einloggen und dann den code über Execute() verwenden, dann würde immerhin 1 Mensch das Programm kaufen um an die Daten zu komme xD
Es gibt keine Sicherheit in AutoIt, ich kenne jemanden der hat es geschafft OllyDBG und den Decompiler nichts sehen zu lassen, jedoch war 2 - 3 Tage später auch ein anderer fertig das ganzr wieder sichtbar zu machen...
Selbst EA schafft es nicht sich gegen Piraterie zu schützen, debuggen kann am Ende jeder gute und erfahrenn Debugger.

Worauf ich dennoch Hinweise: Es geht hier im Hilfebereich um Probleme die AutoIt Sourcecode betreffen, jedoch nicht solche Probleme wie Sicherheit und decompiling.
Diese wären eher in Talk oder Off-Topic aufgehoben.

€: Wofür brauchst du das eigentlich?
Mir is noch kein AutoIt Programm zu Gesicht gekommen, für welches man zahlen sollte.

Hm, du scheinst nicht auf meine Fragen eingehen zu wollen - aber vielleicht beherzigst du ja was davon.

Unterm Strich bleibt aber trotzdem zu sagen, dass die Aussagen von Marsi et al. prinzipiell richtig sind: wer den Quellcode offenlegt, kann deine Sperren ausbauen. Ob du nun 1, 2 oder 10 Programme verwendest. Allerdings kann ich mir nicht vorstellen, dass du das nicht einsiehst bzw. verstehst - also gehe ich mal davon aus, dass du dieses Risiko als gegeben hinnimmst und alles andere so gut wie möglich absichern willst - und da spricht meiner Meinung nach, da bleibe ich dabei, auch nichts dagegen (schließlich wird nicht jeder, der dein Programm benutzen will gleich einen Decompilier heranziehen).

Mein Fazit:
- Falls jemand dein Programm knacken will, so wird er es schaffen
- Falls nicht, kannst du eine ungewollte Bedienung verhindern bzw. erschweren
- 2 Programme bringen dich - was die Sicherheit angeht - nicht weiter
- Ein dauerhaftes Überprüfen bringt ziemlich sicher auch nichts (außer Serverlast)

Gruß
Trainer