Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSFuck (2012)

jsfuck.com

Post reply on HN
Print view View original

131–140 of 168 posts

Re: JSFuck (2012)

#131

Post by dorgo »

colordrops wrote: post #103
idolaspecus wrote: post #74

Earlier quoted context omitted.

This is in my opinion actually a decent interview question. If you know JS in detail, if you know how the "+" operator works, it's a super easy question. If you don't know JS in detail, if you don't know how the "+" operator works, it's pretty tough. If you want an engineer who knows JS in detail, asking this question can be valuable.

"+" isn't some singular operator. They are different operators for different types using the same character. You'd have to memorize a table of all JS types and what "+" does for each, which is silly considering that the only place it should really be used in modern JS is arithmetic and the occasional string concatenation.

afaik these two places ( arithmetic and string concatenation ) are the only ones where + operation is defined. JS picks one of these two operations and casts the operands accordingly.

Edit: Wait, there is also the unary + which takes only one argument, but it also could be considered arithmetic.

Re: JSFuck (2012)

#132

Post by uryga »

int0x2e wrote: post #122
classichasclass wrote: post #50

Earlier quoted context omitted.

I understand the frustration, but as someone having to debug browser bugs with JavaScript edge cases, minified (and in this case ultra-obfuscated) JS is hell on earth to untangle and I wish people wouldn't.

Just making sure - you're using js source maps, right? The minifaction should be adding significant pain in your debugging process.

IME, code on prod rarely ships with a sourcemap. and as far as i can tell, GP is talking about other people's minified code, not something where they control the build process

Re: JSFuck (2012)

#133

Post by robocat »

int0x2e wrote: post #122
classichasclass wrote: post #50

Earlier quoted context omitted.

I understand the frustration, but as someone having to debug browser bugs with JavaScript edge cases, minified (and in this case ultra-obfuscated) JS is hell on earth to untangle and I wish people wouldn't.

Just making sure - you're using js source maps, right? The minifaction should be adding significant pain in your debugging process.

Source maps are used for anti-debugging: https://www.perimeterx.com/tech-blog/2019/javascript-anti-de...

Re: JSFuck (2012)

#135

Post by richardfey »

ollyfg wrote: post #19

I probably deserve to get downvoted to oblivion for this but... I've deployed JSFuck in production! We wanted to obfuscate this bit of code, to make life just a little bit harder for reverse engineers. We made this huge function where we pretty much passed in all our application state, and it would run this JSFuck code, and spit out a token. We even made a few tweaks to the code so that you couldn't just reverse it b…

Talk about security by obscurity!

Re: JSFuck (2012)

#136

Post by richardfey »

userbinator wrote: post #96
ollyfg wrote: post #19

I probably deserve to get downvoted to oblivion for this but... I've deployed JSFuck in production! We wanted to obfuscate this bit of code, to make life just a little bit harder for reverse engineers. We made this huge function where we pretty much passed in all our application state, and it would run this JSFuck code, and spit out a token. We even made a few tweaks to the code so that you couldn't just reverse it b…

I think I might've actually analysed the code you're describing. We even made a few tweaks to the code so that you couldn't just reverse it back into JS This is why a lot of us keep our tools private... an old tradition of the cracking scene going back decades to the 80s. Think of things like IDA/Hexrays and Ghidra, then realise the most prolific crackers had similar private tools they had written many years before t…

But once better tools have been published, why not show what you did?

Re: JSFuck (2012)

#137

Post by jstanley »

woojoo666 wrote: post #128
zemnmez wrote: post #45

Earlier quoted context omitted.

makes me sad to hear that :( I will say, as a reverse engineer, that javascript minifiers like closure compiler will optimize almost all obfuscation out, and the rest you can usually translate to a form which it can understand and then it will do the rest. The effect of obfuscation is not what you expect. It seems like it moves the whole difficulty up, but it only moves up the floor. By doing so it tends to remove al…

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.

Re: JSFuck (2012)

#138

Post by laumars »

tonyedgecombe wrote: post #102
userbinator wrote: post #96

Earlier quoted context omitted.

I think I might've actually analysed the code you're describing. We even made a few tweaks to the code so that you couldn't just reverse it back into JS This is why a lot of us keep our tools private... an old tradition of the cracking scene going back decades to the 80s. Think of things like IDA/Hexrays and Ghidra, then realise the most prolific crackers had similar private tools they had written many years before t…

>This is why a lot of us keep our tools private How ironic, that you want to open up other peoples code but keep your own hidden.

Different motives. Think of it like encryption: when someone finds a weakness in a cypher people will generally move onto a new cypher that’s harder to crack. The difference here is the purpose of writing those tools isn’t to improve security, it’s to break code open. So keeping these tools hidden keeps them effective.

Re: JSFuck (2012)

#139

Post by 0xFF0123 »

zemnmez wrote: post #45
ollyfg wrote: post #19

I probably deserve to get downvoted to oblivion for this but... I've deployed JSFuck in production! We wanted to obfuscate this bit of code, to make life just a little bit harder for reverse engineers. We made this huge function where we pretty much passed in all our application state, and it would run this JSFuck code, and spit out a token. We even made a few tweaks to the code so that you couldn't just reverse it b…

makes me sad to hear that :( I will say, as a reverse engineer, that javascript minifiers like closure compiler will optimize almost all obfuscation out, and the rest you can usually translate to a form which it can understand and then it will do the rest. The effect of obfuscation is not what you expect. It seems like it moves the whole difficulty up, but it only moves up the floor. By doing so it tends to remove al…

Really enjoyed that blog post, thanks for linking it! How long would you say actually finding those two issues took? The attack surface must've been fairly large, but I guess intuition helps.

Re: JSFuck (2012)

#140

Post by 10x-dev »

seanp2k2 wrote: post #64
shrimpx wrote: post #48

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.

FWIW I’ve had Google recruiters ask me stuff where they don’t understand the answer and the questions are things like “what is the protocol number for ICMP” and “what port does NTP use”. If one doesn’t work with these things very often, they’re very forgettable as they’re so easy to google and find the correct answer to in seconds, and therefore not worth memorizing. No idea if they’re still doing this, but it was li…

I went through the swe generalist interview pipeline 3 times at Google, so that's about 15 interviews. All the questions have been standard , except this one dumb question, which was along the lines of "explain how multithreading works". I suppose he wanted me to follow up with some questions to narrow down the topic, but I was stressed out enough that I just started with the basics, like cores, processes, OS threads, and shared memory, trying to explain it in simple terms. He interrupted me about 5 minutes in and moved on.

Having interviewed people myself, I think that's an overly broad question to ask in an interview and if the candidate starts answering it as asked, then you're not going to get a lot of signal from it.

Otherwise I thought the problems asked weren't that difficult, one was even directly taken from Cracking the Coding Interview - if only I had read that chapter ahead of the interview...

Post reply on HN