When we want to use a native shared library, we have to have the header files. So when we publish the software, others do not have the header files and they can not use the library.
But the managed library does not need any headers. Because you can simply use add reference in Visual Studio and use Object Browser to see all the classes and namespaces.
So when we publish our application with managed library, not only others can use our library in their own project (whether it is obfuscated or not), but also they can decompile it and see the whole source code if it is not obfuscated.
Is it true?
How can we secure our managed library?
Well, that's perfectly safe. In practice the main impact of having users able to see (a decompiled approximation of) the workings of the library is that you sometimes get a higher quality of bug report from them.
Software companies like Microsoft manage to eke a living despite consumers being able to decompile their libraries, or indeed just read the published source.
But if you really want to prevent it then being managed does not preclude being obfuscated.
There are several obfuscators available, and if you really want to get in the way of your users, you can ilmerge in the library to a make a single obfuscated executable, so they can't even use the library, never mind give you useful feedback copy your code.
Related
Is it possible to extract the code of a Xamarin Android application and inspect it?
I am in last stages of one Application which would be soon released on Play Store. However, I am worried if the code could be extracted and looked at by other people.
Please advise, how to secure my App from other people looking at the code for it.
Yes, it is possible to extract the code of a Xamarin.Android application. By default, the .dll files are just resources inside the APK, and they can be extracted with a zip utility and examined with e.g. ILSpy.
The Xamarin docs explain how to protect your application, including:
Disable debugging
Obfuscate with Dotfuscator
Bundle assemblies into native code (but see below)
Use AOT (native) compilation (but see below)
Note that #3 requires an Enterprise license and just puts the .NET .dlls a layer deeper in the APK; it is still possible to extract them and they are still unobfuscated.
Note that #4 is explicitly listed as an experimental feature that should not be used in production.
Full disclosure: I work for PreEmptive Solutions, and we make Dotfuscator.
You can select Ahead Of Time (AOT) compilation.
That won't prevent extraction, but will made it very difficult to do. On top of that, you can use
Crypto Obfuscator.
I would suggest to read about SafetyNet as well, which provides a set of services and APIs that help protect your app against security threats, including device tampering, bad URLs, potentially harmful apps, and fake users:
https://developer.android.com/training/safetynet/index.html
Obfuscating of Xamarin Android apps is of no sense (you can turn on "Enable ProGuard" option if you want but it will not Obfuscate your code) its better to turn on "Embed assemblies to native code" which will convert all code into a binary .so file. and it will make it difficult for hacker or reverse engineer to read that code and do reverse engineering AOT but that is in experimental and might create problem for some device after updated on play store. in order to play safe i would suggest to go with "Embed assemblies to native code"
Good day,
I want to take an existing C# project and wrap functions into a C++/CLI DLL. I need to be able to read this DLL from VB 6. I choose this route because I won't have to register a .net DLL in order to use it with VB 6. Frankly I have no experience with this kind of thing so I would greatly appreciate a good example. I know there are plenty of similar questions like this but I haven't been able to find anything simple enough for me to understand.
This is a fairly unwise route to pursue, making C# code [ComVisible] is pretty trivial and Regasm.exe should not scare you. The usual mistake with Regasm is to forget to use its /codebase option on your dev machine.
If you insist on not taking advantage of this then you'll need to find a way to get the CLR loaded yourself so it can execute your C++/CLI and C# code. There are three basic ways to do so. You've written off COM interop and hosting the CLR yourself isn't very practical if the host app is VB6. You however can take advantage of the C++/CLI compiler's ability to generate unmanaged DLL entrypoint stubs that load the CLR for you and switches to managed code execution. Do so by writing a static function that you decorate with __declspec(dllexport). The technique is shown in this answer. Beware that it isn't particularly performant and you'll have to live with the restrictions imposed by the VB6 Declare statement.
Also check this post-processing tool that can inject these stubs directly into a C# assembly. Not sure how reliable it is, I haven't used it myself.
Be a man and make that DLL under a couple of different compilation/linking/function-call-protocol configurations. Then go ahead and try a couple of different referencing configurations in your VB6 project. Post what works. Contribute, go forth!
Take a look at Export Managed Code as Unmanaged
and C# Project Template for Unmanaged Exports
Attempting to build a C# NPAPI plugin I have found a tutorial which describes that your dll needs to implement a number of methods such as NP_GetEntryPoints , NP_Initialize and NPP_New along with a number of others.
However what I want to understand is if I can simply mirror these method names and construct equivalent datastructures as described in the article (like _NPPluginFuncs) in C# and everything will work?
Could someone please be kind enough to provide some guidance? Is it possible to build a NPAPI plugin in C# and if so what are the basic steps involved?
As stated in the documentation:
A NPAPI browser plugin is, at it’s core, simply a DLL with a few specific entry points
That means you need to export some function from a regular dll, that is done usually in C/C++. Unfortunately it is not possible to expose any entry point from a plain C# dll, but look at this answer, with some effort it appear to be possible to trick some export by some sort of post build tool.
In any case don't expect to pass too much complicated data structures from/to the plugin interfaces, it will be a pain. If you are interested in doing more research the keywork to use is "reverse P/Invoke", in analogy with direct P/Invoke that is calling regular dll from managed world.
The reason a C# dll can't expose directly "entry points" is that entry point are actually just some address inside the dll poiting to some assembly code immediately executable. C# dll are different kind of beast: they are just files containing IL that is compiled "Just In Time" and indeed such compilation is forced AFAIK with some OS tricks. This is the reason reverse P/Invoke is not starightforward at all.
As Georg Fritzsche says in his comment:
NPAPI plugins are basically DLLs with a few required C-exports
and there is no built-in way to export functions (in the C-export sense) from an assembly written in C#.
Some of your options are:
A mixed-mode C++ assembly which can export the functions directly. This could have implications for hosting the CLR in your plugin's host process.
A small native DLL which hosts the exports, then uses COM interop to delegate to a C# assembly containing the plugin functionality. The "official" way to do so-called "reverse p/invoke".
An intriguing project which post-processes your fully-managed assembly, turning static methods marked with a custom attribute into named function exports. (I have no affiliation with this project; I stumbled across it after I got to wondering whether anyone had improved on the COM interop way of doing things.)
I built a simple demo application in C# using a modular approach so it consists of one executable and a couple of DLLs. Suppose I put it in a zip file and hand it over to somebody, with the sole purpose they can try out the demo application simply by extracting the file and doubleclicking the exe.
Now, to my understanding everybody that gets the application and the DLLs, can just add a reference to the DLLs in a Visual Studio project, and then start using whatever functions/classes they have as long as they are declared public. And hence, they can get access to a lot more than what I want them to access.
Is there a way to disable this, and get a system that is somehwat like with C++ DLLs (e.g. I can give anyone a lot of C++ DLLs and they'll have a rather hard time using the functions/classes in it if they do not have the header files)? Can I somehow strip the DLLs so that they are still usable by the exe, but do not expose references? Or are there attributes or so that I can use in the code that say "this class is usable only be DLLs/exes built by me"?
You could use the InternalsVisibleToAttribute and not make anything public, but...
You're mistaken if you think that anything stops someone from using non-public classes from your DLL. An application with full-trust can access private and internal content no problem, or they can decompile and rebuild the DLL with everything public.
People will suggest obfuscation, but that doesn't do much more.
You should read this answer (and question, but mostly answer): C#: How to Make it Harder for Hacker/Cracker to Get Around or Bypass the Licensing Check?
One possible solution is to leave public only the method that is supposed to be called from the executable. Everything else could be private or internal. You could also obfuscate the assembly. But remember that no matter what you do, there is always the possibility of using Reflection to invoke any method inside the assembly. Of course if it is obfuscated it will be a little harder but not impossible.
I think you can use Friend assemblies for that.
You may also obfuscate internals of your dlls so it become really hard to do reverse engineering and decompile your assemblies. Tools like Dotfuscator will rename all function/variable names inside your compiled dll to something like a0002345 so reading it will be really exhaustive.
Please notice that none of methods gives you 100% protection as still it is possible to use .NET reflection routines to access and use your private and internal classes. However making stuff internal or private will stop majority developers using those classes. Use obfuscation to stop advanced engineers who tries to dig into your compiled sources. In theory protection is considered safe enough if decompiling effort is greater than effort for writing similar tool from scratch. If somebody can't read your dlls the one won't be able to know how to use it.
No, sorry, not.
You could do ilmerge followed by obfuscation (I'm not sure what tool) for something similar.
It's a standard practice to decompile and reverse engineer .net assemblies.
I'd like to release some plugin assemblies that will add to existing applications, but I don't want them to be utilized by others.
What are some ways I can hide the source of these assemblies?
It's theoretically impossible to achieve 100% protection unless you control the target hardware. If the CPU is able to execute it, given enough time and knowledge, a human being can read it too. This is not even limited to C# (although it's usually easier to do in managed languages). You can use an obfuscator like Dotfuscator or XenoCode to make it harder to understand the decompiled code. If you're really concerned, you should move to a server-based application.
You can use an obfuscator tool, it will help but reverse engineering will still be very possible.
Your users' computer needs to know what it needs to do, so you have to tell it. The owner of the computer has total control over it, and can therefore know himself what you told the computer to do, and he can tell it to do something else.
There is a way to hide the data, its called steganography. There's an author of a number of articles covered on CodeProject, who wrote a framework for doing exactly this. The title of the articles were 'Steganography ' in a series from 1 up to 12 I think. This is the website that is affiliated with the author.
There is a also a obfuscator called 'Phoenix Protector', found here, which can obfuscate the .NET code, personally, I have not tried it but it sounds good.
Hope this helps,
Best regards,
Tom.
It's software; anything is possible. You can encrypt your binaries, and then decrypt all or part of them into your application at runtime. It's not foolproof, but it's up to you to decide how draconian you want to be.
You can write an app that will host CLR using the CLR COM api, that way you can first load and decode the assembly at the native code level. If you reinforce the native loader using several anti-reverse engeneering techniques, you can achieve good enough security.
At the very least, you should obfuscate your dlls to prevent hackers & competitors from viewing and making sense of your code. Obfuscation is not 100% foolproof, but it presents a big enough obstacle in their path.
Some obfuscators such as Crypto Obfuscator have a feature of embedding all dlls in the main exe so your dlls are not explicitly visible and available on disk to open in reverse-engineering tools such as Reflector.