5 ms·

So what's going on here? I have been trying to follow along but I'm confused why anything happens. There's a test button that calls ThreadProc_dbg(bug) which

So what's going on here? I have been trying to follow along but I'm confused why anything happens. There's a test button that calls ThreadProc_dbg(bug) which then calls test(result), which in turns has some assembler code commented out and finishes with: unescape('%u31C9%u5589%uE55D%u2EF8%uC390%u9090'); return 0; The variable 'result' is (visibly) untouched by the function but ThreadProc_dbg tests its value to see if the processor is vulnerable or not. So just the test() function has the good stuff. (assuming it works) So either the assembler code does something even though it's commented out, or the unescape is not happy but I'm not sure why… I haven't tried too much on the code that actually crashing the computer (or whatever it does) since just the test puzzles me.

ricardobeat 14y ago
> The variable 'result' is (visibly) untouched Actually it is invisibily touched by that call to unescape(). The assembly code in the comments is what is generated by the interpreter, and that's where the trick happens.
- olliej 14y ago
  No. The interpreter doesn't generate that. They have taken the assembly, placed it in a string, and then done nothing more. There is no obvious attempt to actually get the JS engine to do anything out of the ordinary. The string '%u31C9%u5589%uE55D%u2EF8%uC390%u9090' is simply the unicode escaped version of the assembly above. The goal of this exploit would be to get the interpreter to set PC to the address of that string. There is no obvious attempt to do that. Just compare the decoded opcodes in the DISASM comment to the contents of the string.
  - alcuadrado 14y ago
    I noticed the same, but then figured out that the PoC is incomplete like the engine function. I assume that's on purpose. I look forward this gets the attention of security experts to know if this is real or not.
    - duskwuff 14y ago
      There's "incomplete", and then there's "broken", and then there's this code. It's not even broken; "broken" would imply that it could be fixed. There's simply nothing there. See my analysis: http://news.ycombinator.com/item?id=4246338 http://news.ycombinator.com/item?id=4246338
  - deleted 14y ago
    [deleted]

ricardobeat 14y ago

> The variable 'result' is (visibly) untouched Actually it is invisibily touched by that call to unescape(). The assembly code in the comments is what is generated by the interpreter, and that's where the trick happens.

olliej 14y ago
No. The interpreter doesn't generate that. They have taken the assembly, placed it in a string, and then done nothing more. There is no obvious attempt to actually get the JS engine to do anything out of the ordinary. The string '%u31C9%u5589%uE55D%u2EF8%uC390%u9090' is simply the unicode escaped version of the assembly above. The goal of this exploit would be to get the interpreter to set PC to the address of that string. There is no obvious attempt to do that. Just compare the decoded opcodes in the DISASM comment to the contents of the string.
- alcuadrado 14y ago
  I noticed the same, but then figured out that the PoC is incomplete like the engine function. I assume that's on purpose. I look forward this gets the attention of security experts to know if this is real or not.
  - duskwuff 14y ago
    There's "incomplete", and then there's "broken", and then there's this code. It's not even broken; "broken" would imply that it could be fixed. There's simply nothing there. See my analysis: http://news.ycombinator.com/item?id=4246338 http://news.ycombinator.com/item?id=4246338
- deleted 14y ago
  [deleted]