AutoIT und Cheats ? | #1 | |
Join Date: May 2011 Posts: 419 User-Rating: 199 positive
8 negative
|
AutoIT und Cheats - Wie ich finde keine gute Kombination. Das hier wird ein kleiner Informations- und Diskussions-Thread. Wie funktioniert AutoIT? - AutoIT ist eine Skriptsprache, das heißt, sie wird zur Runtime (während der Ausführung) von einem Interpreter, wie der Name schon sagt, interpretiert. Danach werden die entsprechenden Befehle ausgeführt. AutoIT bietet hier sogar die Möglichkeit, Funktionen aus Win32-DLLs einzubinden. Zum Vergleich: Programme die in C/C++ geschrieben wurden, werden (einmalig) in "Computersprache" übersetzt, die die CPU direkt versteht. Der Endbenutzer erhält also nur das fertige Programm in "Computersprache", nicht den Quellcode. Daher sind AutoIT-Programme deutlich langsamer. Wie funktioniert der AutoIT-"Compiler" ("Script to EXE Converter") ? - Laut Wikipedia sind Compiler "spezielle Übersetzer, die Programmcode aus [...] Hochsprachen, in [...] maschinell ausführbare Maschinensprache oder Bytecode überführen." Auch wenn in der offiziellen AutoIT-Dokumentation von "kompilieren" die Rede ist, wird bei AutoIT eigentlich nichts übersetzt. Der "Script to EXE Converter" packt einfach das Skript (mit dessen Abhängigkeiten), und einen etwas angepassten Interpreter in eine ausführbare Datei (Portable Executable), auch bekannt als ".exe"-Datei. Aufgrund dieser Funktionsweise lässt sich aus mit AutoIT generierten Executables auch einfach der Quellcode auslesen. Was ist mit AutoIT-Obfuscatoren ? - Solche Tools verschleiern den Quelltext des AutoIT-Programms, um es vor Reverse Engineering (der Nachkonstruktion des Originalen Quellcodes) zu schützen. Allerdings gibt es auch DeObfuscatoren, die verschleierte Programme wieder zu relativ lesbarem Code aufarbeiten. Oft wird (je nach Tool) nur der Quelltext verschleiert. Außerdem lassen sich mit allgemeinen Methoden wie z.B. dem Abfangen (Hooking) bestimmter Funktionsaufrufe (z.B. Funktionen der WindowsAPI), auch etwas über Programmablauf herausfinden. Obfuscatoren wirken sich je nach Implementierung negativ auf die Performance aus, der Triggerbot von Flo' ist hier ein klasse Beispiel: Bis der Hack mal gestartet ist, und der Login-Screen zu sehen ist, wird satte 1,14 Millionen mal Speicher reserviert (HeapAlloc()), und 0,83 Millionen mal wieder Speicher freigegeben (HeapFree()), weil teile des Skripts erst einmal "entschlüsselt" werden müssen. Das macht sich in Form einer spürbaren Verzögerung bemerkbar. Zum Vergleich: Der Windows-Taschenrechner ruft bis er offen ist, nur ca. 3000 mal HeapAlloc() auf. Ist es Vorteil gegenüber AntiCheats, AutoIT zu benutzen ? - Da AutoIT Programme nur Scripts sind, die von einem Interpreter ausführt werden, kann es ggf. für AntiCheats schwerer werden, ein solches Programm zu erkennen, da der Interpreter an sich ja kein verbotenes Programm ist. Aus diesem Grund blockieren mache AntiCheats (z.B. Punkbuster) AutoIT komplett. Wer jedoch den "Script to EXE Converter" benutzt, verschenkt diesen "Vorteil" wieder, da das Script dann ein fester Bestandteil wird, und nicht mehr von dem universalen Interpreter eingelesen wird. Außerdem ist es kaum/nicht möglich, sein Programm vor AntiCheats zu verstecken. Man kann AutoIT-Programme unter anderem nicht in einen Prozess Injizieren oder im Kernel-Modus (höhere Privilegierungs- bzw. Sicherheitsstufe) ausführen. Mein Fazit zu AutoIT: AutoIT ist gut geeignet, um sich kleine Programme mit GUI zu programmieren, die den Alltag erleichtern sollen. Kleinere Cheats, wie z.B. Trainer zählen auch dazu. Um professionelle Hacks schreiben, ist C/C++ jedoch Pflicht, da AutoIT mit vielen Einschränkungen daherkommt und langsam ist. Ein Dankeschön geht an SilverDeath, der sich alles durchgelesen hat, und mir einige Verbesserungsvorschläge gemacht hat. __________________ Da unten ist ein Like-Button, benutze ihn doch Last edited by Dr_Pepper (Sat 29. Nov 2014, 22:22)
Reason: no reason given |
|
Dr_Pepper is offline | ||
3 positive
1 negative
|
This post has been rated by: |