nxbdi / jsunpack-n

Automatically exported from code.google.com/p/jsunpack-n

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Evaluate the use of an alternate JS engine for higher throughput

GoogleCodeExporter opened this issue · comments

A faster JS engine like f.e. V8 would significantly speedup the deobfuscation 
process, and given the small patch to SpiderMonkey, patching v8 should be very 
easy?! There are lots of tests out there that show the huge performance 
increase of the latest free software engines. A google search for JaegerMonkey 
vs V8 or similar will provide insight into the topic.

Original issue reported on code.google.com by ali.iki...@gmail.com on 1 Jun 2011 at 5:47

After patching I think changing line 301 from 

po = subprocess.Popen(['js', '-f', self.OPTIONS.pre, '-f', 
current_filename+'.js', '-f', self.OPTIONS.post], shell=False, stdout = 
js_stdout, stderr = js_stderr)

to 

po = subprocess.Popen(['d8', ' ', self.OPTIONS.pre, ' ', 
current_filename+'.js', ' ', self.OPTIONS.post], shell=False, stdout = 
js_stdout, stderr = js_stderr)

should do the job for v8. Shouldn't it?

Original comment by ali.iki...@gmail.com on 1 Jun 2011 at 7:29

This is a good idea and I've tested it myself to confirm it is effective. Even 
further speedup can be achieved by using the code as a library instead of 
launching a new process each time (effectively fork and exec copies the entire 
process memory).

I'd recommend that If you do make this engine change to make sure that you are 
still hooking the eval function. By default there are locations to do this in 
the existing code in the patch to spidermonkey (default on), and pre.js hooking 
(default off). If you decide to move away from spidermonkey, then just enable 
the pre.js eval hooking instead.

Original comment by urul...@gmail.com on 1 Jun 2011 at 5:47