客户端防破解

一、Wails 的架构决定了其逆向面#

Wails = Go 后端 + Web 前端（HTML/JS/CSS）

层面	逆向难度	说明
前端资源	⭐ 极低	JS/HTML/CSS 本质是明文，从二进制中提取后几乎可直接阅读
Go 二进制	⭐⭐ 较低	Go 编译产物保留大量符号、类型、路径信息，反编译友好
前后端绑定	⭐ 极低	Wails 的 bindings 自动生成，接口名、参数结构一目了然
核心算法/密钥	⭐⭐ 较低	若硬编码在 Go 或 JS 中，均可被提取

Bash

1
# Wails 将前端资源嵌入二进制，但可通过工具提取
2
# 例如使用 binwalk、strings 或专用脚本提取嵌入的 zip/文件系统
3
strings myapp.exe | grep -i "function\|api\|key"

Bash

1
# Go 二进制默认保留完整符号表
2
go tool objdump myapp.exe
3
# 使用 Ghidra + Golang 插件可恢复函数名和结构体
4
# 使用 IDA Pro 的 GoReSym 插件可还原符号

措施	效果	局限
JS 混淆（Jscrambler/javascript-obfuscator）	增加前端分析时间	可被 deobfuscator 还原逻辑
Go 符号剥离 `-ldflags="-s -w"`	减小体积，去掉部分信息	对专业逆向者影响有限
Go 代码混淆（garble）	打乱函数名/变量名	控制流仍可分析
加壳（VMProtect / Themida）	增加静态分析难度	可被脱壳，且影响性能
关键逻辑移至服务端	✅ 最有效	需要网络，增加架构复杂度
WASM 加密模块	增加提取难度	仍可被 dump 和分析
反调试 / 完整性校验	增加动态分析门槛	可被 patch 绕过

text

1
🔑 核心原则：不要信任客户端

Wails 应用 ≠ 安全黑盒。
它的 Web 前端天然透明，Go 后端逆向门槛也不高。如果你的威胁模型是”防止任何人逆向”，那 Wails（或任何客户端框架）都做不到。
正确的思路是：假设客户端一定会被破解，把安全边界放在服务端。

如果你能说明具体想保护什么（算法？许可证？数据？），我可以给出更有针对性的方案。