Don't understand how to rebase OS X Memory Offsets

[bugs181]

Title: Don't understand how to rebase OS X Memory Offsets

Okay, so I'm kind of back after almost a year. Once upon a time I was making an Lua Bot but since then decided of approaching this from a different way.

I've also gained a little (not much!) knowledge on how assembly works, etc.

The debugger of your choice makes ALL the difference in the world.

For the beginners out there like me, if you find that your debugger is too "complicated" or has too many "moving parts" for you to understand right away,
do yourself a favor and pick a lightweight debugger with as few of features as possible until you can learn the basics. For me, I suggest using Hopper Dissembler.
I think I remember reading that Hopper is OSX and Windows.


Back to the topic:

All addresses relate to WoW client: 5.0.5.16135
Using this thread we can gather some addresses: https://www.ownedcore.com/forums/wor...mp-thread.html ([WoW][5.0.5.16135] x86 Info Dump Thread)

The problem here is that I am not quite sure how OSX rebases their addresses. I do think that it's not random, because I can write to the same exact address after every relaunch, with the same result. For example,

0x4fc900={0xb8,0x01,0x00,0x00,0x00,0xc3} (Places a MOV instruction at one of the checks.)

#1
So onto my first question, are the addresses in the info dump thread the actual addresses of the sub routine or of the definition?
Since a lot of users here seem to point to RunMacroText for gaining an idea of the addresses, let's use that.

Searching for RunMacroText:
00d9f99d                                 db         "RunMacroText", 0                     ; XREF=0x658fae

This tells us that we can find the address of the routine at 0x658fae, let's jump to that.

Now we are inside a function with a lot of calls to another subroutines. On this version they all seem to be leading to the same place.

00658fae C704249DF9D900                  mov        dword [ss:esp], 0xd9f99d              ; "RunMacroText"
00658fb5 E8461A1600                      call       sub_7baa00

The subroutine sub_7baa00 is at address:

                                    sub_7baa00:
007baa00 55                              push       ebp                                   ; XREF=0x1b193d, 0x1b1949, 0x1b1955, 0x1b1961, 0x1b196d, 0x1b1979, ...

Is it safe to assume that the address: 007baa00 (sub_7baa00) is the one being used in the info dump thread or are they pointing to the "definition"?


#2
As you can tell these addresses don't collaborate with the info dump thread. What's going wrong here? Obviously some kind of "rebasing".

I have tried to do as many calculations as humanly possible to find out if I could figure out how to rebase the addresses but no luck.

At first I assumed that we could use the address of the start routine and subtract that from the RunMacroText subroutine address, but that didnt work.


#3
I have a piece of code, It's quite common on the forums, google, etc for unlocking Lua on OSX, I can't give credit because I'm not sure who the original author is.
I would like to understand it a little more. I am really interesting in understanding ASM because the power of what you can do is pretty neat. If a person understands ASM, they could make practically any application (even not their own) behave the way they want. There are injections, jump replacements, etc.

So let's dismantle this piece of code.

echo "set {char[6]}0x4fc900={0xb8,0x01,0x00,0x00,0x00,0xc3}" | gdb attach `ps ax|grep Warcraft|grep -v grep|awk '{print $1}'`

Let's not worry about the first part yet, but we do know that we're telling console to set some bytes to a character array and output that to stdout.

• gdb attach = Use gdb debugger and attach to the next part
• ps ax|grep Warcraft - Find WoW processes and print out the PID of WoW
• grep -v grep - Remove grep from the list of above processes.
• awk '{print $1}'` - Prints the character array from stdout earlier

Now onto the part I have the question, the character array from earlier is composed of 6 bytes.
In ASM, the first byte 0xb8 represents a MOV instruction, followed by another 5 bytes.
If you were to look at this in the debugger, something odd is happening.
It get's translated into MOV EAX, 0x1

Since my objective is to learn more about ASM, let's try to understand this a bit more.

MOV is basically a misnomer because data isn't actually being moved, but actually copied from one place to another.
What is EAX? I could only assume, it is the place to store the value 0x1.



Basically the instructions

004fc900  push ebp
004fc901  mov ebp, esp
004fc903  push esi
004fc904  sub esp, 0x14

get replaced with:

004fc900  mov eax, 0x1  ; XREF=0x209c93, 0x2072ae, 0x5b4f30, 0x3256d0, 0x31f260, 0x646650, ...
004fc905  db  0xc3 ; '.'
004fc906  db  0x14

What do the addresses 004fc905 & 004fc906 do?


Another question that kind of ties into the first, since I'm not sure what this address IS without rebasing it.
What subroutine is at the address 0x4fc900? Is it just a tainted check or is it CGGameUI__CanPerformAction?

<br>
Thanks for taking the time to read this and sorry for the long post.

[Cypher]

Maybe start here: http://yurichev.com/writings/RE_for_beginners-en.pdf

[bugs181]

Thanks for the link. Realistically I'm a fiddler though. I'm a college student with a full time job. I don't think it's possible for me to learn everything in that book any time soon. It's most likely an invaluable resource. I've seen you around on the forum quite a bit and I know you're a pretty smart person. Do you think you could perhaps at least answer the "rebase" question or is it something you don't know? Or perhaps don't care to know due to different OS or such.

As a side note, I think I answered my first question as I sat here thinking.
The address 007baa00 is the actual address of the subroutine for RunMacroText.
The DB instruction at 00d9f99d is basically just a string value for lookup.
The call at 00658fb5 is in another subroutine/function which we likely don't care about.