Looking for advice with FramescriptExecute internal call and patching invalid ptr menu

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 15 of 18
  1. #1
    hycolyte's Avatar Active Member Authenticator enabled
    Reputation
    17
    Join Date
    Nov 2019
    Posts
    45
    Thanks G/R
    19/11
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Looking for advice with FramescriptExecute internal call and patching invalid ptr

    Ida shows framescriptExecute as
    Code:
    __int64 __fastcall frameExecute(__int64 luaScript, __int64 scriptName, __int64 value)
    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.
    Attached Thumbnails Attached Thumbnails Looking for advice with FramescriptExecute internal call and patching invalid ptr-runscript-png  
    Last edited by hycolyte; 06-04-2020 at 02:37 AM. Reason: update

    These ads disappear when you log in.

  2. #2
    Icesythe7's Avatar Contributor
    Reputation
    213
    Join Date
    Feb 2017
    Posts
    153
    Thanks G/R
    8/104
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I do like this (classic 34600)

    Code:
    inline uintptr_t Base = reinterpret_cast<uintptr_t>(GetModuleHandle(nullptr));
    inline uintptr_t FrameScriptExecute = 0x31F360;
    
    inline void Execute(const char* com)
    {
    	reinterpret_cast<uintptr_t(__fastcall*)(const char*, const char*, int64_t)>(Base + FrameScriptExecute)(com, "karma karma karma karma karma chameleon", 0);
    }
    
    inline void Execute(const std::string& com)
    {
    	Execute(com.c_str());
    }
    Code:
    Execute("print('hello world!')");
    Last edited by Icesythe7; 06-05-2020 at 08:14 PM.

  3. Thanks hycolyte (1 members gave Thanks to Icesythe7 for this useful post)
  4. #3
    hycolyte's Avatar Active Member Authenticator enabled
    Reputation
    17
    Join Date
    Nov 2019
    Posts
    45
    Thanks G/R
    19/11
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Originally Posted by Icesythe7 View Post
    I do like this (classic 34600)

    Code:
    inline uintptr_t Base = reinterpret_cast<uintptr_t>(GetModuleHandle(nullptr));
    inline uintptr_t FrameScriptExecute = 0x31F360;
    
    inline void Execute(const char* com)
    {
    	reinterpret_cast<uintptr_t(__fastcall*)(const char*, const char*, int64_t)>(Base + FrameScriptExecute)(com, "karma karma karma karma karma chameleon", 0);
    }
    
    inline void Execute(const std::string& com)
    {
    	Execute(com.c_str());
    }
    Code:
    Execute("print('hello world!')");
    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 hycolyte; 06-06-2020 at 11:26 AM. Reason: blah

  5. #4
    king48488's Avatar ★ Elder ★


    Reputation
    1356
    Join Date
    Nov 2008
    Posts
    801
    Thanks G/R
    33/411
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Originally Posted by hycolyte View Post
    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.
    because they are all __int64

  6. #5
    hycolyte's Avatar Active Member Authenticator enabled
    Reputation
    17
    Join Date
    Nov 2019
    Posts
    45
    Thanks G/R
    19/11
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Originally Posted by king48488 View Post
    because they are all __int64
    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 hycolyte; 06-06-2020 at 08:38 PM.

  7. #6
    counted's Avatar Contributor Authenticator enabled
    Reputation
    198
    Join Date
    Mar 2008
    Posts
    179
    Thanks G/R
    10/104
    Trade Feedback
    0 (0%)
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Originally Posted by hycolyte View Post
    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.
    Last edited by counted; 06-06-2020 at 08:54 PM.

  8. Thanks hycolyte, stoneharry (2 members gave Thanks to counted for this useful post)
  9. #7
    Jadd's Avatar 🐸
    Reputation
    1448
    Join Date
    May 2008
    Posts
    2,386
    Thanks G/R
    77/286
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Originally Posted by counted View Post
    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.

  10. Thanks hycolyte, aeo (2 members gave Thanks to Jadd for this useful post)
  11. #8
    hycolyte's Avatar Active Member Authenticator enabled
    Reputation
    17
    Join Date
    Nov 2019
    Posts
    45
    Thanks G/R
    19/11
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Originally Posted by Jadd View Post
    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

  12. #9
    hycolyte's Avatar Active Member Authenticator enabled
    Reputation
    17
    Join Date
    Nov 2019
    Posts
    45
    Thanks G/R
    19/11
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    lol it took me way too long to correct my mistakes but I finally committed the unforgiveable.. gg Blizzard!
    Untitled.png
    Last edited by hycolyte; 06-07-2020 at 01:51 AM. Reason: to to too

  13. #10
    counted's Avatar Contributor Authenticator enabled
    Reputation
    198
    Join Date
    Mar 2008
    Posts
    179
    Thanks G/R
    10/104
    Trade Feedback
    0 (0%)
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Originally Posted by Jadd View Post
    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.

  14. #11
    Jadd's Avatar 🐸
    Reputation
    1448
    Join Date
    May 2008
    Posts
    2,386
    Thanks G/R
    77/286
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Originally Posted by counted View Post
    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.

  15. #12
    hycolyte's Avatar Active Member Authenticator enabled
    Reputation
    17
    Join Date
    Nov 2019
    Posts
    45
    Thanks G/R
    19/11
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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. How do I get back on track and do this properly?

    Code:
    std::string GameMethods::GetText(const char* varName)
    {
    	const auto result = reinterpret_cast<__int64(__fastcall*)(const char*)>(Offsets::base + Offsets::getText)(varName);
    	char buffer[256];
    	sprintf_s(buffer, "%I64", result);
    	return buffer;
    }
    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*?

    Code:
    __int64 __fastcall FS_GetText(const char *varName, __int64 notUsed, int gender, unsigned __int8 someByte)
    Last edited by hycolyte; 4 Weeks Ago at 03:07 AM.

  16. #13
    aeo's Avatar Contributor Authenticator enabled
    Reputation
    104
    Join Date
    Apr 2007
    Posts
    216
    Thanks G/R
    41/49
    Trade Feedback
    5 (100%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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

  17. Thanks hycolyte (1 members gave Thanks to aeo for this useful post)
  18. #14
    hycolyte's Avatar Active Member Authenticator enabled
    Reputation
    17
    Join Date
    Nov 2019
    Posts
    45
    Thanks G/R
    19/11
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Originally Posted by aeo View Post
    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 hycolyte; 3 Weeks Ago at 02:43 PM. Reason: update

  19. #15
    Jadd's Avatar 🐸
    Reputation
    1448
    Join Date
    May 2008
    Posts
    2,386
    Thanks G/R
    77/286
    Trade Feedback
    0 (0%)
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Just FYI the 6.0.1.18179 Mac build has all function names exported too and it's more up to date.

  20. Thanks hycolyte (1 members gave Thanks to Jadd for this useful post)
Page 1 of 2 12 LastLast
All times are GMT -5. The time now is 11:43 AM. Powered by vBulletin® Version 4.2.3
Copyright © 2020 vBulletin Solutions, Inc. All rights reserved. User Alert System provided by Advanced User Tagging (Pro) - vBulletin Mods & Addons Copyright © 2020 DragonByte Technologies Ltd.
Digital Point modules: Sphinx-based search