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
Main difference from ILSpy :
Uses dnLib to read assemblies (vs ILSpy's Mono.Cecil)
dnlib was created because de4dot needed a robust .NET ...
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.
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:
static void Main(string args)
var rawAssembly = File.ReadAllBytes("Test.dll");
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 ...
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.
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.
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'
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 ...
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) ...
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 ...
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 ...
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
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 ...
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/...
The Linked Dll's native method is here you can load the dll directly in ollydbg too to find a resolved disassembly of the native method
E:\1dll>ls -l 1.dll
-rwxr-xr-x 1 Admin Administ 268288 Dec 24 15:27 1.dll
E:\1dll>rahash2 -a md5 1.dll
1.dll: 0x00000000-0x000417ff md5: 82eab591d8bc6d293a2a07f10a5f6a46
E:\1dll>"c:\Program Files\Microsoft SDKs\...
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 ...
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
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 ...
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 ...
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 ...
If you can, you should post links to 2-3 of your real targa images, and the corresponding game targa images (beware of license issues though). Sometimes, looking at the files rings a bell, and i could have checked much of what i'm going to say if it works for your files or not.
Are some of the tga files referenced from Lua? There is Lua source ...
Modifying a Release-Mode .NET Assembly
Since IL is so simple, one way to achieve the same result without a debugger is to simply decompile the executable using ILDASM on a corresponding .NET release mode x64 executable using the following command line command:
"C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\ildasm.exe" ...
C# is a bad language to compare source code with assembly, because your source code doesn't get compiled to assembly (*). Instead, the source is translated to some intermediate code; running the program means starting an interpreter which takes over and interprets that intermediate code. So the only thing you can trace is that interpreter itself, not the ...
For reference to those still looking for an answer to this question, I would recommend trying dnSpy - it allows you to do exactly what the requester asked - modify the high level code and recompile.
It isn't perfect, but I've been able to make small changes to the in-house exe's we have where we didn't have the latest source code (disgruntled employees, don'...
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 ...
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.
VB Decompiler is for decompiling native programs and P-code programs.
But as @ebux said, your target appears to be written in .NET, so you'd need to use something like ILSpy or .NET Reflector.
However, given that your target is packed with BoxedApp, you'll first need to unpack it. A quick Google search shows that it's rather easy to unpack the packed files ...