I wrote a windows application using C# .Net 2.0 and i want to do something which hide the source code, so when any one use refactor tool can't see the source code.
I used dotfuscator but it just changed the function names but not all the source code.
UPDATE:
I want to hide the source code, not because of hiding the key, but to hide how the code is working.
Thanks,
IL is by definition very expressive in terms of what remains in the body; you'll just have to either:
find a better (read: more expensive) obfuscator
keep the key source under your control (for example, via a web-service, so key logic is never at the client).
Well, the source code is yours and unless you explicitly provide it, youll perobably only be providing compiled binaries.
Now, these compiled binaries are IL code. To prevent someone "decompiling" and reverse engineering your IL code back to source code, you'll need to obfuscate the IL code. This is done with a code obfuscator. There are many in the marketplace.
You've already done this with dotfuscator, however, you say that it only changed the function names, not all the source code. It sounds like you're using the dotfuscator edition that comes with Visual Studio. This is effectively the "community edition" and only contains a subset of the functionality of the "professional edition". Please see this link for a comparison matrix of the features of the community edition and the professional edition.
If you want more obfuscation of your code (specifically to protect against people using tools such as Reflector), you'll need the professional edition of Dotfuscator, or another code obfuscator product that contains similar functionality.
As soon as people get a hand on your binaries they can reverse-engineer it. It’s easier with languages that are compiled to bytecode (C# and Java) and it’s harder with languages that are compiled to CPU-specific binaries but it’s always possible. Face it.
Try SmartAssembly
http://www.smartassembly.com/index.aspx
There are limits to the lengths obfuscation software can go to to hide the contents of methods, fundamentally changing the internals without affecting the correctness (and certainly performance) is extremely hard.
It is notable that code with many small methods tends to become far harder to understand once obfuscated, especially when techniques for sharing names between methods that would appear to collide to the eye but not to the runtime are employed.
Some obfuscators allow the generation of constructs which are not representable in any of the target languages, the set of all operations allowable in CIL for example is way more than that expressible through c# or even C++/CLI. However this often requires an explicit setting to enable (since it can cause problems). This can cause decompilers to fail, but some will just do their best and work around it (perhaps inlining the il it cannot handle).
If you distribute the pdb's with the app then even more can inferred due to the additional symbols.
Just symbol renaming is not enough of a hindrance to reverse-engineering your app. You also need control flow obfuscation, string encryption, resource protection, meta data reduction, anti-reflector defenses, etc, etc. Try Crypto Obfuscator which supports all this and more.
Create a setup project for your application and install the setup on your friends computer like a software. There are 5 steps to creating the setup project using microsoft visual studio.
Step 1: Create a Sample .Net Project. I have named this project as "TestProject" after that build your project in release mode.
Step 2: Add New Project using right click on your solution and select setup project and give the name this as "TestSetup".
Step 3: Right click on setup project and Add primary Output and select your project displayed.
Step 4: Right Click the setup project and select View-> File System -> Application Folder. Now copy what you want to be in installation folder.
Step 5: Now go to our project folder and open the release folder you can get the setup.exe file here. Double click on the "TestSetup" file and install your project to your and other computer.
Related
I'm using ILSpy to look at a .dll. A Majority of the classes are in english, but some of the classes are in the weird letters that I can't explain. I'm wondering if there is an error with the .dll or ILspy or if you it needed to be decompiled differently.
Because the code has been obfuscated, it's a way of making the code so hard to understand that it deters reverse engineering.
Usually PreEmptive's Obfuscation tool comes in Visual Studio, check it out. You could also try Market Place, Nuget & Visual Studio Gallery for more.
If you wish to de-obfuscate the DLL it might be possible with an old copy of the code and refactoring based on that. Otherwise you will find that Obfuscation is typically one way, eg renaming a btnSave to a1 is irreversible.
I have an application written in C# (without the source of course), that needs to be changed a little bit. For example, I need to stop a few lines of code that create an unnecessary menu. So I think I should comment them out.
The source code is not obfuscated. I know I can completely decompile, change, and compile again, using tools like Reflector/Reflexil. But everyone knows that by doing this, many parts of code won't compile again! Is there a way in Reflector (or any other product) that a part of could be disabled/changed without this process?
Thanks.
You might want to try dnSpy. It is a .NET assembly editor, decompiler, and debugger forked from ILSpy.
https://github.com/0xd4d/dnSpy
If you really needed to do this, you could decompile it with Reflector (or a similar product) and then use that to try to recreate a solution in .Net that will produce the same executable.
You may run into issues around:
Obfuscated code
Sections where the decompile shows you accurate code for specific sections, but for some reason it just doesn't work in your new solution (and then what do you do?)
This is not to mention the potential legal issues related to doing this. If the executable was released under a license that would permit you to do this, then you would most likely have access to the source code. So the fact that you do not have access to the source code implies that doing what you are suggesting might not be legal.
Eventually I managed to "disable" a few lines of code in the compiled exe.
I used Reflector with Reflexil plugin installed. Reflexil allowed me to edit an MSIL instruction, and then save the result back to an exe file. So, it involved learning a few MSIL instructions, especially the "no operation" command (making a line of code do nothing). To see the list of instructions and a tutorial, see here and here.
Hope it helps someone else.
for the sake of completeness:
Another possible solution is to use the ildasm http://msdn.microsoft.com/en-US/library/f7dy01k1%28v=vs.80%29.aspx
MSIL Disassembler, edit the MSIL and feed it back to ilasm.
How practical this solution is, depends on you of course
This thread may help: dotnet dll decompile and change the code
Last time When I tried with decompile the source using reflection, I got too many compilation issues with regarding to resources and other subs though the dll isn't obfuscated. So there could be things beyond just extracting the source and modifying in order to make your new dll work as the old one.
SO I would suggest to go with direct dll manipulation using any of the options mentioned in the other thread.
If you have source code on the same machine on which you are testing your exe file, and if you are making changes in your sourcecode in visual studio, then while compiling it will automatically get reflected in your exe file.
You need not do any special thing for it. And if it is not, then just make the changes in code and paste your debugg folder's new exe (with debugg folder) on another machine having all recent changes.
We recently had a developer leave our organization. We're not sure if the version of an executable he put on a production server is the same that is currently in TFS. Is there any way (besides using something like Just Compile or ILDASM) to build the project from TFS and compare that executable to the one currently on our production server?
UPDATE: I'm trying out Just Decompile, and I've loaded both binaries, so I'm stepping through each namespace, member, etc to compare them against each other. I'm used to using Schema Compare in Visual Studio to compare the schemas of 2 databases and seeing the updated, removed and added items with the differences highlighted. Isn't there some tool that would take these 2 decompiled binaries and somehow highlight the differences?
Right now I can only think of this approach:
Use dotPeek to decompile the live assembly
Use dotPeek to decompile the same assembly freshly built from TFS
Use a tool like Beyond Compare on the two decompiled sources
Merge the changes as necessary
Hope this is what you were looking for??
Other reading that may be beneficial for the future in terms of versioning so you know what dll contains what functionality (may or may not be useful for you, forgive me if I am telling you something obvious):
Best practices/guidance for maintaining assembly version numbers
Good luck
Yes using NDepend you can diff between two .Net assemblies. Although even compiling exactly the same source twice will not generate exactly the same assemblies.
A product we use for detailed comparisons, including comparisons of binary files, is Beyond Compare. When we first got the product I thought it would be something of limited utility, but it has helped us solve some very tricky problems. It compares directories, text files, binary files, mp3's, pictures, and software versions. It's not particular expensive either.
I just ran the product against the binaries of an application in both Release and Debug and it highlighted every diff.
I am sure that you could run ILDASM against two binaries and do an eyeball comparison, but a tool like this will probably pay for itself over and over again.
We're going to be using Orchard as a base for a particular client. We're a C# shop running VS2K10. We'll throw it in our version control system as per the norm for our projects.
That said, we'll be creating custom modules based on the needs of our clients. What approach does everyone here recommend?
Get full source from CodePlex and check that in
Download just the Orchard web code (similar to Web Platform Installer)
Problem with #1 is that the code base is rather large, but it will allow us to debug the site locally when developing.
What are the caveats with #2? Lack of debugging?
I'm curious what everyone's approach would be for this. I'm inclined to go with #1, get the full source, throw it in SVN, and build off of that.
Thoughts?
If you are going to develop modules using Visual Studio, just use the full source code. Disk space is cheap.
Caveats with #2 are that it's immensely less comfortable. Why bother?
I use the full source version, but I only check the modules and themes that I'm working on into source control.
I did originally use just the web code, but found myself running into lots of little problems that were much easier to track down when using the full source.
I found that only source controlling the stuff I was working on made updating to later versions of Orchard much easier.
I'm no software engineer, but here is what I would do :
Get the source code.
Add it in your VS solution and source control.
Do NOT reference the project(s).
Add a post-build event on that project to copy the dll and the symbols (for debug) in the folders of the project that would otherwise refer this one.
If it crashed in a class from that project's assembly, you'll be able to specify the source code files since you got the symbols, and since you won't be modifying that project on a regular basis, your VS won't rebuild it every time. You could even unload the project if you want to save some memory, however trivial it might be.
It would be nice if it did both a list of methods to choose from and the list of potential input parameters. This was done for powershell and I was curious if there was any similar functionality implemented for emacs or vim?
Clarification:
A fellow developer I work with wants to use either vim or emacs for the low overhead without running visual studio. In essence he would like to be able to write tests, edit code in emacs or vim then just run NANT scripts to compile the code and run the tests. The only feature from Visual Studio he wants is code completion. The rest he can live without for 98-99 percent of the time.
You can use a vim editor emulator for Visual Studio.
http://www.viemu.com/
I haven't come across an emacs mode that would offer code completion suggestions based on "knowledge" of the API(s) that the user's environment is offering. To a lot of people this is an issue which prevents them from attempting to use Emacs or VIM when working with rich/large/unwieldy (delete as applicable) APIs.
However I am wondering how much of a problem this would present during day-to-day work. I've been using Emacs with C#-mode to crank out quite a lot of C# code. I also tend to run dabbrev-mode or pabbrev-mode, which tends to take care of the more common function and variable names I tend to use. To my eternal shame I have to admit that I tend to have a browser open on the MSDN website to look up the rest - those APIs that I don't use often enough to remember. Another potential helper that your colleague might want to look into is icicles, which may also be a step in the right direction. Neither of these libraries however will offer the full breadth of completion support that something the like Visual Studio IDE will offer. I'd see this as part of the trade-off when using a more efficient editor.
As an aside, if your colleague is working in a team and other members working on the same project are using Visual Studio, MSBuild might offer a better solution for building outside of VS than Nant as MSBuild reads the same solution and project files that VS uses (in fact a lot of the build work in VS2008 is handled by MSBuild). The syntax isn't too far away from Nant and with the community tasks added (which gives you NUnit integration etc) and it'll ensure that everybody is using very similar mechanisms to build the executables.
The furthest along completion I've seen for C# is at this blog, specifically at this post. (Blog link included for context and other Emacs posts.)
If you can live with dumb completion, you might be able to roll your own with tags and tag completion.
A previous stack on the same issue.
Your source code should be processed through the CEDET framework: http://cedet.sourceforge.net/
Then either use the example UIs bundled with cedet or else try any of these two:
- company-mode: http://nschum.de/src/emacs/company-mode
- completion-ui: http://www.dr-qubit.org/emacs.php
both supporting CEDET as a completion search backend.
apa!
for emacs and C# you can look at this tool : http://code.google.com/p/idebridge/
OmniSharp provides contextual intellisense for C# in vim.
Some of the suggestions in Eclipse Style Function Completions in Emacs for C, C++ and JAVA? may be relevant for emacs.
Not c# specific, but still.
I have found the http://code.google.com/p/csense this is an emacs c# intellisense/code sense. I found it from this blog post http://osdir.com/ml/emacs.sources/2007-11/msg00018.html, this may be close to the answer I was looking for.
After looking further it has not been updated since November 2007, looks stale to me.
For Vim, you can install insenvim. It support for the C# code completion.
After download the plugin you could install the installation file or install manually by following steps:
Copy the file cs_vis.vim into your $VIM\vimfiles\ftplugin directory.
Copy the file csft.dll into your $VIM_INTELLISENSE directory.
Copy CSVimHelper.dll,reg.bat to your $VIM_INTELLISENSE directory.
Run reg.bat to register the dlls. You need to set the directory gacutil.exe
in the path. You need the latest version of .NET SDK.