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.
Visual Studio for Mac can do the job. Just hit File / Open and then choose the executable or library you want. It'll open the Assembly Browser window.
If you need more detailed code change the Visibility to All members and the Language to C#.
Best free tool for the job is ILSpy, but it runs on Windows. This gives you a limited list of options:
create a windows virtual machine (with virtualbox or vmware player) and run it in there
install WINE on mac, to allow you run .exe files.
get visual studio for mac and use ikdasm
if you feel hardcore, open it in a disassembler ;)
Being an IT guy myself, I ...
You can always feed the original binary to IDA and use the plugin Findcrypt2 to identify the algorithms used. Other than this the Kanal plugin for PeiD can also detect cryptography used.
Another tool for the same task is Hash & Crypto Detector
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 are a number of options:
C# code can be compiled to native code (like C++ compilation) using Ngen.exe or .NET Native. Although the IL code and metadata might still be required by the runtime.
All kinds of information that is contained in an assembly such as type names, variable names, method names, strings, and constants can be obfuscated. This makes ...
In the past I've had issues editing the IL code during run time, especially if the method had already been compiled by the JIT Compiler, and the most full proof way I found was to patch it during run time was to edit the x86/x86_64(or whatever architecture you're running) generated by the JIT Compiler which is located at the pointer given by
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 ...
It's not very reliable. IDA can't determine types beyond analyzing the size and type of loads and stores. For instance IDA doesn't tell the difference between a pointer to a type and an integer, given that they're the same size, as far as I know. Other than that all it can do is propagate type information entered by the user. I believe the Hex-Rays ...
Good news, You're lucky!
What you're facing in front of you is a stream cipher. Why is that good? because the way stream ciphers are built makes them extremely easy to reverse - the decryption and encryption functions of stream ciphers are actually the same function.
A stream cipher is a symmetric key cipher where plaintext digits are combined with a ...
Well the algo is quite simple, let's try to break it down:
if (code.Substring(0, 2) != "DC")
It has to start with DC
if (code.Length != 0x1a)
and be of length 26 chars
string s = code.Substring(2, 14);
byte buffer1 = new SHA256Managed().ComputeHash(Encoding.UTF8.GetBytes(s));
then take the 14 chars starting from third (skip DC) and ...
Try using dnSpy. It includes an ability to inject the recompiled code, and has the same interface as ILSpy. Use "Edit Method" option on the method you're editing, then "Build" and save the assembly. You won't need Reflexil then.
Since the compilation output of .NET languages is MSIL, which is quite readable itself, it can be transformed back to (almost) original source code.
There are many applications which can do that.
My favourite is dnSpy since it's free, open source and has debugging functionalities. AFAIK it can even try to build a Visual Studio Solution (.sln) file from your ...
To answer your question "Can I end up with the original source code in a way I can finish the coding of the missing items and recompile again?": if it runs on your system, it means you have all the dependencies needed and you'll be able to decompile to a state where you can edit and recompile at will.
I don't know about Reflector, but with ILSpy, you have ...
It's base64. One entry per line. Entries look like they're padded to 0x10. So after base64 decoding the data is probably encrypted by a block cipher with 128-bit block size. Maybe AES. At this stage you probably need to analyze the executable in order to get the plaintext back.
Not quite sure what you are looking for, so here goes:
If you just want to open the database of a FM runtime solution, thats easy:
Just rename the .USR file to .fp7 and open it with Filemaker (you might need Filemaker Pro Advanced). See also the developers guide for the layout of the bound files (page 14). The .USR file is called the "bound" (as in binding ...
Converting multiple comments of mine to an answer for future readers:
You can't always deobfuscate .NET binaries. If, when the binaries are compiled, the obfuscation implementation modifies the name itself in every place it's referenced, then that (the mangled name) is what the name will be for you, the reverser. It's as if the developer developed the ...
You can use de4dot (https://github.com/0xd4d/de4dot) to deobfuscate the binary. Static analysis of dotnet binaries can be done easily by using de4dot and then using ILSpy to create a visual studio project, then you can analyze the source code in visual studio. You can also use dnSpy which allows you to debug the binary easily.
About the instrumentation, a ...
Currently, there's no way to modify the binary directly with ILSpy. The only solution is the one you described, export the source and recompile it.
However, the feature you are looking for is included with .NET Reflector in the Reflexil plugin.
This is 64-bit math. The compiler has to do the addition in two steps because the processor can only work 32 bits at a time. And carry has to be propagated from the low addition to the high one - same way when you do addition of multiple-digit numbers on paper.
Here's what the current version of the decompiler (1.7) produces (after fixing the function ...
Depending how extensive your modifications are, the way I've always done it was to only compile the snippet you want to inject (or manually convert the OpCodes) and patch the existing binary rather than recompile
also, IlSpy may be easier for what you want as you can simply go:
.net binary > c# decompiled > .net binary
There are three ways to do this:
Decompile the content of the JAR, make your changes to the decompiled source code, recompile the sources, and rebuild the JAR. This works well if the CLASS files aren't obfuscated or overly complex.
As you answered in your question, you could extract the CLASS, hex edit it to make your changes, and add it back into the JAR ...
You file is obfuscated with ConfuserEX and I know it because of the way the ControlFlow looks. ControlFlow is simply the fact that the method body seems to be confusing / puzzling, with Switch Cases and Gotos.
If you dig into Google, and look for "ConfuserEX Deobfuscator" you will be able to download a few tools to clean your protected assembly (mainly on ...
They are not inside the application, there should be somewhere on your machine and will be loaded at runtime. You can use Process Monitor to check from where they are loaded.
ILSpy should be able to go into those DLLs so if it can't it might be an indication that it can't find them.
It appears to me as if these are just file names, which may or may not refer to files embedded in the executable. Looking at the cross references and the surrounding API calls might tell you how they are being used.
Perhaps using a utility like strings might help to discover if there is more embedded text. If you think the files might be obfuscated you ...
it's not immediately apparent how the classes are put together, i.e.
how and when methods on the classes are called
I'm afraid there is no free lunch here.
What you can tackle this with two approaches:
Static disassembly (look at the disassembled code and try to make sense of it)
Dynamic analysis (e.g. use a debugger like dnSpy) This way you can 'watch' ...