前端能像移动端一样被反编译吗？求大佬解答

[v2410117]

我是做移动端的，最近在学习安全方面的东西，发现不管是 iOS、安卓，都有被反编译的风险，无论我使用 AES、RSA、MD5 怎么翻来覆去的让数据在传输过程中密文化，通过反编译都能够分析出加密流程，自己在网上搜索了一下前端，有人说前端等于裸奔，加密没意义，我自己用 vue 随便写了个页面做测试，当打包发布后，在控制台里我确实能看到加密后的密文传输数据，但是好像没找到可以看加密流程的 js，好像是被 webpack 压缩还是怎么了，我想知道前端有办法像移动端那样被反编译查看出我的加密流程吗？对前端不太懂，希望大佬帮忙解答一下。谢谢。

[HuasLeung]

前端代码都是暴露的，加密意义不大。js 可以压缩混淆，但是也有很多格式化的工具。请求后端加密接口更安全。

[LLaMA2]

F12 打开控制台，找到指定的 html 元素，右键 Break On. 就是下个断点啦，一点点的定位到他最后到底调用了哪个 JS，再断点再 DEBUG，你懂我意思把

[hugee]

甚至不用反编译

[LLaMA2]

加密的意义是在于不让第三方知道二者之间的通信内容，如果坏人直接用的 APP 或者网页攻击，那他根本就不是第三方，而是通信之间的两点的其中一点，这是没法防止的。
推荐你把你的问题补充一下，说下你具体要防止什么操作，例如别人攻破你的访问鉴权然后爬虫，又或者他伪造金额发送请求买东西之类的。这样大家伙有更好的讨论方向。

[seeker]

通常不说叫编译。从一个语言到另一个语言称为编译。

[abcbuzhiming]

都一样，核心关键在于你的产品能被对方直接拿到手进行调试。那么被破解只是一个成本问题，服务器为什么相对安全就是因为一般无法被直接调试。一旦能直接调试程序，那程序被破解只是时间和成本的问题

[jydeng]

前端代码完全属于你，只是被压缩混淆了。

[duan602728596]

其实 js 代码先算是先编译，然后混淆，通过美化格式，拿到的变量也是 abcdefg 这样，而且我还发现，用 chrome 或者 Firefox 断点调试 webpack 打包的文件的时候，会造成开发者工具栏卡死的情况

[guyeu]

拿到加密流程并不代表可以破解你的加密。。。无论如何，只要有编译产物，就可以反编译，加密混淆加壳这些操作只是在增加反编译的成本（加密也只是增加破解的成本）。

当反编译或者破解的成本大于破解你的系统带来的收益时，就够了。

[youngluo]

前端和原生开发不一样，不存在你想的编译问题，最多就是压缩混淆罢了，这种操作都是为了减小体积而已

[kimown]

我们解决反调试的方法很简单，就是加体积，开发者工具直接假死

[maplerecall]

前端加密的意义只是为了防止被轻易窃取数据而已，本质上只是障眼法，只要有心想反编译，难度元比原生 app 小得多，说裸奔并不算特别不对。

至于增加体积多重混淆之类的，讲道理在一般场景下属于歪门邪道，因为这会同时影响浏览器正常解析的性能，大多数场景下并不值得。而且要反编译并不一定要浏览器，卡死 devtools 之类的也可以通过提高硬件轻易解决。

[broadliyn]

前端无法保证 100%的安全，你能做的，也只有提高破解 /反编译成本。
简单点，代码混淆。
复杂点，核心加密模块用 c/c++。
再复杂点，服务端一起配合加入风控模型。
但是不管怎么搞，对于服务端来说，数据逻辑的正确性要由服务端校验，以要保证业务的正确性。

[wolfie]

代码写恶心点就行。
加体积 +1。

[emeab]

前端不能保证 100%的安全 只要服务不是跑在你自己的机器上就不能保证用户怎么做 So 服务端再做下校验

[loginbygoogle]

前端需要反编译吗

[gzxu]

关键部分用 WebAssembly 处理一下，基本上很难反编译

[gzxu]

据说 Google 的验证码服务 reCAPTCHA 是用 JS 实现了一个 bytecode 虚拟机，然后在虚拟机里面跑逻辑

[weixiangzhe]

变量改成 abc 而已，es6 babel 编译为 es5，想要看是用看懂的，写的恶心也木用。

[fenghuang]

@gzxu #18 reCAPTCHA 是真的狠