I've been using software obfuscation and encryption for about a decade, and this is the first time I've ever heard of "obfuscation" being used that way. Pretty much every single software protection program/solution out there makes a very hard distinction between obfuscation and encryption. They can be used together, but they are by no means similar in anything that they do - well, that is what I get from every vendor that I've ever looked at. (I'm over-simplifying, but other aspects of obfuscation are not significantly different in the abstract - they are all replacements.)
Many software obfuscators out there create an obfuscation map. It's a simple file that maps the obfuscated values to what the programmer wrote. So, you end up going from a, b, c back to year, month, day. It's a flat, linear transformation.
Here's a partial example of a map from a 1-off program that I wrote to do some data cleaning and normalization:
<map>
<field>
<signature>System.Windows.Forms.Label</signature>
<name>lblEfwYear</name>
<newname>k</newname>
</field>
<field>
<signature>char[]</signature>
<name>split</name>
<newname>a</newname>
</field>
<field>
<signature>System.Windows.Forms.TextBox</signature>
<name>txtCountries</name>
<newname>c</newname>
</field>
<field>
<signature>System.Windows.Forms.TextBox</signature>
<name>txtEfwYear</name>
<newname>l</newname>
</field>
<field>
<signature>System.Windows.Forms.TextBox</signature>
<name>txtOriginal</name>
<newname>e</newname>
</field>
<field>
<signature>System.Windows.Forms.TextBox</signature>
<name>txtTransformation</name>
<newname>f</newname>
</field>
<field>
<signature>System.Windows.Forms.TextBox</signature>
<name>txtYears</name>
<newname>d</newname>
</field>
<otherstuff />
<method>
<signature>void(object, System.EventArgs)</signature>
<name>btnInsurance_Click</name>
<newname>h</newname>
</method>
<method>
<signature>void(object, System.EventArgs)</signature>
<name>btnInsurance2_Click</name>
<newname>c</newname>
</method>
<method>
<signature>void(object, System.EventArgs)</signature>
<name>btnSchool_Click</name>
<newname>i</newname>
</method>
<method>
<signature>void(object, System.EventArgs)</signature>
<name>btnSchool2_Click</name>
<newname>d</newname>
</method>
<method>
<signature>void(bool)</signature>
<name>Dispose</name>
</method>
<method>
<signature>void(object, System.EventArgs)</signature>
<name>Form1_Load</name>
<newname>k</newname>
</method>
<method>
<signature>void()</signature>
<name>InitializeComponent</name>
<newname>a</newname>
</method>
</map>
Here's the abstract:
http://eprint.iacr.org/2013/451Abstract: In this work, we study indistinguishability obfuscation and functional encryption for general circuits:
Indistinguishability obfuscation requires that given any two equivalent circuits C_0 and C_1 of similar size, the obfuscations of C_0 and C_1 should be computationally indistinguishable.
In functional encryption, ciphertexts encrypt inputs x and keys are issued for circuits C. Using the key SK_C to decrypt a ciphertext CT_x = Enc(x), yields the value C(x) but does not reveal anything else about x. Furthermore, no collusion of secret key holders should be able to learn anything more than the union of what they can each learn individually.
Sigh... Looks like yet another case of reporters not knowing about what they're reporting on and not understanding the terminology. The researchers are using the language normally.
Some friends and people I know (mISVs) actually roll their own solutions. But they're really damn good at it. They've found that most commercial solutions were simply too easy to crack (they cracked them), and it was simply better to do it themselves. (Ballsy.) One fellow wrote up a portion of his approach called "partial key verification". It's interesting, but not what these guys are doing.
I do wonder how they get around the dumping problem though... Maybe I'll read on it later after I finish some work. (I'm goofing off at the moment.
)
