(Artemis) My disfunctional memory dumper

[Lazy Bastard]

cYs Driver was gracious enough to share this source

[misfire]

Hm, those functions were actually written by me:

u32 getSyscallVTblAddr(void);
u32 KernelRead(void *addr, void *buf, u32 size);
void HookSyscall(int syscall_num, void *myhandler, u32 *j_defhandler);

At least, it should be noted somewhere!

[Lazy Bastard]

Heh, ah. He did give a huge thanks to you in the readme, but I suppose he didn't mention specifically what for.

[cYs Driver]

Hm, those functions were actually written by me:

u32 getSyscallVTblAddr(void);
u32 KernelRead(void *addr, void *buf, u32 size);
void HookSyscall(int syscall_num, void *myhandler, u32 *j_defhandler);

At least, it should be noted somewhere!

your name was mentioned in the readme

[misfire]

Don't worry, it's not a big deal, just wanted to remind you of my copyright before I sue you.

(Btw, I can't see no readme file in this thread. Screen.rar doesn't contain a copyright notice either.)

[Lazy Bastard]

Hmm...I think I remember a readme for this. Perhaps you sent me an archive of this before you posted it, and that's where I've seen the readme.

[cYs Driver]

Don't worry, it's not a big deal, just wanted to remind you of my copyright before I sue you.

(Btw, I can't see no readme file in this thread. Screen.rar doesn't contain a copyright notice either.)

I always distribute readme's with all my work, maybe that one was just a private upload

[Derek8588]

Driver were you ever able to read or write from mc0 in game? In other words did you ever get your memory dumper to work?

[misfire]

I was able to write to mc0 in game.

For debugging purposes, I developed a small IRX module that does nothing more than printing a list of all loaded modules and their attributes to a text file on mc0. IIRC, I used low level I/O functions (open, write, close) and an open source implementation of sprintf for it (the native one is broken!).

However, there's no RPC involved here, but it's a beginning.

[misfire]

cYs Driver, from a quick look at your source code I can tell you that it is not going to work.

I see that you're using the .resident section for stuff that needs to stay in memory. I've used this trick myself, but soon realized the problem that comes with it: It doesn't take care of the called SDK functions (memcpy, fio* functions, RPC crap, etc.). Those have to be put in resident memory too! (Unless you abuse the game's code.)

The best solution is to compile _two_ ELF files. The first one contains the payload - the code you want to keep alive. You must set the ELF's load address to 0x00080000, for example. The second ELF is the loader which copies the contents of the payload to its load address (0x00080000). I did this by creating a C header file which stores the contents in a byte array. The loader's address can be anywhere above 0x00100000.

[cYs Driver]

cYs Driver, from a quick look at your source code I can tell you that it is not going to work.

I see that you're using the .resident section for stuff that needs to stay in memory. I've used this trick myself, but soon realized the problem that comes with it: It doesn't take care of the called SDK functions (memcpy, fio* functions, RPC crap, etc.). Those have to be put in resident memory too! (Unless you abuse the game's code.)

The best solution is to compile _two_ ELF files. The first one contains the payload - the code you want to keep alive. You must set the ELF's load address to 0x00080000, for example. The second ELF is the loader which copies the contents of the payload to its load address (0x00080000). I did this by creating a C header file which stores the contents in a byte array. The loader's address can be anywhere above 0x00100000.

if you look in the file linkfile you'll see that the .text section is also loaded in resident memory, either that or i've uploaded the wrong linkfile but loading the .text section into resident memory will take care of loading in stuff like memcpy etc, i then sjcrunched the main code so that it loaded in user land then sjcrunch decompressed it into resident memory and executed it, even still this did not work

But concrats on your IOP module

[Lazy Bastard]

That's pretty awesome that you managed to read loaded modules and write them to a text file on mem card in-game...that's a huge step.

[misfire]

Thank you, but it wasn't that difficult.

From a PM I wrote to Derek8588:

Yes, the whole IOP module crap is one of the greatest issues; we have to take care of dependencies, IOP resets, and whatnot. I think it will be difficult to find a generic solution for it.

Actually, I was able to initialize TCP/IP while running a game (TimeSplitters PAL). What I did was to call the game's SifLoadModule() function to load the network modules from memory card (requires a SBV patch) after the game has loaded its own ones. That way I was able to continuously send a "ping" from PS2 to PC. I haven't done more work on it yet.

I've applied the same method to load the other module I mentioned.

[Lazy Bastard]

The ability to make the PS2 send packets to the PC during gameplay means we could at least attach that process to a button combination (or sequence, even), and potentially force memory dumps to PC (though we'd have no way of testing codes, and we'd have to use a PC-side compare application to narrow results). That is, if we can perform a dump of memory.

[cYs Driver]

any attempts at ingame graphics print out?