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.

Change resources in other Win32-dll/exe

There is a Resource Hacker program which allow to change the resources in the other win32(64) dll and exe files.
I need to do the same thing, but programmaticaly. Is it possible to do it using .Net framework? What is the good starting point to do it?

You must use the BeginUpdateResource, UpdateResource and EndUpdateResource WinApi functions, try this page to check the pinvoke .Net signature of these functions, also you can check this project ResourceLib.

The author points to another tool "XN Resource Editor" which comes with source code (although Delphi, not .NET).
This should be enough to see which functions being used and use the .NET equivalent of them.

Take a look at Anolis.Resourcer. It seems to be the thing you need
A ResHacker clone developed as a testbed for Anolis.Core and to replace ResHacker (because ResHacker doesn't support x64, XN Resource Editor (ResHacker's spiritual sequel) doesn't support multiple-language resources and crashes a lot, and other utilities rest cost actual money. It has a powerful yet simplified UI that doesn't duplicate commands or confuse the users with special-case handlers (which ResHacker and XN have in spades).

Note that none of these will work if you're dealing with signed EXEs or DLLs.

Well, as I see it is not easy task, so I'll use command line interface of Resource Hacker.

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 to avoid .NET DLL files from being disassembled? [duplicate]

This question already has answers here:
How can I protect my .NET assemblies from decompilation?
(13 answers)
Closed 6 years ago.
I am writing a .NET application (a Windows class library) for implementing the licensing our product.
The problem is that the DLL can be easily disassembled by the MSIL disassembler or any other third-party tools and one can easily break the code.
I have even tried signing the assembly, but still it can be disassembled.
So how do I prevent this?
Is there any tool to available for this?

Check out the answers for this question.
You cannot achieve complete protection, but you can hinder disassembly in ways that make it more difficult for people to succeed at it. There are more ways to do this, some of them detailed in the answers to the question in my link above:
Obfuscate your code.
Use public/private key or asymmetric encryption to generate product license keys.
Use a packer to pack your .NET executable into an encrypted w32 wrapper application.
What I would add would be incremental updating, both for your core functionality and the protection code, so your users will constantly benefit from the new features while making crackers lag behind you in breaking your software. If you can release faster than they can break and distribute your software, you are in gain. Legitimate users will always have technical support and a word to say regarding new features. They are your best market, as the ones who crack your software wouldn't have payed for it anyway.

You can't, but you can use an obfuscator so that it's impossible to make sense out of your code.
For example, have a look at Dotfuscator.
The community edition of this program is included with Visual Studio.

.NET has an attribute called SuppressIldasmAttribute which prevents disassembling the code. For example, consider the following code:
using System;
using System.Text;
using System.Runtime.CompilerServices;
[assembly: SuppressIldasmAttribute()]
namespace HelloWorld
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello world...");
}
}
}
As you can see, there are just two differences:
We have added System.Runtime.CompilerServices namespace decleration.
We have added [assembly: SuppressIldasmAttribute()] attribute.
After building the application in Visual Studio, when we try to open the resulting EXE file in ILDASM, now we get the error message.

Anything written for the .NET framework is subject to disassembly. You cannot prevent it.
There are obfuscation tools available that will change variable names and insert other 'noise' into your IL, for instance Dotfuscator.
You might want to consider taking another approach with your licensing library, that is, using something else other than .NET, if licensing your product is absolutely necessary.

As mentioned above in the selected answer, there is no true full proof way to secure you code.
Even in something like c++, if your applications code is in your customers hands : Eg - they have physical access to the binary, that application could potentially be disassembled.
The solution would be to keep the functionality that you are licensing, out of reach of people who may want to disassemble it, let them use it, but don't let them hold it.
Consider using :
Web Services
Keep your marketable content server side and beyond the reach of your clients. They can use it, but not examine the code.
Encrypted Binaries and Online Binaries
Maybe even streaming assemblies in an encrypted format to a wrapper application. Keep your decryption keys server side to prevent offline disassembly. This might be circumvented however if someone found a way of exporting the assembly from the app domain of the application, once it has loaded it. (You cannot load an encrypted binary, so an end user might wait until your application has done the work of decryption, then exploit that to export the finished binary) (I was investigating a way to accomplish this (the exporting) - I didn't quite get it working, doesn't mean someone else wont)
The only thing to remember is that ANY code, no matter how well coded it may be, is vulnerable if it is on a users system. You have to assume the worst when you put binaries on their system. A really talented Engineer can disassemble any dll, be it c++ or c#.

How do I best localize an entire app to many different languages?

I'm using Visual Studio (2005 and up). I am looking into trying out making an application where the user can change language for all menues, input formats and such. How would I go on doing this, as I suppose that there is some complete feature within .Net that can help me with this?
I need to take the following into account (and fill me in if I miss some obvious stuff)
Strings (menues, texts)
Input data (parsing floats, dates, etc..)
Should be easy to add support for another language

I'm not an expert with .NET by any means but Localization is never just as simple as "swapping out String values" or "changing date formats". There is much more to be taken into consideration such as layout, proper text placement.
Take Chinese for example. The way you read is top to bottom not left to right. If properly localized the app should take that into account.
http://msdn.microsoft.com/en-us/library/y99d1cd3(VS.80).aspx seems to be a good start though if you're dealing with Windows Forms.

The classic recipe is: design the app with no native language but a localization facility, and develop an initialization into one language (e.g., English). So you build the app and localize it into English every night; without the localization step it would not be usable. Do that well, and the resources for the initial sample localization can be replaced with those for any other language. Take into account non-roman scripts from the beginning. It's much cleaner to have a no-language app that always requires localization rather than a language-specific app that needs to have its native language subtracted and a replacement added.

For strings you should just separate your strings from your code (having an XML/DLL that will transform string IDs to real strings is one way to go). However you do need to make sure that you are supporting double byte characters for some languages (this is relevant if you use C/C++).
For input data what you want is to have different locale's. In Java this is relatively easy, and if you use C# it probably is quite easy also. In C/C++ I don't really know. The basic idea is that the input parsers should be different based on the locale selected at that time. So each field (textfield, textbox, etc.) must have an abstract parser that is then implemented by a different class depending on the locale (right to left, double byte, etc.).
Check the Java implementation for details on how they did it. It is quite functional.

You definitely need to be using the .NET ResourceManager and the resx file xml format, however there are a number of approaches to using this.
It really depends on what you are wanting to achieve. For me I wanted a single xml resource file (for each supported language) that could be modified by anyone. I created a helper class that loaded the global resource file into ResourceManager (once only) and I had a helper function that gives me the required resource for a given name. The only disadvantage in this approach was that I could not leverage dynamic binding of resources to properties.
I found this better and easier to manage than multiple or embedded resource files for every form. Additionally exactly the same approach can used in an ASP.NET application. I also found this approach means that outsourcing translation of resources and shipping language packs to customers much more manageable.

Microsoft's recommended approach is to use satellite assemblies, as described in Packaging and Deploying Resources. If you're using a ResourceManager to load resources, .NET will load the correct resources for the CurrentUICulture. This defaults to the user's current UI language setting in Windows.
It is possible to localize Windows Forms either through Visual Studio or an external tool, WinRes.exe. This article describes WinRes and how to use Visual Studio to localize the form.