How to call native functions from injected DLL?

Discussion in 'OT Technology' started by Nader_D, Aug 5, 2008.

  1. Nader_D

    Nader_D HAHAHEHHUH ---- POOOHhHhHHCHhh! OT Supporter

    Joined:
    Oct 31, 2005
    Messages:
    88,288
    Likes Received:
    0
    Location:
    Ottawa, Canada
    This question is for the OT super nerd crew,

    I have a dll which I injected into a process. The dll is able to access local memory of whatever it is injected to. For example,

    int *time = (int*)0x100579C;
    MessageBox(0, itoa(*time, buf, 10), "The time", 0);

    0x100579C is the offset to where Minesweeper keeps track of its time. The MessageBox will print it.

    Sticking the the minesweeper example, you can see that winmine.exe imports and experts from dozens of DLLs which provide their functions:


    [​IMG]

    So this is where my question comes in,

    I know the function name and the offset, but how I do call a function which is exported from another DLL? (for example, I want to call PlaySoundW from WINMM.DLL - what is it's return value type? what are the arguments?)

    I would assume it would require creating a function declaration, but for that I would need to know the signature... how do I find that out? And after the function declaration I would have to somehow relate it to the pointer, etc... :confused:
     
  2. Nader_D

    Nader_D HAHAHEHHUH ---- POOOHhHhHHCHhh! OT Supporter

    Joined:
    Oct 31, 2005
    Messages:
    88,288
    Likes Received:
    0
    Location:
    Ottawa, Canada
    Ok so I fired up IDA pro and got a function definition and it's signature. So now I have all the info I need to call it. How to I actually call the function using c/cpp?

    I assumed I can use an assembly block to pop the arguments onto the stack then CALL the location of the function... but there has to be a simpler way.

    Lets use this method as example:

    Code:
     BOOL __stdcall _imp__MoveWindow(HWND hWnd,int X,int Y,int nWidth,int nHeight,BOOL bRepaint)
    .idata:01001118 extrn [email protected]:dword
    
     
  3. skinjob

    skinjob Active Member

    Joined:
    Jan 6, 2001
    Messages:
    2,337
    Likes Received:
    0
    Location:
    Aztlán
  4. deusexaethera

    deusexaethera OT Supporter

    Joined:
    Jan 27, 2005
    Messages:
    19,712
    Likes Received:
    0
    So...building a virus, huh? :coolugh:
     
  5. Nader_D

    Nader_D HAHAHEHHUH ---- POOOHhHhHHCHhh! OT Supporter

    Joined:
    Oct 31, 2005
    Messages:
    88,288
    Likes Received:
    0
    Location:
    Ottawa, Canada
    Great link, thank you.

    What happens in the event that the function is provided by the .exe, not .dll?

    The explicit pattern requires loading a handle to a dll, requesting a function by name, then executing. How would the loading of the dll step be executed if the function in question resides in the .exe?
     
  6. skinjob

    skinjob Active Member

    Joined:
    Jan 6, 2001
    Messages:
    2,337
    Likes Received:
    0
    Location:
    Aztlán
    You could load the exe into memory using the LoadLibraryEx function with the DONT_RESOLVE_DLL_REFERENCES flag. There is no export table in an exe, so you'd have to figure out the offset to the function you're interested in yourself. You then use the handle returned by LoadLibraryEx as the base address to get the address of the function. But, there's no guarantee the function will work, since loading an exe this way doesn't load any of the exe's dependencies.
     
  7. Nader_D

    Nader_D HAHAHEHHUH ---- POOOHhHhHHCHhh! OT Supporter

    Joined:
    Oct 31, 2005
    Messages:
    88,288
    Likes Received:
    0
    Location:
    Ottawa, Canada
    What happens in the event that the exe or DLL is already loaded? As in, I am injecting an active process.

    The methods above seem like 'launcher' type injection.

    btw thanks for your help, learning a lot :big grin:
     
    Last edited: Aug 6, 2008
  8. Nader_D

    Nader_D HAHAHEHHUH ---- POOOHhHhHHCHhh! OT Supporter

    Joined:
    Oct 31, 2005
    Messages:
    88,288
    Likes Received:
    0
    Location:
    Ottawa, Canada
    I did a bit more experimenting, and turns out this pattern works, which is really cool:

    typedef UINT (CALLBACK* LPFNDLLFUNC1)();
    ...

    LPFNDLLFUNC1 lpfnDllFunc1;
    ...

    lpfnDllFunc1 = (LPFNDLLFUNC1)0x1003D1D; //memory address of DoAbout()
    uReturnVal = lpfnDllFunc1();

    Now I've noticed from calling a lot of these functions is the application hangs right after the function call. I would assume this is because the thread I am executing these function under doesn't get killed automatically?

    For example, in the DoAbout() case, Minesweeper will display it's About box, and after clicking 'ok', control is returned to Minesweeper main window, but it is hung.

    Is there proper pre and post call etiquette? I remember in assembly you had to push the next command on the stack, then the function call, so when the processor comes back from the function call it knows the next command to go to, which in most cases would just be the next location in memory following the call statement. Does this have to be done here, or does compiler handle this for me since I am calling from a c function?

    Edit: After some googling, it looks like CALL should handle this process for me, so the problem might lie elsewhere.

    Call the function Here, the processor pushes contents of the %EIP (instruction pointer) onto the stack, and it points to the first byte after the CALL instruction. After this finishes, the caller has lost control, and the callee is in charge. This step does not change the %ebp register.
     
    Last edited: Aug 6, 2008
  9. Nader_D

    Nader_D HAHAHEHHUH ---- POOOHhHhHHCHhh! OT Supporter

    Joined:
    Oct 31, 2005
    Messages:
    88,288
    Likes Received:
    0
    Location:
    Ottawa, Canada
    Hmm two days of searching and I'm still stuck :wtc:
     

Share This Page