looking for group

[abuckau907]

Anyone here care to group up? Just got a graphics card capable of playing...leaving wow and going to newer mmorpg.



basically it's something along the lines of gc_sub_UpdateHealth()

at the bottom, eax is new_health_value, ecx = address of health loc


a few lines up you should be able to figure out where Object_Base is. Or, a substructure in Object. Anyway, since there is so little activity here, I'm probably not going to make [info post]s just because I'd rather not draw attention to myself. Pm me if interested. (I'm not looking for code. yes, if you know a bunch of stuff about the game, that would be very helpful.) Currently I've got 1-2 patterns and am trying to find the object list. Will have better idea of list structure in about a week hopefully.

[Cromon]

Why are you hiding the adresses but leaving the jumps? And are you seriously using win xp?

[abuckau907]

@Cromon stfu. Assume I answered your questions, then what? POINTLESS POST. Sorry I can't afford a new pc and my current one runs xp better than 7 or 8. Thanks for reminding me dude.
edit* edited image and re-uploaded. Covered up jmps. You could still FindPattern() and know where it is...technically it's more work tho.
I didn't cover up ALL of the image so if you looked at it, you would know it's valid. Yes, if you try, you can figure out where this code is.
(I wasn't trying to hide it. That was partially the point. so you know it's actually from swtor, just not a random screenshot)

Anyway,

mov    [ecx], eax //   ecx = obj_health_addr, eax = new_health_value

(above it, we see)
mov ecx, [esi+30] // esi + 30 ....is a health addr, what is esi? probably obj.base , obj.substructure? or ?

recent addr this instruction accessed:


a few of the 'obj' or 'obj.subob' are the same [/strike]size[/strike]distance apart, so it's probably a list. For now we can patch to get this list, then once we know more about it, we shouldn't have to patch.

edit* mis-typed eax/ecx. Correct now.

^^ That could all be wrong! the point is, I'm working on it.

[abuckau907]

edit: I actually browsed the mem region where localplayer.health is stored --> the information around it looks like more 'health data', not more 'player data',
ie. its in a big array of 'unit healts' , I think? I noticed that at the addr like 20 or so bytes before my health addr was some 4 bytes changing with my health value.

There appear to be quite a few of these similar chunks around my health addr. So I think this is an array of 'health data', not inside my 'local player structure'
Continuing.

*long red line = my health value
*short red line = magical health offset
*looks like it's an array of similar data -everything appears to be 8 or 4 aligned. even 00's.

[Cromon]

Lol, dude dont get mad . There is no reason to hide anything at all (besides that you are still showing that the cursor was at 0xB4F474)...

Some remarks:
You wrote:

mov    [ecx], eax //   ecx = obj_health_addr, eax = new_health_value

(above it, we see)
mov ecx, [esi+30] // esi + 30 ....is a health addr, what is esi? probably obj.base , obj.substructure? or ?

about esi:
Assuming that swtor was compiled with cl.exe you end up having this passed in ecx and then "stored" in esi, that gives you the typical __thiscall prologue:
push ebp
mov ebp, esp
; bunch of opcodes
mov esi, ecx

If you go a little bit up you find:

mov eax, [esi]
mov edx, [eax + 8]
mov ecx, esi
call edx

That shows you that esi is an instance of a polymorphic class with a virtual method table (which you can easily read at runtime) and its second virtual function gets called there. In fact it seems to be an instance of a rather complex class, a lil bit above you see that the 50th virtual function gets called.

About short red line and magical health offset. Im pretty sure offset is not the right word here. I guess you are using 32 Bit (as you are using XP) and not 64 Bit thus an offset of 0xAAA638DE is already per se in kernel mode memory and oviously not an offset.

[abuckau907]

That shows you that esi is an instance of a polymorphic class with a virtual method table (which you can easily read at runtime) and its second virtual function gets called there. In fact it seems to be an instance of a rather complex class, a lil bit above you see that the 50th virtual function gets called.

I don't know about virtual functions / compiler implementation yet

and I didn't mean offset -- but for *some reason* idk yet, your health value is stored larger than it actually is? ie. * 2 or something. Apparently, around 60 locs before your health addr, there is some value which is directly related to calculating health. ie. when health changes, this value changes also. <--I think the 'conversion' math is in my first screenshot, but I've never dealt with xmm0, xmm1,xmm2 etc.


question:

mov ecx, [esi + 30]
...
..
mov [ecx], eax // ecx = health addr

so, esi = object.base , and at obj.base+30 is a pointer to obj health??