I disassemled a game's DLL and want to insert some code.
I need asm code to call another DLL in the current directory(I'm on Windows).
The background is, that I want to be able to execute custom code in my DLL,
but I can't load the DLL. So my idea was to load the DLL via modified game DLL.
There may be a function in the game which gives me the current directory path the DLL's are but I think I won't find it.
The calls you are looking for are LoadLibrary, which will search in a selection of places including the current directory for the DLL and then load it, then GetProcAddress.
If the DLL makes any other Win32 calls it is probably already linked against kernel32.dll, so that's all you need to do.
It is arguable as to whether modifying the DLL or using DLL injection is faster in terms of how long it takes to write the code since you're going to have to reverse engineer anyway, however, one advantage of pure DLL injection is that all existing code remains unmodified in terms of the installation, making these modifications easier to undo should the user wish to "unpatch" whatever you are doing.
Microsoft Detours comes with setdll.exe and withdll.exe, those utilities will let you start an exe with a custom dll file.
Related
My setup that I created using Inno setup mainly registers some DLLs.
Now I would like to add some conditional behavior. A certain path shall be taken if another DLL is installed/registered on the system.
Is it possible to use Inno setup to detect whether a certain DLL is registered in Windows?
The DLL I want to check is not from me. The only thing I know is its name, but I don't know about any COM objects or CLSIDs.
There's nothing like "DLL registration" as such. Only COM objects are registered. So you have to know, what COM objects the DLL does register; and then check for those.
Only other thing you can do, is it to traverse whole HKEY_CLASSES_ROOT looking for an entry with the DLL. But that may take tens of seconds even on a fast machine.
I have a large fortran code-base of which I would like to move some parts to dll's. After doing some research I know how to build a normal fortran dll with my IDE of choice (code::blocks) and how to use it in another fortran program. However, I have run into a wall. As long as I only need to put procedures in the dll everything is peachy. However, what I want to do is to include a Fortran 2003 class in such a way that I can also use the class in my fortran program. The first problem is that a class needs to be imbedded in a module (which is slightly but importantly different from a normal fortran file for a dll). In itself, this is not a big issue for building the dll, but it is when trying to access the subroutines or class.
I currently have a stopgap solution which entails including a use statement in my program:
use mydllmodule;
and also placing the module file mydllmodule.mod in the module directory of my program.
Is there a nicer way of creating a fortran dll which contains fortran classes, and allows them to be accessed in the main program (without the use of compiler specific pragma's, since this code is compiled and run on my local windows machine for development, and compiled and run on an HPC for production). I am looking for a setup in which the life of the user can be as simple as possible (i.e. just put dll somewhere, maybe use a use-statement)
thanks
I need to make some exe file to load my DLL at startup...
What is the easiest way to do it?
I need this exactly, no any injectors or starters.
I though about adding one more code section into exe, rewriting to there entry point logic and placing DLL loading code, then NOPing original entry point and calling my custom made entry point function. Will this work?
Are there any other easer ways?
I also thinking about changing one of system dll name in hex editor to name of my DLL. Will this work? If my dll then load that replaced system dll?
Any thoughts?
Adding it to the PE's import table should be enough. Woodman's lists a few tools which can do it:
http://www.woodmann.com/collaborative/tools/index.php/Category:Import_Editors
I'm trying to interact with a .dll which will allow me to receive information from a variety of devices (Eye Gaze to be specific). The .dll is called ETUDriver and can be found at http://www.sis.uta.fi/~csolsp/projects.php however it does not come with an accompanying .h file.
I am struggling to actually load, interact and invoke functions from the .dll. A manual is supplied but it is of no help whatsoever with regards to actually setting up the code to start it off. There are three accompanying example apps (with source code) but only two of these work and one of which is in C# so is not helpful. The one that works however loads up the .dll via MFC and this is not a viable option with my code (which is intended to be used with many other projects and as such can't enforce MFC or any other libraries that are not as standard to projects).
Essentially, within the .dll is a series of classes which I need to create within my code and invoke the relevant functions of that class.
I've tried to use HRESULT hr = CoInitialize(NULL);
hr = CoCreateInstance(__uuidof(ETUDSink), NULL, CLSCTX_INPROC, __uuidof(IETUDSink), (LPVOID*)&pETUDSink);
if(pETUDSink)
{
pETUDSink->Start();
} however it always returns an error saying that the class is not registered. I can't use MFC to call the relevant .rgs file and am completely stuck on how to get this to work otherwise.
Is there a given format to doing this that I am unaware of and has anyone had experience in using the ETUDriver (or is able to get it working in C++ without use of MFC)?
Thank you for any help you can provide on this subject :)
I am not familiar with the specific DLL in question, but it sounds like you did not register the DLL on the target machine. You can do this by running regsvr32.exe or by calling the DLL's exported DllRegisterServer function or by using side-by-side assemblies. You need to do register the DLL on each machine that needs to leverage the COM functionality within it, so when you distribute your application, make sure that your installer registers the DLL if you go the regsvr32.exe route.
You can use the #import directive in Microsoft Visual C++ to load the information contained within the DLL without using a header file or rewriting it yourself based on documentation.
I'm trying to create an D application which uses a (third party) COM .dll so I can scrape a text box of another application so I can sound an error when a certain string shows up.
However the third party doesn't provide .lib, .def or .h files that go with the dll (atleast with the free trial version). I can create the .lib file with the implib tool but I don't see any of the library's functions in the created .lib.
Their (visual c++) samples use the #import directive to link it in however that is of no use for me ...
On a side note how can I get the proper interfaces (in a .di with boilerplate that does the linking) of the dll automatically? I ask so the correctness of the linkage doesn't depend on my (likely to be incorrect) translation of the functions. They do have a webpage which gives all functions but the object model is a bit chaotic to say the least.
From what I know, COM libraries only expose a few functions, required to (un)register the library and to create objects.
You can however view the interfaces and functions in a COM .dll using the OLE/COM Object Viewer. It seems it might be able to output header files (.h). Afterwards, maybe you could use htod as a starting point to converting everything to D interfaces.
The DMD distribution seems to include a .COM sample (chello.d, dclient.d, dserver.d), and at first glance it doesn't look like it would require any LIBs explicitly.
Unfortunately, I've never actually used COM in D, so I can't advise any further. I hope this helps in some way.
While I have yet to actually do COM work myself, I am trying to revive Juno over on Github/he-the-great. Part of the project is tlbimpd which is what will output a D file from a DLL.
I've tested the examples and successfully run tlbimpd. Please do try things out for your use and submit any issues.