3 ms·

Man, if you didn't care about performance or bandwidth, this would be a hell an of obfuscation technique.

simcop2387 14y ago
Performance might not be too bad actually. My understanding is that he's building up a string with the code you run normally and then evaling it, so the performance might not be bad, aside from the start-up cost. Bandwidth... I don't want to speculate on that one :)
- mistercow 14y ago
  Actually, I did a small test and found that after gzip, the file size only expands by about 10x. Running both input and output through bz2, the obfuscated file only comes out 3x larger. If you were very protective of your code, and you had enough of it to justify loading up a bz2 decoder on the client side, you could actually make that economical bandwidth-wise. That said, this was a very small test; the original file was a random snippet of JS code less than 500 bytes, and that itself took a considerable amount for hieroglyphy to chew on, so I can't really do a proper test of a larger input file.
  - dherman 14y ago
    I think if you wanted to make this really robust, you could use more techniques to beef it up. One technique would be to store verbose or commonly-used string constants in accessible locations like Array.prototype.f. Then you could access, say, the string "prototype" by simply writing [][(![]+[])[+[]]] Once you build up a little scratch storage of the most common or hard-to-encode strings, everything starts getting orders of magnitude smaller. (Technically, this means that you're polluting the space shared with the program being encoded, so for everything to work the program can't make use of it. But that's a pretty simple invariant to ask of the input program: "don't get or set the 'f' property of arrays.") Another technique would be to break up large statements into smaller substatements, to avoid fixed limits of JS engines on statement size. You can always avoid semicolons, since ASI is guaranteed to work if you start your statement with a !. Dave
alcuadrado 14y ago
This is pretty easy to reverse. Most JS parsers can print the source code of functions, so you can do that for the generated lambdas.
- mistercow 14y ago
  Yes of course. And even if they couldn't, it would be trivial to fork an existing JS implementation and make eval spit out its input.
shurane 14y ago
But think of the reduced complexity (in terms of characters) this language is! This makes me think of the small amount of primitives needed to make a LISP machine. Or Brainfuck. Or Unlambda.
- gmrple 14y ago
  Eh, I can restrict my self to ones and zeros for even more reduced language complexity and have amazing performance if I'm clever.
simonster 14y ago
Bandwidth is probably not too bad. It seems like it would be quite amenable to gzip.
- mistercow 14y ago
  I mentioned in another reply that it actually does gzip fairly well (and bzips even better). But you still end up with an order of magnitude expansion with gzip (as compared to gzipping the original source), and around 3x expansion with bz2 (again compared to bz2 on the original source). That's from a <0.5KB test input, so the expansion might be mitigated a little more for larger files. I was going to test on a 3KB microlibrary, but gave up after about 10 minutes of waiting for the conversion to finish.
mseebach 14y ago
That's not neccesary, I've got right-click disabled on my website.
- erichocean 14y ago
  Okay, that made me laugh. :)

Performance might not be too bad actually. My understanding is that he's building up a string with the code you run normally and then evaling it, so the performance might not be bad, aside from the start-up cost. Bandwidth... I don't want to speculate on that one :)

mistercow 14y ago
Actually, I did a small test and found that after gzip, the file size only expands by about 10x. Running both input and output through bz2, the obfuscated file only comes out 3x larger. If you were very protective of your code, and you had enough of it to justify loading up a bz2 decoder on the client side, you could actually make that economical bandwidth-wise. That said, this was a very small test; the original file was a random snippet of JS code less than 500 bytes, and that itself took a considerable amount for hieroglyphy to chew on, so I can't really do a proper test of a larger input file.
- dherman 14y ago
  I think if you wanted to make this really robust, you could use more techniques to beef it up. One technique would be to store verbose or commonly-used string constants in accessible locations like Array.prototype.f. Then you could access, say, the string "prototype" by simply writing [][(![]+[])[+[]]] Once you build up a little scratch storage of the most common or hard-to-encode strings, everything starts getting orders of magnitude smaller. (Technically, this means that you're polluting the space shared with the program being encoded, so for everything to work the program can't make use of it. But that's a pretty simple invariant to ask of the input program: "don't get or set the 'f' property of arrays.") Another technique would be to break up large statements into smaller substatements, to avoid fixed limits of JS engines on statement size. You can always avoid semicolons, since ASI is guaranteed to work if you start your statement with a !. Dave

alcuadrado 14y ago

This is pretty easy to reverse. Most JS parsers can print the source code of functions, so you can do that for the generated lambdas.

mistercow 14y ago
Yes of course. And even if they couldn't, it would be trivial to fork an existing JS implementation and make eval spit out its input.

shurane 14y ago

But think of the reduced complexity (in terms of characters) this language is! This makes me think of the small amount of primitives needed to make a LISP machine. Or Brainfuck. Or Unlambda.

gmrple 14y ago
Eh, I can restrict my self to ones and zeros for even more reduced language complexity and have amazing performance if I'm clever.

simonster 14y ago

Bandwidth is probably not too bad. It seems like it would be quite amenable to gzip.

mistercow 14y ago
I mentioned in another reply that it actually does gzip fairly well (and bzips even better). But you still end up with an order of magnitude expansion with gzip (as compared to gzipping the original source), and around 3x expansion with bz2 (again compared to bz2 on the original source). That's from a <0.5KB test input, so the expansion might be mitigated a little more for larger files. I was going to test on a 3KB microlibrary, but gave up after about 10 minutes of waiting for the conversion to finish.

mseebach 14y ago

That's not neccesary, I've got right-click disabled on my website.

erichocean 14y ago
Okay, that made me laugh. :)