What else can be loaded into ram?

[Torero]

Static addresses are noted in the format [module+offset]. For example, In logger.dll, we may have discovered a valuable integer at address 0x003304C0. Since logger.dll may move, we don’t just use this address directly. Instead, we use [logger.dll+0x4C0]. Therefore, when logger.dll decides to packs its things and move on to 0x05000000, [logger.dll+0x4C0] gives us 0x050004C0, and we still have our valuable integer.




Can you define DLL in terms of its meaning to MHS, and what else can be loaded into ram?

Like the active in-game variables that exist only when it runs probably don't exist as any particular file under its own folder.

I understand the concept of off-set now, it's when we discover a value's relation to what that something owns that sector of ram, we can alwadys find the new location of that value 99.99% of the time beacuse it's part of that something (like a .dll)

[Torero]

Remember, a pointer is just another data type, and data types are defined by how they are used. During dynamic memory allocation, Windows® will find an arbitrary address that can not be predicted, thus pointers are used to tell the game where the requested memory has been allocated. A pointer is an unsigned long that, instead of being used for math, is used to indicate the locations of various data the game needs to run. The game knows where the pointer itself is, and then by using that pointer it can determine where other things are—and so can we.

All data in all games have addresses and values. An integer can have an address of 0x00443C0C and have a value of 100 (0x64), and this value is used for mathematical purposes. Likewise, a pointer can have an address of 0x0042104C and a value of 0x004AE804, but this value isn’t used for math. This value is yet another address.







in other words, we can find all pointers there are by searching the ram throughly, since the format of pointers are defined by Windows TM, it's gurranteed that we can rely on the fact that pointer look just like, a pointer, all the time. right ?


I was confused and thought that the games can use cryptic ways of relaying itself data and scramble them so that it's hard to find out which address contain the value we want...

Like, write down HP = 58 ten thousand times and automatically generate useless but complex computations to camouflage the real HP 's adress.

which can be changed 10k times per second.

right ?

[Torero]

Notice that the pointer itself did not move—only its value changed to indicate a new address for our player data. The game relies on this pointer staying in the same location, or else it has no way to know where our player data is in RAM. When the game was compiled, address [lspiro.exe+0x2104C] was designated by the compiler as being the location the game can always use to find its player data.

This is why it is important that all the data inside a module moves exactly with the module itself. During compilation, the compiler writes instructions that simply “understand” the way each address (from the module base) is to be used, and if the data in the module does not stay perfectly aligned, the game simply can not run.






I am still digesting this, but I think it means it's hard to do the tricks i mentioned aboe... i think.,

[Torero]

Get The Board Tiles
View the 0x01005334 address in the Hex Editor again.
The board height was right there, and the chances are good that the board array (the tiles on the playing field) are there too.
As mentioned, the Hex Editor will highlight bytes that change, so use this to our advantage.
Go to Minesweeper, Game/New (or press the smiley face).
This makes a new game with a new board array. If anything changed in our Hex Editor, it will be related to this change in our game.

Looking back at the Hex Editor shows that indeed several bytes have changed just below 0x01005334.
Guess what. We just found the board array already.
Further investigation reveals that it starts on 0x01005361.







how does an array look like in the hex editor?

[L. Spiro]

Can you define DLL in terms of its meaning to MHS, and what else can be loaded into ram?

A DLL in MHS is the same as anywhere else. Any type of module that can be loaded and “executed” by the target process (or any process).
This applies to both questions.

Like the active in-game variables that exist only when it runs probably don't exist as any particular file under its own folder.

The .EXE file itself either has them or makes them.

can alwadys find the new location of that value 99.99% of the time beacuse it's part of that something (like a .dll)

100% of the time.

in other words, we can find all pointers there are by searching the ram throughly, since the format of pointers are defined by Windows TM, it's gurranteed that we can rely on the fact that pointer look just like, a pointer, all the time. right ?

Windows® always returns a pointer in a specific format but the game can encode that point however it pleases.
You can’t always just search for this format, however encoding pointers is a long process that slows down the game, so very few, if any, do this.

Like, write down HP = 58 ten thousand times and automatically generate useless but complex computations to camouflage the real HP 's adress.

which can be changed 10k times per second.

right ?

They could if they wanted.

I am still digesting this, but I think it means it's hard to do the tricks i mentioned aboe... i think.,

Up to the game to do the tricks, if it has enough resources and time available to do them.
High-speed games such as Doom 3 or Half-Life 2 can’t do these costly encryptions because they need all their resources for drawing the screen, lighting, physics, etc.
Encryptions would slow the game down and they don’t like it.

how does an array look like in the hex editor?

Like a series of connected sets of data.
A series of bytes or a series of shorts or whatever.


L. Spiro