Schutz vor Decompeilierung

[gmarts]

Teuerste und effektivste Lösung: Lager wichtigen Coden "einfach" auf eine Hardware aus, die mit dem eigentlichen Programm kommuniziert. :mrgreen:

Das dauert bis findige Chinesen den Hardware-Chip kopiert haben.

[sECuRE]

Hi,

wenn du DAS Top-Programm geschrieben hast, dann wird es sowieso geknackt und veröffentlicht. Punkt. (Wurde ja schon oft genug in diesem Thread gesagt). Es gibt kein Programm, das nicht früher oder später veröffentlicht wird. Da nützen auch keine Packer, Dongles oder sonstige Methoden was. Die Cracker freuen sich, je höher der Level der Protection ist, denn desto mehr Ruhm heimsen sie ein.

Was ich dir raten würde: Zerbrich dir nicht den Kopf über Sachen, die du eh nicht ändern kannst. Änder lieber in jeder Kopie, die du verteilst (wenn es bei 3 Lieferungen die Woche bleibt) ein paar Bytes und schau nach, wenn du eine Raubkopie in die Hände bekommst, welcher Kunde das Programm weitergegeben hat und fühl ihm ein bisschen auf den Zahn.

cu

[Phoenix]

Zitat:

Zitat von gmarts

Teuerste und effektivste Lösung: Lager wichtigen Coden "einfach" auf eine Hardware aus, die mit dem eigentlichen Programm kommuniziert. :mrgreen:

Das dauert bis findige Chinesen den Hardware-Chip kopiert haben.

Genau DAS bringt mich auf eine Idee:
Lagere den wichtigen Code auf einen Webservice aus - und verlange Miete von den Kunden die dafür bezahlen. Das verhindert, das der Code disassembliert werden kann weil niemand Zugriff auf den Code hat.

Andersrum: Jeder Cracker wird zwar mit Leichtigkeit herausfinden, welchen Webservice er wie verwenden muss, aber Du hast auf jeden Fall mindestens die IP des Aufrufenden und damit eine eindeutige Identifikation.

Natürlich erzwingt das für das Programm zur Laufzeit eine immer bestehende Internetverbindung und Performanter wird das ganze dadurch auch nicht, aber einen gewissen Abschreckungseffekt erzielst Du damit.

Idealerweise kannst Du Deine Kunden noch dazu zwingen vorher ihre IP (mit Kundenname) bei Dir zu registrieren und nur registrierte IP's dürfen den Webservice nutzen. Macht natürlich einen gewissen Aufwand, aber DEN Schutz knackt so schnell keiner, solange nur Du Zugriff auf den Webserver hast ;-)

[DGL-luke]

und ein zugang mit dynamischer ip kostet mehr und der kunde muss auch noch ein authentifikationsprog dazukaufen, das dir seine CLSID schickt.
willkommen in der schönen neuen welt....

[mh166]

So, nun will ich auch mal! :wink: Das Thema interessiert mich irgendwie. Ich hab sowas auch schon mal probiert und habs auch schon geschafft Dialoge/Serial-Abfragen zu NOPen :stupid: (Stichwort "Checksumme" :zwinker: ). Allerdings hab ich mich nich weiter groß um das Thema gekpmmert. Nun wird es einem hier wieder schmackhaft gemacht.

Deshalb meine Frage: wie genau funktioniert das mit einem Loader (sowohl erstellen, als auch cracken)? Und was hat es mit dem Debugger-Check (IsDebuggerPresent) auf sich?

mfg, mh166, der mal wieder voller Wissensdurst ist

[Olli]

Zitat:

Zitat von mh166

Deshalb meine Frage: wie genau funktioniert das mit einem Loader (sowohl erstellen, als auch cracken)? Und was hat es mit dem Debugger-Check (IsDebuggerPresent) auf sich?

mfg, mh166, der mal wieder voller Wissensdurst ist

Guck mal die 3 Beiträge ab diesem an ;)

[Simonko]

Du musst nur aufpassen mit den Strings z.b Trial version abgelaufen oder so was. mit einen diassembler
kann man diese strings finden und dann ist es einfach den code dort zu verstehen und sprung befehle zu löschen. ansonsten wäre es unmöglich sich in den ganzen code auszukennen.

[Olli]

Zitat:

Zitat von Simonko

Du musst nur aufpassen mit den Strings z.b Trial version abgelaufen oder so was. mit einen diassembler
kann man diese strings finden und dann ist es einfach den code dort zu verstehen und sprung befehle zu löschen. ansonsten wäre es unmöglich sich in den ganzen code auszukennen.

Für einen Laien vielleicht. Die Kunst ist ja gerade auch ohne "Strings" weiterzukommen. Ergo -> Quark!

[TeronG]

??? :gruebel: Irgendwie dreht sich das alles hier im Kreis ^^
Selbst das x-te und noch so gute Pack/Verschlüsselungs-proggie muss es zur Laufzeit zu mindest Teilweise entpacken .....

Es ist wohl allen klar, daß es keinen 100% schutz giebt und nur eine Sache von aufwand und nutzen ist ... und zwar für beide Seiten.
Weder werde Ich ein 100€ Programm für 1000€ schützen noch wird es einer (zumindest keine Firma :mrgreen:) für 1000€ Knacken lassen.
(bitte legt jetzt die Zahlen nicht auf die Goldwaage Ja? ^^)

[Luckie]

Mal ein kleiner Denkanstoss: Wenn ich nicht verhindern kann, dass der Nagel mit dem Hammer in die Wand geschlagen wird, wie wäre es denn damit zu versuchen zu verhindern, dass derjenige den Hammer aus dem Werkzeugkasten nehemen kann? ;)

Olli, Motzi und ich habe da was in der Mache, der erste Teil könnte bis Ende der Woche online sein.

[MaBuSE]

Zitat:

Zitat von gmarts

Teuerste und effektivste Lösung: Lager wichtigen Coden "einfach" auf eine Hardware aus, die mit dem eigentlichen Programm kommuniziert. :mrgreen:
Das dauert bis findige Chinesen den Hardware-Chip kopiert haben.

Ich habe mir damals so ein Programm gekauft, und nun habe ich keinen ISA Slot mehr frei :-/

Das Programm hiess Chessboard und war mehr oder weniger komplett auf der Karte. Es existierte nur ein MS DOS Fontend um mit dem Anwender zu komunizieren.

Auf der Steckkarte ist unter anderem ein 6510 mit eigenem Ram drauf.
Es ist also ein eigener Rechner, der über den Bus mit dem PC kommuniziert ;-)

Damals bei den 8006er war das eine gute Möglichkeit die Rechenleistung für ein vernünftiges Schachprogramm zur Verfügung zu stellen.

[Phoenix]

Zitat:

Zitat von Luckie

Wenn ich nicht verhindern kann, dass der Nagel mit dem Hammer in die Wand geschlagen wird, wie wäre es denn damit zu versuchen zu verhindern, dass derjenige den Hammer aus dem Werkzeugkasten nehmen kann? ;)

Dann nehme ich ggf. den gesamten Werkzeugkasten und versuche den Nagel damit einzuschlagen. Oder mit der Schuhsohle. Ist zwar jeweils mühsamer, kann aber letzten Endes mit einigem Aufwand dennoch erfolgreich sein.

Aber was ist, wenn es erst gar keinen Nagel gibt? Die Codeauslagerung in einen Bereich auf den nur der Entwickler Zugriff hat (sei es Hardware oder eben ein Webservice) entzieht dem Angreifer den kompletten Code und bietet somit keinerlei Angriffsfläche (=> keinen Nagel) mehr.

[sECuRE]

Hi,

@Luckie: Nun, wenn du meinst, dass du den Zugriff auf Debugger etc sperren willst: Man kann das Programm auch Disassemblen und dann mithilfe von diesem Code knacken oder das Programm Schritt für Schritt durchlaufen lassen und die Debugger-Abfrage umgehen...

Bin auf jeden Fall gespannt, was ihr euch da habt einfallen lassen ;)

cu

[brechi]

denke kaum, dass die da irgendwelche antidebugger tips geben, höchtens nen listing aller crypter etc.

dafür ist luckies programm selbst zu schlecht geschützt :)

[DGL-luke]

Zitat:

Zitat von Luckie

Mal ein kleiner Denkanstoss: Wenn ich nicht verhindern kann, dass der Nagel mit dem Hammer in die Wand geschlagen wird, wie wäre es denn damit zu versuchen zu verhindern, dass derjenige den Hammer aus dem Werkzeugkasten nehemen kann? ;)

Olli, Motzi und ich habe da was in der Mache, der erste Teil könnte bis Ende der Woche online sein.

also wenn du damit meinst, dass du einen virus mitlieferst, der alle bekannten debugger/dekompilierer usw. zerstört/behindert/sonstwas dann würde ich so etwas extrem unverschämt finden! denn mein computer ist mein computer, und in die progs, die ich da installiert hab, lass ich mir von niemandem(ausser leider WinXP) hineinreden!

Also wenn der Hammer der Dekompilierer ist, dann gibt es ja gar keine Möglichkeit, die nicht als Virus zu klassifizieren wäre, oder?

[alcaeus]

Zitat:

Zitat von DGL-luke

also wenn du damit meinst, dass du einen virus mitlieferst, der alle bekannten debugger/dekompilierer usw. zerstört/behindert/sonstwas dann würde ich so etwas extrem unverschämt finden! denn mein computer ist mein computer, und in die progs, die ich da installiert hab, lass ich mir von niemandem(ausser leider WinXP) hineinreden!

Ruhig Blut und abwarten ;)
Ich bin mir sicher Luckie, Olli und Motzi werden das Ding hier voller Stolz vorstellen ;)
Luckie selbst würde so ein Programm nichtmal schreiben ;)

Greetz
alcaeus

[Luckie]

Mancheiner wird es sicher gemerkt haben, dass Olli, Motzi und ich gestern Abend ab 9 Uhr bis spät in die Nacht im Chat waren. Olli hat uns da so ein paar Sauereien erklärt/demonstriert. Ich und Motzi sind gerade dabei das in eine veröffentlichungsreife Form zu bringen. Im Laufe des Tages könnt ihr mal eine neue Demo-Version des Usermanagers runterladen (Ich geb Bescheid), dann können wir mal gucken, ob es was taugt, was uns Olli da erzählt habt und ob ich es verstanden habe. ;)

Zitat:

Zitat von sECuRE

@Luckie: Nun, wenn du meinst, dass du den Zugriff auf Debugger etc sperren willst: Man kann das Programm auch Disassemblen und dann mithilfe von diesem Code knacken oder das Programm Schritt für Schritt durchlaufen lassen und die Debugger-Abfrage umgehen...

Du meist statische Debugger. Aber die versagen, wenn die Exe durch einen Scramblker/Crypter gejagt wurde und unter NT ff. hat uns Olli gerade was demonstriert. ;)

[brechi]

laufen da mehrere protectoren drüber oder ist die debugger detection / checksumme in delphi programmiert?

[Luckie]

Zitat:

Zitat von brechi

laufen da mehrere protectoren drüber oder ist die debugger detection / checksumme in delphi programmiert?

Wo beim jetzigen? Ist nur ein Scrambler drübergelaufen. Beim neuen wird es etwas mehr sein. ;)

[Olli]

@Luckie: *gähn* Habe mich mal ein wenig ausgeschlafen. Nach 40h "online" war das auch nötig.

Zitat:

Zitat von Phoenix

Dann nehme ich ggf. den gesamten Werkzeugkasten und versuche den Nagel damit einzuschlagen. Oder mit der Schuhsohle. Ist zwar jeweils mühsamer, kann aber letzten Endes mit einigem Aufwand dennoch erfolgreich sein.

ROFLMAO!!!! :mrgreen:

Zitat:

Zitat von Phoenix

Aber was ist, wenn es erst gar keinen Nagel gibt? Die Codeauslagerung in einen Bereich auf den nur der Entwickler Zugriff hat (sei es Hardware oder eben ein Webservice) entzieht dem Angreifer den kompletten Code und bietet somit keinerlei Angriffsfläche (=> keinen Nagel) mehr.

Beides ist mit heutigen Möglichkeiten nicht machbar. Auch Chips und Dongles kann man auslesen. Das Problem ist immer die Peripherie. Und genau dort ist es wo ich ansetze, wenn ich einen Dongle auslesen will *g*
Ein Prozessor aus Blackbox ist denkbar, aber nicht finanzierbar. Eine VM ist ebenfalls machbar - liefe eben auf einen softwarebasierten Prozessor hinaus - dort muß der Reverser also nicht nur den Maschinencode verstehen, sondern einen neuen (undok.) Maschinencode erforschen und lernen.

Ich finde aber, daß Luckie ein wenig übertreibt mit seiner Euphorie. Habe ihm auch gesagt, daß statische Analyse das Problem umgeht.

Zitat:

Zitat von sECuRE

@Luckie: Nun, wenn du meinst, dass du den Zugriff auf Debugger etc sperren willst: Man kann das Programm auch Disassemblen und dann mithilfe von diesem Code knacken oder das Programm Schritt für Schritt durchlaufen lassen und die Debugger-Abfrage umgehen...

Das wiederum ist nicht immer so einfach, wie du denkt ... was zu beweisen sein wird :zwinker:
Debugger sperren mach man nicht ... sowas ist nicht nett gegenüber dem Anwender. Und wenn ich dann an diese tollen "Detections" denke, wo REGMON, FILEMON usw. ausgeschalten werden. Pah ... Fenstertitel austauschen und der "Schutz" war nie da.

Zitat:

Zitat von brechi

denke kaum, dass die da irgendwelche antidebugger tips geben, höchtens nen listing aller crypter etc.

dafür ist luckies programm selbst zu schlecht geschützt :)

Findest du das bei der letzten Version immernoch? Es ist machbar, keine Frage. Aber man muß schon mehr Aufwand betreiben. Da wir weiter oben bemerkt haben, daß es eine Kosten/Nutzen-Rechnung ist, würde sich vielleicht jemand den Spaß machen es zu knacken. Ernsthaft jedoch nicht.

Zitat:

Zitat von brechi

laufen da mehrere protectoren drüber oder ist die debugger detection / checksumme in delphi programmiert?

Schau dir's doch dann an. Übrigens, du kennst den Trick ja schon.

[Luckie]

Er hat es bei der letzten Version gefunden, nur dass unter Windows 2000 Die Nick-Messagebox mit deaktivierten OK Button erscheint, somit ist das Programm weder nutzbar noch ohne Taskamanger beendebar. Eigentor würde ich sagen, oder, um bei meiner Analaogie zu bleiben: Auf den Daumen gehauen. :mrgreen:

[brechi]

ich weiß ja nicht was ihr mit der letzen version meint,

ich hab das nur für die version gemacht die mit UPX und danach mit so nem crypter gepackt wurde
dafür brauch ich nicht aml 10 mins

hab dann auch schnell den check vom debugger und von der msgbox rausgemacht, luckie hat die version - unter win2k funzt es wohl nich, unter XP schon

jedenfalls hab ich die verschlüsselungen leicht umgangen, die exe ist genau wie die, die normal compiliert wurde...

downlaodlink hat luckie ich geb den net weiter, müsst ihr den fragen

falls es sich bei "der" vresio ndie du meinst um eine neue mit mehr checks handelt, die hab ich noch nicht, aber ich glaube es wird nicht wirklich schwerer werden

[Luckie]

Zitat:

Zitat von brechi

falls es sich bei "der" vresio ndie du meinst um eine neue mit mehr checks handelt, die hab ich noch nicht, aber ich glaube es wird nicht wirklich schwerer werden

Die neue Version gibt es noch nicht. Aber ich glaube nicht das einfach wird. ;)

[Olli]

Zitat:

Zitat von Luckie

Die neue Version gibt es noch nicht. Aber ich glaube nicht das einfach wird. ;)

Einfach nicht. Aber bei brechi bin ich zuversichtlich, daß er schnell auf den Trichter kommt. Ist ihm bisher ja auch gelungen, gelle? :zwinker:

[brechi]

Luckie musst schon sagen wenn du deinen UserMng geupdatet hast mit dem neuen schutz

[Luckie]

Jetzt ist sie da: http://www.delphipraxis.net/internal...=255881#255881

Aber um den geht es hier nicht. Wir sind nur wegen des Schutzes darufgekommen. Bitte, wenn es speziell um den Usermanager geht im entsprechenden Thread diskutieren.

[Nicodius]

ihr seid ziemlich off topic :warn:


ont
dede compiler wurde in delphi geschrieben oder?

[Olli]

Zitat:

Zitat von Nicodius

ont
dede compiler wurde in delphi geschrieben oder?

Ja. Source ist verfügbar.

Was ist daran übrigens OT?

[Nicodius]

ich habe eh onT geschrieben?

[Olli]

Zitat:

Zitat von Nicodius

ich habe eh onT geschrieben?

Ich meinte auch eher diesen Kommentar:

Zitat:

Zitat von Nicodius

ihr seid ziemlich off topic :warn:

[Nicodius]

ist ja egal


--> siehe auf luckies beitrag unten "editiert von" ihr habt angefangen über den Usermanager zu plaudern ;)

[Mystic]

Es gibt auch noch ein Delphi Anti-Cracking FAQ (englisch), das erklärt wie man das Cracken der eigenen Programme erschweren kann.

[brechi]

ich war mal so frei und hab nen unmorpher für die morphine27 version geschrieben (1. seite des threads)

www.arschvoll.net/unmorph.zip

morphine 2.7 sowie mein unmorpher enthalten :)

[chris]

hi,

Zitat:

Zitat von turboPASCAL

Hallo Leute,
Ein Tipp ?!
Ich habe mich immer damit Beholfen, das ich meine EXE-File
mit UPX packe. Die gepackte EXE dann in eine Hexeditor laden,
die Stringvorkommen 'UPX' in sinnlose Zeichen zB. 'UPX' nach 'z3"',
das nächste dann in '8J_' usw. speichern.
(man könnt' ja auch n' Prog schreiben :mrgreen: )

Wer nun versucht mit UPX zu ent.- bzw. zu packen.... hahaha

Vorteil: Prg. ist "verschlüsselt" und Gepackt.

Die Exe kann man problemlos starten (noch keine Probleme gehabt).
Einen Ultimativen Schutz vor guten Hackern wird es aber wohl nie nicht geben. :wink:

MfG.

Nachteil: Laut UPX License Agreement nicht legal (s. Zitate)!

Zitat:

SPECIAL EXCEPTION FOR COMPRESSED EXECUTABLES
============================================

[..]

2. This also implies that the UPX stub must be completely unmodfied, i.e.
the stub imbedded in your compressed program must be byte-identical
to the stub that is produced by the official unmodified UPX version.

[..]

und

Zitat:

ANNOTATIONS
===========

[..]

- We grant you special permission to freely use and distribute all UPX
compressed programs. But any modification of the UPX stub (such as,
but not limited to, removing our copyright string or making your
program non-decompressible) will immediately revoke your right to
use and distribute a UPX compressed program.

- UPX is not a software protection tool; by requiring that you use
the unmodified UPX version for your proprietary programs we
make sure that any user can decompress your program. This protects
both you and your users as nobody can hide malicious code -
any program that cannot be decompressed is highly suspicious
by definition.

[..]

[Olli]

@chris: Dann benutzt du einfach eine alte UPX-Version von vor 0.84 und schwuppdi hast du das mit eingebaut (zumindest soweit wie es auch durch Modifikation möglich ist). In diesen älteren Versionen wurden noch keine Daten zur späteren kompletten Wiederherstellung mitgespeichert und die sind auch mit neueren UPXen nicht zu entpacken.

[brechi]

denk mal ProcDump wird das aber hinbekommen (ungetestet)
uns os schwer isses gar nicht nen programm zu dumpen und ie import sectionwieder herzustellen, also den dump wieder lauffähig zu machen

[Olli]

Zitat:

Zitat von brechi

denk mal ProcDump wird das aber hinbekommen (ungetestet)
uns os schwer isses gar nicht nen programm zu dumpen und ie import sectionwieder herzustellen, also den dump wieder lauffähig zu machen

Ja eben. Ich meinte ja auch nur, daß man statt der Methode mit dem UPX-Scrambler auch einfach eine frühere UPX-Version benutzen kann. Daß es nichts gibt, was nicht knackbar wäre haben wir bereits mehrfach erwähnt :zwinker: .

Ist ja auch egal wie man es entpackt. Solange das Programm zu einem Zeitpunkt vollständig entpackt im Speicher vorliegt, ist es immer "relativ" einfach. Ansonsten ist es eben aufwendiger.

[Progcoder]

Hallo!

Ich weiß, das es den absoluten Schutz nicht gibt. Aber ich weiß auch das man eine Verschlüsselung wählen kann, die so gut ist, das der Aufwand zum Entschlüsseln zu
groß wird, um sich noch zu rentieren.

Beispiel:

Wenn ich auf meinem aktuellen Rechner 10 Jahre brauche, um eine Seriennummer zu knacken, die ich zum Installieren meiner Raubkopie brauche, habe ich die Software in dieser Zeit mit meinem rechtmäßig erworbenen Delphi auch neu geschrieben.

Nun geht es hier um den Schutz vor Reassemblierung einer EXE, um den Programmcode vor unbefugter Einsichtnahme zu schützen, um beispielsweise eine Testversion herausgeben zu können, die nur über einen begrenzten Zeitraum lauffähig ist. Also könnte im einfachsten Fall sogar ein Schutz ausreichen, der verhindert, das im Testzeitraum die Zeitbegrenzung entfernt werden kann. Dann ist natürlich trotzdem ein weiterer, stärkerer Schutz nötig, der verhindert, das in vertretbarer Zeit nach Testablauf in aller Ruhe eine Freischaltung erfolgen kann.

Kurz und gut. Es kommt darauf an, den Schutz so zu gestalten, das der Aufwand, den Schutz zu umgehen auch für den Profi unvertretbar hoch wird. Interessant wäre in diesem Zusammenhang, zu erfahren, wieviel Zeit sich ein Profi für so eine illegale Dekodierung maximal nimmt. Kommt sicher auf das Programm selber und auf den Verkaufspreis an. Vielleicht noch auf das Budget des Interessenten der Software. Ein Laie wird eher aufgeben, als ein Profi, der wirklich alle Tricks kennt.

Ein kommerzielles Programm für die Aufgabe, die hier gestellt ist, ist ExeCrypter. Einfach mal googeln.

Viel Erfolg wünscht

Progcoder

[Olli]

Zitat:

Zitat von Progcoder

Ich weiß, das es den absoluten Schutz nicht gibt. Aber ich weiß auch das man eine Verschlüsselung wählen kann, die so gut ist, das der Aufwand zum Entschlüsseln zu
groß wird, um sich noch zu rentieren.

Dies erreichst du nur indem das Programm zu keinem Zeitpunkt vollständig entschlüsselt im Speicher vorliegt. Also jeder Codeblock wird erst vor seiner Ausführung dekodiert. Ist das Programm dann hinreichend groß, wird der Aufwand auch unschön. Allerdings birgt diese Laufzeit-Dechriffierung auch gewisse Risiken.

Zitat:

Zitat von Progcoder

Wenn ich auf meinem aktuellen Rechner 10 Jahre brauche, um eine Seriennummer zu knacken, die ich zum Installieren meiner Raubkopie brauche, habe ich die Software in dieser Zeit mit meinem rechtmäßig erworbenen Delphi auch neu geschrieben.

Du brauchst aber keine 10 Jahre, weil der Autor den Schlüssel mitliefert. Es wird also nicht nötig sein eine Verschlüsselung zu knacken (im kryptographischen Sinne). Das habe ich weiter oben bereits mehrfach erwähnt.

Zitat:

Zitat von Progcoder

Kurz und gut. Es kommt darauf an, den Schutz so zu gestalten, das der Aufwand, den Schutz zu umgehen auch für den Profi unvertretbar hoch wird. Interessant wäre in diesem Zusammenhang, zu erfahren, wieviel Zeit sich ein Profi für so eine illegale Dekodierung maximal nimmt.

Da wirst du nur keine absolute Angabe bekommen, sondern das wird vollkommen von deinem Programm und seiner Attraktivität abhängen! Der Preis ist auch nicht vorrangig, denn es gibt Leute, die das machen werden um (es) sich zu beweisen (Ergebnis bleibt unter Verschluß) und jene die es machen werden um (es) sich zu beweisen und es anderen beweisen (indem sie ihr Ergebnis als Crack/Keygen oder sonstwas öffentlich online stellen). Letzteres finde ich unmoralisch. Und das unterscheidet IMO den Reverser vom Cracker - Moral - auch wenn sich beide "Arten" das gleiche Wissensgebiet teilen.

Zitat:

Zitat von Progcoder

Ein kommerzielles Programm für die Aufgabe, die hier gestellt ist, ist ExeCrypter. Einfach mal googeln.

Die kommerziellen Programme haben nur einen Vorteil (für die Seite des Autoren): "security through obscurity".
Bei OpenSource, wie Morphine, schreibt dann einfach jemand wie brechi einen "Entpacker".
Nachtrag: Das soll nicht heißen, daß dies für kommerzielle Programme (und also ClosedSource) unmöglich wäre - der Aufwand ist eben nur höher, da man ja wiederum den "Packer" analysieren muß.

[brechi]

ich habe mir den source von morphine nich mal angeguckt und nen unmorpher geschrieben
bin gerade an nspack dran (unter google noch ziemlich unbekannt, aber besser als aspack)

man nimmt sich die zeit die man hat,e gal wie lange es dauert, und wenn man jeden tag nur 30 minuten reinschaut.
je besser es geschützt ist desto mehr spass macht es, und auch als cracker kann man geld verdienen.

execryptor ist an sich nicht schlecht, aber da ist nichts verschlpsselt, es werden nur unzählige jumps etc zwischengepackt was extrem auf die performance geht, ausserdem sind strings verschlüsselt (entschlüsselungsalg. ist auch net so doll) und sie haben ne eigene GetProcAddress funktion die nicht auf md5 oder vergleichparem basiert sondern halt die verschlüsselten strings testet (diese werden auch wieder entschlüsselt)
zum schluss gibbet noch den antidebugger der auch net weiter schwer ist wegzunoppen

so doll is der crypter also auch nicht...