I have to decompile obfuscated dll which was written in Microsoft Visual C++ 6.0 DLL?
How can I do that? I have tried so many software .Net Reflector,JetBrains dotPeeks but they all seems useless :(
If you just need to use the functionality of the DLL, use LoadLibrary and GetProcAddress instead to dynamically load the library and obtain function pointers.
You can use Dependency Walker if you need to see what functions the DLL exports (but it would be easier if you just had a header file for it on hand).
Microsoft Visual C++ compile code into native x86 code (not CLR).
For decompiling native code into c/assembler you should use IDA Pro with the "hexrays" plug-in.
http://www.hex-rays.com/products/ida/index.shtml
Related
I asked this question yesterday about using the Cygwin compiler to produce a C++ DLL that can be used by .NET: Using C++ app in .NET
The solution was to compile the C++ application using Visual C++ rather than Cygwin i.e. I was able to call a C++ function from .NET.
Why am I able to do this in Visual C++ and not Cygwin? The code can be found in my linked question. Here is a screen shot of Dependancy Walker for the Visual C++ DLL in case it helps answer my question:
Name mangling schemes are different in gcc/mingw/cygwin and msvs. You'll have to use the pure-C interface if you want to share DLLs between compilers.
Alternatively, you could use .def files as is described in the bottom answer to this question: How to use libraries compiled with MingW in MSVC?
I work on the optimization algorithm so the performance really matters. The algorithm is about 8 times faster when compiled in VS 2010 compared to VS 2008. Googling shows that it is not my fault (see e.g. https://stackoverflow.com/a/5560184/890355). The problem is that the final project must be built under VS 2008.
The solution I tend to is to built my algorithm as DLL in VS 2010 and then link it to the main project. Is it possible to use VC++ 2010 run-time libraries with my DLL under VS 2008? If so, what is the least painful way to do it?
Any other ideas?
Thanks.
The runtimes are not an issue. Nothing stops you from linking your DLL against the VC2010 runtime and then using that DLL in other projects. It doesn't matter if those projects are built using Visual C++ 2008 or any other language.
The tricky part is designing the DLL interface. Simply exporting some C++ classes is risky since it exposes you to incompatibilities between the different compilers. I think your best bet would be to either expose a C-style interface or use COM. I think COM is the best approach, but if you're unfamiliar with the technology, then a C-style interface will work fine. (COM could also be over-kill if the interface is simple.)
If you ask for any other way to combine 2008 and 2010 libraries in one executable other than moving 2010 part outside into a DLL, than the answer is probably "there is no other easy way to achieve this".
But if you don't want to "VC++ 2010 run-time libraries ... under VS 2008" (that is building against 2010 libraries in old 2008 IDE), but "use a 2010-compiled DLL in your 2008-compiled program", it is perfectly possible.
The easiest way, as we do it in our projects, is to build (both .exe and DLL) against statically linked standard libraries (MFC, if you use it) and then use LoadLibrary in your .exe to load the DLL. In the DLL you can export (_declspec (dllexport)) a function (preferably inside extern "C" {} guards) and use it in the .exe through GetProcAddress.
Static linkage and explicit loading save you from a lot of inconsistency bugs caused by different runtimes.
If you are worried about DLL loading and function calling costs, you can try to make these calls as rare as possible (maybe by moving not only the algorithm, but also some more high-level logics into the DLL). See this issie too.
And you can build all your code in one IDE (2010) using native multitargeting (however you will still need to build you main app and DLL separately against v9 and v10 libraries respectively).
You can if you're careful, and the MS documentation provides some hints. I have answered this question before here:
Wondering if the lower version of visual studio can use the dll built using higher version of visual studio?
I have a third-party DLL that depends on MSVCR80 and allocates resources that I need to cleanup. The library does not expose a free-function for doing this. Instead, I need to load the same runtime library and manually call the free function.
As a workaround I'm trying to write a "wrapper" DLL that loads the correct runtime and exposes the free function. This DLL is created using Visual Studio 2010 and is dependent on a separate runtime library. Doing LoadLibrary("msvcr80.dll") fails with error R6034 which I guess is because of manifest issues.
Is it even possible to load msvcr80.dll using LoadLibrary? Do I need to create a manifest, embed it into the DLL and store msvcr80.dll in the same directory as my wrapper DLL?
I realize that this is a flaw in the third-party library, but I'm pretty much stuck with this version. Getting the vendor to fix this is most likely not an option.
Probably there are better solutions, but in case everything else failed you could find somewhere a copy of VC++ 2005 Express Edition (=free, no piracy is needed ;) ), which uses the version 8.0 of the compiler, and thus the same runtime of the defective dll.
Then you would build your wrapper dll with it, which would just call the free provided by its CRT (double check that you're using the dll version!).
Im developing a MFC DLL project in VS2008.
The dll compiles OK and I can call it fine from an GUI exe that a contractor has developed for me. Visual C++ Redistributables are required to be installed for my dll (and maybe the exe which is developed in C++ too)
Another company wants to licence my dll to use with their C++ exe. They have requested that my dll have no external dependencies. Is it possible to compile my dll to remove all external dependencies like the Visual C++ Redistributables?
Does setting /MT do this?
I have read Should I compile with /MD or /MT? which makes some sense but I am concerned about dll hell.
Can this create issues with exe calling my dll? I read somewhere about that the exe and dll need to be using the same Visual C++ Redistributables or something.
I am somewhat new to C++. Any advice appreciated.
You can link with the static version of the CRT (yes, /MT) but it is quite dangerous. You'll have to carefully review your exports. Make very sure that none of them return C++ objects, not even an std::string (or CString). Or any pointers that the client code has to release. This will go wrong badly because the client will have its own CRT copy and use a different heap. That will leak the returned object/pointer, crash the program on Vista and Win7 when their secure heap manager detects that the pointer doesn't belong to the heap.
It might be a matter of debate what exactly an 'external dependency' means. Having a dependency on the CRT is not exactly external. You will however have to supply them with a version of the DLL that was built on the same version of Visual Studio that they use. The CRT can only be shared if the version matches.
Why not you package all the dependent dlls into a installer package and release to your customer?
I have seen some of the software package does include the vc's dependent libraries....
I have a lot of legacy code which I currently compile using an antiquated install of Borland C++ 3.0.
There's a rules engine in this code that I'd like to extract and use in a C# .NET application.
The thing is, if I extract the rules engine into it's own DLL, I want to be able to call this DLL from both the existing legacy code which I don't have time to port, and from the C# .NET app.
If I build a DLL using the old Borland compiler, I can't work out how to reference it from the C# .Net project. DllImport fails with a BadImageFormatException. Googling on this exception indicates that most people encounter this problem when compiling a 64-bit capable program and loading something 32-bit into it. Thing is, I'm reasonably sure I'm generating 16-bit DLLs, and there seems to be no workaround for this.
I can download the newer Borland 5 compiler which has a 32-bit compiler and linker, but I'm still getting the same issue, so perhaps I have something wrong there too.
This is my C# calling code
[DllImport( "C:\\NSDB\\BorlandDLL\\BorlandDLL.dll", ExactSpelling = false, CallingConvention = CallingConvention.Cdecl )]
static extern int Version();
public frmHelpAbout()
{
InitializeComponent();
lblIssueVersion.Text = + Version();
}
This is my DLL code
int Version()
{
return 93;
}
My compiler flags and linker flags are all complete guesswork - I'm hoping that this is my main problem
I noticed my DLL code is not decorated with anything like __stdcall, extern "C" or whatever. I can't seem to find the correct set of symbols that Borland C++ 3.0 understands to force the kind of calling conventions I need.
So, the questions:
1) Will DllImport ever be able to work with code generated from Borland C++ 3.0
1b) If not, will I be able to port the code to work with the Borland C+ 5.5.1 compiler, and get DllImport to work with that?
2) Can I turn the problem around? If I ported the DLL code into .NET, would I ever be able to get the old Borland code to call it?
3) Do you have any other innovative solutions that will let me simply extract the code I need from this old Borland project?
As far as I know, DllImport will only work for unmanaged dlls that are the same word size as the .Net app. E.g. DllImport in a 64-bit .Net app will only work on 64-bit dlls, a 32-bit .Net app can only load 32-bit dlls, etc. I also don't think it's possible to get DllImport to load a 16-bit dll.
Some possible solutions come to mind:
Steve mentioned using COM. If you want to keep your .Net app in 64-bit, you could use COM to make things work like this: recompile your C code as a 32-bit dll, use .Net to write a 32-bit COM wrapper for that dll, then have your 64-bit .Net app call the 32-bit COM server, which would in turn call your 32-bit dll. MSDN has some info on interoperating with unmanaged code.
Compile both your dll and .Net app for 32-bits. DllImport should be able to load the dll then. (You might need to wrap your C code in extern "C", and run the TDUMP or DUMPBIN utilities on the dll to check for name mangling).
If you have all of the C source code, can you just forget about the Borland compiler and build the code with Visual Studio's C++ compiler?
.net will call COM and can be called as COM quite happily (for a suitably COM-adjusted value of happy), so if the old native code provides a suitable COM interface you could try using that directly (but that would need to be using a 32-bit build).
If you don't need everything to be in the one process, an alternative approach would be to build the code as a C++/CLI assembly and as a Borland DLL (if you have .c files, then you will need .cpp files that just #include the .c file in the .net project).
If you're using both 32bit .NET and 32bit C-DLL you should not have a problem. I'm almost 100% sure that you can not call 16bit code from a 32bit application easily (though I think I've seen solutions that do that - the word "thunking" comes to my mind here?).
If both .NET and DLL are 32bit, you should be alright with what you're doing above, but I remember that there was something about Borland DLLs which made them kind of incompatible with other "normal" C-DLLs.
The answer by Steve Gilham about COM can be ignored I think, as COM is neither necessary nor a good option in your case.