我正在为Android开发一款支付处理应用程序,我想防止黑客访问APK文件中的任何资源、资产或源代码。

如果有人将.apk扩展名更改为.zip,那么他们可以将其解压缩并轻松访问应用程序的所有资源和资产,并且可以使用dex2jar和Java反编译器访问源代码。对Android APK文件进行反向工程非常容易-有关更多详细信息,请参阅堆栈溢出问题从APK文件到项目的反向工程。

我已经使用了Android SDK提供的Proguard工具。当我对使用签名密钥库和Proguard生成的APK文件进行反向工程时,我得到了混淆的代码。

然而,Android组件的名称保持不变,一些代码(如应用程序中使用的关键值)保持不变。根据Proguard文档,该工具无法混淆Manifest文件中提到的组件。

现在我的问题是:

如何完全防止Android APK的反向工程?这可能吗?我如何保护应用程序的所有资源、资产和源代码,使黑客无法以任何方式破解APK文件?有没有办法让黑客攻击变得更加困难甚至不可能?我还能做什么来保护APK文件中的源代码?


当前回答

只是上面已经很好的答案的补充。

我知道的另一个技巧是将有价值的代码存储为Java库。然后将该库设置为Android项目。与C.so文件一样好,但Android Lib可以。

这样,这些存储在Android库中的宝贵代码在反编译后将不可见。

其他回答

1.如何完全避免Android APK的反向工程?这可能吗?

不可能的

2.如何保护应用程序的所有资源、资产和源代码,使黑客无法以任何方式破解APK文件?

不可能的

3.有没有办法让黑客攻击变得更加困难甚至不可能?我还能做什么来保护APK文件中的源代码?

可能会更难,但事实上,对于普通用户来说,这将更难,因为他们只是在谷歌上搜索黑客指南。如果有人真的想入侵你的应用程序,它迟早会被入侵。

基本上这是不可能的。这永远不可能。然而,这是有希望的。你可以使用混淆器来实现,这样一些常见的攻击就更难执行了,包括:

重命名方法/类(因此在反编译器中,您可以获得像.a这样的类型)使控制流混乱(因此在反编译器中,代码很难阅读)加密字符串和可能的资源

我肯定还有其他的,但这是主要的。我在一家名为PreEmptive Solutions的公司工作,负责.NET混淆器。他们还有一个适用于Android的Java混淆器,一个叫做DashO的混淆器。

不过,困惑总是有代价的。值得注意的是,性能通常更差,通常需要一些额外的时间来发布。然而,如果你的知识产权对你来说非常重要,那么它通常是值得的。

否则,你唯一的选择就是让你的Android应用程序直接传递到一个承载你应用程序所有真实逻辑的服务器。这有其自身的问题,因为这意味着用户必须连接到Internet才能使用您的应用程序。

此外,不仅仅是Android有这个问题。这是每个应用商店的问题。这只是获取程序包文件有多困难的问题(例如,我不相信在iPhone上很容易,但仍然有可能)。

不,不可能!

你的三个问题围绕着100%保护应用程序不被阅读。原则上这是做不到的。而且,你在尝试做这件事上投入的越多,你的体验就会越差,最终,无论哪台机器只想读你的应用。想想HTTP的HTTPS本质上有多慢,因为需要处理安全层和数学。层数越多,有人打开它的速度就越慢,但如果你真的想让它被阅读,那就永远不可能,这就是为什么它会被打包并交付的原因。

一个简单的类比是将任何给定的隐藏对象交给某人。如果那个人能看到里面的东西,那么他们就可以拍一张照片,做一些完全类似的事情。更重要的是,在代码的情况下,有足够的专业人员可以创建该对象的精确副本,即使使用完全不同的过程。

假安全感

作为一个处理应用程序,你不应该关心你认为可以在二进制代码中创建的任何安全性,也不应该关心整个系统的完整性。假设来自客户机的任何信息都可能很快变得不可靠。保持应用程序简单、流畅、快速。相反,请担心您的服务器。例如,制定一个严格的通信协议以方便地监控服务器。这是我们唯一可以依靠的。

现在,坚持我的另一个想法,如何改进服务器端。。。

嘴上的钱

我正在开发支付处理应用程序

谷歌通过使用一种简单的财务方法来“保护”谷歌Chrome,在总体上成功地避免了恶意黑客,我引述如下:

我们有50000美元的奖励,奖励参与者可以在客户模式下使用Chromebook或Chromebox进行设备持久性测试

我们真正接近100%“安全”的最佳选择是为我们的金钱价值选择正确的斗争。也许大多数人都无法提供50k的奖励,但即使是1k的奖励也会有很长的路要走,而且这也比将这些钱投资于设计任何类型的bug捕捉器要便宜得多。

投资于人工智能来识别资金流动模式,以预测潜在风险并发现小的泄漏,这也比通过任何工程来防止这两种情况要便宜得多。

明显的例外

当然,这并不能保护我们免受“疯子”和“幸运的恶作剧者”的伤害。。。但什么都不会。同时,如果设置得当,当系统重新调整时,后一组只会享受很少的时间。而一个疯子,我们只需要担心,以防它大到有一个克星。无论如何,这将是一个伟大的故事!:)

太长;没有阅读;

换言之,也许一个更好的问题可以问你自己,而不是“如何避免在我的应用程序中进行逆向工程”,而是“如何设计一个更安全的支付处理系统”,并专注于你实际想要实现的目标:一个安全的系统。

很久以前,我曾尝试写更多关于以上所有内容的文章,以回答一些问题,比如为什么我在引号中加上“安全”和“保护”(它们到底是什么意思?)。

此处同意@Muhammad Saqib:https://stackoverflow.com/a/46183706/2496464

@Mumair提供了良好的开始步骤:https://stackoverflow.com/a/35411378/474330

假设您分发到用户设备的所有内容都属于用户,这总是安全的。简单明了。你也许可以使用最新的工具和程序来加密你的知识产权,但没有办法阻止一个有决心的人“研究”你的系统。即使目前的技术可能会让他们很难获得不需要的访问权限,明天,甚至下一个小时,可能会有一些简单的方法!

因此,方程式如下:

说到钱,我们总是认为客户是不可信的。

即使在游戏内经济这么简单的情况下。(尤其是在游戏中!那里有更多“老练”的用户,漏洞在几秒钟内就扩散了!)

我们如何保持安全?

大多数(如果不是全部)关键处理系统(当然还有数据库)都位于服务器端。客户端和服务器之间存在加密通信、验证等。这就是瘦客户端的概念。

我可以看出这个问题有很好的答案。除此之外,您可以使用FacebookReDex来优化代码。ReDex在.dex级别工作,而ProGuard在.class级别工作。