News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: Finding pointers through calculation? PSP  (Read 1065 times)

tywald

  • Newbie
  • *
  • Posts: 3
    • View Profile
Finding pointers through calculation? PSP
« on: November 11, 2017, 05:09:15 am »
Hi, just wondering if it's possible to find pointers by calculating. Example:

A pointer 7329(2973?) found at offset 023B6947 to 023B6948 points at 023B8BFE. I found this manually by counting from the first pointer but maybe there is a quicker way. The pattern for these pointers look like this: 0000 5429 0000 6329 0000 7329 0000 and so on.

Now I want to find the pointer for offset 023B36A2 which uses a different table a bit earlier, can this be calculated somehow?

The point table where I found for 023B8BFE starts at 023B628F and ends at 23B763B.
The point table for 023B36A2 I assume starts at 023AD864 and ends at 023AEEEC but I'm not sure.

Maybe it's possible to find by searching with a distance? i.e. if we take the above pointers: 5429, 6329, 7329 the distance from 54 to 63 is 0F and 63 to 73 is 10. I don't know if there are any hex editors that can do that. What I mean is, I don't know the actual pointer yet but I know the distance from one name to the next I should be able to search the table where these distances would match.

Name 1) 023B36A2
Name 2) 023B36AC
Name 3) 023B36B6
Name 4) 023B36BC

XXYY 0000 (XX+A)YY 0000 (XX+14)YY 0000 (XX+1A)YY 0000
XX and YY are unknown, all I know is there are 0000 between each pointer and the distance from one pointer to the next. The values I added above are the distance from Name 1.
« Last Edit: November 11, 2017, 12:09:37 pm by tywald »

FAST6191

  • Hero Member
  • *****
  • Posts: 2560
    • View Profile
Re: Finding pointers through calculation? PSP
« Reply #1 on: November 12, 2017, 07:22:17 am »
"if we take the above pointers: 5429, 6329, 7329 the distance from 54 to 63 is 0F and 63 to 73 is 10."

Save yourself some hassle later and always put the relevant number of 00s in, assuming that is not a byte flipped original.
Do a last minute mod and you are thinking I just need to add 10 when you actually meant 1000

Anyway I am not sure I would use an approach like yours.

I occasionally predict pointers -- if I am at some kind of notable position within a ROM/file then I might try a search for a fragment of that address to see if I can find it somewhere. Can be quicker than tracing pointers.

Similarly I tend to assume there are three types of pointer
1) Normal/direct (measure from start of file/ROM/memory location)
2) Offset (measure from some position within file/ROM/memory location, for the original programmer is saves really having to note how long your pointer table is)
3) Relative (take current location, add pointer value, maybe also offset. Mainly useful for

Equally I have had formats that only know their length and go from there.

To answer your question use a spreadsheet. There are times when using a spreadsheet is a bit crude but this kind of analysis is fine. You may have to convert hex to decimal to do the maths (and then back again) but it is easy then to subtract one cell from the next, or generate a list of locations (if you have a list of names are they separated by a 00 or something? Many a hex editor will search for a value and generate a list of locations for them, feed that into your spreadsheet) and use it as a sanity check or something.

tywald

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: Finding pointers through calculation? PSP
« Reply #2 on: November 12, 2017, 11:49:57 am »
It was for simplicity, once the first pair reaches FF the second pair will change when you add more: i.e FF29 -> +4 -> 032A. It's most likely flipped if you treat the two pairs as a system: i.e 29FF -> +4 -> 2A03(in reality but in the hex editor it's flipped). So I'm just working with the first pair until it reaches its max then increase the second pair by 1 then the first pair start over from 00 all the way to FF again, rinse and repeat until the end of the table :P

I assume the search thing I brought up doesn't exist? That's a shame.

I guess I need to count manually again in the strings(for example if the name I'm searching for is the 500th name counting from the bottom) then count the same in the pointer table to find the pointer. Last time wasn't so bad because the pointer table was directly before the item list however this time there are like 6 different lists that use the same pointer table so it's very time consuming to find the one I'm looking for as it's somewhere in the middle.
Or just change a pointer randomly then when I encounter it in-game I know what that is then work from there.

Yeah, each name or sentence is seperated by 00.

Here is a part of the pointer table for the items, I highlighted the first 5 items in red. The offset is in decimal.
https://i.imgur.com/FTHCR2r.png
I don't have problems with this table though as I'm already finished with it but I'm using it as an example how it looks like since the other table is similar.

weissvulf

  • Sr. Member
  • ****
  • Posts: 324
  • Good news! An anomaly solved the enigma.
    • View Profile
Re: Finding pointers through calculation? PSP
« Reply #3 on: November 12, 2017, 03:45:53 pm »
I don't know of a tool that counts by relative distance like that. I suspect the pointer pattern would differ too much from game to game for such a tool to be very useful. Also, I have also seen a lot of pointer tables that break their pattern. For example, some text will have multiple pointers- presumable because the text is displayed in multiple places. 

Pointers all end up the same - they produce the memory address of where the text starts.

The pointers you're dealing with are probably 32 bit values (aka 4byte long) and the PSP is little-endian (smallest value shown first)  so the bytes will be reversed in a hex editor. I always fix the byte order when I talk about stuff so I don't get it mixed up.

The values you mention like  00002954 are probably added to the upper digits of the text's RAM location. (ie 0x800F0000 + 0x00002954 = 0x800F2954 = text location in RAM). Location in RAM is not to be confused with location in ISO. The disk image has tons of other junk in it that makes offsets jump around  a lot.

One cheesy way to help with pointers is to copy the entire text block to a separate snippet of data. Then add 00 'padding' to the snippet until the text locations match the pointer values exactly. Example:

If the text "Bombs Only" is first entry.
And it's pointer value is  00002954.
Add 0x2954 blank 00s to beginning of  extracted snippet.

Now the text locations will match the pointer values exactly. If you want to find the pointer for a given piece of text, just note its location and search for that value in the pointer field. When you're done with edits, just overwrite a copy of the text-snippet back into the original data, making sure you don't include any of the 00 padding.

tywald

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: Finding pointers through calculation? PSP
« Reply #4 on: November 16, 2017, 02:23:06 pm »
Thanks for the replies, I think I understand a bit better now.

It's kinda like you said the pointer value gets added to one address. For the items in my screenshot it's the one just before the first(that has the pointer value of 13B8) which is offset 037446283 or 023B628B. 023B628B+2973=023B8BFE just like in my opening post. So that's good to know, I assume I can do the same for the other pointer table, find the offset just before the first name then pick a random pointer and add it to it and see where it points to.

Edit
It worked! My guess where the table starts was correct: 023AD864. And the pointer for the first name that I was looking which was on offset 23B36A2 is 5E3E, verified in game that it was indeed that one :)
https://i.imgur.com/WzoXX0H.png
« Last Edit: November 16, 2017, 08:54:27 pm by tywald »