C# Tools

Started by
9 comments, last by Varela431 7 years, 1 month ago

Does anyone know where I can get any or all the following tools for C#/.NET? I would appreciate it, thanks:

- A compiler to PC machine language.

- An obfuscator.

- A function for changing file author/owner name (preferably built into a library rather than some DLL).

Also, this stuff needs to be free, and not require any sort of registration. Thanks.

Advertisement

Have you looked at .NET Native? Or Mono's AOT functions? There's a few options available here, but without knowing precisely what your goals are it's hard to give accurately-targetted recommendations.

Once you compile C# to native code you really shouldn't need an obfuscator; the purpose of obfuscators is to make the IL difficult to understand when read by a decompiler tool, but native code doesn't really need that. It's already difficult to read when decompiled.

Similarly, I'm not entirely sure what exactly you mean by something to "change the file author." If you just need the assembly info of some compiled C# assembly to change, you can do that directly in the AssemblyInfo.cs or any other file using the appropriate assembly attributes.

- An obfuscator.
- A function for changing file author/owner name (preferably built into a library rather than some DLL).


For your second question, I haven't personally used obfuscation on my own projects yet, but the one I keep hearing about is Dotfuscator:
https://www.preemptive.com/products/dotfuscator/compare-editions

I do both machine code and .Net reverse engineering as a hobby and I've seen some obfuscated .Net code. The typical obfuscations are to rename everything to short, meaningless names or symbols that are legal in IL land but illegal if you attempt to decompile them with a naiive decompiler. This is a deterrent to CASUAL reverse engineering, but a minor nuisance against someone who wants to find a specific part of your code (such as save game "encryption"), and worthless against anyone who has an intelligent labelling decompiler.

As far as native decompilation goes, you still have to decide whether you want to obfuscate or not; by default the native compilers will keep your symbols pretty much the same as whatever you started with, so using renaming obfuscation can actually provide more obfuscation. Some of the most useful hints for decompiling native code are debugging symbols, and .Net's type info that's used by reflection is basically debugging symbols on crack.

If you're using Unity's IL2CPP converter, you can strip symbols afterwards to eliminate a lot of this information. Chances are if you're too aggressive you can break any or all of your reflection-based code, though.

For the .DLL/.EXE info, the only thing I'm aware of is the AssemblyInfo that Josh mentioned. If you just have a .DLL and want to hack it to pretend it's yours, there are tools available that will rewrite .Net DLL/EXE files in pretty much any way you want. Mono.Cecil, ilSpy, or dnSpy would probably be able to do something like that. You may get into very hot legal water if you pretend someone else's DLL/EXE is yours, though.

This wouldn't have anything to do with your recent post asking how to implement your own encryption routines in C#, would it?

The pattern of topics seems to suggest you're in to something way over your head. It can be fun to learn about, but it is also possible to do some really stupid things. Be careful, please.

Actually frob, no, this is unrelated to that.

I'm just writing a program, and I don't want anyone to be able to know how it works, so I don't like the fact that .NET keeps all the variable names still in the EXE file (presumably for reflection purposes).

And also, I don't want anyone to know that I made the program, or various other files that the I or my program writes, hence the author name change, so I can be anonymous. Isn't there some function that I can just import? Why wouldn't there be?

As for the compilation to machine language, that's partially to obfuscate, but mostly it's because I'm afraid that my program may end up being executed on a computer that for whatever reason might not have .NET runtimes, and I don't know what version of Windows will be on it, but I know it should run fine as a machine language EXE.

Incidentally, I've had the necessary .NET stuff installed on my computer for years, so I haven't really had to deal with that in a long time, but just in case I need to distribute it as a .NET EXE, if I remember correctly:

- all that a computer needs to run .NET programs is to have the .NET runtime installed, right?

- Are the runtime versions backward compatible, so my program will work on it even if it was written in an older version of .NET?

- Is a computer necessarily going to already have the runtime installed if it's running, say, Windows 7, even a simple edition?

- If it doesn't, is there an easy way to get and install it, even if an old runtime version is needed?

so I don't like the fact that .NET keeps all the variable names still in the EXE file (presumably for reflection purposes)

The variable names aren't usually so important. If somebody is really concerned about figuring out what your code does, they really just need that code, the operation graph it performs. Obfuscating the C# usually mostly hides names, it doesn't necessarily do a great job at restructuring the control flow to obscure what's going on (in part because doing so might fundamentally change the performance characteristics of the code, or indeed the actual functionality thereof). Compiling to native code helps this a bit but as Nypyren pointed out any use of reflection may still leave significant tells in the generated machine code.

Isn't there some function that I can just import? Why wouldn't there be?

Programming languages don't concern themselves with concepts like "who authored this binary." That's a concept that is squarely in the domain of the OS or the hosting platform, generally. In the case of Windows and the .NET platform, there are some assembly attributes that can be used to embed some metadata into the compiled assemblies that are exposed via the PE file format so Windows can read it.

Visual Studio generates an AssemblyInfo.cs file containing attributes that describe that assembly metadata as a matter of course. It's not required. If you don't want it there, scrub your name from it or delete the file entirely.

but mostly it's because I'm afraid that my program may end up being executed on a computer that for whatever reason might not have .NET runtimes, and I don't know what version of Windows will be on it, but I know it should run fine as a machine language EXE.

This isn't really true; you'll need a runtime of some sort. Pure C++ programs need a runtime (that's what those "Visual C++ Redistributables" are, C++ runtimes of the appropriate version required by programs). Depending on the tool you use to generate native from you C# code, you still may need to bundle a runtime. When in doubt, tools like Dependency Walker can help you examine the dependencies of any given PE file in Windows. Sometimes you can restructure how you build your program to eliminate these dependencies, but not always.

Thanks about the Dependency Walker. I'll check that out.

What I mean about hiding information about who created the file is that if somebody gets the properties of the file in Windows, I don't want it to say who created it, and also if the information is embedded anywhere in the EXE file, I want that gone too.

That should be a very easy and common thing to do, I would think.

What I mean about hiding information about who created the file is that if somebody gets the properties of the file in Windows, I don't want it to say who created it, and also if the information is embedded anywhere in the EXE file, I want that gone too.
That should be a very easy and common thing to do, I would think.


We've told you at least two times in this very thread how to remove those properties. Please read.

is he making some kind of virus o.o?

No I'm not making a virus. Why would you think that?

This topic is closed to new replies.

Advertisement