I would like to protect my dll file from easy disassembly. I have found some programs like Dotfuscator, Crypto Obfuscator - but they aren't made for c++. Have you got any idea what program i could use or how to change my code to make it harder for hacking?
Most important for me, is to hide Strings from being seen.
There are C++ executable files protectors exist: E.g. SoftwarePassportTM (ex. Armadillo library). It uses different methods to prevent disassemble and debugging of the application. Now sure how it fits to single dll protection
Related
At the end of the compilation process, the program is in a .exe file in machine code. So shouldn't the machine be able to run it without having to install something like MS Visual Studio C++? Basically, I am making a program with mingw and want to share it with someone else. I do not understand why I can not just send them the .exe file. Clarification will be appreciated.
C++ compiles your code to machine code. If your program is self-contained, that is all you need. However, more complex running programs often relies on additional compiled code, which is made available to your program through a library.
Generally, libraries come in two "flavors" - static and dynamic. Static libraries are "baked into" your compiled code. This is not ideal, because multiple programs include identical code, leading to code duplication. Dynamic libraries, on the other hand, are shared among all programs using them, leading to more efficient use of space.
Installing runtime adds dynamic libraries for use by all programs compiled with C++.
Your program likely calls many functions from the standard library that you didn't write yourself. You need the runtime libraries for that. Your code probably also needs code run before main to setup the basic environment that's expected for a C++ program - the runtime libs do that for you. Also after main ends, various cleanup needs to happen according to the standard (and your program probably also depends on this) and the compilers runtime libraries take care of this.
Your code does not exist in a vacuum (it can, but then it's no longer a standard hosted C++ program). It depends on and relies on the standard runtime libs to provide the environment the C++ standard says you can expect.
I know it's impossible to reverse a dll into a c++ code so I would like to collect as much as possible details from it.
It's not my dll, so I don't have the source code of course. Which program should I use?
Well, if you are skilled you can disassemble the DLL and understand all of its functions. This takes a substantial amount of time, but if you do that you can reverse it back to source by hand.
Otherwise, you can start by using a tool like Dependency Walker to get the DLLs and functions it depends on, and the functions it exports. From there you can find functions that interest you, and use a disassembler like IDA to see what they do.
You can see the list of exported functions by using the dumpbin tool. If C++ functions are exported, you might be able to infer parameters by the name mangling.
You can extract all the resources from the DLL by just "opening" it as a file for resource viewing in Visual Studio. If the DLL is a COM based DLL, there's a small chance the Type Library is embedded as a resource inside it. And if you have the Type Library, you can #import it to reconstruct the header files for the public interfaces.
That's about as good as it gets.
You need a PE file viewer. This will tell you the exports from the DLL and you can get the data in the .text section to see the machine code.
I want to compile a bunch of C++ files into raw machine code and the run it with a platform-dependent starter written in C. Something like
fread(buffer, 1, len, file);
a=((*int(*)(int))buffer)(b);
How can I tell g++ to output raw code?
Will function calls work? How can I make it work?
I think the calling conventions of Linux and Windows differ. Is this a problem? How can I solve it?
EDIT: I know that PE and ELF prevent the DIRECT starting of the executable. But that's what I have the starter for.
There is one (relatively) simple way of achieving some of this, and that's called "position independent code". See your compiler documentation for this.
Meaning you can compile some sources into a binary which will execute no matter where in the address space you place it. If you have such a piece of x86 binary code in a file and mmap() it (or the Windows equivalent) it is possible to invoke it from both Linux and Windows.
Limitations already mentioned are of course still present - namely, the binary code must restrict itself to using a calling convention that's identical on both platforms / can be represented on both platforms (for 32bit x86, that'd be passing args on the stack and returning values in EAX), and of course the code must be fully self-contained - no DLL function calls as resolving these is system dependent, no system calls either.
I.e.:
You need position-independent code
You must create self-contained code without any external dependencies
You must extract the machine code from the object file.
Then mmap() that file, initialize a function pointer, and (*myblob)(someArgs) may do.
If you're using gcc, the -ffreestanding -nostdinc -fPIC options should give you most of what you want regarding the first two, then use objdump to extract the binary blob from the ELF object file afterwards.
Theoretically, some of this is achievable. However there are so many gotchas along the way that it's not really a practical solution for anything.
System call formats are totally incompatible
DEP will prevent data executing as code
Memory layouts are different
You need to effectively dynamically 'relink' the code before you can run it.
.. and so forth...
The same executable cannot be run on both Windows and Linux.
You write your code platform independently (STL, Boost & Qt can help with this), then compile in G++ on Linux to output a linux-binary, and similarly on a compiler on the windows platform.
EDIT: Also, perhaps these two posts might help you:
One
Two
Why don't you take a look at wine? It's for using windows executables on Linux. Another solution for that is using Java or .NET bytecode.
You can run .NET executables on Linux (requires mono runtime)
Also have a look at Agner's objconv (disassembling, converting PE executable to ELF etc.)
http://www.agner.org/optimize/#objconv
Someone actually figured this out. It’s called αcτµαlly pδrταblε εxεcµταblε (APE) and you use the Cosmopolitan C library. The gist is that there’s a way to cause Windows PE executable headers to be ignored and treated as a shell script. Same goes for MacOS allowing you to define a single executable. Additionally, they also figured out how to smuggle ZIP into it so that it can incrementally compress the various sections of the file / decompress on run.
https://justine.lol/ape.html
https://github.com/jart/cosmopolitan
Example of a single identical Lua binary running on Linux and Windows:
https://ahgamut.github.io/2021/02/27/ape-cosmo/
Doing such a thing would be rather complicated. It isn't just a matter of the cpu commands being issued, the compiler has dependencies on many libraries that will be linked into the code. Those libraries will have to match at run-time or it won't work.
For example, the STL library is a series of templates and library functions. The compiler will inline some constructs and call the library for others. It'd have to be the exact same library to work.
Now, in theory you could avoid using any library and just write in fundamentals, but even there the compiler may make assumptions about how they work, what type of data alignment is involved, calling convention, etc.
Don't get me wrong, it can work. Look at the WINE project and other native drivers from windows being used on Linux. I'm just saying it isn't something you can quickly and easily do.
Far better would be to recompile on each platform.
That is achievable only if you have WINE available on your Linux system. Otherwise, the difference in the executable file format will prevent you from running Windows code on Linux.
I've encountered a strange behavior in __declspec(dllexport) in my project.
I have a C++ project that uses classes, namespaces, try-catches and more cpp elements.
When exporting any dummy function in this DLL, no other C project will be able to load it with LoadLibrary (Getting error 'module not found').
Is it possible to load dynamically C++ dlls through C projects?
These projects are Windows Mobile projects, but they should behave the same as on regular PC win32.
I'm stuck on it and any help will be appreciated.
Thank you,
Emil.
LoadLibrary is completely oblivious to the language used to compile a module. If LoadLibrary says it can't find the module, then it's very likely the case that it really can't find it. Make sure you've specified the right file name. If you've included a drive and path, make sure they're correct, too. If you haven't included a drive or path, then make sure the file exists somewhere where LoadLibrary can find it. The places it searches are listed in Dynamic-Link Library Search Order. Also consider whether Windows Vista's directory-virtualization feature might be interfering.
Once the DLL is loaded, you may have any number of other issues in using the C++ DLL from your C code. The C++ compiler may have mangled the function names, so you'll need to provide the right names when you call GetProcAddress. The C++ code might use a different calling convention from what your C code expects, so you may need to change declarations in the C++ code, the C code, or both. If the C++ functions expect to receive pointers to classes or other C++-specific types, you'll need to change your C++ code so that its API is compatible with C. If your DLL allocates memory that the host program should free, or vice versa, you'll need to make sure that both modules can use the same memory manager.
All that is separate from the problem you're reporting, though, which is simply that the OS can't find your file. Focus on that first.
I found the problem. It was really a dependency dll problem. It was not found in the directory of the loading DLL.
Thank you all.
I have a C++ dll file that uses a lot of other c++ librarys (IPP, Opencv +++) that I need to load into matlab. How can I do this?
I have tried loadlibrary and mex. The load library does not work.
The mex finds the linux things (platform independent library) and tries to include them. And that does not work.
Does anyone have any good ideas?
loadlibrary should work. I use it all the time to call functions from dlls written in C++ with C wrappers.
What errors are you getting when you try to use loadlibrary?
Make sure that the exported functions of the dll are C functions, not C++ functions. If not, then write C wrappers.
More info on exactly what you are doing when using loadlibrary would be helpful.
As mentioned by others, you should first wrap your C++ library as a C library - mathworks used to advise not to use C++ code directly in mex (dlopening C++ core directly is complicated), maybe it is still true.
Your description is quite unclear, too: what do you mean by "mex finds the linux thing", but that does not work. Saying that it does not work is not helpful: the exact commands and error message are.
You could go for the Java approach (since Matlab runs on a JRE and can access Java objects/methods -- just be aware that the Matlab JRE is not as up-to-date as the latest JRE, the one I'm running uses Java 1.5) and use JNA to access your DLL.
Or, if you wrote the top-level DLL, you could go for the COM/ActiveX approach.
I've had good success architecting the interface to my C++ functions as COM/ActiveX libraries -- you don't have to bother with that .h stuff.
See the External Interfaces guide on COM clients, particularly the part about managing/converting data.
It would be extra work to add the COM/ActiveX layer, but would make your library more portable within the Windows world and probably more easily used in MATLAB.
If you have a lot of function calls to your DLL, the COM/ActiveX approach might be faster (not sure), but otherwise I think the JNA approach would be easier.