android逆向 - 微信逆向android




如何避免反向工程的APK文件? (20)

我正在开发针对Android的付款处理应用程序 ,并且我想阻止黑客访问APK文件中的任何资源,资产或源代码。

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

我已经使用了Android SDK提供的Proguard工具。 当我对使用签名的密钥库和Proguard生成的APK文件进行反向工程时,我得到了混淆的代码。 但是,Android组件的名称保持不变,并且某些代码(如应用中使用的键值)保持不变。 根据Proguard文档,该工具不能混淆Manifest文件中提到的组件。

现在我的问题是:

  1. 我如何完全避免 Android APK的逆向工程? 这可能吗?
  2. 我如何保护所有应用程序的资源,资产和源代码,以便黑客无法以任何方式破解APK文件?
  3. 有没有办法让黑客更加困难甚至不可能? 我还能做些什么来保护APK文件中的源代码?

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

AFAIK,完全避免逆向工程没有任何窍门。

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

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

尽管如此,你可以使用不同的技巧来使黑客更加困难。 例如,使用混淆(如果它是Java代码)。 这通常会显着减缓逆向工程。

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

正如大家所说,并且你可能知道,没有100%的安全性。 但是,谷歌内置的Android开始之地是ProGuard。 如果您可以选择包含共享库 ,那么您可以在C ++中包含所需的代码来验证文件大小,集成等。如果您需要将外部本机库添加到每个构建的APK库文件夹中,则可以使用它由下面的建议。

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

<project>/libs/armeabi/libstuff.so

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

这是不可能的

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

当有人将.apk扩展名更改为.zip时,解压缩后,某人可以轻松获取所有资源( Manifest.xml除外),但使用APKtool您也可以获取清单文件的实际内容。 再次,一个没有。

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

再次,不,但是你可以防止达到某个水平,也就是说,

  • 从Web下载资源并执行一些加密过程
  • 使用预编译的本机库(C,C ++,JNI,NDK)
  • 总是执行一些散列( MD5 / SHA键或任何其他逻辑)

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


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

不可能

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

不可能

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

更强硬 - 可能,但实际上,对于普通用户来说,这种攻击会更加困难,因为普通用户只是在搜索黑客指南。 如果有人真的想破解你的应用 - 它迟早会被黑客入侵。


应用程序安全性的第一条规则:无论攻击者实际在哪里或为此支付了多少钱,攻击者现在获得无限制物理或电子访问权限的任何计算机都属于您的攻击者。

应用程序安全的第二条规则:无论您花费多少时间对代码进行编码,任何让攻击者无法穿透的物理边界的软件都属于您的攻击者。

第三条规则:任何留下攻击者无法穿透的物理边界的信息都属于你的攻击者,不管它对你有多大的价值。

信息技术安全的基础是基于这三个基本原则; 唯一真正安全的电脑就是一个锁在法拉第笼内的保险箱里面,一个钢制的笼子里。 有些电脑的大部分使用寿命都处于这种状态; 每年一次(或更少),他们为受信任的根证书颁发机构生成私钥(在许多目击者面前,摄像机记录他们所在的房间的每一寸)。

现在,大多数计算机不在这些类型的环境下使用; 他们身体状况良好,通过无线电频道连接到互联网。 简而言之,他们和他们的软件一样脆弱。 因此他们不被信任。 计算机及其软件必须知道或做某些事情才能有用,但必须注意确保他们永远不会知道或足够造成损害(至少在单个机器的范围之外不会造成永久性损坏) )。

你已经知道这一切; 这就是为什么你要保护你的应用程序的代码。 但是,这是第一个问题。 混淆工具可能会让代码变得混乱,以致于人们试图挖掘,但程序仍然需要运行; 这意味着应用程序的实际逻辑流程及其使用的数据不受混淆影响。 给定一点韧性,攻击者可以简单地解开代码,而且在某些情况下甚至不需要他看到的东西不能只是他想要的东西。

相反,您应该试图确保攻击者无法对您的代码执行任何操作,无论他获得清晰的副本是多么容易。 这意味着,没有硬编码的秘密,因为只要代码离开您开发它的建筑物,这些秘密就不是秘密。

这些硬编码的键值应完全从应用程序的源代码中删除。 相反,他们应该在三个地方之一。 设备上的非易失性内存,攻击者获取脱机副本比较困难(但仍然不是不可能); 永久地放在服务器群集上,通过铁腕来控制访问; 或与您的设备或服务器无关的第二个数据存储区(如物理卡或用户存储器中)(意味着它最终将存储在易失性存储器中,但不一定要很长时间)。

考虑以下方案。 用户从内存中输入他们的应用程序凭据到设备中。 不幸的是,您必须相信用户的设备并未被键盘记录程序或特洛伊木马危害; 在这方面你可以做的最好的办法是通过记住关于用户使用的设备(MAC / IP,IMEI等)的难以辨认的信息并通过提供至少一个附加通道来实现多因素安全可以验证陌生设备上的登录尝试。

凭证一旦输入,就会被客户端软件模糊处理(使用安全散列),并丢弃纯文本凭证; 他们已经达到了目的。 混淆后的凭证通过安全通道发送到证书认证服务器, 再次将其再次散列以产生用于验证登录有效性的数据。 这样,客户端永远不会知道与数据库值进行了什么实际比较,应用程序服务器从不知道验证所接收到的纯文本凭证,数据服务器永远不知道它存储用于验证的数据是如何产生的,即使安全通道受到损害,中间只能看到乱码。

一旦通过验证,服务器就会通过该通道传回令牌。 该令牌仅在安全会话中有用,由随机噪声或会话标识符的加密(并因此可验证)副本组成,并且客户端应用程序必须将该令牌作为任何请求的一部分在同一个通道上发送到服务器做某事。 客户端应用程序会多次执行此操作,因为它不能执行任何涉及金钱,敏感数据或任何可能会对其造成损害的任何事情; 它必须要求服务器完成这项任务。 客户端应用程序永远不会将任何敏感信息写入设备本身的永久内存中,至少不能以纯文本形式; 客户端可以通过安全通道向服务器请求对称密钥来加密服务器将记住的任何本地数据; 在稍后的会话中,客户端可以向服务器请求相同的密钥来解密用于易失性存储器的数据。 这些数据也不会是唯一的副本; 客户端存储的任何内容都应以某种形式传输到服务器。

显然,这使得你的应用程序严重依赖于Internet访问; 如果没有服务器的正确连接和认证,客户端设备不能执行其任何基本功能。 真的,与Facebook没有什么不同。

现在,攻击者需要的计算机就是你的服务器,因为它而不是客户端应用程序/设备是可以使他赚钱或使他人享受他人痛苦的东西。 没关系; 与保护所有客户端相比,您花更多的钱和更多的努力来保护服务器,您将获得更大的回报。 该服务器可以位于各种防火墙和其他电子安全设备的后面,并且还可以在钢结构,混凝土,钥匙卡/引脚访问以及24小时视频监控之后进行物理固定。 你的攻击者确实需要非常复杂才能直接获得对服务器的任何访问权限,并且你应该立即知道它。

攻击者可以做的最好的事情是窃取用户的电话和凭据,并以客户端的有限权限登录到服务器。 如果发生这种情况,就像丢失信用卡一样,应该指示合法用户拨打800号码(最好容易记住,而不是在他们携带的钱包,钱包或公文包中携带的卡的背面)从他们可以访问的任何手机上直接连接到您的客户服务。 他们表示他们的手机被盗,提供了一些基本的唯一标识符,并且账户被锁定,攻击者可能处理的任何交易都会回滚,攻击者又回到原点。


Nothing is secure when you put it on end-users hand but some common practice may make this harder for attacker to steal data.

  • Put your main logic (algorithms) into server side.
  • Communicate with server and client; make sure communication b/w server and client is secured via SSL or HTTPS; or use other techniques key-pair generation algorithms (ECC, RSA). Ensure that sensitive information is remain End-to-End encrypted.
  • Use sessions and expire them after specific time interval.
  • Encrypt resources and fetch them from server on demand.
  • Or you can make Hybrid app which access system via webview protect resource + code on server

Multiple approaches; this is obvious you have to sacrifice among performance and security


100%避免对Android APK进行逆向工程是不可能的,但您可以使用这些方法来避免提取更多数据,例如源代码,APK资源和资源:

  1. 使用ProGuard来模糊应用程序代码

  2. 使用使用C和C ++的 NDK将您的应用程序核心和部分代码保存在.so文件中

  3. 为了确保资源安全,请勿使用APK在资产文件夹中包含所有重要资源。 在申请首次启动时下载这些资源。


APK signature scheme v2 in Android N

The PackageManager class now supports verifying apps using the APK signature scheme v2. The APK signature scheme v2 is a whole-file signature scheme that significantly improves verification speed and strengthens integrity guarantees by detecting any unauthorized changes to APK files.

To maintain backward-compatibility, an APK must be signed with the v1 signature scheme (JAR signature scheme) before being signed with the v2 signature scheme. With the v2 signature scheme, verification fails if you sign the APK with an additional certificate after signing with the v2 scheme.

APK signature scheme v2 support will be available later in the N Developer Preview.

http://developer.android.com/preview/api-overview.html#apk_signature_v2


Tool: Using Proguard in your application it can be restricted to reverse engineering your application


Aren't TPM chips (Trusted Platform Module) supposed to manage protected code for you ? They are becoming common on PCs (especially Apple ones) and they may already exist in today's smartphone chips. Unfortunately there is no OS API to make use of it yet. Hopefully Android will add support for this one day. That's also the key to clean content DRM (which Google is working on for WebM).


As someone who worked extensively on payment platforms, including one mobile payments application (MyCheck), I would say that you need to delegate this behaviour to the server, no user name or password for the payment processor (whichever it is) should be stored or hardcoded in the mobile application, that's the last thing you want, because the source can be understood even when if you obfuscate the code.

Also, you shouldn't store credit cards or payment tokens on the application, everything should be, again, delegated to a service you built, it will also allow you later on, be PCI-compliant more easily, and the Credit Card companies won't breath down your neck (like they did for us).


Basically, there are 5 methods to protect your APK. Isolate Java Program, Encrypt Class Files, Convert to Native Codes, Code Obfuscation and Online Encryption I suggest you use online encryption because it is safe and convenient. You needn't spend to much time to achieve this. Such as APK Protect , it is an online encryption website for APK. It provides Java codes and C++ codes protection to achieve anti-debugging and decompile effects. The operation process is simple and easy.



Its not possible to completely avoid RE but By making them more complex internally, you put make it more difficult for attackers to see the clear operation of the app, which may reduce the number of attack vectors.

If the application handles highly sensitive data, Various techniques exist which can increase the complexity of reverse engineering your code. One technique is to use C/C++ to limit easy runtime manipulation by the attacker. There are ample C and C++ libraries that are very mature and easy to integrate with Android offers JNI. An attacker must first circumvent the debugging restrictions in order to attack the application on a low level. This adds further complexity to an attack. Android applications should have android:debuggable=”false” set in the application manifest to prevent easy run time manipulation by an attacker or malware.

Trace Checking – An application can determine whether or not it is currently being traced by a debugger or other debugging tool. If being traced, the application can perform any number of possible attack response actions, such as discarding encryption keys to protect user data, notifying a server administrator, or other such type responses in an attempt to defend itself. This can be determined by checking the process status flags or using other techniques like comparing the return value of ptrace attach, checking parent process, blacklist debuggers in the process list or comparing timestamps on different places of the program.

Optimizations - To hide advanced mathematical computations and other types of complex logic, utilizing compiler optimizations can help obfuscate the object code so that it cannot easily be disassembled by an attacker, making it more difficult for an attacker to gain an understanding of the particular code. In Android this can more easily be achieved by utilizing natively compiled libraries with the NDK. In addition, using an LLVM Obfuscator or any protector SDK will provide better machine code obfuscation.

Stripping binaries – Stripping native binaries is an effective way to increase the amount of time and skill level required of an attacker in order to view the makeup of your application's low level functions. By stripping a binary, the symbol table of the binary is stripped, so that an attacker cannot easily debug or reverse engineer an application.You can refer techniques used on GNU/Linux systems like sstriping or using UPX.

And at last you must be aware about obfuscation and tools like ProGuard.


Just an addition to already good answers above.

Another trick I know is to store valuable codes as Java Library. Then set that Library to be your Android Project. Would be good as C .so file but Android Lib would do.

This way these valuable codes stored on Android Library won't be visible after decompiling.


While I agree there's no 100% solution that's going to protect your code, v3 of HoseDex2Jar is now up if you want to give it a try.


when they have the app on their phone, they have full access to memory of it. so if u want to prevent it from being hacked, you could try to make it so that u cant just get the static memory address directly by using a debugger. they could do a stack buffer overflow if they have somewhere to write and they have a limit. so try to make it so when they write something, if u have to have a limit, if they send in more chars than limit, if (input > limit) then ignore, so they cant put assembly code there.


其他有争议的答案在这里是正确的。 我只是想提供另一种选择。

对于您认为重要的某些功能,您可以将WebView控件托管在您的应用程序中。 该功能将在您的Web服务器上实现。 它看起来像在应用程序中运行。


在计算史上,从来没有人可以在向攻击者提供工作副本时阻止对软件进行逆向工程。 而且,大多数情况下, 它永远不可能

有了这个理解,有一个明显的解决方案: 不要把你的秘密给你的攻击者。 虽然您无法保护APK的内容,但您可以保护的是您不会分发的任何内容。 通常,这是服务器端软件,用于激活,支付,规则执行和其他多汁代码。 您可以通过将它们分发到APK中来保护有价值的资产。 相反,请设置一个服务器来响应来自应用程序的请求,“使用”资产(无论这可能意味着什么),然后将结果发送回应用程序。 如果这种模式不适用于您想要的资产,那么您可能需要重新考虑您的策略。

此外, 如果您的主要目标是防止应用程序盗版 :甚至不打扰。 你已经在这个问题上花费了更多的时间和金钱,而不是任何反盗版措施都可能希望拯救你。 解决这个问题的投资回报如此之低,甚至连想都没有意义。


开发人员可以采取以下措施来防止APK以某种方式被盗,

  • 最基本的方法是使用ProGuard工具来混淆他们的代码,但直到现在,要完全防止某人反编译应用程序是相当困难的。

  • 我也听说过一个工具HoseDex2Jar 。 它通过在Android APK中插入无害代码来停止Dex2Jar ,该APK会混淆和禁用Dex2Jar并保护代码免受反编译。 它可以以某种方式防止黑客将APK反编译为可读的Java代码。

  • 仅在需要时才使用某个服务器端应用程序与应用程序进行通信。 它可以帮助防止重要的数据。

毕竟,你无法完全保护你的代码免受潜在的黑客攻击。 不知何故,你可能会让他们难以完成反编译代码的任务。 最有效的方法之一是编写本地代码(C / C ++)并将其作为编译库存储。


您可以尝试以下几种方法:

  1. 使用obfuscationProGuard等工具。
  2. 加密源和数据的一部分。
  3. 在应用中使用专有的内置校验和来检测篡改。
  4. 引入代码以避免在调试器中加载,也就是让应用程序能够检测调试器并退出/终止调试器。
  5. 将身份验证作为在线服务分开。
  6. 使用应用多样性
  7. 在对设备进行身份验证之前,使用手指打印技术来处理来自不同子系统的设备的硬件签名。




reverse-engineering