I'm fairly sure we're talking practically snake oil here. I wrote up a pretty long post on it before, but didn't get around to posting it, but since I have nothing else to do...
The subject matter is Indistinguishability obfuscation. The central idea seems to be, take a finite series of significant operations to do something, and generate some other program that maps the same input/outputs, but with a massive bump in complexity
An example to illustrate by the original authors is a banking application that instead of containing your password in memory at any recognizable point, magically makes sure the right bits get to where they need in order to be validated.
A bunch of other benefits are touted such as plausible deniability (the program can look like (!a-banking-program in obfuscated form) and if decompiled, you can't figure out which version of the artifact came from what build toolchain apparently.
Throwing my best effort understanding at it, I cannot say as I find anything remotely practical, as all this thing seems to promise to do is somehow magically hide what it's doing every execution by...eating up more processing cycles doing more stuff that isn't what you set out to do in the first place. This is being optimistic mind, and accepting it's even remotely possible. I still need to wade through their math. I've been putting it off, because I generally have a very hard time with papers claiming to have done something that doesn't make any sense whatsoever.
Like if you imagine such a thing as an executable artifact, the only way I see it working is you've got this chunk of generative code in some library somewhere, you're dynamically linked, or hell, statically linked against it, your trace goes into that code for a long bloody time while you keep track of other tracepoints, and reconstitute what step in a known set of transformations is getting near-GIGO'd to hell and back. I mean, you can explode the implementation details of an encryption key bit get as much as you like, but if you want performance, you have to get those bits marshalled to the right place to feed unobfuscated decryption. Furthermore, hust think of the issues created by that generative piece. Run it in a reversing debugger, and all you get is a bigger pain in the arse trying to figure out what's going on, unless you already know what the thing is mostly up to, in which case enough understanding of the logistics of the program's functionality and the physical nature of information transfer dictates you can simplify the information down to a simplest possible transformation.
Unless, that is, you're swinging for the theoretical fences, and what you set out to do is so badly performant, it's difficult to even qualify it as computing anymore. I may be wrong, but this whole thing strikes me as sliding off the truck of realistic utility.
Oh Goodness.
This again.
I'm fairly sure we're talking practically snake oil here. I wrote up a pretty long post on it before, but didn't get around to posting it, but since I have nothing else to do...
The subject matter is Indistinguishability obfuscation. The central idea seems to be, take a finite series of significant operations to do something, and generate some other program that maps the same input/outputs, but with a massive bump in complexity
An example to illustrate by the original authors is a banking application that instead of containing your password in memory at any recognizable point, magically makes sure the right bits get to where they need in order to be validated.
A bunch of other benefits are touted such as plausible deniability (the program can look like (!a-banking-program in obfuscated form) and if decompiled, you can't figure out which version of the artifact came from what build toolchain apparently.
Throwing my best effort understanding at it, I cannot say as I find anything remotely practical, as all this thing seems to promise to do is somehow magically hide what it's doing every execution by...eating up more processing cycles doing more stuff that isn't what you set out to do in the first place. This is being optimistic mind, and accepting it's even remotely possible. I still need to wade through their math. I've been putting it off, because I generally have a very hard time with papers claiming to have done something that doesn't make any sense whatsoever.
Like if you imagine such a thing as an executable artifact, the only way I see it working is you've got this chunk of generative code in some library somewhere, you're dynamically linked, or hell, statically linked against it, your trace goes into that code for a long bloody time while you keep track of other tracepoints, and reconstitute what step in a known set of transformations is getting near-GIGO'd to hell and back. I mean, you can explode the implementation details of an encryption key bit get as much as you like, but if you want performance, you have to get those bits marshalled to the right place to feed unobfuscated decryption. Furthermore, hust think of the issues created by that generative piece. Run it in a reversing debugger, and all you get is a bigger pain in the arse trying to figure out what's going on, unless you already know what the thing is mostly up to, in which case enough understanding of the logistics of the program's functionality and the physical nature of information transfer dictates you can simplify the information down to a simplest possible transformation.
Unless, that is, you're swinging for the theoretical fences, and what you set out to do is so badly performant, it's difficult to even qualify it as computing anymore. I may be wrong, but this whole thing strikes me as sliding off the truck of realistic utility.