编译后Delphi iOS/Android应用硬编码加密算法与密码的查找难度问询

咱们先拆解你的问题，分两部分来聊：逆向查找硬编码加密信息的难度，以及如何确保客户端结果不被篡改。

一、逆向查找硬编码加密算法与密码的难度对比 #

你提到Windows平台有大量成熟工具，这点没错——IDA、x64dbg、PEview这些工具能让新手快速定位硬编码字符串、反汇编加密逻辑。那iOS和Android平台的情况呢？

iOS平台 #

Delphi编译iOS会生成ARM64架构的Mach-O二进制文件，这里的逆向门槛比Windows稍高，但绝非不可行：

• 首先，非越狱设备很难获取到应用的原始二进制，但越狱后可以用frida-ios-dump这类工具脱壳，拿到可逆向的文件。
• 硬编码密码：如果是直接写死的字符串，用strings命令扫一遍Mach-O文件就能轻松找到；哪怕是简单混淆（比如XOR加密字符串），逆向者只要跟踪下解密逻辑的指令，几分钟就能还原出明文。
• 加密算法：Delphi自带的System.Cryptography库编译后会变成ARM机器码，有经验的逆向工程师能通过指令特征快速识别出AES、RSA这类常见算法；就算是你自己实现的小众算法，只要有足够的耐心跟踪调用栈，也能把逻辑扒出来。

Android平台 #

Delphi编译Android会生成APK，里面核心逻辑其实是打包在lib/armeabi-v7a或lib/arm64-v8a下的.so原生库：

• APK本身很容易用apktool解压，但核心的加密逻辑不在Dalvik字节码里，而是在.so文件中。
• 硬编码密码：同样，未混淆的字符串用strings扫.so文件就能找到；如果做了混淆，就需要用IDA或Ghidra这类工具逆向ARM架构的机器码，难度比逆向Dalvik字节码高，但对于专业逆向来说只是时间问题。
• 加密算法：和iOS类似，常见加密算法的指令序列有固定特征，逆向者能快速定位；自定义算法也逃不过指令级的分析。

和Windows的对比 #

本质上，硬编码的内容在任何平台都不安全——Windows平台工具链更成熟，逆向门槛低；iOS/Android需要对ARM架构有了解，还要处理脱壳、签名验证这些额外步骤，但只要攻击者有足够的经验和时间，硬编码的密钥、算法逻辑迟早会被扒出来。

二、客户端结果防篡改的核心思路 #

你想让客户端加密结果发给服务器，但这里有个致命问题：如果加密密钥是硬编码在客户端的，攻击者逆向拿到密钥后，完全可以篡改结果再用密钥重新加密，服务器根本分辨不出真假。

给你几个更靠谱的方案：

• 用数字签名替代单纯加密：服务器给每个客户端分配唯一的私钥（别硬编码！最好通过服务器动态下发，存在iOS的Keychain或Android的Keystore里），客户端用私钥对结果做签名，服务器用对应的公钥验证签名。这样就算攻击者篡改了结果，也没法生成有效的签名。
• 增加挑战-响应机制：客户端发起操作前，服务器先下发一个随机的挑战值，客户端把挑战值和操作结果一起签名/加密后发给服务器。因为挑战值是随机的，攻击者没法提前伪造合法的结果。
• 客户端环境检测：在执行核心操作前，检测设备是否越狱/root、是否有调试器附加、应用签名是否被篡改。虽然没法完全阻止攻击者，但能大幅提高篡改成本。
• 核心逻辑上移到服务器：如果业务允许，把计算结果的核心逻辑放在服务器端，客户端只负责收集输入数据，发送给服务器计算后返回结果。这样客户端根本碰不到最终结果，自然没法篡改。

总结一下：别指望硬编码加密能防篡改，必须结合服务器端的验证机制，从“信任客户端”转向“验证客户端提交内容的合法性”。

内容的提问来源于stack exchange，提问作者zeus