50
ILSpy is a great open-source decompiler.
ILSpy Features
Assembly browsing
IL Disassembly
Support C# 5.0 "async"
Decompilation to C#
Supports lambdas and 'yield return'
Shows XML documentation
Decompilation to VB
Saving of resources
Save decompiled assembly as .csproj
Search for types/methods/properties (substring)
Hyperlink-...
24
I've used JetBrains dotPeek (free of charge) before with some success.
Any JetBrains software I've ever used has been very solid.
It is not quite the 'original source' but it is very readable C# - about the closest thing I would expect to get. Quote from their website:
What's Cool about dotPeek?
Decompiling .NET 1.0-4.5 assemblies to C#
...
14
Recently I've been using dnSpy [forked from ILSpy by the creator(s) of de4dot] as my main tool for the decompiling and live debugging of .NET code
https://github.com/0xd4d/dnSpy
Main difference from ILSpy :
Uses dnLib to read assemblies (vs ILSpy's Mono.Cecil)
https://github.com/0xd4d/dnlib
dnlib was created because de4dot needed a robust .NET ...
13
JetBrains dotPeek is a free decompiler that has the option of decompiling whole assemblies into VS projects:
11
There is a free tool available called JustDecompile which does that.
Some features:
Creating a Visual Studio project from an assembly in order to export lost projects or obtain multiple classes without the need to copy and paste code. At present, JustDecompile is able to export decompiled code only to C#.
Exporting code directly from the command ...
10
Why does decompiling an F# assembly produce C# code?
It doesn't. It produces IL code which then can be interpreted as C#, F# or VB.NET. dotPeek doesn't allow you to use any other language for previewing but for example dnSpy, ILSpy allow you to pick your favourite one. Just wondering if there's any tools that allows F#. Not sure/haven't seen one.
Despite ...
9
I have used .NET Reflector (Note: Commercial, but trial available) several times and quite like it:
http://www.red-gate.com/products/dotnet-development/reflector/
8
It is in fact trivial to dump the byte array or the module directly from dnSpy.
To mimic the described scenario I wrote some trivial example code:
using System.IO;
using System.Reflection;
namespace DumpAssembly
{
class Program
{
static void Main(string[] args)
{
var rawAssembly = File.ReadAllBytes("Test.dll");
...
7
There is a plugin called Reflexil for Reflector which makes it very easy to patch a .NET binary.
Reflexil is an assembly editor and runs as a plug-in for Red Gate's
Reflector and Telerik's JustDecompile. Reflexil is using Mono.Cecil,
written by Jb Evain and is able to manipulate IL code and save the
modified assemblies to disk. Reflexil also ...
7
Reverse engineering .net without any anti-reverse engineering protections is trivial.
The reason is that programs like these are compiled down to an intermediate language that we call bytecode which contains high level information (symbol names,data definitions etc) making it possible to recover source code almost similar to the original which simplifies ...
7
Some plugins like reflexil provide this functionality.
7
These are Unicode characters that are not supported by the font used by dnSpy.
Usually, you'll see it when the code is obfuscated or in cases where the developer used languages as Chinese and Russian in their code. But yeah, usually obfuscation.
You can try to deobfuscate this .Net binary by using de4dot which is doing an incredible job with deobfuscating ...
5
Update: dnSpy is now my go to tool for .net decompiling. It's open-source, it exports to Visual Studio projects and the debugger works like a charm.
https://github.com/0xd4d/dnSpy
Original answer: Telerik JustDecompile also can export to Visual Studio projects. I used it recently and it worked with very minor modifications to the code. It's a free tool.
...
5
You may work according to the following pattern:
Save code in ILSpy (or in Reflector) as .cs files (as you already described)
Try to create a Visual Studio project from that code
Make all modifications in Visual Studio.
If VS compiles the code, it should open as well in ILSpy and/or Reflector.
If it doesn't it is most probably not complete and/or not ...
5
This is definitely one of the naming schemes from Crypto Obfuscator.
As listed on their features page:
Fake Renaming Scheme
Crypto Obfuscator also has a renaming mode which renames all classes, fields, methods, etc to fake but realistic names like Domain/Log/Stream/etc (for classes) or Open/Close/Clear/Delete/etc for methods and so on. This makes it ...
5
The problem you face is quite common. A .NET application still loads many native DLLs. Most surprising for many people is that the .NET framework itself is native.
You can identify .NET DLLs in WinDbg using the lm v command. In case of a managed DLL it says:
0:008> lmv m MyApp
start end module name
10310000 10574000 MyApp(deferred) ...
5
I'm trying to get to the code behind newObject(), which is apparently instantiated from marshaled code. I'm no .Net expert, but from what I read marshaled code is some kind of serialization that can be applied on objects to transfer functional code over binary channels (such as a TCP connection, for example).
I'm not sure what "marshaled code" means, but ...
5
If you're looking at a "normal" mono droid application (compiled with something like Xamarin) then you'll see some of these structures in the APK/ZIP'
/assemblies/Sikur.Monodroid.dll
/assemblies/Sikur.dll
/assemblies/Xamarin.Android.Support.v13.dll
/assemblies/Xamarin.Android.Support.v4.dll
/assemblies/Xamarin.Android.Support.v7.AppCompat.dll
/assemblies/...
5
There is no real prolog in IL code because it does not need to manage the stack, save clobbered registers, or do any other standard bookkeeping necessary in the native code.
However, the bytecode itself is preceded by the method header, and those have a limited number of possibilities. From the book .NET IL Assembler:
Method Header Attributes
The ...
5
that instrumentation is not easily possible because of JIT compilation of IL instructions.
Well it's actually the opposite. Tracing methods is quite easy - it would be difficult if we would like to trace fields usages. .NET assemblies contain rich type/method information that can be used to inspect/modify them. There's also a great library that does that ...
4
EDIT: The OP updated his question yesterday to say that he's dealing with a .NET application, so the advice below no longer applies. I'll leave this answer here though since it might help others for Win32 applications.
Try setting breakpoints on API functions that might be used to create the nag screen.
For example, (from http://www.woodmann.com/krobar/...
4
Low-level details and implementation for patching and intercepting .NET code at runtime: http://www.ntcore.com/files/netint_injection.htm
High-level details and implementation for patching and intercepting .NET code at runtime: http://www.codeproject.com/Articles/16359/MethodLogger-Hook-into-method-calls-in-NET-binarie
4
Try http://de4dot.com its a powerful .net deobfuscator. I've authored a serie of tutorials dubbed "demystifying dot net reverse engineering" google it, its a great point of start if you are new on .net RE.
Here is an article on how to deal with obfuscated assemblies http://resources.infosecinstitute.com/reverse-engineering-obfuscated-assemblies/
And this ...
4
Just to be clear: You can not reconstruct source code from .net or c++ binaries. You can try to recover it using heuristics, embedded symbols and knowledge about the assembler, but you already lost the necessary information in translation.
You should differentiate between packing and obfuscation.
Packing means you encrypt (and / or compress) parts of your ...
4
I dont think .NET is as simple.. you can clearly see it in IDA Pro - there at least a few different one byte function prologues.
Why not use a decompiler library for dnSpy/de4dot - dnlib to decompile and then use code clone detection, for example Simian or implement some fuzzy matching (hashing?) algorithm.
.NET generally decompiles nicely when its not ...
4
the last byte of API/library call instructions is always 0x0A
It's because calls needs to have method (ref) as a parameter and methods are defined in the table that has an id of 0x0A.
Having bytes of the call like this 280600000A let's go one by one.
0x28 - is the value for opcode 'call' and it takes one operand.
the rest of the opcode is the metadata ...
3
If you are interested into a decompiler on API level: https://code.google.com/p/facile-api/ (in Java though)
3
In general, bytecode is easier to reverse engineer than compiled code. It (usually) contains a lot more metadata and uses an idealized computing model. A good obfuscater can make this much harder, but still not nearly as complex as native code written with reverse engineering in mind. This is because bytecode languages don't allow nearly as many 'tricks' ...
3
If you use the windbg sos extension you can step into the internal calls - which are unmanaged code. The documentation for using sos is a bit tricky to sort out IMO. This link is helpful for learning the sos commands: http://msdn.microsoft.com/en-us/library/bb190764(v=vs.110).aspx. To load SOS I use:
.loadby sos clr ; for .NET 4 and higher
.loadby sos ...
3
It's probably a native dll. You can probably decompile the main photo viewer binary (which presumably is managed code, based on your statement) to get some information about the native dll to assist in your disassembly based reverse engineering of the dll.
Only top voted, non community-wiki answers of a minimum length are eligible
