After obfuscation there is a performance drop for Mirrors

After using this obfuscation above there appears to be an extreme performance dip using Mirrors. Any idea why? Anyone else encounter this?

obfuscation will de-optimise your critical loop code and turn it into slow performing junk code. doing this will threejs, not good!

it wards off some lazy people but if someone really wants your code they get it. the obfuscator is oss and can be reversed, there are even projects out there called “un-obfuscator”.

btw this code:

var variable1 = '5' - 3
var variable2 = '5' + 3
var variable3 = '5' + -'2'
var variable4 = ['10', '10', '10', '10', '10'].map(parseInt)
var variable5 = 'foo ' + 1 + 1
console.log(variable1)
console.log(variable2)
console.log(variable3)
console.log(variable4)
console.log(variable5)

turns into this, it’s no wonder it runs slower

var _0x9947 = [
  'map',
  'log',
  'foo\x20',
  'bvmqO',
  '133039ViRMWR',
  'xPfLC',
  'ytpdx',
  '1243717qSZCyh',
  '2|7|4|6|9|',
  '1ErtbCr',
  '1608314VKvthn',
  '1ZRaFKN',
  'XBoAA',
  '423266kQOYHV',
  '3|0|5|8|1',
  '235064xPNdKe',
  '13RUDZfG',
  '157gNPQGm',
  '1639212MvnHZL',
  'rDjOa',
  'iBHph',
  '9926iRHoRl',
  'split',
]
function _0x33e4(_0x1809b5, _0x37ef6e) {
  return (
    (_0x33e4 = function (_0x338a69, _0x39ad79) {
      _0x338a69 = _0x338a69 - (0x1939 + -0xf * 0x1f3 + 0x1 * 0x469)
      var _0x2b223a = _0x9947[_0x338a69]
      return _0x2b223a
    }),
    _0x33e4(_0x1809b5, _0x37ef6e)
  )
}
;(function (_0x431d87, _0x156c7f) {
  var _0x10cf6e = _0x33e4
  while (!![]) {
    try {
      var _0x330ad1 =
        -parseInt(_0x10cf6e(0x6c)) * -parseInt(_0x10cf6e(0x6d)) +
        -parseInt(_0x10cf6e(0x74)) * -parseInt(_0x10cf6e(0x78)) +
        parseInt(_0x10cf6e(0x6a)) +
        -parseInt(_0x10cf6e(0x70)) +
        parseInt(_0x10cf6e(0x6e)) * -parseInt(_0x10cf6e(0x75)) +
        parseInt(_0x10cf6e(0x72)) +
        -parseInt(_0x10cf6e(0x67)) * parseInt(_0x10cf6e(0x73))
      if (_0x330ad1 === _0x156c7f) break
      else _0x431d87['push'](_0x431d87['shift']())
    } catch (_0x9f878) {
      _0x431d87['push'](_0x431d87['shift']())
    }
  }
})(_0x9947, -0xb6270 + 0x4dfd2 * 0x2 + 0x75460 * 0x2),
  (function () {
    var _0x1f346d = _0x33e4,
      _0x860db8 = {
        ytpdx: _0x1f346d(0x6b) + _0x1f346d(0x71),
        bvmqO: function (_0x560787, _0x519b9e) {
          return _0x560787 - _0x519b9e
        },
        rDjOa: function (_0x4501fe, _0x2b07a3) {
          return _0x4501fe + _0x2b07a3
        },
        xPfLC: function (_0x5f3c9b, _0x434936) {
          return _0x5f3c9b + _0x434936
        },
        XBoAA: function (_0x535b8a, _0x42eef4) {
          return _0x535b8a + _0x42eef4
        },
        iBHph: _0x1f346d(0x65),
      },
      _0x346c55 = _0x860db8[_0x1f346d(0x69)][_0x1f346d(0x79)]('|'),
      _0x3bf817 = 0x4bb * 0x1 + 0x801 + -0xcbc
    while (!![]) {
      switch (_0x346c55[_0x3bf817++]) {
        case '0':
          console[_0x1f346d(0x7b)](_0x4c96d8)
          continue
        case '1':
          console[_0x1f346d(0x7b)](_0x101028)
          continue
        case '2':
          var _0x65977d = _0x860db8[_0x1f346d(0x66)]('5', -0x586 + -0x2195 + -0x6 * -0x685)
          continue
        case '3':
          console[_0x1f346d(0x7b)](_0x65977d)
          continue
        case '4':
          var _0x56d39b = _0x860db8[_0x1f346d(0x76)]('5', -'2')
          continue
        case '5':
          console[_0x1f346d(0x7b)](_0x56d39b)
          continue
        case '6':
          var _0x544285 = ['10', '10', '10', '10', '10'][_0x1f346d(0x7a)](parseInt)
          continue
        case '7':
          var _0x4c96d8 = _0x860db8[_0x1f346d(0x68)]('5', 0x622 * -0x6 + 0x4a * 0x3 + 0x1 * 0x23f1)
          continue
        case '8':
          console[_0x1f346d(0x7b)](_0x544285)
          continue
        case '9':
          var _0x101028 = _0x860db8[_0x1f346d(0x6f)](
            _0x860db8[_0x1f346d(0x6f)](_0x860db8[_0x1f346d(0x77)], 0x6fb * 0x5 + 0x1ebf * 0x1 + -0x41a5),
            0x209 * 0xa + 0x1314 + -0x276d
          )
          continue
      }
      break
    }
  })()
1 Like

I get that obfuscation can be detrimental to performance and I agree that it is a bit ott but are you saying you can deobfuscate the obfuscated code you’ve shared to read as the original you posted above it? I’ve tried with a few online tools with little to no improvement of readability, definitely nothing like the original code snippet you posted…

@FuzzyWobble you can try setting “splitStrings” to false, it’s likely that there’s shaders defined as strings in the mirror class which are all going to be broken into smaller nightmare chunks, it’s worth playing around with the settings of the obfuscator you’re using, you can also try only obfuscating certain important parts of your code too maybe…

@drcmda I think obfuscation can be a very important tool, especially if working and sharing code that might be contractual, it can add a level of security so working environments can be experienced and navigated until the contract is fulfilled, at which point the source can be released… Its definitely not optimal or something you’d want to push to deployment builds though unless very subtle settings are used which simply shorten variable and function names

here: https://deobfuscate.relative.im

so easy, now i have your code.

  var _0x65977d = '5' - 3
  var _0x4c96d8 = '5' + 3
  var _0x56d39b = '5' + -'2'
  var _0x544285 = ['10', '10', '10', '10', '10'].map(parseInt)
  var _0x101028 = 'foo ' + 1 + 1
  console.log(_0x65977d)
  console.log(_0x4c96d8)
  console.log(_0x56d39b)
  console.log(_0x544285)
  console.log(_0x101028)

at best obfuscation stops casuals. and if that tool above didn’t exist, since the obfuscator is open source really all you’d need to do is reverse it. an afternoon of work. even if the obfuscator is proprietory, AI will have a field day with this.

2 Likes

I ran the deobfuscator on some previously obfuscated code and it outputs this:


So yes it definitely deobfuscates the code very well, but the final output is still quite annoying to make sense of with the variable names turned to nonsense, so I guess it’s better than nothing…

imo not annoying at all. code’s there. add something that re-establishes the variable names and it may be better then the original:

it is what it is, if a 100x negative performance impact is worth it so that a casual won’t be able to read it, go for it.

2 Likes

Interesting, I tried with one of my projects and got the following result…

Starting deobfuscation with timeout of 2 minutes
Deobfuscation error! SyntaxError: 'import' and 'export' may appear only with 'sourceType: module' (1:1449)

looks like you have to use the cli tool directly, it has more options. but im not familiar with it, was just the first thing i found.

1 Like

The goal of obfuscators is to obfuscate, i.e. to deform the code to a point it is incomprehensible by humans, but still keep it working. The cost for this is often performance. In most cases this lost of performance is not noticeable, but is some time-critical and performance-critical situations (as in 3D graphics) obfuscation has a pretty negative impact. For example, I’ve seen obfuscators that decompose constants and function calls and then composing them back in real-time. This kills all possible optimizations.

No, when I meet obfuscated code, it is usually in some simple cases. And I have never obfuscated my own code too. In the past I thought of doing it – it was for a 3D interactive student assessment tool. I didn’t want the students to easily see the code. But then I told myself, hey, if they look in the source, they will more than simply studying for the exam. So I just minified the source, keeping the actual (and long) names of variables… + I also gave the students the original source code. And I have never felt sorry for this.

@drcmda thanks for your brutally passive agressive help :melting_face:

haha, that’s me in a nutshell :joy:
but i do hope it helped to at least get another perspective. in a company i’ve worked for we got our obfuscated code stolen. there is very little safety in that.