How to encrypt javascript source code in .ipa and .apk

[Zhe Wang]

Hi all,

Is there any mature approach to encrypt javascript code based on JSB, which are packed as assets in .ipa and .apk?

Any ideas?

Bests,

Zhe

[Ricardo Quesada]

I think there are 2 possibilities:

a)

Encrypt the .js files.

And CCFileutils decrypts them in memory and executes the scripts from memory.

b)

obfuscate the .js files (actually minified them).

I think option b) is safer. Since a guy with a jailbroken iOS (or Android device) + some basic debugging knowledge can easily decyrpt the .js files.

I would vote for b.

--
You received this message because you are subscribed to the Google Groups "cocos2d JS development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cocos2d-js-dev...@googlegroups.com.
To post to this group, send email to cocos2d-...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Shun Lin]

For b):

 

It is possible to obfuscate all game  files and Cocos2d-html5 engine files into a minified file.

However, it is hard to obfuscate them in JSB mode. 

If we want, we should obfuscate JSB generated files firstly, and then output a checklist.

Game files should be obfuscated by the checklist.

I don't know it is possible or not for Closure Compiler.

[Ricardo Quesada]

Apparently it is possible tell Google Closure not to minify "extern" code:

https://developers.google.com/closure/compiler/docs/api-tutorial3#externs

So, JSB should generate a file called externs.js with all the cc / cp / gl bound classes / functions.

[Hao Wu]

---------- Forwarded message ----------
From: Hao Wu <wu...@cocos2d-x.org>
Date: Tue, Mar 12, 2013 at 2:23 PM
Subject: Re: [cocos2d-js-devel] How to encrypt javascript source code in .ipa and .apk
To: Ricardo Quesada <ricardo...@gmail.com>

is it possible to get the result from the jit?

if so, we only have to store the intermediate code only, that would be much secure than storing js file in theory?

[Shun Lin]

In my opinion, it is not just externs.js.

Closure Compiler would "skip" to rename all items which listed in externs.js when you pass  externs.js as parameter.

As the result, there are a  lot of cc.Sprite.create or cc.Actionxxx.create, etc. in minified file. 

It is not safe enough.

However, if all cc / cp / gl bound classes / functions are rename to other names, includes JSB registered files for SpiderMonkey,  it would be better.

There are not any "cc" in the minified file.

Such as：

It also need to be obfuscated.

So, what we need it is a converted table or checklist, which tells Closure Compiler to convert the name to corresponding name.

[Zhe Wang]

So:

1. Can we have a demo that how to obfuscate JSB codes before GDC and Devcon Beijing?

2. Another topic, is there any chance that we can compile to javascript bytecode on development environment, like lua, then distribute the javascript bytecode in .ipa & .apk. This would be much safer than obfuscation. 

For example, google v8 has two major phases to run js source, (well, v8 is using JIT)

js_compiled = Script::Compile(js_source);

js_compiled->Run()

And SpiderMonkey also has 2 phases:

JSScript* script = JS::Compile(..., js_source);

JS_ExecuteScript(JSContext*, JSObject, script, jsval)

I'm not sure if JSScript* is the very object that contents the bytecode. If do, can we serialise JSContext *cx, JSObject global, and JSScript to storage, pack them into apps,  then recover the context, run the bytecode in runtime? 

[Ricardo Quesada]

marshalling / unmarshalling the JSScript sounds like a good idea... at least in theory. Not only it will help for obfuscation, but also for loading speed.

In practice I don't know how complex is that. Any idea ?