Hot answers tagged

11

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 ...


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 ...


7

Some plugins like reflexil provide this functionality.


7

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#.


6

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 ...


5

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 ...


5

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


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

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 ...


5

As far as free and open source tools go, I'd recommend dnSpy. It is the best tool I've used for .NET reverse engineering. You might also want to try out ILSpy, which is free and open source as well.


5

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 MethodInfo....


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

Consider also JetBrains dotPeek that is free, decompiles .NET 1.0-4.5 assemblies to C#. Has support for .dll, .exe, .zip, .vsix, .nupkg, and .winmd files.


4

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 ...


4

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 ...


4

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.


3

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 ...


3

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 ...


3

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.


3

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'...


3

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 ...


3

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 ...


3

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 ...


3

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, ....


3

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. ...


2

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.


2

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 ...


2

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 http://ilspy.net


2

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 ...


Only top voted, non community-wiki answers of a minimum length are eligible