Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The decoder should not pollute a global scope unless it's fine #7

Closed
lifthrasiir opened this issue Aug 25, 2021 · 1 comment
Closed
Assignees
Labels
bug Something isn't working enhancement New feature or request
Milestone

Comments

@lifthrasiir
Copy link
Owner

lifthrasiir commented Aug 25, 2021

<canvas id=a><script>/* Roadroller output from a JS code using a */</script>

This won't work, because a (among others) gets assigned during the decompression and it shadows window.a.

The problem is that this might be okay depending on the input, and we definitely want to exploit that whenever possible. There are ~16 variables used by Roadroller, carefully chosen so that the decoder gets compressed more, and changing any of them can have undesirable effects. One possible resolution is to put everything into a giant function:

eval(((A='....', t=1234, a, c, f, l, ...) => {
    /* code */
})())

But I'm not sure how to make it compatible with multiple inputs (#8).

Workaround

For now you should avoid using the following ids in your HTML, either outside <script> or written with document.write.

A M a c e f l m o p r t u w x y

If you can't avoid using them there are two other workarounds:

  • Prepend window. to all uses of such variables.
  • Put delete VARIABLE; for all affected variables at the beginning of your code.
@lifthrasiir lifthrasiir added bug Something isn't working enhancement New feature or request labels Aug 25, 2021
@lifthrasiir lifthrasiir self-assigned this Aug 25, 2021
@lifthrasiir lifthrasiir added this to the 1.3.0 milestone Aug 26, 2021
@lifthrasiir
Copy link
Owner Author

lifthrasiir commented Aug 26, 2021

I've experimented with multiple implementation strategies:

  • Insert delete VARIABLE;s at the beginning of the input. This turned out to be unworkable if the variable was only used locally and got hoisted (delete f; function f() { ... } will be incorrect for example). So this workaround only works when we do the escape analysis, which is unreasonable for Roadroller.
  • Insert delete VARIABLE;s right before the actual eval. This is less invalid than before but still can cause a problem if there is other uncompressed code around. I'm not sure if we should support this mode or not though.
  • eval(((A='COMPRESSED DATA', VARIABLES...) => { VAR=INIT; ...; return c })()) was very lengthy.
  • eval(eval("let A='COMPRESSED DATA'," + [...'VARIABLES'] + "; VAR=INIT; ...; c")) avoids return but VARIABLES should be unique, limiting the optimization possibility. A variant using var would allow duplicates but pollutes the global scope.
  • eval(Function("A='COMPRESSED DATA'", ...'VARIABLES', "VAR=INIT; ...; return c")()) still has the same problem but seems to be a bit smaller.
  • eval(Function("A='COMPRESSED DATA'", ...'SOME VARIABLES', "VAR=INIT", "...; return c")()) combines initial assignments with argument definitions.
  • eval(Function("[A='COMPRESSED DATA'", ...']VARIABLES', "...; return c")([], INIT...)) eliminates initial assignments by reusing arguments. The first variable has to be undefined, hence a weird argument definition (translates to [A=...,],V,A,R,I,A,B,L,E,S). This seems to be the best alternative so far, only ~25B larger than before. (But see below.)

Some of these experiments required another variable renaming, and honestly I'm sick of it. So the next step is to make variable names fully configurable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant