Let's say I want to make a cheat script for inf. mana.
I first find out which address is for mana and then find an opcode that writes to the address.
When I search which addresses access to the opcode(to know if the opcode is only for mana or for many other addresses) and the result says hundreds of address access to the opcode.
I select the address for mana as group 1 and use 'find commodalities' function but get nothing useful.
I usually see stack result of the address and match each relative address and static values.
Usually written in aob assembly script as
cmp [rbp-xx],xxx.exe+xxxxx
jne originalcode
cmp [rbp-xx],xxx.exe+xxxxx
jne originalcode
cmp [rbp-xx],xxx.exe+xxxxx
jne originalcode
...(repeat)
but this works only when a few address access to an opcode
I can't distinguish a certain address(address for mana in an above example) with that method(too many lines even if it's possible).
Any other ideas? I alway got stuck when opcodes are general opcodes...
How to sort out in a general opcode?
Re: How to sort out in a general opcode?
When there are multiple instructions addressing the same address, I usually check for:
- is this instruction using the right offset directly (i.e. mov rax,[rsi+e0] instead of mov rax,[rax])
- is this instruction in a good spot (can do a jmp5/jmp14 easily)
- is this instruction always used (when in the menu, when in the game, when looking at inventory, in combat, out of combat, etc.)
- is this instruction used reasonably often? (often enough to make a difference, but not too often - one-four access per frame drawn is a good candidate, 1 per second might not be enough, 1000s per second it an instruction you probably don't want to use),
- is this instruction used only on the event when needed (e.g. when a spell is cast and mana is meant to be decreasing) - here, you don't need to consider how often it is accessed.
- is this the only address the instruction is accessing? (so I would not need to build code to sieve through objects)
- is there a valid register with other useful information I would like to use (e.g. player's address)
This is a generic list of considerations, not specific to your use case, but it should give you ideas how to feed that 'sweet spot'.
- is this instruction using the right offset directly (i.e. mov rax,[rsi+e0] instead of mov rax,[rax])
- is this instruction in a good spot (can do a jmp5/jmp14 easily)
- is this instruction always used (when in the menu, when in the game, when looking at inventory, in combat, out of combat, etc.)
- is this instruction used reasonably often? (often enough to make a difference, but not too often - one-four access per frame drawn is a good candidate, 1 per second might not be enough, 1000s per second it an instruction you probably don't want to use),
- is this instruction used only on the event when needed (e.g. when a spell is cast and mana is meant to be decreasing) - here, you don't need to consider how often it is accessed.
- is this the only address the instruction is accessing? (so I would not need to build code to sieve through objects)
- is there a valid register with other useful information I would like to use (e.g. player's address)
This is a generic list of considerations, not specific to your use case, but it should give you ideas how to feed that 'sweet spot'.
Re: How to sort out in a general opcode?
^^ and some more tactics:
a. you do not necessarily need the 'write' opcode; in most/many situations any opcode that reads your mana will do
(iow if you can change/update it via the addresslist manually, you'll know...)
b. still: find any opcode that accesses mana, and check each and everyone to find out which address(es) show up. again, some of them will uniquely return your mana(struct).
=> if you DO need to use the 'write' opcode - and pt b. gave you a "unique" opcode - you register the struct in opcode b. to distinct your mana in opcode a.
c. start building pointers: before proceeding, weed them out to a reasonable/sustainable amount (iow they stay "alive" days/weeks later). now check what opcode accesses the "base" of your chain - with some luck you'll get a static address directly from the opocde - and if not, work up the chain and check other substruct_values along the way. I rarely miss here frankly...
a. you do not necessarily need the 'write' opcode; in most/many situations any opcode that reads your mana will do
(iow if you can change/update it via the addresslist manually, you'll know...)
b. still: find any opcode that accesses mana, and check each and everyone to find out which address(es) show up. again, some of them will uniquely return your mana(struct).
=> if you DO need to use the 'write' opcode - and pt b. gave you a "unique" opcode - you register the struct in opcode b. to distinct your mana in opcode a.
c. start building pointers: before proceeding, weed them out to a reasonable/sustainable amount (iow they stay "alive" days/weeks later). now check what opcode accesses the "base" of your chain - with some luck you'll get a static address directly from the opocde - and if not, work up the chain and check other substruct_values along the way. I rarely miss here frankly...
Who is online
Users browsing this forum: No registered users