search

j4k0xb / webcrack

Deobfuscate obfuscator.io, unminify and unpack bundled javascript
https://webcrack.netlify.app
MIT License
663 stars 72 forks source link

(0, fn)(...args) type of calls #6

Open mr-cheater opened 1 year ago

mr-cheater commented 1 year ago

Is there any particular reason to not replace calls like (0, fn)(...args) to just fn(...args)? Also, would be great to know in which cases webpack does this kind of transformation if anyone knows...

j4k0xb commented 1 year ago

(0, fn)(arg) should be converted, thanks for the suggestion

but in other cases it's not guaranteed to be safe webpack or TS do it so exported functions aren't called with a different this E.g. this inside (0, lib.fn)(arg) is undefined but in lib.fn(arg) it's the lib object

Maybe the function can be analyzed, or I'll just add an option to use unsafe transforms

mr-cheater commented 1 year ago

Yeah that's what it does but do you really see any possible issue with not removing context for such function calls? I mean it could be useful in super specific and advanced JS cases, but assuming Webpack usually works with ES/TS codebases, it shouldn't really be the issue. That's why I've asked about cases when it does that as I'm almost sure that it doesn't do this particular transform because of specific of the source code and in raw ES/TS source the calls would be made with this context anyway.

mr-cheater commented 1 year ago

Seems like webpack does this only in case fn has no internal references to this so should be perfectly safe to convert it?

j4k0xb commented 1 year ago

Just checked: TS and webpack do it for all functions Here's an example where it would fail without: https://github.com/es-shims/Promise.allSettled/issues/5 That's what I meant with analyzing... Have to make sure the functions don't reference this to transform it back safely

0xdevalias commented 8 months ago

I came across another tool today that seemed to handle this pretty well:

Digging through the code a little lead me to this:

j4k0xb commented 8 months ago

good idea to do it like this 👍🏻 Another thing I noticed is that bundlers only create (0, lib.fn)() if it was originally an esm import, so it should be enough to identify the module type and convert all require to named imports