Debug Symbol information is often "stripped off" from C++ binaries. Symbol information stores all user-created names, symbols, and types, bounds, fouction boundary and other function related metadata information (it is generally stored according to a popular and standardized "dwarf" format which is widely used and employed in modern ...
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#.
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 ...
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 ...
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 ...
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 ...
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.
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'...
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 ...
I've used dnSpy in production for debugging as it can be put on a USB. It's perfectly capable of decompiling and debugging dll's.
It has a pretty rich set of features. It's able to attach to running .net processes, decompile the code, edit variables at breakpoints and make some code changes on the fly.
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 ...
reading your question several times and the discussion in the comments i did not understand what you're trying to get/obtain, so i will be answering to parts that i think that are relevant according to the problems you posed. maybe other and more experienced people here would help elaborate and improve:
if you're trying to "reverse" an interpreted code, ....
I'm starting in RE too (since beggining of 2020), and I thought I could put here what I've learned so far. Maybe it might be of help.
So first of all, you need Assembly knowledges. You asked if it's still worth to learn x86 because there is x64 now. Well, that's a thing I learned too. x64 is just an extension of x86. The real name for x64 is actually x86_64. ...
So all the steps above are correct the way they were described. The only thing I have done wrong was, that my target DLL was modified by Mono.Cecil before (I already had read and wrote my target DLL and modified it by this way). So the DLL and the PDB was not the same anymore.
So if you want to run Mono.Cecil just once and you get the exception above do the ...
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