(Artemis) Thoughts or Ideas

[Derek8588]

Should work if you apply sbv_patch_enable_lmb().

Well I have tested your irx under a standalone elf. I loaded
sio2man, mcman, and mcserv modules. I then used the above mentioned method (storing it in a buffer) and it loaded and worked flawlessly. Neat little thingy. When i finish dinner, I will try to run it during a game Hopefully it works.

EDIT::::::::::Result of test... She is a no go

Edit 2: Curious question. Im tryen to figure out why its not working when being called from game, yet it works when run in a standalone elf. I did notice the loading of the irx returned 36... which seems good. But this causes the ps2 to freeze. So my question is, would loading a module from kernel memory while in kernel mode cause this? (0x80025000) I know the memory is clear because everything else I put there works. Any ideas? What baout this question. Would loading a module in a vblank handler cause this? The vblank handler only calls it once. I dont think either of these things should matter, but who knows. Maby you guys know something I dont (prolly alot). Thanks

[misfire]

Whoa now, easy there partner. Even though I have heard of this "sbv patch" crap, I still have never used them. What exactly are they, and what headers / modules must I include to use it / them? Also, what do they do exactly?

From the sbv readme:

sbv was partly written to overcome certain limitations and restrictions imposed
by Sony onto the Playstation 2's BIOS. It consists of a library and runtime
patches for code running on the Emotion Engine (EE).

The included library isn't limited to runtime patching, and it has many other
uses for exerting unholy control over the PS2's I/O processor (IOP) and EE
kernel.

sbv_patch_disable_prefix_check() disables the MODLOAD check for ELF or IRX files on certain devices. Without this path, you can't load IOP modules from mc0 using SifLoadModule().

sbv_patch_enable_lmb() enables LoadModuleBuffer() via RPC.

[misfire]

Well I have tested your irx under a standalone elf. I loaded
sio2man, mcman, and mcserv modules. I then used the above mentioned method (storing it in a buffer) and it loaded and worked flawlessly. Neat little thingy. When i finish dinner, I will try to run it during a game Hopefully it works.

EDIT::::::::::Result of test... She is a no go

Edit 2: Curious question. Im tryen to figure out why its not working when being called from game, yet it works when run in a standalone elf. I did notice the loading of the irx returned 36... which seems good. But this causes the ps2 to freeze. So my question is, would loading a module from kernel memory while in kernel mode cause this? (0x80025000) I know the memory is clear because everything else I put there works. Any ideas? What baout this question. Would loading a module in a vblank handler cause this? The vblank handler only calls it once. I dont think either of these things should matter, but who knows. Maby you guys know something I dont (prolly alot). Thanks

Actually, I've never tried loading a module in kernel mode. I recommend writing a test application to find out if its possible or not. I'm not sure if moving code that is supposed to be in user space to kernel memory works without any modifications, especially when calling this code from an interrupt handler (vblank). Consider that there're dedicated syscalls intended to be called from interrupt handlers, e.g. iRotateThreadReadyQueue() instead of RotateThreadReadyQueue(). Again, I suggest loading modules using the game's user space code.

Also, I'm planning to advance lsmod to get more information about IOP modules and their dependencies, so we can eventually figure out any issues. There're quite a few things we have to learn here...

EDIT: Mega Man, the author of Kernelloader, is probably the best person to ask for kernel-related information.

[Derek8588]

Wow I figured out why it didnt work. I modified the working Elf that successfully loaded and executed the lsmod irx and put the same code in a vsync handler. Boom... PS2 freezes. So that must be why it didnt work as it should have during a game This is what my SIO terminal app prints out when my ps2 freezes:

# DMAC(5) Handler does not exist.
# <Thread> No active threads
# Restart.
# Initialize GS ...
# Initialize INTC ...
# Initialize TIMER ...
# Initialize DMAC ...
# Initialize VU1 ...
# Initialize VIF1 ...
# Initialize GIF ...
# Initialize VU0 ...
# Initialize VIF0 ...
# Initialize IPU ...
# Initialize FPU ...
# Initialize User Memory ...
# Initialize Scratch Pad ...
# Restart Done.
# DMAC(5) Handler does not exist.

The reason I used a vsync handler was the impliment thread like functionality without creating a thread. Reason being, when a game is running, multiple threads are running with different priorities. So I thought that creating a thread that idled in the background would be difficult because you have to set each thread with the same priority and use IRotateThreadReadyQue(); Out of curiousity, within a vsync handler ,could I safely set each thread with the same priority and rotate threads with the syscall iRotateThreadReadyQue to switch between the different threads including my own that would run your irx? My goal is to run the IRX without manually hooking the game. Which I can run some code with a vsync handler. That is how I created my universal SIO memory dumper.

EDIT 2: Was reading around on the ps2dev forums. I noticed that mrbrown said you could use iWakeupThread() within a vsync handler. So I could create a thread and store it in memory. At the press of a button, the vsync handler could call iWakeupThread on my thread that does whatever... and at the end of the thread I call SleepThread() which will pass control back to the game thread. Wow. This sounds promising if I can get it to work. Here goes nothing...

[misfire]

Derek8588, check your PM.

[Derek8588]

Progress

During my free time this weekend, I managed to get a thread running while a game was running. I can call iWakeupThread on it and put it to sleep on command. It freezes the game while its executing however (gains control). I did also manage to make the thread run simultaneously with the game by assigning my thread the same priority as the games MAIN thread (it has multiple) and using iRotateThreadReadyQueue(). Ok so for the final test of what I was trying to do was load lsmod.irx while the game was running. It doesnt work Within my thread I call:

sbv_patch_enable_lmb();
sbv_patch_disable_prefix_check();

sio_printf("Loadind lsmod.irx\n");

ret = SifExecModuleBuffer(lsmod, size_lsmod, 0, NULL, lsmod_ret); //loads the irx from an array

sio_printf("SifExecModuleBuffer Return = %d\n", ret);

I can use my threads to do almost anything from my tests, but when it runs the above code, the last thing I see is "Loading lsmod.irx." Therefore, it never gets to the return value printf function. Funny thing is, the PS2 doesnt freeze. The above method works fine when in a standalone elf. So now im trying to figure out what I can do to get this to load. Any ideas? Thanks

[misfire]

I guess the (evil) IOP is the reason for your problem. Particularly, take care of IOP resets and module dependencies. You have to call sbv_patch_enable_lmb() each time the IOP is reset. Also, as lsmod imports I/O functions from (a specific version of) IOMAN, you have to make sure that the right version of IOMAN is already loaded. Otherwise, if a game loads a newer version that isn't compatible with your import list, calls to open(), write() etc. will fail. Then you have to adapt lsmod accordingly (i.e. create a new import list).

You can use irxtool by Mega Man to get a list of the imported and exported functions of an IOP module.

Here is the output for lsmod.irx:

$irxtool lsmod.irx

stdio 1.02
0x00000ce4 4 printf()

ioman 1.01
0x00000d08 4 open()
0x00000d10 5 close()
0x00000d18 6 read()
0x00000d20 7 write()
0x00000d28 8 lseek()

sysclib 1.01
0x00000d4c 14 memset()
0x00000d54 12 memcpy()
0x00000d5c 27 strlen()
0x00000d64 30 strncpy()
0x00000d6c 29 strncmp()

loadcore 1.01
0x00000d90 6 RegisterLibraryEntries()
0x00000d98 11 QueryLibraryEntryTable()
0x00000da0 5 FlushDcache()
0x00000da8 4 FlushIcache()

thbase 1.01
0x00000dcc 4 CreateThread()
0x00000dd4 5 DeleteThread()
0x00000ddc 6 StartThread()
0x00000de4 24 SleepThread()
0x00000dec 20 GetThreadId()
0x00000df4 9 ExitDeleteThread()
0x00000dfc 33 DelayThread()

thsemap 1.02
0x00000e20 4 CreateSema()
0x00000e28 6 SignalSema()
0x00000e30 7 iSignalSema()
0x00000e38 8 WaitSema()
0x00000e40 5 DeleteSema()

sifcmd 1.01
0x00000e64 14 sceSifInitRpc()

intrman 1.02
0x00000e88 8 CpuDisableIntr()
0x00000e90 9 CpuEnableIntr()

Module dependencies are one of the bigger issues and I don't know everything about them yet. If we want to create a generic game hacking system we have to deal with them sooner or later...

[Derek8588]

I cant compile irxtool. I am on win32 and I have tried my mingw compilers... and its a no go. I will look through the makefile later and see if I can fix it.

[Gtlcpimp]

I guess the (evil) IOP is the reason for your problem. Particularly, take care of IOP resets and module dependencies. You have to call sbv_patch_enable_lmb() each time the IOP is reset. Also, as lsmod imports I/O functions from (a specific version of) IOMAN, you have to make sure that the right version of IOMAN is already loaded. Otherwise, if a game loads a newer version that isn't compatible with your import list, calls to open(), write() etc. will fail. Then you have to adapt lsmod accordingly (i.e. create a new import list).

You can use irxtool by Mega Man to get a list of the imported and exported functions of an IOP module.

Here is the output for lsmod.irx:

$irxtool lsmod.irx

stdio 1.02
0x00000ce4 4 printf()

ioman 1.01
0x00000d08 4 open()
0x00000d10 5 close()
0x00000d18 6 read()
0x00000d20 7 write()
0x00000d28 8 lseek()

sysclib 1.01
0x00000d4c 14 memset()
0x00000d54 12 memcpy()
0x00000d5c 27 strlen()
0x00000d64 30 strncpy()
0x00000d6c 29 strncmp()

loadcore 1.01
0x00000d90 6 RegisterLibraryEntries()
0x00000d98 11 QueryLibraryEntryTable()
0x00000da0 5 FlushDcache()
0x00000da8 4 FlushIcache()

thbase 1.01
0x00000dcc 4 CreateThread()
0x00000dd4 5 DeleteThread()
0x00000ddc 6 StartThread()
0x00000de4 24 SleepThread()
0x00000dec 20 GetThreadId()
0x00000df4 9 ExitDeleteThread()
0x00000dfc 33 DelayThread()

thsemap 1.02
0x00000e20 4 CreateSema()
0x00000e28 6 SignalSema()
0x00000e30 7 iSignalSema()
0x00000e38 8 WaitSema()
0x00000e40 5 DeleteSema()

sifcmd 1.01
0x00000e64 14 sceSifInitRpc()

intrman 1.02
0x00000e88 8 CpuDisableIntr()
0x00000e90 9 CpuEnableIntr()

Module dependencies are one of the bigger issues and I don't know everything about them yet. If we want to create a generic game hacking system we have to deal with them sooner or later...

If it's the modules loaded from the game that make the difference between working and not working, then we don't need to build some special .IRX file to dump crap to the memory card. All you would have to do is set the load address of a .ELF file to a portion of RAM that isn't touched by games (I prefer using 0x01C00000 and up, because I still have yet to see a game touch 0x01C00000 to 0x01EF00000). Seeing as games use the IOP image to load all their modules up with, what can we do to load the modules needed so we can access files in game play of any game? Any time I try to load the modules needed for file manipulation, whether it's from rom0 or from a module_buffer, my ps2 Freezes.

[Derek8588]

If it's the modules loaded from the game that make the difference between working and not working, then we don't need to build some special .IRX file to dump crap to the memory card. All you would have to do is set the load address of a .ELF file to a portion of RAM that isn't touched by games (I prefer using 0x01C00000 and up, because I still have yet to see a game touch 0x01C00000 to 0x01EF00000). Seeing as games use the IOP image to load all their modules up with, what can we do to load the modules needed so we can access files in game play of any game? Any time I try to load the modules needed for file manipulation, whether it's from rom0 or from a module_buffer, my ps2 Freezes.

When the Game loads, it clears all user memory though. So I load my elfs at 0x000b0000 which isnt cleared by the game. So I know it stays there. I think my problem is what misfire describes. When I load a module, its dependencies functions and libs are different in the newer modules that are loaded by the game. Notice how iopmod uses lib versions that are 1.2 and below. Im sure the newer modules in todays games are way different. I dont see why newer modules cant be backward compatible with older stuff though I am trying to use iopmod just as a proof of concept. If it works, then I will venture from there. Oh by the way, irxtool is definitely intended for linux compilation. It's paths have the same file structure as linux. I see that generatedb.pl refers to a folder named perl. What should I use to compile this? I was thinking of setting up cygwin like I did for the ps3 toolchain and try to compile. Im stuck Thanks

[Gtlcpimp]

When the Game loads, it clears all user memory though. So I load my elfs at 0x000b0000 which isnt cleared by the game. So I know it stays there. I think my problem is what misfire describes. When I load a module, its dependencies functions and libs are different in the newer modules that are loaded by the game. Notice how iopmod uses lib versions that are 1.2 and below. Im sure the newer modules in todays games are way different. I dont see why newer modules cant be backward compatible with older stuff though I am trying to use iopmod just as a proof of concept. If it works, then I will venture from there. Oh by the way, irxtool is definitely intended for linux compilation. It's paths have the same file structure as linux. I see that generatedb.pl refers to a folder named perl. What should I use to compile this? I was thinking of setting up cygwin like I did for the ps3 toolchain and try to compile. Im stuck Thanks

I have tested this lsmod.irx under SOCOM: Combined Assault, and it refuses to work. I have tried using the game's SifLoadModule() function, the ExecModuleBuffer() function, my elf's SifLoadModule() function, and retried all of those using the patches that misfire said to use. None of it worked, all of it froze the ps2 instantly. I can apply the patches with no problem, but the instant my elf or the lsmod.irx tries to access a file in any way, the ps2 freezes.

[misfire]

When the Game loads, it clears all user memory though. So I load my elfs at 0x000b0000 which isnt cleared by the game. So I know it stays there. [...]

You can easily patch the kernel code that is responsible for clearing user memory. Take a look at ZoneLoader's disableClearUserMem() function.

Shouldn't be too difficult to port irxtool to Windows. From a quick view I noticed that irxtool.c includes elf.h which might not be part of your environment. Also, to build and run the irxtool executable, you don't need the Perl scripts at all.

[misfire]

I have tested this lsmod.irx under SOCOM: Combined Assault, and it refuses to work. I have tried using the game's SifLoadModule() function, the ExecModuleBuffer() function, my elf's SifLoadModule() function, and retried all of those using the patches that misfire said to use. None of it worked, all of it froze the ps2 instantly. I can apply the patches with no problem, but the instant my elf or the lsmod.irx tries to access a file in any way, the ps2 freezes.

As I've said before, the export and import lists must be compatible, otherwise the linking between the modules fails. AFAIK, at least the major version (1.x, 2.x etc.) has to be the same in both export and import lists to make sure that the function prototypes are compatible.

Example: lsmod.irx imports open() from IOMAN version 1.01. open() happens to be the 4th function in the export list. Now, if a game loads version 1.x of IOMAN, there shouldn't be a problem with lsmod.irx as far as the linkage is concerned. Otherwise, if the game loads a newer (major) version like 2.0 or it doesn't load IOMAN at all, the linking will fail.

That's the theory. In fact, it's a little bit more complicated. For example, MCMAN must be loaded to set up the file driver subsystem for mc0 and mc1, etc.

On IOP programming:
http://ps2dev.org/ps2/Tutorials/TUTO...essor.download

[Derek8588]

Well darn. I have looked through many of the IRX's that come on the disc of the game using ps2dis. All of their imported functions come from libs that are 1.4 and below. Although, some modules such as mcman and mcserv are 2.0 and up, but lsmod doesnt use those. So I will try an older game. The oldest I have right now is Socom I. I have been doing my tests with socom 2, Which came out in 2003. So We will see...

Edit: I have tested Socom I and it still fails to load. Odd thing is, when I try to load the module from a buffer, the ps2 doesnt freeze. I have since tried ret = SifLoadModule("mc0:\lsmod.irx", 0, NULL);
When I attempt to access mc0, my ps2 freezes. Curious question. Since the IOP is already running modules, do I need to call anything else before loading the modules other than applying the SBV patches? Such as SifInitRpc(0);?

[misfire]

Maybe the SBV patch doesn't work with the IOP program loader (Module_Manager + Module_File_loader) that comes with newer games. I'll do some further research when I'm finished with my other work.

Btw, here is a Win32 port of irxtool:
http://gshi.org/vb/showthread.php?t=3232