Many thanks for the ideas guys. We want this to be a generic solution, not one particular js tied up within a custom binary. The idea is to have the source files present on disk as encrypted files. This allows us to easily roll out new patches, add functionality by adding new files, etc. Having a separate executable for each independent bit of javascript would become unmaintainable very quickly.
________________________________ From: Mike Schwartz <myk...@gmail.com> Sent: Monday, 27 June 2016 10:23 PM To: v8-users Cc: beethovian.symph...@outlook.com Subject: Re: [v8-users] Re: Protecting IP It doesn't seem that hard to hack node to do this. You use something like nasm and include your packaged .js program. Then hack node to load and optionally decrypt your program and eval() it. Nasm generates a .o file you link your custom node with. Seems like a couple of hours' work. You would have to patch any newer versions of node as you want to upgrade. I'd be sure to run the unit tests for node itself before deploying. On Mon, Jun 27, 2016 at 2:49 PM Zephyr Pellerin <zephyr.pelle...@gmail.com<mailto:zephyr.pelle...@gmail.com>> wrote: This is actually a fairly common requirement that I've had the "pleasure" of dealing with for a host of people and firms. Unfortunately, it's also very easy to mess up without a lot of care. I have a longtime interest in reverse engineering so I may have a different standard of "trivial disassembly" but here are some guidelines to start out with if you just want to prevent easy recovery of the original source code. 1. Obfuscators typically don't. There are tons of tools out there that 'obfuscate' JavaScript source and equally many tools that deobfuscate everything short of variable names. If you go down this path, minification alone may be your best bet. Just remember, this sort of protection can be unmade by individuals without any programming experience. 2. It's best to know what you are doing if you are serious. I've seen others try the "strip v8 down until you've just got bytecode" route. It can be a solid approach depending on your familiarity with V8 and IDA Pro -- I've also seen it turn into a company-ending-waste-of-time. Here's one way a team tried to do it that I wouldn't recommend. Emit raw bytecode and process at dbrk -- someone can also just emit the source of each function. So you patch code->kind to OPTIMIZED_FUNCTION -- The source is still available in full in any hex editor in the global offset table (ELF executable here). So you strip the some ordinal set from global offset table post hoc -- program breaks (they ended up calling a consultant) 3. The host of alternative JS transpilers and compilers are generally more inscrutable but that effect is gained through obscurity. High level information about the program's source and structure are still preserved. Best of luck, - zv On Tuesday, June 14, 2016 at 6:33:35 AM UTC-7, Joe Bloggs wrote: Hi, My employer is looking to shift major development to node.js. Now, before you point out that this is the v8 mailing list, rest assured this message is pertinent to this list. My employer wants to protect their IP and not have it available as simple text files. We understand that a binary compilation is still hackable, that anything that executes on a remote machine can be reverse engineered, but we just want it to be non-trivial - no one should be able to merely open a text file and read the source code. I want to soundboard my current (extremely rudimentary) thoughts against you guys. The idea is to create a custom compilation of node and the v8 engine, where the v8 engine has been modified in the following manner (very high level, lots of details need to be filled in): 1. v8 exposes a function 'ExecuteEncryptedString' which internally decrypts the string and passes on execution to already available functions. 2. There shall be no way for the 'require' syntax to load an encrypted file. 3. Any attempt to use console.log to dump the encrypt string merely dumps the encrypted string. 4. The overall outcome we are looking for is anyone can execute the code if they have the custom executable, but they can't decrypt it trivially. They will need to disassemble the executable. 5. We want this approach to be forward compatible. That's where we will need guidance from you guys on how to ensure that, to the extent reasonably possible, in the future we will be able to simply download the code for a new version of v8, and run a simple script to add the custom parts and create the custom executable. Of course, in the face of innovation for better performance etc. this might break, and that is understandable. We also understand we may need a separate discussion with the node.js guys. I would like to hear your thoughts on this. If you have better ideas on achieving this, if you see obvious loopholes in the approach, or you just want to share your thoughts, please feel free to provide constructive feedback. Regards, Simon -- -- v8-users mailing list v8-users@googlegroups.com<mailto:v8-users@googlegroups.com> http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com<mailto:v8-users+unsubscr...@googlegroups.com>. For more options, visit https://groups.google.com/d/optout. -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
