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> 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 > 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. > -- -- 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.
