Hallo
Autoit ist ja opensource.
Könnte man nicht einfach ne anleitung posten wie man sein eigenen Compiler schreibt bzw. was man ändern muss damit der Decompiler nicht mehr geht?
Weil nach jeder neuen Version geht der Decompiler ja nicht mehr.
Wär es möglich wen ja könnte jemand hier ne anleitung reinstellen für das umschreiben ?
Decompiler unschädlich machen
-
- [ offen ]
-
Freaky -
9. Dezember 2009 um 17:42 -
Geschlossen -
Erledigt
-
Eigentlich ist sowas fast unmöglich weil es wird immer schlaue geben die die Cryption kancken sieht mann ja bei WINDOWS
aber was man machen könnte ist den skrip obsfucaten das schützt noch mal extra
gruß Michael
-
- Also AutoIt ist nicht OpenSource (das war mal)
- Wenn du wirklich AutoIt3 komplett neu schreiben willst wünsche ich dir viel Spaß
Echten Schutz vor Dekompilierung gibt es erst mit einem echten Compiler und den wird es nicht geben. Bei AutoIt wird nur das Skript etwas verschlüsselt und zusammen mit dem Interpreter in eine Exe gepackt. -
wen du den neusten decompiler kenst dann hilft dir obfuscator nicht weiter
der macht das auch rückgengig
-
Naja das würd wohl stimmen aber es wehrt zumindest billig decompiler ab
-
Hi,
einen Schutz in dem Sinne gibt es nicht.
Du könntest dir einen eigenen Obfuscator schreiben, aber sicher wird der auch nicht sein.
Allerdings kann man Daten immer Abfangen. Wenn man den Befehl findet, der sich mit einem Passwort auf einem FTP-Server einloggt, dann kann man durch Debuggen immer den Klartext herausfinden. -
- Also AutoIt ist nicht OpenSource (das war mal)
-
Wenn du wirklich AutoIt3 komplett neu schreiben willst wünsche ich dir viel Spaß
Echten Schutz vor Dekompilierung gibt es erst mit einem echten Compiler und den wird es nicht geben. Bei AutoIt wird nur das Skript etwas verschlüsselt und zusammen mit dem Interpreter in eine Exe gepackt.ich habe nie gesagt autoit neu schreiben
nur den compiler etwas abändernachja habe gesehen das autoit beim compilen ein passwort setzet xD
Spoiler anzeigen
Code
Alles anzeigenScript Type 3.2.5+ found. AlternativeSigScan for 'FILE'-signature in au3-body... 00043055 -> SrcFile_FileInst: >>>AUTOIT SCRIPT<<< Seeking back to script start position... AU3_Signature: A3 48 4B BE 98 6C 4A A9 99 4C 53 0A 86 D6 48 7D £HK¾˜lJ©™LS †ÖH} 00043013 -> SubType: 0x41 AU3! ~ Note: The following offset values are were the data ends (and not were it starts) ~ 00043017 -> New AutoIt Script Found. - Type2 = EA06 Script is password protected! 00043027 -> Password/MD5PassphraseHash: BCCE2DC43F3F8D3FF9E5AE45C3753FE2 ¼Î-Ä???ùå®EÃu?â MD5PassphraseHash_ByteSum: 00000000 '+ 2477' => decryption key! -
Oder schütz Deinen Code, indem Du bei deinen Scripten das hier einfügst:
[autoit]If not @Compiled then _SelfDelete()
[/autoit]
Wenn Du Deine Scripte noch mit dem Obfuscator verschlüsselst, ist das schonmal einigermaßen sicher. Aber pass auf, das Du Deine Scripte nicht aus versehen löscht
-
Wie soll das den Sourcecode schützen?
Gedanken sollte man sich trotzdem mal über das Thema machen.
Die Decomplilierer verhindern, dass man "sensible" Daten in Autoitprogrammen verwenden kann, da per Decompilierer sofort die Verschlüsselungsmethode inkl. Passwort zu sehen ist.
Vielleicht könnte man einen simplen Deckmantel mit Passwortschutz in einer Hochsprache über das Autoitskript legen?
Allerdings ist mir nicht klar, ob der Code nicht zur Laufzeit abgreifbar bleibt, schließlich muss das Skript trotzdem durch den Interpreter. -
Meine Meinung dazu ist, dass es keinen absoluten Schutz gibt!
Z.B. die Spieleindustrie hat sich die wildesten Kopierschutzmechanismen ausgedacht und trotzdem werden die Spiele geknackt! Oder die Cracks und Keygens zu diversen Programmen. Haben sich die Programmieren keine Gedanken über Schutzmaßnahmen gemacht? Ich denke doch.
Zu AutoIt: wenn jemand den Skill hat, wird er den Code knacken und den Code reversen. Wenn ich meine AutoIt Programm kommerzialisieren will, dann muss ich damit rechnen, dass er geknackt wird.
Jos und Co. kann den Code von der Exe wiederherstellen - also ist eine Möglichkeit doch möglich!
Gruß,
UEZ -
Absoluten Schutz gibt es sicher nicht.
Nach "Autoit + Decompilierer" googeln ist aber doch etwas zu einfach.Um kommerzialisieren gehts mir gar nicht, eher darum per Autoit verschlüsselte Daten nicht so einfach (decomilieren des Decrypt-Scripts) zugänglich zu machen.
Was meint ihr dazu:
Eine Inputbox zur Passwortabfrage, Fileinstall mit Randomziel/Randomnamen des Autoitscript und ein einfaches Run in einer Hochsprache "richtig" compliliert. Vom Programmieraufwand würde sich der Deckmantel in Grenzen halten und man könnte fürs Hauptskript bei Autoit bleiben.
Bringt das was? Die genaue Vorgehensweise wäre ja im Deckmantel verborgen und sozusagen geheim. -
- Offizieller Beitrag
ZitatEine Inputbox zur Passwortabfrage, Fileinstall mit Randomziel/Randomnamen des Autoitscript und ein einfaches Run in einer Hochsprache "richtig" compliliert. Vom Programmieraufwand würde sich der Deckmantel in Grenzen halten und man könnte fürs Hauptskript bei Autoit bleiben.
Bringt das was? Die genaue Vorgehensweise wäre ja im Deckmantel verborgen und sozusagen geheim.Ich finde die Diskussion äußerst müßig. Aber gut...
Das ist trivial auszuhebeln, weil man allein mit der Sysinterals-Suite bequemst einem Prozess auf die Finger schauen kann und erkennt, welche Dateien er schreibt...Bin ich froh, dass OpenSource mir diesen ganzen Heimlichtuerei-Quatsch erspart :).
Johannes
-
Am Ende ist es nur eine Frage der Zeit. Ich knack dir jede *.au3 Datei, egal wie du sie schützt. Hierbei hilft mir dann z.B. OllyDbg
-
Du könntest die Exe noch einmal durch einen Protector jagen, wie zum Beispiel MEW. Dieser sollte den Meisten Debugger und Decompilierern schon etwas Kopfzerbrechen bereiten
Bietet natürlich auch keinen 100%igen Schutz, sollte aber zumin Anfänger vom Cracken abhalten.Die Syntax von Autoit ist aber auch schon so eher schwerer zu durchschauen und nichts für i-welche Scriptkiddies.
C++, VB und ASM sind da m.E. viel einfacher zu verstehen. -
Zitat
C++, VB und ASM sind da m.E. viel einfacher zu verstehen.
Aha....
Jetzt wäre nur noch die Frage, wozu jemand, der fit in Assembler ist, einen Decompiler braucht?! Es ist absolut müßig überhaupt darüber zu sprechen, im Endeffekt ist JEDE Datei (solange sie lesbar ist) zu dekodieren. Ob jetzt ein C-code kompiliert wird, oder Pascal oder Forth, solange man den Prozessorcode (oder Bytecode) im Zweifelsfall aus einem Speicherdump "lesen" kann, ist der Rest uninteressant.
Und genau da liegt der Hase im Pfeffer. Wer das KnowHow hat, der macht alles andere als zu versuchen in irgendwelchen "Pixelbots" für WOW den Angel-Code zu "knacken"....Wobei mal wieder die Zielgruppe der Decompiler-User festgelegt wäre
Wer die 10 Euro nicht hat um in der Bucht den Bot zu kaufen, der soll halt am Samstag eine Stunde Zeitungen austragen gehen! -
Zitat
Und genau da liegt der Hase im Pfeffer. Wer das KnowHow hat, der macht alles andere als zu versuchen in irgendwelchen "Pixelbots" für WOW den Angel-Code zu "knacken"....Wobei mal wieder die Zielgruppe der Decompiler-User festgelegt wäre
Wer das KnowHow hat, wird sich dann aber wohl lieber an größeren Projekte austoben (Spiele, gut geschützte Software, ...), als mal nebenbei nen kleines Autoit-Script zu knacken. Also sollte es doch reichen die Scripte gegen Anfänger zu sichern, damit diese keine Passwörter usw. auslesen!?
ZitatJetzt wäre nur noch die Frage, wozu jemand, der fit in Assembler ist, einen Decompiler braucht?!
Nen Autoitdecompiler wird er wohl dann nicht benötigen, aber wenn der Debugger an einem Protector verzweifelt, sollte man den Maschienencode zumindest in Assembler übersetzen. Denn Maschienencode können wahrscheinlich nur die wenigsten direkt lesen, falls überhaupt jemand.
-
- Offizieller Beitrag
@Pee: Ja, ihr Linuxjünger habt das eingesehen - es gibt kein Schutz, alles ist crack/hack/knackbar. Warum es also noch mit Sicherheitsmaßnahmen Versuchen?
@Topic: Ich habe mir ein eigenen Obfuscator geschrieben. Der ist nicht so komplex wie der große, macht den Code aber doch schon unleserlich.
Und den kennt (noch) kein Decompiler Einfach ein bisschen mit Execute, Assign, .. arbeitenGruß
Spider -
Gibt es dafür irgendein Tutorial?
Da man ja wahrscheinlich eine bestimmte machart dafür braucht oder ändert man einfach einen bestehenden Code?
Könnte mir das einer erklären.
Wäre super -
Wenn du die exe durch einen Crypter jagst dürfte, sie auch nicht decompilierbar sein. Du brauchst allerdings dann schon die richtigen Einstellung und auch den richtigen Crypter sonst funktioniert die exe eventuell nicht mehr. Im Bereich der Schadsoftware dürfte man genug finden... Bezüglich Tutorial kannst du bei youtube nach Crypter suchen.
Trotzdessen bleibt die exe deassemblierbar, wie jedes Programm weil nunmal der Objektcode im Codesegment liegt, der im grunde frei auslesbar ist.
Gute Deassemblierer/Debugger geben dir den Code sogar in einer Hochsprache zurück. -
Die Syntax von Autoit ist [...] eher schwerer zu durchschauen[...].
C++ [...] (ist) viel einfacher zu verstehen.
Ähm... Der Syntax von AutoIt ist einer der einfachsten, er ist BASIC-ähnlich. C++ soll einfacher sein?
