Deobfuscate control flow flattening with dead code injection

[821938089]

After deobfuscating of this code, some parts are still obfuscated. obfuscated.txt

Obfuscation 1: An object stores a lot of simple functions and literals.

Obfuscation 2: An object references some literals or functions in another object.

[j4k0xb]

In general it supports deobfuscating these objects, but often fails when dead code injection is enabled additionally: Code in the red boxes is removed later and f = m.QMyUp(g, m.AuWjE); never runs but makes it much harder to distinguish from normal user code that should be ignored. E.g.:

var m = {
  abcde: 'abc'
};
if (....) {
  m = {
    abcde: 'xyz'
  }
}
console.log(m.abcde);

[j4k0xb]

Here you can test a workaround but it's not guaranteed to be safe: https://deploy-preview-45--webcrack.netlify.app/

[821938089]

I tested that the deobfuscated code runs fine. While inspecting the code I found that some of the useless obfuscated code was not removed.

Regarding the above question, in general, it is possible to assume that the objects generated by the obfuscator are not reassigned. You also can try deobfuscate the if statement first to confirm that the branching code will not run.

[j4k0xb]

it is possible to assume that the objects generated by the obfuscator are not reassigned

Yes that's what was checked for previously

https://github.com/j4k0xb/webcrack/blob/3aeada5740a8a66f64ec8a8a5375218aa0bf8016/packages/webcrack/src/deobfuscate/control-flow-object.ts#L115-L121

You also can try deobfuscate the if statement first to confirm that the branching code will not run.

I tried..

its the messiest code ever and there are still so many edge cases left:

• It might find a branch that calls fQUgr: function (p, q) { return f.zvlrc(p, q); but f hasn't been deobfuscated/inlined yet
• f could also be initialized later: https://github.com/j4k0xb/webcrack/blob/3aeada5740a8a66f64ec8a8a5375218aa0bf8016/packages/webcrack/src/deobfuscate/test/samples/obfuscator.io-control-flow-keys.js#L30-L34
• The function in f could again reference another object instead of directly returning a === b, etc.

There's no way to do it "first" because of the order in which these objects are created

[821938089]

I mean don't do these checks, just inline them.

It might find a branch that calls fQUgr: function (p, q) { return f.zvlrc(p, q); but f hasn't been deobfuscated/inlined yet

what is "f hasn't been deobfuscated/inlined yet" ? Will the objects generated by the obfuscator be obfuscated?