[C#]SigScan help...

[FattyXP]

So I'm using a class called SigScan, a C# Port of FindPattern by P47R!CK. Byte Signatures, Masks, etc.

This is finding the appropriate location, and it gets put into a IntPtr called pAddr. Now.. this is where it just isn't clicking for me. If I take the IntPtr that is returned, convert to hex, subtract the hex Base address, and there is my offset. I also happen to be using GreyMagic, and with WriteBytes is where my problem starts. If I use the offset with isRelative = true, then it works perfectly fine, but only when I program it statically. But as soon as I try to use pAddr without isRelative, WoW crashes. The IntPtr returned does not be to be rebased (as subtracting the base gives me the offset that works fine with isRelative) In fact it crashes if I try to use it with isRelative on as well. I tried programmatically subtracting the base and letting isRelative re-add the base, that didn't work. Also tried rebasing with isRelative off, still crashes. But if I set it with new IntPtr() followed by the offset then everything is dandy... but I'm tryin' to use signatures lol.

MemoryIn.WriteBytes(new IntPtr(0x8E9E76), new byte[] { 0x74, 0x32, 0x90, 0x90, 0x90, 0x90, 0x90 }, true);

Works fine... I'm banging my head against the wall here.

Might also need to mention I'm using External reader, not injected.

[abuckau907]

So, this work

MemoryIn.WriteBytes(new IntPtr(0x8E9E76), new byte[] { 0x74, 0x32, 0x90, 0x90, 0x90, 0x90, 0x90 }, true);

but this doesn't?

IntPtr xx = 0x8E9E76; // or xx = SigScan();
MemoryIn.WriteBytes(xx, new byte[] { 0x74, 0x32, 0x90, 0x90, 0x90, 0x90, 0x90 }, true);

From your post title -- so, you have SigScan working. ? This is a question about patching/codecave ?

[FattyXP]

Yes SigScan is working, I have SigScan returning an IntPtr to pAddr. Then I am trying to pass that pointer to WriteBytes but it causes wow to error when I write to it, but the same pointer results in the offset that works perfectly fine. Its not a huge deal I guess, I can just manually update the offsetts using the SIgScan to find them, but I'd rather just have it find them at runtime.

Sent from my SPH-L710 using Tapatalk 2 :: lol stupid auto-correct... retyped on my PC.

[abuckau907]

edit: the way you say ..return AN INTPTR..and..pass that POINTER -- you call it a pointer, but really it's not a pointer --> you never read it, and use the address that was read (from what I gather, the addr is in .code section, and contains asm, not a pointer??) you simply write to it (some asm + nops). So maybe call it a mem address / mem location ? Maybe that's what you meant* to say, but seeing as the difference is so critical, thought I'd bring it up?

Sorry, dumb question, but
a) you verify SigScan returns the correct* result? ie. 0x8E9E76 or 9346678 in decimal ?
If so, it's very weird that hardcoding the writebytes would work, but passing in the IntPtr doesn't? So weird, that I think SigScan result is problem?

try

IntPtr xAddr = SigScan(your byte pattern);
MessageBox.Show("SigScan Result: " & xAddr.ToString("X")); // .ToString("X") = convert to hex string, at least in vb :/

b) check 100% sure xAddr == 0x8E9E76 ?

--I was thinking maybe the memory loc is READ_ONLY (or, not WRITEable), which would maybe cause wow to crash? or your program to throw an exception. But if it works with the hardcoded address, that's not the problem
--So it's the IntPtr you're passing in??

c) when you hard-code the value in --> Browse the memory region w/ CheatEngine to verify WriteBytes worked?
ie. starting at address 0x8E9E76 you see the values 0x74, 0x32, 0x90, 0x90, 0x90, 0x90, 0x90

[FattyXP]

I got it working... was working with the wrong offset and pattern all night somehow, I must have mixed myself up half asleep lol.

Sent from my SPH-L710 using Tapatalk 2

[abuckau907]

Sweetness. glad.

(again, maybe being too technical,but there are no 'offsets' in this example, unless by 'offset' you meant 0x8E9E76? since you're not adding it to anything, isn't it really just a memory loc, not an offset?)

[ccKep]

again, maybe being too technical,but there are no 'offsets' in this example, unless by 'offset' you meant 0x8E9E76? since you're not adding it to anything, isn't it really just a memory loc, not an offset?

This reminded me of something _Mike posted last year (don't ask me why... I always keep remembering useless stuff):

And an offset from zero is effectively an absolute address.

Thread: Address != Offset

[abuckau907]

"And an offset from zero is ..." is just silly.

technically any valid positive offset, could also be a valid absolute address (offset = an integer, address = an integer, both are just integers) Same with pointers, technically just a integer.
not trying to argue semantics (as it's already been done here), but someone who keeps 'accidentally' calling them the wrong name, like pointer, when really they just meant 'memory address', is probably actually treating it like a pointer sometimes :/

[ccKep]

Same with pointers, technically just a integer.

x64 would like a word with you.

Edit: Maybe my english was a bit rusted and you didn't mean the data type... in this case: ignore this post ofc.

[abuckau907]

yes, I meant 'integer' as in 'a natural number' -->not the 'integer data type'. off topic now.

edit: natural numbers can be negative, plz don't.

[Cypher]

yes, I meant 'integer' as in 'a natural number' -->not the 'integer data type'. off topic now.

edit: natural numbers can be negative, plz don't.

[citation needed]

[abuckau907]

[citation needed]

touche. i did a hasty wiki search(definitions 'natural numbers', 'real numbers', etc). I was wrong.

[FattyXP]

God, can't get away from the grammar nazi's anywhere... =-P

[Cypher]

God, can't get away from the grammar nazi's anywhere... =-P

The issue I raised had nothing to do with grammar... There's a difference between nitpicking someone's grammar and pointing out something which is factually incorrect.

[FattyXP]

The issue I raised had nothing to do with grammar... There's a difference between nitpicking someone's grammar and pointing out something which is factually incorrect.

Well what exactly is one to think when something is being put into something called IntPtr. Pointer is in the GD name dude. It doesn't matter what the data being held actually represents... its called an IntegerPointer. Its pointing me to a specific spot in memory. The "offset" I'm getting, is subtracting whatever the base is, and wham... thats how far off of the start of the program I need to look for whatever I'm doing... its an offset.

Citation:
The distance from a starting point, either the start of a file or the start of a memory address. Its value is added to a base value to derive the actual value. An offset into a file is simply the character location within that file, usually starting with 0; thus "offset 240" is actually the 241st byte in the file. See relative address.
Offset Definition from PC Magazine Encyclopedia

#2: In computer engineering and low-level programming (such as assembly language), an offset usually denotes the number of address locations added to a base address in order to get to a specific absolute address. In this (original) meaning of offset, only the basic address unit, usually the 8-bit byte, is used to specify the offset's size. In this context an offset is sometimes called a relative address.
Offset (computer science) - Wikipedia, the free encyclopedia

So yes, I am using it properly.


And yes, they are nit picking with the way I used the words. All I'm doing is saying its returning an IntPtr... because it is. Thats the freaking data type being returned, into an IntPtr variable type. Had I been reading and returning a "POINTER" I would have said the full word instead of the abbreviation that's used as a variable data type.