This method could also be used to evade XSS filters.
For e.g. I believe encoding code using something similar is the only way to solve this challenge - http://escape.alf.nu/9/
Brainfuck beware: JavaScript is after you (2012)
31–39 of 39 posts
Re: Brainfuck beware: JavaScript is after you (2012)
#32Earlier quoted context omitted.
once the eval() invocation is complete and the code generated/compiled the performance should be the same as the code normally written. Basically it's only compiler from []{}!+ to javascript.
However, your js files would get really big, and download latency could actually be a performance drop.
True, however they should be very well compressible by 'deflate' too, the main concern is the initial parsing grok by the JIT.
Yet, on runtime the scripts will be good as any.
Re: Brainfuck beware: JavaScript is after you (2012)
#33I've seen this before here: http://www.jsfuck.com/.
It's nice that this guy actually explains how it works
Re: Brainfuck beware: JavaScript is after you (2012)
#34I'm curious on what the performance implications are. If I have some JavaScript on a webpage that I want to "obfuscate", would using this accomplish the task?
The performance seriously decreases. I haven't measure how much, but I guess it'd only work for very very small scripts.
Re: Brainfuck beware: JavaScript is after you (2012)
#35Yet another example of the horrible mess unprincipled automatic type conversion causes. What prevents language designers from avoiding all these lurking bugs with a generic type-conversion operator? E.g. here's how it might look in a Python-like language: >>> x = 1 >>> y = "2" >>> print(x + cast(y)) 3 >>> print(cast(x) + y) "12" >>> print(cast(x) + cast(y)) Exception: ambiguous type
Idris has a type class that is pretty much this: https://github.com/idris-lang/Idris-dev/blob/master/libs/pre...
Here's an example interaction. There's a difference, though, since + is only for {Num instance,Fin} addition while ++ is {String,List,Vect} concatenation.
Re: Brainfuck beware: JavaScript is after you (2012)
#36Earlier quoted context omitted.
Why is this preferable to a set of functions that return a particular type? Most uses of such a cast function would be something like cast(unknown_type) known_type The programmer could just write tostring or tonumber instead of cast, if the type of the other operand is known >_>
Automatic type casting remains popular because it reduces the syntactic and cognitive overhead. I'm suggesting that a better solution would be to retain explicit casting, but minimise the overheads. So, to take things a step further, lets use, say, the $ operator for casting. Then we have: >>> x = 1 >>> y = "2" >>> print($x + y) 3 >>> print(x + $y) "12" >>> print($x + $y) CastError: ... What do you think?
The proper way to do this is using something like TryParse() and ToString() and to handle the case of failing to parse the string as a number and maybe even specifying the locale for both operations. If you are absolutely sure that parsing can not fail you can use Parse() and omit the error handling.
Re: Brainfuck beware: JavaScript is after you (2012)
#37I once did something similar in PHP.[1] View the semi-useful writeup[2] as well.
[1]: https://gist.githubusercontent.com/nubs/5849633/raw/78bae58f...
Re: Brainfuck beware: JavaScript is after you (2012)
#38Yet another example of the horrible mess unprincipled automatic type conversion causes. What prevents language designers from avoiding all these lurking bugs with a generic type-conversion operator? E.g. here's how it might look in a Python-like language: >>> x = 1 >>> y = "2" >>> print(x + cast(y)) 3 >>> print(cast(x) + y) "12" >>> print(cast(x) + cast(y)) Exception: ambiguous type
you can already do exactly that in Python with a bit of evil magic:
$ cat evil.py
class cast(object):
def __init__(self, x):
if isinstance(x, cast):
self.x = x.x
else:
self.x = x
def __add__(self, other):
return other.__class__(self.x) + other
def __radd__(self, other):
return other + other.__class__(self.x)
$ python3 -i evil.py
>>> a = 1
>>> b = "2"
>>> a + b
Traceback (most recent call last):
File "", line 1, in
TypeError: unsupported operand type(s) for +: 'int' and 'str'
>>> cast(a) + b
'12'
>>> a + cast(b)
3
>>> cast(a) + cast(b)
Traceback (most recent call last):
File "", line 1, in
File "evil.py", line 9, in __add__
return other.__class__(self.x) + other
File "evil.py", line 9, in __add__
... repeated many times ...
File "evil.py", line 9, in __add__
return other.__class__(self.x) + other
RuntimeError: maximum recursion depth exceededRe: Brainfuck beware: JavaScript is after you (2012)
#39Yet another example of the horrible mess unprincipled automatic type conversion causes. What prevents language designers from avoiding all these lurking bugs with a generic type-conversion operator? E.g. here's how it might look in a Python-like language: >>> x = 1 >>> y = "2" >>> print(x + cast(y)) 3 >>> print(cast(x) + y) "12" >>> print(cast(x) + cast(y)) Exception: ambiguous type
you can already do exactly that in Python with a bit of evil magic: $ cat evil.py class cast(object): def __init__(self, x): if isinstance(x, cast): self.x = x.x else: self.x = x def __add__(self, other): return other.__class__(self.x) + other def __radd__(self, other): return other + other.__class__(self.x) $ python3 -i evil.py >>> a = 1 >>> b = "2" >>> a + b Traceback (most recent call last): File " ", line 1, in T…
That's awesome. Have a unicode trophy (🏆) as a prize:
🏆