Categories
Support Corner

Remove Log4J calls with DashO’s Method Call Removal

Reading Time: 3 minutes

As we all know Log4j is a ubiquitous piece of software used to record activities in a wide range of systems found in consumer facing products and services. The discovery of the recent vulnerability in the Java logging package (CVE-2021-4428) This risk posed a severe threat to millions of consumer products from enterprise software to web applications. It presents risk of loss, or breach of personal information, financial loss and irreversible reputation harm. Currently, the FTC is taking action to require organizations to settle any associated risk caused by the known vulnerabilities. The FTC is now noted as using its full legal authority to pursue companies that fail to take reasonable steps to protect consumer data from exposures. 

A recent example of this negligence came on the back of a complaint in regards to Equifax’s failure to patch a known vulnerability which irreversibly exposed the personal identifiable information of 147 million consumers. This resulted in Equifax paying $700 million to settle the actions taken by the FTC and the consumer financial protection bureau. The risk for businesses is therefore clear, take actionable steps to remediate the vulnerability, or face litigation, breach risk and reputation damage.

In this guide, we will walk you through how you can use Method Call Removal to mitigate this vulnerability.

Method Call Removal

Method Call Removal has been available since our DashO 6.11 release.  It is mostly used for removing logging statements, but it can be used to strip any method calls we’d prefer not to have in our production release.  The only caveat is that the method definition must also be in DashO’s input.

Let’s assume Log4j is used for our application’s logging.  We might want to remove all log statements from production builds, then create special debug builds with logging enabled as needed.  Or, we might want to remove Info, Warn, and Debug messages, but retain Error or Fatal message in our production build.  This can be done using DashO’s Method Call Removal feature, without needing to adjust the Log4j configuration.

Please consider the following example:

This application logs informational messages when the app starts, and when it shuts down.  

The Log4J configuration has been organized into a global logging class:

In our DashO project, I’ll select the “LogInfo” method for method call removal:

Graphical user interface, text, application
Description automatically generated

After doing so, the application runs normally, but informational messages are no longer logged to console or written to log file.

After the app has been in production, I may need to create an obfuscated debug build for troubleshooting an issue with a specific client.  If so, I can run DashO without Method Call Removal to preserve logging calls in my debug build.

The above 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
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
Press Releases

New Release: PreEmptive DashO 11.2.1

Reading Time: < 1 minute

Professional-grade Application protection With PreEmptive DashO

You asked, we delivered: Announcing a new minor release for PreEmptive DashO

Obfuscation is more than just renaming! PreEmptive DashO is a layered obfuscation approach to provide your Java, Kotlin & Android applications with the security protection you need.

In the latest update, our development team has rolled out some new enhancements, changes and bug fixes. What’s New?

Version 11.2.1 includes:

  • Enhancements
  • Validate the Modifiers input fields in the Config Editor for Include & Exclude rules
  • New option for Properties with filesystem path values that opens a system browse dialog
  • A new dropdown for Android mode projects allowing easy switching from configured build variants and their associated inputs in the Config Editor.
  • Changes
  • The Config Editor now opens the last project on startup by default
  • Bug Fixes
  • Fixed an issue where input Jars with the same name could overwrite each other, if “Merge Inputs” was unchecked.
  • Fixed an issue where the Config Editor allowed selection of some methods for Check injections in Android projects.

Ready to learn more about DashO? Request a quote: Request A Qoute

Categories
101

Top 3 Reasons to Use PreEmptive

Reading Time: 3 minutes

Cyber attacks are part of our everyday discussions and most likely will continue to be present throughout the next 12-18 months. With the rise in nation state attacks, and consistent expansion of IOT tools developers have to stay focused on the prescience of cyber threats. For those who followed our #DataPrivacyWeek on our social platforms, we explained that our personal lives are very much intertwined with our work lives, with many folks working remotely, we are more likely to be part of those data breaches we read in the news, as a side effect of network security risks. In this article we will dive into the primary reasons your team can benefit from PreEmptive to protect your applications. 

While we were focused on supply chain attacks, ransomware threats, we overlooked another but equally prominent risk – mobile app breaches. There were over 200 BILLION mobile application downloads in 2021 and that number will most likely increase as we progress through 2022. This means, if you’re a programmer developing an app or creating a program that consists of custom code, securing your work is more important than ever. Here are the top 3 reasons why you should use PreEmptive to add a security layer to your applications:

Reason 3: Protecting Your Hard Work

We understand the countless hours that go into coding, whether that was spent on debugging, creating or troubleshooting your code’s infrastructure, it takes hard work. Many developers have projects that have been in the works for lengths at a time and have firm deadlines to meet. So when a project is complete it feels like gold! We tend to concentrate on completing our projects and ensuring that functionality/usability is up to standard. But, security is often an afterthought. PreEmptive In-App security features have been helping programmers prevent, detect, and respond to attacks without breaking or slowing down your applications – giving you a peace of mind throughout development. Sure, we all want to complete our projects on time or earlier than expected, but if we treat our projects like we treat our phones by putting a lock on it, then that finish line will look even sweeter. 

Reason 2: Knowing the Functionality of Your Security

Data breaches are a hot topic, so searching for the right security platform has become even more of a priority. One of the factors when searching for the right security toolset – how does it actually work? PreEmptive has a layered approach when it comes to protecting your data. Think of it as building your perfect sandwich starting with the bread (obfuscation), adding the meat (renaming code), then the veggies – lettuce (string encryption), tomato (control flow) and more, topping it off with the condiments (active runtime checks) that monitors tampering, debugs, and more. Now that you know what’s in the perfect “security sandwich,” it’s imperative that you continue to test and secure after each build. This will allow you to have the confidence in your security application.

Reason 1: Becoming another Data Breach Statistic

Every month there is another data breach that is brought to our attention. Which makes you really think, are you choosing the right security platform? How do you know this platform is the right one? Assessing the needs of your company/organization or projects is the first step, next researching security options. Some promise to be “the leading” security platform or the “number one,” but PreEmptive has been in the biz since 1996. That’s over 20 years of securing your applications! Not only do we have the experience, we have hundreds of fortune 500 companies who use PreEmptive, Charles Schwab, FedEx, Census Bureau, Microsoft to name a few. If these companies trust our software, we guarantee that by using us, you won’t become another data breach victim.

In case you still need more information, we encourage everyone to read our case studies to find out how other companies found success in protecting their companies with PreEmptive. We hope this blog has eased your worries, but if you’re not sold try us with a FREE Trial


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

Categories
DashO Change Log

DashO Java Obfuscator Change Log V 11.3 Build 1 – Release Date September 28, 2022

Reading Time: < 1 minute

Enhancements

  • A new option to automatically exclude classes with large methods (larger than 65535 bytes of code after obfuscation) that fail the builds. The option is called “Exclude classes having a method larger than 64K” and adds such classes to the “Global Processing Exclusions” list.
  • A new option to ignore missing entry points.

Changes

  • The ASM Java bytecode manipulation framework library shipped with DashO updated to version 9.3.
  • Apache Groovy library shipped with DashO updated to version 3.0.12.

Fixes

  • Fixed Spring Boot JAR processing.
  • Fixed Spring Boot “Flatten Hierarchy” processing and logging.
Categories
Dotfuscator Pro Change Log

Dotfuscator Professional Edition, Version 6.5.1- Release Date September 22, 2022

Reading Time: < 1 minute

Important Compatibility Changes

  • Dotfuscator distributed as a Nuget package targets .NET 6 instead of previously .NET Core 2.1.
  • Dependencies updated to the newer version of the libraries used by Dotfuscator.
Categories
Support Corner

Support Corner: Protecting .NET Applications That Use Custom Attributes

Reading Time: 3 minutesAttributes are used for many different things in .NET: unit testing, serialization, language interoperability, etc.

.NET also provides the ability to create custom attributes. This can be used for building our own object mapping (ORM), custom serialization mechanisms, or other distinguishing objects for a specific purpose.

Protecting .NET applications that use custom attributes is a seamless process with Dotfuscator. Dotfuscator cloaks attribute definitions and automatically updates references throughout the application, so the name remains hidden. If the attribute is defined in an external library (not included in obfuscation), Dotfuscator automatically preserves the attribute usage within its inputs. 

This default behavior handles most scenarios involving attributes. But there are times when a custom configuration is necessary. Fortunately, Dotfuscator’s rules engine gives us the flexibility to handle any unique scenario involving custom attributes.

Please consider the following example app:

A custom PermissionRequiredAttribute has been created to distinguish features requiring special permission:

After protecting with Dotfuscator, the PermissionRequiredAttribute, along with all references, are hidden:

Equally as important, the app runtime behavior works properly after protection:

The above scenario works great. But other times, Dotfuscator configuration is required. For example, if PermissionRequiredAttribute is loaded by an external reference not included in obfuscation, we would need a rule to preserve PermissionRequiredAttribute from Renaming. 

In another example, types decorated by PermissionRequiredAttribute are serialized, but the deserialization mechanism is not obfuscated. In this case, rather than excluding the custom attribute itself, we would create a rule to exclude any type (or member) decorated by PermissionsRequiredAttribute:

Custom attributes are yet another powerful component of the .NET platform and, when used effectively, save time and lines of code. Protecting apps that use custom attributes is simple when we take note of the guidelines above.

You can download the complete sample code here.


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
Risk Management

Does Obfuscation Affect Code Performance?

Reading Time: 5 minutes

The digital age has built bridges to new frontiers. However, these frontiers aren’t limited to the well-intentioned. Unfortunately, malicious online characters are common, and studies show that a new cyber attack is carried out every 39 seconds. 

 

Such high cybercrime rates imply that keepers of online assets must find ways to protect those assets. In addition, coders face unique threats to their work, given that their products form the foundations of the digital world. Thankfully, there are ways to defend code from being accessed, reengineered, stolen, and abused.

 

Open-source code obfuscation is a security application technique that prevents all forms of hacking and tampering. It takes executed code/data and reorders it, rendering it unidentifiable to hackers and other third parties looking to cause trouble. The benefits of code obfuscation are numerous:

 

  • It defends open-source code information and data.
  • It can eliminate debugging loopholes.
  • It slows down hackers trying to re-engineer programs and applications.
  • It helps protect intellectual property.

 

Although obfuscation has considerable upsides, many ask the question: does obfuscation affect performance? It’s a common defense tactic, but many claim that it harms source code performance and decide that the tradeoff between execution and security isn’t worth it. 

 

It’s important to understand obfuscation, what it accomplishes, and its varying methods to engage in this debate with the necessary information. Only then should someone judge whether it’s the right decision for their digital assets.

 

What Is Code Obfuscation?

 

Code obfuscation is the process of encrypting and complicating lines of code, data, and communication loops. These measures cause hackers immense difficulty in interpreting and changing existing information. Ultimately, obfuscation stymies potential hackers, limiting their access and ability to steal and manipulate.

 

There’s a broad range of methods used to carry out code obfuscation. However, in essence, obfuscation is any method implemented to make source code harder to understand. Intense levels of encryption make it so hackers require more time and resources to figure out the code they’re trying to infiltrate.

 

Renaming Obfuscation

Renaming is one of the most common and accessible forms of obfuscation. This method is used in Java, IOS, Android, and NET. Renaming code consists of disguising the variable and method names while retaining the fundamental execution. It’s useful because it directly alters the source code, leaving the program’s functions untouched. 

 

Programmers can also insert “dummy code,” additional strings of false code that mean nothing and only exist to increase the difficulty of reverse engineering. Another method removes unnecessary and gratuitous lines of code and metadata, which improves performance and shrinks the availability of hackable material. 

 

Data Obfuscation

Obfuscation takes many forms, and another standard method is encrypting stored data that’s layered into the code. This form of security creates a barrier between hackers and the valuable data within the program and memory. Data obfuscation can involve aggregation and storage-based methods. 

 

Then there’s string encryption, which entails encrypting legible strings of code. Then, each time a line of code is needed, it must be deciphered before becoming usable again. 

 

In terms of implementation, data obfuscation is more intense than renaming methods. However, combining both practices leads to amplified security. 

 

Control Code Obfuscation

Plugging in additional control loops causes hackers to lose track of any sense of a program’s patterned intent. Furthermore, tinkering with the flow of the codebase — by entering dead-end statements, for example — leaves hackers struggling to find patterns. These statements create a labyrinth, making it especially challenging to reverse engineer a coding pattern.

 

Many consider control code obfuscation the most effective way to guard their program from hackers because it removes all logic from the code’s flow, confusing those looking to cause harm. 

 

Disadvantages of Code Obfuscation

With the what, why, and how of obfuscation established, it’s time to examine the other side of the aisle: why do some cast a wary eye on the practice of obfuscation?

 

The main weakness cited against obfuscation is that adding extra layers of security bogs down code performance. Some estimate that obfuscation can impact program performance between 10% and 80%. This criticism is reasonable because it’s true: adding obfuscation tactics results in extra layers of complexity and affects performance. But there are important caveats — namely that not all obfuscation methods impact performance to the same extent.

 

Renaming obfuscation rarely impacts code performance as it only deals with the semantic structure. As a result, the program function remains nearly identical after obfuscation. Any resulting performance drop-off from this method is minor, if not non-existent.

 

On the other hand, data and control flow obfuscation can sometimes cause a significant performance reduction depending on the intensity of the encryption. Baking additional safety layers into the data and code flow cause the application to take on extra work to execute its function. However, as opposed to renaming methods, data and control flow provide more comprehensive defense against hackers. 

 

Nothing is guaranteed, and there’s never 100% certainty that obfuscation prevents hacking. Some hackers can overcome even high levels of obfuscation. Nevertheless, obfuscation should always be considered because without it, the results can be severe.

 

Leaving Coding Insecure

The rate at which hackers attempt to steal information makes preparation vital to maintaining online safety. If that’s not a good enough reason, up to $400 billion in capital is lost to online hackers every year.

 

Even though obfuscating code comes with some slight downsides, nothing compares to being left helpless as hackers infiltrate, ruin, and steal the hard work of entire companies.

 

Refusing to obfuscate significantly increases the chances of falling prey to such schemes, which can lead to unimaginable consequences depending on what was left unsecured. Such dangers all but necessitate analyzing programs for weaknesses and finding the right solution to protect sensitive data. 

 

Forming a multi-layered obfuscation strategy is a great way to defend digital property from being stolen or attacked. Anyone looking for best-in-class code obfuscation needn’t look any further than PreEmptive’s vast offering of protective services. Visit PreEmptive’s product page for more information or to sign up for a free trial.

 

 

 

Categories
Dotfuscator

Presenting Dotfuscator 6.5: Major Maintenance Update!

Reading Time: 2 minutes

PreEmptive is pleased to announce the release of Dotfuscator 6.5, a tool used by software developers to protect code from hacking and reverse engineering.

The version 6.5 update is a big one. It addresses various .NET Core, .NET 5, and cross-platform support items, fixes various bugs, and improves performance of the licensing system that was introduced earlier this year. We’ve added new static and dynamic code transforms and injected runtime checks to ensure security in all stages of the development process. We also amplified defense against de-obfuscators and de-compilers.

 

 

Dotfuscator at a Glance

Dotfuscator is a DevSecOps tool that protects .NET applications from reverse-engineering and hacking. Using static and dynamic code transforms and injected runtime checks, Dotfuscator obfuscates source code on .NET, Xamarin, and Windows Platform Apps. 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.

For more information, check out Dotfuscator 101. It’ll walk you through its features and show how the program provides ironclad security against common (and uncommon) software development vulnerabilities.

 

 

 

New Features & Fixes in Version 6.5

The release notes provide fully detailed information about the updates in this version, which include: 

  • Simplified license key use
  • Improved subscription checks  from the license server
  • Status messaging for Dotfuscator CLI and MSBuild integration users
  • Added support for NuGet packages
  • Improved V2 license verification
  • Compatibility with both forward and backslashes
  • Accelerated Dotfuscator GUI build time
  • dnSpy detection
  • Improved support for Nullable Reference Types
  • Updated Xamarin Android Tamper Check to use new APIs
  • Sample project showing how to use Dotfuscator with Azure DevOps
  • Additional samples for non-Windows environments
  • Tamper and Debugging Check for .NET Core 3.1 and .NET 5 apps

 

 

Upgrade or Download a Demo Today!

Every organization developing .NET software needs Dotfuscator in its development process. Data breaches are no longer a maybe. They happen every day to companies of all sizes in all industries. If you don’t protect your code at the onset, you risk becoming just one more data breach statistic.

 

PreEmptive Dotfuscator has been the leader in In-App security since 2003. We serve clients of all sizes, including enterprise and Fortune 500 companies in medical, government, and other industries. This release is supported for licensed users as described in the release notes. We encourage you to upgrade your software to enjoy the new features. And if you haven’t tried Dotfuscator yet, request a demo today.


Categories
Press Releases

Major Updates in Dotfuscator 6.5 Release

Reading Time: 2 minutes

 

Maintenance updates, bug fixes, and new features significantly increase functionality and ease of use.

 

PreEmptive has deployed version 6.5 of its obfuscation and optimization software, Dotfuscator Professional. The latest version continues the legacy of seamless integration into the development environment to protect .NET applications from reverse-engineering and hacking while adding a new variety of static and dynamic code transforms and injected runtime checks to ensure security at every stage of the development process.

 

This release addresses various .NET 5 and cross-platform support items, bug fixes, and cleanup of the new licensing system introduced earlier this year. We also amplified defense against de-obfuscators and de-compilers by making them ineffective against Dotfuscator. See our Change log for more information. 

 

New and updated features include:

  • Simplified license key use
  • Improved subscription checks  from the license server
  • Status messaging for Dotfuscator CLI and MSBuild integration users
  • Added support for NuGet packages
  • Improved V2 license verification
  • Compatibility with both forward and backslashes
  • Accelerated Dotfuscator GUI build time
  • dnSpy detection
  • Updated Xamarin Android Tamper Check to use new APIs
  • Sample project showing how to use Dotfuscator with Azure DevOps
  • Additional samples for non-Windows environments
  • Tamper and Debugging Check for .NET Core 3.1 and .NET 5 apps

 

Whether a start-up company, freelancer or an organization developing projects using .NET software, using this in the development process can prevent theft or catastrophic outcomes. Data breaches happen every day, but being proactive about security will help protect your business. 

 

About PreEmptive

 

PreEmptive is a trusted global leader of protection tools for Desktop, Mobile, Cloud, and Internet of Things (IoT) applications. We help organizations make their applications more resistant and resilient to hacking and tampering while protecting intellectual property, sensitive data, and revenue. For more information, contact our sales team and we can walk you through a demo!


 

Categories
Dotfuscator Pro Change Log

Dotfuscator Professional Edition, Version 6.5.0 – Release Date September 13, 2022

Reading Time: < 1 minute

Enhancements

  • Tamper Check support is added for .NET Core 3.1/.NET 5+.
  • Debugging Check support is added for .NET Core 3.1/.NET 5+.
  • Additional license status messages are displayed in the CLI and MSBuild output.
  • Changing the Product License does not require the client to be restarted anymore.
  • The new signing methods are used instead of the deprecated ones for Android Pie (API Level 28) and newer OSes with Tamper Check.
  • Added a Readme file for the Dotfuscator NuGet package for a more seamless setup experience.
  • Added a new “force_nuget_tools” global option.
  • [This release may include protection enhancements not described here]

Functional Changes

  • Merged the Evaluation (Free Trial) and Professional version clients so that the PreEmptive Licensing Server tells the client how to behave. The client does not have to be reinstalled upon upgrading from Evaluation to Professional anymore.
  • Forward slashes are being used by default in the config file for better cross-OS support.
  • Version “6.0.0” of Microsoft.NETCore.ILAsm and Microsoft.NETCore.ILDasm NuGet packages are used by default (instead of “5.0.0” in the previous version of Dotfuscator), unless you override this value in the “DOT_ILTOOLS_CORE_VERSION” property.

Fixes

  • Display that Linking is not supported for .NET Core/.NET 5+ projects instead of displaying an unrelated error message.
  • Fixed an issue when Root Check for Xamarin.Android returns false-positive results on certain Android devices.
Categories
DevSecOps

10 DevSecOps Best Practices to Implement Now

Reading Time: 5 minutes

Organizations are under constant pressure to deliver software faster and more efficiently. In response, many have turned to DevOps, a set of practices that emphasizes communication, collaboration, and integration between software developers and IT operations professionals.

However, simply adopting DevOps practices is not enough to ensure success. To truly reap the benefits of DevOps, organizations must also adopt a security-minded approach known as DevSecOps.

DevSecOps is a set of practices that focus on integrating security into the software development lifecycle. By automating code scanning, defect reporting, and incorporating security into the development process, organizations can reduce the risk of vulnerabilities and ensure that their applications are secure.

In this article, we will discuss 10 DevSecOps best practices that your organization can implement now.

10 DevSecOps Best Practices To Implement Now

The speed and complexity of modern software development have made it necessary for organizations to adopt DevSecOps practices in order to remain competitive. DevSecOps is a set of best practices that seek to integrate security into the software development process. By doing so, organizations can more effectively secure their applications and reduce the risk of defects.

There are many DevSecOps best practices that organizations can adopt, but some are more important than others. Here are 10 of the most important DevSecOps best practices to implement now:

1. Shift Left

The first and arguably most important DevSecOps best practice is to shift security left. What this means is that security testing should be integrated as early as possible into the software development process, rather than tacked on at the end. By doing this, security risks can be identified and mitigated much more effectively.

2. Implement Continuous Integration and Continuous Delivery

If you’re not already using continuous integration (CI) and continuous delivery (CD), now is the time to start. CI/CD are key components of DevOps, and are essential for implementing DevSecOps best practices.

With CI/CD, teams can automatically build, test, and deploy code changes. This helps ensure that code changes are integrated and delivered quickly and efficiently. It also helps reduce the risk of human error.

3. Implement Obfuscation Techniques

One of the best ways to protect your code from being reverse engineered is to use obfuscation techniques. Obfuscation is the process of making code difficult to understand, to obscure its meaning If you will. Doing so makes it more difficult for attackers to understand the code and find vulnerabilities.

Many different obfuscation techniques can be used, such as code encryption, code compression, and white-box cryptography.

4. Threat Modeling

Threat modeling is the process of identifying, quantifying, and prioritizing the risks to your systems and data. It’s a key part of DevSecOps, and it’s important to do it early and often.

There are many ways to approach threat modeling, but one popular method is the STRIDE method. This involves identifying six different types of risks:

  • Spoofing – When someone pretends to be someone else
  • Tampering – When someone modifies data
  • Repudiation – When someone denies having performed an action
  • Information disclosure – When someone gains access to data they should not have
  • Denial of service – When someone prevents legitimate users from accessing a system
  • Elevation of privilege – When someone gains access to a system or data to which they should not have access

5. Adopt a Microservices Architecture

One of the key benefits of DevSecOps is that it enables you to adopt a microservices architecture. This means breaking up your monolithic applications into smaller, more manageable services.

There are several benefits to this approach:

  • Services can be developed, tested, and deployed independently
  • Services can be scaled independently
  • Services can be updated without affecting the rest of the application

A microservices architecture also makes it easier to implement security controls. For example, you can deploy security controls at the service level, rather than at the application level.

6. Use Cloud-native Technologies

The world is moving to the cloud, and so is DevOps. But DevOps in the cloud is different than DevOps on-premises. When DevOps teams move to the cloud, they need to use cloud-native technologies.

Cloud-native technologies are those designed to run in the cloud. They are built to be scalable, fault-tolerant, and easy to manage.

Some of the most popular cloud-native technologies include:

  • Containers (Docker, Kubernetes)
  • Microservices
  • Serverless computing
  • NoSQL databases (MongoDB, Cassandra)

If DevOps teams want to be successful in the cloud, they need to use these cloud-native technologies.

7. Encrypt Data in Motion

Another important DevSecOps best practice is to encrypt data in motion. This means that data should be encrypted when being transferred between different systems. This is important because it helps protect the data from being intercepted and read by unauthorized people.

8. Implement Role-based Access Control

Organizations need to trust that the right people have access to the right information at the right time. Role-based access control (RBAC) is a security model that can help accomplish this. RBAC can be used to control who has access to what resources in an organization. It can also be used to control what actions users can take with those resources.

RBAC is an important part of DevSecOps best practices because it can help prevent unauthorized access to sensitive data and systems. It can also help ensure that only authorized users can make changes to systems and data.

9. Monitor and Log Activity

To ensure your system is secure, it’s important to monitor and log all activity. This way, you can see what’s happening on your system and identify any potential issues. By monitoring and logging activity, you can also detect patterns of behavior that may indicate an attempted attack.

10. Implement DevOps at All Levels of the Organization

The success of DevOps implementation cannot be overstated. In order to truly reap the benefits of DevOps, it must be implemented at all levels of the organization. What this means is that everyone, from the CEO to the front-line workers, must be on board with the DevOps philosophy. This can be a challenge, but it’s important to remember that DevOps is about culture first and foremost. Only by getting everyone on board with the culture change can an organization hope to fully reap the benefits of DevOps.


Getting Started

It’s easy to see how following best practices can help keep your software development process safe and secure. Implementing these 10 DevSecOps best practices is a great way to get started, but it’s only the beginning.

Make sure you also have the right tools in place, like PreEmptive Solutions‘ products, which make it easy to follow standard processes and ensure that your code is always up-to-date and compliant.

Want to learn more? Check out our product pages for more information on how we can help you stay safe and secure while you develop amazing software.


Categories
DevSecOps

Defining Data Obfuscation and How It Works Within Your Development

Reading Time: 5 minutes

Nowadays, the stakes of cybersecurity are higher and the methods of data breaches are becoming more sophisticated. Cyberattackers are inventing more lethal data breach strategies such as reverse engineering tools, decompilers, and disassemblers.

In response, developers must take extra steps to ensure the safety and security of their code and their users’ data. The healthcare industry is the most targeted by hackers, followed by the financial services and retail sectors. According to a study cited by the National Library of Medicine, there were 2216 incidences of data breaches reported across 65 countries in 2018 alone. Among these data breach incidences, the healthcare industry faced 536 breaches. 

Software development is one of the most affected industry sectors. In fact, data from the recent IBM report showed that software development was the target of 44% of all ransomware attacks in 2021. Findings from research conducted by Positive Technologies show that mobile banking applications are the most affected by cybercrime. The study also showed that common cyberattacks and cyber vulnerabilities are caused by names of classes and methods explicitly written in the source code, without being masked or encrypted through methods such as code obfuscation.

The need for masking is increasing as stakes in cybercrime rise. Data from CBinsights shows that data masking will grow to be an $800M industry by 2023. As you can see, data obfuscation is important for many reasons. Not only does it protect your intellectual property, but it also helps to keep user data safe and secure.

What Is Data Obfuscation and Why Should I Care?

So, what is data obfuscation? In their guide, Brunton and Nissenbaum define data obfuscation as “the deliberate use of ambiguous, confusing, or misleading information to interfere with surveillance and data collection projects.” In simple terms, it is a method of hiding data by making it difficult to interpret. App hardening is an excellent example of the use of data obfuscation and protection. It’s a technique used to protect information by making it unreadable and unusable to anyone who doesn’t have the proper key to unlock it.

This is accomplished by using some of the best practices of data protection such as encryption, code transformation, and watermarking. In the software development world, data obfuscation is important. It assists software developers to protect intellectual property, ensure the safety of user data, and prevent reverse engineering. For instance, software developers can prevent intellectual property theft through encryption. By encrypting code, it becomes much more difficult for non-authorized people to copy it or reverse engineer it.

The use of data obfuscation is becoming increasingly relevant, especially as businesses and start-ups move to the online space. A survey conducted by 451 Research LLC revealed that data obfuscation techniques are on the rise, partly due to accelerating DevOps and as developers’ access to production data rises. Findings from the survey revealed that 53% of organizations interviewed used data obfuscation methods to protect the organization’s developer infrastructure. However, mobile developers seem to be lagging behind in adopting data obfuscation strategies to prevent data breaches in their development activities. According to research by the Association for Computing Machinery, only 24.92% of the 1.7 million free Android apps from Google Play are obfuscated by the developers.

This is a concern because, as the number of mobile devices and apps increases, so does the risk of data breaches. A recent study by Kaspersky shows that nearly one-in-five (17% of internet users) have had private information leaked to the public without their consent. With the increasing number of data breaches, it is becoming more important than ever for developers to take measures to protect their code and user data. One way to do this is through data obfuscation.

Five Types of Software Vulnerabilities That Affect All Developers

As a developer, it is important to be aware of the different types of software vulnerabilities that can affect your code. By understanding these vulnerabilities, you can take steps to avoid them and keep your code safe. Here are five common software vulnerabilities:

1. SQL Injection

SQL injection is a type of attack that allows attackers to execute malicious SQL code on a database. This can be done by submitting malicious input into an application that then gets executed by the database. SQL injection can be used to access sensitive data, such as user passwords and credit card numbers. SQL injection can be prevented by using data obfuscation techniques, such as string encryption, and parameterized queries.

2. Cross-Site Scripting (XSS)

Cross-site scripting is a type of attack that allows attackers to inject malicious code into a web page. This can be done by submitting malicious input into an application that is then displayed on the web page. XSS can be used to steal sensitive information, such as cookies and session IDs. It can also be used to inject malicious code into the web page, such as JavaScript code that redirects users to a malicious site.

XSS can be prevented by using data obfuscation techniques, such as input validation and output encoding. Input validation involves checking user input to ensure that it is valid before it is displayed on the web page. PreEmptive’s Dotfuscator uses input validation to verify the application’s integrity during runtime.

3. Cross-Site Request Forgery (CSRF)

Cross-site request forgery is a type of attack that allows attackers to inject malicious code into a web page. This can be done by submitting a malicious link or form to a user. CSRF can be used to trick users into submitting sensitive information, such as their username and password. It can also be used to inject malicious code into the web page, such as JavaScript code that redirects users to a malicious site.

CSRF can be prevented by using data obfuscation techniques such as input validation and output encoding. Input validation involves checking user input to ensure that it is valid before it is processed by the application.

4. Session Hijacking

Session hijacking is a type of attack that allows attackers to take over a user’s session. This can be done by stealing the user’s session ID. Session hijacking can be used to access sensitive data, such as user passwords and credit card numbers. It can also be used to modify data, such as changing a user’s password or adding new users to a database. PreEmptive’s Dotfuscator is the best app shield against session hijacking.

5. Denial of Service (DoS)

Denial of service is a type of attack that prevents users from accessing a website or service. This can be done by overwhelming the website with traffic or by crashing the server. DoS can be used to make a website unavailable, such as by preventing users from being able to access the website or by slowing down the website so that it is unusable. Denial of service can be prevented by using data obfuscation techniques, such as input validation and output encoding.

Data obfuscation is an important tool that any developer should use in developing security application. By using data obfuscation techniques, such as input validation and output encoding, developers can make it much more difficult for attackers to inject malicious code into their web pages. This can help to prevent a wide range of attacks, including SQL injection, cross-site scripting, CSRF, session hijacking, and denial of service.


Don’t Let Your Data Fall Into the Wrong Hands

Data obfuscation is a critical step in software development, yet too often it is neglected. By understanding what data obfuscation is and how to apply it, you can protect your applications from hacking and tampering. PreEmptive’s comprehensive suite of obfuscation tools can help you secure your DevSecOps pipelines and investments. With our help, you can protect your systems and keep your data safe. Contact us today to learn more about our products and services!


Categories
Risk Management

How Your Android App Can Be Stolen for Hacking

Reading Time: 5 minutes

Android is the most common mobile OS by far, cornering 87% of the market share — a number which is expected to grow. Android’s open platform and extensive library of resources make it easy for developers to create and integrate new apps. However, the same features that make Android easy for developers to use also make it easy for hackers to exploit

Android apps have become the most widely used alternative to desktop software. Because apps are used for banking, shopping, and transmitting personal information, they’re a prime target for cybercriminals. One of the most common methods hackers use to carry out various attacks is reverse engineering your code.

1. Reverse Engineering

Android’s open environment makes it an easy target for reverse engineering. Reverse engineering analyzes an app to figure out how it works and its design and implementation process. This is done by examining the compiled code, observing the app during runtime, or both. There are numerous free tools available to reverse engineer the binary code of Android apps. 

Attackers can use reverse engineering to steal your intellectual property, modify your code, attack your back-end systems, discover security vulnerabilities, and gain access to confidential data. The first step in almost all Android hacking attempts is reverse engineering the code. 

2. Repackaging Attacks

Repackaging, or cloning, attacks are a problem for apps of all sizes. Hackers often take good but not very popular apps and reverse engineer their code. They then modify the code to suit their purpose, which could be embedding malware to steal credentials or ad revenue. The modified code is then repackaged, and consumers may be convinced to install it, thinking they’re installing a trusted app. Another variation of the repackaging app is when hackers rebrand an app and publish it as their own, often making more than the original developer. 

3. String Table Analysis

String tables are frequently used for storing sensitive information such as license keys, credentials, and other confidential data on both the client and server sides. Hackers can analyze the string tables to gather information, identify algorithms, understand database designs, and more. The string table may contain the data they want to steal, or they may use the information they gather to launch a different type of attack. 

4. Functional Cross Referencing

Cross-referencing can help hackers determine where a particular function was called from. They can use that to detect vulnerable code they can use to execute malware or find the code that does the encryption of data they want to steal. Cross-referencing can show how information was accessed, which is invaluable to hackers trying to steal intellectual property, sensitive data, or insert malicious code. 

5. Debugging and Emulator Attacks

Hackers can use debuggers and emulators for dynamic analysis during runtime. Using these tools, they’re able to identify vulnerabilities and exploit them with runtime attacks. Unlike the other methods, these attacks require active hardening. Your app needs to be able to modify its behavior and response during runtime if an active threat is detected. 

Preventing Reverse Engineering With Obfuscation

Almost any code can be reverse-engineered given enough time and resources. However, obfuscating your code can make it more difficult, expensive, and time-consuming for hackers to reverse engineer. The free decompilers make it extremely simple for hackers to reverse engineer code that isn’t obfuscated. 

If your code is obfuscated, hackers are more likely to give up and move on rather than investing time and money into reverse engineering the source code. Code obfuscation can consist of a number of different techniques designed to disguise your code from hackers while not interfering with its execution. 

Data obfuscation 

Data obfuscation scrambles data via tokenization or encryption to make it unreadable to hackers. 

Code obfuscation 

Obfuscating your code makes it look like unusable nonsense to hackers. There are many ways to obfuscate your code, and your hardening process should use a layered approach to make it harder to crack. At PreEmptive, we employ a range of different obfuscation techniques to provide a high level of security. 

Our DashO security application provides passive hardening through the following types of code obfuscation: 

Rename obfuscation 

Renaming changes the name of methods and variables. 

String encryption 

Even when you rename your methods and variables, your strings may still be discoverable. String encryption provides an additional layer of security to your software by making it harder for threat agents to decipher and understand.

Protecting Against Runtime Attacks

Obfuscating your data and code isn’t enough to secure your Android app. You also need to use active hardening to protect against runtime attacks. Some of the methods DashO uses to deflect runtime hacking attempts include: 

Tamper detection and defense

You can prohibit or modify your app’s behavior if it detects an unauthorized attempt to gain access. 

Root detection and defense

Jailbreaking a device compromises the security of your app. Control whether your app will run on a rooted device and how it will respond.

Emulator detection and defense

Running an app on an emulator allows a hacker to understand and analyze an app’s functioning in a controlled environment. DashO can sense when your app is being used in an emulator. You can decide whether or not your app will run in an emulator and how it will respond if it is. 

Hooking detection and defense

Hackers use hooking frameworks to modify your app at runtime without altering the binaries. If DashO detects a hooking framework, the app can respond by shutting down, throwing an exception, or sending an alert, among other options. 


Multi-faceted App Hardening

App hardening

To protect your Android app from ever-evolving cybersecurity threats, you must take a multi-pronged approach. However, hardening your app is pointless if your app breaks as the runtime platform evolves. At PreEmptive, we are constantly monitoring, testing, and upgrading our solutions to protect your app from runtime issues and to respond to new hacker threats and tools.

Your organization can’t afford the expense, exposure, or possible brand damage associated with having your app hacked. Contact us today to find out how our solutions can integrate with your current DevOps practices to provide the security and protection you need.