PSP ASM Hacking for Variable Width Font

Hey chepchep
I can't wait to see what game it is
Im hoping it's one of the big 10

 

Why not simply change the width to 8 pixel and leave it fixed-width? It should be enough most of the time.
If it's particularly wordy, try adding an extra line and make the message box wider.
If that still isn't enough, just divide the text between two text boxes, like SMT1 iOS and many PS1 releases did.

 

All of this will vary greatly depending on the game but basically there are two ways:

1) Forward -- from text to rendering
Find your text in memory, set a read breakpoint on it (of course you will use PPSSPP, it's your best friend), trace how this data is processed. It probably will be read in several places, try to find out which one is responsible for text rendering. Try changing registers (eg change 'a' to 'z' and see if it's changed on the screen, change things that look like display offsets and see if it moves).
2) Backwards -- from rendering to the text (ONLY do this if you're really desperate)
You should know how PSP graphics works. Find displaylist in memory, find where your text is rendered, breakpoint this on write; use PPSSPP's graphics debugger. Try to figure out how this data got there, somewhere along the way there will be a calculation of the X and Y offsets. This is usually way harder because there are much more layers the text gets passed through after the X and Y are calculated.

 

Half-assed job. reducing the width is like your first step when doing a vwf, you can just go all the way then if you've find this lol

 

It is for the GBA but it should give you ideas on how to set about it
http://www.romhacking.net/documents/337/
Generally though it is a width look up table if the font itself does not support it (or you did not want to hack it into the font). If a basic width change is not going to do it for you then you also have what I usually dub the pseudo variable width font where you take a leaf out of the old methods and encode wider characters over a couple of tiles.

"I am again plague with a game that does not support variable width font"
If you are going to play in Japanese game translation circles then get used to it. At least with more modern consoles it is not unheard of for them to use a fully realised font format -- on the DS I believe* the NFTR format is inherently VFW even if the devs do not use it.

*I am told the the SDAT format will jettison the relevant part of the libraries if you do not use a given sound format in a game, I do not think NFTR does this though.

"Almost every single line of text goes way outside the textboxes throughout the entire game."
Do you mean that the boxes are too small for your translation or that the lines themselves do not wrap? The wrapping thing is not a font issue, though altering the font is certain an aid in such scenarios, and more of a text handling issue.

 

Finding locations to put your new code is always a fun part of assembly hacking.

Debug strings, runs of 00, error messages for wifi/network (I have seen games include several uncommon ones), areas of memory set aside, memory that never gets to be used in normal games (harder to find in more modern games) and so on and so on are all good things to look for. The worst case scenario is you have to reverse engineer and optimise/shrink existing code to gain yourself some space. Halfway between that is you break a bonus mode or something in the game and steal its data.

You tend not to find your back up against the wall in ROM hacking (such things are more for embedded devices, small kernels and those hacking that sort of thing) but it is not like you can throw a simple malloc in there either. Mind you depending upon the game, the memory handling available and the system you are using you might actually be able to extend the binary in memory and rely on any hardcoded locations being for the binary rather than general runtime memory.

 

I think you should be able to just extend the .text section in eboot ELF, or well, any section because all memory is readable+writeable+executable on PSP. Maybe this https://bitbucket.org/blackdragonhu...b042b01754abfe/eboot_patch.py?at=master#cl-40 could be related and you could learn from that patch although I myself haven't looked into how they extend the eboot.

 

Regarding that expand of eboot - very interesting, can anyone advice some decent tutorial, how to integrate new sections/expand existing ones/restrictions? As really tired in finding free spaces in eboots, there is never enough.

 

It's pretty much the same as for .exe files. Obviously the format's different, ELF is a bit harder to do, but it's the same thing really.

Here's a quick example using Digimon Adventure:

Firstly here's the default (decrypted/extracted) EBOOT:



There's a detailed explanation of the file header on http://en.wikipedia.org/wiki/Executable_and_Linkable_Format - Things to note are the pointer to the start of the program header table at 0x1c, which in this case is 0x34, and the number of program headers at 0x2c, which in this case is 0x3. So there are 3 program headers at 0x20 bytes each starting at 0x34.

Program header struct:

Code:

u32 iType;
u32 iOffset;
u32 iVaddr;
u32 iPaddr;
u32 iFilesz;
u32 iMemsz;
u32 iFlags;
u32 iAlign;

Our 3 program sections start at 0x34, 0x54 and 0x74. You can see the first section starts at 0xc0, so luckily in this case we have more than 0x20 bytes free and can add another section without adding bytes. If you didn't have enough room, you'd just have to add another x bytes for whatever alignment the file uses (0x10 should be alright, but you can emulate the original, which in this case is 0x40) and fix a lot of other pointers: The section header table pointer in the file header. The iOffset entry for each program header entry, and iPaddr for the first program entry. Then also each individual section header entry in the section header table.

So at 0x94, from the struct above, I can just add in a new program section:



Increase the program header count by 1 so your new section will actually be read. I'm adding 0x1000 bytes to the end, so my file size and virtual sizes are set to 0x1000, but you can make it as big as you need. Flags set to 0x7 for read/write/execute. You can get the virtual address by adding up the iMemsz (the memory sizes) of the previous sections. I didn't align it as the game ran perfectly fine, but if you get any errors try aligning that too, 0x10 should do. Make sure you fix up the aligning at the end of the file (I was using 0x40 in this case) and set your offset there.

Add the new x bytes to your file. I just wrote in some text so I can show it appearing in the disassembler:



And finally, put the EBOOT back into the UMD, run the game, and we find our new 0x1000 byte section in memory, at base (in this case 0x8804000) + the specified virtual address (0x2835C9) = 0x8A875C9:



There are other ways you can do this, you can just extend another section if you want. You'd ahve to add your bytes to the end of that section, increase the filesize for that program section, and then add the amount of bytes you increased it by to all the other program sections below the one you extended, so they point to the right place. You will likely have to mess with and add to the relocation table and crap as well eventually, to make sure offsets work correctly, like the call/jump to your new section, and any you make in your code as well. Relocations are annoying though, have fun with that. You can make the whole thing "cleaner" by adding your new section under the first .text section, instead of after .text/.data/.reloc as I did, but it doesn't really make any difference. Going with the extend way would be cleaner too, as both ways keep all the execute code together, but in the end it's all the same, whichever's easier is best. I do like having my own section which I can usually name .patch or something.

That's the basics of adding/extending sections though. I think the biggest problem you may have is using a decrypted EBOOT. Not every game runs properly using the ELF (I think? Maybe I'm wrong here). And trying to re-crypt the EBOOT might be a bit difficult.

 

Thx for explanations! Well, I think even if such games exist (who do not run as decrypted Eboots), I still did not saw them Usually this was related with LBA issue, not Eboot encrypted. Anyway I can be wrong too, as did not have much experience in this.

So, regarding the explanations. I just took a EBOOT, and there is a start from A0. So I need more x10 bytes as you told. So, I shift all program table +x10 bytes forward and shift the sections data table start forward for x10 too. What else I should do apart this? As after this PPSSPP started crashing on ISO load, so I suppose there is something else... I just inserted 0x10 bytes, nothing else.

 

Which game? I think you'll have to change each section header entries as well if you're moving things. The pointer to them, as well as their size and count are defined in the file header. There's tonnes of them so it's a real uber pain to do manually, but that's always the case with manually editing executables. Probably quicker to whip up a quick script to change them for you.

 

Already done sort of script (who told PHP is only for web?) and sent you a PM Maybe I can do some semi-automatic tool for my needs, if all will work correctly.

 

The iFilesz is the size as it is in the file itself. The iMemsz (and iVaddr) is the sizes (and address) of the executable in memory when it gets loaded. When you load executables they aren't 1:1 copies from file to what executes in memory. So 0x1FDE00 is the file size of the EBOOT, but 0x318780 will be the full "loaded" executable size.

I'd recommend adding a new table, because I think it's easier, and once you've added it you can change the size of it without affecting anything. If you expand the current one you'll have to update the section header every time (and that takes ages).

So the things you'll need to edit would be:

Add 0x20 bytes in at 0x54, pushing the code down to 0x74.
Add 0x20 bytes to the pointer at 0x20 in the file.
Add 0x20 bytes to iOffset.
Add 0x20 bytes to iPaddr of the first program header entry.

Then go to that pointer at 0x20, that takes you to the section header table. All the offsets there need to be updated as well. There'll be 0x18 of them, each one 0x28 bytes, and the offset you need to change is 0x10 bytes into each entry. Add 0x20 to all those 0x18 entries, and then you should be set in terms of expanding.

Then you should be able to add your new program header in just in the way I did above.

If you want to send me the EBOOT I can do it for if you'd like. I just helped Scorp with his for Ever17.

 

Yes, exactly, as I stumbled into same issue And I think tomorrow I can show a script, which could automatically expand any (well, at least supposed to be so) EBOOT by adding a new program section just after all other section, exactly like Kelebek described. I am not really sure as there is quite strange behaviour of "Sections" part, which I cannot fully understand (so by now just do a check to skip that part).