Hi.. I'm interested in learning how to write code for the photo exploit on the 2.0 firmware (not an eboot ran through fanjita's loader).. but, I'm not an experienced coder - I'm only just getting the hang of C++ and the pspsdk, and I don't know assembly or have any detailed knowledge of the hardware or exploit, so I have some questions I'd like to ask.. any help would be much appreciated!
1) (edit : nevermind, irrelevant)
2) Is it possible to write a piece of code that's contained entirely in the photo folder (without using any files on the root of the mem stick) that would be able to read/write to the memory stick (ie create a dir, copy a file)?
3) (edit : nevermind...)
4) How hard would it be to translate a c++ function to code that would run through this exploit?
5) Is there anything which explains the exploit or how to write code for it in a little more detail than the readme file with the hello world code?
6) When loading a .bin file, does it have to be in the root of the mem stick or can it be in any folder?
EDIT: Ok, I found the 2.0 hello world program, which has a bit more info on the nature of the exploit.. I noticed at the end of the overflow.tif file there was a path (ms0:/h.bin), I tried adding some folders with a hex editor but it just crashed, I'm assuming it *could* load with some encouragement, but was hard-coded to read that specific path.. can anyone point me in the right direction? Could I modify the frame_buffer.png file to load the extra part of the modified overflow.tif?
2.00 photo exploit code?
Unless you've got a good reason for wanting to develop directly to the TIFF exploit, I'd really recommend just compiling a standard EBOOT and using the loader. It'll be a lot less painful, and your code will run on other firmwares, not just v2.0.
But, developing to the TIFF exploit can be educational, so here are some of the answers to your questions:
1. Everything that's run directly from a TIFF so far has used very small amounts of code in the TIFF itself, and used that code to load other code from file (i.e. H.BIN). By running stuff from file, and loading to an appropriate address (0x08900000 would probably be good) you can run several MBs of code.
2. Yep, after all, most of the TIFFs use the kernel APIs to load the file that they will run, so it's no problem to do simple code within the image. It's unknown how much code you can actually squeeze in there, I suspect there's quite a small limit. All code I've seen so far uses at max a few tens of bytes of code in the image itself.
3. It's limited by which libraries are already loaded by VSH. That turns out to include most of the non-kernel functions. Main exceptions are IR, WLAN, USB. You're also limited to which functions have been mapped to syscall numbers - see another thread called something like "syscalls" elsewhere in the forum.
4. If you want to code in C++, the EBOOT loader is by far the best bet. If you want to use vanilla C, then it depends whether you want to run your code directly from an image. If you do, then unless you know ASM you'll find it difficult, because you need to provide position-independent code. If you're happy to use a .BIN file, then it's easy to use C - just look at the source for one of the hello worlds. Remember that you need to provide a syscall-based implementation of any API functions that you intend to use.
5. I'm happy to answer any questions you have on it. I keep meaning to publicly release the source to my TIFF tetris app - PM me if you want a copy.
6. Ought to be possible to load from any file by hex editing that string. Remember though that the BIN file you load needs to have been compiled and linked to load at the address that the TIFF code is trying to load it to. The main reason for keeping the path short is to avoid having unnecessarily-long data in the TIFF file.
But, developing to the TIFF exploit can be educational, so here are some of the answers to your questions:
1. Everything that's run directly from a TIFF so far has used very small amounts of code in the TIFF itself, and used that code to load other code from file (i.e. H.BIN). By running stuff from file, and loading to an appropriate address (0x08900000 would probably be good) you can run several MBs of code.
2. Yep, after all, most of the TIFFs use the kernel APIs to load the file that they will run, so it's no problem to do simple code within the image. It's unknown how much code you can actually squeeze in there, I suspect there's quite a small limit. All code I've seen so far uses at max a few tens of bytes of code in the image itself.
3. It's limited by which libraries are already loaded by VSH. That turns out to include most of the non-kernel functions. Main exceptions are IR, WLAN, USB. You're also limited to which functions have been mapped to syscall numbers - see another thread called something like "syscalls" elsewhere in the forum.
4. If you want to code in C++, the EBOOT loader is by far the best bet. If you want to use vanilla C, then it depends whether you want to run your code directly from an image. If you do, then unless you know ASM you'll find it difficult, because you need to provide position-independent code. If you're happy to use a .BIN file, then it's easy to use C - just look at the source for one of the hello worlds. Remember that you need to provide a syscall-based implementation of any API functions that you intend to use.
5. I'm happy to answer any questions you have on it. I keep meaning to publicly release the source to my TIFF tetris app - PM me if you want a copy.
6. Ought to be possible to load from any file by hex editing that string. Remember though that the BIN file you load needs to have been compiled and linked to load at the address that the TIFF code is trying to load it to. The main reason for keeping the path short is to avoid having unnecessarily-long data in the TIFF file.
Got a v2.0-v2.80 firmware PSP? Download the eLoader here to run homebrew on it!
The PSP Homebrew Database needs you!
The PSP Homebrew Database needs you!