Cheat Engine

[icp]

Recently, the problem with memory allocation has become more frequent. Here is a screenshot of the table for the game oxygen-not-included. As you can see, there is free memory in the region, but the allocation gives an error. This happens when the game has allocated a lot of memory already after the desired code. If you use the same selection as soon as the game created the desired function, the selection works fine. If later, when it already writes about the impossibility of selection, disable one of the previously enabled injections, thereby freeing up memory, then enabling another injection will be fine, but then enabling the disabled one will already write an error. The game is somehow blocking memory allocation next to its regions.
How to solve this problem?


[RUS]
В последнее время участилась проблема с выделением памяти. Привожу скриншот таблицы для игры oxygen-not-included. Как видим память свободная в регионе есть, а вот выделение выдаёт ошибку. Происходит это когда игра выделила достаточно много памяти уже после искомого кода. Если использовать то же выделение сразу, как игра создала нужную функцию, выделение проходит нормально. Если потом, когда уже пишет о невозможности выделения отключить одну из ранее включенных инъекций, освободив тем самым память, то включение другой инъекции пройдёт нормально, но тогда включение отключенной уже напишет ошибку. Т.е. игра как-то блокирует выделение памяти рядом со своими регионами.
Как решить данную проблему?

[LeFiXER]

It looks as if those regions don't have access permissions. That could potentially explain why you cannot allocate memory in that region.

[icp]

I assumed, probably the inscription "no access" prompted me. I'm not interested in the cause of what is happening.
I'm not interested in how and why the game closes free memory regions, but how to fix this situation and allow the alloc command to work with them.



p.s. The most logical way out would be to use a far jmp. But it requires more work on injection. And there are free regions nearby, so I want to follow a simple path.

[Csimbi]

Why do you need memory in that specific region?

[icp]

[ParkourPenguin]

In a 64-bit process, if the target of a branch (i.e. jmp) is within 2 GiB of the address of the instruction following the branch (RIP), the branch target can be encoded using a signed 32-bit relative displacement. This means you only need 5 bytes to jump to your code.

If the destination isn't within 2 GiB, CE has to do some trickery to make it work. This involves 14 bytes instead of 5, making the injection point take up far more space and increases the likelihood of running into problems.

This is what the third parameter to alloc is for.

OP:
First of all, CE uses VirtualProtectEx to allocate memory in the target process. This only works on addresses that are a multiple of Windows's allocation granularity (64 KiB, 0x10000 bytes). Any free regions you see with a size of less than that can't be used.

I'm not sure why the first two regions you marked aren't being used. They're well within 2 GiB and have plenty of memory (unless you're trying to allocate a large amount of memory). I doubt it's a race condition between CE and the game allocating memory- CE tries multiple times to reduce this chance IIRC. Maybe it's a bug in how CE searches for free regions.

[icp]

These are not the only large free windows within reach. I am requesting 0x100 bytes. I have to choose the closest range 0x1000. But writes an error. It looks like the game is somehow blocking intermediate memory areas. I need to somehow get around this.

[Dark Byte]

Is kernelmode querymemoryregions enabled or disabled in settings? (Should be disabled as it really screws up the preferred allocation routine)

Free memory should look like this screenshot, yours seems to have weird data

[Csimbi]

I see you are trying to hack a mono game, so there is one more thing for you to consider.
Mono generates the executable (byte) code in runtime.
The later a piece of code is used, the later it will be generated and the farther away it will be in the memory.
As such, there's no guarantee that you will have chance to do a jmp5 next time you start that process, or, when your script is used on another machine.
I found this out the hard way: the game kept crashing randomly and I was pulling my hair out.
Eventually I noticed that the jmp5s became jmp14s randomly, overwriting used code and returning at the wrong address, too.
I had a chat with Dark Byte and he recommended that I force the jmp14 every time instead of assuming I get lucky with a jmp5 every time.
So, think about that a bit and don't be lazy

[gid2525]

[icp]

[Dark Byte]

kwrnelmode virtualqueryex is not debug related, it's memory related

that means that scanning for free memory goes through there and kernelmode vqe only detects touched memory. So if it tries to allocate in untouched but allocated memory it fails

[icp]