android - 如何使我的代码安全并防止反编译？

Question

我创建了 android 应用程序，它工作正常。
问题是当我们反编译应用程序时，我们可以看到所有代码，所以黑客可以看到我们的。 API 网址 和 API 类 所以他们可以克隆应用程序。

所以我的问题是如何保护我的 android 应用程序，以便保护它免受黑客攻击。

Answer 1

你的问题

I created android app and it is working fine. The issue is that when we decompile the app we can see all the code, so hacker can see our API URL and API Classes so they can clone the app.

无论您使用什么工具来混淆甚至加密代码，您的 API url 在某些时候都需要以明文形式显示，也就是当您执行 API 请求时，因此它很容易被攻击者获取。因此，如果攻击者无法通过静态二进制分析提取它，它将在运行时使用检测框架进行提取，例如 Frida :

Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.

因此，基本上攻击者需要在代码中找到您执行 API 请求的位置，将 Frida 卡在上面，然后提取 URL 或任何与其一起传递的 secret ，以在 API 服务器中识别/授权您的移动应用程序。

攻击者可以采取的另一种方法是在他控制的移动设备中执行中间人攻击，并拦截向 API 服务器发出的请求:


图片来自文章: Steal that API key with a Man in the Middle Attack

正如您在上面的示例中看到的那样，截获的 API 请求显示了 API 服务器 url 和正在使用的 API key 。

可能的解决方案

So my question is that how can I secure my android app so I can protect it from hackers.

增加安全性时，无论是软件还是物质事物，总是与层有关，例如中世纪的城堡，它们不仅有一层防御，而且有好几层。因此，您应该将相同的原则应用于您的移动应用程序。

我将列出一些你应该做的最小的事情，但不是一个详尽的 list 。

JNI/NDK

JNI/NDK :

The Native Development Kit (NDK) is a set of tools that allows you to use C and C++ code with Android, and provides platform libraries you can use to manage native activities and access physical device components, such as sensors and touch input.

在 this demo app我展示了如何使用原生 C 代码 to hide the API key静态二进制分析很容易进行逆向工程，但正如您已经看到的那样，您可以在运行时使用中间人攻击来捕获它。

#include <jni.h>
#include <string>
#include "api_key.h"

extern "C" JNIEXPORT jstring JNICALL
Java_com_criticalblue_currencyconverterdemo_MainActivity_stringFromJNI(
        JNIEnv *env,
        jobject /* this */) {

    // To add the API_KEY to the mobile app when is compiled you need to:
    //   * copy `api_key.h.example` to `api_key.h`
    //   * edit the file and replace this text `place-the-api-key-here` with your desired API_KEY
    std::string JNI_API_KEY = API_KEY_H;

    return env->NewStringUTF(JNI_API_KEY.c_str());
}

如果您想详细了解如何在您的移动应用程序中实现它，请访问 Github 存储库。

混淆

你应该总是混淆你的代码。如果您买不起最先进的解决方案，那么至少使用内置的 ProGuard 解决方案。这增加了浏览代码所需的时间和技能。

加密

您可以使用加密来隐藏敏感代码和数据，快速的 Google 搜索将产生大量资源和技术。

对于用户数据加密，您可以在 Android docs 中开始了解更多信息。 :

Encryption is the process of encoding all user data on an Android device using symmetric encryption keys. Once a device is encrypted, all user-created data is automatically encrypted before committing it to disk and all reads automatically decrypt data before returning it to the calling process. Encryption ensures that even if an unauthorized party tries to access the data, they won’t be able to read it.

您可以阅读 Android docs这样做的一些例子:

This document describes the proper way to use Android's cryptographic facilities and includes some examples of its use. If your app requires greater key security, use the Android Keystore system.

但请记住，使用 Frida 将允许攻击者 Hook 返回未加密数据的代码并提取它，但也需要更多的技巧和时间来实现这一点。

移动应用证明

这个概念引入了一种处理保护您的移动应用程序的新方法。

传统方法主要集中在客户端，但首先您要保护的数据位于 API 服务器中，在这里您需要一种机制，让您知道 什么发出请求的确实是您的正版移动应用程序，与您上传到 Google Play 商店的应用程序相同。

在深入探讨移动应用认证的角色之前，我想先澄清一个关于 的误解。什么对比 谁正在做 API 请求，我会引用 this article我写:

The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?

The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.

移动应用证明角色在 this section 中描述。在我写的另一篇文章中，我引用了以下文字:

The role of a Mobile App Attestation service is to authenticate what is sending the requests, thus only responding to requests coming from genuine mobile app instances and rejecting all other requests from unauthorized sources.

In order to know what is sending the requests to the API server, a Mobile App Attestation service, at run-time, will identify with high confidence that your mobile app is present, has not been tampered/repackaged, is not running in a rooted device, has not been hooked into by an instrumentation framework (Frida, xPosed, Cydia, etc.) and is not the object of a Man in the Middle Attack (MitM). This is achieved by running an SDK in the background that will communicate with a service running in the cloud to attest the integrity of the mobile app and device it is running on.

On a successful attestation of the mobile app integrity, a short time lived JWT token is issued and signed with a secret that only the API server and the Mobile App Attestation service in the cloud know. In the case that attestation fails the JWT token is signed with an incorrect secret. Since the secret used by the Mobile App Attestation service is not known by the mobile app, it is not possible to reverse engineer it at run-time even when the app has been tampered with, is running in a rooted device or communicating over a connection that is the target of a MitM attack.

The mobile app must send the JWT token in the header of every API request. This allows the API server to only serve requests when it can verify that the JWT token was signed with the shared secret and that it has not expired. All other requests will be refused. In other words a valid JWT token tells the API server that what is making the request is the genuine mobile app uploaded to the Google or Apple store, while an invalid or missing JWT token means that what is making the request is not authorized to do so, because it may be a bot, a repackaged app or an attacker making a MitM attack.

因此，如果 JWT token 具有有效的签名和过期时间，这种方法将使您的 API 服务器非常有信心地相信请求确实来自您上传到 Google Play 商店的同一个移动应用程序，并且将所有其他请求丢弃为不可信请求。

加倍努力

我忍不住向您推荐 OWASP 基金会的出色工作，因为没有经过 The Mobile Security Testing Guide 的移动安全解决方案是不完整的。 :

The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.