
Originally Posted by
misfire
I disagree. ERL does all what you described and a lot more.
Your method is ugly and error-prone, not to speak of code maintenance and reuseability. Though it might work with simple ASM code, it quickly becomes a pain in the ass when it comes to C code.
With ERL, you can write ASM and C code as usual and don't have to worry about relocation. The library handles all common relocation types (not only JAL) and is able to resolve module dependencies automatically.
Technically, it isn't a problem to store the cheat engine inside Kernel RAM, but I don't really see the overall benefit.
My method has never failed me, and has never caused any errors. So far it has proven to be the most effective method and is by far much easier.
It is easily performed by something like this:
Code:
void Engine(void)
{
// Coding
}
int EngineBottom(void) // To prevent any issues
{
return 0;
}
void MoveEngine(int NewAddr)
{
u32 StartAddr;
u32 StopAddr;
u32 TmpAddr;
u32 Data;
u32 Diff;
StartAddr = (void*)Engine;
StopAddr = (void*)EngineBottom;
TmpAddr = NewAddr;
Diff = StartAddr - NewAddr;
Diff = Diff / 4;
for (i = StartAddr; i < StopAddr; i += 4)
{
Data = _lw(i);
// Patch JAL's and J's
if ( ( _lb(i + 3) == 0x08 ) || ( _lb(i + 3) == 0x0C ) )
{
Data -= Diff;
}
_sw(Data, TmpAddr);
TmpAddr += 4;
}
}
It is a whole lot easier than having to produce any "ERL" crap.
The greatest benefit of having the engine stored within Kernel RAM and HOOKED within Kernel RAM is that the engine will always be active. If you load it up with a game that goes through multiple .ELF files, you don't have to worry about having to re-hook from the next .ELF file. For games that reset by loading the main .ELF again will clear your engine out unless it is stored and hooked within Kernel. Also, the engine hooked from Kernel is executed more often which makes it process the data much faster along side with the actual game executable. You never have to do any scan and hook specific syscalls, so it is much easier and much more effective.