←
Sist oppdatert i 2020, I disse dager arkivert da disse tingene ikke forandrer seg særlig og har etter noen år blitt finspikket ferdig ganske bra. Jeg benytter kjernekoden iblant når jeg skal modde spill, enten via C# eller direkte i C/C++. Det gjør det veldig kjapt å sette opp kodehuler og hopp etter analyse i IDA/x64dbg/CE etc. hvor man da bare kan kopiere bytes direkte fra disassembleren rett inn i relative funksjonskall. Spesielt for relativ enkel hacking hvor målet kun er å modifisere enkel oppførsel eller verdier, noe som utgjør omkring 90% av spillhacking. Legger ikke ut denne offentlig, for å unngå at hashing og signaturer etablerer og sprer seg mer enn nødvendig.
WriteMem(bool AddBaseAddr, uintptr_t WriteAddr, unsigned char* WriteBuf, SIZE_T BufSize)
ReadMem(bool AddBaseAddr, uintptr_t ReadAddr, unsigned char* ReadBuf, SIZE_T BufSize)
PrepProcess(const wchar_t* ExeProcessFileName)
AobScan(const unsigned char* Pattern, const char* Mask, bool SKIP_MEM_MAPPED = true, SCAN_ONLY_EXECUTE_READ = true)
GetModBaseAddr(const wchar_t* NameOfModule, bool EndAddrInsteadOfBaseAddr)
Where the last one, SmartHook, is the heart and motivation of the project. While the other functions are also exported and can be used for manual hooking. Process handle and debug rights is automatically sorted by PrepProcess().
Multithreaded and optimized memory scanning added late April 2020. Resulting in very fast AOB search results (w/mask), e.g. when initially turning hacks on. Even in modern games (32 & 64-bit) with very large data allocations (4GB+ RAM usage). Added 2 options in April 2022 to allow scanner to skip MEM_MAPPED areas and target only PAGE_EXECUTE_READ for even faster (instantaneous) results where applicable.
Todo: Add option for game DLL targeting, for games where it's even faster to target specific module memory. I do this in my C++ trainers where applicable, and should add an option for it in the library as well.
I called it "Smart" hooking because it does a few things automagically that saves me time and effort from having to redo jump and hook management manually every time I want to hack a game. It remembers addresses for jumps and caves as well as original bytes that was replaced in an internal register so it can turn hooks on/off easily.
It will automatically scan the entire game (and its modules) for AOB patterns and register these locations for instant use thereafter. It always reuses individual code caves. It automatically calculates near E9 jumps from/back between hooks and caves, and makes sure the jump is never more than 32-bit long, even in 64-bit processes (Code caves generated from CE may have multiple short 5-byte jumps, this means we would be risking the skew of byte count if replacing return jumps with 64-bit/near 12-14 byte jumps, unnecessarily complicating things. So it sticks strictly to 32- bit near jumps, with guaranteed integrity).
Noen av programmene jeg lagde og hvor jeg brukte dette i tidsrommet 2018 - 2022 som eksempel:
Mediagalleri - Spillmods 2018 til 2022 ↗
Publisert: 12.jul.2023 10:57 | Oppdatert: 8.aug.2023 13:08.
I did a thing!
ProcMemInterface.dll - Spillmodifiseringsbibliotek
Sist oppdatert i 2020, I disse dager arkivert da disse tingene ikke forandrer seg særlig og har etter noen år blitt finspikket ferdig ganske bra. Jeg benytter kjernekoden iblant når jeg skal modde spill, enten via C# eller direkte i C/C++. Det gjør det veldig kjapt å sette opp kodehuler og hopp etter analyse i IDA/x64dbg/CE etc. hvor man da bare kan kopiere bytes direkte fra disassembleren rett inn i relative funksjonskall. Spesielt for relativ enkel hacking hvor målet kun er å modifisere enkel oppførsel eller verdier, noe som utgjør omkring 90% av spillhacking. Legger ikke ut denne offentlig, for å unngå at hashing og signaturer etablerer og sprer seg mer enn nødvendig.
Arkivert informasjon på engelsk fra gammel nettside følger:
ProcMemInterface is a c/c++ library I created for making C# game hack clients.Exportable functions to C#
CreateCave(uintptr_t TargetPtr, SIZE_T AllocSize)WriteMem(bool AddBaseAddr, uintptr_t WriteAddr, unsigned char* WriteBuf, SIZE_T BufSize)
ReadMem(bool AddBaseAddr, uintptr_t ReadAddr, unsigned char* ReadBuf, SIZE_T BufSize)
PrepProcess(const wchar_t* ExeProcessFileName)
AobScan(const unsigned char* Pattern, const char* Mask, bool SKIP_MEM_MAPPED = true, SCAN_ONLY_EXECUTE_READ = true)
GetModBaseAddr(const wchar_t* NameOfModule, bool EndAddrInsteadOfBaseAddr)
SmartHook( const unsigned char* ByteSearchPattern, const char* ByteSearchMask, unsigned char CaveBytes[], int CaveBytesLength, int ByteSearchJumpOffset, (Startindex=0, offset in AOB to insert jump) int NOPCount )
Where the last one, SmartHook, is the heart and motivation of the project. While the other functions are also exported and can be used for manual hooking. Process handle and debug rights is automatically sorted by PrepProcess().
Multithreaded and optimized memory scanning added late April 2020. Resulting in very fast AOB search results (w/mask), e.g. when initially turning hacks on. Even in modern games (32 & 64-bit) with very large data allocations (4GB+ RAM usage). Added 2 options in April 2022 to allow scanner to skip MEM_MAPPED areas and target only PAGE_EXECUTE_READ for even faster (instantaneous) results where applicable.
Todo: Add option for game DLL targeting, for games where it's even faster to target specific module memory. I do this in my C++ trainers where applicable, and should add an option for it in the library as well.
General Information
Made for C# GUI projects.I called it "Smart" hooking because it does a few things automagically that saves me time and effort from having to redo jump and hook management manually every time I want to hack a game. It remembers addresses for jumps and caves as well as original bytes that was replaced in an internal register so it can turn hooks on/off easily.
It will automatically scan the entire game (and its modules) for AOB patterns and register these locations for instant use thereafter. It always reuses individual code caves. It automatically calculates near E9 jumps from/back between hooks and caves, and makes sure the jump is never more than 32-bit long, even in 64-bit processes (Code caves generated from CE may have multiple short 5-byte jumps, this means we would be risking the skew of byte count if replacing return jumps with 64-bit/near 12-14 byte jumps, unnecessarily complicating things. So it sticks strictly to 32- bit near jumps, with guaranteed integrity).
P/Invokes
[DllImport("ProcMemInterface.dll")]
public static extern UIntPtr CreateCave(
UIntPtr TargetPtr,
ulong AllocSize
);
[DllImport("ProcMemInterface.dll")]
public static extern UIntPtr AobScan(
byte[] Pattern,
string Mask
);
[DllImport("ProcMemInterface.dll")]
[return: MarshalAs(UnmanagedType.I1)]
public static extern bool WriteMem(
bool AddBaseAddr,
UIntPtr TargetPtr,
byte[] WriteBuf,
UIntPtr BufSize
);
[DllImport("ProcMemInterface.dll")]
[return: MarshalAs(UnmanagedType.I1)]
public static extern bool ReadMem(
bool AddBaseAddr,
UIntPtr TargetPtr,
byte[] ReadBuf,
UIntPtr BufSize
);
[DllImport("ProcMemInterface.dll")]
[return: MarshalAs(UnmanagedType.I1)]
public static extern bool PrepProcess(
[MarshalAs(UnmanagedType.LPWStr)]
String ExeProcessFileName
);
[DllImport("ProcMemInterface.dll")]
public static extern UIntPtr GetModBaseAddr(
[MarshalAs(UnmanagedType.LPWStr)]
String NameOfModule,
bool EndAddrInsteadOfBaseAddr
);
[DllImport("ProcMemInterface.dll")]
[return: MarshalAs(UnmanagedType.I1)]
public static extern bool SmartHook(
byte[] ByteSearchPattern,
string ByteSearchMask,
byte[] CaveBytes,
int CaveByteLength,
int ByteSearchJumpOffset,
int NOPCount
);Noen av programmene jeg lagde og hvor jeg brukte dette i tidsrommet 2018 - 2022 som eksempel:
Mediagalleri - Spillmods 2018 til 2022 ↗
Publisert: 12.jul.2023 10:57 | Oppdatert: 8.aug.2023 13:08.
I did a thing!
