151–160 of 168 posts
Earlier quoted context omitted.
Flexible !== awful
JavaScript can certainly be awesome, but the tricks that JSFuck relies on aren't "flexible". They're things that make you say "Wat?" https://www.destroyallsoftware.com/talks/wat
Earlier quoted context omitted.
JScrambler I actually did de-obfuscate to bypass some very significant bot detection a few years ago, but it took a bit more doing -- it uses ES6 features IIRC so I had to transpile it down to ES5 via babel first, but it worked OK after that. has a pretty good crack at obfuscator.io, too: https://closure-compiler.appspot.com/home#code%3D%252F%252F%... That's the example from the site. "console.log('Hello world')" get…
> That's the example from the site. "console.log('Hello world')" gets deobfuscated to "console[a(482)]("Hello World!");" That does not look deobfuscated to me.
And, even if you don't, you can always call a(482)
Earlier quoted context omitted.
> That's the example from the site. "console.log('Hello world')" gets deobfuscated to "console[a(482)]("Hello World!");" That does not look deobfuscated to me.
Anyone familiar with JS is going to have some really good guesses at what a(482) is in this case. And, even if you don't, you can always call a(482)
Earlier quoted context omitted.
I think someone once asked me the simplified variant of that question. What is the result of: []+[] And I didn’t know the answer to that (I mean, who does that kind of fuckery in Javascript, you can’t sum arrays). I would have no chance with these Google level questions.
That's an idiotic interview question. I've experienced this at young companies where both the company and its engineers are too immature to understand basic etiquette in the industry. Btw I doubt Google would ask a stupid "gotcha" question like that. They tend to ask hard algorithmic questions.
Earlier quoted context omitted.
Sure, but in the wild, you would actually run the thing in the repl to see what it does. So either you know the answer or you don't and it doesn't affect whether or not you can do the job well. In my opinion binary knowledge-based questions are seldom useful unless you specifically are checking for that exact knowledge. You can have someone who is totally terrible in general but just knows that one thing or the answe…
My reply was less about whether or not it's a good interview question and more about the comments people are making in this thread that the question is completely invalid because only a "fool" would write code like that. In practice, unless you have some extremely pedantic, end to end testing, your first hint that something is going wrong is probably going to be malformed output. TypeScript won't catch this error bec…
If you ask about how to uppercase a string, certain constructs like []+[], or whether camelCase or PascalCase is superior you will get the people who know the answers to those questions.
Earlier quoted context omitted.
That's an idiotic interview question. I've experienced this at young companies where both the company and its engineers are too immature to understand basic etiquette in the industry. Btw I doubt Google would ask a stupid "gotcha" question like that. They tend to ask hard algorithmic questions.
> I doubt Google would ask a stupid "gotcha" question like that. You're kidding, right?
Earlier quoted context omitted.
While I think itcs bad to use obfuscation to hide security holes, I do think obfuscation has it's uses. If there's reasons to make data private, then there's reasons to make execution private as well. Not to mention, it was recently proved that indistinguishable obfuscation is possible, so I'm not sure how useful de-obfuscation tools will be in the future
But you don't make data private by obfuscating it and then passing it to people you don't trust. You make data private by not giving it to people you don't trust, or by encrypting it and not giving the key to people you don't trust.
Earlier quoted context omitted.
Flexible !== awful
I noticed that you had to use !== instead of != because the comparison operators in JavaScript are awful :D
Though I'd still argue that the presence of both `==`/`!=` and `===`/`!==` is somewhat more indicative of flexibility than awfulness.
Earlier quoted context omitted.
I think closure compiler's 'obfuscation' is an incidental part of its minification passes.
Got it. Thank you. I've been using the Google Closure compiler for many years with advanced and every time I look at the code output I'm like "there's no way in a 100 years I would be able to de-obfuscate back to my own code to a great extent". But I don't specialize in reverse engineering, so I might be missing something big.