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

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

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

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

现在我的问题是:

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


当前回答

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

其他回答

作为一个在支付平台(包括一个移动支付应用程序(MyCheck))上广泛工作的人,我想说,您需要将这种行为委托给服务器。移动应用程序中不应存储或硬编码支付处理器的用户名或密码(以其为准)。这是您最不希望看到的,因为即使您混淆了代码,也可以理解源代码。

此外,您不应在应用程序上存储信用卡或支付令牌。一切都应该再次委托给您构建的服务。这也会让你以后更容易遵守PCI标准,信用卡公司也不会像对待我们那样,让你喘不过气来。

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

AFAIK,没有任何技巧可以完全避免逆向工程。

@inazaruk也说得很好:无论你对代码做了什么,潜在的攻击者都可以以她或他认为可行的任何方式修改代码。你基本上无法保护你的应用程序不被修改。您在其中放置的任何保护都可以禁用/删除。

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

不过,你可以使用不同的技巧来提高黑客攻击的难度。例如,使用混淆(如果是Java代码)。这通常会大大降低逆向工程的速度。

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

正如大家所说的,正如你可能知道的,没有100%的安全性。但谷歌内置的安卓系统的起点是ProGuard。如果您可以选择包含共享库,则可以在C++中包含所需的代码,等。如果您需要在每次构建时将外部本机库添加到APK的库文件夹中,那么你可以根据以下建议使用它。

将库放在默认为“libs”的本机库路径中您的项目文件夹。如果您为“armeabi”目标构建了本机代码,请将其放入在libs/armeabi下。如果它是用armeabi-v7a建造的,那么把它放在下面libs/armeabi-v7a。

<project>/libs/armeabi/libstuff.so

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

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

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

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

不可能的

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

不可能的

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

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

如果我们想让逆向工程(几乎)不可能实现,我们可以将应用程序放在一个高度防篡改的芯片上,该芯片在内部执行所有敏感的内容,并与一些协议通信,使控制GUI在主机上成为可能。即使是防篡改芯片也不能100%防裂;他们只是设定了比软件方法高得多的标准。当然,这是不方便的:该应用程序需要一些小的USB疣来保持芯片插入设备。

这个问题并没有揭示出想要如此谨慎地保护这个应用程序的动机。

如果目的是通过隐藏应用程序可能存在的任何安全缺陷(已知或其他)来提高支付方法的安全性,那么这是完全错误的。如果可行的话,安全敏感位实际上应该是开源的。您应该尽可能方便任何审查您的应用程序的安全研究人员查找这些信息并仔细检查其操作,并与您联系。付款应用程序不应包含任何嵌入证书。也就是说,不应该有任何服务器应用程序仅仅因为设备具有来自工厂的固定证书而信任该设备。支付交易应仅凭用户的凭证进行,使用正确设计的端到端认证协议,避免信任应用程序、平台或网络等。

如果目标是防止克隆,除了防篡改芯片之外,你无法采取任何措施来保护程序不被反向工程和复制,从而使某人将兼容的支付方法融入自己的应用程序,从而导致“未经授权的客户”。有一些方法可以使开发未经授权的客户端变得困难。一种方法是基于程序完整状态的快照创建校验和:所有状态变量,所有内容。GUI、逻辑等等。克隆程序将不具有完全相同的内部状态。当然,它是一个状态机,具有类似的外部可见状态转换(可以通过输入和输出观察到),但几乎没有相同的内部状态。服务器应用程序可以询问程序:您的详细状态是什么?(即给我一个所有内部状态变量的校验和)。这可以与虚拟客户端代码进行比较,虚拟客户端代码在服务器上并行执行,并经过真正的状态转换。第三方克隆人必须复制真实程序的所有相关状态变化,才能给出正确的响应,这将阻碍其开发。