Zitat:
ich wollte mal wissen wie man überhaupt einen Wert in einer Exe datei von delphi speichern kann?
Da gibt es mehrere Wege:
Als normale Konstante
Delphi-Quellcode:
const
MeinWert: TGUID = ['{A5F774AA-9DAF-4F52-A96D-DFF12FEB0086}'];
die im Datensegment der Anwendung gespeichert würde.
Da wir aber aktiven und verschlüsselten Code möglichst auch mit Daten versehen wollen speichern wir diese Daten im Codesegment
Delphi-Quellcode:
function Copyright: PChar;
asm
MOV EAX,OFFSET @@1
RET
@@1:
DB '
Portion Copyright (c) 2003 by Hagen Reddmann', 0
end;
Mit Writeln( Copyright ); greifen wir also ReadOnly auf eine Testkonstante die im Codesegment gespeichert wurde zu.
So, als Schutzmechanismus muß man immer auch das Konzept des Schutzes überdenken, dies ist der Erste Schritt. Wichtig dabei, zerlege jeden Algorithmus in ZWEI Teile. Einem zum Installieren des Schutzes und verschlüsseln in einer separaten Anwendung, und in der geschützten Anwendung NUR zur Verifikation und Entschlüsselung den anderen Teil des Algos.
Damit die Schutzsoftware weiß wo sie was zu verschlüsseln und zu patchen hat integriert man Marker in die zu schützende Software. Alles was zwischen und inklusive der Marker ist wird dann verschlüsselt.
Delphi-Quellcode:
function StartCode: PChar;
asm
MOV EAX,OFFSET StartMarker
RET
StartMarker:
DB '
CODESTART'#0
end;
procedure ProtectedCode;
begin
....
end;
procedure StopMarker;
asm
DB '
STOPCODE'#0
end;
function StopCode: PChar;
asm
MOV EAX,OFFSET StopMarker + 9
RET
end;
StopCode - StartCode = SizeOf(ProtectedCode);
Wie man den Code in ProtectedCode nun schreiben muß hängt davon ab wie man diesen Code entschlüsselt. In meiner Demo erzeuge ich einen Byte Array Block, kopiere alles zwischen StartCode bis StopCode da hinein. Dann entschlüssele ich dieses ByteArray und springe per CALL in diesen Speicherbereich hinein. D.h. der eigentliche verschlüsselte Code wird niemals direkt ausgeführt sondern nun eine Kopie die entschlüsselt wurde im dynamischen Speicher.
Die Schutzsoftware muß nun die EXE Patchen. Die lädt die EXE zB. in einem TMemoryStream, sucht nach 'STARTCODE' und 'STOPCODE' und verschlüsselt diesen Bereich. Danach wird der TMemoryStream wieder auf die Platte gespeichert.
Man könnte also auch den Code zwischen StartCode-StopCode als normale Resource in die EXE einlinken, oder sogar diesen Code als verschlüsselte Datei als Registrationsschlüssel verschicken.
WICHTIG! dabei ist das dann aber dieser Code NIEMALS mit relativen Einsprungadressen in zB.
API Funktionen arbeiten darf. Das liegt daran das diese Adressen relativ zur Adresse im Codesegment wo der CALL steht durch den Moduleloader realloziert werden. Ein einfaches LoadLibrary() im ProtectedCode ist also tabu und würde zum Absturtz führen. Am besten ist es für ALLE diese Funktionen eine eigene "Realokationstabelle" zu definieren.
Delphi-Quellcode:
var
MyReloc =
packed record
LoadLibaray:
function(
Name: PChar): THandle;
stdcall = @LoadLibrary;
FreeLibrary:
function(
handle: THande): Integer;
stdcall = @FreeLibrary;
.. usw. usw.
end;
Das Hauptprogram initialisiert nun diesen MyReloc mit den absoluten Adressen zu den benötigten Funktionen. Dem Protectedcode wird dieser Record als Paramter übergeben, und alle Funktionen werden nun mit
Delphi-Quellcode:
procedure ProtectedCode(var Reloc: TMyReloc);
var
Lib: THandle;
begin
Lib := Reloc.LoadLibrary('my.dll');
Reloc.FreeLibrary(Lib);
end;
den indirekten Aufruf über Reloc aufgerufen. Die gilt auch für statische Object Methoden, aber NICHT für virtuelle oder dynamisch Methoden, oder Interfaces. Die letzteren machen nämlich nichts anderes als unser Reloc Record.
Gruß Hagen