I did code a PE packer in C++, which does load an executable into his process space, fixes IAT and relocations, then calls the entry point.
My problem is that .NET is not supported: I did search about .NET PE format, and it is just a 32 bit executable with the entry point set to an imported function (_CorExeMain).
If I call it, windows just popups an error that tells me that I have not .NET installed.
I did also read that .NET PE executables have a special COM header in DataDirectory but I don't know how to handle it.
I hope someone could help me.
Thanks in advance
Obviously the idea you had does not work as-is for .Net.
Your "packed" executable is just a native executable whose code is an unpacker, and whose data is the compressed real executable. When running, Windows expects and gets native code.
For .Net executables, you must obviously do the same: write a .Net executable whose code is an unpacker, and whose data is the compressed .Net bytecode.
Related
My application store some data in data only dll files. Those dll files are loaded with LoadLibrary() when needed at runtime and then discarded with FreeLibrary() after finish using them. The main application access the data stored in the dll files using GetProcAddress(). The program is written in C++ and uses WinAPI calls, no MFC or other libraries. It has two versions x64 and x86. It works fine on most systems. My dll files do not call other libraries or depend on anything else. Each is a stand alone file.
Recently, I discovered the program does not work on one machine. this specific one has Windows 10 x64 installed on it. After investigations I found the following:
LoadLibrary() fails with error message "Could not find module". The dll is in same directory with main program.
I replaced the call to LoadLibrary() with LoadLibraryEx() and tried the following falgs:
LOAD_IGNORE_CODE_AUTHZ_LEVEL did not work. The dll could not be loaded.
DONT_RESOLVE_DLL_REFERENCES ... works?? But, Microsoft strongly recommends not to use it.
LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE ... loading the dll succeeds?? But, the call to GetProcessAddress later fails. the program could not access the data in the dll file. So this is not actually working.
I could not find anything wrong with this machine. All other programs are working fine.
I tried the x86 version on this machine and it worked fine using original LoadLibrary().
My installer is dual system and automatically installs x64 version when it finds x64 windows. Normal user can not simply switch to x86 when he gets such error.
My question is how can I eliminate this error and make my program works on any machine:
Should I call LoadLibraryEx() using DONT_RESOLVE_DLL_REFERENCES flag and ignore Microsoft warning?
Is there any way I can get my library loaded with simple call to LoadLibrary()?
If I call LoadLibraryEx() with LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE flag, as recommended by Microsoft, how can I access the data without calling GetProcessAddress()?
Thank you in advance.
I'm trying to write some code for an migration app, which can migrate all the apps from an old PC to an new PC. My part of job is to locate and restore COM for all apps。
For now, my question is:
1.Given an app, how to find all its relevant COM dll?
2.How to find all apps' COM dlls?
I'm very new to COM, please answer as detailed as possible:)
Any idea will be appreciated! Thanks in advance!
There are two ways to open a DLL: by linking with them directly, and by opening them manually. You can get a list of all DLLs of the first type by using the tool Dependency Walker (http://www.dependencywalker.com/). Be careful to use the right version; the 32-bit version does not play well with 64-bit applications and vice versa.
A list of DLLs of the second type, unfortunately, cannot be extracted automatically.
I have a 32bit/64bit COM DLLs in C++: mycom32.dll, mycom64.dll. Both of them are exactly the same but mycom32.dll is compiled for 32bit and mycom64.dll is compiled for 64bit.
That means that BOTH DLLs have the same UUID and the same CLSID!
Now, sometimes I want to use this COM from 32bit processes and sometimes I want to use this COM from 64bit processes.
Is it possible to load the correct DLL without creating two different CLSIDs and check during runtime if the process is 32bit/64bit?
It should be possible to register both of them without issue; this is part of what Registry Redirection is supposed to solve.
Here's a more detailed explanation of how this works.
I need to know whether a given .exe is 32-bit or a 64-bit, before I launch it. IsWow64Process is no use here, since there is no process yet. Is there some other API that will give me this information?
If you really only want to do this for EXEs and not DLLs, just use GetBinaryType.
Determines whether a file is an
executable (.exe) file, and if so,
which subsystem runs the executable
file.
This post will surely help you.
Is C# related but it will give you the idea.
This information is available in one of the headers of the PE File file format (the format used for exe's and dll's). The information in these headers can either be extracted programmatically (they are at a specified offset) or more safely queried via the Win32 API.
Alright, Liviu got the correct pointer for you.
I've written a C++ DLL that connects to a Sybase database using the native C library for Sybase. I can build and run the program on my C drive, and others can run it from their C drives, and everything works. But in some situations both my DLL and the Sybase DLL are located on the F drive instead of the C drive. In those cases my DLL apparently fails to load the Sybase DLL.
I'm a little unclear on how linking works, but based on my incomplete understanding my best guess is that the C-drive location of the DLL is what gets built into the final DLL, which is what causes it to fail when it runs from a different drive letter. Does that sound like a reasonable explanation? Any other reasons my DLL would fail to load the Sybase DLL when run from a different drive letter? Any idea how I can resolve this?
EDIT: Turns out this was the wrong question, but it led me in the right direction. The Sybase DLL uses an ini file to determine database connection details, and I had the path for that hard-coded to the C drive.
Generally speaking absolute locations are not used inside DLLs. Only the name of the DLL is stored.
The places where system looks for DLLs are descrived here: http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx
Though it IS possible to load a DLL by absolute path - with a techinique known as run-time DLL loading - but I suspect not many programs do so.
Is this .net and is the F drive a network drive? There are some security issues on some versions of windows when you do a copy of a .net exe to a network drive and try to run the code. The operating system won't let it run. I expect this is your problem.
is the location that your DLL and the Sybase DLL are stored on the PATH ?