(Artemis) Thoughts or Ideas

[Gtlcpimp]

Does anyone have any ideas on how to open a file during game-play without the PS2 locking up / freezing? From the ways I have tried, the PS2 refuses to access the file and locks up / freezes on every attempt.

What I have been doing is loading my ELF into address 0x01E00000, making a function that will be hooked to from within the game, locating the address of that function for making the hook, and then integrating my Cheat Device features into it so I can apply that hook in the form of a "Jokered Code". I have tested the function to make sure it is working by setting it to do other features such as modify the game memory to apply a different code or two, just to make sure it works, and it works flawlessly. The only problem is, every time I try to open a file using the "fopen" or "fioOpen" functions, my PS2 locks up and never accesses the file. I don't know if it matters or not, but I have even tried saving every single "Register" (what I consider just simple variables) in the game from the launching of my ELF, then loading those up in the function that accesses the file during game play to see if it would work. Even that idea failed to work.

Does anyone have any thoughts, ideas, or suggestions on how I could open a file during game-play?

[cYs Driver]

The reason fioOpen will lock up is because all those functions are contained in the ps2sdk which isn't getting loaded into where your cheat device is (i haven't looked at yours so that is a guess). So to get around that you must load the entire elf including all needed ps2sdk functions into memory where its not going to get overwritten, or find some low level functions that allow opening of files. The later method i have never looked into and the first method i always had trouble with

[Gtlcpimp]

There is no issue with data being over written. 0x01E00000 is not touched by any game I have seen, and is free to be used. I have my ELF loading to that address, and every bit of data contained by the ELF is not removed or overwritten at all. The PS2 will simply lock up no matter what: fopen(); fioOpen(); ExecPS2(); LoadExecPS2(); etc.

[Pyriel]

Well, it'd be easier to venture a guess if there were some source code to look at. That way we could at least tell if there's something simple missing from your code. As it is, we can only speculate blindly.

The file I/O features will obviously require that the right modules are loaded to the IOP, among other things. As to the syscalls failing, I could only guess. I'm not terribly familiar with the rules for their use, and especially how calling them in an unintended fashion would affect them. It's also possible that the game unregisters them. Although that seems unlikely.

For what it's worth, the approach I've been toying with in my head is to let the IOP handle most of the tasks at a very low-level. Writing a small module that either carries or finds what it needs, and then pulls blocks of memory from the EE according to prearranged conditions, writing them to a file. If I read the documentation correctly, at least one of the channels between them is bi-directional, and there is functionality for the IOP to request data transfer from the EE. In the end, the only code that might need to run on the EE to facilitate this (in its simplest form) is a small routine that keeps the IOP module running.

Of course, I'm working with a highly theoretical knowledge at this point, as I never mucked with the IOP much, and I haven't done any PS2 development in several years. At any rate, you guys can make of that what you will, and feel free to use the idea. It could be completely wrong, and I may not have time soon to test it. I meant to try it this weekend, and wound up tossing my nephew around instead.

[Lazy Bastard]

Pyriel: Heh. I also spent most of the weekend with the family, but I did play around with fonts and padlib a bit, in the interest of building the GUI. It's great that you're helping us muck around the PS2 for the right answers; thanks for joining in.

gtlcpimp: Yes, please do share some of your source. The goal here is to allow the scene to benefit from the best PS2 hacking system possible, not to trade bits of sparse knowledge, so we can each make our own marginally useful application.

[Derek8588]

Same problem...

I have been busy with life lately, but in regards to this topic, I have had a lot of trouble opening files as well from in game. I load all my code at 0x80025000 and jump to it from within a game (in kernel mode of course). I have tried fioOpen, mcopen, and neither works. I have yet to try and create an IOP module to test simple mc0 read and writes. When I get the time I will. In the meantime, I have been using my EE SIO port to debug and dump my games.

[Gtlcpimp]

I have done a quick slap together (since I deleted my previous source) so then you all can have something to look at. I have included my functions that utilize drawing strings on the screen. The syntax for them (if you would like to use them with your own projects, your welcome ):

DrawString("Text or String Here", X, Y, R, G, B, PACKET, Width, BgR, BgG, BgB);

X - X Coordinate
Y - Y Coordinate
R - Red Color Value
G - Green Color Value
B - Blue Color Value
PACKET - Graph Packet Used
Width - How wide it will go before it wraps below
BgR - Back Ground Red Color Value
BgG - Back Ground Green Color Value
BgB - Back Ground Blue color Value

The source code: http://www.cheaterslounge.net/downlo...GameFileEx.rar

It utilizes my simple cheat engine in order to apply memory modifications during gameplay. I use SOCOM: Combined Assault to do quick testing with In-Gameplay projects, so I included the "codes" to assist you if you have that game.

[misfire]

[...] For what it's worth, the approach I've been toying with in my head is to let the IOP handle most of the tasks at a very low-level. Writing a small module that either carries or finds what it needs, and then pulls blocks of memory from the EE according to prearranged conditions, writing them to a file. [...]

This is similar to what I've described here:
http://gshi.org/vb/showthread.php?p=29681#post29681

[Pyriel]

Well, nobody ever said all ideas had to be completely original. Now I know my thinking wasn't totally out of bounds, in any case.

[misfire]

In fact, letting the IOP handle most of the work is a very good idea! We should be able to call the actual game's SifLoadModule() function to execute our IOP module(s) at will. Then we have to find a appropriate way to transport memory chunks from EE to IOP. I guess the first thing I'm gonna try is shared memory, though I have to take care of race conditions.

Btw, Mega Man's Kernelloader uses IOP RAM above 0x001FF000 as shared memory:
http://kernelloader.cvs.sourceforge....der/sharedmem/

[Pyriel]

I'll have to look at that later. Apparently, you can access the IOP's RAM from the EE in kernel mode, but I hadn't seen anything that indicated the reverse was possible on the IOP. If you can get at EE memory without even the need for the usual transfer interface, that will make things much simpler.

[misfire]

Yes, the EE can directly access the IOP's memory:
http://psp.jim.sh/svn/filedetails.ph...clude%2Fsmem.h

But it doesn't work the other way around.

Here is how shared memory could be used to dump EE RAM:
- IOP listens to network for incoming command packets from PC
- IOP receives dump command
- IOP forwards (i.e. copies) dump command to shared memory (some dedicated area in IOP RAM)
- EE frequently polls shared memory for new commands (every cheat engine loop or so)
- EE reads dump command
- EE copies requested memory chunk to shared memory
- IOP detects command completion and sends answer (EE memory) to PC

This is obviously very simplified but you get the idea.

[Pyriel]

Yeah, a bit more complicated, but not terribly so. A similar idea had occurred to me, but I filed it away for later because it necessitated extra handlers on the EE.

My thought was to have the IOP request bus transfers, so that user commands could be responded to without any intervention from the EE. Well, at least there would little EE involvement in requests that don't require any complex handling, such as "dump 1KB of RAM starting at 0x300000". The only thing is, I haven't had time to truly check whether such a transfer request will work. The documentation I have indicates that it will, but as we've seen, in practice things are usually a bit thornier than we hoped.

What I was toying with was more a proof-of-concept, to see if the IOP could do pretty much everything on its own. Also, LazyBastard and I were discussing the possibility that a very simple USB dumper could be turned out somewhat quickly in this manner, if it works. The shared memory approach is probably a more mature one, as it would pretty much cover shuffling data for all possible requests without involving anything more complex than a couple of syscalls and a handful of basic operations.

Edit: Now that I've thought on it a bit more, the bus-transfer idea may make an interesting experiment, but time would be better spent on shared memory.

[Gtlcpimp]

Has anyone actually been able to open a file during gameplay of any game? As in, while in a game such as SOCOM, hitting a certain "joker combination" on the controller to activate a routine to open a file on the memory card? Or am I going to have to screw around with a billion different theories until I get one to work?

[Pyriel]

After looking at your code, I'd have to say you're relying on the game to load IOP modules that the PS2SDK is compatible with. That will probably not happen, since virtually all games load an IOP image file. As far as I know, they ignore the console's preloaded I/O modules almost completely.

It depends on what your specific definition is for "opening a file". It can be done somewhat reliably by using the game's own routines (sceMcOpen, sceMcWrite). Provided, that is, that the memory card library the game uses will cooperate. With respect to your approach, I don't know if anybody has ever successfully done that in the past. From what LB told me in IRC the other day, that's the major head-scratcher. From the sound of it, people have even tried loading the appropriate I/O modules, and it still crashes.