我们自己的工作中会涉及到浏览器端的通信数据加密,但一般普通混淆太容易被黑盒或白盒利用了,后来我们使用 Webassembly 以及 asmjs 加密,但频繁用 C++写相对应的逻辑太麻烦,因此我们在工作中沉淀了 SecurityWorker。简单的说,SecurityWorker 是个可靠的类 WebWorker 环境,他有独立的 VM,兼容 ECMAScript5.1,如此一来既方便你写又有足够的保护强度。
官网: https://www.securitify.io
文档: https://github.com/qiaozi-tech/SecurityWorker
1
zsx 2019-03-27 23:08:01 +08:00
看了一下代码,大概是你们自己写了一个跑 OPCode 的 Runtime,然后用 Emscripten 把这个 Runtime 编译成 asm.js ?这么玩了性能居然还只降低这么一点。。。
|
3
zsx 2019-03-27 23:31:53 +08:00
@zyEros #2 不是啥高手哈。。我最近在做一个 PHP 的加密,在性能和安全上摇摆不定。看了一下你的文档,还是挺惊讶于你的性能降低居然只有这么一点的……
|
4
alvin666 2019-03-27 23:35:27 +08:00 via Android
关注一下,js 的加密 /混淆一直是个难题
|
6
yixiang 2019-03-27 23:38:55 +08:00
security by obscurity? hmmmmmm
|
7
kimown 2019-03-27 23:38:58 +08:00 via Android
我们有个策略,wasm 混合 js,然后合并其他库,最终输出 wasm 文件接近 10M,不知道这样有没有方法能解析出源码
|
9
zyEros OP @kimown 你们 js 最终会被 eval 执行,那么就存在风险。SecurityWorker 是独立的 vm,代码会被编译为 opcode bytes 然后混编,不存在 eval 之类的动态执行。但目前跟 WebWorker 一样,没有 DOM/BOM,需要两个环境通信
|
12
kimown 2019-03-28 00:10:58 +08:00 via Android
@zyEros
有个疑问,run script 最前面覆盖各种 console,alert 之类的函数,判断 eval 是否为 native,否就不执行,保证整个执行都在 VMXXX 内,这样还有办法可以破解吗 https://stackoverflow.com/questions/6598945/detect-if-function-is-native-to-browser |
13
zyEros OP @kimown 不行,因为我可以拿到你的代码,然后改文件输入 debug,你可能会因为代码太大导致 devtool 崩溃,但我们还有其他办法,比如通过 chrome 的协议远程调试然后跟踪到你 eval 逻辑前,或者直接在你 eval 前 ajax 发送代码,file api 操作等。这些弯路我们都走过。
|
14
zyEros OP @kimown 浏览器整个都是不安全环境,只要你的代码以原始代码动态执行在不安全环境,他就是不安全的
|
16
zyEros OP @polythene “ SecurityWorker 不同于普通的 Javascript 代码混淆,我们使用 独立 Javascript VM + 二进制混淆 opcode 核心执行 的方式防止您的代码被开发者工具调试、代码反向。”以及“ SecurityWorker VM 与 V8 等强调性能的 Javascript 引擎不同,SecurityWorker VM 主要目标是更小的 emscripten 生成体积以及更少的内存使用。对于 SecurityWorker VM 来说,我们并没有集成类似 V8 一样的 JIT 机制,而是使用通过离线翻译你的 Javascript 代码为 SecurityWorker VM 指令,然后在运行时解释执行的方式,因此在性能上会有一定的损失。”
|
17
kimown 2019-03-28 00:25:55 +08:00 via Android
@zyEros
是的,当时我也考虑过,最后不行重编译 chromium,简单覆盖下 eval,原来方案就失效了, https://github.com/mbbill/JSC.js 有考虑过 js 内嵌 jsc 吗,感觉这也是个思路,楼主有邮箱吗,以后可以交流下 |
19
tyrealgray 2019-03-28 00:30:46 +08:00
其实加密可以考虑 google 的方案,用 https://github.com/javascript-obfuscator/javascript-obfuscator
基本上锁 domain 和禁用 console 后,解密的可能性就很低了 |
20
zyEros OP @tyrealgray 并不是,ob 实际上是混淆,但仍然可以通过代码逆出核心算法,相比 SecurityWorker 的强度来说低很多很多
|
21
tyrealgray 2019-03-28 00:36:32 +08:00
啊,记错了,google 的方案是 Closure Compiler,javascript-obfuscator 是另外一个
|
22
hanguofu 2019-03-28 02:35:29 +08:00 via Android
这个工具太好了,解决了 js 的加密的大难题!
|
23
binux 2019-03-28 03:39:58 +08:00 via Android
之前暴力破解过一个 fingerprint 的 js 的 VM 加密,直接断下 assign 的 op,修改中间步骤返回值就好了。
你逻辑是加密了,但是终究是要在内存的某个部分拼出完整的请求提交数据的。 |
24
zyEros OP @binux 里面不存在 js 源码了,只会有离线翻译的 opcode bytes,opcode bytes 会做第二次加密
|
25
zyEros OP @binux
1.上传代码 2.JS 翻译为 opcode bytes 3.二进制数据加密并重打包 4.核心压缩加壳 5.得到最终文件 运行时解密得到 opcode bytes,然后 vm 执行,除非你知道我的 opcode 设计,否则很难继续 debug |
26
zyEros OP @binux 哦,我懂你意思了,但是那样如何被大规模利用是个问题,我们还有一些环境监测,防止 node 运行,如果有时间可以试着破一破帮助我们改进(逃
|
28
binux 2019-03-28 05:15:04 +08:00
@zyEros #26 确实没法大规模利用,那时候只是要破解一个网站的 fingerprint,而且我是在 electron 中运行的。
|
29
zyEros OP @binux SecurityWorker 只是保证代码安全,但是其他安全流程是需要使用者去设计的,包括数据的签名检验防止重放,检验 key 唯一下发等等,防止被大规模使用,这不是 SecurityWorker 要解决的问题
|
30
Mutoo 2019-03-28 06:23:27 +08:00
最大的风险难道不是“上传文件”到第三方服务,再编译成加密脚本吗。
|
31
zyEros OP @Mutoo 如果整体开源了就没有安全性可言了,流程和 opcode 设计都能看到,如果上传不信任当然也没办法了
|
32
qdwang 2019-03-28 08:09:44 +08:00 via iPhone
@zyEros 可以考虑增加一个 opcode shuffle 的功能。让此功能生成一个随机又特定的 opcode encoder 和 decoder。这样每个用户的 opcode 都不一样,并且不透明的,破解者没那么容易反编译。
但是上面人所说的也对,其实本质上还是可以破解的,只是需要花一些时间。 这类库我也做过,不过不是拿来干代码加密的事情 |
34
zyEros OP @qdwang opcode bytes 我们是会进行二进制混淆的,并且会对 bytes 进行二次加密,每次加密的 key 是随机的,你说的 shuffle 是在二进制混淆的阶段做么
|
35
qdwang 2019-03-28 08:49:20 +08:00 via iPhone
|
36
zyEros OP @qdwang 在 vm 内部通过一些算法取出,所以你有可能能获取到,但是即使取到意义也不大,源码已经变成 opcode,因为你没有 opcode 的设计以及一个供其运行的 runtime
|
38
lamada 2019-03-28 13:27:06 +08:00
mark 了,有点意思
|
39
luvxy 2019-03-28 14:24:31 +08:00
在哪学这些安全方面的知识
|
41
weloveayaka 2019-04-09 16:51:31 +08:00
请问未来会出离线版本吗,会收费吗?
有没有粉丝 QQ 群之类的? |
42
zyEros OP @weloveayaka 离线版本 /收费 /定制化可以问我们的客服,vx:suyanqiong1986
|