Attributes are used for many different things in .NET: unit testing, serialization, language interoperability, etc.
.NET also provides the ability to create custom attributes. This can be used for building our own object mapping (ORM), custom serialization mechanisms, or other distinguishing objects for a specific purpose.
Protecting .NET applications that use custom attributes is a seamless process with Dotfuscator. Dotfuscator cloaks attribute definitions and automatically updates references throughout the application, so the name remains hidden. If the attribute is defined in an external library (not included in obfuscation), Dotfuscator automatically preserves the attribute usage within its inputs.
This default behavior handles most scenarios involving attributes. But there are times when a custom configuration is necessary. Fortunately, Dotfuscator’s rules engine gives us the flexibility to handle any unique scenario involving custom attributes.
Please consider the following example app:
A custom PermissionRequiredAttribute has been created to distinguish features requiring special permission:
After protecting with Dotfuscator, the PermissionRequiredAttribute, along with all references, are hidden:
Equally as important, the app runtime behavior works properly after protection:
The above scenario works great. But other times, Dotfuscator configuration is required. For example, if PermissionRequiredAttribute is loaded by an external reference not included in obfuscation, we would need a rule to preserve PermissionRequiredAttribute from Renaming.
In another example, types decorated by PermissionRequiredAttribute are serialized, but the deserialization mechanism is not obfuscated. In this case, rather than excluding the custom attribute itself, we would create a rule to exclude any type (or member) decorated by PermissionsRequiredAttribute:
Custom attributes are yet another powerful component of the .NET platform and, when used effectively, save time and lines of code. Protecting apps that use custom attributes is simple when we take note of the guidelines above.
Organizations are under constant pressure to deliver software faster and more efficiently. In response, many have turned to DevOps, a set of practices that emphasizes communication, collaboration, and integration between software developers and IT operations professionals.
However, simply adopting DevOps practices is not enough to ensure success. To truly reap the benefits of DevOps, organizations must also adopt a security-minded approach known as DevSecOps.
DevSecOps is a set of practices that focus on integrating security into the software development lifecycle. By automating code scanning, defect reporting, and incorporating security into the development process, organizations can reduce the risk of vulnerabilities and ensure that their applications are secure.
In this article, we will discuss 10 DevSecOps best practices that your organization can implement now.
10 DevSecOps Best Practices To Implement Now
The speed and complexity of modern software development have made it necessary for organizations to adopt DevSecOps practices in order to remain competitive. DevSecOps is a set of best practices that seek to integrate security into the software development process. By doing so, organizations can more effectively secure their applications and reduce the risk of defects.
There are many DevSecOps best practices that organizations can adopt, but some are more important than others. Here are 10 of the most important DevSecOps best practices to implement now:
1. Shift Left
The first and arguably most important DevSecOps best practice is to shift security left. What this means is that security testing should be integrated as early as possible into the software development process, rather than tacked on at the end. By doing this, security risks can be identified and mitigated much more effectively.
2. Implement Continuous Integration and Continuous Delivery
With CI/CD, teams can automatically build, test, and deploy code changes. This helps ensure that code changes are integrated and delivered quickly and efficiently. It also helps reduce the risk of human error.
3. Implement Obfuscation Techniques
One of the best ways to protect your code from being reverse engineered is to use obfuscation techniques. Obfuscation is the process of making code difficult to understand, to obscure its meaning If you will. Doing so makes it more difficult for attackers to understand the code and find vulnerabilities.
Many different obfuscation techniques can be used, such as code encryption, code compression, and white-box cryptography.
4. Threat Modeling
Threat modeling is the process of identifying, quantifying, and prioritizing the risks to your systems and data. It’s a key part of DevSecOps, and it’s important to do it early and often.
There are many ways to approach threat modeling, but one popular method is the STRIDE method. This involves identifying six different types of risks:
Spoofing – When someone pretends to be someone else
Tampering – When someone modifies data
Repudiation – When someone denies having performed an action
Information disclosure – When someone gains access to data they should not have
Denial of service – When someone prevents legitimate users from accessing a system
Elevation of privilege – When someone gains access to a system or data to which they should not have access
5. Adopt a Microservices Architecture
One of the key benefits of DevSecOps is that it enables you to adopt a microservices architecture. This means breaking up your monolithic applications into smaller, more manageable services.
There are several benefits to this approach:
Services can be developed, tested, and deployed independently
Services can be scaled independently
Services can be updated without affecting the rest of the application
A microservices architecture also makes it easier to implement security controls. For example, you can deploy security controls at the service level, rather than at the application level.
6. Use Cloud-native Technologies
The world is moving to the cloud, and so is DevOps. But DevOps in the cloud is different than DevOps on-premises. When DevOps teams move to the cloud, they need to use cloud-native technologies.
Cloud-native technologies are those designed to run in the cloud. They are built to be scalable, fault-tolerant, and easy to manage.
Some of the most popular cloud-native technologies include:
Containers (Docker, Kubernetes)
NoSQL databases (MongoDB, Cassandra)
If DevOps teams want to be successful in the cloud, they need to use these cloud-native technologies.
7. Encrypt Data in Motion
Another important DevSecOps best practice is to encrypt data in motion. This means that data should be encrypted when being transferred between different systems. This is important because it helps protect the data from being intercepted and read by unauthorized people.
8. Implement Role-based Access Control
Organizations need to trust that the right people have access to the right information at the right time. Role-based access control (RBAC) is a security model that can help accomplish this. RBAC can be used to control who has access to what resources in an organization. It can also be used to control what actions users can take with those resources.
RBAC is an important part of DevSecOps best practices because it can help prevent unauthorized access to sensitive data and systems. It can also help ensure that only authorized users can make changes to systems and data.
9. Monitor and Log Activity
To ensure your system is secure, it’s important to monitor and log all activity. This way, you can see what’s happening on your system and identify any potential issues. By monitoring and logging activity, you can also detect patterns of behavior that may indicate an attempted attack.
10. Implement DevOps at All Levels of the Organization
The success of DevOps implementation cannot be overstated. In order to truly reap the benefits of DevOps, it must be implemented at all levels of the organization. What this means is that everyone, from the CEO to the front-line workers, must be on board with the DevOps philosophy. This can be a challenge, but it’s important to remember that DevOps is about culture first and foremost. Only by getting everyone on board with the culture change can an organization hope to fully reap the benefits of DevOps.
It’s easy to see how following best practices can help keep your software development process safe and secure. Implementing these 10 DevSecOps best practices is a great way to get started, but it’s only the beginning.
Make sure you also have the right tools in place, like PreEmptive Solutions‘ products, which make it easy to follow standard processes and ensure that your code is always up-to-date and compliant.
Want to learn more? Check out our product pages for more information on how we can help you stay safe and secure while you develop amazing software.
Android is the most common mobile OS by far, cornering 87% of the market share — a number which is expected to grow. Android’s open platform and extensive library of resources make it easy for developers to create and integrate new apps. However, the same features that make Android easy for developers to use also make it easy for hackers to exploit.
Android apps have become the most widely used alternative to desktop software. Because apps are used for banking, shopping, and transmitting personal information, they’re a prime target for cybercriminals. One of the most common methods hackers use to carry out various attacks is reverse engineering your code.
1. Reverse Engineering
Android’s open environment makes it an easy target for reverse engineering. Reverse engineering analyzes an app to figure out how it works and its design and implementation process. This is done by examining the compiled code, observing the app during runtime, or both. There are numerous free tools available to reverse engineer the binary code of Android apps.
Attackers can use reverse engineering to steal your intellectual property, modify your code, attack your back-end systems, discover security vulnerabilities, and gain access to confidential data. The first step in almost all Android hacking attempts is reverse engineering the code.
2. Repackaging Attacks
Repackaging, or cloning, attacks are a problem for apps of all sizes. Hackers often take good but not very popular apps and reverse engineer their code. They then modify the code to suit their purpose, which could be embedding malware to steal credentials or ad revenue. The modified code is then repackaged, and consumers may be convinced to install it, thinking they’re installing a trusted app. Another variation of the repackaging app is when hackers rebrand an app and publish it as their own, often making more than the original developer.
3. String Table Analysis
String tables are frequently used for storing sensitive information such as license keys, credentials, and other confidential data on both the client and server sides. Hackers can analyze the string tables to gather information, identify algorithms, understand database designs, and more. The string table may contain the data they want to steal, or they may use the information they gather to launch a different type of attack.
4. Functional Cross Referencing
Cross-referencing can help hackers determine where a particular function was called from. They can use that to detect vulnerable code they can use to execute malware or find the code that does the encryption of data they want to steal. Cross-referencing can show how information was accessed, which is invaluable to hackers trying to steal intellectual property, sensitive data, or insert malicious code.
5. Debugging and Emulator Attacks
Hackers can use debuggers and emulators for dynamic analysis during runtime. Using these tools, they’re able to identify vulnerabilities and exploit them with runtime attacks. Unlike the other methods, these attacks require active hardening. Your app needs to be able to modify its behavior and response during runtime if an active threat is detected.
Preventing Reverse Engineering With Obfuscation
Almost any code can be reverse-engineered given enough time and resources. However, obfuscating your code can make it more difficult, expensive, and time-consuming for hackers to reverse engineer. The free decompilers make it extremely simple for hackers to reverse engineer code that isn’t obfuscated.
If your code is obfuscated, hackers are more likely to give up and move on rather than investing time and money into reverse engineering the source code. Code obfuscation can consist of a number of different techniques designed to disguise your code from hackers while not interfering with its execution.
Data obfuscation scrambles data via tokenization or encryption to make it unreadable to hackers.
Obfuscating your code makes it look like unusable nonsense to hackers. There are many ways to obfuscate your code, and your hardening process should use a layered approach to make it harder to crack. At PreEmptive, we employ a range of different obfuscation techniques to provide a high level of security.
Renaming changes the name of methods and variables.
Even when you rename your methods and variables, your strings may still be discoverable. String encryption provides an additional layer of security to your software by making it harder for threat agents to decipher and understand.
Protecting Against Runtime Attacks
Obfuscating your data and code isn’t enough to secure your Android app. You also need to use active hardening to protect against runtime attacks. Some of the methods DashO uses to deflect runtime hacking attempts include:
Tamper detection and defense
You can prohibit or modify your app’s behavior if it detects an unauthorized attempt to gain access.
Root detection and defense
Jailbreaking a device compromises the security of your app. Control whether your app will run on a rooted device and how it will respond.
Emulator detection and defense
Running an app on an emulator allows a hacker to understand and analyze an app’s functioning in a controlled environment. DashO can sense when your app is being used in an emulator. You can decide whether or not your app will run in an emulator and how it will respond if it is.
Hooking detection and defense
Hackers use hooking frameworks to modify your app at runtime without altering the binaries. If DashO detects a hooking framework, the app can respond by shutting down, throwing an exception, or sending an alert, among other options.
Multi-faceted App Hardening
To protect your Android app from ever-evolving cybersecurity threats, you must take a multi-pronged approach. However, hardening your app is pointless if your app breaks as the runtime platform evolves. At PreEmptive, we are constantly monitoring, testing, and upgrading our solutions to protect your app from runtime issues and to respond to new hacker threats and tools.
Your organization can’t afford the expense, exposure, or possible brand damage associated with having your app hacked. Contact us today to find out how our solutions can integrate with your current DevOps practices to provide the security and protection you need.
With the advent of new technologies and the rapid shift in consumer habits, applications on smartphones and tablets have become prevalent in our everyday lives. It has never been easier to access mobile banking than it is now, let alone to book flights or shop online. But with this ever-increasing dependence on our smartphones and tablets, we are also more exposed to cybercrime than ever before.
The myth that mobile apps are invulnerable to cyberattacks hasn’t withstood scrutiny. It’s true that mobile apps, on average, have fewer vulnerabilities than desktops or laptops, but their widespread use and application present hackers with a broad. and nearly irresistible, attack surface area.
The good news is that there are many steps the tech industry can take to protect itself from threats.
Mobile Application Breaches
Mobile devices are vulnerable because of their open architecture and their ability to connect to other devices and networks. Mobile apps are particularly at risk. Hackers can exploit bugs and errors, either in the code of the app or on the app store that hosts them.
The top vulnerability is unencrypted data transmission. Bad actors can easily intercept unencrypted data when it travels from one device to another. That often happens when a user goes online while using an unsecured network, like their coffee shop Wi-Fi network, and connects their device to it.
But there are other potential problems, especially in app development. Incorrect default credentials or failing to validate input parameters before storing them in memory can lead to serious vulnerabilities within the app itself.
In one major breach that just happened recently, cybercriminals uploaded a counterfeit crypto wallet to the iOS App Store. The unfortunate users who downloaded it and entered their credentials, thinking it was safe, were instantly deprived of their funds. And this while using iOS, often considered a safer alternative to Android!
How Mobile Application Breaches Affect the Industry
Mobile devices have become an integral part of our lives and we depend on them for everything from banking transactions to social networking. They contain sensitive information, such as passwords and payment card data, which makes them especially vulnerable to security breaches. 40% of all data breaches were traceable in some way to a mobile device.
These breaches create a lack of confidence among users and can cause them to question whether it’s safe to conduct transactions on their mobile device. As more people use mobile devices for financial transactions, the number of security breaches will probably continue increasing at an alarming rate.
The Industry Response
App developers must double down on their security practices during and after development. That includes investing in secure coding practices like encryption and making sure they’re using the latest version of any tools they use. They should also consider implementing application hardening tools, such as those that PreEmptive offers, that can help uncover any security threats before they become major problems.
The added expenditure into security means that the tech industry is spending more money on product development. After many painful lessons, industry leaders have learned to take the threat of mobile cyber attacks seriously, no matter the platform. This means that not only are companies creating more secure applications and platforms, but they are also investing in security tools that can help them identify vulnerabilities.
Mitigation Measures Within App Development
The risks of launching untested applications are clear: potential data breaches and reputational harm. But how can companies mitigate these threats? There are several things to consider before releasing an application, including legal matters and security vulnerabilities. Here are some best practices for mitigating these risks:
Make sure developers understand the app’s purpose and requirements.
Conduct thorough testing before launch, including penetration testing, end-to-end testing, and user acceptance testing.
Make sure to have documented processes in place to handle any security issues that arise after launch.
App testing, for example, is the process of ensuring that an application meets its business requirements, functional requirements, and quality standards before being deployed for use by end users.
Software testers play an important role in ensuring that applications are free from defects and ready for release. They identify errors or defects in software requirements, design, code, and other elements of the software lifecycle. They also help ensure compliance with industry standards and regulations. Testers can work as part of a group or individually on specific projects within the organization.
Developers can also contract with third parties like PreEmptive to help them reduce security vulnerabilities in their apps. Third-party utilities can be used to scan the code for vulnerabilities, perhaps even finding some that would be otherwise missed by the developers themselves.
Building More Secure Mobile Apps
Given the threat of mobile breaches, there’s an ever-increasing need for developers to create more secure applications. App developers can start reducing their risk at multiple different levels:
Secure Coding Practices. Developers need to use secure coding practices that provide protection against common vulnerabilities like SQL injection, cross-site scripting and insecure data storage. These types of bugs can expose sensitive data to unauthorized parties or even allow attackers to take over an app.
Protecting Sensitive Data. Sensitive data includes credit card numbers, social security numbers, or other personal information. User data should always be encrypted and securely stored, whether on a company’s own server or a hardened server owned by a third-party.
User Authentication and Authorization. User authorization refers to restricting what resources each user can access at a given authorization level. An example is only allowing certain users to access specific features or functionality within the app based on their role within the organization.
Auditing, Testing, and Training. App developers can hire a team of experts to audit their apps, both internally and externally. They should also test their apps to make sure they work as intended. New security-oriented training procedures can be implemented across the entire organization as well.
Whether speaking about a corporate entity or an independent developer, mobile app security is a serious issue that can have disastrous implications if not approached carefully.
Companies should build their apps with security in mind from the start. PreEmptive is the leader in application security testing and analysis. We provide solutions that are easy to use, yet effective in preventing many types of vulnerabilities and defects in common mobile applications and systems. Contact us to learn more about how we can help you.
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!
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.
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.
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.
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 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.
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.
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.