Memory addresses and how to find them?

So I have followed these kind of mods for a pretty long time(SA-MP etc) and one thing that intrigues me a lot is that how do you locate the things you need from the memory. For example you have the function that you can change the weather with. When you made that, where did you start from? How did you locate the function that the game uses to change the weather and the place where the weather is stored? Is there some kind of a method to find that easily or do you only have good guesses? When you decompile the game, what do you look for when you search for the weather for example? I know that the player coordinates are quite easy to locate and so on but location more complex things like the weather interests me.

I would be so grateful if you could offer me some insight. Also I could probably give some help with the project as I have pretty strong c++ skills but not very strong in this particular field.

Thanks!

This has something to do with Reverse Engineering, you need to first find out how the program works.
I'm however not entirely sure on how to do it with C++ but in Java I would decompile the source code, then modify the Java Bytecode.

You usually have an entry point from which you can start reverse engineering, progressing towards the pieces of code which you are interested in. Entry points can for example be found by using memory read / write breakpoints on data you know will be used in code which is related to your point of interest.

There really isn't that much about it. You need to be able to read and understand assembly, know logic flows, design concepts. You need to be able to focus on a computer screen which is filled with huge amounts of information (at least assembly, hex dumps, CPU registers) and have fun with it.

I don't decompile executables (usually), I'm using a debugger and inspecting the running process: https://www.ollydbg.de/

You need to be patient, dedicated, passionate. If you are, you can achieve anything you want in time.

I usually use Cheat Engine for finding values,code offset where the values are accessed and then IDA to study it.
You have to know a lot about assembly to do something.

Roby

I know quite a bit about debugging and some assembly. Some days ago I tried to reverse the sims 3 for practice and find the function that pauses the game. With some string references I found a place in the code which is called when the game is paused. I tried to track it upwards and see where it is called etc but I just got stuck and couldn't find the correct place. Maybe there is a problem with my techniques.

Quote:

---

Originally Posted by Samppaa

I know quite a bit about debugging and some assembly. Some days ago I tried to reverse the sims 3 for practice and find the function that pauses the game. With some string references I found a place in the code which is called when the game is paused. I tried to track it upwards and see where it is called etc but I just got stuck and couldn't find the correct place. Maybe there is a problem with my techniques.

---

Don't start with a game so huge. Start small.
I started with GTA SA, it's not so difficult.
Get an old Single Player game, start cheating with memory addresses.
Then, start cheating harder: change the asm, make ne ammunitions go up instead of down.
In GTA VC i bugged the game making the armor go up when someone hit me.

Windows exported functions usch as ReadFile are usefull for finding where files are loaded.
Start from these functions, then go deeper in the files and find what you want to change and document the addresses on a file or a note.
I started like this and then created a basic GTA SA mp mod :)

Roby

You must be careful when debugging large apps, instead of breakpoints you should use log breakpoints, so things will keep flowing but you will still have information you need.

Also tell debugger to ignore most of the exceptions (if not all, from 0~0xFFFFFFFF) so you wont catch any of the app's exceptions nor debugger traps. Games are based on time to render frames and run the logics, pausing execution might be troublesome in some cases as well.

Most important is to step into a reference you know a certain function will have to execute/access and collect the data of what, when and why. If you actually find a breakpoint in a function you are sure the function you want have called, you can analyze stack for the RET values to track the source of the call and then understand why it was called, eventually finding the piece of code you want.

Knowing how to use debugger tools is also a life saver. Will help you collect the important data in smaller ammounts of time and will give you shortcuts for your goals. Making poor use of the tools will just ruin you and waste a lot of time and sometimes make you miss what is important.