Reverse Engineering ist eine ziemlich aufwändige, langwierige und komplizierte Art und Weise eine Programmiersprache zu lernen. Unabhängig von der eigentlichen Sprache sind Computerprogramme heutzutage so komplex und umfangreich, daß man i.d.R. nicht sehr viel mit einzelnen Codefragmenten anfangen könnte, so man sie denn aus der Binär-Version extrahiert bekommt. Wer sich also nur mal angucken will, wie z.B. in WinAmp das Skinning umgesetzt wurde, der wird mehrere Tage und Wochen vonder Bildfläche verschwinden und sich die Zähne an Disassembler, Decompiler, Hexeditor, usw. ausbeissen, bevor er eine leichte Ahnung bekommt, wie es vielleicht umgesetzt wurde.
Das Schwierigste bei dem Ganzen ist es nach dem disassemblieren / decompilieren eine wieder assemblier- / übersetzungs-fähigen Quelltext zu bekommen.
Bei Java mag es noch möglich sein, da hier oftmals kleine Applets vorliegen, die von Funktionsumfang und Komplexität her überschaubar sind, bei .exe Dateien ist es schon aussichtsloser. Den Quelltext einer Windows / DOS Anwendung herauszukitzeln ist nahezu aussichtslos, und wenn dann lassen sich nur Teile rekonstruieren, eine übersetzungsfähige Version ist i.d.R. nicht möglich. Außerdem muß man dazu wissen, mit welchem Programm die .exe erstellt wurde, meist auch die exakte Version (z.B. gibt es Decompiler für VB3 und auch VB4, jedoch nicht für höhere Versionen; wie gut diese sind kann ich nicht beurteilen, da ichs nicht getestet habe).
Was bei .exe immer geht ist die Datei zu disassemblieren, d.h. die binären / hexadezimalen Befehle (sog. Maschinencode) innerhalb der .exe in eine lesbare Form zubringen (sog. Assemblercode). Was aber beim C64 noch sehr überschaubar war, da die Anzahl der Assembler Befehle sehr gering war, ist heutzutage mit MMX, SSE, SSE2, usw. schon ein riesen Gewirr an Möglichkeiten, die man alle beherrschen muß, um überhaupt eine minimale Chance zu haben, etwas verstehen zu können. Mit Programmieren hat das aber so gut wie gar nichts zu tun. Es gibt nur noch sehr wenige Programmierer, die so tief unten, in Assembler, programmieren. I.d.R. werden Programme in sog. Hochsprachen geschrieben (C, C++, Pascal, Delphi, Basic, Java, usw.), die dafür eingesetzten Programmierumgebungen sorgen automatisch beim Compilieren dafür daß die entsprechenden Anweisungen direkt in Assembler, bzw. Maschinencode umgesetzt werden.
Wenn Du also Programme decompilieren willst, um programmieren zu lernen, dann dauert das wesentlich länger und ist um einiges komplizierter als wenn Du Dir einfach eine VisualBasic Version zulegst, ein Buch dazu und damit loslegst. Allerdings ist es vergleichbar mit den Leuten die sich HTML mit Notepad beibringen, es dauert länger, aber man hat nachher ein ziemlich gutes Verständnis von den darunterliegenden Zusammenhängen (allerdings ist es keine Entschuldigung für immer auf diesem Stand stehenzubleiben, denn wie gesagt in Assembler programmiert heute so gut wie kein Programmierer mehr, oder sagen wir zumindest nicht für Wintel Systeme, bei Embedded Systemen oder anderen Devices sieht das durchaus anders aus; wobei ich zugeben muß ebenfalls mit Assembler und auch Notepad angefangen zu haben). Trotzdem kann ich nur extremst davon abraten so in die Programmierung einzusteigen. Im Vergleich zur Programmierung einer Hochsprache sind die Erfolge mit Assembler spärlich gesäht, mühsam zu erreichen und die Frustgrenze sehr niedrig (und Du wirst weitestgehend alleine Deinen Weg finden müssen, denn wie gesagt es programmiert kaum einer).
Was die rechtliche Situation betrifft: Wenn Du privat, zu Hause mit welchem Tool auch immer .exe Dateien disassemblierst, dann ist das Dein Privatvergnügen.
Und unter der Vorraussetzung, daß Du a) eine Lizenz des Originalprogramms besitzt, b) eine Lizenz des Tools besitzt und c) Deine Ergebnisse für Dich behälst und nicht weiter aus- / verwertest, dann machst Du Dich auch nicht direkt strafbar. Du verstößt lediglich gegen die AGBs, bzw. die Nutzungsbedingungen des Herstellers, welche i.d.R. Decompilieren generell ausschließen.
Aber da man soviel Arbeit (siehe oben) ja nicht umsonst in eine .exe investiert wird Punkt c) schwierig einzuhalten sein. Denn sei es nur daß Du ein Programm "patchst", damit es Funktion X kann oder z.B. die Nutzungsdauer einer 30 Tage Version erhöht, dann wird es schon anders. Der erste Fall einer neuen Funktionalität die nur auf Deinem Rechner läuft mag noch ok sein, sobald aber Dein Kumpel eine Kopie haben möchte (selbst wenn ihr beide eine gültige Lizenz habe), ist schon bedenklich. Bei der 30 Testversion bist Du nach Ablauf der 30 Tage nicht mehr berechtigt die Software zu nutzen, Du hast also dann keine gültige Lizenz mehr was Punkt a) verletzt....
Also Obacht!!
Was den ResHacker angeht, den setze ich auch ab und zu ein. Das Tool ist trotz seines Namens recht nützlich und gar nicht verboten! Man kann damit nämlich lediglich die Ressourcen einer .exe Datei verändern. Die Resourcen bestehen aus Stringtabellen, Layouts für sämtliche Anwendungsdialoge, Menuleisten oder Icons, etc. Man kann also z.B. das Icon einer Anwendung austauschen und durch ein eigenes ersetzen. Da die Resourcen innerhalb einer .exe Datei in einem eigenen Bereich abgelegt werden können diese problemlos ausgetauscht werden, ohne die Funktion des Programms zu verändern.
Man kann z.B. auch in einem der Dialoge die Buttons umsortieren, wenn einem die Reihenfolge nicht zusagt, oder neue Texte einfügen, aber Funktionalität kann man nicht dadurch ergänzen, dazu benötigt man den Quellcode und die Programmierumgebung. Da es einfacher ist die Original Quellen zu ändern und neu zu compilieren ziehe ich diese Variante meist vor, da jede neue Programmversion von der Programmierumgebung mit neuen Resourcen ausgestattet wird und man so jede Version erneut mit dem ResHacker anfassen müßte. Also lieber den Master ändern..
Der ResHacker kommt aber z.B. bei Flash Projektoren zum Einsatz, um das Flash Icon und die Titelleiste an die enthaltene Anwendung anzupassen, damit auf der CD-ROM eines Kunden alles "rund" ist.
confused: aso: mit was öffnet mann/frau .class-Dateien (in Verbindung mit java appelt)?)
