Clearing the Fog: Obfuscators vs Protectors

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 a encrypted binary blob which then gets decrypted to a memory and executed 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 a now historical piece of software called NetWinProtector by Safe Lion:

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:

NetWinProtector Register

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:

NetWinProtector 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 its supposedly protected modules from 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:

NetWinProtector assembly viewed in JetBrains dotPeek decompiler

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 2n 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...

comments powered by Disqus