However I'm not getting a response when I try to call this internally from a DX12 hook
Code:
const auto wowBase = uintptr_t(GetModuleHandle(NULL));
typedef int (__fastcall* framescriptExecute)(const char*, const char*, int);
const auto pframescriptExecute = framescriptExecute(wowBase + 0x532280);
pframescriptExecute("print(\"hello\")", "hello.lua", 0);
update: I tried calling the framescriptToLString function to prep the command, but now I'm thinking it's just that the injected dll is moving the address I need to call further down. I setup a little test to call it out of process, but I'm getting an access violation.
Last edited by GlittPrizes; 06-04-2020 at 02:37 AM.
Reason: update
Epic! I still don't understand why Ida shows all __int64 for the arguments and return value, but I'm guessing if I actually knew how to reverse, I'd look at the disassembly for a better hint as to what the signature is instead of just hitting F5 and renaming stuff.
Last edited by GlittPrizes; 06-06-2020 at 11:26 AM.
Reason: blah
Epic! I still don't understand why Ida shows all __int64 for the arguments and return value, but I'm guessing if I actually knew how to reverse, I'd look at the disassembly for a better hint as to what the signature is instead of just hitting F5 and renaming stuff.
Well I still don't get that part, but I don't gotta get hung up on it I guess. It seems I wasn't far off from having something working in the first place - I mainly had the wrong offset. I followed the dump from memory guide to set everything and the offsets I have are ahead by a very exact amount. I couldn't find anywhere that says to offset my addresses to account for something something, so I'm confused here as well. I used the default Ida analysis options, loaded resources, loaded manually, checked yes to everything except the debug symbols and my offsets are off by a very suspect amount.
I have what I need to move forward, it's just the curiosity at this point that wants to know why this and why that. Sorry this has become another handout thread I don't deserve, but I hope I eventually get set straight or find out these little details. I just find it funny that the stubbornness of people like me is apparent now because in the past I've been doing things like just dumping the exe without fixing imports and then quickly hitting F5 and using the known tricks to get the offsets I need. If I had actually read the entire dump thread I'd have been diffing to grab the function names instead of trying to do things like doctor up old scripts found on OC to rename a portion of the functions. I guess I had to learn the hard way to do some fairly simply things.
edit: Maybe I'm not even on the right trail, but the only thing I can find on the web is a small bit of info about the default segment base size. This could resolve part of my question, but I've read through so much of this section I'm surprised I've never come across anything related.
Last edited by GlittPrizes; 06-06-2020 at 08:38 PM.
Well I still don't get that part, but I don't gotta get hung up on it I guess. It seems I wasn't far off from having something working in the first place - I mainly had the wrong offset. I followed the dump from memory guide to set everything and the offsets I have are ahead by a very exact amount. I couldn't find anywhere that says to offset my addresses to account for something something, so I'm confused here as well. I used the default Ida analysis options, loaded resources, loaded manually, checked yes to everything except the debug symbols and my offsets are off by a very suspect amount.
I have what I need to move forward, it's just the curiosity at this point that wants to know why this and why that. Sorry this has become another handout thread I don't deserve, but I hope I eventually get set straight or find out these little details. I just find it funny that the stubbornness of people like me is apparent now because in the past I've been doing things like just dumping the exe without fixing imports and then quickly hitting F5 and using the known tricks to get the offsets I need. If I had actually read the entire dump thread I'd have been diffing to grab the function names instead of trying to do things like doctor up old scripts found on OC to rename a portion of the functions. I guess I had to learn the hard way to do some fairly simply things.
edit: Maybe I'm not even on the right trail, but the only thing I can find on the web is a small bit of info about the default segment base size. This could resolve part of my question, but I've read through so much of this section I'm surprised I've never come across anything related.
I think you might be missing the concept of Address Space Layout Randomization or ASLR. Sometime ago Microsoft added a security feature to Windows operating system that give every executable loaded a random Address base, before that every executable got an address base of 0x40000. So once you get the memory dump loaded into IDA you need to ReBase the address space from the random base it had when you dumped it from memory to ZERO, ( actually 0x1000) IDA MENU->Edit->Segments->Rebase ( enter 0 ). After IDA translates the address space to the Zero base you are half way done. You then find the subroutine offset you are interested in and record that address ( really an offset from the beginning of the binary). Once you launch the wow.exe and you attach to it you need to get the current randomized base address ( it will be different each time you close and reload wow) you then add the zero base offset you got from your static IDA analysis to this current randomize base address and now you know the location of the subroutine you are trying to call.
I think you might be missing the concept of Address Space Layout Randomization or ASLR. Sometime ago Microsoft added a security feature to Windows operating system that give every executable loaded a random Address base, before that every executable got an address base of 0x40000. So once you get the memory dump loaded into IDA you need to ReBase the address space from the random base it had when you dumped it from memory to ZERO, ( actually 0x1000) IDA MENU->Edit->Segments->Rebase ( enter 0 ). After IDA translates the address space to the Zero base you are half way done. You then find the subroutine offset you are interested in and record that address ( really an offset from the beginning of the binary). Once you launch the wow.exe and you attach to it you need to get the current randomized base address ( it will be different each time you close and reload wow) you then add the zero base offset you got from your static IDA analysis to this current randomize base address and now you know the location of the subroutine you are trying to call.
You'll notice rebasing to zero will cause a lot of constant, non-reloc'd values start appearing as references. For example, some movement flag comparison (cmp eax, 0x10000) will now appear as (cmp eax, offs_0x10000) and it also confuses the hell out of IDA, defining the value at 0x10000 as a DWORD when it may be something else entirely. The best option is to leave it as the PE base address, it will drastically improve the analysis output.
You'll notice rebasing to zero will cause a lot of constant, non-reloc'd values start appearing as references. For example, some movement flag comparison (cmp eax, 0x10000) will now appear as (cmp eax, offs_0x10000) and it also confuses the hell out of IDA, defining the value at 0x10000 as a DWORD when it may be something else entirely. The best option is to leave it as the PE base address, it will drastically improve the analysis output.
I will just scrap the little bits I have and reanalyze fresh then if that's the best approach. I will also do my duty to still better understand the reversing side of things instead of just marching on without a clue though. To summarize, a few let's say highly repped OC users here have basically handed me the intel I need to take my first baby steps which I'm very grateful for. It's the kind of thing that could be implemented day one for someone fresh, but I guess it's good that I've been off and on with the in-process research over time because I'd say the result is I'm better equipped for the task ahead.
I had been working on a pixel bot previously, but all said and done, I realized it was kind of too dumb to do my bidding. I'm not sure about the fascination.. I'm obsessed with the idea of some imaginary dude collecting fake gold and goodies in a game. I'm rambling because I'm excited of what lies ahead, but most importantly thanks to all for the guidance. When my user handle is polluting the top two threads about something that is already on OC if you do your homework, I would have expected to be exiled or something instead of people dropping fat hints for me and others. Big win for me here
You'll notice rebasing to zero will cause a lot of constant, non-reloc'd values start appearing as references. For example, some movement flag comparison (cmp eax, 0x10000) will now appear as (cmp eax, offs_0x10000) and it also confuses the hell out of IDA, defining the value at 0x10000 as a DWORD when it may be something else entirely. The best option is to leave it as the PE base address, it will drastically improve the analysis output.
Thanks for that info Jadd. I normally do my IDA analysis on the un-rebased binary and after that is complete rebased it so my scripts generate 0 based offsets. I will change that and leave the binary un-rebased and figure out how to get the base address in ida and do the math in my scripts.
Thanks for that info Jadd. I normally do my IDA analysis on the un-rebased binary and after that is complete rebased it so my scripts generate 0 based offsets. I will change that and leave the binary un-rebased and figure out how to get the base address in ida and do the math in my scripts.
Dump the process with ASLR disabled and it will always be 0x140000000, and/or you can adjust your script to rebase it by FirstSeg() or idc.get_first_seg() in IDAPython.
I've been playing around with the WoW API, and I'm struggling to get a return value using GetText. I think I have the right offset, so my signature must be wrong. I don't know how to avoid a dangling pointer when dealing with c_str->string, so I'm doing adventurous things like using sprintf:confused:. How do I get back on track and do this properly?
edit: after looking at other examples of this function, I think I'm looking at Script_GetText and not the Framescript version. This what Ida shows for what I assume is the actual function I want. Do I just cast the address it returns to char*?
You need to find the clean mac IDB. Most of these functions have no changed. It will also help you compare and search the current versions. I do not have it uploaded anywhere
You need to find the clean mac IDB. Most of these functions have no changed. It will also help you compare and search the current versions. I do not have it uploaded anywhere
I have it (OSX 15662). It wasn't my first thought to go and compare to that, but once I did, I identified the function based on a unique string. I would be pretty confident that I have the right function except that it takes 4 arguments instead of the 3 I was expecting unless there was a recent change to the client. I'll have to compare to some other clients I have, but it seems like a valid candidate for FS_GetText when decompiling. I was expecting 3 arguments passed based on krycess's repos (not sure how to tag a user). I feel I'm pretty close instead of no cigar, so I'll keep trying to get a return value working. It could be just how I'm dealing with the lua command.
Update: Hells yeah! I got it working. I was real close yesterday, but I was doing std::to_string(getTextResultAddr) which was just turning the address to a string instead of that actual result.
Last edited by GlittPrizes; 06-16-2020 at 02:43 PM.
Reason: update