Cheat Engine

[Akillibirisi]

As the image suggests, "Find Out What Writes To Address" returns opcodes like Nop or Push, which I don't see how would be possible without even reference to the address in question. CE version is 7.5

[ParkourPenguin]

That address is in the stack. Instructions like `push` / `pop` access the stack.

As for `nop`, I don't see any in that list (the bottom is probably an instruction you replaced w/ nops afterwards), but it might be some edge case concerning a string operation with a `rep` prefix.

That `jmp` instruction is weird. I'd make the same guess.

[Akillibirisi]

Sorry for the confusion, here's the reupload of the same window scrolled down.

I was expecting that only lines that make direct alterations to the chosen memory location show up in the list. I still can't think of a scenario where stack somehow makes changes to a select memory location.

I'm afraid the original assembly here is completely intact, apart from some friendly value changes here and there. So Nops are the most baffling for me.

Could this "Find Out What Writes" function may be more involved than simply sending the actor by any chance ?

[ParkourPenguin]

Oh, I think I see what's happening. Maybe CE gets confused when a `call` instruction triggers a data breakpoint. This type of breakpoint triggers after the relevant instruction has executed. In the case of a `call` instruction, the thread has already branched to the callee, but CE tries to guess the previous instruction anyway (i.e. nop).
This might explain that weird `jmp` instruction too.

[Akillibirisi]

I mean, instructions like Nop, Call or Push followed by direct register reference, by nature, cannot alter the memory area that is not the stack, to my knowledge.

If my target address is pointed to by [esp] register and instruction "mov [esp],esi" executes, then that's the part I should be seeing, not the part where it is pushed, followed/preceded by nops, called or anything.

push esi will alter the stack, but the memory ? How can this line trigger an overwrite operation on the memory ? I don't understand.

Thing is, is it proper that I see an operation in the window that results in no changes being made to the memory location I'm interested in ? Stack is pushed, that may be followed by changes to the memory area I'm interested in, in which case I do think that's the only part I should be seeing, not the cluster of instructions that led up to that final state. There being no references to memory locations in push instructions like push [eax] should make it impossible for it to affect the memory (not the region where stack resides) directly, should it not ? It's otherwise just an operation between the stack and registers.

I hope that's been comprehensive.

I'd like to state on a side note here that I do not know the precise implementation that makes keeping track of changes to a memory location possible. There may be cases that require inclusion of those follow-up instructions like you mentioned, yet I've not come across this type of situation before, hence I'm here asking. I'm assuming that this is either a known limitation or an oversight.

[ParkourPenguin]

[Akillibirisi]

Well, I had completely ruled out the possibility that 0019B740 is a stack area, my bad there. I was expecting this address to hold some basic value like health, yet it turned out to be a highway of data that's being sent back and forth through.

Apart from that, I addressed stack and memory separately thinking it'd be more convenient though it seemingly backfired. I know stack is inside the memory, it's just the fact that said memory location happened to be the stack area that I failed to notice.

Stack is pushed, as in it expands to accommodate a new line on top, just a different interpretation of the same thing so chill out there.

Also thanks, I figured out the part of the ordeal caused by my oversight at the very least.