Missing callback for encoding string values

uxebu / confusion

Simple obfuscator for JavaScript source code

ISC License

31 stars 6 forks source link

Missing callback for encoding string values #1

Closed ghost closed 9 years ago

ghost commented 9 years ago

Missing callback for encoding string values Will be useful, u can make strings unreadable too with it.

davidaurelio commented 9 years ago

How would the encoded strings be decoded at runtime? Do you have any specific API and/or result in mind?

ghost commented 9 years ago

Take a look here: http://javascriptobfuscator.com/Javascript-Obfuscator.aspx

Basically I've noticed that Confusion already encode unicode characters to \u0000 form. But ascii characters leaves unchanged, but it could encode them to \x00 form.

davidaurelio commented 9 years ago

I see what you mean.

We’ve relinquished to do that for a couple of reasons:

when post-processing the output (e.g. with a minifier) those escape sequences are going to get decoded again.
these escape sequences are trivial to decode, and might add non-trivial size overhead.

Therefore, we won’t add this feature to confusion.

davidaurelio commented 9 years ago

If you try this out on http://www.jsnice.org you’ll see that it does not really help. Closing.

ghost commented 9 years ago

This is truth that these escape sequences are trivial to decode, but we can say that all Confusion mechanisms are trivial to decode and this is truth too. I think this is the missing puzzle piece of Trivial to decode Confusion module.

davidaurelio commented 9 years ago

@Kamil93 I’ll be happy to accept a pull request, I just don’t want to invest time myself.

Tbh, I don’t even know whether that’s easy to achieve with the current toolchain: We are using escodegen (but might change back to recast) for code generation. I fear that an ast node for "a" might be just the same as for "\x61".