Obfuscation methods are using patchable functions that makes code unsafe

[doctor8296]

Hello! First of all I want to say that this tool is great. Previously I was using only javascript-obfsucator, but it was extremily easy to deobfuscated and debug. Some people even did whole deobfuscators based on the obfuscation logic of the javascript-obfuscator.

Okay, now I will give a little bit of context. I am web game anticheat dev. My client side anticheats were used in multiple games, and it was pretty effective, even tho it is just uncopmlite version of actual anticheat (actual versioun requires a lot of server related work which is extremily difficult and have a lot of issues at implementing it on ready made games + plus it has bad relationships with hashing).

So, since I was using javascript obfuscator on custom low obfuscation config, because I couldn't use any other since it took huge chunk of performance (like 2 seconds, which is unacceptable for the game or site), for hackers it was very easy to handle it "on fly" and edit specific places in code to make it work like they wanted. Even tho they did it I was very happy that they were forced to do this out of options, instead of trying to monkeypatch this (basically my anticheat protects from monkeypatching).

So I wanted to make it stronger. And in you library I see a lot of great features for that, but unfortunatly a lot of them use patchable function to make them work.

Patchable functions are methods / global functions / global classes that can be redefined. Here the example of one:

const S_charCode = "S".charCodeAt(0);

And this function (method String.prototype.charCodeAt) can be patched, for example like this:

String.prototype.charCodeAt = function() {
    return "fake value"
}

And this is unsafe.

The live example of it is source protection. I actually use hash source protection that wraps all the completed / obfuscated code into function, then I am getting the hash of this function and pass as argument. Inside of this function I am getting the function signature and compare it's hash with passed hash. Obviously to hash it I have to use chatCodeAt to get char code and base hash value on it. I did it by creating static dictionary of all existing symbols:

      return {
        0: 48,
        1: 49,
        2: 50,
        3: 51,
        4: 52,
        5: 53,
        6: 54,
        7: 55,
        8: 56,
        9: 57,
        ":": 58,
        ";": 59,
        "<": 60,

Alright. Now I'll show some specific case of the methods of the JS-Confuser which we can make safier.

• String compression I don't quite understand how this option works, but I see that it use patchable/unsafe methods like: join, split, charCodeAt, charAt, push, pop There are a safe analogs of this functions, however, it will make my comment way longer than it should. If not replacing them, it could be amazing to have customisable function for encoding and other string-operate functions (such as String concealing, String encoding)! The same issue is related to the array shuffle.

• Duplicated literal removal This method is interesting as well, I kind wanted to implement my own in my obfuscator. This thing is great, but it has some little issue with it. It has OVV74A9['call'](this) for no obvious reason. I can imagine only one case, for example when function returns array that has arrow function... I am not sure, but apperantly it has a reason, but it still stays unsafe.

• Dispatcher It has similar to Duplicated literal removal issue, but it also uses spread operator in arguments. And yeah... spread operator is also hackable.

• Opaque Predicates To be honest, I don't really see any changes on my example code, maybe this is a bug. (At we version)

• Dead code Little comment on Dead code option Deobfuscators (such as deobfuscate.relative.im) can easily find such expressions that are obviously "dead". You can make it more difficult for deobfuscators by creating check when even human can never be sure. For example "key123" in {} (we can never be sure that prototype hasn't this property defined... well... yeah it can break someones code, but who defines something on global prototype anyway, right? I can modify this example).

• Stack / Flattern Another very interesting option. But it has unsafe spread operator use, defineProperty (for some reason). Also I think I should mention that adding properties to object that didn't originaly had it is a bad idea from the safetiy side, since it can be redefined. unsafe:

  const obj = {}
  obj[key] = "new value"
  ```safe:
  ```js
  const obj = {
  key: null
  }
  obj[key] = "new value"

• Rgf It has huge potential but it is weird and unsafe in both term.

Overall this thing is great. I cannot ask you to implement this things that I meantioned, probably gonna do it myself. Web security and monkeypatching is very difficult topics, that no one actually know about and only a few neet it.

Little comments:

• _=>_=>_=>...=>_ <- this thing will kill obfsucator.
• debugger stuff is not that effective against monkeypatching at all (we can just manualy disable setInterval and fake Date.now)
• do you use hashing for integrity check?
• footer on js-confuser.com is hidding very buttom of the code
• if you select shuffle false on js-confuser.com it will still try to shuffle arrays with length > 2