Develop Reference

Tool to analyze the executable

is there a tool that analyzes the executable and detects:
- the programming language used (compiler),
- frameworks used (Qt, Gtk, .Net, WxWidgets etc),
- other useful information (compression, etc.).
I know it is quite hard to tell the programming language sometimes (especially in C or Pascal exes), but it is possible to tell the language or compiler used? (Delphi generates exes differently, VB6 too for instance).
It may be possible eg. with dependency analysis of the dlls, headers etc.
Thanks.

On GNU, you can use several tools to try to guess the informartion you want :
ldd to resolv shared libraries linked to the binary
nm to list symbols Imported/exporeted by the binary
strings, which can dump the strings embedded in the binary
objdump can be useful too
A hex editor can be useful too.
I guess there are similar tools on the windows plateform. Dumpbin.exe is something similar to nm, and depends.exe to ldd iirc.
Btw, java is often bytecode compiled, not native.

I have used in the past (uni) PEInfo, but it did not give information you want. After that I used reflector as I knew my dll/exe where .net
But I think there is no software to do that.
Workaround: Best thing you can do is look in the strings of exe (for example use Process explorer) and guess yourself.

Open your executable in a binary file viewer and look for strings that look like names of the functions. These strings are not always available, but in certain cases they are present. They can be used to resolve links with DLLs for example. After that google those strings. There is a chance that they will tell you something.

i dont think there is a possible way to do this correctly. Maybe some basic programming languages can be detected but nobody can detect frameworks used. There are thousands of frameworks.

How to do CRC check on executable loaded in memory?

I want to run a thread that checks the memory image of the current executable, for protection reasons. Any ideas how to do CRC on the current memory executable (WinAPI or .NET way)? My app is written in .NET.

Signing your assemblies will give you as good verification as you can get with relation to verify CRC of .Net assembly (see Rodrigo's answer).
If you are worried that someone will patch assembly at runtime you probably worried too much. It requires better understanding of runtime to in memory patch IL for a method that is already JIT'ed compared to simply disassembling your .Net code and fixing it up (including removal of your CRC checks).
If you doing it more for fun than you shoud be able to find base address where assembly is loaded and compute CRC of some sort... or see if pages are marked as modified...

I think that's going to be quite difficult in .NET. When an executable is loaded, it can potentially be split up and loaded into several different regions in memory. You'll need to acquaint yourself with the Window's Executable format:
http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx
as well as the Windows executable loading process.
You'll might also want to concern yourself with depenency dlls as well. You'll be making so many native calls, that you might want to consider doing this in C.
Not much of an answer, I'm afraid.

Any runtime check you do will have the following drawbacks:
False positives. Because this is .NET, you cannot assume the runtime doesn't modify your in-memory code. You may detect a hack where there is none.
Any run-time check you make will be no more secure than the code you are trying to protect. This includes any runtime mechanism you create in your app such as periodic CRC checks, sentinel processes, or even checking with a server where the request can be faked.
You will decrease performance in your legitimate application, where the pirated version will run better without all these checks
You will do nothing to solve patching your EXE.
I understand that you are just trying to make it as hard as possible, even though it's not 100% uncrackable. But the solutions you propose (and likely any solution you can implement yourself) will do extremely little to thwart any average cracker.
Because this is such a demanded feature though, I would look for 3rd party solutions where they have put forth the effort for a sophisticated solution which can be updated as cracking techniques evolve. I cannot recommend any personally though.

I am not aware of a way to do this in .NET.
If you are interested in protecting you executables, you can generate a new key with sn and add it to AssemblyInfo.cs, so that if the application is modified at least it will not run.

Jon Skeet's Miscellaneous Utility Library contains a method to compute the Adler32 checksum on a stream. Its usage would be:
MiscUtil.Checksum.Adler32.ComputeChecksum(stream);
As for creating a memorystream out of the assembly that is currently running... I don't know if that is even possible (or advisable).

String Table Resource in Native Executable

Using C#, can I modify the string table resource of a native windows executable?

As far as I know, there's no support for doing that in the .NET Framework. You'll probably have to p/invoke BeginUpdateResource(), UpdateResource() and EndUpdateResource() from your code.
You can find an example of modifying resources in unmanaged code here. Although it involves dialog boxes instead of string tables, it might give you a starting point.

P/Invoke dynamic DLL search path

I have an existing app which P/Invokes to a DLL residing in the same directory as the app itself.
Now (due to the fact that Canon produces one of the crappiest API's around) I need to support two versions of this API and determine at run-time which one I should use (old or new). Since the DLLs have the same name (the first one loads other DLLs with same names so just renaming the first one won't help me) I must keep them in different directories.
Hence my question: what options do I have to control what directory the DLL given in a DllImport declaration uses?
I guess I can start out by trying any of these two ideas:
1) Use "SetDllDirectory" to set my desired directory before doing the first P/Invoke and then reset it afterwards.
2) Load the desired DLL manually using "LoadLibraryEx" and hope that that will do the trick.
But are there any more ".NET:ish way" to try out first?
UPDATE: I realize that I can stuff all access to the DLLs in two separate .Net assemblies and then place each one of them in a separate directory with the corresponding API files. Then I can load the proper .Net assembly dynamically and the loading of the correct DLL whould happen automatically. Any reason that shouldn't work?
I can think of one: how would I go about debugging this stuff? It is possible to tell Visual Studio that an assembly (contained in my solution) shall be placed in a subdirectory and debugged from there?

My condolences, I've seen one of the APIs and it was indeed shockingly bad. The bigger problem is that you'll need to be able to convince Windows to find the DLL. They won't be in your .exe directory so the default won't work. Using SetDllDirectory() would work, using Environment.CurrentDirectory does too. LoadLibrary cannot work, the P/Invoke marshaller will use LoadLibrary itself.
If it is at all an option, you can use different names for the two P/Invoke declarations, using different arguments for the DllImport() constructor and using the EntryPoint attribute. Doesn't sound like that will fly.

I think 2nd option will work, but it will require to write a lot of code to manage dll loading in .net.
First one might work also, but i either don't like it.
Here is my suggestion: you can specify full path (and may be relative) in DllImport [DllImport(#"C:\dll\a32.dll"]

Your first option (P/Invoke with SetDllDirectory) is the option I personally prefer. Unfortunately, there isn't a ".NETish" way to handle loading native DLLs...which does make sense.

Starting with .NET Core 3.0, and also works with .NET 5 & .NET 6, you can use NativeLibrary.Load(string) to dynamically load DLLs at runtime, and use via P/Invoke normally.
Check this answer for more details: https://stackoverflow.com/a/69958827/211672

How do I invoke C++ compiler programmatically?

For business reasons, I want to create a C# application that would take a C++ file / snippet as input, compile it (probably invoking a C++ compiler under the hood) and output compilation results.
Do you know how this could be done?
Thanks in advance.

Using CL.exe

Look in to the Process class.
It provides all of the functionality required to start an external application, including a compiler.
Now, depending on the compiler you choose, you will need to specify the start arguments of the process carefully in order to compile in a predictable way.

Most compilers support command-line parameters.
You just need to build the right command and execute it through the shell like advised here.
che
If you want to not just build a single file, but a whole .vcproj file - check the command line parameters for devenv.exe. If I remember correct it is:
devenv.exe /build my.vcproj

You can shell out to any number of command-line C++ compilers (like gcc) using Process.Start.

You could do this by calling any C++ compiler on the command line. I'm sure the compilation results can be redirected so that you can grab it after the compile finished.

If you are trying to achieve something like SnippetCompiler for C++, you might want to look at one of the C/C++ scripting languages. I have always liked CInt.

Sure its possible, it is actually common practice nmake and other make-like utilities call the compiler all the time.
OTOH if you are thinking of deploying this solution to a customer you may be in for a bit of rough ride cause of all the details like settings, location where files are, how to react on the result, license, which c++ compiler to deploy etc.
Another option which is much simpler (IMHO) is instead of C++ to invoke the C# compiler directly from your C# program for compiling a C# snippet. Files can then stay in memory and you don't need to save any files before you compile. There are numerous examples on the web that show how to do that. Another advantage with this solution is that you already have the C# compiler there so there is no need to install a C++ compiler as well.