So I'm trying to obfuscate my program AFTER it's been compiled. I'm pretty sure that's how you do it (?)
I'm using a pretty popular freeware called EazFuscator which has a nice little command line utility.
So if I go:
Eazfuscator.NET MyProgram.exe
it'll obfuscate it successfully, and when it's done, I'll try to run my program and it crashes! (gives me some runtime exception)
Another thing I tried instead is to obfuscate one of the DLL's my program uses:
EazFuscator.NET SomeDLLMyProgramUses.dll
it'll obfuscate it successfully, but again, when I run my program crashes...
I'm wondering first off, regardless of this EazFuscator program, is it possible to obfuscate .DLL and .EXE files? and is it usually NOT supposed to break them?
Note: I do have some reflection going on in my program, and maybe that's whats causing the problem.. but I'm not 100% sure.
There is Dotfuscator community edition, which you could try.
In general obfuscators are not supposed to break the apps they obfuscate. You should contact the manufacturer if you can reproduce the issue.
Most of the Obfuscation tools have settings that allow you to manage the level of obfuscation - like type names, method names, strings and so on. It is possible that your level of obfuscation has resulted in an IL code that is broken due to these changes that the tool performed on your original IL code. Check the settings available and attempt to avoid a few of those settings.
If you are using reflection then the obfuscation tool will probably break you code. During obfuscation type names are usually changed, therefore your reflection may not work as expected, especially if you are referring to a type by name. Use a tool like reflector to have a look at you obfuscated assembly, you will be able to see whats going on.
Yes, we need to obfuscate our assembly after compilation. Assembly is built again by obfuscator. So we don't need to worry about compilation and building it.
I am using FxProtect which is free obfuscator. Advance Professional version is also available but it is not free. You can try it...
.Net Obfuscator
No, you do not typically obsfucate your executable program. I'm sure you've been thinking about it since you posted your question and can imagine why.
Run the obfuscation on your source code then compile that into deliverable.
Whether or not your code is broken by obfuscation depends upon what you do in your code. If you're using reflection in there that will almost certainly be the root cause.
CLISecure has worked well for me in the past (even on mixed-mode assemblies) ...but we don't use any reflection in our codebase.
Related
I managed to decompile a c# file (using dotpeek) and I want to edit a couple of simple things (using visual studio).
The problem is this file has many dll dependencies even though the edits are necessary only on the main exe.
Obviously if you try to build an exe on vs without having the references and dependencies in place the compiler will complain. Are there any solutions to this?
You cannot build without the dependencies; however, there is no need to decompile the dependencies. Just add the DLLs themselves as reference to the project.
This is always fine if the decompiled assembly depends on other DLLs; however, if the other DLLs depend on the decompiled assembly, this will only work if the assemblies are not signed, i.e. if they are not using strong names. The purpose of signing is precisely to disallow such hacks.
No, you can't build without the dependencies because the compiler has to check that types match and have the indicated members etc.
I know this is a wacky question, but in Visual Studio 2010 C#.Net is there a way to name an Assembly with a different extension than DLL. E.g., MyAssembly.MLL instead of MyAssembly.DLL.
I poked around but could not find a way to do it.
No, I don't believe so - at least not without a bunch of extra work.
I've just tried this with a manual rename step, and although you can compile against a renamed assembly, it won't be found at execution time. The code will contain a reference to MyAssembly, and the runtime will try to resolve that to MyAssembly.dll and MyAssembly.exe... but it won't know the actual filename you used. It's possible that there's a way of configuring this within app.config or using AppDomain.AssemblyResolve to resolve the assembly yourself - but I strongly suspect other things may break.
Aside from anything else, I would discourage you from doing this just in terms of unconventionality. You'll surprise other developers, tools etc - not a good idea.
thanks to some resource of the web, I made a little tool to know whether my .NET dll is in debug or in release build; but I'd like it to work also for c/c++ DLLs.
Does anyone have some piece of code about this? The DLLs are compiled using Visual Studio.
As far as I know there is no way of telling such thing just looking at the DLL. In our work we use different names for debug dlls (adding a D at the end) and using preprocessor stuff.
As Debug or Release builds are just a set of properties for the compiler you could end up with a Debug build that compiles like a Release does and the other way around.
Summarizing, I think there is no way, sorry.
This is not 100% but take a look at this.
http://msdn.microsoft.com/en-us/library/system.diagnostics.fileversioninfo.isdebug.aspx
Information is usually contained in the PE header. You can write some code for parsing it.
I have a C# application which links to a few c# DLLs which in turn use bindings to call c++ functions in other Dlls.
This all works fine if I compile the c++ Dlls with /MTd but when I use /MDd I get an XMLParseException in my C# app complaining that it can't find any Dlls(it fails to find the first of my Dlls that I use). My best guess is that using this other switch causes it to change the path where it looks for its Dlls, causing it to fail. I used DependencyWalker to have a closer look and the two Dlls it actually fails to find are 'IESHIMS.DLL' and 'WER.DLL'. I can't see my c# Dlls anywhere in the tree in DependecyWalker however. Anyone have any ideas what might be wrong here?
Also, using the non-debug equivalents (/MD and /MT) make no difference. Regardless, I can't use /MT as it causes another bug.
EDIT: I've narrowed the problem down somewhat. When compiled and linked using the VS2010 command prompt, my app works fine, with the VS2008 command prompt it still fails to find the Dll. Does anyone know any differences between these two version of VS which could cause the behaviour I described above?
Thanks in advance,
Are you compiling all the modules against the same run-time libraries? From:
http://msdn.microsoft.com/en-us/library/2kzt1wy3(VS.80).aspx
"All modules passed to a given invocation of the linker must have been compiled with the same run-time library compiler option (/MD, /MT, /LD)."
Is there a tool to import/convert COM type libraries into C# code rather than generating an assembly? The TLBIMP tool and the TypeLibaryConverter class only generate assemblies.
I've had some success ripping the C# ComImport definitions by running Reflector over the generated Interop assembly and copying a pasting the disassembled source, but this usually requires quite a bit of manual patching up before it'll compile.
Desired goal is a single EXE without satellite Interop DLLs, so perhaps the answer is to use ILMerge to effectively embed the interop DLL in the EXE.
I was sure in the past I'd come across such a tool - but maybe it dreamt it :-)
I'm not so sure it is going to be useful to you, but the source code for a managed version of Tlbimp.exe has been released on CodePlex. VS2010 will definitely solve your problem.
This won't help you out today, but there is a feature coming in the next version of C#. It's called NoPia or Type Embedding depending on which presentation you read. This feature essentially will link a PIA assembly into whatever project you reference it from. The end resulrt is a single EXE which no need to deploy an interop/PIA DLL.
Misha's post on the subject: http://blogs.msdn.com/mshneer/archive/2008/10/28/type-embedding-support-in-c.aspx
Short term though, you may have to go with ILMerge or reflector + copy code.
As I originally suspected the best solution is going with ILMerge. I can't be selective about parts of a COM API to embed, but it works well enough.
Here is the Post Build Event Command Line I'm using, which should be easy enough to reuse:
set MERGEFILES=Interop.Foo.dll Interop.Bar.dll
if "$(ConfigurationName)" == "Release" (
ren "$(TargetFileName)" "_$(TargetFileName)"
"$(ProgramFiles)\Microsoft\ILMerge\ILMerge.exe" /out:"$(TargetFileName)" "_$(TargetFileName)" %MERGEFILES%
del "_$(TargetFileName)"
del %MERGEFILES%
)