Hi everyone,
I am finally free from school again and able to learn more about my PSP :)
After playing around with the internal memory for a few days, I found out the following main memory layout for a typical application at its run time (I assume it is also true for many other apps):
************************************************
(higher address)
------stack (local data for procedures)
|
| (going down)
V
^
| (going up)
|
-------- dynamic data segment (allocate at run time)
|
static data segment (allocated at compile time)
|
---------
|
text segment (program executable)
|
--------- 0x4000
??? (reserved segment maybe)
--------- 0x0
(lower address)
************************************************
A blur line for me at the moment is the line which separates the static data segment and the starting address of the dynamic data segment. I am assuming there is a pointer somewhere pointing to this boundary (or a variable specifies the size of the static data segment), but I haven't fount it yet. Maybe someone can direct me to a source discussing about the boot header format (for pre-3.xx fw, which is what I am working with).
Anyway, I am hoping to learn more about this this summer. So, I am thinking whether or not I am able to shift the static data segment up a little bit. My goal is to insert a small amount of data at the bottom of the static data segment, and therefore "lifting" up the whole segment by a small offset, while the application still runs as if the segment has not been changed. Now, I know there are going to be pointers in the text segment pointing at the the data in the static data segment, the question is whether or not I can go in and change all these pointers and make them pointing at the right places. Is this possible though, to literally trace all of the static data pointers? Besides what I've mentioned above, is there any other places I need to look at in order to make sure the app run healthy?
I know there is a heavy assembly involved, but I want to do it as a summer project. Thanks for helping me :)
Possible to alter static data segment in memory?
What exactly do you want to do? All the addresses (in the rodata, data and bss segments) within the executable are resolved at link time. To move any of them at run time would require you to fix up the offsets within the whole program and fix the relocations. You could, I suppose, if you know the start address of the part you want to move, you could copy the part to the new location then use the relocation addresses to fix everything up, but there might be a easier way to accomplish whatever it is you are trying to do.
PS. The _fdata symbol points to the start of the read write data segment and _fbss points to the start of the uninitialized data segment.
PS. The _fdata symbol points to the start of the read write data segment and _fbss points to the start of the uninitialized data segment.
I am thinking to add an fix offset to the all the addresses (maybe not the lower part of the word, but the upper part) to accomplish that. Does it matter when the addressed get changed at run time and all the relocations stuff?crazyc wrote:What exactly do you want to do? All the addresses (in the rodata, data and bss segments) within the executable are resolved at link time. To move any of them at run time would require you to fix up the offsets within the whole program and fix the relocations. You could, I suppose, if you know the start address of the part you want to move, you could copy the part to the new location then use the relocation addresses to fix everything up, but there might be a easier way to accomplish whatever it is you are trying to do.
PS. The _fdata symbol points to the start of the read write data segment and _fbss points to the start of the uninitialized data segment.
I am not pretending I know everything pretty well here :) Yeah, I suppose I can write a application my own and change the linker script to do that for me, but I don't really get to learn too much this way. Well, maybe I don't have to do it at runtime.jimparis wrote:Just change it at link time, do you really need to do it at runtime?
You should be able to set things up however you'd like by modifying the linker script accordingly.
I can get started by writing a demo application which supposes to read a file to a fix size buffer. But maybe I have a large file that it actually overflows the buffer, overwrites other static data, and crashes the whole program. So I can go into the executable and fix every address and then run it and see if I can make the whole program work again. I just want to have fun messing up with the internal memory and see how far I can get. Anyways, I am still googling for sources about these relocation stuff, hope someone can help me out when I run into trouble =P
Aren't people ask questions here when they are not sure? plus I did not ask for a lesson either. At least, I know what I am doing is possible, although you don't necessarily agree with what I am doing. What I mean by asking for help is someone (hopefully) comes out and clarify points I am not quite sure.J.F. wrote:Given what you are trying to do, asking for help is self-defeating. If you don't know how, go learn. We don't give lessons here in any case. This is a developer board, not a correspondence class for ITT.
Generally speaking, if they aren't sure, they're asking at the wrong place. :)serige wrote: Aren't people ask questions here when they are not sure? plus I did not ask for a lesson either. At least, I know what I am doing is possible, although you don't necessarily agree with what I am doing. What I mean by asking for help is someone (hopefully) comes out and clarify points I am not quite sure.
How do I do collision detection? General programming and won't be helped.
How do I render a polygon with the GU? PSP related and we'd point them to a thread (or tell them to search the threads).
What you want to do is make your own ELF loader, and that's general programming, not PSP specific. If you wanted to know where the ELF file is inside the PBP file, we'd tell you to read the old threads/use search as reading files from the PBP has already been talked about. At least telling you that you want to get the info from the SFO in the PBP gives you something to search on.
The fact that you don't know the PSP uses an ELF file embedded in the PBP shows you didn't do your homework before asking. Once you know that, you can go almost anywhere on the net for info on ELF file format and examples of reading such files. It's pretty complicated, so most of us here are assuming you didn't bother with either of those steps because you wished to avoid the work yourself. That won't get you much help or sympathy here. The fact that you don't say anything about what you're trying to do other than some vague hand-waving leads most of us to assume it's related to cracking games, which again won't garner any help or sympathy here.
What I want to do is to make my own ELF loader? Not quite... As for the ELF format, that is something I can look up from some open source code out there (but I am less concerned about it for now), so I don't know what makes you think I don't know the ELF file inside the PBP story. If you really want to know what I am trying to do, well, all I can tell you is that I am trying to write a little in-game debugger plugin so that people who find it useful can use it (whether or not I can do it is another issue). So I am hoping I can be helped by some useful info when I encounter more technical problems, which is of course going to be PSP related.J.F. wrote:Generally speaking, if they aren't sure, they're asking at the wrong place. :)serige wrote: Aren't people ask questions here when they are not sure? plus I did not ask for a lesson either. At least, I know what I am doing is possible, although you don't necessarily agree with what I am doing. What I mean by asking for help is someone (hopefully) comes out and clarify points I am not quite sure.
How do I do collision detection? General programming and won't be helped.
How do I render a polygon with the GU? PSP related and we'd point them to a thread (or tell them to search the threads).
What you want to do is make your own ELF loader, and that's general programming, not PSP specific. If you wanted to know where the ELF file is inside the PBP file, we'd tell you to read the old threads/use search as reading files from the PBP has already been talked about. At least telling you that you want to get the info from the SFO in the PBP gives you something to search on.
The fact that you don't know the PSP uses an ELF file embedded in the PBP shows you didn't do your homework before asking. Once you know that, you can go almost anywhere on the net for info on ELF file format and examples of reading such files. It's pretty complicated, so most of us here are assuming you didn't bother with either of those steps because you wished to avoid the work yourself. That won't get you much help or sympathy here. The fact that you don't say anything about what you're trying to do other than some vague hand-waving leads most of us to assume it's related to cracking games, which again won't garner any help or sympathy here.
I have been studying the internal of the PSP whenever I am free, and I admit that I am that kind of person who learns through hacking (btw, did people not learn the PSP's internal though hacking? I just don't see how I am different from them). If your are replying me based on your over-assumption that I am breaking the rule here, I am not trying to say anything to change what it is in your mind, although I was avoiding to make people think that way when I wrote this topic.
I think you are thinking about this the wrong way. Look at the source for psplink.serige wrote:If you really want to know what I am trying to do, well, all I can tell you is that I am trying to write a little in-game debugger plugin so that people who find it useful can use it (whether or not I can do it is another issue). So I am hoping I can be helped by some useful info when I encounter more technical problems, which is of course going to be PSP related.
Thanks for your comments, maybe I am heading the wrong direction. I was just thinking about this in different way - it might sound a bit crazy (please don't laugh at me). What was in my mind was that I found printf() a great debugging tool in many case without the use of gdb, all I did was to insert a printf() in front of a statement and print out the variables value. So maybe I can do something as simple as that in assembly level. One limitation here is that you can not just insert a function in any places like you do in C or Java, but you might be able to do it in some earlier instructions, and then emulate the instructions up to the one you want to check out the values (maybe some of the data in the static data segment). Now I have to consider some of its implications too - and I just need to do more researches on exactly how does the PSP internal work in order to think further.crazyc wrote:I think you are thinking about this the wrong way. Look at the source for psplink.
So what you want is to be able to step through code at the instruction level then? Well... for a start GDB does that, psplink should do that (not checked it still works :P). Alternatively use printf perhaps, if you run your code in psplink then doing printf (or fprintf(stderr, ...)) will spit out to your local terminal.
Of course I am not necessarily saying you have to use psplink but you are not making much sense really, and it sounds like psplink already does what you want and is freely available with source for people to look at (and no doubt steal as per)
If that is not what you want to do, I have no idea what it is :P
Of course I am not necessarily saying you have to use psplink but you are not making much sense really, and it sounds like psplink already does what you want and is freely available with source for people to look at (and no doubt steal as per)
If that is not what you want to do, I have no idea what it is :P
Thanks for your pointer, I am reading some of the sources out there :)TyRaNiD wrote:So what you want is to be able to step through code at the instruction level then? Well... for a start GDB does that, psplink should do that (not checked it still works :P). Alternatively use printf perhaps, if you run your code in psplink then doing printf (or fprintf(stderr, ...)) will spit out to your local terminal.
Of course I am not necessarily saying you have to use psplink but you are not making much sense really, and it sounds like psplink already does what you want and is freely available with source for people to look at (and no doubt steal as per)
If that is not what you want to do, I have no idea what it is :P