Dev Project

[-MIPs-]

Since I need a dump badly of the game I'm working on I'm trying to write a simple 'dump any game' proggy. So far I've just been messing around and compiling test code just to get my feet wet in the dev environment. Driver I've pretty much taken apart your code and learned a ton from it. The main part was how you loaded code into kernel memory.

My question is would it be possible to change the write cheat function in cora to a function that copies user mem to a buffer then to say a mem card?(just as an initial test) I'm asking first because once I thought about it, it seems impratical. Would I be able to allocate that much space(8mb) for a buffer before I copy it to a file on the mem card while a game is running? Would I have to do it in smaller chunks or is there a way to copy it directly to the card? I'm not to familiar with kernel mem and I'm having trouble finding but very little info on it.

*EDIT* ^_^ man those guys on dev site no there stuff but damn are they serious about not messing with official games and sdk.

[cYs Driver]

well my friend one guess what im working on right this moment

lol yeah ive had this idea for a while and yesterday i decided to start coding it after i learned some stuff about handling ps2 breakpoints so yeah hopefully il have the ultimate cheating tool soon lol

il go through my code with you when im done

[-MIPs-]

well my friend one guess what im working on right this moment

lol yeah ive had this idea for a while and yesterday i decided to start coding it after i learned some stuff about handling ps2 breakpoints so yeah hopefully il have the ultimate cheating tool soon lol

il go through my code with you when im done

Sounds like a plan! Looks like your going all out on this one. If you get the dumper portion of it working soon could I possibly borrow it Lol that was all I was going for was a simple dumper so I could dump this game.

IDOT is suppose to be releasing his 'easy dumper' as well but I didnt want to wait on that.

P.S. Have you played Socom:CA....It's awesome compared to 3. They did a nice job on most of the maps and it brings back alot of good memories from socom 1 & 2 ^^ O and good luck with your ultimate cheat tool!

[cYs Driver]

no i havent played it.

Well ran into a problem!
my code sits fine in resident memory(every last bit of it)

Then when i press my control buttons to activate the dump it calls a jal to a function called "dump_memory" this just calls fioOpen fioWrite and fioClose to write the memory. but making the jal to "dump_memory" it fails... :-/ even if "dump_memory" is empty it still fails its something to do with its location and it is extremely hard to move all the code :s

[misfire]

FYI, the fio* functions have to be placed in resident memory, too. But this can't be done by simply using the "section" attribute in C.

[cYs Driver]

i know i have set my entry point to 0x00090000 (this was one of the only address that didn't freeze me when i loaded it in ps2link because of the resident ps2link code) and i had to set the system call handler to 0x00080000 because it kept freezing when it loaded the game which was weird. If you could give me some help or look at my code or something it is strange :s

[-MIPs-]

FYI, the fio* functions have to be placed in resident memory, too. But this can't be done by simply using the "section" attribute in C.

How did you guys get the fio* functions in resident memory? That sounds interesting.

*EDIT* Driver, just a guess but are you writing to memcard? If so, don't you have to sync after open and write(if you're not already).

[misfire]

How did you guys get the fio* functions in resident memory? That sounds interesting.

*EDIT* Driver, just a guess but are you writing to memcard? If so, don't you have to sync after open and write(if you're not already).

The additional sync operation is only required for the mc* functions. The fio* functions also work for the memory card and don't need an explicit synchronization.

[Lazy Bastard]

An interesting module is the one I've attached...though I believe it's been accomplished other ways since its inception...that, and from what I recall, it specifically affects the PS2's detection of the IOP reset.

[misfire]

fakeboot and other nice stuff can be found here:
http://www.cdvdmania.com.ru/main.html

Actually, it's no problem to detect IOP resets, even on the EE side.

[Lazy Bastard]

Thanks; I'd been wondering where I'd found that. They've also got a decent amount of other interesting things.

[cYs Driver]

yeah ive seen the fakeboot stuff before but its only useful when i need modules which i dont really need for dumping :s wish someone could give me a hand with this who knows what there doing

[-MIPs-]

The additional sync operation is only required for the mc* functions. The fio* functions also work for the memory card and don't need an explicit synchronization.

O ok thnx. I didn't know the standard fio functions worked with mem card. *sigh* I'm trying here. Long way to go but I'm working.

You don't have to waste your time giving me step by step instructions on how to load fio* functions into kernel mem. Just point me to what I need to read up on and I'll do the rest.

*EDIT* Static linkage maybe? So that the functions are added into our code instead of dynamically linked? Just guessing...

[-MIPs-]

Ok I think I got it. PS2Link has the fio* functions loaded into the IOP thru an IRX. And I guess it's using RPC packets to communicate. Now I see where fakeboot could come into play since games like to reset the IOP for some reason. Considering your last post though, I'm assuming theres another way this could be done.

[cYs Driver]

the fio functions do not need loaded by an irx and they are also not dependant on any specific modules. I just loaded them by setting my entrypoint in resident memory, setting a system call handler to check for pad input then call the fio functions, but its calling the fio functions it fails :-/ needs some work