我正在为Android开发一款支付处理应用程序,我想防止黑客访问APK文件中的任何资源、资产或源代码。
如果有人将.apk扩展名更改为.zip,那么他们可以将其解压缩并轻松访问应用程序的所有资源和资产,并且可以使用dex2jar和Java反编译器访问源代码。对Android APK文件进行反向工程非常容易-有关更多详细信息,请参阅堆栈溢出问题从APK文件到项目的反向工程。
我已经使用了Android SDK提供的Proguard工具。当我对使用签名密钥库和Proguard生成的APK文件进行反向工程时,我得到了混淆的代码。
然而,Android组件的名称保持不变,一些代码(如应用程序中使用的关键值)保持不变。根据Proguard文档,该工具无法混淆Manifest文件中提到的组件。
现在我的问题是:
如何完全防止Android APK的反向工程?这可能吗?我如何保护应用程序的所有资源、资产和源代码,使黑客无法以任何方式破解APK文件?有没有办法让黑客攻击变得更加困难甚至不可能?我还能做什么来保护APK文件中的源代码?
完全避免逆向工程是不可能的,但通过在内部使其更加复杂,攻击者可能更难看到应用程序的清晰操作,这可能会减少攻击向量的数量。
如果应用程序处理高度敏感的数据,则存在各种技术,这些技术会增加代码反向工程的复杂性。一种技术是使用C/C++来限制攻击者容易进行的运行时操作。有大量的C和C++库非常成熟,易于集成,Android提供JNI。
攻击者必须首先绕过调试限制,才能在较低级别上攻击应用程序。这增加了攻击的复杂性。Android应用程序应在应用程序清单中设置Android:debuggable=“false”,以防止攻击者或恶意软件轻易地进行运行时操作。
跟踪检查–应用程序可以确定调试器或其他调试工具当前是否正在跟踪它。如果被跟踪,应用程序可以执行任意数量的可能的攻击响应动作,例如丢弃加密密钥以保护用户数据、通知服务器管理员或其他此类类型的响应以试图自卫。这可以通过检查进程状态标志或使用其他技术来确定,如比较ptrace附件的返回值、检查父进程、进程列表中的黑名单调试器或比较程序不同位置的时间戳。
优化-为了隐藏高级数学计算和其他类型的复杂逻辑,利用编译器优化可以帮助混淆目标代码,使其不易被攻击者分解,从而使攻击者更难理解特定代码。在Android中,这可以通过使用NDK本地编译的库更容易地实现。此外,使用LLVM混淆器或任何保护器SDK将提供更好的机器代码混淆。
剥离二进制文件–剥离本机二进制文件是一种有效的方法,可以增加攻击者查看应用程序低级功能组成所需的时间和技能水平。通过剥离二进制文件,二进制文件的符号表被剥离,这样攻击者就无法轻松调试或反向工程应用程序。您可以参考GNU/Linux系统上使用的技术,如sstriping或使用UPX。
最后,您必须了解混淆和ProGuard等工具。
Android 7.0中的APK签名方案v2(Nougat)
PackageManager类现在支持使用APK签名方案v2验证应用程序。APK签名方案v2是一个完整的文件签名方案,通过检测对APK文件的任何未经授权的更改,显著提高了验证速度并加强了完整性保证。
为了保持向后兼容性,APK必须在使用v2签名方案签名之前使用v1签名方案(JAR签名方案)签名。使用v2签名方案,如果在使用v2方案签名后使用附加证书对APK进行签名,则验证失败。
APK签名方案v2支持稍后将在N开发者预览版中提供。
http://developer.android.com/preview/api-overview.html#apk_signature_v2
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
不,不可能!
你的三个问题围绕着100%保护应用程序不被阅读。原则上这是做不到的。而且,你在尝试做这件事上投入的越多,你的体验就会越差,最终,无论哪台机器只想读你的应用。想想HTTP的HTTPS本质上有多慢,因为需要处理安全层和数学。层数越多,有人打开它的速度就越慢,但如果你真的想让它被阅读,那就永远不可能,这就是为什么它会被打包并交付的原因。
一个简单的类比是将任何给定的隐藏对象交给某人。如果那个人能看到里面的东西,那么他们就可以拍一张照片,做一些完全类似的事情。更重要的是,在代码的情况下,有足够的专业人员可以创建该对象的精确副本,即使使用完全不同的过程。
假安全感
作为一个处理应用程序,你不应该关心你认为可以在二进制代码中创建的任何安全性,也不应该关心整个系统的完整性。假设来自客户机的任何信息都可能很快变得不可靠。保持应用程序简单、流畅、快速。相反,请担心您的服务器。例如,制定一个严格的通信协议以方便地监控服务器。这是我们唯一可以依靠的。
现在,坚持我的另一个想法,如何改进服务器端。。。
嘴上的钱
我正在开发支付处理应用程序
谷歌通过使用一种简单的财务方法来“保护”谷歌Chrome,在总体上成功地避免了恶意黑客,我引述如下:
我们有50000美元的奖励,奖励参与者可以在客户模式下使用Chromebook或Chromebox进行设备持久性测试
我们真正接近100%“安全”的最佳选择是为我们的金钱价值选择正确的斗争。也许大多数人都无法提供50k的奖励,但即使是1k的奖励也会有很长的路要走,而且这也比将这些钱投资于设计任何类型的bug捕捉器要便宜得多。
投资于人工智能来识别资金流动模式,以预测潜在风险并发现小的泄漏,这也比通过任何工程来防止这两种情况要便宜得多。
明显的例外
当然,这并不能保护我们免受“疯子”和“幸运的恶作剧者”的伤害。。。但什么都不会。同时,如果设置得当,当系统重新调整时,后一组只会享受很少的时间。而一个疯子,我们只需要担心,以防它大到有一个克星。无论如何,这将是一个伟大的故事!:)
太长;没有阅读;
换言之,也许一个更好的问题可以问你自己,而不是“如何避免在我的应用程序中进行逆向工程”,而是“如何设计一个更安全的支付处理系统”,并专注于你实际想要实现的目标:一个安全的系统。
很久以前,我曾尝试写更多关于以上所有内容的文章,以回答一些问题,比如为什么我在引号中加上“安全”和“保护”(它们到底是什么意思?)。