I built a .NET class library and used an obfuscator to obfuscate it with anti-debugging.
I built a testing project using my obfuscated class library. I would have hoped that anti-debugging forbids debugger to step into my class library. But it simply threw exception "Debugger detected" when my class library was invoked when I started the project in debugging mode (by pressing "F5" in Visual Studio).
What this means is that if a project uses my library then the developer simply cannot debug at all. They may have millions of lines of code that has nothing to do with my library. Not being able to debug at all in their project will only mean one thing: they will not use my library.
Is there anyway a developer can do to "isolate" my library, so that they can debug elsewhere?
Specially thanks to #Artem Razin for:
isolate sensitive code to a separate process that runs with the
enabled anti-debugging feature.
Its great and helpful. Also virtualization he specified is good approach. I will post you a good approach if you need exactly working with anti-debug envirnoment. Bceause you mention the exception: Debugger Detected
Am assume you use Eziriz .NET Reactor. When I speak with support. They said you can't provide two anti-debug version for specific HardwareID. Because HardwareID involved in the licensing system and it must not bypassed!
I can tell you a workaround for that by using .NET Reactor CLI and MSBuild targets.
What scenario it should be? (I will show what we need to do before write CLI...)
If you a have a developer team, or friend who need to use your obfuscated library. That's great. But he can't debug because its anti-debugged.
Then we must separate an assembly into two assemblies. One for developer its obfuscated but without anti-debug feature enabled. and other assembly into release folder for consumer or your audience.
So when you build your assembly. or need to create nuget package for it. you need to do a double obfuscation. Firstly you will obfuscate the anti-debug version for consumer into Consumer/AntiDebug folder. Secondly you will obfuscate the original DLL again but for developer without anti-debug feature!
So please use Directory.Build.targets for that. Here's code for obfuscation:
<Target Name="ObfuscateDLL" Condition="'$(Configuration)' == 'Release' AND $(OutputType) == 'Library'"
AfterTargets="AfterBuild">
<PropertyGroup>
<ObfuscatedFolder>$(MSBuildThisFileDirectory)\Anti Debug</ObfuscatedFolder>
<ObfuscatorPath>C:\Program Files (x86)\Eziriz\.NET Reactor\dotNET_Reactor.Console.exe</ObfuscatorPath>
<ObfuscatorParameters>-antitamp 1 -anti_debug 1 -hide_calls 1 -hide_calls_internals 1 -control_flow_obfuscation 1 -flow_level 9 -resourceencryption 1 -antistrong 1 -virtualization 1 -necrobit 1 -mapping_file 1 -mapping_file_overwrite 1 -mapping_filename "<ProtectedAssemblyLocation>\<AssemblyName>.nrmap" </ObfuscatorParameters>
</PropertyGroup>
<!-- Obfuscate with anti-debug to Obfuscated folder or \Release path when GenerateNuget enabled -->
<Exec Command=""$(ObfuscatorPath)" -file "$(TargetPath)" -targetfile "$(ObfuscatedFolder)\$(TargetFileName)" $(ObfuscatorParameters)"/>
<!-- Obfuscate without anti-debug to /Release path for Nuget package for Developers -->
<Exec Command=""$(ObfuscatorPath)" -file "$(TargetPath)" -targetfile "$(TargetPath)" $(ObfuscatorParameters.Replace('-anti_debug 1','').Replace('-mapping_file 1', ''))"/>
</Target>
Please use above code! if you need it as simple as possible. But you need to manually create nuget package for you developer. via MSBuild or by the way you need.
But If you use .NET Framework and want to generate obfuscated debuggable nuget package (for developers). And also provide anti-debug version to your consumer. You can use following MSBuild targets.
It contains ability to create Nuget package with all dependencies automatically.
It obfuscate the consumer library to Anti Debug folder. then It will obfuscate nuget version and packacking it. then copy back Anti Debug version to Release folder.
You can manually turn on/off GenerateNuget property. If you will not generate nuget so anti-debug version only produced.
Change the code depending on your needs...
https://pastebin.com/wmvcWMUp
(See link XML content are large can't posted to StackOverflow)
Anti-debugging is a well-known feature since the times of exe packers. Unfortunately, it is a process-wide thing. Usually, .NET obfuscators check debugger-specific environment variables.
There is no way to prevent a debugger from stepping into your assembly.
I would say that anti-debugging is for those who want to protect their end-user products, not libraries.
You can virtualize your code (modern obfuscators like ArmDot provide this feature), so debugging it would have almost no sense.
Another idea is to isolate sensitive code to a separate process that runs with the enabled anti-debugging feature. On the client-side, you just provide a proxy that redirects all calls to the process.
Related
I am trying to automate a build process for a C# (vs2008) solution.
The build script is written in a Batch script which I want to change. We use Clearcase as the CM system. I have searched some tools such as MSBUILD, NANT.
Any suggestions which is a better solution like a sample script in MSBUILD and NANT?
I have not seen any sites where MSBUILD and NANT is documented well or any good tutorial about each task description.
Where I can learn MSBUILD or NANT either of them and write script from scratch?
There is a third way which I prefer. You can also use devenv.com. It's faster than NANT, doesn't require NANT bins and works on any machine with VS installed. You also avoid possible errors with MSBUILD (http://support.microsoft.com/kb/964125).
Just use %path_to_devenv.com%\devenv.com "%path_to_sln" /<buildoption> BuildConfig
In my case it's
%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\devenv.com "C:\Projects\XYZ\xyz.sln" /rebuild Debug
This way it's guaranteed that your project will be build exactly the same way as it's being built in Visual Studio.
EDIT:
Now that we know how how much there is to do, I'll try to give an outline how you can setup the whole system for automated build controll.
Set up your repository (I hope this is already done - tell me if not)
Install and set up Jenkins (https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins) including users, ClearCase-Credentials, plug-ins for ClearCase, MSBuild, etc. (all of them can be found in the Jenkins plug-in interface) - this is the biggest peace of work
Create and set up a new project in the jenkins interface (name, working directory, etc.)
Tell jenkins to use source code management (e.g. subversion module), enter the ClearCase repos to use, set the desired behavior of the source code management
Set a build trigger (I recommend checking the source code management each minute: * * * * *)
Add a build step and select "Build a Visual Studio project or solution using MSBuild" - this option should appear after installation of the MSBuild plugin (https://wiki.jenkins-ci.org/display/JENKINS/MSBuild+Plugin)
Set the path to the .sln file (you have checked it out from your repository)
Add more optional arguments if desired (eg /p:Configuration=Release or Debug or whatever http://msdn.microsoft.com/en-us/library/vstudio/ms164311%28v=vs.110%29.aspx)
Play around untill it works
Btw., I recommend to put all external dlls into your repository.
For Linux packages, specifically RPMs with stored checksums, we always can check two things: the contents of package is ok and the installation from this package is ok. When someone modifies parts of the installation he shouldn't, we can see it by running rpm -Vp my-precious-package. In our busyness it is not only recommended, but obligatory to provide our packages with tools for this purpose and for Linux these are just simple bash scripts.
Now I have to do something similar for Windows. Basically what I want is to provide some batch file by running which one can get assured, the installation is the same as it meant to be in the package. I'm using InstallShield for packaging, and yet it has some great visual tools, I still haven't found a way to verify package checksums in the command line.
Is it even possible, or should I reinvent the wheel writing my own checking utils?
Take a look at MakeCat and SignTool from Microsoft, both in SDK
http://msdn.microsoft.com/en-us/library/windows/desktop/aa386967%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa387764%28v=vs.85%29.aspx
Windows Installer has a feature called resiliency that supports auto repair of products and there are ways to call it for self checks only. (This is assuming by InstallShield you mean Windows Installer based projects.)
Here's a couple links to read to get you started:
INFO: Description of Resiliency in Windows Installer
Resiliency
Application Resiliency: Unlock the Hidden Features of Windows Installer
MsiProvideComponent function (See dwInstallMode flags)
This also assumes all files are key files. Companion files are not managed by the installer. Also changes performed by custom actions outside of the installer aren't managed.
I would like to setup an automatic software distribution process, preferably from Microsoft Visual Studio, which builds my projects in all the different configurations and platforms, and packages all the created objects in a predefined folder tree structure.
The software distribution packages would be for Windows libraries and WDM driver projects written in C/C++. Each library has several different configurations (i.e. Windows 7 Release, Windows XP Release, MT/MD runtime compilation flags) for different platforms (i.e. x86 and x64). A similar thing is with the drivers. Without any automatic process to create a software distribution package, it's necessary to build all the different configurations for each platform and then copy the created objects to a predefined folder structure and then zip the created folder giving it a release name and version. This process is quite time consuming and error prone. Therefore, my goal is to automate this process using a clean a nice solution.
I've been researching about this for a few weeks already and have actually implemented a few different solutions. However non of the solutions I implemented until now is flawless whatsoever. Hence since this should be a problem that I guess many developers have already encountered, I would like to hear different opinions on what would be a nice and efficient way to do it.
Up until now I've tried the following:
A batch script and a Makefile to be used by NMAKE. This is not so good because it makes difficult to set the same build parameters that are set on the visual studio project.
Implemented a "deploy" target task (editing the .vcsproj files) which calls MSBuild of the project for each configuration/platform and copies the generated files to a distribution directory. This has the advantage that I can start the deploy activity from within visual studio but it also produces several environment variables problems, specially when building windows drivers.
Any ideas or suggested solutions will be appreciated.
Thanks in advance.
Zion
If you haven't already, add a post-build step for each lib and driver which copies the built files into your specific tree and also zips them.
If you haven't already, create one Visual Studio solution (.sln file) which builds all these projects at once.
If you haven't already, set up Build configuration using the Build | Configuration Manager dialog. Now from the IDE, you should be able to specify a specific configuration and do a Build | Rebuild Solution and make sure all the projects are successfully built.
From the command-line, you can now automate #3 by opening a Visual Studio command line prompt (which sets up the environment variables appropriately). Start devenv.exe with appropriate command-line parameters.
I've created a Windows Forms (C#) application called "Image Processing". It uses many external dlls so I decided to use ILMerge to merge all of them into one exe file and it worked. But today I've localized my application. After building I had 3 new folders in Debug folder: "en-US", "ru-RU", "uk-UA" with one dll with the same name "ImageProcessing.resources.dll". So I included all of them in a ILMerge command:
ILMerge.exe /t:winexe /out:ImageProcessingRelease.exe ImageProcessing.exe AForge.dll AForge.Imaging.dll AForge.Math.dll DevExpress.Data.v10.2.dll DevExpress.Utils.v10.2.dll DevExpress.XtraBars.v10.2.dll DevExpress.XtraEditors.v10.2.dll FreeImageNET.dll uk-UA\ImageProcessing.resources.dll ru-RU\ImageProcessing.resources.dll en-US\ImageProcessing.resources.dll
My program stores language locale in settings. After merging I can't change language, but settings are changing.
I don't know what else I can include here for more details so tell me please what.
The answer is simple. ILMerge is not suitable in this case, as .NET Framework relies on the folder structure to determine which resource file to use.
It is meaningless to combine assemblies in that way, and some third party assembly vendor's end user license does not permit you to merge their product with your own assemblies.
Suppose you have some source code that comes from the unix world. This source consists of a few files which will create a library and a lot of small .c files (say 20 or so) that are compiled into command-line tools, each with their own main() function, that will use the library.
On unixy systems you can use a makefile to do this easily but the most naive transformation to the windows / Visual Studio world involves making a separate project for each tool which, although it works, is a lot of work to set up and synchronize and more difficult to navigate at both the filesystem and project/solution level. I've thought about using different configurations where all but one .c file are excluded from the build but that would make building all the tools at once impossible.
Is there a nice way of building all the tools from a single "thing" (project, msbuild file, etc.)?
I'm really not interested in using cygwin's gcc/mingw or NAnt. I'd like to stick with the standard Windows toolchain as much as possible.
You don't HAVE to use visual studio to compile code. You can make your own batch file or Powershell script that simply calls the compiler on your source, just like a makefile.
So I've been looking into this for a while now and the solutions all leave much to be desired.
You can...
Create a lot of small projects by hand.
Use MSBuild and deal with its steep learning curve.
Use a build tool that does not integrate well with Visual Studio, like GNU make.
You can't even make a project template like you can with .NET projects! Well, you can make a wizard if you want to wade through the docs on doing that I suppose. Personally, I have decided to go with the "many small projects" solution and just deal with it. It turns out it can be less horrible than I had thought, though it still sucks. Here's what I did in Visual Studio 2008:
Create your first Win32 command line tool project, get all your settings down for all platforms and make sure it works under all circumstances. This is going to be your "template" so you don't want to edit it after you've made 20 copies.
(optional) I set up my paths in the visual studio project files so that everything is built in the project directory, then I have a post-build step copy just the dll/exe/pdb files I need to $(SolutionDir)$(OutDir). That way you can jump into a single directory to test all your tools and/or wrap them up for a binary distribution. VS2008 seems to be insane and drops output folders all over the place, with the default locations of Win32 and x64 output differing. Spending a few minutes to ensure that all platforms are consistent will pay off later.
Clean up your template. Get rid of any user settings files and compiler output.
Copy and paste your project as many times as you need. One project per tool.
Rename each copied project folder and project file to a new tool name. Open up the project file in a text editor like Notepad++. If you have a simple, 1-file project you'll need to change the project name at two places at the beginning of the file and the source code file name(s) at the end of the file. You shouldn't need to touch the configuration stuff in the middle.
You will also need to change the GUID for the project. Pop open guidgen.exe (in the SDK bin directory) and use the last radio button setting. Copy and paste a new GUID into each project file at the top. If you have dependencies, there will be one or more GUIDs at the bottom of the file near the source code. Do NOT change them as they are the GUIDs from the dependencies and have to match!
Go into Visual Studio, open up your main solution and add your tool projects.
Go into the configuration manager and make sure that everything is correct for all supported platforms, then test your build.
It's not beautiful, but it works and it's very much worth the setup time to be able to control your builds from the GUI. Hopefully VS2010 will be better about this, but I'm not too hopeful. It looks like MS is giving a lot more love to the .NET community than the C/C++ community these days.
If you have a makefile you can use a 'makefile' project in Visual Studio (which in misnamed - it simply allows you to specify custom build/debug commands), and use it to invoke GNU make.
You will need to change the makefile to use the VC++ command line tools instead of cc or gcc or whatever it uses, but often these are specified by macros at the top of the makefile.
If the makefile uses other Unix specific commands (such as rm), you may need to make modifications, or create bath files to map commands to Windows equivalents. Another option is to install any necessary tools from GNUWin32 to make it work.
If the build is very complex or involves configure scripts, then you have a harder task. You could generate the makefile from a configure script using MSYS/MinGW, and then modify it as above to make it work with VC++.
Makefile projects will not be as tightly integrated in Visual Studio however. All the build management is down to you and the makefile.
If you're really using Visual Studio, I would suggest creating a project for each tool, and adding these projects to a single solution. From Visual Studio, it's easy to build a complete solution all at once, and MSBuild knows how to build .sln files as well.
msbuild myslnfile.sln
or even:
msbuild
... will build your solution.