forums.ps2dev.org

[CrazyT]

K ... here we go.
I want to find locations of possible exploits ... so i wonder if there is a simple function that i can use to test if a return adress was rewritten.
For example i tried a epb-file with a game-icon that has a size of 4095*1023 pixels with 24bpp on a psp 2.82.
I saw that the psp was hanging cos there seems to be no size check for the image-size.
(also tryed to put the image in photo folder ... but there is a check that tells that the file is corrupted)
So i wondered if this is just a out-of-memory error or a bufferoverflow.
Because i do not know the location on memory of that buffer and i do not want to set a bg-picture(wich is static in memory) with code that might not work and fail, i need a simple function that change some visible thing on my psp, so that i can see if it worked.
The problem is the function should not have any params.

Thx for useful answers,CrazyT

[harleyg]

:|

[CrazyT]

That answer wasn't very helpful rofl.

:/

Maybe sb just did not understood me ...
All i want is to know an adress of a function that helps to test exploits that change the return-adress.
The function should just be able to detect cause the psp would crash after it ... so only 1 function is usable.(for example a sound-beep, turning off the psp , go to standby mode, or whatever ...).
But the function should not need any param.
Already looked at:
http://pspdev.ofcode.com/api2.0/

Unfortunately i did not found any useful.(cos im too lazy to look through every command).
So i ask if some experienced coder, that know alot of commands, could help me.

[Fanjita]

Well, therein lies the difficulty ;)

You're generally much better off with static code analysis to work out whether you've managed that, as getting function code into known places in the PSP RAM, before you've got a working exploit, is very hard. And there are no obviously-convenient functions that you can call ... besides which, you call the API functions via syscall, not via memory jumps.

If you're working with 2.01 firmware or less, then you can stick some code in the framebuffer - something that fills the ram with a colour is traditional, since it requires no API calls for a visible result. But this technique is blocked on 2.5 or later.
_________________
Got a v2.0-v2.80 firmware PSP? Download the eLoader here to run homebrew on it!
The PSP Homebrew Database needs you!

[CrazyT]

Ah ... i see ... now i partly understand.
Maybe i just thought that it would be similar to windows-similar-example(cause it is alot easier there because you can use functions to test your exploit ... and you have a debugger that gives you alot of help in developing)

Are there other static places i can use to run exploits?
Or is there even a table on the net that explains some memory locations?
Sad that it is not that easy to do the things i want :/.
Debugging such things without any application seems to be really difficult.

Maybe somebody has a devhook with debugger and can test the reason why It crashes ... i uploaded the file to rapidshare:
http://rapidshare.com/files/8673177/EBOOT.PBP.html
Hopefully it is a usable bufferoverrun ... but im not that shure.
(because it can also be a out-of-memory error because of the big image-size)