Interessante Kodierung in der Autoit-Memory

    Hallo!

    Eigentlich ist das kein Script, mehr ne Entdeckung, aber das passt einfach in kein anderes Forum, und ich wollte mal sehen, was ihr dazu sagt. :D
    Wenn man die Memory eines AutoIt-Programms untersucht (bspw. mit Cheat-Engine) kann man an manchen Stellen (ganz abgesehen von Teilen des Programmcodes und Variablennamen, Pfaden usw.) noch etwas seeehr cooles sehen!

    http://nerdworld.de/au3-lol.jpg
    http://nerdworld.de/au3-lol2.jpg

    Wenn man genau hinsieht, kann man sogar an der Hex-Kodierung das Logo von AutoIt erkenne. :D

    Einmal editiert, zuletzt von GtaSpider (19. Dezember 2010 um 16:25)

    Jetzt wissen wir auch, warum Anfragen nach eine kleineren AutoIt-Exe immer abgelehnt werden. Dann wäre kein Platz mehr für solche Spielereien.

    ....oder einfach nur das(die) Logo-Icons in einem 16(32)-Bit-Farbformat.... :thumbup:
    Irgendwo müssen diese Dinger ja herkommen, oder hat sich bisher noch keiner gefragt, woher das Icon kommt, dass nach einem herzhaften Hieb auf F5 unten in der Taskleiste steht? 8o

    Bitmap-Format FTW

    Andy: Man, jetzt hast du die ganze Verschwörungstheorie widerlegt. Das kann ich nicht zulassen :D

    PS: Das gehört nach Talk oder Off-Topic, aber nicht nach Skripte denke ich. Kann ein Mod, das bitte verschieben?

    Zitat

    Andy: Man, jetzt hast du die ganze Verschwörungstheorie widerlegt.

    nöööö, das war doch nur ein kleiner Stupser in die Richtung, wie man dieses Logo aus dem "Memory" (sic) extrahieren und anzeigen könnte.
    Kürzestes Script gewinnt! 8o

    Hab das jetzt nicht aus dem Memory, aber hier eine einfache Variante das Muster aus der Exe-Datei anzuzeigen

    Spoiler anzeigen
    [autoit]

    Local $hFile = FileOpen(@AutoItExe, 0)
    Local $sFile = FileRead($hFile)
    FileClose($hFile)
    Local $sTest = StringLeft(StringTrimLeft($sFile, 614512), 2254)
    $sTest = StringRegExpReplace($sTest, "[\x00\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f]", " ")
    Local $aText = StringRegExp($sTest, ".{48}", 3)

    [/autoit] [autoit][/autoit] [autoit]

    Local $EasterEgg
    For $i = 0 To UBound($aText) -1
    $EasterEgg &= $aText[$i] & @CRLF
    Next

    [/autoit] [autoit][/autoit] [autoit]

    GUICreate("Easteregg", 440, 660)
    GUISetFont(Default, Default, 0, "Courier")
    GUISetState()
    GUICtrlCreateEdit($EasterEgg, 10, 10, 420, 640, 0x0800)

    [/autoit] [autoit][/autoit] [autoit]

    Do
    Until GUIGetMsg() = -3

    [/autoit] [autoit][/autoit] [autoit][/autoit]

    Sehr seltsam ... aber cool :thumbup:
    Ich erkenne nicht direkt das 2te, aber ich denke das es 2 Ostereier sein sollen ?(

    Die Exe-Dateien sind, wenn ich das richtig sehe, hauptsächlich von der beträchtlichen Größe, weil unheimlich viel Code von AutoIt mitkompiliert wird - also zum Beispiel Konstanten, die garnicht in dem Programm verwendet werden.

    Wenn man kleinere Exe-Dateien haben will, muss man wahrscheinlich eine andere Programmiersprache - bzw. eine "echte" Programmiersprache nehmen, wie C++, wo wirklich nur das kompiliert wird, was man auch geschrieben hat. ;)

    Pennywise: Das ist schon klar, aber die unnötigen Codeteile kann man per Obfuscator entfernen lassen. Es gab hin und wieder Anfragen, die AutoIt.exe zu verkleinern, aber das wird abgelehnt mit der Begründung, dass das nicht möglich ist. (sozusagen ist jedes Autitscript eine AutoIt.exe mit angehängter au3-Datei)
    Ich habe das auch nicht ernst gemeint, sondern das sollte nur ein Witz sein.

    au man, was ist denn mit euch los ? oder macht ihr alles späße ? oder hab ich was überlesen ?
    das ist das icon welches in der resource-section der datei liegt ... und es ist völlig normal das es so in acsii ausschaut.
    selbiges ist ungepackt da .ico/.bmp s immer so abgelegt werden.
    lest mal was übers PE format falls es euch interessiert ;)

    Meine stille Hoffnung:

    eines Schönen Tages stehe ich auf, schalte die Kiste an und entdecke dass es einen "echten" kompiler für AutoIt Skripte gibt der automatisch alle Variablen richtig deklariert und castet und eine richtig "echte" asm-Exe daraus macht. xD

    Das ist wahrscheinlich nicht machbar...

    Was aber geht ist:
    Das Skript wird vom Compiler durchgegangen und alles wird durch das ersetzt was der Interpreter damit machen würde.
    Berechnungen werden nicht interpretiert, sondern direkt angegangen.
    .
    .
    .
    usw.
    -----> C++ Code.
    Der wird dann Kompiliert.
    Nach meinem jetzigen Kennsnisstand sollte das funktionieren und sehr schnelle Exe Dateien liefern.

    Was auch gehen müsste was Java (auch wenn ich es persönlich nicht mag :P) uns vorgemacht hat:
    Einen Installierbaren Interpreter der wesentlich schneller interpretieren kann als der Jetzige von AutoIt.
    Dazu müsste das Skript vorkompiliert werden. (dazu könnte man das a3x Format nehmen welches zurzeit nahezu keine Bedeutung hat)

    Das War das wort zum Abend.... Gute Nacht :P

    mfg
    Mars(i)

    Zitat

    au man, was ist denn mit euch los ? oder macht ihr alles späße ?

    Völliger Ernst das alles ist, junger Padawan!

    Zitat

    und entdecke dass es einen "echten" kompiler für AutoIt Skripte gibt der automatisch alle Variablen richtig deklariert und castet und eine richtig "echte" asm-Exe daraus macht. xD

    :D Naja, eine "richtige" Exe hat man doch heute schon. Das Argument der Größe lasse ich nur in absoluten Ausnahmefällen gelten, wenn das so wichtig wäre, gäbe es wesentlich mehr *.COM-Dateien :love:

    Zitat

    C++ Code.
    Der wird dann Kompiliert.

    Kompilieren kann man jeden Code, das ist nicht das Ding! Aber so zu kompilieren, dass es JEDER Anforderung gerecht wird, ist das Problem! Genaue Berechnung oder schnelle Berechnung bissl schnell oder ungenaue Berechnung und ganz schnell?
    C++ ist da ein hervorragendes Beispiel! Da wird lauthals die Portabilität hervorgehoben, aber wenn es "wirklich" mal drauf ankommt, kommt man nicht drumherum vom "Standard" abzuweichen, und auf für die jeweilige Plattform optimierte Libs einzusetzen. Und/oder hunderte Compilerschalter vorzusehen, die auch noch grösstenteils voneinander abhängig sind und jeweils andere Ergebnisse produzieren...

    Da bleibe ich lieber bei meinem AutoIt-Spaghetticode, undeklarierten Variablen unbestimmten Typs und "eingeschränkter" Geschwindigkeit, die übrigens in 99% aller Fälle völlig ausreiched ist. Ich bin Techniker, kein Programmierer. Das Ergebnis zählt. Und Leistung = Arbeit pro Zeit. In 15 Minuten ein "Script" incl benutzbarer Oberfläche erstellen zu können, welches mir und meinen Mitarbeitern die Arbeit erleichtert, ist m.E. mehr Wert als "Portabilität".

    Zitat

    Was auch gehen müsste was Java (auch wenn ich es persönlich nicht mag ) uns vorgemacht hat:
    Einen Installierbaren Interpreter der wesentlich schneller interpretieren kann als der Jetzige von AutoIt.

    Zieh mal 2000 Programmierer von Sun ab, in ca 10-15 Jahren hast du dann auch ein "schnelles" AutoIt :rofl:
    Nein, mal im Ernst, Java ist der Weg, und auch an der Idee von .Net ist was dran. Anders ist wirkliche Portabilität nicht machbar. Und das ist gut so! Aber Moment, irgendeiner hat doch was von Dateigrösse gesagt ;) ....