scanning help

[esco]

Oh alright then, so I was on the right track. I thought I was WAY off again or something.

SO I went ahead and made some structures... and the ones that I needed for just mem addresses, I learned how to do the addition in Hexadecimal... so here's what I'm doing:

Code: Select all

//my static address.... I used the pointer search for static addresses only... //and this is one for the psx emulator exe itself.
extern LONG address = { "", 0x400144 };  (Address is 10f000e0)
//variables
extern BYTE buttonpress = { "", address+0xbe74b3 }; (Address is 1ac7593)
extern SHORT rooms = { "", buttonpress+0x351ed };  (Address is 1afc780)
extern BYTE character = { "", buttonpress+0x3542d };   (Address is 1afc9c0)
extern BYTE canmove = { "", buttonpress+0x6b989 };
extern SHORT whippowerup = { "", buttonpress+0x6b98d };

You'll notice how the top variable references to address, and the rest to buttonpress. The reason is for now I am HAVING trouble finding an address that the variables can all reference to on multiple computers where they all come out correct. (so for now I did this, so that I don't have to CHANGE ALL OF THEM DUE TO MY MISTAKE.... just 2 instead).

That is why I am WRITING again, I need help with this. I'm trying to get around the DMA. How do I figure out which address to use, so that basically on every computer I go to, it looks for the value in that address (which in turn points to another address), then I can add to it to figure out where all my variables start.

P.S. The one I chose above for address is the same on every computer. And the one I picked the day before today, was different on each computer and didn't add up right either.[/code]

[L. Spiro]

The only thing you can trust is that on all computers there will be one static pointer that points to the ROM, and from within the ROM all the data will be the same. There will also be a static pointer to the RAM the ROM uses and pointers inside the ROM will have to be translated to get the final address on the machine.


So if all the values you are changing are inside the ROM image, all you need is the pointer to the ROM image. Then the image can move anywhere but your pointer is static so it will always know where it moves.

With this out of the way, I don’t see if you have any more problems.


L. Spiro

[esco]

The only thing you can trust is that on all computers there will be one static pointer that points to the ROM, and from within the ROM all the data will be the same. There will also be a static pointer to the RAM the ROM uses and pointers inside the ROM will have to be translated to get the final address on the machine.


So if all the values you are changing are inside the ROM image, all you need is the pointer to the ROM image. Then the image can move anywhere but your pointer is static so it will always know where it moves.

With this out of the way, I don’t see if you have any more problems.


L. Spiro

So how do i know at what address the rom data begins at? I'm assuming that is the address that I want to do a pointer search for, and find the address which in turn points to it right?

Also, that code above does not work... even after I adjusted for the new range yesterday, if I use Printf with %p, the addresses for the vars after buttonpress seem to be 000000. And I'm not sure why.

[L. Spiro]

So how do i know at what address the rom data begins at?

By searching for it in RAM.
Open the ROM file and seach for the byte array of the beginning of the file in RAM.

I'm assuming that is the address that I want to do a pointer search for, and find the address which in turn points to it right?

Something along those lones.

Also, that code above does not work... even after I adjusted for the new range yesterday, if I use Printf with %p, the addresses for the vars after buttonpress seem to be 000000. And I'm not sure why.

Use %.8X. This may not solve your problem, but then again maybe it will. Your problem might be a simple matter of not printing data of the correct sizes.

Or maybe you are not printing the correct information.
If you want the address of character in the target process, PrintF( "%.8X", &character );.


L. Spiro

[esco]

So how do i know at what address the rom data begins at?

By searching for it in RAM.
Open the ROM file and seach for the byte array of the beginning of the file in RAM.

!!!!!!!!! Christ, why didn't I think of that.

So I used your ram watcher tool and I found where pretty much the rom data I want to change starts. It was kind of obvious with all the NA's that suddenly popup and go on for MILES! Plus I already had an idea where it started in reference to one of my var declarations. AND I found an address that points DIRECTLY to it (though oddly the address where the rom starts is around 1abf000, and the pointer that goes directly to it is in the 7ff0000 range), so I'm guessing that's it.

I'll check tomorrow at work, by comparing the data on 2 computers to each other.

Use %.8X. This may not solve your problem, but then again maybe it will. Your problem might be a simple matter of not printing data of the correct sizes.

Or maybe you are not printing the correct information.
If you want the address of character in the target process, PrintF( "%.8X", &character );.
L. Spiro

Nope.. doesn't help at all. I figured out WHY I'm having this problem though. The FIRST variable (address) has a pointer stored in it... the rest all have numeric values in them... so basically when I add that HEX amount, I am ADDING to the value stored at the variables address.... NOT the vairable address itself. And using &VARNAME, doesn't help. Nor does *VARNAME. SO what exactly is the syntax to add an amount to a variables address, rather than it's stored value?

By the way... THANKS FOR ALL YOUR HELP! And your continued effort on this fantastic program of yours. You get far too little credit for all your work.

[L. Spiro]

SO what exactly is the syntax to add an amount to a variables address, rather than it's stored value?

((DWORD)&VAR) + VAL;


L. Spiro

[esco]

..

[esco]

Coo bro, hey thanks again for all your help. I figured out a way to do it, which mixes up your method with using an array. So that I don't have to declare the same variable again for each function.

EDIT: DAMNIT! Now I have another odd question... I figured to make the code easier to read I would declare a few constants here is why.

Right now I have it setup like this:

Code: Select all


const int rooms = 125888;

extern LONG baseaddress = { "", 0x7ffdb008 };  //value is 1ccf000
extern SHORT address[1] = { "", baseaddress-0x02};  //makes it start at 1cceffe

So basically now address[rooms] should take me to the address of 1d0c780:

address[1] = 1ccf000, so address[125888] = 1ccf000+3d780 (125888 * 2 due to it being of type SHORT) This in turn equals 1d0c780. However when I run it, for some reason it comes out with a value of 0, and the memory address is still 1cceffe... it's as if it ignores rooms and put in a 0 instead.

Even typing out address[125888] won't work. I have the constants declared at the top with my structures, so it is global. And I want to use constants like this so the code is MUCH easier to work with, rather than staring at a bunch of numbers.

[L. Spiro]

0x7FFDB008 is an address inside or very near a system module and can not possibly be the pointer to your ROM.


125888 is too large for an array. Don’t declare static arrays larger than 65,565 units long (actually I think I allow arrays over 2 megabytes or something, but static arrays this size are never good).

However when I run it, for some reason it comes out with a value of 0

What comes out as 0?
&address[125888], or address[125888]?

If address is extern and &address[125888] == 0, address was not declared on valid memory. You made a mistake somewhere. Verify all expected results in the Hex Editor to ensure the target address is readable.


L. Spiro

[esco]

0x7FFDB008 is an address inside or very near a system module and can not possibly be the pointer to your ROM.

I was shocked too.... but it points to EXACTLY where the data starts that I want to edit, and that even cheat devices utilized in epsxe. And it also matches my data from the other emulator. It also works PERFECTLY on multiple computers.

125888 is too large for an array. Don’t declare static arrays larger than 65,565 units long (actually I think I allow arrays over 2 megabytes or something, but static arrays this size are never good).

Nah bro. I didn't DECLARE an array of this size, I remember what you said before... I kept your advice and declared the array to be of size 1. The code is below.

If address is extern and &address[125888] == 0, address was not declared on valid memory. You made a mistake somewhere. Verify all expected results in the Hex Editor to ensure the target address is readable.


L. Spiro

Here is a SNIPPET of the code.... with the relevant variables.

Code: Select all

const int rooms = 125888;
extern LONG address = { "", 0x7ffdb008 };    //value is 1ccf000
VOID Lock()
{
extern SHORT address2[1] = { "", address-0x02};
extern BYTE character = { "", address+0x3d9c0 };
if (character == 1 && address2[125888] > 0) {functionhere;}
}

Using PrintF("%.8x", &address2[ANY NUMBER HERE]), prints the value of where the array starts (0000effe, since it's short type, long prints 01cceffe). If I use %d and address2[any number here] the value is always 00000000. Now do you see why I'm so confused?

[L. Spiro]

What version are you using?
I fixed the extern array bug months ago.


L. Spiro

[esco]

What version are you using?
I fixed the extern array bug months ago.


L. Spiro

File version 5.0.0.0. downloaded 3/7. Interestingly enough... I have ANOTHER array in a function that functions fine. It prints decimal values fine, but if I use the setup below... it will ONLY print the memory address for whiptemp[0] no matter WHAT is entered between the [].

Code: Select all

(snippet with necessary data)
extern LONG address = { "", 0x7ffdb008 };

void brandishwhip ()
{
extern SHORT whiptemp[1] = { "", address+0x74ff6 };

   PrintF("%.8x", &whiptemp[1]);
}

[L. Spiro]

The file version is always 5.0.0.0.

You need to get Demo #24.



However there is a bug in Demo #24 I have just found.

Code: Select all

extern LONG e_sShorts[1] = { "", 0x01005334 };
PrintF( "%.8X", &e_sShorts[0] );

Prints 01005334

Code: Select all

extern SHORT e_sShorts[1] = { "", 0x01005334 };
PrintF( "%.8X", &e_sShorts[0] );

Prints 00005334

Code: Select all

extern BYTE e_sShorts[1] = { "", 0x01005334 };
PrintF( "%.8X", &e_sShorts[0] );

Prints 00000034

See the pattern?

I will give you the code to MHS and let you fix it.


L. Spiro



P. S.: Also, &e_sShorts[0] prints 01005334, &e_sShorts[23] prints 01005334, &e_sShorts[239837] prints 01005334, etc.
But &e_sShorts[I] prints 01005334, 01005338, 0100533C, etc., as I increases.

So it prints the correct address if a variable is used.

So I think this might be easy to fix when I get home from Japanese class.
Two changes: Apply address offsets with constant indices, and do not cast the return value to the same type as the variable.

[esco]

The file version is always 5.0.0.0.

You need to get Demo #24.

I had demo 23, I just downloaded 24

However there is a bug in Demo #24 I have just found.

It's coo, i'm about to leave work so I won't be working on it till tomorrow again.

Code: Select all

extern LONG e_sShorts[1] = { "", 0x01005334 };
PrintF( "%.8X", &e_sShorts[0] );

Prints 01005334

Code: Select all

extern SHORT e_sShorts[1] = { "", 0x01005334 };
PrintF( "%.8X", &e_sShorts[0] );

Prints 00005334

Code: Select all

extern BYTE e_sShorts[1] = { "", 0x01005334 };
PrintF( "%.8X", &e_sShorts[0] );

Prints 00000034

See the pattern?

Yeah, I understand this already bro.

I will give you the code to MHS and let you fix it.


L. Spiro

?????

P. S.: Also, &e_sShorts[0] prints 01005334, &e_sShorts[23] prints 01005334, &e_sShorts[239837] prints 01005334, etc.
But &e_sShorts[I] prints 01005334, 01005338, 0100533C, etc., as I increases.

So it prints the correct address if a variable is used.

So I think this might be easy to fix when I get home from Japanese class.
Two changes: Apply address offsets with constant indices, and do not cast the return value to the same type as the variable.

OH! So I found some bugs... huh, see I can be helpful. 2nd time I've actually been of some use to you. Now I just need to help you out about 50+ MORE TIMES, and we'll be even for all the help you've given me! LOL.

Anyways, I'll check the forums tomorrow for the updated version. Thanks.

[Torero]

Pointer search:




as the help file described, I used the pointer search and found 21 results, what i don't understand is how i can narrow down to the pointer iam looking for?


also, if the pointer is quite close (as it is small ) , they most likely wouldnt not be inside a module.



if i can find values inside a module, i don't need pointer right?

and if they are not inside a module, the values most likely are far enough away from the modules that the bases themselves cannot be labeled with {module + offset}.



what should i do?