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
Related
I'm using MSI to create a setup, it's all fine but I have a question that I got this:
Why do we get .dll and .DLL file? And what is the difference between them.
Thanks
There's no difference between them, just that the creator of the name and extension chose to name them that way. The Operating system considers them the same types of files. Same thing happens with .EXE and .exe, .AVI, .... Some organizations may consider it a naming convention.
On a Windows filesystem, there is absolutely no difference as file names are case insensitive.
The only time you will notice a problem is when accessing the filesystem through a file sharing protocol that is case sensitive.
That screenshot is Visual Studio Deployment Projects view and it appears it isn't smart enough to realize those are the same DLL's. I'd build the MSI and look at it in ORCA and see if it actually tried to package it twice and create a component rule violation in the process. It wouldn't surprise me at all but this isn't one of well known issues that I can recall at the moment.
In addition to Windows being case aware but case insensitive, fill extensions don't really matter that much either. A Windows dynamically loaded library (PE format) can be any extension as the LoadLibrary() function doesn't really care. Common extensions are .DLL, .SYS, .OCX and .DRV.
okay, so i dont really know much about DLLs. but i need to edit some of them. ones that seem like archive files.
such as: firefox's xul.dll, windows/twain_32.dll
when i tried to open them in .NET Reflector, it couldnt open them. and a really downvoted answer on here made me realize they can be opened with 7zip, and seem to have files inside.
i can extract the files, but cant edit the dll, and i dont know how to create a dll like this. i dont have visual c++ or basic, and i dont know if i could do this with them.
thank you in advance, or how to say
A dll file usually contains program code (that is: binary code you can not easily understand). Some dll files may also contain resources, which can be sometimes edited with a resource editor (such as ResourceHacker).
dll files are no archives and their primary usage does not include holding files. Resources normally are rather small data elements such as icons.
Edit: If you open a dll file in 7zip, you will see some virtual files (which are no real files but sections of the binary object file, see symbol table and relocation table in object file for example) along with a virtual folder .rscs (abbreviation for "resources") that contains the mentioned resources you can edit with a resource editor. Again, remember these are not files. 7zip only displays them in a way you may think of files.
The object code inside of .text, .data and .reloc contains binary program code and initialization data along with the reallocation table. It makes no sense to edit those information unless you use a disassembler, can understand the generated assembler code, know about the pitfalls of disassembling, make senseful changes and are able to reassemble the code.
Not that even if you did so, you'd apply the disassembler to the whole object file instead of single sections.
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.
I am in the midst of evaluating the benefits of changing our program from 30+ statically linked libraries to 30+ dynamically linked libraries. We hope by changing to DLL, it will reduce the link time.
One immediate problem is the requirement to add __declspec in front of all the classes to create the lib file for other dlls to link. Is there a way to get around that? Is there a flag in the compiler to force a lib generation so to make all classes inside the DLL available for export? If not, is there any existing script/program that will do that? That will certainly make the switch from statically linked library to a dynamic one a lot easier. If not, what is the rationale behind __declspec? Why not an option to make all dll functions exportable?
Thank you.
Perhaps it's too late, but have you looked into using a DEF file?
There is one another way to solve your problem.
You just need to create one definition file(.def) and export all the methods or class you want to share.
U will also have to set :
Properties->Linker->Input->Module Definition File -> add name of your created .def file.
Now use run time dynamic linking:
In project where you want to call the exported methods use LoadLibrary to get handle of your Dll and call the required method using GetProcAddress.
I'm racking my brain trying to come up with an elegant solution to a DLL load problem. I have an application that statically links to other lib files which load DLLs. I'm not loading the DLLs directly. I'd like to have some DLLs in another folder other than the folder that the executable is in. Something like %working_folder%\dlls - I'd rather not have dozens (yes ... dozens) of DLLs in my %working_folder%.
I'm trying to develop something that is part of the main app that will adjust the search path # startup. The problem I'm running into is that this new custom DLL path isn't in the system search path. When I start the app it crashes (STATUS_DLL_NOT_FOUND) because the necessary DLLs are not in the appropriate places. What I'd like to do is to check # startup if this new custom DLL folder is in the process environment variable search path and if not add it. Problem is, the application attempts to load all these DLLs before the app executes one line of code.
How do I fix this? I've considered writing a help app that starts first, adjusts the environment variables appropriately and the launches the main app via CreateProcess. This will work I'm sure of it but it makes things difficult on the developers. When they debug the main app they're not going to launch a helper app first - not that they could even do that.
I've tried the registry app path feature with no success. Same chicken and egg problem as before.
What can I do here?
I found Matthew's answer worked for me.
In visual studio 2012 goto your project properties and in
Configuration Properties->Linker->Input->Delay Loaded Dlls
add each dll file that you want to not load until needed.
Although it no longer needs to run before main, this is my code to set the new search path
class RunBeforeMain
{
public:
RunBeforeMain()
{
const TCHAR* dllPathEnvName= name of env variable to directory containing dlls
const TCHAR* pathEnvName= TEXT("Path");
TCHAR newSearchPath[4096];
::GetEnvironmentVariable(dllPathEnvName, newSearchPath, MAX_PATH);
//append bin
_tcscat_s(newSearchPath, MAX_PATH, TEXT("bin;"));
size_t length = _tcslen(newSearchPath);
//append existing Path
::GetEnvironmentVariable(pathEnvName, newSearchPath + length, 4096-length);
::SetEnvironmentVariable(pathEnvName, newSearchPath);
}
};
static RunBeforeMain runBeforeMain; //constructor code will run before main.
[Edit - after re-reading the question I see that the problem you're having is that the DLLs are getting loaded before main starts]
I'm guessing that those libraries are written in C++ and are loading the DLLs from the constructor of some objects in global scope. This is problematic. Allow me to quote Yossi Kreinin:
Do it first thing in main(). If you use C++, you should do it first thing before main(), because people can use FP in constructors of global variables. This can be achieved by figuring out the compiler-specific translation unit initialization order, compiling your own C/C++ start-up library, overriding the entry point of a compiled start-up library using stuff like LD_PRELOAD, overwriting it in a statically linked program right there in the binary image, having a coding convention forcing to call FloatingPointSingleton::instance() before using FP, or shooting the people who like to do things before main(). It’s a trade-off.
[Original answer below]
See this page for the search algorithm used for loading DLLs. You can use SetDllDirectory() to add a directory to the DLL search path.
You also should be able to add a directory to the PATH environment variable using GetEnvironmentVariable() and SetEnvironmentVariable().
Another option is to change the current working directory to the folder containing the DLLs with SetCurrentDirectory(). Just make sure to change the working directory back after loading the DLLs if you ever load any files using relative filenames.
My recommendation is to use delayload linking for the DLLs and call SetDllDirectory() early enough so it can find them when the methods/functions are invoked.