Dynamic Memory Allocation für Anti-Cheating-Zwecke
Verfasst: 16.06.2006 18:42
Dynamic Memory Allocation (DMA) heißt nichts weiter, als das der benötigte Speicher für Daten während der Laufzeit des Programms festgelegt und reserviert (allokiert) wird.
Für Anti-Cheating-Zwecke ist das deswegen gut geeignet, da bei jedem Programmstart die Speicheradressen der allokierten Speicherblöcke anders sind. Viele Trainer-Coder haben Probleme mit DMA, da sie den Pointer im Speicher finden müssen, bevor der Trainer auf die Daten zugreifen kann. Allerdings gibt es auch viele die das können, also DMA bietet keinen absoluten Schutz. Aber es ist besser als garnichts.
Wie man im folgenden Code sehen kann, ist DMA in PureBasic sehr simpel. Lässt sich also ohne weiteres in jedes PB-Spiel implementieren.
Es ist darauf zu achten, dass nicht für jede Variable ein eigener Speicherblock allokiert wird, denn die Untergrenze für Speicherregionen befindet sich bei Win32-Systemen bei 4 Kilobyte. Das heißt, wenn wir jede Variable einzeln allokieren, haben wir für jede Variable einen Speicherverbrauch von 4 KB.
Wenns Fragen gibt, ruhig fragen, obwohl ich denke der Code ist eindeutig und leicht verständlich.
Für Anti-Cheating-Zwecke ist das deswegen gut geeignet, da bei jedem Programmstart die Speicheradressen der allokierten Speicherblöcke anders sind. Viele Trainer-Coder haben Probleme mit DMA, da sie den Pointer im Speicher finden müssen, bevor der Trainer auf die Daten zugreifen kann. Allerdings gibt es auch viele die das können, also DMA bietet keinen absoluten Schutz. Aber es ist besser als garnichts.
Wie man im folgenden Code sehen kann, ist DMA in PureBasic sehr simpel. Lässt sich also ohne weiteres in jedes PB-Spiel implementieren.
Es ist darauf zu achten, dass nicht für jede Variable ein eigener Speicherblock allokiert wird, denn die Untergrenze für Speicherregionen befindet sich bei Win32-Systemen bei 4 Kilobyte. Das heißt, wenn wir jede Variable einzeln allokieren, haben wir für jede Variable einen Speicherverbrauch von 4 KB.
Wenns Fragen gibt, ruhig fragen, obwohl ich denke der Code ist eindeutig und leicht verständlich.
Code: Alles auswählen
;--------------------------------------------------------
;| Dynamic Memory Allocation for Anti-Cheating purposes |
;| |
;| Version 1.00 |
;| Developed by Thorium, http://www.SacredVault.de/ |
;| |
;| PureBasic 4.00 Code |
;--------------------------------------------------------
EnableExplicit
;die Pointer der kritischen Variablen
Global Hitpoints.l ;Lebensenergie, hier wollen wir ein Long haben
Global Lifes.l ; Lebensanzahl, hier wollen wir ein Byte haben, müssen aber dennoch ein Long definieren
Procedure AllocCriticalVars()
Define Temp.l
;allokieren einer zufälligen Größe an Speicher
;ohne dies werden unsere Variablen immer an der gleichen Speicheradresse liegen
Temp = AllocateMemory(Random($10000)+1)
;allokieren des Speichers für die Hitpoints und Lifes
;wir wollen ein Long und ein Byte haben, also müssen wir 5 Byte allokieren
;Long=4Byte Byte=1Byte
;Jede Variable einzeln zu allokieren, währe Speicherverschwendung,
;da die Mindestgrenze für eine Speicherregion bei 4 Kilobyte liegt.
Hitpoints = AllocateMemory(5)
;Hitpoints sind ein Long, also 4 Byte,
;also müssen wir nur + 4 zur Speicheradresse von Hitpoints
;addieren um den Pointer zu Lifes zu bekommen
Lifes = Hitpoints + 4
;freigeben des zufällig allokierten Speichers
;immer schön aufräumen und freigeben, was wir nichtmehr benötigen
FreeMemory(Temp)
EndProcedure
;allokieren des Speichers für kritische Variablen
AllocCriticalVars()
;wir sehen, das sich unsere Variablen bei jedem Programmaufruf an einer anderen Speicheradresse befinden
Debug("Pointer to Hitpoints: " + Str(Hitpoints))
Debug("Pointer to Lifes: " + Str(Lifes))
;so müssen wir nun auf die Variablen zugreifen:
;schreiben
PokeL(Hitpoints,100)
PokeB(Lifes,3)
;lesen
Debug("Hitpoints: " + Str(PeekL(Hitpoints)))
Debug("Lifes: " + Str(PeekB(Lifes)))
