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

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

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

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

现在我的问题是:

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


当前回答

这里的主要问题是,dex文件是否可以反编译,答案是它们可以“有点”。有像dedexer和smali这样的拆装器。

正确配置的ProGuard会使代码变得模糊。DexGuard是ProGuard的商业扩展版本,它可能会有更多帮助。然而,您的代码仍然可以转换为smali,具有逆向工程经验的开发人员将能够从smali中了解您正在做什么。

也许选择一个好的许可证,并以最好的方式通过法律强制执行。

其他回答

我知道一些银行应用程序正在使用DexGuard,它提供了类、字符串、资产、资源文件和本地库的混淆和加密。

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

这是不可能的

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

当某人将.apk扩展名更改为.zip,然后在解压缩之后,某人可以轻松地获取所有资源(Manifest.xml除外),但使用APKtool,也可以获取清单文件的真实内容。同样,一个不。

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

同样,不,但你可以在一定程度上防止,

从Web下载资源并执行一些加密过程使用预编译的本机库(C、C++、JNI、NDK)始终执行一些哈希(MD5/SHA密钥或任何其他逻辑)

即使使用Smali,人们也可以使用您的代码。总而言之,这是不可能的。

这里的主要问题是,dex文件是否可以反编译,答案是它们可以“有点”。有像dedexer和smali这样的拆装器。

正确配置的ProGuard会使代码变得模糊。DexGuard是ProGuard的商业扩展版本,它可能会有更多帮助。然而,您的代码仍然可以转换为smali,具有逆向工程经验的开发人员将能够从smali中了解您正在做什么。

也许选择一个好的许可证,并以最好的方式通过法律强制执行。

当您将其放在最终用户手中时,没有什么是安全的,但一些常见的做法可能会使攻击者更难窃取数据。

将主要逻辑(算法)放在服务器端。与服务器和客户端通信;确保服务器和客户端之间的通信通过SSL或HTTPS进行安全;或者使用其他技术用于密钥对生成算法(ECC和RSA)。确保敏感信息保持端到端加密。使用会话并在特定时间间隔后使其过期。加密资源并按需从服务器获取资源。或者你可以制作一个混合应用程序,通过webview访问系统,保护服务器上的资源+代码

多种方法;很明显,您必须牺牲性能和安全性。

AFAIK,您不能再保护/res目录中的文件,因为它们现在受到保护。

然而,您可以采取一些步骤来保护源代码,或者至少保护它的功能(如果不是所有功能)。

使用ProGuard等工具。这些将使您的代码变得模糊,如果不是不可能的话,在反编译时更难阅读。将服务中最关键的部分从应用程序中移出,并隐藏在服务器端语言(如PHP)后面的Web服务中。例如,如果你有一个花费了一百万美元编写的算法。你显然不希望人们从你的应用程序中窃取它。移动算法,让它在远程服务器上处理数据,然后使用应用程序简单地向它提供数据。或者使用NDK将它们本机写入.so文件,这比apk更不容易被反编译。我认为目前还没有一个.so文件的反编译器(即使存在,也不如Java反编译器)。此外,正如@nikolay在评论中提到的,在服务器和设备之间进行交互时,应该使用SSL。在设备上存储值时,不要以原始格式存储。例如,如果您有一个游戏,并且您正在SharedPreferences中存储用户的游戏货币数量。假设是10000枚硬币。不要直接保存10000,而是使用((货币*2)+1)/13这样的算法保存。因此,您将1538.53846154保存到SharedPreferences中,而不是10000。然而,上面的例子并不完美,你必须努力想出一个不会因舍入误差而失去货币价值的公式。您可以对服务器端任务执行类似的操作。现在举个例子,让我们来看看你的支付处理应用。假设用户必须支付200美元。不要向服务器发送一个200美元的原始值,而是发送一系列较小的预定义值,这些值加起来可以达到200美元。例如,在服务器上有一个文件或表,它将单词与值等同。假设查理相当于47美元,约翰相当于3美元。所以,你不需要寄200美元,而是可以寄查理四次,约翰四次。在服务器上,解释它们的含义并将其相加。这可以防止黑客向您的服务器发送任意值,因为他们不知道哪个单词对应什么值。作为一种额外的安全措施,您可以使用类似于第3点的公式,并每隔n天更改关键字。最后,你可以在你的应用程序中插入随机无用的源代码,这样黑客就可以大海捞针了。插入包含来自互联网的片段的随机类,或者只是用于计算诸如斐波那契序列之类的随机事物的函数。确保这些类可以编译,但不会被应用程序的实际功能所使用。添加足够多的这些虚假类,黑客将很难找到真正的代码。

总而言之,没有办法100%保护您的应用程序。你可以让它更难,但不是不可能。你的网络服务器可能会被破坏,黑客可以通过监控多个交易金额和你发送的关键字来找出你的关键字,黑客可以费力地通过源代码找出哪个代码是伪代码。

你只能反击,但永远不会赢。