Asm Help Needed

[abuckau907]

007be110 push ebp
007be111 mov ebp,esp
007be113 mov ecx,fs[0x2c] tls_slot (learned from this forum..thanks
007be11a mov eax,[0x135D9Fc] tls_slot_number
007be11f mov edx,[ecx+eax*4] tls_pointer
007be122 mov ecx,[edx+0x10] ecx=?? Not sure yet...first object address?
007be128 sub esp,0x8 something about stack pointer? Should i read about stack pointer(s)?
007be12b test ecx,ecx
007be12d je short 0x007Be15C if ecx=0 call BadSpot15C
007be12f mov eax,[ebp+0x8]
007be132 mov edx,[ebp+0xC]
007be135 push esi
007be136 mov esi,eax
007be138 or esi,edx
007be13a pop esi
007be13b je short 0x007Be15C 'what is the condition for this jump??
007be13d mov [ebp-0x4],edx
007be140 lea edx,[ebp-0x8]
007be143 push edx
007be145 mov [ebp-0x8],eax
007be148 call 007BDF10 'this has no condition...goto and copy source..need to do*
007be14d test eax,eax
007be14f je short 0x007Be15E if eax==0 goto badspot
007be151 mov ecx,[eax+0x8] 'wtf? ECX wasn't used before this and is now being over-written..so the call to 007BDF10 must use it??

007be154 mov edx,[ebp+0x10]
007be157 test [ecx+0x8],edx
007be15a jnz short 0x007Be15E
007be15c xor eax,eax --------------- eax = 0 not good..so the calls to this line = bad ??
007be15e mov esp,ebp standard
007be160 pop ebp standard
007be161 retn standard
007be162 int3

I set a breakpoing on my health's memory address and then checked for code accessing that location. I got an address, 5c4e1C: mov [esi+F90],edx
where esi+0xF90 = my_health_location

In the line RIGHT AFTER the call to 007be110 (the asm above) is move esi,eax SO the EAX is being returned from the 007be110 function. and it's the base_address to my player..so 007be110 is like 'getPlayerBaseBy****' where **** is eithor Guid...or, not sure? Maybe it's like..getLocalPlayerBase and not as important to me (though that would be..something nice to know)
I see the line 007be15c xor eax,eax eax=0..so the code i didn't show(that puts my health into health memoryloc) doesn't check for esi==0, so..?that confuses me?
..but i don't know asm well enough..can anyone help explain it if they ..aren't busy? If you are too busy..close this thread and PLZ don't reply w/ 'go read' lol..for real, i'd rather it got 0 replies



Thanks in Advance,
Andrew

ps. I wrote down the other section of asm..so here are both parts..the one below is the one that actually change my health on the bottom line of asm. Thanks agin.

5c4def int3
5c4df0 push ebp
5c4df1 mov ebp,esp
5c4df3 mov eax,[ebp+0xC]
5c4df6 push ebx
5c4df7 mov ebx,[ebp+0x8]
5c4dfa push esi
5c4dfb push edi
5c4dfc push 0x2DC
5c4e01 push 0x9A21Bc
5c4e06 push 0x8
5c4e08 push eax
5c4e09 push ebx
5c4e0a call 0x007Be110 ------SEE ASM ABOVE-----
5c4e0f mov esi,eax
5c4e11 mov ecx,[esi+0xD0]
5c4e17 mov edx,[ecx+0x44]
5c4e1a mov eax,ecx
5c4e1c mov [esi+0xF90],edx esi+f90 = my_health_location, esi=player_base_address???*Most important question* I think

[Oowafas]

007be128 sub esp,0x8 something about stack pointer? Should i read about stack pointer(s)?

Reading up on how the stack pointer works would be a good idea. It's setting up the stack for local variables, so anything pushed onto the stack will go underneath the local variables.

007be135 push esi
007be136 mov esi,eax
007be138 or esi,edx
007be13a pop esi
007be13b je short 0x007Be15C 'what is the condition for this jump??

The last time the zero flag (checked by je) was set would have been on the:
or esi, edx
so we know that that'll only be true if esi and edx are 0.

007be148 call 007BDF10 'this has no condition...goto and copy source..need to do*
007be14d test eax,eax
007be14f je short 0x007Be15E if eax==0 goto badspot
007be151 mov ecx,[eax+0x8] 'wtf? ECX wasn't used before this and is now being over-written..so the call to 007BDF10 must use it??

The call doesn't have to use ecx, but that just means that it is now being used by whatever at [eax+8h], which is likely an object base and so ecx will be the descriptor field. The function 7BDF10h looks like it returns an object's address from it's GUID, based on the fact that it returns one thing in eax which is later used as a pointer and that it is passed 2 parameters (further reversing confirms this).

5c4e1c mov [esi+0xF90],edx esi+f90 = my_health_location, esi=player_base_address???*Most important question* I think

Yes, it looks that way. For the future, it might be a good idea to grab a book on reversing (check the book thread, there's a good one in there) and get some more experience with assembly/reversing in general before you come here to ask questions, you're likely to get flamed. The first few times you actually reverse something useful will be very slow but it'll get faster as you gain experience. AoA is a good place to start with asm. Also, read through other posts, Apoc posted an IDB with all kinds of symbolic information in it that would've saved you a lot of time.

[abuckau907]

007be122 : ecx = something
....
CALL 007BDF10
....
007be151 : ecx = something_else

logically, why would ecx be set to something, do some other stuff *not* involving ecx, then over-write ecx?

My thought was that was ecx was essentially being 'passed in' to the call at 007BDF10..it's not really a big deal, was just curious.

[lanman92]

ecx is used in __thiscall functions(class functions). So, 0x7BE122 is setting ecx to the base of the class, and if you look at that function being called, I bet you'll see a mov ecx, esi and then that function will use esi as the basepointer and restore esi after. Look up calling conventions.

[amadmonk]

007be135 push esi
007be136 mov esi,eax
007be138 or esi,edx
007be13a pop esi
007be13b je short 0x007Be15C

This is most likely checking for a null guid. Any time you see two 32 bit registers being or'ed as a jump condition in WoW, it's probably a shorthand way to check if one 64 bit value (ie, a guid) is null.

007be122 : ecx = something
....
CALL 007BDF10
....
007be151 : ecx = something_else

logically, why would ecx be set to something, do some other stuff *not* involving ecx, then over-write ecx?

My thought was that was ecx was essentially being 'passed in' to the call at 007BDF10..it's not really a big deal, was just curious.

Your thought was right. This is a "thiscall" method invocation and ecx is the "this" pointer, most likely (can't be 100% without IDA in front of me, but that's the most logical reason you'd see ecx set up before a call).

[abuckau907]

Ok..so basically i just need to look at more asm (...slowly).

1)So..normally to view a character's health:

UnitAddress = [obj_base + 0x8]

Char.Health = [UnitAddress + &H17 * 4]

SO why is the asm I'm looking at

2)Char.Health = [obj_base + &HFD0]


So...what the heck? I thought using the first way was the only way --> ie. why does a static offset work (_base + 0xF90)? I thought my char health location wouldn't actually be a set distance from the _base --> I thought that was the point of the UnitAddress pointer :S Someone told me in a previous post 'thats just how offsets work' ? But..why does 1 use a pointer and the other doesn't? Maybe the code I'm looking at doesn't actually return the obj_base but rather... I'm not sure? I think it's because I don't know how wow is storing all this info. For example, is there really a bunch of arrays for each property (like ALL object hp's are kept in an array(), ALL objects Energy are kept in an array() etc) OR ..from what I've seen on here, there is the 'object_manager' which contains a linked list --> But are there really arrays w/ each property? Probably not.... My guess that is in 2) it's not really obj_base+0xF90, but really obj_SOMETHING + 0xF90

[amadmonk]

So...what the heck? I thought using the first way was the only way --> ie. why does a static offset work (_base + 0xF90)?

The same data may be stashed in multiple locations. Often times there's a "correct" way to get data and a "quick" way (this is collapsing the whole concept of caching and cache coherency down to one sentence, so take with a grain of salt). The app may, at times, take shortcuts, and hackers may, at times, use those shortcuts. Still, the "correct" way to get unit health ("correct" in the sense that "that's how the app stores it based on the packet data, and that's the most unchanging way to read it") is to walk the descriptors based on the known index into the unit fields. If you reverse the packet receive code, you'll see that the values are unloaded into a flat array, not poked willy-nilly into some bigger struct.

But are there really arrays w/ each property? Probably not.

You are correct. There are not. SOME data is cached, but not all. I do not believe that there is a unit health cache.

[abuckau907]

Hmm...so when I started i set a bp on my player's health_addr --> Maybe that's why it's _base + 0xF90...= something to do w/ showing my hp on the gui label instead of...not sure? ( I *think* I know what you mean by cache coherency, ie. is the data up-to-date?) so I just tested...and you can get every npc's health using _base + 0xF90....what's up with that? ie. Why are there 2 copies of everything's health:

.hp = [unitAddress + 0x17*4]
.hp = [_baseAddr + 0xF90]

I just checked and these 2 locations are NOT the same:
healthLoc1 = MyBase.BaseAddress + 0xF90
healthLoc2 = UnitFieldsAddress + 0x17 * 4
again, they are NOT the same..and this works for every npc object..so they ALL have 2 copies of their current health? Hmm..1 answer= a million more questions Has anyone else done this before? Or am I the first person to set a bp on my health_addr and to see the offset 0xF90 :S Thanks Amadmonk for the replies, much appreciated.


ps. lanman, in this specific example it doesn't have to restore esi because it's over-written as soon as the call returns? ..but I know what you mean, thank you. :P That isn't really important because i see you were trying to tell me often they'll push values, use registers, pop values back, to preserve.

[amadmonk]

Again, the health may be stashed in the unit object because it's easier/faster/simpler for the WoW code to retrieve it via a static offset, than by scaling the unit fields. Or, it may simply be a compiler artifact.

Ultimately, you can use either method to retrieve unit health if you want, but the descriptor scaling (UnitFieldsAddress + 0x17 * 4 in your example) is more reliable and will remain unchanged for longer, most likely.

[Cypher]

Again, the health may be stashed in the unit object because it's easier/faster/simpler for the WoW code to retrieve it via a static offset, than by scaling the unit fields. Or, it may simply be a compiler artifact.

Ultimately, you can use either method to retrieve unit health if you want, but the descriptor scaling (UnitFieldsAddress + 0x17 * 4 in your example) is more reliable and will remain unchanged for longer, most likely.

Actually, all the stuff in the unit fields can be accessed via an offset of the object base. It's the same for a lot of the other structures that units have pointers to (movement info, unit info, etc).

It seems that whatever compiler they use takes the data and "dumps" it at the end of the object at the same location every time.

So, if a member is CUnitInfo* pUnitInfo, when that is allocated (upon object creation) it seems to just get dumped some place after the end of the object. Whether this is a compiler byproduct or something else is something I currently don't know, but its a consistent effect throughout a lot of WoW's classes.

[amadmonk]

I guess it would make sense to keep the memory for an object contiguous rather than frag the heap with a zillion objects + descriptors. Does the data stay in sequential, ulong-sized chunks?

Edit (you're welcome, Apoc :P): Argh... I wonder if they're doing that old (bad) C trick where you tack a variable-length array at the end of an object in order to keep the memory contiguous...

struct Foo {
int objCount;
OBJECT objects[0];
};

[abuckau907]

edit:
It's kind of weird because I'm using structure in my code that I know nothing about :P ie. I saw wowradar code and learned enough about it to...copy it basically. So now I'm using tons of offsets in my code w/o knowing where/how to find them in asm..so next patch, I'll be in line asking for all the new offsets. I'm trying to figure out the scructures myself..where would you recommend looking next: probably at lua? I really don't care about injection, hooking, etc...The first thing I want to do is learn about all the object structure (ie. I still don't have a clear picture about how many object types there are. for example, Player, Mob, Npc, Node(like mineing vein, herbs..etc?) / what baseclasses they come from. So basically I want to start learning the structs..would you recommend I reverse the lua functions...I mean..from what I think lua is really just used to script the use of core functions in wow, for example: UseItemByName() is a lua function, but somewhere in wow there is also a function to use an item...and the lua functions just ...make it easier/prettier to access them? So if I want to know a core wow structure, such as wowPlayerObject, i need to destruct a lua functions that uses that structure..such as... *something like* UpdateStats(player,health,energy,etc) and inside update stats i'll get all the offsets I need (well..as many things as the function updates) so now it's just a matter of selecting my lua functions and disassembling them? Any thoughts? I see cypher says that ppl around here are kinda....script kids(auto it..:|)so lua is a script language..so they know it, they think..and just ask too many questions like 'how do I use item, know how many items in stack, etc etc' --> I'm not asking that...just ..is my idea semi-correct (about how to get offsets/structures from debugging lua functions)

uoy htiw eb ecaeP

anti-flame edit: I'm not saying Cypher said some ppl here are script kids, he said something like..im too lazy to look it up, bye.

[amadmonk]

I mean..from what I think lua is really just used to script the use of core functions in wow, for example: UseItemByName() is a lua function, but somewhere in wow there is also a function to use an item...and the lua functions just ...make it easier/prettier to access them?

Essentially this is correct. VM-based languages like LUA can't "do" anything without native helpers, so WoW has both a LUA function to "UseItemByName" and a cfunc (C(++) function) to do the same thing. Usually the LUA func is just a thin wrapper around the cfunc. However, I don't wanna talk outta my ass on that, since Cypher et al are much more expert on WoW's LUA interface than I am.

But yes, reversing LUA functions is a good place to start. Inevitably you'll start seeing recurring patterns (for instance, checking to see if a unit name is null, etc.) and you'll see where the "real" cfunc gets called.

[abuckau907]

ya..I think the first one I noticed was 007be110 (..the only one so far actually..haven't been working on this really) but..i'm 99% sure 007be110 is GetObjBaseByGuid() which returns the obj_base in the eax register (..i just made another post about this 2 secs ago so I hope it wasn't wrong) anyway...thanks! I think i know what I'm doing next Have a good weekend.