Repository navigation
[Improvement] Numbers to expressions improvement #773
Description
Hello!
I have some ideas how to improve numbersToExpressions feature.
One of pros it that code will become uglier and also it will be harder to parse it with regex, as it does javascript-deobfuscator 😏
I think this construction is familiar to you:
const a = ("foo", "bar");
It is not kind of array or similar, it is just chain of literals, so result will be the last - a == "bar".
So, my idea is to replace some number literals to this construction.
// Before:
-0xd93 + -0x10b4 + 0x41 * 0x67
// After
-0xd93 + (-0xff8, -0x10b4) + 0x41 * 0x67
And second idea is even for all numbers.
Use different number formats.
Not only hexadecomal, but also decimal, binary and octal:
// Before:
-0x377 * 0x1 + 0x1 * 0x1871 + -0x1e * 0xb3
// After
-887 * 0x1 + 0x1 * 0o14161 + -0b11110 * 0xb3
// Uppercase - even uglier=)
-887 * 0X1 + 0X1 * 0O14161 + -0B11110 * 0XB3
Reacted by Timofey Kachalov, Dbuggerx and relative
Activity
sanex3339 commentedon Oct 10, 2020
So. It's a slightly different thing. The type of number view does not relate with
numbersToExpressionsoption.It just could be an enhancement of base numbers transformation.
But here is a problem. If I will just randomly transform number to one of the number formats, it can be hard to test it, because right now all tests with numbers depend on the hexadecimal format.
da411d commentedon Oct 10, 2020
It can be moved to another option like
numbersFormats(array) with list of supported formatssanex3339 commentedon Oct 10, 2020
Hmm. Looks good to me.
rmcf commentedon Aug 28, 2023
I tried to use “numbersToExpressions” option, but received “not obfuscated” results in some cases: