![]() |
Script Confuser?
Deleted
|
Sowas nennt sich Obfuscator und davon gibt es mehr als genug.
|
Und das soll was bringen? Es macht den Code für den Entwickler unlesbar, da nutzt man einfach einen Obfuscator auf das kompilierte Produkt. Ein Obfuscator macht nichts anderes als das was du da planst, nur eben für das fertige Produkt, was 10x schneller geht und 10x sinnvoller ist.
|
Es gibt auch schon genug obscufator für den code, ist wahrlich keine neue idee
|
Es gibt auch schon genug Dateishredder und Taskmanager :/
|
google mal nach "pringels source undetector", da siehste wo du rankommen musst.
der hat zwar damals alle gescammt aber trotzdem nen fettes teil was der da rausgehauen hat... |
Noch nie davon gehört, dass man das Kompilat immer möglichst klein halten sollte? :/ Wenn schon so viel Müll aus 4 Zeilen wird...
|
Quote:
Code:
Dim ABC123 As StringUnd jetzt aus reiner Interesse, was bringt es wenn du einen String als "This is a test!" definierst, er aber durch deinen Code Confuser zu irgend nem Haufen Zahlen und Buchstaben wird ? Dann würde ja jede Definition umsonst sein, und das ganze Programm wohl nicht funktionieren... |
Durch den obfuscator bleibt die funktionalität erhalten, per definition. sonst wäre es kein obfuscator sondern ein kaputtfuscator. und ob die assembly größer oder kleiner ist, macht bei .net languages dann auch keinen großen unterschied mehr.
|
Ich habs mit nem Handy geschrieben und war zu faul nochmal zurückzuscrollen um zu zählen ;f
tnd0 inwiefern ist die Assembly Größe egal? Oder meinst du, wenn es ohnehin Schrott ist? |
Die Geschwindigkeit einer executable kann man unterteilen in Load-Speed, also die Zeit die der NT-Imageloader braucht vom starten des programms bis der main-thread den Program Entry Point durchläuft, und Run-Speed, also die Zeit die ein Programm für Aufgabe X braucht.
Load-Speed hängt von der Assemblygröße ab, allerdings zählt nicht 'jedes byte' - sondern nur 4KiB Blöcke - soviel liest der NTImageLoader pro Aufruf von der Festplatte, d.h. ob eine Assembly 10KiB oder 11.9999KiB groß ist macht im Load-Speed keinen unterschied. Nach dem NTImageLoader kommt bei .Net dann noch der RunTimeCompiler, der compiled line per line, im Falle von .Net spielt hier nun die Assemblygröße eine 'kleine' Rolle, da die gesamte Assembly in einem Satz compiled wird, im gegensatz zum Java-Just-in-Time compiler. Der .Net RunTimeCompiler ist aber um ein tausendfaches schneller als der NTImageLoader, ist i.d.R. schon fertig bevor der NTImageloader den letzten 4KiB Block in den Speicher geladen hat, denn die letzten paar 4KiB Blöcke sind i.d.R. resourcen die nicht compiled werden müssen. Daher kann man behaupten, dass die Assemblygröße, wenn es um 1000 oder 5000 Zeilen Code mehr oder weniger geht, keine Rolle bei der Geschwindigkeit spielt. Wenn man Pech hat überschreitet man die 4KiB Block größe und dann braucht der ImageLoader eben einen Cycle länger. Interessanter ist die Runtime-Geschwindigkeit, die meisten Obfuscator bauen sinnlose Jumps überall ein, dadurch muss die CPU bei der Ausführung dauernd die InstructionPipe flushen was die Performance ganz schön drückt, und das ist dann ein viel viel größerer Performanceverlust als den Cycle den der NTImageLoader ggf. mehr brauchen könnte. |
Quote:
trotzdem bin ich mir ziemlich sicher das das: Code:
Dim ABC123 As StringSpoiler:
"this is a test" irgendwo vorkommt. (Ne Ver&Ent-schlüsselung erkenne ich beim überfliegen auch nirgends) |
nur hast du so wenig ahnung von programmierung wie meine oma. daher vermute ich mal dass das nicht dein produkt ist.
|
Quote:
Warum sollte es nicht mein Produkt sein? Ich habe wohl bessere Referenzen als viele andere hier. |
Quote:
|
Ich glaub Müll hast du eher in deinem Kopf.
|
Davon habe ich in der tat eine Menge, allerdings muss ich nicht aus jeder müll idee ein Tool machen und es releasen. :|
|
Quote:
Quote:
[Only registered and activated users can see links. Click Here To Register...] |
Quote:
Herausforderung sein :rolleyes: Naja wenns ein wenig weniger Müll produzieren würde, wärs vielleicht sogar brauchbar.. |
Also ich persönlich nutze eazfuscator. Die Dateigröße ändert sich nicht sonderlich und das Ganze ist einigermassen sicher. Ferner ist es mittels Drag&Drop möglich einzustellen, dass das Programm bei jedem Kompiliervorgang durch den Obfuscator gejagt wird.
Ich weiß zwar, dass es Deobfuscatoren gibt, aber selbst die produzieren nicht immer die gewünschten Ergebnisse. |
Trotzdem ist er besser als dein ranz "obfuscator". Deine Methode Strings zu verstecken ist ja ganz schlau
+= "T" [tausend zeilen müll] += "h" [tausend zeilen müll] += "i" ... |
Er hat nicht gesagt, dass dies ein Obfuscator sei.
Trotzdem find ich es am Besten einfach seine Projekte Open Source zu machen, es gibt keine Leute die deine Programme cracken und man kann die Programmleistung auf das Maximum kurbeln. |
Quote:
Denn letztlich tun alle das Selbe und am Ende gibts immer irgendwen, der einen Deobfuscator oder Deconfuser schreibt. Im Übrigen gibt es kaum eine sicherere Methode als den Code einfach nicht in das Programm zu schreiben ;) Sehr gute Ansätze, sein Programm zu schützen findet man zum Beispiel hier => [Only registered and activated users can see links. Click Here To Register...] Dagegen kann kein Obfuscator anstinken. Einziger Nachteil: Man muss als Nutzer über eine bestehende Internetverbindung verfügen. Da das aber in den meisten Fällen gegeben ist, sehe ich diese Lösung als "Ultimativlösung". |
Die ist nicht ultimativ, es gibt keine 100%ige Sicherheit.
|
Quote:
|
Wenns einfach du obfuscated ist, mag das sogar stimmen, ansonsten wären hier schon viele nicht in der Lage aktuelle Packer zu knacken, mich eingeschlossen (bzw. es ist auch immer eine Frage des Willens, wie sehr man ein Programm knacken will...Copyprotection soll keine 100%ige Sicherheit bieten, sie soll den Cracker nur so frustrieren, dass er keine Lust mehr hat).
Alleine ist es nicht unbedingt die beste Lösung, in Verbindung mit anderen aber sicherlich schon erheblich und das beste mir bekannte, was geht. Es ist halt immer am sichersten, den Code erst gar nicht in die Hände des Crackers fallen zu lassen, dann braucht man sich auch nicht viel Gedanken über Schutz zu machen (wobei umgekehrt auch einige Packer so arbeiten können, dass man ohne eine valide Serial gar nicht an den originalen Code rankommt). |
Quote:
|
| All times are GMT +2. The time now is 03:19. |
Powered by vBulletin®
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
SEO by vBSEO ©2011, Crawlability, Inc.