Categories
Support Corner

Understanding Cross-Assembly obfuscation

Reading Time: 2 minutes

Enterprise application development involves several moving parts.  There may be different teams working on different components: server-side, client-side, GUI, API, database, etc.  Each component may have a completely different release cycle, and each team may be working completely independent of one another.  But however the work is divided, all these components must come together to work properly at runtime. Any professional application protection tool should have the ability to handle these complex scenarios without disrupting the development process.  

Dotfuscator’s Runtime

Dotfuscator is designed with that at the center. The tool allows users to get up and running quickly, while providing full control to adjust for specific project requirements.  Cross-Assembly Obfuscation is just one example of the many ways it provides us this flexibility. 

Dotfuscator treats its inputs as a set of related assemblies.  It examines all internal and external references, traverses the full inheritance hierarchy.  It then performs “Cross-Assembly Obfuscation” meaning classes, methods, properties and their references are renamed uniformly across all input assemblies.

Dotfuscator Flexibility

If it’s not feasible to obfuscate and deploy our entire application at the same time, this is not a problem for Dotfuscator.  It can be approached a few different ways, but the easiest to maintain is to build with Library Mode enabled for each project.  In Library Mode, Dotfuscator preserves public and protected types and member names and signatures.  Only private and internal types and members will be renamed.  Obfuscation transforms like Control Flow, String Encryption, and Tamper detection will be performed regardless of access modifier.  This ensures that calls to the obfuscated assemblies work properly whether the calling assembly has been obfuscated in the same project or not.  

Cross Assembly Obfuscation Example

A simple example can be downloaded here.  This shows the same set of assemblies (two dll’s referenced by one main exe) obfuscated two different ways.  In the first scenario, all assembly files are included in one Dotfuscator project.  In the second scenario, each assembly is obfuscated separately, with Library Mode enabled to preserve references between them.  In both scenarios, the obfuscated binaries come together to work properly at runtime. 


Stay tuned for our continuation article, we will examine other strategies for approaching obfuscation spanning different teams.  If you have feedback on this topic or other topics you would like us to discuss in the Support Corner, please feel free to contact our Support Department.


Categories
Support Corner

Protecting a ClickOnce Deployed Application

Reading Time: 2 minutes

ClickOnce is a popular way to deploy and keep applications up to date without a lot of hassle.  These applications are downloaded to the end user’s machine after being published to the server, which means they can easily be decompiled and reverse engineered like other .NET applications. 

Protecting an application that is deployed via ClickOnce is usually very complicated.  After protection, the application and deployment manifests must be manually updated using the Mage tool.  Signing of manifests and assembly files must be done manually, as well. 

With Dotfuscator, we’ve worked to make this process much simpler.

Consider this Example

In 4x versions, Dotfuscator accepted the ClickOnce .application as direct input.  It would re-generate the obfuscated assemblies along with the updated .application package.  The updated deployment manifest and protected binaries would then be copied to the ClickOnce deployment server to be downloaded by the end-user.

Starting with version 6, we’ve made this process even easier.  We just have to integrate Dotfuscator into our application’s project file (.csproj, .vbproj).    

Doing so triggers Dotfuscator to run before packaging steps of our Release build.  Protected binaries are then automatically packaged for deployment.  No additional steps required.

We’ve worked with customers that deploy through ClickOnce, and also create an installer for offline installs.  This process allows us to do both without any additional steps.

A simple ClickOnce project with Dotfuscator integration can be downloaded here.  A release publish of this project generates obfuscated binaries.  Double-clicking the .application manifest simulates a download and install of the ClickOnce application on the client’s machine.

If you have feedback on this topic or other topics you would like us to discuss in the Support Corner, please feel free to contact our Support Department.


Categories
101

Dotfuscator 101

Reading Time: 4 minutes

In this blog we will dive into Dotfuscator  as part of our 101 series – we walk you through what Dofuscator for .NET does and how this can help protect your projects. 

For those of you who are in the industry and know how this product protects your code, we appreciate the loyalty! If you are not tech savvy, but want to know a little bit more about this product, here’s our summary:

What is Dotfuscator for .NET?

Dotfuscator – by definition is a multi-functional tool that combines obfuscation, optimization while shrinking your source code, on .NET, Xamarin and Windows Platform Apps. Basically this jumbles, encrypts your code, hardening it to prevent theft. 

How does Dotfuscator work?

PreEmptive Dotfuscator for .Net provides many layers of protection for .NET users with multiple forms of obfuscation. We like to describe this as constructing the perfect sandwich.

  • First we start with the bread, in this case we will call it Renaming. Renaming obfuscation alters the variables and methods making it difficult to read or scan over to gain access to the certain parts of your source code. However, we go a little further by making things extra difficult for the typical hacker by utilizing Overload Induction™. This renames as many methods as possible to the same name instead of changing one variable one by one. To say this least – this is what makes the “bread” harden at surface level.
  • Then add the veggies: lettuce (Control Flow) and tomato (String Encryption). Control Flow uses advanced obfuscation by falsifying conditional statements. Basically it destroys the code patterns that decompilers use to recreate source code resulting in spaghetti logic to confuse anyone who tries to crack the code. Adding the tomato to this (String Encryption), hides all the strings that are present in the user’s assembly. To better explain, the typical hacker will locate string references inside the binary. Usually if the application is time sensitive, a message will pop up when time has expired – this is exactly what hackers search for inside the decompiled output indicating that they are VERY close to stealing your algorithm. Dotfuscator directly addresses this issue by allowing the user to encrypt strings in the most vulnerable part of the source code. 
  • Now comes the choice of meat (Watermarking, Pruning, Linking-Assembly Merging). Watermarking helps track unauthorized copies of the user’s project by embedding copyright information directly into .NET applications without jeopardizing runtime behavior. Pruning takes the work out for you by removing unused types, methods, fields, debugging information and non-essential metadata from a MSIL file all while processing. Dotfuscator Linking-Assembly Merger combines multiple input assemblies into one or more output assemblies – meaning it shrinks your application down alongside pruning and renaming. 
  • Next is the cheese (Tamper Detection & Defense). Dotfuscator injects code that verifies your application’s integrity during runtime and if it detects tampering, it will shut down the application, invoking random crashes. Now that’s an excellent choice of cheese! 
  • Last but not least are the condiments: mayo (Debug Detection) and mustard (Defense Using Checks). These two are prebuilt into Dotfuscator and can be injected into the .NET apps. This allows your app to detect any unauthorized uses such as debugging or tampering of any sort. Don’t be fooled, checks can do more than just the average scanning, they can react too, for example – exiting the app when tampering is found. 
  • For those who like a little extra to the sandwich, (Shelf Life) is the pickle! Shelf Life is an inventory management function that allows you to embed an expiration date, de-activation, and notification logic to your code! Now this is what we call the ultimate sandwich! 

When should you use Dotfuscator?

Whether you’re a start-up company, freelancer or an organization developing projects using .NET software, you should be using this in the development process – preferably in the beginning stages even after launches. Data breaches are no longer part of the “new normal” they are part of everyday scenarios. If you don’t protect your code from the beginning…you will likely become another data breach statistic.

Where does Dotfuscator work?

Dotfuscator is injected directly into your source code, providing a multi-layered approach by way of in-app hardening; assessing and securing where your code is vulnerable.  

Why should you use PreEmptive Dotfuscator?

PreEmptive Dotfuscator has paved the way in In-App security since 2003, that’s 19 years in the biz! Our clients range from small to large enterprises including many Fortune 500 companies of different industries from medical to government agencies. But if you still need a little more convincing, check out our client list here

For more information on how to get started, download our free trial or need further help, we encourage you to use our resources, found in our navigation bar. We hope this blog has helped you better understand Dotfuscator for .NET. We look forward to our next 101!


Categories
Support Corner

Protecting VSTO Add-Ins

Reading Time: 2 minutes

Visual Studio Tools for Office (VSTO) have enabled .NET developers to extend the functionality of Office applications like Word, Outlook, and Excel since 2003.  VSTO Add-Ins are deployed directly to the end user’s machine and triggered when the Office application starts.  Because of this, VSTO Add-Ins can be easily decompiled and reverse engineered like other .NET applications. As many developers can attest, this is an easy access point for hackers to gain control of your applications.

Most application hardening techniques are quite cumbersome for VSTO Add-Ins.  After application hardening, the VSTO application manifest (.manifest) and deployment manifest (.vsto) must be manually created or updated using the Mage tool.  Signing of assembly and manifest files must be done separately as well. 

Protecting VSTO Add-Ins

Fortunately, protecting VSTO Add-Ins is made simple with PreEmptive’s Dotfuscator.  All we have to do is edit the project file (.csproj, .vbproj) to add tags that call Dotfuscator.

This will trigger Dotfuscator to run before packaging steps of our build, so protected binaries are automatically packaged for deployment.  This works whether we’ve created an installer or are using ClickOnce.  No additional steps are required and developers can implement it relatively easily.

Example of VSTO Add-In

A simple VSTO Add-In with Dotfuscator integration can be downloaded here.  A release build automatically generates obfuscated binaries, and double clicking the .vsto manifest installs the Word Add-In.

Although VSTO Add-Ins are being phased out in favor of the new Office Add-in, there are still several VSTO applications in production which could benefit from Dotfuscator’s simple integration. If you have questions on this or other topics you would like us to discuss in the Support Corner, please feel free to contact our Support Department


Categories
Dotfuscator Support Corner

Protecting Windows Forms Applications with Data Bound GUI Controls

Reading Time: 3 minutes

Today we will focus on data binding, but first let’s define this. Data binding allows Windows Forms applications to display and update UI controls from a data source, without having to modify source code for the control itself. 

When protecting Windows Forms applications, it is important to note how the data bound controls are constructed to determine if they will be impacted by code obfuscation.  If the controls bind to a collection of objects, original property names of that object must be preserved to correctly populate “DisplayMember” and “ValueMember” properties of the control.  When binding controls to an Enum, the original names of its members must be preserved, or the GUI control might show obfuscated names.  On the other hand, if we’re binding directly to a database table (and the table does not map to an object in source code), we don’t need any custom configurations because Dotfuscator does not mangle table and column names.

Consider the Following Example:

This simple Windows Forms application has three UI controls with different data binding techniques: a DataGridView binds to a Customer table in a database, a ListBox binds to a collection of Employee objects, and ComboBox binds to an Enum called DaysOfWeek:  

If I obfuscate with project defaults, I experience a runtime error at app startup:

This occurs because original property names of the Employee object are used in “DisplayMember” and “ValueMember” ListBox properties:

            listBox1.DataSource = employeeList;

            listBox1.DisplayMember = “Name”;

            listBox1.ValueMember = “Department”;

To Avoid the Runtime Error:

First, I’ll open my project configuration file (DotfuscatorConfig.xml) in the Dotfuscator Config Editor, and set a Rename exclusion for the properties in the Employee object:

After configuring this Rename exclusions, the application starts without the runtime exception, but the “DaysOfWeek” ComboBox appears with obfuscated names:

In order to fix this, I will configure a Rename exclusion for the members of DaysOfWeek.

After providing this Rename exclusion, the app starts without any issues or erroneous behavior.  Please also note the DataGridView, which binds to the Customer table in our database, did not require any Rename configuration to start and display correctly.

Conclusion

There are several different ways to use data binding in Windows Forms applications.  We’ve seen a few ways that data bound controls can be impacted by obfuscation.  If you experienced a runtime crash or erroneous UI behavior after applying obfuscation, please use the above steps to resolve the issue. 

The full example can be downloaded here.

If you have any feedback on this topic or other topics you would like us to discuss in the Support Corner, please feel free to contact our Support Department.

Categories
Press Releases

PreEmptive Product Updates

Reading Time: 3 minutes

We are pleased to announce the general availability of Dotfuscator 6.4, DashO 11.2 and JSDefender 2.4 for our customers.

PreEmptive has been hard at work on the latest releases of Dotfuscator, DashO, and JSDefender. The improvements are part of PreEmptive’s strategy to continuously support all products with regular updates and new features. Headlining some of the product updates are improvements to integration and usability, and bug fixes to help ensure we keep our customers happy!

Below are the highlights of each release with links to further information such as how to access the latest version, documentation, and changelogs. Free evaluations are always available for each product.

Dotfuscator 6.4

Dotfuscator Professional protects .NET applications from reverse-engineering and hacking, using a variety of static and dynamic code transforms and injected runtime checks. Examples include symbol renaming, control flow obfuscation, string encryption, debugger detection, and tamper detection. It integrates into the development build process and operates on the .NET Intermediate Language. Dotfuscator Professional supports .NET, including .NET Core, .NET 5, Xamarin, and Mono.

The Dotfuscator Professional 6.4.0 release improves the support for default interface implementations in .NET Core 3+. Dotfuscator can now protect applications that use .NET’s default interface implementation feature, without extra configuration steps which were required before.

Additionally, the tool now provides more granular control of managed resource renaming. Users can now disable automatic resource renaming, in cases where the application loads those resources manually from strings that cannot be statically analyzed.

This version enables authenticated proxies to communicate with the PreEmptive licensing servers, which is a requirement at many enterprise customers.

The Xamarin.Android Root Check is also updated to handle new versions of Android rooting tools. 

Product Links

DashO 11.2

DashO protects Java and Android applications from reverse-engineering and hacking, using a variety of static and dynamic code transforms and injected runtime checks. Examples include symbol renaming, control flow obfuscation, string encryption, debugger detection, and tamper detection. It integrates into the development build process and operates directly on compiled Java bytecode.

The DashO 11.2.0 release enables Include and Exclude rules to be configured via Java Annotations and Supertypes. Rules can now match classes based on the existence of methods or fields that match the criteria.
The New Project Wizard now includes settings for generating Entry Point rules based on Java annotation based criteria, including a special set of entry points for Hibernate/Java Persistence API.

Additionally, DashO now processes compiled bytecode from Java 16 (except for the record type and the Sealed Classes preview feature).

Also, Global Processing Excludes now allows for classes to never be updated by DashO.

Product Links

JSDefender 2.4

JSDefender protects JavaScript code from reverse-engineering and hacking, using a variety of static and dynamic code transforms and injected runtime checks. Examples include symbol renaming, control flow obfuscation, string encryption, browser-based “Dev Tools” detection, and tamper detection. It integrates into the development build process and operates directly on JavaScript code. JSDefender also supports other languages that “transpile” to JavaScript, such as TypeScript. JSDefender can protect JavaScript running in the browser, on servers/workstations (e.g. NodeJS based applications), and on mobile devices (e.g. React Native applications).

The JSDefender 2.4.0 release brought several changes to the protection runtime which makes the protected code of our customers much harder to reverse-engineer.

Also, it extends the Control Flow transform with an option called “injectFakeCode” that injects fake test conditions to the control flow statements to mislead and confuse the attacker.

Additionally, the release fixes some bugs in the error script parsing of the runtime checks and in the Control Flow transform.

Product Links