[feature request] obfuscate the contents of the generated string table

[rondonjon]

confusion currently creates one big table of all strings. Do you see any chance to further obfuscate this table?

One possible approach to make strings more difficult to read is by converting them to hex notation. Pro: easy to implement, no de-obfuscation needed at runtime, remains difficult to read in debuggers. Contra: increases the filesize significantly (gzip transfer may compensate that)

Another possible option is to crypt all strings during table generation, and then add a decrypt function to the output source code which (either on page load or on demand) returns the original string. Pro: less filesize overhead Contra: more difficult to implement

[rondonjon]

FYI, hex notation doesn't work. the generator rewrites everything as plain strings.

[davidaurelio]

Sorry for not responding earlier, somehow I managed to turn off notifications for this repo. Fixed that :)

Have a look at #1, that’s pretty much the same discussion.

In order to minimize runtime overhead, we’d probably have to decode the strings once, e.g. like

(function(_x24139) {
  a[_x24139[0]](called[_x24139[1]](_x24139[2]));
  an[_x24139[3]](_x24139[4], _x24139[5], _x24139[6]);
}).call(
  this,
 (function(string) { 
   /*DECRYPTION CODE HERE */ 
 }(["yo*`4q%B", "`!5C", ";9\=;ImDb)*oTV6m", "'iT]2", "CJ6=", "0_", ".@Q3]"])
);

This, on the other hand, makes it a “copy & paste into console” operation to get to the actual values.

Since I’m quite busy atm, I don’t have time to spare for such a functionality. I’d be happy to accept a pull request, though.

[jinmel]

I kinda did this implementation on my fork but the code is poor. As @davidaurelio said encrypting string doesn't really help protecting the code. However exposing strings made my boss nervous and I unwillingly implemented this to please him.. :grin: