Reverse Engineering
-
Hallo,
wenn ich eine dll mit .net reflector reverse engineere, ist das dann wirklich 1:1 wieder der ursprüngliche Code oder können VAriablen auch mal unterschiedlich sein ?
-
Auf .NET Beschränkt:
Alle Bezeichner sind die Gleichen, allerdings wird der Code nie der Gleiche sein.
-
Soll heißen ob es eine foreach oder nur for Schleife war kann der Decompilierer nicht rausfinden ?
-
...
-
ohne Verschlüsselung kann man Reverse Engineering wohl kaum stoppen. Aber irgendwie ist es ja auch gewollt sonst würde Microsoft nicht sogar ein eigenes Tool anbieten
-
...
-
Ich kann mich aber an einen Bericht erinnern, indem ging es eben darum wie man sich vor reverse Engineering schützen kann. Irgendwas wird es also geben.
-
...
-
Nee gewollt ist es nicht. Aber warum bieten sie ein Tool dafür an . Gewissermaßen unterstützen sie ja dadurch dass man durch reverse Engineering Code klauen kann.
-
M$ bietet es vielleicht an, weil es sonst andere tun? Mittel und Wege gibt es immer.
-
im prinzip wird man code immer irgendwie zurückführen können. code sind anweisungen entweder an die machine (machinenbefehle, also nativ, d.h. assembly) oder eben an einen interpreter. sofern man weiß, was welcher befehl bedeutet, kann man die anwendungen stück für stück so rekonstruiren, dass man seinem spezifischen ziel näher kommt. aber auf den 1:1 code wird man nie zurückkommen können, wenn dieser nicht ersichtlich ist bzw. er nicht in irgendeiner form ansehbar ist. aber das ist ja auch nicht unbedingt nötig.:D jedenfalls, ob microsoft das gefällt oder nicht ist also irrelevant, allerdings kann man ja ein RE sehr erschweren je nach mittel und weg.
-
Zeus schrieb:
Auf .NET Beschränkt:
Alle Bezeichner sind die Gleichen, allerdings wird der Code nie der Gleiche sein.
Das betrifft nur "sichtbare" Bezeichner.
Lokale Variablennamen sind alle weg.
-
codereconstruction schrieb:
im prinzip wird man code immer irgendwie zurückführen können. code sind anweisungen entweder an die machine (machinenbefehle, also nativ, d.h. assembly) oder eben an einen interpreter. sofern man weiß, was welcher befehl bedeutet, kann man die anwendungen stück für stück so rekonstruiren, dass man seinem spezifischen ziel näher kommt. aber auf den 1:1 code wird man nie zurückkommen können, wenn dieser nicht ersichtlich ist bzw. er nicht in irgendeiner form ansehbar ist. aber das ist ja auch nicht unbedingt nötig.:D jedenfalls, ob microsoft das gefällt oder nicht ist also irrelevant, allerdings kann man ja ein RE sehr erschweren je nach mittel und weg.
Kommt halt immer darauf an was der Compiler übrig lässt. Zb. ein C++-Compiler wird in der Regel für diese beiden Fälle identischen Code erzeugen:
class Foo { struct Vector { float x, y, z; } vec; float do_something() { return vec.x * vec.y * vec.z; } };vs.
float do_something(float* v) { return v[0] * v[1] * v[2]; }Oder der Aufruf wird direkt inlined und es bleibt garnichts übrig.
Das macht im Falle von C++ sehr schwierig/unmöglich einen akkuraten Decompiler zu schreiben.
Bei C# ist es viel einfacher.
-
blurry333 schrieb:
ohne Verschlüsselung kann man Reverse Engineering wohl kaum stoppen. Aber irgendwie ist es ja auch gewollt sonst würde Microsoft nicht sogar ein eigenes Tool anbieten
Du fliegst eine Boeing XYZ, aber hast noch keine einzige Flugstunde! Bitte verschone uns damit.
-
-lowbyte- schrieb:
...aber hast noch keine einzige Flugstunde! Bitte verschone uns damit.
Ich schon, ich fliege regelmäßig aus Beziehungen, Firmen, Clubs, Programmen und Foren! Allerdings meist nicht als PIC, kann ich es mir trotzdem anrechnen lassen
-
Da es sowieso nicht wirklich verhindert werden kann um Codeklau zu verhindern dann wohl besser gleich Tooling anbieten und mir als Entwickler in üblen Situationen (bspw. fremde DLL kackt ab) die Möglichkeit geben nachzusehen warum dem so ist...
MfG SideWinder
