i am currently stuck in the process of trying to create a wrapper DLL for another DLL which i want to replace but then include in my own created DLL.
When the dll is getting attached by the main program i would load the original DLL and then setup a hook function that let's me decide what i want to send to the original DLL function.
I already have the basic structure to import the dll, but my problem is that i don't really know what the best way of doing it is, because i only want to hook one function and the others should still just work normally without me doing anything.
Is there an easier solution than defining every function and just redirecting it to the original DLL? And also how would i even make it that my DLL function is exactly the same as the original one? I got a basic prototype but i don't know if i need anything else:
typedef int(__cdecl *PROC_cef_parse_url)(
const cef_string_t* url,
cef_urlparts_t* parts
);
And i can call it probably like this:
PROC_cef_parse_url _cef_parse_url = (PROC_cef_parse_url) GetProcAddress(hModule, "cef_parse_url");
But because i actually have no idea if this works or not and have no experience in DLL creation and stuff like this, i wanted to ask if i need something else, or if someone can provide me with an easy example.
Related
This may be too broad a question, but I have a DLL that contains a UI. It is currently invoked by an EXE. What steps would I do to try and invoke the UI within the DLL? Or put another way, how would I go about teasing out the code that would invoke the UI as it happens in the EXE?
Looks like you have access to source for both dll and executable that uses it. so what you are doing is writing a host for that dll from scratch.
Create a MFC application from VS project templates (make it the same kind as main executable, dialog, single document, multiple document, etc).
Look at what function dll exports, also look at its headers and best of all -- documentation.
Search source code of main exe and find the places the dll functions are called.
Figure out what is being done and why.
Narrow down scenarios you want to reproduce (initialize dll, show basic UI and tear down)
Start reproducing that code in your example app.
Copy the dll call, see what parameters it takes, see how those are initialized, etc.
Fix errors as they come up.
Related to: How to find a functions address to hook/detour in an EXE file?
I have to detour a function defined inside the executable I'm injecting my code into. The application is Open-Source so I know everything about the function I'd need for hooking it.
In the accepted answer to that question, it says to hook some low level windows api functions first to get the address of the actual function I want to hook, question is, which windows API function should I hook?
Choose an API inside your target EXE that get called first when it runs. Load it to OllyDbg and trace until you find one.
I'm pretty new to WinAPI programming, and have written a Win32 application for screen capture. When I run the program, the cursor immediately changes to a crosshair and I can click and drag to capture a portion of the screen and save it to file.
However, I'd now like to modify my program so that it doesn't contain a main method (WinMain) and essentially turn it into an object class rather than an application class so I can call functions from other programs. I haven't been able to find a good resource on how to do this, as I believe WinMain carries out special functionality under the hood so I can't simply change the name of the method.
Can anyone suggest some good resources or tutorials that address this?
There are many ways to do that, but you have fist move one step back:
How do yopu expect your "program" (let us continue to call that way) to be called?
With which parameters and what return type?
Then, what kind of API do you want to expose? A C++ class in header? a C++ class from a static library?
A C function exported from a DLL? an COM object?
There are many sample on how a library or a DLL or a COM library looks like (just try google those keywords).
The simple way is most likely to set up a library or a DLL project (most IDE have wizard that provide empty skeletons), than paste in it the relevant code that you require to leave there, letting it be called from the exposed function or class method.
A more precise answer can be given only after you decided which "form" your "object" should have.
I have created a COM dll using ATL. When I attempt to use it within unmanaged C++ I find that I get a buffer overrun. I am currently testing using one simple method called OnInitIDA() and all I do within this is a cout statement and return. When I ran this the HRESULT returned would be 0 however it would not output the line I expected. By using the step over and step into functions of the debugger I found that rather than entering the code for OnInitIDA when called this actually went into another method called GetInclusionList. Once I placed a statement within this method and when the app was run this line was printed off. Does anyone have any idea why the wrong method would be invoked?
If it helps my code has been posted here: https://docs.google.com/open?id=0B3ehFEncKJH7ZDgxMGI1YjgtZTE2MS00ZTBkLWI2NzgtYzVhZjUxOWEzZGI0
This sounds like you've changed your interface since building your client.
It would be a good idea to clean and rebuild all your projects.
I found an answer to my question. Basically, when I created my dll project it inherited from IDispatch, however the interface I was using in the test app expected it to inherit from IUnknown. This meant the interfaces did not match, with IDispatch inheriting from IUnknown and adding a number of methods. Change changing these to match the dll worked.
I have used a lot of modal dialogs and they worked fine without the use of AFX_MANAGE_STATE, but recently I was working on a different project in which the resource dlls are different from the launching dll. I surfed the web and found out the above line and when I inserted it before launching the dialog, it worked. I guess that maybe since we have different dlls, we need to load the state of the main dll in order to launch the dialog, but I am not sure. I have not been able to find a good explanation anywhere on the internet. Could anyone please explain in simple terms what AFX_MANAGE_STATE does and why I suddenly had to use it.
Thanks.
Every .exe and .dll has an internal resource handle, pointing to your dialogs and other resources. If you call a function in your DLL, the current resource handle is pointing to the resources in the .exe, which is wrong and needs to be changed to the resources of the DLL.
This is what AFX_MANAGE_STATE does.
AFX_MANAGE_STATE is a macro which calls resource function so that resource would be looked up only in this DLL, and not the EXE/DLL from which particular function is called. This macro also causes AFX_MAINTAIN_STATE class to be put on stack. This class would, on exit of function, reset the resource lookup, so that EXE/DLL that called this exported function gets it resource searching back.
In C++ terms:
// Some exported function that launches GUI or uses other resources
int GetSomething()
{
AFX_MANAGE_STATE();
...
}
Would be something like (not exactly):
int GetSomething()
{
SetResourceSearchingToThisDLL();
AFX_MAINTAIN_STATE state_RAII;
//Use resource
// Compiler will put destroctor call for state_RAII object here
// which will mean AFX_MAINTAIN_STATE::~AFX_MAINTAIN_STATE()
// And that would call something like:
ResetResourceSearching();
}
Usage of this macro, within same DLL call stack wont hurt anyone, since Resource-Searching has some usage-counter, which will revert to caller (DLL/EXE resource) only if it reaches 0.
It is important to note that, not every MFC DLL has to use this macro. It is only if DLL is loaded by non-MFC client, may be by a C client, a C++ console based application, .NET client etc (yes, may be MFC Windows application client also).
If your EXE and DLL are made in MFC, using same MFC/Compiler/linker version and has one CWinApp object, you need not to use this macro.