[Classic] 1.13.3.32836 - CorpsePosition?

[NoxiaZ]

Hi,


Anyone who know how to find CorpsePosition?
I have been trying to look into GetCorpseMapPosition but with no luck, i know that last patch the pointer was 0x216C7B0, but in IDA it leads to "nothing"?

When i jump to the address in the old version it is just shown as:
.data:000000000216C7AF db 0
.data:000000000216C7B0 db 0
.data:000000000216C7B1 db 0

no xrefs or anything.

Can anyone tell me what i'm doing wrong?

[Buntstift]

Didnt look into it. But maybe you can find it just by Cheatengine:
Find out your current position in a healthy state. Note it down, then die. run back to you corpse and search in your memory for this position you noted down.

[charles420]

cheat engine or live debug would be the right way to do it but you can also just find closest offset u can find and take the difference and + or - it from corpseX offset , that's the lazy factor way for win Work Smarter Not Harder

[NoxiaZ]

I can find it by using Cheat Engine, but i can't figure out how to get the pointer using Cheat Engine in this version of WoW.

When doing pointer scan i either doesn't end up with anything that works, or it takes the whole night to run the pointer map. - All the pointers are name something like THREADSTACK1 which i haven't figured out how works.
So hoped i could find it by using IDA instead.

Edit: too much work compared to just store the location when I die. Anyways thanks guys for taking time to answer

[Mr.Sergey]

CorpseX = 0x21C2768 + 0x28

[NoxiaZ]

CorpseX = 0x21C2768 + 0x28

Thank you so much, but still wondering how you guys are finding this pointer

[Jadd]

Depending on what I need, I use a combination of IDA (static analysis,) Cheat Engine (simple live analysis) and x64dbg (intricate live analysis.)

For corpse position I found it easily through Cheat Engine taking note of my position, dying and releasing. From there I sigged it and added it to my IDA pattern scan script.

    if function_name == 's_corpseMapId':
        ea = FindBinary(0, SEARCH_DOWN, '48 C7 05 ?? ?? ?? ?? FF FF FF FF 0F 57 C0 89 05 ?? ?? ?? ??')
        ea = GetOperandValue(ea, 0)
        return ea
    
    if function_name == 's_corpsePosition':
        ea = FindBinary(0, SEARCH_DOWN, '48 C7 05 ?? ?? ?? ?? FF FF FF FF 0F 57 C0 89 05 ?? ?? ?? ??')
        ea = find_next_op(ea, 'movsd')
        ea = GetOperandValue(ea, 0)
        return ea

[NoxiaZ]

Depending on what I need, I use a combination of IDA (static analysis,) Cheat Engine (simple live analysis) and x64dbg (intricate live analysis.)

For corpse position I found it easily through Cheat Engine taking note of my position, dying and releasing. From there I sigged it and added it to my IDA pattern scan script.

    if function_name == 's_corpseMapId':
        ea = FindBinary(0, SEARCH_DOWN, '48 C7 05 ?? ?? ?? ?? FF FF FF FF 0F 57 C0 89 05 ?? ?? ?? ??')
        ea = GetOperandValue(ea, 0)
        return ea
    
    if function_name == 's_corpsePosition':
        ea = FindBinary(0, SEARCH_DOWN, '48 C7 05 ?? ?? ?? ?? FF FF FF FF 0F 57 C0 89 05 ?? ?? ?? ??')
        ea = find_next_op(ea, 'movsd')
        ea = GetOperandValue(ea, 0)
        return ea

Thank you so much for you answer, can't thank you enough for this.

I have a hard time coming from CE to pointer, so i can find it in IDA and create a pattern, guess i have a lot to learn there yet. - But now i know your approach, and that's very helpful

May i ask if you are using plugin to IDA for creating pattern scan script or you creating them you self? - I'm using GitHub - ajkhoury/SigMaker-x64: IDA Pro 7.0 compatible SigMaker plugin which have been working fine for me until now (Or that is what i thought actually)

After Mr.Sergey posted the pointer i went to IDA and trying to figure out how i could find it my self, but with no luck, couldn't find some indication of what i could search for.
Then i tried to sig it with the plugin, but either i got 0x0 pointer or a totally off pointer with the pattern it created.

I'm using https://www.ownedcore.com/forums/wor...r-offsets.html ([C++] Descriptors dumper & Find descriptor offsets) for pattern scan, funny enough i haven't been able to find any pattern scan in C# - And yet i don't totally understand how this works, so i decided to use what ejt made.
But you saying "IDA patter scan script" are you searching in IDA with the pattern or on the running program?

Anyways, i don't want to bore you more with how i'm messing around with it, but i would again like to thank you for you time answering, it have been really helpful to know the approach, so i know what i should look more into.

[Jadd]

First make sure you're providing IDA with an unpacked WowClassic.exe. The client you'll find in your Wow installation will be packed, meaning 99.99% encoded bytes and the remainder being the code to unpack itself. In IDA this is essentially useless to you. You will have to dump the unpacked client by letting the game load (unpack itself) then dumping it with external tools. I use Scylla for this.

You probably don't want to try sigging .data (static R/W variables section) directly, since the whole purpose of this section is for variables that will be modified. If you're attempting to sig an address in .data then you will need to look for something constant that provides a reference to it. The signature I provided is from .text, the constant/readonly (after unpacking) section containing executable code. Within that function you can find direct references to s_corpsePosition and s_corpseMapId.



I normally create signatures myself, even though it takes longer initially. I find it saves time in the long run, since a well made signature will generally be more reliable and last longer through game updates, client variations, etc.

[NoxiaZ]

I'm following the guide created by counted, using Scylla as well to dump the wowclassic.exe

Seems like i'm doing some of it right, what i have been doing is to located the pointer address in IDA, then click on the xref to go to function that are using the address, and then auto generate a pattern from there. (Select a few opcodes that it should generate a pattern from and then use the plugin, and verify that it looks okay)
The reason i'm using the plugin instead of doing it handmade it because i'm not sure when its static and when its dynamic opcodes so it have to be "??"
But really helpful with you explanation, it makes it way more clear on how it works, i appreciate that. - First i found it really hard to understand how it actually worked, but actually looks a lot easier then what i thought it would be creating patterns


The pattern i came up with, or the plugin is was "48 C7 05 ? ? ? ? FF FF FF FF 0F 57 C0 89 05 ? ? ? ? 0F 14 C6 F2 0F 11 05 ? ? ? ? ?" which i actually thought was right, but it gives me a wrong pointer which are "0x21C274C", actually the same as your pattern gives me, and now i wonder how it can work for you?

in your code you pasted earlier you wrote "ea = find_next_op(ea, 'movsd')" are you looking at the opcodes using C++ or is this IDA?

Again i can't thank you enough for this, and i'm sorry it lead to a bit more questions on your approach, but you are really good at explaining it

[Jadd]

You need to use wildcards where the bytes are expected to be different between patches. In most cases you should worry about references to data in other sections.

Take the following example (corpse map ID):


We know in different versions/variations of the client that the most likely operands to remain the same are instruction (mov) and value (0xFFFFFFFFFFFFFFFF or -1). The relative address will inevitably change if either: the variable's location changes; the .data section's virtual address changes; or if the code moves to a different address (because the operand 0x01479A55 is relative to the code address.) You will get a better feel for this once you spend some time with assembly. It's fine to use your sigmaker plugin, you should challenge yourself to come up with a signature beforehand and then see what the plugin comes up with.

So the signatured bytes will end up as 48 C7 05 ?? ?? ?? ?? FF FF FF FF. You'll want to do this for few more lines to ensure it is unique to this specific function. Both mine and your signature have two matches in the entire client, but it's not an issue since both functions reference the values we want.

find_next_op is a function I have defined in an IDA python script. It's self explanatory:

def find_next_op(ea, operand):
    ea = NextHead(ea)
    ea_end = find_func_end(ea)
    
    while True:
        if GetMnem(ea) == operand:
            return ea
        
        ea = NextHead(ea)
        if ea >= ea_end:
            return BADADDR

Where are you seeing 0x21C274C? It should be 0x21C2750 for corpse map ID in 1.13.3.32836.

[NoxiaZ]

That's a really good explanation of how it works, and it seems to be my lack of experience with assembly that are shown, its good to know that when creating the patterns i have to look for the "mov" instructions.
But this have given me a lot of new information about how to create patterns so i will defiantly try create them my self and use the plugin as a guideline.

Always hoped that i could come around without learning assembly, but guess it's time for that to change if i want more success with this.


I'm using https://www.ownedcore.com/forums/wor...r-offsets.html ([C++] Descriptors dumper & Find descriptor offsets) for pattern search and when i add the pattern "48 C7 05 ?? ?? ?? ?? FF FF FF FF 0F 57 C0 89 05 ?? ?? ?? ??" it come up with the pointer 0x21C274C as you can see on the picture here: offsets.PNG


Guess the next step will be creating a pattern scanner my self, which hopefully will give better insight.

Again, thank you so much for you time, this is really awesome! - I can't say this enough, i really appreciate the time you spend on explaining this for me.

[Jadd]

There's some issue with the dumper then. I couldn't tell you what without debugging it.

I'd just use IDA with the IDAPython interface. Personally I think a scripting language is better suited to dump offsets and IDA provides much more versatile functionality and information to take advantage of.

[ejt]

The reason for adding 0x4 to the offset in my dumper (previously, fixed in latest push) was because it reads from memory and I believe relative offsets are calculated from the end of the instruction but my dumper reads from the beginning. So it needs to add 1 (for the mnemonic) and 4 for the 32-bit relative offset.

Take this as an example
.text:0000000000FF9B5A | E8 61 22 C1 FF

My dumper reads relative offset FFC12261 from FF9B5A but the FFC12261 is actually relative to FF9B5A+5.

I could be wrong, still a noob in asm and such, feel free to correct me.

IDA is much better at offset dumping and all that good stuff, anything having to do with parsing the binary and getting juicy information. However this require you to dump the binary every patch, this is why dumping from memory is smoother if you just want your offsets.

[NoxiaZ]

There's some issue with the dumper then. I couldn't tell you what without debugging it.

I'd just use IDA with the IDAPython interface. Personally I think a scripting language is better suited to dump offsets and IDA provides much more versatile functionality and information to take advantage of.

I like that i don't need to dump wow before being able to get pointers, but i get your point - Might try to look into scripting with IDA, but for now i guess i have enough to learn.
I'll try creating my own dumper, but all this memory reading are a bit confusing with patterns.

But again, i can't thank you enough for all your time, it have really been educative.