Start- / Endadresse Skript im Speicher finden

1. offizieller Beitrag

    Hallo @all :)
    Zum ersten mal finde ich leider keine Antwort auf mein Autoit Problem.
    ( @allDevelopers Danke für dieses tolle Projekt!)
    Nach dem start der compilierten EXE möchte ich die Start- / Endadresse des Autoitskriptes im Speicher wissen.
    Also die Adressen des aktuell interpretierten Skriptes.
    Für Lösungsvorschläge wäre ich dankbar.
    ( Hoffentlich habe ich nichts ganz einfaches übersehen like @scriptstart oder ähnliches :D )

    Holla die Waldfee! Bischen sehr restriktiv hier bei einer ganz normalen Frage ?(
    Ein vernünftiger Grund ist zum Beispiel, selbst wenn ein Moderator dies nicht gleich erkennen mag, der Programmschutz.
    Codecrypter ( https://www.autoitscript.com/forum/topic/15…ypt-your-script ) ist nicht ganz das was ich benötige.
    Meine Grundidee zeigt aber in die gleiche Richtung. ( Dekompilieren erschweren/verhindern, Kopierschutz)
    Hoffentlich war das genau genug erklärt.
    ( @all Vielen Dank für Lösungsvorschläge zum eigentlichen Problem )

    Auf die schnelle habe ich da 2 gute Info-Seiten gefunden:
    Memory auslesen
    Memory bearbeiten (mit Prozess)
    Ich hoffe, das hilft dir weiter, auch wenn ich mich frage, ob es so viel Sinn macht, den Memory zu blockieren/änderungen darin festzustellen.
    Wenn wirklich jemand da dran will, kommt er auch dran. Du kannst es nur schwerer machen. Alles, was ohne Passworteingabe eines Users,... läuft kann irgendwie geknackt werden... Der Computer muss ja auch irgendwie an die Daten kommen. Will jemand den Memory deines Programmes auslesen und weiß wie das geht, hat er vermutlich auch das Wissen/Können, um da anders dranzukommen.

    MfG Kanashius

    Zitat

    Selbstmodifizierender Code?
    Ich sehe dafür keinen vernünftigen Grund (außer bei Viren oder ähnlichen Programmen).


    Hast dich wohl nie damit beschäftigt, was? ^^
    Mir fallen auf Anhieb gleich mehrere Möglichkeiten ein wofür man sowas brauchen könnte.

    - Debugger beispielsweise können einen Software Breakpoint in kompilierte Programme einsetzen. Gibt aber bestimmt auch andere Ansätze für sowas...
    - Diese "Anti Hack Programme" in diversen Spielen (bei normalen Programmen noch nicht gesehen) scannen in ihrem eigenen Softwares bestimmte Stellen, um zu sehen ob dort Änderungen durchgeführt wurden. So werden eben Zugriffe bemerkt und dann kann die Software entsprechend reagieren.
    - Möglicher Ansatz für eine Seed AI (wenn auch ein nicht sinnvoller Ansatz ^^) >> https://de.wikipedia.org/wiki/Seed_AI <<
    - Wikipedia hat auch noch was: https://de.wikipedia.org/wiki/Selbstmodifizierender_Code

    Dekompilier-, Programm-, Anti-Hack-Schutz, etc. ist ein Kampf gegen Windmühlen - Don Quichotte lässt Grüßen...

    Was machst du denn so tolles, dass du mit allen Mitteln es schützen willst?

    Auch am Arsch geht ein Weg vorbei...

    ¯\_(ツ)_/¯

    @UEZ Don Quichotte nur dann, falls man 100% Schutz haben möchte. Mir reicht es schon, wenn nicht jedes Tool, welches ich über Google finde, den Source auflisten kann bzw. eine einfache Kopie mit dem USB-Stick funktioniert.
    Mein Projekt ist nicht interessant genug um Zeit und Geld in einen Hack zu inversieren.
    Also mach, in diesem Fall, ein Schutz schon Sinn.
    ( So wie auch beschusshemmende Westen getragen werden, obwohl diese natürlich nicht kugelSICHER sind ;) )

    @Kanashius Vielen Dank. NomadMemory.au3 kannte ich schon, aber hatte noch keine Zeit mich damit wirklich zu beschäftigen.
    Scheint aber wohl die einzige Alternative zu sein. Die Links werde ich später noch abarbeiten. Vielen Dank nochmals.
    Ich hatte gehofft, eventuell etwas sehr einfaches übersehen zu haben.
    Oftmals sieht man ja den Wald vor lauter Bäumen nicht :D

    Falls jemand eine simple Lösung kennt, bin ich für weitere Informationen dankbar.


    @Make-Grafik
    Danke für den Link auf Wikipedia. 6502 Assembler ... Man waren das noch Zeiten :D

    Zitat

    NomadMemory.au3 kannte ich schon, aber hatte noch keine Zeit mich damit wirklich zu beschäftigen.
    Scheint aber wohl die einzige Alternative zu sein.


    Quatsch, die greift nur auf die WinAPI zu. Die Funktionen hat AutoIt aber mtlw. selber integriert.
    _WinAPI_WriteProcessMemory() als Beispiel. Alle funktionen in der NomadMemory sind mtlw schon in der WinAPI UDF vorhanden.

    Ich glaube, das man den Code eines laufenden AutoIt Skripts nicht manipulieren kann. Immerhin wird er nicht einfach "ausgeführt" sondern interpretiert. Das bedeutet, das der Interpreter intern verschiedene Zustände haben kann. Diese Zustände hängen vom bisher gelaufenen Code ab. Ändert man nun einfach ein Stück des Codes bin ich sehr sicher, das der Interpreter (selbstverständlich ohne nachvollziehbaren Errorcode) abschmiert.

    [100% Offtopic]
    NomadMemory: Die Person die diese UDF geschrieben hat hat mehr erreicht, als dieses gesamte Forum in den letzten 100 Jahren. Wirklich JEDER der aus welchen Gründen auch immer irgendetwas mit AutoIt zu tun hatte, haben könnte, haben will, haben wird, hätte gehabt hat, usw kennt diese UDF. Wenn ich diesen Namen lese füllt sich mein Herz mit Neid, da es ein Anderer außer mir geschafft hat sich in alle Ewigkeit einen Namen zu machen, obwohl die Leistung für diesen Erfolg lächerlich gering ist. Ich bin dafür das jeder hier Anwesende eine MarsMemory, eine Make-GrafikMemory, eine AndyMemory, usw erstellt die jeweils den gleichen Funktionsumfang haben. Villeicht schaffen wir es auf dieses 20 Jahre alte Schiff aufzuspringen, um wenigstens ein kleines Bisschen Erfolg im Leben zu haben. Amen.
    [/Bitte innerlich so lesen, als würden diese Worte in der Kirche vorgetragen werden]

    @Mars, hab ich tatsächlich schon gemacht. Meine UDF baut direkt auf die winapi UDF auf, macht 50% weniger eigencode und bleibt Übersichtlich. Ist im bösen forum auch schon hochgeladen. Und das meine ich ernst, nicht als Witz ^^

    Zitat von AspirinJunkie

    Ich nicht - und nun?Hab ich was Grundlegendes verpasst in den letzten 10 Jahren?

    Glaube nicht :D mir ist die auch noch nicht übern weg gekrochen...klar gehört hab ich davon schon aber ich habe sie noch nie benutzt geschweige denn eine ahnung wofür die gut ist :/
    da muss ich mich jetzt wohl ganz schön schämen nicht?

    Bild1: Ich beim debuggen

    [Blockierte Grafik: http://data5.blog.de/media/039/3707039_6d9a32c9d0_m.gif][Blockierte Grafik: http://www.looki.de/gfx/user/1/5/1/680c5_816726/avatar_160.jpg] Die UDF wrappert die DLL Call Aufrufe zu bestimmten Funktionen, um Werte direkt im RAM zu lesen bzw. zu verändern. Damit sollte damals in AutoIt ein einfacher manueller Zugriff auf den Arbeitsspeicher erreicht werden. Sehr beliebt bei vielen Bot Codern, da man damit eben viel mehr Möglichkeiten hat als diese klassischen Pixelbots. :D

    NomadMemory.... :rofl:

    @Mars, du hast vollkommen Recht! Mir spritzt auch der Neid aus allen Poren! Da hat es jemand geschafft, aus SCHE*** Gold zu machen, denn JEDER, der mal ein "U*L*T*R*A*ROXX*O*R"-Coder werden will, nimmt dafür "natürlich" dieses phänomenale Script.

    Mal ganz ohne Spass, dieses #grmblfxx#-Script war eins der Gründe für AssembleIt und AssembleIt2, denn in der FASM.UDF wurde es eingesetzt, das hat mir nicht gepasst!
    Und gebraucht habe ich es noch nie!

    @AspirinJunkie,
    willkommen im Club, ich kenne mich mit diesen "Dingen" auch nicht aus :saint: