ERL and relocatable code

[misfire]

I've written some code that extends the functionality of PS2SDK's ERL library. (FYI, an ERL is a relocatable ELF similar to an IOP IRX.) In particular, I've added the ability to relocate an ERL at a specific memory address (ERLs are relocated at a dynamic memory address by default.)

At the moment, I'm trying to get my patch into the official PS2SDK:
http://forums.ps2dev.org/viewtopic.php?t=11701
EDIT: My patch made it into the homebrew PS2SDK.

Here is a sample project that demonstrates how to use the new *_to_addr functions.


What this means to Artemis:

I've integrated the new ERL functions into Artemis' cheat engine manager. I'm proud to say that we are now able to relocate the cheat engine at any memory address in user space.

The address can be configured by the boot loader or a custom code type. There will be a default engine ERL statically linked into the main ELF, but you can also load other engines from ERL files at will. It is even possible to have multiple engines running concurrently, provided they're placed at different memory locations.

Of course, this is not limited to the cheat engine. We can use it for the debugger code and other things too.

[Gtlcpimp]

If you write the Cheat Engine as a stand-alone function within your ELF file, you don't need to do any special "ERL" business. Even if the Cheat Engine is a series of functions that call each other for whatever reason, a simple "copy + paste" process solves the problem. If you have it call other functions as part of the Engine then after it's all copied to a different memory address, just patch the JAL's that exist within. I have already written plenty of Cheat Devices, and have already found the perfect method of producing a Cheat Device. Write out your Cheat Engine as a stand alone function, then build another function or a piece of source code within another function that does nothing but copy the Cheat Engine to whatever memory address specified. If any other functions are being called from the Cheat Engine and get copied with the Cheat Engine, then you must patch the JAL to jump to the new area rather than the old area. Since the next functions are still the same distance from the function calling it, you can simply take the difference of the current memory address and the new memory address, divide by four to obtain the JAL data, and subtract that number from the JAL data. This patches the JAL perfectly when moving multiple functions for the Cheat Engine as long as you copy them all to be the same number of bytes apart from each other. The best method you will ever take in building the Cheat Engine, is making sure that it gets stored in Kernel, and is hooked from Kernel. Forget those syscall hooks that I have been reading from your posts that you like to use, that method of hooking is wimpy compared to a hook from Kernel (trust me ).

[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.

[Gtlcpimp]

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:

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.

[Parasyte]

I have a similar program for NDS that will relocate code that wasn't written to be relocatable. In theory, it works fine. In practice it kind of sucks. Not because it has flaws during run time, but because it's just a hack.

And when it comes to flaws during run time, it doesn't bother to touch any static pointers, because it's impossible to find them all (while ignoring false-positives). The root cause is related to the halting problem.

On the other hand, having genuinely relocatable code solves these issues and quite a lot more. The last work I did on GCNrd was writing a relocatable ELF library. I never finished it, but the idea was to make it possible to dynamically place the debugger executable where it would cause the least interference in system memory. This would have fixed the last remaining "trouble games" with the debugger.

In short, don't skip out on a powerful relocatable executable library! It will save you many headaches in the end.

[Gtlcpimp]

I have a similar program for NDS that will relocate code that wasn't written to be relocatable. In theory, it works fine. In practice it kind of sucks. Not because it has flaws during run time, but because it's just a hack.

And when it comes to flaws during run time, it doesn't bother to touch any static pointers, because it's impossible to find them all (while ignoring false-positives). The root cause is related to the halting problem.

On the other hand, having genuinely relocatable code solves these issues and quite a lot more. The last work I did on GCNrd was writing a relocatable ELF library. I never finished it, but the idea was to make it possible to dynamically place the debugger executable where it would cause the least interference in system memory. This would have fixed the last remaining "trouble games" with the debugger.

In short, don't skip out on a powerful relocatable executable library! It will save you many headaches in the end.

We are talking about a Cheat ENGINE, as in a single function or a series of functions. There are no pointers involved, which make the relocatable business too much work. You don't need 30 nails to hold down a 2x4, so you don't need this extra relocatable crap to place a CHEAT ENGINE in another portion of RAM. Therefore, simply copying a single function or copying a series + patching the Jumps is much more efficient and easier to manage. Plus I have never had any issue or error from it, so you cannot say it is error prone. The only way it will be error prone is if you do not know how to program it properly.

[misfire]

In short, don't skip out on a powerful relocatable executable library! It will save you many headaches in the end.

I second that.

@Gtlcpimp

No. I've never said that it's only about the cheat engine. I've created the ERL patch for anything that needs to be relocated. In particular, I'm thinking of the debugger which will enable you to debug games over network (like Para did before). Trying to relocate the network code with all its dependencies using anything but a powerful library like ERL is just foolish. (Kudos to pixel for his great work!)

[Gtlcpimp]

I've integrated the new ERL functions into Artemis' cheat engine manager. I'm proud to say that we are now able to relocate the cheat engine at any memory address in user space.

I was referring to this statement right here. You don't need ERL to "relocate" a cheat engine to another memory address, all you got to do is copy it over. It is much more simple and easier to copy than to build it as an ERL. As far as a debugger, I still do not see why you would want to do more work by building it as an ERL. The debuggers I have built do not debug over a internet connection due to the fact that I build my work to maintain its process while you are playing a game and module dependencies are a pain in the ass at that point. My debuggers are visual on-screen menus with actual text forced on-screen during game play of any game, and none of them are ERL. I simply keep the entire program backed-up in Kernel, and have a Kernel-hooked function set to "extract" the ELF contents from Kernel directly to the RAM in the exact manner necessary for it to be executable with no errors. So far I have yet to see a game use data between 0x01C00000 - 0x01EF0000, so I keep my programs used during game play set to load at those addresses. I have never had an issue with it. So if you truly believe that the ERL business is best for you, then what ever floats your boat. I'm just trying to give you an idea that I have used and believe is more efficient.

[bungholio]

So far I have yet to see a game use data between 0x01C00000 - 0x01EF0000, so I keep my programs used during game play set to load at those addresses.

I can think of only one game: Dark Cloud 2. Seems as if nearly all of the useful data worth messing with in the game is right there in the 01ec???? area, and all around it.
Just checked, Dark Cloud 1 also uses that area for many codes too.

[misfire]

@Gtlcpimp

Yeah, I truly believe that ERL modules exactly fit my needs in every aspect.

Another good thing about it is that you can easily load external engines (or whatever) from ERL files. I used to do this in a more complicated way, but those modules and their exports are simpler to handle.

[misfire]

My patches finally made it into the homebrew PS2SDK.

That keeps me motivated to submit more patches.

[Lazy Bastard]

Heh, I completely forgot to go add it myself. Well, that's good.

[cosmito]

My patches finally made it into the homebrew PS2SDK.

That keeps me motivated to submit more patches.

BTW, good work misfire!
Always nice to see quality contributions to the sdk.

[Lazy Bastard]

Yeah; it's definitely a useful feature for the ERL implementation, and not just for our project.

[misfire]

Thank you. I'm sure it wasn't my last contribution.

At the moment I'm working on decent CMake support for the PS2SDK. CMake is a powerful cross-platform build system that automatically generates native Makefiles for you. I'm considering using it for larger software projects like Artemis.

Here is a small preview. To build it, run the commands:

$ cd build/
$ cmake ..
$ make