Gapotchenko Blog

On Benefits of Obfuscation

Wed, 08 Sep 2021 13:31:17 Z

Your application's code is your intellectual property (IP) that comes with costs of time and money to develop. Therefore, protecting the code before distributing it is integral to the security of your business.

If the code gets leaked or stolen, your company may face a spectrum of adverse effects, including loss of competitive edge, exposure of your innovations, and other serious consequences. Protecting that edge had become for the companies with intellectual property less of an option and more of a norm.

What is code obfuscation?

Software protection is gaining more importance in this present digital era. You can protect against intellectual property theft, unauthorized access, and vulnerability discovery by making an application much more difficult to reverse-engineer. And obfuscation is one of the main approaches to achieve that.

Code obfuscation is the technique of deliberately obscuring a code to make it much more difficult for humans to understand and useless to hackers who may have ulterior motives. Obfuscation uses several tricks to make the code irritating as hell to read and debug.

Reasons to use obfuscation

Lack of protection may cause significant damage to a business owner. Cybercriminals may steal intellectual property, benefit from sensitive information, identify vulnerabilities, or add malicious code to apps.

The idea moved towards obfuscation because of the following reasons:

Intellectual Property theft might quickly cost customers and brand reputation. Losing IP means losing of the first-to-market advantage or loss of profitability, or — in the worst case — losing entire lines of business to competitors.
Intellectual property is rapidly becoming a fundamental basis of wealth representing the most valuable asset. However, IP risk poses a threat to your intellectual capital and your financial success. In particular, to trade secrets, know-hows, lifestyle, salaries, and profits.
It is believed that IP rights stimulate investment (time and money) and lead to innovation. As global IP theft increases, people invest less in new technology and products when they know their software will be stolen. This affects both inventors and investors.

Advantages of obfuscation

Obfuscation gives us a lot of benefits:

Cost-effectiveness. While protection is core to any IP strategy, it can also have a significant capital value for any business. As the obfuscated code becomes much more challenging to analyze, this will reduce the possible hacker attacks. And your intellectual property won't be out in the open. So, your return on investments will definitely increase.
Safety. Obfuscation is an integral method, referred to as application's self-defense. Considering the untrusted environment, it is always better to deploy an obfuscated application. This makes it much harder for attackers to decompile it and extract the intellectual property.
Performance. Obfuscation also optimizes the code by removing not-so-useful metadata, unused code, or duplicate code. This, in turn, speeds up code execution, thus upping application performance.
Reliability. Code obfuscation hides the implementation of a program while still allowing users to run it. Hiding business logic and valuable information in the obfuscated code makes it harder for attackers to access and reverse-engineer your application.

Conclusion

Software is a valuable type of intellectual property that can be challenging to secure. Therefore, protecting it should be among your priorities if it isn't already. The first line of defense against IP theft is often the existence of a well-implemented protection strategy.

When properly implemented, code obfuscation is an effective approach for protecting your business assets. It isn't a way out, but it significally lowers the risks associated with IP leaks.

Deterministic Obfuscation

Tue, 18 May 2021 14:14:29 Z

Eazfuscator.NET gained the ability to perform deterministic obfuscation since version 2021.1.

Deterministic obfuscation allows to produce an assembly whose binary content is identical across obfuscations for identical inputs.

By default, obfuscator output from a given set of inputs is unique, since the obfuscator uses randomly generated cryptographic material for every obfuscation, which is a good thing.

But sometimes, you may want to perform deterministic obfuscation. In that case, the obfuscator will produce a deterministic assembly, the one whose binary content is identical across obfuscations as long as the input remains the same.

Here is a bit more information from Eazfuscator.NET documentation: learn.gapotchenko.com/eazfuscator.net/docs/sensei-features/deterministic-obfuscation

Deterministic obfuscation is a complementary feature to deterministic compilation provided by some .NET languages. Deterministic obfuscation is solely an industrial feature, the one that allows you to inspect the results with the finest precision.

The areas of possible use are shaped by your needs and imagination. From what we have heard from the users, this is mainly a quality assurance (QA). For example, deterministic compilation and obfuscation allow to ensure that two separate build servers produce identical outputs, thus rulling out non-deterministic behaviors such as soft errors.

But the deterministic mode is not designed exclusively for QA. For example, one can imagine a deployment model that relies on changes in modules. If the source code of a module has no changes then why the compiled/obfuscated module should change? This approach can considerably simplify the patch review process for software manufacturers.

Give Eazfuscator.NET a try

Availability of Eazfuscator.NET SDK NuGet Package

Mon, 17 May 2021 17:49:04 Z

Starting with Eazfuscator.NET version 2021.1, the Software Development Kit (SDK) for .NET is available as a public NuGet package.

SDK provides programmatic access to some specific features of Eazfuscator.NET. The most prominent one is stack trace decoding.

Say you have an obfuscated stack trace or a log file and want to "deobfuscate" it, provided that you have the proper secret knowledge (password) at hand. All you need for that to work is to reference the official Eazfuscator.NET SDK NuGet package. Here is how it can be achieved in code:

using Gapotchenko.Eazfuscator.NET.SDK;

string stackTrace = SymbolDecoder.Decode("<obfuscated stack trace>", "secret-password");  
Console.WriteLine(stackTrace);

SymbolDecoder.Decode is a static function that covers the most common usage scenario. It is simple but you may need more. For example, stack trace decoding does take some time and you may prefer to use the cancellable variant:

stackTrace = SymbolDecoder.Decode("<obfuscated stack trace>", "secret-password", cancellationToken);

Or if you need to decode a multitude of stacks/files with the same password, the simplest variant of SymbolDecoder.Decode may put you into trouble because it performs key derivation operation each and every time the function is called. And it tends to be relatively slow, as the key derivation function has to be computationally intensive to deter brute-force attacks on a password.

To overcome that inherent performance bottleneck, symbol decoder can be created beforehand and then reused multiple times with a great efficiency:

using Gapotchenko.Eazfuscator.NET.SDK;

// Create symbol decoder beforehand. The creation operation is on a slower side.
var decoder = SymbolDecoder.Create("secret-password");

// Reuse the decoder multiple times. Consequent decoding operations are fast.
stackTrace = decoder.Decode("<obfuscated stack trace 1>");  
stackTrace = decoder.Decode("<obfuscated stack trace 2>");  
// ...
stackTrace = decoder.Decode("<obfuscated stack trace N>");

// Once you finish with symbol decoder, it is a good practice to dispose it to clean up the remnants of cryptographic material from memory.
decoder.Dispose();

Eazfuscator.NET SDK can be employed for various applications such as logging, diagnostics, data collection, automated error reporting et cetera. It is all up to your needs and imagination!

Give Eazfuscator.NET a try

Managing Stack Trace Passwords

Mon, 28 Dec 2020 13:31:00 Z

Since its inception, Eazfuscator.NET has offered the ability to encrypt the names of types, members, and other assembly symbols with a secret password.

Once encryption is applied, the assembly remains obfuscated but the original symbol names can be retrieved back whenever such neccessity arises.

The most common usage scenario is to decode an obfuscated stack trace back to its original form:

Hence the umbrella name of that feature: stack trace decoding. It allows to decode a stack trace using a piece of prior knowledge such as stack trace password.

In contrast to its numerous rivals, Eazfuscator.NET neither uses database nor mapping files. This signigicantly simplifies the handling of obfuscated assemblies as there is no separate state to store or manage. Instead, there is a password and that's all it takes.

From security standpoint, you may prefer to use several stack trace passwords. One password per product is a good general approach. Naturally, you have to remember which password corresponds to which product; thus switching between products may take some extra time and effort.

To make this process easier, Eazfuscator.NET 2020.4 offers a built-in management of stack trace passwords:

The list of predefined passwords is the basis of the password management:

The dialog allows to manipulate the predefined passwords in every conceivable way. Once defined, passwords can be quickly reused in the password text box.

Give Eazfuscator.NET a try

Clearing the Fog: Obfuscators vs Protectors

Thu, 26 Dec 2019 13:25:44 Z

Eazfuscator.NET is an obfuscator for .NET platform designed to protect .NET software from reverse-engineering and intellectual property theft. It belongs to the category of obfuscators.

There is another tool category that claims to be as useful as obfuscation: protectors.

While both obfuscators and protectors promise the same benefits, they are very different in instrumental parts of the implementation.

Obfuscation is all about mathematics. It produces computational challenges to make it hard for an observer to interpret the meaning of inner parts of a program. In best case scenario, an observer cannot grasp the inner workings of an obuscated program at all.

In contrast, protectors rely on a more down-to-earth strategy of sneaking a program from an observer with some purely technical tricks. For example, a protector can pack a program in an encrypted binary blob which then gets decrypted to the memory just before execution in run time.

Today I want to show you a good example of that difference, seasoned with a pinch of nostalgia.

Let's take a look at now a historical piece of software called NetWinProtector by Safe Lion:

Note a distinctive look of that program. The design is a bit harsh and weird. However it seams to have a long-standing effect on human memory, as I vividly remember how I could not get it out of my head once I saw it back in 2015. It is weird and attractive, in a way.

If you click that Buy button you get directed to a now defunct website, but you can still enjoy it via Internet Archive.

To get another portion of a weird nostalgia, we can press Register button:

Register online is expectedly defunct too, as it tries to access http://safe-lion.com/Reg.asmx. Whatever amount of customers this product had, they all are left in the cold now.

So what about protection? A product documentation provides the following overview:

"Your program is encrypted, wrapped into a manageable wrapper loader [sic]" - sounds like a typical protector. Before we even run it on a real app let's see if the product passes a smoke test.

.NET Generic Unpacker tool by Daniel Pistelli is an instrument we will use for testing. All it does is scans the memory of a running process trying to find the boundaries of executable modules, then saves them to disk. So let's try to extract the modules of a running NetWinProtector instance which was handily protected by itself.

As soon as we run NETUnpack.exe tool we see something sneaky is going on. NetWinProtector shuts itself down! Probably this is what "Anti Memory Dump protection" feature is about.

Let's do a dumb change by renaming NETUnpack.exe file to 123NETUnpack.exe. Once that is done, NetWinProtector process does not exit anymore, so we can scan and grab all of its supposedly protected modules from the process memory:

Once unpacking is done, we get a bunch of files. And sure enough, NetWinProtector .NET assemblies are there, fully intact and ready for open observation:

This is underwhelming result if you ask me. Reliance on technical trickery puts protectors and software protected by them to assailable position.

In contrast, obfuscation makes a bet on computational hardness. This characterizes obfuscation as a new but relatively established branch of cryptography, which is in turn a prominent branch of mathematics intersected with other disciplines.

To give a practical analogy: once attackers meet a 2ⁿ combinatorial complexity where n > 80, there is no NETUnpack tool to rely on. They have to descend into realm of guessing and brute forcing, but due to the laws of computational complexity their chances are neglectably dim. This is what's called a cryptographical obfuscation and this is the future we are heading to.

Regarding NetWinProtector. Despite its short lifespan, it became a weird piece of nostalgia to me. The website, slogan, funky registration window, pricing. All those commercial aspirations whirled in the sands of time...

Homomorphic Encryption of Code

Thu, 10 Oct 2019 02:32:00 Z

Previously we announced that we discovered a novel way of cryptographically secure obfuscation of software. This article gives a brief illustrated overview of discovery. It also provides some practical examples based on existing implementation of technology in Eazfuscator.NET obfuscator for .NET platform.

Introduction

Obfuscation is relatively new field of cryptography and it often falls behind its older and bigger sibling - the data encryption. It's all about guarantees.

The data encryption guarantees that data remains unobservable unless an observer knows the key. The key is selected to be a large enough number (or blob of data) that is extremely hard (i.e. impossible) to brute force.

It's different when it comes to the code of a program. The code must remain observable in order to be executed by CPU. At the same time, a cryptographically secure obfuscation should make the code unobservable to an attacker.

What some obfuscators (specifically protectors) do is they encrypt the code and put the key right into resulting executable file. This serves the purpose only until the key is discovered by a decompiler or memory dumper. After that, the game is over - the full code becomes observable by an attacker. As you can see, not a whole lot of guarantees at all.

Extracting a key from executable file is billion of billions times simpler than brute forcing a 80 bit key used for encryption. An attacker wins by choosing the cheapest method.

The only technique contemporary obfuscators are good at is concealing the information. For example, Eazfuscator.NET does a good job on symbols by irreversibly renaming them. Removing the essential information is a great security measure. But the code is still there and it remains observable.

Another neat trick some obfuscators employ is code virtualization. It's achieved by translating the instructions of a target platform to instructions of a custom virtual machine. This gives solid results at the expense of code speed, but still the virtualized code remains somewhat observable. It is humanely possible to build a so-called devirtualizer that would obtain the original code of a program.

Indistinguishability Obfuscation

Indistinguishability obfuscation (IO) is a cryptographic primitive that provides a formal notion of program obfuscation. Informally, indistinguishability obfuscation hides the implementation of a program while still allowing users to run it.

That's exactly what we need in order to make the code unobservable by an attacker.

The definition of indistinguishability obfuscation has its roots at the notion of ciphertext indistinguishability which was later extended to a more general computational indistinguishability.

Homomorphic Encryption

At first, let's introduce a notion of program:

O = P(I)

where P denotes a program, I denotes its input and O stands for output.

The easiest way to look at this notion is to imagine that a program P is a Unix-like command line tool with input I in a form of stdin and output O in form of stdout.

In mathematical sense, program P may be much simpler than a full-blown application. For example, it can be just a single operation like multiplication.

The most intriguing candidate for indistinguishability obfuscation is Homomorphic Encryption (HE). Let's see how it works:

Figure 1. Homomorphic encryption

Homomorphic encryption (HE) uses a public-key cryptosystem that provides E and D functions. Function E encrypts the data while D performs the inverse operation of decryption.

Now having those two functions we can write the program equation in homomorphically encrypted form by applying E to both sides of equation:

E(O) = E(P(E(I)))

Let's introduce three shortcut symbols to better understand what's going on:

P_E = E(P);  // encrypted program
I_E = E(I);  // encrypted input
O_E = E(O);  // encrypted output

This gives us a more concise view of HE program equation:

O_E = P_E(I_E)

As you can see, the HE program P_E solely works in encrypted domain, consuming encrypted input I_E and producing encrypted output O_E.

In this way, the homomorphic encryption can be used to move a computationally extensive work P_E to an untrusted party through a remote communication channel. Since the untrusted party never receives the private key of asymmetric cryptosystem, it never knows what program or data are being evaluated.

This fact is denoted by the presence of a Security Barrier in the figure above. The whole HE scheme is secure as long as Encrypted Domain and Plain Domain are kept separated by the barrier.

But in software obfuscation, the security barrier is missing and P_E should be able to work on unencrypted I and O.

Let's write down a corresponding program equation that reflects that:

O = D(P_E(E(I)))

It goes just fine until D function is used to decrypt the output. This poses a fatal problem as function D can be used not only to decrypt the output, it can also be used to decrypt the encrypted program P_E:

P = D(P_E);  // game over

In this way, the obfuscation of P_E is getting thwarted, rendering the whole HE scheme without a security barrier useless.

A Seemingly Unsolvable Dilemma

The impossibility to build an indistinguishability obfuscation based on a general notion of homomorphic encryption that would be able to produce unencrypted output leads us to the root of a problem.

In data communication, participants are separated by natural barriers:

Figure 2. Encrypted data communication

The presence of barriers is what makes data encryption feasible: an attacker is physically unable to retrieve the key and thus cannot decrypt the information.

In software obfuscation, all participants are located at the same security zone and every one of them has a physical access to an encryption key that is stored in software:

Figure 3. The software obfuscation dilemma

The absence of security barrier between Mallory and an encryption key embedded in software renders all program obfuscation attempts useless as Mallory will always be able to decrypt it.

If we cease to embed a program encryption key in software, then we are safe from Mallory but CPU is not able to execute the program.

This represents a seemingly unsolvable dilemma of indistinguishability obfuscation of software.

Another name of this model is Virtual Black Box (VBB) obfuscation which was proven to be impossible by Barak et al. [Barak01]. The impossibility of VBB obfuscation means that we need to find a more relaxed model of obfuscation.

A Hint From The Book

On a cold fall of 2015, we stumbled upon important observation by Kris Kaspersky [Kris03, p. 567]:

The analysis of code can be thwarted successfully only by encrypting the program. However, the processor cannot directly execute the encrypted code. Therefore, it must be decrypted before control is passed to the program. If the key is contained within the program, the reliability of the protection is close to zero. ...

In general, protection consists of implementing a certain mathematical model in a program that is used to generate the key. Different branches of the program are encrypted using various keys. To work out the keys, it is necessary to know the state of the model at the moment control is passed to the corresponding branch of the program. The code is dynamically decrypted at run time. To decrypt it entirely, all possible states of the model need to be tried sequentially. If there are lots of them, which is easy to achieve, the reconstruction of all code will be practically impossible.

Kaspersky suggested a plausible obfuscation model. Let's call it a Conditional Indistinguishability Obfuscation (CiO).

The CiO model implies that conditional parts of a program remain indistinguishable until they are executed. Once they hit the execution path, they become uncovered by decryption and thus become observable to CPU (and to Mallory).

Since then, that brilliant idea never left our heads. It felt so powerful yet unreachable. An attacker cannot reconstruct the whole program as he only has access to the parts he can observe. And intuitively he cannot observe all the parts but... how to achieve that?

Kaspersky suggested to use "machine state" as the source of key material but it would be an inherently weak source due to the lack of entropy.

Indistinguishable Associative Array

Three years later, at fall of 2018, we became involved in construction of indistinguishable associative array. We needed it in order to protect the dispatch table of Eazfuscator.NET virtual machine from attacks based on static analysis.

Imagine a class IndistinguishableDictionary<long, long> that behaves just like the ordinary Dictionary<long, long> but with a twist: nobody is able to tell beforehand what association a dictionary holds unless they have a corresponding lookup key.

Ordinary Dictionary<long, long> can be enumerated, so all associations held by dictionary can be revealed:

foreach (var i in map)  
    Console.WriteLine("{0}={1}", i.Key, i.Value);

IndistinguishableDictionary does not allow enumeration by imposing a mathematical hurdle. The only operation it allows is lookup by a key:

value = map[key]

If attacker has no key, he cannot extract the association. The record in indistinguishable dictionary remains unobservable unless a proper lookup key is supplied.

To our surprise, we got a positive result. We were able to construct indistinguishable associative array with the help of homomorphic encryption. It was somewhat unpractical though as it required large keys with lots of bits, and that would lead to gigantic machine instructions.

And then, it hit us.

value = map[key] is just a specific case of a general notion of program O = P(I).

The program P by itself cannot contain a key suitable for black box encryption; but it has input I with lots of entropy, and that I is generally unknown to an attacker.

Program input I is the secret. This is a valid key material for cryptographic obfuscation.

On a closer inspection of Kris' Kaspersky work, we were able to finally identify some hints to this phenomenon [Kris03], albeit they were expressed not as clearly as we would generally prefer:

... Looking to [function] arguments allows the sequences sought to be caught in data streams, irrespective of how these sequences were obtained. For example, an authentication procedure expecting the password "MyGoodPassword" does not care where it came from (the keyboard, a remote terminal, a file, etc.).

More Detailed View on Software Obfuscation

Let's take a closer look at the detailed interaction diagram between participants:

Figure 4. Software obfuscation and interactions between participants

Note how natural security barriers appeared between participants once we identified that program input I can be a reliable source of key material for encryption of program parts.

Indeed, every user of an obfuscated program has its own set of unique input data. For example, if an obfuscated app (say, word processor) works on some files (say .doc files), an attacker cannot fully decompile the app unless he has all the possible file variations the app can work on. Which is not going to happen as an attacker cannot realistically have an access to all that data due to natural barriers of physical separation.

The conditional indistinguishability obfuscation (CiO) of software is now intuitively feasible. So it turns out that software obfuscation dilemma looks pretty solvable in terms of proposed model.

Realization

The intuitive feasibility of proposed CiO model would not mean a lot, unless at least one practical implementation is found.

The CiO model implies a conditional obfuscation, so we had to focus on conditional blocks of code, and specifically on predicates:

if (p)  
    DoSomething();

The conditional block should only be revealed when p is true. And we know that p should be tied to program input I somehow.

Thanks to the work described in paper "Indistinguishable Predicates: A New Tool for Obfuscation" by Zobernig et al. [Zobernig17], we focused our attention on evasive predicates.

An example of evasive predicate is a password check function p(x) = "x == pw". Since it is hard to find an input x that satisfies an evasive predicate, this class of predicates is a good candidate for obfuscation.

Initially we weren't sure if that was a possible endeavor, but on October 24, 2018 around 4 AM we came up with a plausible solution.

Let's take a look at the following code circuit:

if (x == C)  
{
    DoSomething();
    …
}

where x == C is an evasive predicate with input x and constant C.

A good thing about homomorphic encryption is that it allows to view the data through the prism of equations. Note that our evasive predicate is an equation:

x == C

This fact allows us to apply a deterministic encryption function E to both sides:

E(x) == E(C)

Once encryption is applied, please note that E(C) can be calculated at compile time as constant C_E = E(C), thus irreversibly hiding the original value of C:

E(x) == C_E

As a result, we get an encrypted predicate p(x) that is perfectly functional at run time but never discloses the original value of C while providing us with 1 bit of unencrypted output:

p(x) = "E(x) == C_E"

Unencrypted output eliminates the necessity of HE function D that would thwart the obfuscation otherwise. The elimination of D effectively transforms E to a trapdoor function.

So, now we have a conditional statement with a homomorphically encrypted predicate p(x):

if (E(x) == C_E)
{
    DoSomething();
    …
}

An important observation is that x may or may not be tied to program input I. In order to find the exact relation of x to I, all program data flows would need to be traced. Such kind of tracing may be an enormous or even computationally impossible task. So let's just assume that x of every predicate is related to program input I with some not insignificant probability.

The next question is how to encrypt the conditional block of the if statement.

First of all, we need to ensure that the code of conditional block is translated to the data form:

BL = { DoSomething(); … }

if (E(x) == C_E)
    eval(BL);

Eazfuscator.NET achieves that by allowing homomorphic encryption only in virtualized methods, as the virtualized code is in data form already.

Secondly, we need to introduce another encryption function. Let's call it E_s as it should be symmetric. D_s is a corresponding decryption function.

Then, we can use the predicate constant C as a key material for E_s in order to encrypt the conditional block BL at compile time:

BL_E = E_s(BL, C)

Thanks to evasiveness of predicate, we can rely on the fact that x equals to C when the conditional block hits the execution path. In this way, the encrypted conditional block BL_E can be revealed (decrypted) in run time when and only when x == C:

if (E(x) == C_E)
    eval(D_s(BL_E, x));

The goal is achieved.

The obfuscated predicate is indistinguishable. The code of conditional block is also indistinguishable and can only be revealed when it hits the execution path. This behavior corresponds to the proposed model of conditional indistinguishability obfuscation (CiO).

Some Practical Examples

In accordance to original spirit of the product, Eazfuscator.NET automatically finds and indistinguishably obfuscates all the circuits that are suitable for homomorphic encryption (HE) in virtualized methods.

Currently it covers just one circuit class and integer data types, but we plan to significantly extend HE coverage in the future.

We quickly identified that customers will want to visualize the homomorphically encrypted regions of code. That's why we've built HE visualization tool right into Eazfuscator.NET 2019.3 extension for Visual Studio:

Figure 5. Visualization of homomorphically encrypted regions of code

Whenever a suitable code circuit is found, a green circled H symbol appears at the left side of the editor. Hovering the mouse over that symbol reveals some useful information such as the boundaries of encrypted region and the number of entropy bits in key material.

What can it be used for?

HE is a tool, and your imagination is the driver. Here is an interesting quote from Kaspersky [Kris03]:

... trying the combinations of all [...] conceivable arguments will take an infinite amount of time. Reconstructing the source code of the program thus protected will not be possible before each of its branches gains control at least once. However, the frequency of calling different branches is not identical; it is very low for some of them. For example, a special handler can be installed for the word "pine" entered in the text editor. This handler may carry out some additional checks for integrity of the program code, or for the cleanliness of the license for the software being used.

The hacker will not be able to figure out whether the program is [fully] cracked and [will] end quickly. Careful and laborious testing will be necessary, but even carrying out this will not be [that] helpful.

Try It Yourself

Download Eazfuscator.NET and try HE on your own code.

DISCLAIMER: This research and discovery is property of public domain.
AUTHORS: Oleksiy Gapotchenko, Kirill Rode
ORGANIZATION: Gapotchenko LLC
LOCATION: Kharkiv
YEAR: 2019

References

[Barak01]
B. Barak and O. Goldreich and R. Impagliazzo and S. Rudich and A. Sahai and S. P. Vadhan and Ke Yang, “On the (im)possibility of obfuscating programs,” in Advances in Cryptology -- CRYPTO 2001, 21st Annual International Cryptology Conference, Santa Barbara, California, USA, August 19-23, 2001, Proceedings

[Kris03]
K. Kaspersky, “Hacker Disassembling Uncovered: Powerful Techniques To Safeguard Your Programming,” ISBN 978-1-931769-22-8, 2003

[Zobernig17]
L. Zobernig and S. D. Galbraith and G. Russello, “Indistinguishable Predicates: A New Tool for Obfuscation,” IACR Cryptology ePrint Archive, 2017

P.S. We aimed to use as few paragraphs as possible but the resulting article nevertheless have become rather large. More advanced topics like handling of low-entropy inputs, HE vs custom-built encrypted point functions, malleability and algebraic attacks, dictionary and replay attacks on a deterministic cryptosystem etc are thus omitted. They are subjects of a future, probably more formal publication.

Improved NuGet Integration

Tue, 21 May 2019 09:05:21 Z

NuGet became an essential part of the development for .NET platform over the recent years, as it provided the convenience of creating and consuming the packages.

The packages are easy to discover and use with the help of Package Manager UI in Visual Studio. In reality, adding a package reference to a project often comes down to a single line:

<Project>  
  ...
  <ItemGroup>
    <!-- The line below adds Contoso.HelpfulLibrary NuGet package to the project -->
    <PackageReference Include="Contoso.HelpfulLibrary" Version="1.3.0" />
  </ItemGroup>
  ...
</Project>

Once the package reference is in place, Contoso.HelpfulLibrary can be used by the code.

NuGet does all the heavy lifting. It automatically downloads the package (if it is not downloaded yet), adds an assembly reference to the project, copies required package files at the build time and so on.

Development tends to be much easier with NuGet. And even more so since it also allows to consume tools.

Back in 2014, in addition to .msi setup file, we started to distribute Eazfuscator.NET as a NuGet package. It was essential for build servers as they often prohibited direct software installations. We chose to host Eazfuscator.NET package at a private NuGet server. The integration with the package was made at the solution level, so every protected project would share the same version of Eazfuscator.NET. It did the job and looked good, at first.

The time revealed some significant imperfections. One of them was related to new PackageReference format that had to replace an older packages.config. The new format had no support for solution-level NuGet packages. It meant that some newer project types such as .NET Standard and .NET Core could not consume Eazfuscator.NET as a package. Also the original package did not play well with NuGet restore operation due to implementation specifics. Finally, as NuGet was gradually becoming a more mature technology, we faced a considerable demand for a public Eazfuscator.NET package at nuget.org.

The new Eazfucsator.NET 2019.1 takes it all to the perfect state:

Eazfuscator.NET package is publicly hosted on nuget.org
Both PackageReference and packages.config formats are supported out of the box
The package is now integrated at the project level
All known edge corners are rectified

Using the new Eazfuscator.NET is no different from any other NuGet package:

<Project>  
  ...
  <ItemGroup>
    <PackageReference Include="Gapotchenko.Eazfuscator.NET" Version="2019.1.538" />
  </ItemGroup>
  ...
</Project>

Once the package is added, the project is automatically obfuscated every time you build it in Release configuration.

Try it now

Automatic Handling of Windows Forms Data Binding

Tue, 30 Apr 2019 18:35:42 Z

Many users of Eazfuscator.NET use Windows Forms technology to build application UI. Windows Forms provides a set of controls that allows to display data and interact with a user. Sometimes, the displayed data is not set to UI controls directly. A common practice is to use a data binding mechanism that allows to tie the object properties by name. To get property values by name, data binding uses Reflection API.

Consider a simple code that creates a list of products:

class Product  
{
   public int ID { get; set; }
   public string Title { get; set; }
   public string Description { get; set; }
}

// …

var products = new List<Product>  
{
   new Product { ID = 1, Title = "Juice", Description = "Juice description" },
   new Product { ID = 2, Title = "Tea", Description = "Tea description" },
   new Product { ID = 3, Title = "Coffee", Description = "Coffee description" }
};

Let’s display the products in the ComboBox control by title:

productsComboBox.DisplayMember = "Title";  
productsComboBox.DataSource = products;

That’s how it all works:

But what happens if we obfuscate such code? During obfuscation, the names of classes and their members change. When renamed, the Title property is no more available for binding by its old name:

Before now, the workaround was to manually exclude the Title property from renaming using the ObfuscationAttribute:

using System.Reflection;

class Product  
{
   public int ID { get; set; }

   [Obfuscation] // <-- the obfuscation attribute excludes Title property from renaming
   public string Title { get; set; }

   public string Description { get; set; }
}

It looks simple, but in a real application with a large amount of data displayed, this can turn into a nightmare. That’s why we added out of the box coverage for this scenario in Eazfuscator.NET 2018.4. It features support for Windows Forms binding semantics by automatically tracking corresponding properties and preserving them during obfuscation:

Of course, all the other class members get completely obfuscated to the maximum possible extent.

Try Eazfuscator.NET now

Elements of Homomorphic Code Encryption

Wed, 05 Dec 2018 19:02:27 Z

I have great news to share.

We were able to identify and leverage some useful properties of a partially homomorphic cryptosystem to achieve a considerably better obfuscation results.

How much better? Up to the point where parts of a program remain totally unobservable unless they hit the actual execution path. This means that such parts cannot be decompiled unless they are executed. In other words, they become statically undecompilable.

Full disclosure and details are to follow. Stay tuned for the future Eazfuscator.NET release and accompanying publications. Obfuscation remained one of the most intriguing challenges of a humankind. And it looks like we became one step closer to nailing it.

Eazfuscator.NET 2018.4 provides just some elements of homomorphic encryption as a part of code and data virtualization. The fully featured release of this technology is planned for Eazfuscator 2019.1.

Homomorphic encryption feature is on by default. If you have a project that was previously obfuscated by an earlier version of Eazfuscator.NET then you need to bump project compatibility version to 2018.4 or higher in order to take the benefits of homomorphic encryption.

UPDATE: The discovery is fully disclosed at dedicated article.

Your First Product

Tue, 19 Jun 2018 08:53:20 Z

I know that a lot of Eazfuscator.NET users are product makers. And product creation still remains a twilight area.

Yesterday I stumbled upon Leon's Bambrick Your First Product and it got me hooked. Here is the excerpt I liked the most:

When you're building a product you need to view your product from the customer's point of view. You need to see it with "fresh eyes", with the eyes of a beginner.

This is very hard to do. In fact, it's impossible. But you must try.

That's an important point.

Software developers are often plagued by a tunnel vision. They may think they do the good to a customer, but in reality they do the damage. Growing an empathy for customers is a natural way to overcome that inherent mentality.

There is a lot more:

Check it out: https://yourfirstproduct.com/Info

Seamless Integration with Unity

Fri, 11 May 2018 21:00:48 Z

Eazfuscator.NET 2018.2 brings seamless integration with Unity.

Before, you had to obfuscate your Assembly-CSharp.dll assemblies manually:

That is a simple and good approach. Yet it's not workable for Unity targets with more complex build pipelines (Android et al). For such targets, not only Assembly-CSharp.dll should be built and obfuscated at the right time, it also has to be processed with platform-specific tools. And this is where it gets hard.

Instead of manual Assembly-CSharp.dll obfuscation, you can now add Eazfuscator.NET protection right to your Unity project and get everything automated. The easiest way to do so is to drag Assets folder from Unity IDE, and drop it in the green zone of Eazfuscator.NET Assistant:

Once you do that, Eazfuscator.NET Assistant applies protection to the project:

Now when you build the project with Development Build setting off, Assembly-CSharp.dll will be obfuscated automatically during the build. Eazfuscator.NET does it right no matter what platform a Unity project currently targets thanks to the seamless integration.

Download new version of Eazfuscator.NET

.NET Core, .NET Standard and Portable PDB Support. Delivered

Fri, 16 Jun 2017 02:10:22 Z

Eazfuscator.NET now officially supports .NET Core and .NET Standard technologies.

It was a long ride.

.NET Core started with a bit astronautical project system based on project.json files. While they were useful to some degree, the overall experience was at times disappointing.

Thanks to the Gods of Common Sense, Microsoft then refactored the .NET Core project system to a proven MSBuild format. Visual Studio 2017 brought the new MSBuild-based tooling for .NET Core, so you could enjoy all the goodies of a mature build system.

Not that project.json was an absolute evil. Actually it gave birth to two important concepts we use today:

MSBuild project file format was tidied up and is more friendly to human beings now
It can contain <PackageReference> items in order to effortlessly reference NuGet packages

<PackageReference> items are interesting beasts. While they originated in a galaxy far far way, you can add them to your Windows Forms (or whatever) MSBuild project like this:

<ItemGroup>  
  <PackageReference Include="Newtonsoft.Json" Version="10.0.2" />
</ItemGroup>

And then the magic happens. Newtonsoft.Json library becomes instantly available to your code. I wouldn't be too far away if I say that <PackageReference> is the future.

The new Eazfuscator.NET 5.7 brings full support for all these goodies plus a bit more. Portable PDB is the new file format for debug information. It is not so widespread nowadays but this is the default representation of debug symbols for .NET Standard assemblies. We've got it covered in Eazfuscator.NET 5.7, too.

Download the new version of Eazfuscator.NET

Obfuscation of Value Tuples

Mon, 17 Apr 2017 11:50:51 Z

C# 7 and Visual Basic 15 introduced the notion of value tuples. The concept is similar to what you may find in System.Tuple but with two important distinctions:

The new System.ValueTuple is a value type while the older System.Tuple is a reference type. The value type tends to be a more efficient data type when it comes to passing the values in and out of the method calls
System.ValueTuple has a special compiler support and thus allows to define named fields. This is a big advantage comparing to System.Tuple which only has Item1, Item2, ... properties.

How does it affect the obfuscation? Let's take a look at C# example:

static (int sum, int count) Calc(IEnumerable<int> source)  
{
    var r = (sum: 0, count: 0);
    foreach (var value in source)
    {
        r.sum += value;
        r.count++;
    }
    return r;
}

The given method Calc can be used like this:

static void Main()  
{
    var seq = new[] { 1, 2, 3 };
    var r = Calc(seq);
    Console.WriteLine("Sum: {0}", r.sum);
    Console.WriteLine("Count: {0}", r.count);
}

Please note that method Calc returns a value tuple with two named fields: sum and count. Do those names find their ways into resulting .NET assembly? The short answer is yes. They are specified by C# compiler behind the scenes with TupleElementNamesAttribute as shown below:

[return: TupleElementNamesAttribute(new[] { "sum", "count" })]
static System.ValueTuple<int, int> Calc(IEnumerable<int> source)

This is how it looks after compilation:

As you can see, the field names of value tuples basically become the part of .NET assembly metadata. And they will stay there disclosing the private implementation details to the outside world even when you build the assembly in Release configuration.

You can automatically strip the unneeded field names of value tuples by obfuscating the assembly with Eazfuscator.NET:

Starting with version 5.6, Eazfuscator.NET fully understands the semantics implied by value tuples and takes care to automatically prune the unused value tuple metadata, including the aforementioned field names. Such transformation is not only a win in terms of security, but it also gives slight size and performance benefits.

Give Eazfuscator.NET a try

Deeper Visual Studio Integration

Thu, 16 Jun 2016 18:18:00 Z

What if you had a personal assistant that could guide you through particulars of obfuscation?

Wait no more. Eazfuscator.NET 5.3 introduces a deeper Visual Studio integration that improves your productivity when it comes to obfuscation directives and configuration:

This is achieved by Visual Studio extension which is (optionally) installed by Eazfuscator.NET. Not only it provides the IntelliSense suggestions but also shows you quick tips right in the code:

Eazfuscator.NET also gives you relevant real-time information about possible misconfiguration:

Eazfuscator.NET extension for Visual Studio was made with performance in mind. For example, it is activated for obfuscated projects only and never looks at the projects which do not use Eazfuscator.NET. Moreover, it uses only the most efficient data structures, code and algorithms to make your work productive and pleasant.

Please note that Eazfuscator.NET extension for Visual Studio is optional (though highly recommended). You can remove it from the list of installed components in Eazfuscator.NET Setup or right from Visual Studio:

The presence of Visual Studio extension does not affect the core obfuscation. It works fine with or without the extension.

Eazfuscator.NET extension for Visual Studio has a minimum requirement of Visual Studio 2015. It does not work with older Visual Studio versions.

Here is a brief overview of the extension in action:
www.gapotchenko.com/eazfuscator.net/integration/visual-studio

Resource Sanitization

Thu, 16 Jun 2016 17:00:00 Z

Eazfuscator.NET 5.3 has been released just a few hours ago, and it brings a particularly useful feature: resource sanitization.

Say you have the following XML file as an embedded resource of your .NET assembly:

<!--  
  Please thoroughly consult
  https://www.dropbox.com/s/jv1my3n1e0d/GrandPlanOfThings.pdf?dl=0
  before making a change.
-->
<lisp>  
  (define one? (λ (z) (= z 1)))
  ...
</lisp>

The given Dropbox link is super helpful for developers who are working on the project. It gives them a valuable contextual hint, improves their productivity and lowers the chance of introducing a bug.

The only problem is that you probably don't want to share those useful hints with your competitors. So how to keep the highest productivity level without compromising the security?

Just add the following obfuscation directive to your assembly:

[assembly: Obfuscation(Feature = "sanitize resources *.xml", Exclude = false)]

and Eazfuscator.NET will sanitize all XML resources of your assembly during obfuscation, rendering the perfect outcome:

<lisp>  
  (define one? (λ (z) (= z 1)))
  ...
</lisp>

You can configure resource sanitization in a way you like to meet the specific needs of your project.