HELP with Multi Level Pointers
HELP with Multi Level Pointers
So I have found some of multiple offsets that add together to make a pointer. But each time the game patches only one offset changes (the 1st one that is added to the base). My question is : can I find an AOB for it so I don't have to find another one each time? if so, then how? Also, is there another way to do this?
Yes (I think you mean "find a 'pattern' for use with AOB", not 'find an AOB', but same difference). Do you understand what each is?
Post a screenshot of the code at moduleBase + offset1 and we'll go from there (CheatEngine's 'memoryview' is good for it).
example
Post a screenshot of the code at moduleBase + offset1 and we'll go from there (CheatEngine's 'memoryview' is good for it).
example
Here you go.
Cool, so do you understand the concepts of what we're doing?
1. what a 'pattern' is
2. converting a series of assembly instructions to a pattern
3. taking out parts that might change
4. The AOB/FindPattern function itsself
A bit. I've read about some of it before on the net. Not really sure of how to do it properly though.
Do you know the pattern
would make? Or even a small piece of it?
Do you understand which bytes in an instruction can/will change, and which will stay constant?
would make? Or even a small piece of it?
Do you understand which bytes in an instruction can/will change, and which will stay constant?
Nope. Got no pattern/anything. Don't understand what will change or not either. Do you happen to know what signature scans are? another person recommended that I should use them but idk what they are. Another one said something like " GetModuleHandle(NULL), or use a x87 call, then fstenv and read [esp]->FloatingPointInstructionPointer (esp+$0c iirc). "
You already have the pattern 
well..maybe exact pattern, but we'll get to the parts that change. You really need to have an understanding of asm to do this type of thing? Can you name the 8 general purpose registers?
A series of instructions == a pattern
so if the game.exe had some area that looked like
each of those instructions will be represented by 1 or several bytes.
See the "BYTES" tab on the Memory View image? those are the actual bytes, the 0's and 1's, that make up that instruction.
a pattern = several bytes in a row
So when you "Scan memory for a pattern" you're scanning for some specific array of bytes because you know the game uses that code (sequence of bytes) somewhere.
This (sometimes. - more often than hardcoding addr/offsets) works across game-updates because the game function still ends up using very similar asm code. Or the code wasn't changed at all, and only it's relative location in the program changed (and therefor possibly the offsets it uses).
Some parts of the instructions will change, some won't. For example, a jmp instruction is 5 bytes --> 1 bytes for the instruction code, and a 4 byte offset for where to jump to. So, if that jump instruction was a pattern...the first byte would never changes, and the next 4 bytes probably will. So your pattern, for that part, would look like "x****"; where x = an important byte, * = changing byte/unimportant
I'm not explaining it very well...it's kind of hard w/o knowing your background knowledge first. Plz ask a specific question?
I highly recommend the assembly videos tutorials by 'whatsacreel' on youtube for learning a little more about assembly.
--I've heard of x86, no idea what x87 is : p Not sure what they were talking about...
well..maybe exact pattern, but we'll get to the parts that change. You really need to have an understanding of asm to do this type of thing? Can you name the 8 general purpose registers?A series of instructions == a pattern
so if the game.exe had some area that looked like
Code:
push ebp mov ebp,esp mov eax, 21000 mov ecx, 42 mov edx, 7
See the "BYTES" tab on the Memory View image? those are the actual bytes, the 0's and 1's, that make up that instruction.
a pattern = several bytes in a row
So when you "Scan memory for a pattern" you're scanning for some specific array of bytes because you know the game uses that code (sequence of bytes) somewhere.
This (sometimes. - more often than hardcoding addr/offsets) works across game-updates because the game function still ends up using very similar asm code. Or the code wasn't changed at all, and only it's relative location in the program changed (and therefor possibly the offsets it uses).
Some parts of the instructions will change, some won't. For example, a jmp instruction is 5 bytes --> 1 bytes for the instruction code, and a 4 byte offset for where to jump to. So, if that jump instruction was a pattern...the first byte would never changes, and the next 4 bytes probably will. So your pattern, for that part, would look like "x****"; where x = an important byte, * = changing byte/unimportant
I'm not explaining it very well...it's kind of hard w/o knowing your background knowledge first. Plz ask a specific question?
I highly recommend the assembly videos tutorials by 'whatsacreel' on youtube for learning a little more about assembly.
--I've heard of x86, no idea what x87 is : p Not sure what they were talking about...
P47R!CK's SigMaker plugin for ollydbg is excellent for creating signatures. Like abuckau explained, '?' are unknown bytes wich might change on each run ( addresses, offsets, etc ) wich will be ignored in the scan, and 'x' are bytes of opcodes, wich will stay constant.
My quick explanation: ( lets use the code in my sig! )
Code:
00F38C0E B8 0610F300 MOV EAX, 00F31006 00F38C13 C700 208CF300 MOV DWORD PTR DS:[EAX], 00F38C20 00F38C19 EB FF JMP SHORT 00F38C1A 00F38C1B 90 NOP 00F38C1C 0000 ADD BYTE PTR DS:[EAX],AL 00F38C1E 0000 ADD BYTE PTR DS:[EAX],AL 00F38C20 58 POP EAX 00F38C21 ^EB EB JMP SHORT 00F38C0E
Next instruction: MOX DWORD PTR [EAX], 00F38C20. The sig would be "\xC7\x00\x00\x00\x00\x00" and the mask "xx????". Again, the opcode for the mov (0xC7) will stay the same. Note the second 'x'! We can assume the registe will stay the same, so we include the op1 in our scan.
The rest: All of the rest is static. The NOP (0x90) will not change, nor will the DB 00's. (Olly displays DB 00's as ADD BYTE PTR [EAX],AL if you edit them manually) So the rest of the sig is "\x90\x00\x00\x00\x00\x58\xEB\xEB" and the mask is all 'x' obviously: "xxxxxxxx".
SigMaker does all this work for you, and it scans if your pattern is unique to the process. If there is more than one occurence of the pattern, you can't reliably find the place in memory for your hack.
I hope this clears pattern scanning up a bit.
