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 V11.3 Build 0 – Release Date May 23, 2022

Reading Time: < 1 minute

Change Log – Version 11.3.0 – Release Date May 23, 2022

Enhancements

This release may contain protection enhancements not described here.

  • Added native support for WAR inputs without the need for complex scripts to extract before protection and repackage after protection. The classes are automatically treated as inputs and the libraries as support libraries inside the WARs.
  • Added native support for Spring Boot Jar and WAR projects. The classes are automatically treated as inputs and the libraries as support libraries inside the Spring Boot Jars and WARs based on the Manifest file.
  • All the protection features are working now with plain WARs and Spring Boot Jars and WARs including Obfuscation, Checks, Watermarking, Signing.
  • The "Entry Points – Libraries" screen is now merged with the "Input" screen where Libraries, Extensible Libraries, and Spring Boot inputs can be configured with the new Handler property.
  • Updated the Web project wizard to easily configure plain WARs and Spring Boot Jars and WARs.
  • Added a Spring Boot sample to our public samples repository to showcase how to configure a Spring Boot project.

Changes

  • The "Entry Points – Libraries" screen is now merged with the "Input" screen where Libraries, Extensible Libraries, and Spring Boot inputs can be configured with the new Handler property.
  • The ASM Java bytecode manipulation framework shipped with DashO updated to updated to version 9.2
  • Apache Groovy shipped with DashO updated to version 3.0.9.

Fixes

This release may contain protection enhancements not described here.

  • Validate Modifiers input fields in the Config Editor for Include and Exclude rules.
  • Added an option for Properties with filesystem path values to open a system Browse dialog to choose the path.
  • Added a dropdown for Android Mode projects to switch between configured build variants and their associated Inputs in the Config Editor.
  • Added Japanese Documentation.
Categories
Risk Management

Common Mistakes Developers Do When Building Apps

Reading Time: 5 minutes

With the rapid rate at which new apps are popping up, it goes without saying that app development is becoming increasingly popular. Over 143 billion apps were downloaded in 2021 alone. However, not all apps garner the success their developers may have initially hoped to achieve. Many end up getting uninstalled after their first use.

The competitive market is partly to blame for this. But mistakes that occur during the application development process are to blame as well. Here, we’ll go over eight of the most common mistakes developers make so that you can avoid them and position your app for success. 

1. Skipping Over Research

After coming up with or hearing an idea for an app, many developers want to dive right into bringing the vision to life. However, rushing in without research can lead to numerous issues and wasted money. 

Successfully developing and marketing an app relies on user research. Is there a need for the app? If so, who is the target audience — what are their demographics? And what are their typical behaviors and motivations?

Competitor research is also critical. If they’re also developing an app — or if they already have one — then keeping tabs on what they’re up to will help you create something unique and appealing. 

2. Striving to Create a “Perfect” App

There’s nothing wrong with wanting to create a great app that users will love. In fact, that’s usually the point. There’s no such thing as a “perfect” app, though. Trying to create something that’s free of all flaws could lead to a never-ending development cycle. Ultimately, you may never launch it. 

That doesn’t mean you can’t strive to develop an app that continues to improve over time. One way to do this is by creating a minimum viable product or MVP. An MVP is a version of an app that only includes the essential features it needs to work. You can then release it to early adopters who can assess its functionality and performance. Their feedback allows you to create a better final product, avoid time and budget waste, and may even speed up the time to launch. 

3. Failure to Test Properly

Testing is a critical component of the software development lifecycle (SDLC). It ensures a smooth, pleasant user experience and helps developers squash “bugs” before launch. The problem is that several challenges still exist

There are several strategies for dealing with common testing challenges. Here are a few that may help:

  • Develop a solid testing process that includes how often you’ll test an app and who will do it. 
  • Consider using in-house and outsourced testing experts. 
  • Make sure you have all of the proper tools to run tests.
  • Make sure there’s ample time to devote to testing (schedule it if you have to). 

4. Creating a Poor User Experience

It’s not uncommon for developers to get so entrenched in the development process that they forget about how users will interact with an app. Unfortunately, that mistake can be costly. A poor user experience is one of the top reasons people uninstall apps. 

Several issues can impact an app’s user experience, including:

  • Slow loading speeds
  • Difficult to navigate (it takes too many clicks for users to find what they need)
  • Unnecessary log-in pages
  • Intrusive ads
  • Low-quality content
  • Boring design

An essential consideration for a good user experience? The user! Put yourself in their shoes when assessing the overall experience. The feedback you get from your MVP version can come in handy, too.  

5. Trying to Squeeze Too Many Features and Functions Into the App

Unique features and functions that serve a purpose for app users are great. Trying to squeeze in too many, however, can be detrimental. 

For one thing, the more features you add, the more expensive the project becomes. Excessive features can bog the app down, hindering its performance and ruining the user experience. The app can also become too large and require too much space on users’ phones.

When determining what features to add to an app, consider if they’re necessary first. Leave out the ones that don’t offer any value. If you start hearing a call for specific features from users, you can add and optimize them later. 

6. Building for Every Possible Platform

You might feel tempted to develop your app for every possible platform right out of the gate. After all, it’s a surefire way to attract more users.

But trying to tackle multiple platforms from the start could quickly destroy your budget. It can also be incredibly time-consuming. Instead, consider starting with one platform — basing your decision on market research — and expanding to others after your initial launch. 

That doesn’t mean you can’t develop an app for more than one platform to start. Make sure that you have a cross-platform strategy, though. For instance, you could use a single source code on a cross-platform app development tool to deploy on Android and iOS devices. 

7. Ignoring Feedback 

Feedback has come up a couple of times already. Listening to what your app users have to say is critical for building an app that they want to use. It’s about more than just listening, though. It’s also about using that feedback to improve your app with each update. Along with eliminating pain points for your users, using customer input lets them know you care. That’s one of the best ways to earn their loyalty. 

What happens if you don’t listen? User satisfaction decreases, and people start uninstalling your app in favor of something else.

8. Neglecting the Importance of Security

A recent survey found that 86% of developers don’t view security as a top priority when writing code. Half of the respondents also said they wouldn’t be able to guarantee their code to be safe from common vulnerabilities. 

Hackers don’t only attack websites. Some can reverse engineer mobile apps to inspect them while they work or capture communications between an app and server. They can also use code-based attacks to steal data, get around security checks, or compromise your app’s integrity. 

Prioritizing security is a must. One way to do this is with comprehensive mobile app protection with PreEmptive. Applying a layered approach, PreEmptive Protection uses obfuscation, encryption, tamper-proofing, and more to make your apps more difficult for potential hackers to exploit. It integrates seamlessly into your build process and requires no code changes. Best of all, it goes wherever your apps go. 


Avoid Common Mistakes for Better Apps People Love to Use

App development can be a time-intensive and sometimes frustrating process. Even the best developers make mistakes from time to time. Understanding the most common ones can help you avoid them or manage them more effectively if they do happen. 

If you’re looking for ways to make your apps more secure, PreEmptive is here to help. Visit our products page for more information about our app protection, or check out our resources to see what else we can do for you!


Categories
101

Spring Boot: An Overview

Reading Time: 4 minutes

If you develop web or cloud applications in Java, you’ve probably heard about Spring Boot. This convenient tool is found in a huge range of Java applications, supporting them and keeping them running. However, if you’ve never worked with Spring Boot before, it’s not always immediately apparent what it is or how it works. You don’t need to guess anymore. Keep reading to learn what Java Spring Boot does, how it’s used in different applications, and what you need to do to make sure your Spring Boot application has all the security protection it needs to keep your users safe.

What Is Spring Boot?

Spring Boot is a tool designed to make it easier to write applications that run through the Java Spring framework. The Spring framework is an open-source Java framework designed to help enterprises develop standalone applications. The framework is structured to support applications for Java Virtual Machine (JVM) installations. 

Spring Boot makes that process simpler by offering three critical features for app developers:

  • Supports the standalone nature of Spring applications
  • Implements automatic configuration of Java libraries when possible
  • Provides an “opinionated” set of starter configuration beans for apps

Essentially, Spring Boot helps you bootstrap the development of your application by handling many of the behind-the-scenes concerns for you. Using Spring Boot, you can get quickly get started on development proper and waste less time setting up the basic Java Spring framework requirements. This makes it an excellent tool for any developer who wants to increase productivity and ship applications faster.

How Does Spring Boot Work?

Spring Boot accomplishes all that it does by setting up a microservice architecture within the Spring framework. Microservices are small, independent programs within a larger application that can either produce or consume data. In the case of Spring Boot, it produces data based on best practices and your pre-configured settings to handle many tasks automatically. 

For instance, the microservice nature of Spring Boot allows the tool to automatically set up a basic set of beans for an application. Depending on what jar dependencies you’ve included when you initialize Spring Boot, it will take that input and automatically find and include any beans you’ve left out that may be necessary. If, for example, you don’t include any database support beans in your application, Spring Boot will quietly implement them in the background. 

Similarly, it will autoconfigure the libraries that you add based on your settings. When possible, any libraries that you add will be configured to fit the settings and other libraries involved. 

Just as importantly, Spring Boot allows you to override any auto-configurations easily. If, at first, you allowed the program to configure embedded database support, you can replace it just by adding your own datasource bean. 

Setting up a Spring Boot application is easy, too. The Spring.io project offers a Spring Initializer that lets you input all of your important pre-configurations and generate a project file in which you can start writing right away. There’s no need to waste time putting together the base file. Spring does it for you.

Examples of Spring Boot Applications

Spring Boot is most commonly used for web and cloud applications. GitHub is full of excellent examples of applications developed using Spring Boot, such as:

  • Web Applications: The Spring.io website has been built using Spring Boot, so it perfectly demonstrates what the tool looks like in action. The code is up on GitHub, so you can explore how the tool was used to simplify the site’s setup.
  • Internet of Things (IoT) Applications: Spring Boot can kickstart IoT applications. A great example of how the tool can be used for IoT programs is the IxorTalk library, which can be quickly added to any Spring framework project to connect the app to Microsoft Azure and Amazon Web Services IoT offerings.

Still, Spring Boot isn’t perfect. Before you implement the tool in your next application, it’s essential to understand the potential drawbacks of Spring Boot and how to mitigate them. 

The Importance of In-App Protection for Java Spring Boot

Spring Boot has many benefits, but one thing it lacks is automatic security features. While the Spring framework does have some simple security options, they aren’t particularly thorough. Furthermore, you’ll need to continually update your app’s security whenever new threats appear.

You need to make sure your app has more protection than that. The solution is to implement your own in-app security. Hardening your app against security threats requires you to include features like:

  • Obfuscation. If your app contains any kind of private data, it needs to have obfuscation features. You should look for app security solutions that offer multiple forms of obfuscation, such as renaming, encryption, and control flow. This will help you protect everything from login credentials to personal user data.
  • Runtime checks. It’s just as important to ensure your applications aren’t tampered with. Runtime checks let your applications confirm whether or not they have been altered before they start any sensitive tasks. Furthermore, they can help you shut down the app if any unauthorized tampering occurs, helping you avoid data loss.
  • Regular updates. If you want your app to remain safe in the future, you must implement a security solution that will stay up-to-date. The best security solutions automatically update to continue protecting your applications whenever new threats appear.

PreEmptive’s DashO offers all of these features and more. You can add DashO to your Spring Boot application to ensure that it’s secure today and years from now.


Protect Your Spring Boot Application With PreEmptive

Spring Boot is an invaluable tool for Java developers who like the Spring framework. However, it’s important to have proper protection built into your program to avoid common risks native to the framework. That’s where PreEmptive can help. 

With PreEmptive’s DashO, you can protect your application from unnecessary security risks and keep things secure. It’s as easy as following a few simple instructions to ensure your application has built-in hardening protections to keep user data safe. You can learn more about how PreEmptive can help you protect your Spring framework application or get started with DashO today. 


Categories
101

PreEmptive – JSDefender 101

Reading Time: 3 minutes

Did you know JavaScript is used by 13.8 million developers worldwide? This means that 53% of developers either use or have used JavaScript at some point throughout their career. Making this the most popular coding language in web and cloud development. As programming languages are an essential tool, they are a critical security & quality priority that all developers are focused on. And since programming languages are also opportunities for attack, it is essential to implement obfuscation protection as preventative measures to protect your work from being copied, attacked or leveraged to cause further damage.

Just like in our previous 101’s for Dofuscator for .NET, in this article we explain how JSDefender for JavaScript can help secure and protect your work using obfuscation techniques with additional layered security.

What is the Product used for?

Similar to Dotfuscator for .NET, JSDefender is primarily used to protect and harden your applications that are composed of JavaScript. It encrypts your projects through a layered approach. Javascript is commonly used and as the risks of hacking continue to expand, it’s more proficient to implement code security at the early stages of development. In other words, by not using some sort of cybersecurity, it is like leaving your phone on the table and unlocked for the world to see what you’re up to. But, on this scale it is not just your data that is exposed, but the entirety of your users data and product IP.

How does JSDefender work?

JavaScript apps are typically distributed in source form, meaning your code can easily be visible to anyone with access to a browser. If a project isn’t protected, a hacker can conveniently use a debugger (that is built in their browser) along with other sophisticated tools to analyze your code for vulnerabilities – which highlights the path of hijacking your project. JSDefender uses a layered approach that is applied to the binary code using obfuscation, encryption, tamper detection, domain locks, debugger removal, function recording and more, basically scrambling the source code making this very difficult for the average hacker.

When should you use JSDefender?

Anyone who is developing an IoT (internet of things), mobile/desktop application, SaaS (software as a service), or any system software program using JavaScript as your language of development, should be using JSDefender. It’s widely known that investing in DevSecOps (development security operations) is of increasing importance for not only companies, but freelancers as well. There is not an industry that has not been affected by a data breach, and any company who uses or has built a website should know the importance of investing in DevSecOps. We did a case study of GlobalMed who used JSDefender in order to protect their advanced virtual health platform and now they have become the world’s number one telemedicine company!

Where does JSDefender work?

JSDefender is injected directly into your source code. You can specify your own configuration file or use command line options to set up protection attributes. It takes minutes to set up and seconds to begin securing your source file. We have developed a demo so that you can visually see how this works in real time!

JSDefender demo

Why should you use PreEmptive JSDefender?

By using JSDefender you are taking action against any type of attacks to your JavaScript projects by obscuring and managing your vulnerabilities directly in your code within a matter of seconds. We know time is of the essence in development, but implementing security in the beginning of the SDLC saves you time, money and protects your reputation in the long-run. Waiting until the end to scan for vulnerabilities will only prolong the development cycle and you will end up running into issues that could have been avoided if security was part of the process early on. JavaScript is here to stay and as the world of tech advances, so will hackers. So if you feel that your DevSecOps isn’t up to par or stressed about being hacked, download a free trial by visiting our product page and start protecting your intellectual property today!


For more information on how to get started or need further help, we encourage you to use our resources, found in our navigation bar. We hope this blog has guided you to better understand JSDefender for JavaScript. Be on the lookout for our upcoming 101’s! 


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

Reasons to Invest in DevSecOps

Reading Time: 3 minutes

As you know by now, devsecops are commonly talked about by experts across the board, now more than ever as new companies, freelancers and other entities merge into the tech space and increase their reliance on IOT solutions. With all the cyber attacks that have been increasing every 6 months, development security operations have pivoted in the forefront of company investments. That is why it is crucial to not skip out or budget in security measures for your fiscal year. But why should you invest in the first place?

#3: Automation Speeds up Development Process

Working on a large project can be gruesome, but not having it secured is like leaving your wallet on the table to be snatched up. We understand that time is a key factor in the development process, so it should be a no-brainer for companies or developers to seek out a devsecop tool that works in their favor without jeopardizing function. But how can this be achieved? Automation of course! Shift your security to automated testing speeds up your development process providing quicker response time to help pinpoint and solve problems. Just like DevTools, DevSecOps are very similar. They both need automation and by shifting security measures to this, ensures best practices with your IT team.

 #2: Replaces the one-off Security Assessments

Usually security is probably at the last stages of your development cycle and while other companies only look at this quarterly, which only sets you up for a breach. DevSecOps changes this dynamic by securing your projects from the start. It replaces that one-time snapshot of your code by consistently looking at it. And since Devops is driven by code, your security should follow suit, security can easily be integrated in your CI/CD pipeline. Shifting your best practices by investing in DevSecOps takes your team from examining problems at the end to testing each week. If you know where the weak spots are then you easily fix and repeat this process throughout only making your project rock solid!

#1: Breaking Down Organizational Silos

Silos should be a thing of the past, but can still be found in today’s organizations. There should be no reason that security measures be isolated to only one department, because as you may know, each department is used to handling situations in their own way due to urgent matters. The common corporate “red tape” is consistently boroughed through, so in order for DevSecOps to truly work, everyone and every department need to be following the same measures. Development teams should align and agree on what type of measurements to use or have a set of objects implemented throughout, and not only isolated in one department. By having everyone on the same page your security will be one force to be reckoned with and you won’t have to worry about becoming another victim of cyber crime. 


We encourage everyone to read our case studies to find out how other companies found success with PreEmptive in their DevSecOps. PreEmptive has been blazing the trail in devsecops division for quite some time. Not only do we have a long company history, but our products are used by Fortune 500 companies worldwide. We hope this blog has helped you solidify the decision to invest in your DevSecOps process, but if you’re not sold try us with a FREE Trial!


Categories
Risk Management

The Risks Of Not Using In-App Protection

Reading Time: 4 minutes

Businesses of all types rely on applications, in fact they have become the central way the majority of us live our lives. From online banking, to filing your taxes on your phone or attending a virtual doctor’s appointment. Every element of our lives is navigated by a mobile or desktop application

It’s not just users, companies are also reliant on applications. Using them to manage central operations, production, fulfillment and marketing. Organizations use applications in a myriad of fashions, by the same token every application adds further risk. 

Businesses are shifting online to meet emerging needs but are also being faced by an emerging risk landscape with expanding risk across the Internet of Things. Application protection as such is an essential component to protect every element of your organization. IP Theft, application attacks or data leakage can all have material impacts on the organization, reputation and adherence to regulations. The impact of failures in this regard can be expensive. In 2018 it was estimated that IP targeted cyber crime accounted for $50 to $60 Billion of global losses. The payment industry has established fines of up to $500K per incident for security breaches according to UCSC failure to comply for companies is clearly expensive. 

With that noted, it is important to examine the tacit consequences and long term impacts of not using in app protection:

Risk of Unauthorized Access

Unauthorized Access is a critical risk for the majority of industries that handle private information, specifically personally identifiable information. If a person who is not allowed to make use of your application starts making use of it then there are more chances that the individual will commit fraud. It is hard to predict the behavior or intentions of anyone but it is essential to take every proactive step to avoid unauthorized access. 

Vulnerabilities like Broken Authentication expose your applications to hackers gaining access and then committing fraud. Session management or credential management issues can easily enable hackers to gain access and commit fraud against your application. The worst part… these attacks often go unnoticed without in app protection or runtime checks. As we know the cost of breaches only goes up over time: A breach identified in 100 days costs approximately $5.99 Million, while a breach that takes longer can cost upwards of $8.7 Million. 

Hackers can also use access to your application to expose sensitive datam putting end users at risk of losing their personal data or facing the downstream risks of identity theft, data leaking and doxing. All of which present a tangible threat and will likely result in financial obligations for the organization, due to negligence and failure to protect their customers. It can also be as simple as privilege escalation, a user enabling additional privileges allowing them to control aspects of the application that should not be externally leveraged. A recent example is the 2017 Accenture attack.

Risk Of Fines & Financial loss

There is a reason that the top software companies like 1Password, Google & Adobe pay over $100,000 for researchers that identify vulnerabilities within their toolsets. The bug bounty is in fact a rapidly growing industry and entire organizations exist around identifying these vulnerabilities. A recent research report from IBM identified that finance security professionals detect just 56% of incoming attacks, managing 53% of these attacks and only preventing 31% of attacks completely. Organizations don’t have a comprehensive ability to mitigate risk, even if you are using SAST / DAST / IAST and penetration testing risks can still slip through the gaps. 

The average cost of vulnerabilities for all industries is approximately $13 Million. This combines the cost of paying for fines corresponding to regulation violations, the cost of remediating the risky vulnerabilities, the expense to prevent data from being leaked and the potential cost of IP being leaked. Then let’s lay on the cost of reputation damage, Security Magazine reports that 80% of customers will not continue to leverage a bank’s services if their information is compromised… this is probably justified. Organizations are equally skeptical of services following attacks and they will follow the example of customers.  But, reputation isn’t singular, organizations can also face the impact of loss of goodwill. It will impact your brand image and can prevent customers from even acknowledging the validity of your organization.

Risk of IP Loss

Intellectual property loss is likely the most pernicious risk of not using In App protection. It is often the case that applications include some form of intellectual property which could encourage competitors to copy, steal or leverage in their own applications. 

Reverse engineering is a significant issue for organizations, by enabling capabilities on the client side, users and hackers can gain access to and expose more functionality through the server siege of the application. Not obfuscating code enables these users to easily interpret the intended functionality of the application and identify how to replicate this operability. One recent example is American Superconductor, a U.S based provider of clean energy solutions. In 2011 their largest customer Sinovel ignored their contract and refused to pay millions of dollars owed. The company then obtained the source code for all of the electronic components and were able to install a pirated version into their wind turbines. The violation of the IP rights and loss of revenue can incur as much as $200 Million a year in losses. Without possibility for legal resources or ability to prevent continued leverage. 

IP trade theft costs organizations as much as 3% of Annual U.S. GDP.

But, what can be done to prevent these risks? 

Obfuscation, PreEmptive provides a layered approach that clings to the deployed application and helps to ensure any unidentified vulnerabilities that are hidden. Reducing the likelihood of hackers identifying and leveraging them. Obfuscation also protects your IP concealing the framework and structure of your application from corporate spying and ensuring your competitors can’t repurpose your sweat equity.

For more information about in-app security, visit our products page and start protecting your apps today!


Categories
101

Top 10 Memorable Women in Tech

Reading Time: 4 minutes

For those who follow us on our social platforms, many of you know that we celebrated National Women’s History all month long, elevating iconic women who changed technology. Not only do these women leave a legacy behind, many of you may not know who they are or what they have accomplished. What better way to end this month by recapping our top 10 most memorable women who made their >mark< in history.

10: Elizabeth Feinler

American borned information scientist, Elizabeth Feinler, was the director of the Network Information Systems Center at Stanford Research Institute (SRI) from 1972 to 1989. This center was a bit like a “prehistoric Google,” which was operated for the ARPANET that later evolved into Defense Data Network then finally the internet. The NIC was the first place to publish the resources and directories for the internet, developing the original “white and yellow pages” directories. Her group also developed the domain naming scheme of .com, .edu, .gov, .net and many more that we still use today.

9: Karen Sparck-Jones

British computer scientist Karen Sparck-Jones was responsible for the concept of  inverse document frequency (IDF) which is a weighting factor that evaluates the importance of a word to a document. This set the standard in web search engines and is frequently used to rank a document’s relevance to a search query. Her accomplishment landed her the Lovelace Medal in 2007.

8: Katherine Johnson

Mathematician Katherine Johnson was the first African American woman to work for NASA. Her trajectory analysis was crucial to the success of the first US Space flight that she also worked on plans for a mission to Mars. Johnson’s 33 year career at NASA nicknamed her as the “human computer” for her mathematical capabilities when there was little technology and recognition at the time. In 2015, President Barack Obama awarded her the Presidential Medal of Freedom which is the highest civilian honor in the US.

7: Radia Perlman

American computer programmer and network engineer Radia Perlman left a legacy that impacted tech as we know it. Her invention of the algorithm behind the Spanning Tree Protocol (STP), was instrumental in making today’s internet possible. The work made a huge impact on the way networks self-organize and move data, basically laying the ground rules of internet traffic. Perlman delivered many keynote speeches internationally and is still an engineer for Dell EMC. 

6: Adele Goldberg

American computer scientist Adele Goldberg was known for her development of the programming language Smalltalk-80, which influenced the first Apple Computer. Goldberg and Alan Kay were involved in the development of design templates that are still used presently in software design.  She eventually collaborated with Steve Jobs demonstrating her team’s graphical user interface concepts (better known as GUI) that he later adopted with the development of the Macintosh desktop environment.

5: Mary Allen Wilkes

Layer and former computer programmer and logic designer Mary Wilkes, is known for her work for designing the software for the Laboratory INstrument Computer (LINC). The LINC was one of the earliest systems of an interactive personal computer. Her use of the LINC at home in 1965 made her the first woman home computer user. Wilkes’ work is recognized and praised internationally. 

4: Annie Easley

African American mathematician, computer and rocket scientist Annie Easley broke through the barriers and achieved monumental success. She was 1 of 4 African American employees working the lab and was a leading member of the contributing team that developed the Centaur rocket stage. Her contributions included developing and implementing code that analyzed alternative power technologies and identifiers to solve problems, which laid the foundation for future shuttle missions. 

3: Hedy Lamarr

Austrian born actress and inventor, Hedy Lamarr and composer George Antheil invented a radio guidance system that used frequency hopping and spread spectrum technology to defeat the threat of radio jamming by the Axis powers during WWII. It wasn’t until the 1960s when the US navy adopted the technology, however, the primary principals of their work are incorporated into today’s technology – which we all know as Bluetooth and GPS.

2: Grace Hopper

One of the most iconic women in tech, Rear Admiral Grace M. Hopper was a computer scientist and one of the first computer programmers to work on the Harvard Mark I. Her work led to the development of COBOL, an early programming language that is still used today. In 1947, she recorded the world’s first real computer bug. It is also said that she coined the phrase: “It is often easier to ask for forgiveness than to ask for permission.”

1: Lady Ada Lovelace

English born mathematician and writer, Lady Ada Lovelace is widely known to be the first computer programmer in history. Although she only wrote about a computer, the Analytical Engine (that was never built), she realized that the computer could follow a series of simple commands, a program to perform a complex calculation. Lovelace’s interest and dedication to scientific developments echoed in history. To commemorate her work, the U.S. Department of Defense created a computer language called “Ada,” and was approved on December 10, 1980. The Department of Defense Military Standard for this language (MIL-STD-1815) was given the number of the year of her birth. Various awards and medals have been also named after Lady Lovelace, which were given to other iconic women who made our list, making her the first woman pioneer of her time! 


To stay up to date with the latest blogs, webinars or upcoming events, follow us on our social media or sign up for our newsletter


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

How to Avoid Breaches

Reading Time: 4 minutes

Did you know that your company’s finances, reputation and intellectual property is at stake when you’re not protected even during the development phase? Desktop (client) applications perform many critical business functions and when not protected, they are susceptible to piracy, tampering, vulnerability probing, data, and IP breaches. 

We cannot stress enough on the importance of investing in desktop application protection. Research shows that the average application received over 13,000 attacks monthly even after deployment! The same goes for app development, all of those endless nights of debugging, troubleshooting can be hacked within seconds and your sweat equity is sold to the highest bidder. Hackers have no remorse and can readily run a few lines of code to probe or gain access to your project(s). While these criminal activities are not news, cyber hacking has evolved and will continue to do so as DevSecOps also progresses. 

In order to get ahead, you must know the facts about a hacker’s business model, industry risks and the proactive measures in order to prevent breaches.

What is the Hacker’s Business Model?

If you guessed “money” as the ultimate goal of the hackers business model – then you’re right! What else would be the motivation?

In terms of “increasing revenue,” data is equivalent to currency, the more data they obtain, the more money they can get, but this is a small portion of a much larger scheme. One large attack won’t suffice, they tend to automate their tactics or use additional help. For example, a master hacker can create a clever downloadable kit for other hackers to use on a specific site, these are called “proxy” hackers, which technically multiplies the solo hacker’s work. But let’s not underestimate the master hacker, these clever kits have barriers – they allow and grant access to a single proxy hacker to store data on a database in the cloud, all while having adjacent blocking mechanisms to other proxy hackers. Even those proxy hackers cannot see each other’s data, the master hacker has the ultimate backdoor key to the cloud database. 

Time is money, and in the world of hacking “cutting cost” is essential. Let’s not be naive, there are kits for just about every kind of attack. Instead of inventing the wheel or doubling up on the work, hackers will use what others have already built. Another cost-cutting example is to utilize proxy servers. This allows attackers to temporarily store the data that is being retrieved. Last but not least, hackers love to use Remote Desktop Services (RDP) sessions or isolate a central processing unit (CPU) to maximize their attack. 

To stay on top of your security game, the best thing to do is educate yourself and your team about the behavior of hackers. Study their business model, understanding this will allow your IT department to focus their controls on the problem, rather than on the symptom. Educate your teams on how they attack. If you understand their methods, you can be proactive, applying security throughout the SDLC to give your team the power to prevent risk.

Knowing Industry Risks

Each industry has specific risks. For example; software vendors, financial service providers, telecommunications companies, industrial manufacturers and other businesses rely on applications to generate revenue, assure business continuity and contain unique intellectual property. Businesses of all types have risks associated with their divisions and recognizing all of them is a full time job. But, we can’t all afford to hire security researchers, proactive approaches are based on recognizing the key challenges and building security around them. 

If your company’s security systems aren’t up to par, then the risks of a breach are far greater, not discovering a breach costs you money, for every week a risk is in a deployed app your customer data is accessible, IP available and runtime performance at risk. 

The average annualized cost for cybercrime in the financial services industry is approximately $20 Million with the average for all industries being $13 Million. Each year technology changes and with that so do unforeseen challenges, for instance, prior to pandemic industry risks were far less than they are today with remote working. Now that sensitive data can be accessed anywhere at any given time, attacks have tripled in the past three years thus shifting each industry’s security standards. If you know your industry’s risk, you know what to look out for.

Investing in In-App Security

Allocations for security tools are crucial for all types of business when developing for their fiscal budget. According to Cisco, 50% of large enterprises (with over 10,000 employees) are spending $1 million or more annually on security, with 43% spending $250,000 to $999,999, and just 7% spending under $250,000. Larger corporations have the budgets, but it is the smaller businesses that tend to overlook or not invest in security. By not investing in any type of cyber security, this exposes each business to the core. Reputation, loss of finance and sensitive data are just a few examples of what a company will face during a breach. It is better to be safe than sorry.


PreEmptive layered approach using obfuscation, encryption, shielding, and tamper proofing, makes it very difficult for a hacker to read your source code. Our products require no changes to your source code, easily integrate with your build process, and provide passive and active protection customized to your business’ needs. 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.