I have a dll file is written on C #, I opened the file via the Reflector, the file is the code
if (a! = 5)
{
}
How can I change the code on
if (a == 5)
{
}
I still have the plugin Reflexil
You can do that using MSIL Disassembler
Decompile using that tool, apply changes in IL and compile back again using MSIL Assembler
This will work smoothly if compiled app is not protected.
Whilst the answer about modifying the IL is correct, you can also use Denis Bauers plugin for reflector to disassemble the code and create a new project from it. You can then recompile that project to produce a new dll.
This allows you to make the change in a more familiar environment, rather than having to deal with the IL. you can also choose the language you want to make the changes in.
If the assembly needs to be signed then you might have problems getting it to load again.
Other Alternatives are ILSpy or the Resharper 6.0 which also contains a disassembler.
Related
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.
I need to change the code of the .NET DLL. I am able to see the code by compilable the DLL with .NET reflector, but I am not able to change the code of the DLL. With .NET Reflector, I decompile the code and saved in to my hard disk, but when i am able to recompile the code its giving errors.
Few code is decompiled in binary format few code is decompiled with c#. Is there any tool to change and recompile the DLL?
Here are the tools I used for trying to decompile the DLL:
ILSpy
DisSharp
Reflector7.1 With the Reflexil plugin
Spices.Net.Suite.5.8
Deploy .NET 1.0.0
devextras.codereflect
dotPeek-1.0.0.2545
intellilock
JustDecompile_BETA_2011.1.728.1
Unfortunately, none of the tools giving perfect source code to recompile the DLL code.
The following code is working:
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\ildasm.exe" original.dll /out=code.asm
echo Here changes to code.asm should be done.
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ilasm.exe /dll code.asm
So if the change in code is to be small, it's doable by making the changes in assembly code directly. One can compile and disassemble simple methods to see how the assembly code should look like. Putting additional methods inside the assembly file should not be too hard too.
Of course code analyzis should be done using ilspy-like tools, displaying the source code rather than assembly code.
Tools employed here come from Windows SDK (ildasm) and from .net framework (ilasm).
I've had limited success in recompiling DLLs. A better way of going about it is to using Reflector and the Reflexil plugin. You need to have a bit better knowledge of the IL code that makes up .NET assemblies but Reflexil does a great job of describing the OP codes. I have a little walk through on my blog about how I used to modify the PowerShell Cmdlet Help Editor: http://csharpening.net/?p=348
How I can get IL code of C# code ? Can I do this with a extern library, or exists internal functions ?
EDIT : I want to show IL code in my application with a MessageBox.
Programmatically? You can use reflection to get a MethodInfo, and then call MethodBase.GetMethodBody to get the body. From the MethodBody, you can call GetILAsByteArray amongst other things.
Of course, if you just want to examine it yourself, there's Reflector, dotPeek, ildasm (part of the .NET SDK) and no doubt other tools...
Use IL Disassembler like this:
c:\il>csc Class.cs
c:\il>ildasm /output=Class.il Class.exe
you'll both have the IL & the exe.
Just open a Visual Studio command prompt and type ildasm - with ildasm you can open up any assembly and show the generated IL.
Take a look at LinqPad, it has options to see IL.
OR,
Start -> Programs -> Microsoft .NET Framework SDK (Version) -> Tools -> MSIL Disassembler
It's quite an old question, but I'd like to add some accuracies.
GetMethodBody() will give you at best a byte array, which you need to parse manually (which can be painful since some opcodes have two bytes) to get a human readable text.
I just want to mention ILSpy as an alternate solution.
It's open source, meaning you can debug it and integrate with it in your solution.
Quick question.
Can I recover a lost .cs file using RedGate Reflector ?
My assembly is a debug version
If you open .NET assembly in Reflector, you should be able to switch which language Reflector uses to display the code e.g. IL, VB.NET, C#. There is a dropdown list on the UI menu bar with this selection of languages.
As long as you have all the required external libraries and references, you should be able to copy the C# code form Reflector and try to rebuild it.
To make it a little more simple to get the IL code back into a file you should check out this Reflector Add-in.
More add-ins for Reflector can be found here.
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%
)