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

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
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
Support Corner

Protecting VSTO Add-Ins

Reading Time: 2 minutes

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

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

Protecting VSTO Add-Ins

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

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

Example of VSTO Add-In

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

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


Categories
101

PreEmptive 101

Reading Time: 3 minutes

In this blog we’ve established a 101 – of all things PreEmptive. Our goal is to help you comprehensively understand PreEmptive and our products in basic terms. This is a great piece of content to share with your team, decision makers or that pesky finance department that won’t give you extra budget for security tools.

For those of you who are in the industry and know what we offer, we appreciate the loyalty! If you are new to the industry and are not tech savvy, but want to know a little bit more about PreEmptive, check out our 5 W’s:

Who is PreEmptive?

PreEmptive is an Idera INC software company. We have been obfuscating and protecting applications since 1996, starting with DashO for Java then expanding over the last 20 years to our full range of solutions that you see today! Our core values are: to help organizations make their applications more resilient to hacking and tampering –  to protect intellectual property, to secure sensitive data, and enhance revenue. In other words, PreEmptive is the first line of defense for your code!

What is PreEmptive?

PreEmptive is a software security solution that helps you protect and secure your apps intelligently through a layered approach. Our multi-faeceted approach is applied to the binary code to provide: obfuscation, encryption, root detection, shielding and tamper detection with the end goal of making life difficult for hackers & bots. Let’s add some definitions, what is obfuscation? Obfuscation means making something unclear or obscure – it’s like a frosted window, it obscures your vision but does not prevent functionality. With code obfuscation the goal is to conceal the underlying code that enables the application to function, while ensuring effective functionality of the application 

How is this achieved? Our layered application hardening and shielding is directly infused into your .NET, Java, Android, JavaScript and iOS applications. Which means, we do not require changes to your end user’s computer/device or network to stay fully protected– the solution does the dirty work for you, securing the app against any vulnerabilities in your projects and jumbles up the code so that hackers can’t reverse engineer your proprietary information!

  • PreEmptive not only “scrambles” your source code, but also has the right mix of protection, response and security reporting features, allowing the user to better protect their projects and defending against the ever-evolving data, IP theft, fraud, brand damage and drastic revenue loss. 
  • PreEmptive offers 4 different types of protection: Dotfuscator, DashO, JSDefender, and PreEmptive Protection for iOS. Here’s the key differences:
    • Dotfuscator provides many layers of protection for .NET users with multiple forms of obfuscation (renaming, string encryption, watermarking, active runtime checks (tamper, debug, root, and more).
    • DashO is a security plugin for Android and Java users providing layers of protection by obfuscation (renaming, string encryption, resource encryption, and more).
    • JSDefender is for teams that use Javascript, securing their applications through in-app protection and code obfuscation. This tool helps teams to prevent code from being easily visible to anyone with access to a browser.
    • PreEmptive Protection (iOS) protects all Objective-C iOS applications, reducing the risk of piracy, intellectual property theft and tampering. (Don’t worry, if you’re feeling lost, we will dive into more in depth on each product in our upcoming blogs)

When should you use PreEmptive?

If you’re a start-up company that has blossomed overnight, a freelancer with multiple clients, or a large corporation who needs to enhance their security program, that’s when PreEmptive should come into play. With fair pricing based on your project needs, PreEmptive can be applicable for many organizations.. When writing any source code without protection, you are susceptible to damage and theft, which has long term financial implications. By using any of the PreEmptive products, your team will feel at ease instantaneously, knowing your code is secure even after deployment!

Where does this work?

PreEmptive is injected into your source code, but our operational playbook includes a bottom-up evaluation of security risks, vulnerability mitigation techniques, and post deployment protection to further reduce exposure.

Why should you use PreEmptive?

PreEmptive not only offers different packages based on your needs, but it has been the leading security system for over 17 years! We test, obscure and manage your vulnerabilities directly in your code, so if you feel worried about hackers or stressed about how secure your projects are, check out your options by visiting our main page!

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 understand what it is we do. Be on the lookout for our upcoming 101’s! 

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