我正在为Android开发 payment processing app ，我想阻止黑客访问APK文件中的任何资源，资产或源代码 .
如果有人将.apk扩展名更改为.zip，那么他们可以解压缩并轻松访问所有应用程序的资源和资产，并使用dex2jar和Java反编译器，他们也可以访问源代码 . 反向工程Android APK文件非常容易 - 有关更多详细信息，请参阅Stack Overflow问题Reverse engineering from an APK file to a project .
我使用了随Android SDK提供的Proguard工具 . 当我对使用签名密钥库和Proguard生成的APK文件进行逆向工程时，我得到了混淆代码 .
但是，Android组件的名称保持不变，某些代码（如应用程序中使用的键值）保持不变 . 根据Proguard文档，该工具不能混淆清单文件中提到的组件 .
现在我的问题是：
-
如何 completely prevent 逆向工程Android APK？这可能吗？
-
如何以任何方式保护所有app 's resources, assets and source code so that hackers can' t hack APK文件？
-
Is there a way to make hacking more tough or even impossible? 我还可以做些什么来保护我的APK文件中的源代码？
30 回答
AFAIK，完全避免逆向工程没有任何技巧 .
并且@inazaruk也很好地说：无论你对你的代码做什么，潜在的攻击者都能够以她或他认为可行的任何方式改变它 . 您基本上无法保护您的应用程序不被修改 . 您放在那里的任何保护都可以被禁用/删除 .
你可以做不同的技巧，以使黑客更难 . 例如，使用模糊处理（如果是Java代码） . 这通常会显着降低逆向工程的速度 .
正如大家所说，并且你可能知道，没有100％的安全性 . 但是，谷歌内置的Android起点是ProGuard . 如果您可以选择包含 shared libraries ，则可以在C中包含所需的代码以验证文件大小，集成等 . 如果您需要在每个构建时将外部本机库添加到APK的库文件夹，那么您可以使用它以下建议 .
将库放在项目文件夹中默认为"libs"的本机库路径中 . 如果您为 'armeabi' 目标构建了本机代码，则将其置于 libs/armeabi 之下 . 如果它是用 armeabi-v7a 构建的，那么将它放在 libs/armeabi-v7a. 下
在计算历史中，任何时候都有可能在向攻击者提供软件的工作副本时阻止软件的逆向工程 . 此外，最有可能的是 it never will be possible .
有了这个，有一个明显的解决方案：不要把你的秘密告诉你的攻击者 . 虽然您无法保护APK的内容，但您可以保护的是您不分发的任何内容 . 通常，这是服务器端软件，用于激活，支付，规则执行和其他多汁的代码 . 您可以通过不在APK中分发宝贵资产来保护宝贵资产 . 相反，设置一个响应来自您的应用程序的请求的服务器，无论这可能意味着什么，然后将结果发送回应用程序 . 如果此模型不适用于您所考虑的资产，那么您可能需要重新考虑您的策略 .
此外，在这个问题上已经花费了更多的时间和金钱，而不是任何反盗版措施都可能希望拯救你 . 解决这个问题的投资回报率很低，甚至没有意义 .
APK文件受SHA-1算法保护 . 您可以在APK的 META-INF 文件夹中看到一些文件 . 如果您提取任何APK文件并更改其任何内容并再次压缩它，并且当您在Android计算机上运行该新APK文件时，它将无法工作，因为SHA-1哈希将永远不会匹配 .
不可能100％避免Android APK的逆向工程，但您可以使用这些方法来避免提取更多数据，例如源代码，资源形成您的APK和资源：
使用ProGuard模糊应用程序代码
使用C和C使用NDK将应用程序核心和安全部分代码保存在
.so文件中要保护资源，请不要在APK资产文件夹中包含所有重要资源 . 首次启动应用程序时下载这些资源 .
不可能
不可能
更加艰难 - 可能，但事实上，对于普通用户而言，这将更加艰难，他们只是在谷歌搜索黑客指南 . 如果有人真的想破解你的应用程序 - 它迟早会被黑客入侵 .
作为在支付平台上广泛工作的人，包括一个移动支付应用程序（MyCheck），我会说你需要将这种行为委托给服务器，不应该存储支付处理器的用户名或密码（无论哪个）或者在移动应用程序中硬编码，这是你想要的最后一件事，因为即使你混淆了代码，也可以理解源代码 .
此外，您不应该在应用程序上存储信用卡或付款令牌，所有内容应该再次委托给您构建的服务，以后也会允许您使用，更容易符合PCI标准，并且信用卡公司赢了从你的颈部呼吸（就像他们为我们做的那样） .
如果您的应用程序是敏感的，那么您应该考虑服务器端的付款处理部分 . 尝试更改您的付款处理算法 . 仅使用Android应用程序收集和显示用户信息（即帐户余额），而不是在Java代码中处理付款，使用带有加密参数的安全SSL协议将此任务发送到您的服务器 . 创建完全加密且安全的API以与您的服务器通信 .
当然，它也可能被黑客入侵，它与源代码保护无关，但考虑到另一个安全层，使黑客更难以欺骗你的应用程序 .
同意@Muhammad Saqib：https://stackoverflow.com/a/46183706/2496464
@Mumair提供了一个很好的开始步骤：https://stackoverflow.com/a/35411378/474330
假设您分发给用户设备的所有内容都属于用户，这始终是安全的 . 干净利落 . 您可以使用最新的工具和程序来加密您的知识产权，但是无法阻止一个坚定的人“学习”您的系统 . 即使当前的技术可能使他们难以获得不必要的访问，明天可能会有一些简单的方法，甚至只是下一个小时！
因此，这里是等式：
即使像游戏中的经济一样简单 . （特别是在游戏中！那里有更多'复杂'用户，漏洞在几秒钟内传播开来！）
我们如何保持安全？
大多数（如果不是全部）我们的关键处理系统（当然还有数据库）位于服务器端 . 在客户端和服务器之间，存在加密通信，验证等等 . 这就是瘦客户端的想法 .
它不可能完全避免RE但是通过使它们在内部变得更复杂，你会让攻击者更难以看到app的清晰操作，这可能会减少攻击向量的数量 .
如果应用程序处理高度敏感的数据，则会存在各种技术，这些技术会增加代码逆向工程的复杂性 . 一种技术是使用C / C来限制攻击者轻松进行运行时操作 . 有充足的C和C库非常成熟，易于与Android提供JNI集成 . 攻击者必须首先规避调试限制，以便在较低级别攻击应用程序 . 这进一步增加了攻击的复杂性 . Android应用程序应在应用程序清单中设置android：debuggable =“false”，以防止攻击者或恶意软件轻松运行操作 .
Trace Checking - 应用程序可以确定调试器或其他调试工具当前是否正在跟踪它 . 如果被跟踪，应用程序可以执行任意数量的可能的攻击响应操作，例如丢弃加密密钥以保护用户数据，通知服务器管理员或其他此类类型的响应以试图保护自己 . 这可以通过检查进程状态标志或使用其他技术来确定，例如比较ptrace attach的返回值，检查进程列表中的父进程，黑名单调试程序或比较程序的不同位置上的时间戳 .
Optimizations - 为了隐藏高级数学计算和其他类型的复杂逻辑，利用编译器优化可以帮助对象代码，使攻击者无法轻易地对其进行反汇编，从而使攻击者更难以理解特定代码 . 在Android中，通过使用NDK本地编译的库可以更容易地实现这一点 . 此外，使用LLVM Obfuscator或任何保护程序SDK将提供更好的机器代码混淆 .
Stripping binaries - 剥离本机二进制文件是增加攻击者所需的时间和技能水平的有效方法，以便查看应用程序的低级功能 . 通过剥离二进制文件，二进制符号表被剥离，因此攻击者无法轻松调试或反向工程应用程序 . 您可以参考GNU / Linux系统上使用的技术，如sstriping或使用UPX .
And at last you must be aware about obfuscation and tools like ProGuard.
AFAIK，您无法保护/ res目录中的文件，而不是现在受到保护 .
但是，您可以采取一些步骤来保护您的源代码，或者至少可以采取哪些措施来保护您的源代码 .
使用ProGuard等工具 . 这些会使代码混淆，并且在反编译时更难以阅读，如果不是不可能的话 .
将服务的最关键部分移出应用程序，并移植到隐藏在PHP等服务器端语言后面的Web服务中 . 例如，如果您有一个算法，希望人们将其从您的应用中窃取 . 移动算法并让它处理远程服务器上的数据，并使用该应用程序简单地为其提供数据 . 或者使用NDK将它们原生地写入.so文件，这些文件比apks更不可能被反编译 . 我不像Java反编译器那样好 . 另外，正如评论中提到的@nikolay，您应该在服务器和设备之间进行交互时使用SSL .
在设备上存储值时，请重新存储用户在SharedPreferences中使用的游戏货币金额 . 让's assume it' s
10000币 . 而不是直接保存10000，使用像((currency*2)+1)/13这样的算法保存它 . 因此，不是10000，而是将1538.53846154保存到SharedPreferences中 . 但是，上面的例子不得不提出一个方程式，它不会因为舍入错误而失去货币等 .您可以为服务器端任务执行类似的操作 . 现在举个例子，让's actually take your payment processing app. Let'说用户必须支付
$200. 而不是将原始$200值发送到服务器，而是发送一系列较小的预定义值，这些值加起来为$200. 例如，在服务器上放置一个文件或表，将单词与值等同 . 所以我们假设Charlie对应$47，John对应$3. 因此，不是发送$200，而是发送Charlie四次和John四次 . 在服务器上，解释它们的含义并将其添加 . 这可以防止黑客向您的服务器发送任意值，因为他们不知道哪个词对应于什么值 . 作为安全性的附加衡量标准，您也可以使用类似于第3点的等式，并每隔n天数更改关键字 .最后，您可以在您的应用中插入随机无用的源代码，以便黑客在大海捞针中寻找针 . 从互联网插入包含片段的随机类，或者只是用于计算斐波那契序列等随机事物的函数 . 确保这些类编译，但不会被应用程序的实际功能使用 . 添加足够的这些错误类，黑客将很难找到你真正的代码 .
总而言之，没有办法100％保护您的应用程序 . 你可以让它变得更难，但并非不可能 . 您的Web服务器可能会受到攻击，黑客可以通过监控多个交易金额以及您为其发送的关键字来找出您的关键字，黑客可以煞费苦心地查看源代码并找出哪些代码是虚拟代码 .
你只能反击，但永远不会赢 .
基本上这是不可能的 . 永远不可能 . 但是，有希望 . 您可以使用obfuscator来实现它，因此一些常见的攻击很难执行，包括：
重命名方法/类（因此在反编译器中你得到像
a.a这样的类型）混淆控制流程（因此在反编译器中代码很难读取）
加密字符串和可能的资源
我是主要的 . 我在.NET混淆器上为一家名为PreEmptive Solutions的公司工作 . 他们还有一个适用于Android的Java混淆器以及一个名为DashO的混淆器 .
然而，混淆总是带来代价 . 值得注意的是，性能通常更差，并且通常需要一些额外的时间来释放 . 但是，如果您的知识产权对您来说非常重要，那么它通常是值得的 .
否则，您唯一的选择是使您的Android应用程序只是传递到托管应用程序的所有真实逻辑的服务器 . 这有其自身的问题，因为这意味着用户必须连接到Internet才能使用您的应用程序 .
此外，不只是Android有这个问题 . 这是每个应用商店的问题 . 这只是到达包文件有多困难（例如，我不相信它在iPhone上很容易，但它仍然可能） .
没有办法完全避免APK的逆向工程 . 要保护应用程序资产和资源，您可以使用加密 .
加密将更难以在没有解密的情况下使用它 . 选择一些强大的加密算法更难开裂 .
在主逻辑中添加一些欺骗代码，使破解更加困难 .
如果你能用任何母语编写关键逻辑，那肯定会让反编译变得更难 .
使用任何第三方安全框架，如Quixxi
这里的主要问题是dex文件可以被反编译，答案是它们可以是"sort of" . 有像dedexer和smali这样的反汇编程序 .
正确配置的ProGuard将对代码进行模糊处理 . DexGuard是ProGuard的商业扩展版本，可能会有所帮助 . 但是，您的代码仍然可以转换为smali，具有逆向工程经验的开发人员将能够从smali中找出您正在做的事情 .
也许选择一个好的许可证，并以最好的方式执法 .
APK signature scheme v2 in Android N
PackageManager类现在支持使用APK签名方案v2验证应用程序 . APK签名方案v2是一种全文件签名方案，通过检测对APK文件的任何未经授权的更改，显着提高了验证速度并加强了完整性保证 .
为了保持向后兼容性，在使用v2签名方案进行签名之前，必须使用v1签名方案（JAR签名方案）对APK进行签名 . 使用v2签名方案，如果在使用v2方案签名后使用其他证书对APK进行签名，则验证将失败 .
APK签名方案v2支持将在N开发者预览版中稍后提供 .
http://developer.android.com/preview/api-overview.html#apk_signature_v2
如果我们想要进行逆向工程（几乎）不可能，我们可以将应用程序放在一个高度防篡改的芯片上，该芯片在内部执行所有敏感内容，并与某些协议通信，以便在主机上实现控制GUI . 即使是防篡改芯片也不是100％防裂;他们只是设置了比软件方法更高的标准 . 当然，这是不方便的：应用程序需要一些小的USB疣，它可以将芯片插入设备中 .
这个问题没有揭示出如此嫉妒地想要保护这个应用程序的动机 .
如果目的是通过隐藏应用程序可能具有的任何安全缺陷（已知或其他方式）来提高支付方法的安全性，则完全是错误的 . 如果可行的话，安全敏感位实际上应该是开源的 . 对于审核您的应用程序的任何安全研究人员，您应该尽可能简单地找到这些位并仔细检查其操作并与您联系 . 付款应用程序不应包含任何嵌入式证书 . 也就是说，应该没有服务器应用程序信任设备只是因为它具有来自工厂的固定证书 . 应仅使用用户的凭据进行支付交易，使用正确设计的端到端身份验证协议，该协议可排除信任应用程序，平台或网络等 .
如果目的是防止克隆，缺少防篡改芯片，那么您无法做任何事情来保护程序不被反向工程和复制，因此有人将兼容的付款方式纳入他们自己的应用程序，崛起为“未经授权的客户” . 有很多方法可以使开发未经授权的客户变得困难 . 一种方法是根据程序完整状态的快照创建校验和：所有状态变量 . GUI，逻辑，等等 . 克隆程序不具有完全相同的内部状态 . 当然，它是一个状态机，具有类似的外部可见状态转换（可以通过输入和输出观察到），但几乎没有相同的内部状态 . 服务器应用程序可以询问程序：您的详细状态是什么？ （即给我一个所有内部状态变量的校验和） . 这可以与在客户端代码上并行执行的虚拟客户端代码进行比较，通过真正的状态转换 . 第三方克隆必须复制真正程序的所有相关状态更改，以便给出正确的响应，这将妨碍其开发 .
TPM芯片（可信平台模块）是不是应该为您管理受保护的代码？它们在PC（尤其是Apple）上变得越来越普遍，它们可能已经存在于今天的智能手机芯片中 . 不幸的是，还没有OS API可以使用它 . 希望Android能够为这一天增加支持 . 这也是清理内容DRM（Google正在为WebM工作）的关键 .
这里的其他upvoted答案是正确的 . 我只想提供另一种选择 .
对于您认为重要的某些功能，您可以在应用中托管WebView控件 . 然后，您的Web服务器上将实现该功能 . 它看起来像是在你的应用程序中运行 .
Tool: Using Proguard in your application it can be restricted to reverse engineering your application
您可以尝试以下几种方法：
使用obfuscation和ProGuard等工具 .
加密源和数据的某些部分 .
在应用程序中使用专有的内置校验和来检测篡改 .
引入代码以避免在调试器中加载，也就是说，让应用程序能够检测调试器并退出/终止调试器 .
将身份验证分离为在线服务 .
使用application diversity
在验证设备之前，将指纹技术用于例如来自不同子系统的设备的硬件签名 .
我建议你看看Protect Software Applications from Attacks . 它's a commercial service, but my friend'的公司使用它，他们很高兴使用它 .
将主逻辑（算法）放入服务器端 .
与服务器和客户端通信;确保通过SSL或HTTPS保护通信黑白服务器和客户端;或使用其他技术密钥对生成算法（ECC，RSA） . 确保敏感信息保持端到端加密 .
使用会话并在特定时间间隔后使其过期 .
加密资源并按需从服务器获取资源 .
Or you can make Hybrid app which access system via webview protect resource + code on server
多种方法;这显然你必须牺牲 performance 和 security
当他们在手机上安装应用程序时，他们可以完全访问它的内存 . 因此，如果你想阻止它被黑客入侵，你可以尝试使它不能直接通过使用调试器获取静态内存地址 . 如果他们有一个可以写入的地方并且有限制，他们可以执行堆栈缓冲区溢出 . 所以当他们写东西时，如果你必须有一个限制，如果他们发送更多的字符而不是限制，if（输入>限制）然后忽略，那么尝试这样做，所以他们不能把汇编代码放在那里 .
只是上面已经很好的答案的补充 .
我知道的另一个技巧是将有 Value 的代码存储为Java库 . 然后将该库设置为您的Android项目 . 作为C .so文件会好，但Android Lib会这样做 .
这样，存储在Android库中的这些有 Value 的代码在反编译后将不可见 .
我可以在这个帖子中看到这个好答案 . 除了你可以使用Facebook
redex来优化代码 . Redex适用于.dex级别，其中proguard工作为.class级别 .信息技术安全的基础是基于这三个基本原则;唯一真正安全的计算机是一个锁在保险箱内的计算机，在Farraday笼内，在钢笼内 . 有些计算机的大部分服务时间都处于这种状态;每年一次（或更少），他们为受信任的根证书颁发机构生成私钥（在一群目击者面前，摄像机记录了他们所在房间的每一寸） .
现在，大多数计算机都不在这些类型的环境下使用;他们在公开场合，通过无线电 Channels 连接到互联网 . 简而言之，它们和软件一样容易受到攻击 . 因此，他们不值得信任 . 计算机及其软件必须知道或做某些事情才能发挥作用，但必须注意确保他们永远不会知道或做足以造成损害（至少不会造成超出单一机器范围的永久性损坏） ） .
你已经知道了这一切;这就是为什么你要保护你的应用程序的代码 . 但是，这是第一个问题;混淆工具可以使代码变得混乱，人类试图挖掘，但程序仍然必须运行;这意味着应用程序的实际逻辑流程及其使用的数据不受混淆的影响 . 如果有一点韧性，攻击者就可以简单地对代码进行非混淆，而在某些情况下甚至不需要他所看到的东西除了他正在寻找的东西之外别无他法 .
相反，您应该尝试确保攻击者无法对您的代码执行任何操作，无论他获取清晰的副本是多么容易 . 这意味着，没有硬编码的秘密，因为一旦代码离开您开发它的建筑物，这些秘密就不是秘密 .
您已经硬编码的这些键值应该完全从应用程序的源代码中删除 . 相反，他们应该在三个地方之一;设备上的易失性内存，攻击者获取离线副本更难（但仍然不是不可能）的;永久地在服务器群集上，用铁拳控制访问;或者在与您的设备或服务器无关的第二个数据存储中，例如物理卡或用户的存储器（意味着它最终将存在于易失性存储器中，但它不必长时间存在） .
考虑以下方案 . 用户将应用程序的凭据从内存输入设备 . 遗憾的是，您必须相信用户的设备尚未受到键盘记录程序或特洛伊木马的攻击;在这方面你能做的最好的事情是通过记住关于用户使用的设备（MAC / IP，IMEI等）的难以辨认的识别信息，并通过以下方式提供至少一个附加信道来实现多因素安全性 . 可以验证对不熟悉设备的登录尝试 .
一旦输入，凭证就会被客户端软件（使用安全散列）进行模糊处理，并丢弃纯文本凭证;他们达到了目的 . 模糊的凭证通过安全通道发送到经过证书认证的服务器，再次对其进行哈希处理，以生成用于验证登录有效性的数据 . 这样，客户端永远不知道实际上与数据库值相比的是什么，应用服务器永远不会知道它接收到的验证背后的明文凭证，数据服务器永远不知道它为验证存储的数据是如何生成的，并且是一个人即使安全渠道受到损害，中间人也只会看到胡言乱语 .
一旦验证，服务器就通过信道发送回令牌 . 令牌仅在安全会话中有用，由随机噪声或会话标识符的加密（因此可验证）副本组成，并且客户端应用程序必须在同一通道上将此令牌作为任何请求的一部分发送到服务器做某事 . 客户端应用程序将多次执行此操作，因为它无法执行任何涉及金钱，敏感数据或任何其他可能会造成损害的事情;它必须要求服务器执行此任务 . 客户端应用程序永远不会将任何敏感信息写入设备本身的持久性内存，至少不能以纯文本形式写入;客户端可以通过安全通道向服务器请求对称密钥来加密服务器将记住的任何本地数据;在以后的会话中，客户端可以向服务器请求相同的密钥来解密数据以便在易失性存储器中使用 . 这些数据也不是唯一的副本;客户端存储的任何内容也应以某种形式传输到服务器 .
显然，这使您的应用程序严重依赖于Internet访问;如果没有与服务器正确连接和认证，客户端设备将无法执行任何基本功能 . 与Facebook没什么不同，真的 .
现在，攻击者想要的计算机是你的服务器，因为它而不是客户端应用程序/设备是可以让他赚钱或让别人痛苦的东西 . 没关系;为了保证服务器安全而不是试图保护所有客户端，你可以获得更多的收益 . 服务器可以支持所有类型的防火墙和其他电子安全设备，此外还可以在钢铁，混凝土，钥匙卡/插针访问和24小时视频监控背后进行物理保护 . 您的攻击者确实需要非常复杂才能直接获得对服务器的任何访问，您应该（应该）立即了解它 .
攻击者可以做的最好的事情就是窃取用户的电话和凭据，并使用客户端的有限权限登录服务器 . 如果发生这种情况，就像丢失信用卡一样，应该指示合法用户拨打800号码（最好是容易记住，而不是在他们的钱包，钱包或公文包中随身携带的卡片背面）他们可以访问任何直接连接到您的客户服务的手机，与移动设备一起被盗 . 他们说他们的手机被盗，提供一些基本的唯一标识符，并且帐户被锁定，攻击者可能已经处理的任何事务都被回滚，攻击者又回到原点 .
开发人员可以采取以下措施防止APK以某种方式被盗，
最基本的方法是使用像
ProGuard这样的工具来混淆他们的代码，但到目前为止，完全阻止某人反编译应用程序是相当困难的 .我也听说过一个工具HoseDex2Jar . 它通过在Android APK中插入无害代码来停止
Dex2Jar，该APK会混淆和禁用Dex2Jar并保护代码免受反编译 . 它可以某种方式防止黑客将APK反编译成可读的Java代码 .使用某些服务器端应用程序仅在需要时与应用程序通信 . 它可以帮助防止重要数据 .
完全不能完全保护您的代码免受潜在的黑客攻击 . 不知何故，你可能会让它变得困难而且有点困难让他们反编译代码的令人沮丧的任务 . 最有效的方法之一是用本机代码（C / C）编写并将其存储为编译库 .
虽然我同意's no 100% solution that'将保护你的代码，但如果你想尝试一下，HoseDex2Jar的v3现在已经启动了 .
That is impossible
Developers can take steps such as using tools like ProGuard to obfuscate their code, but up until now, it has been quite difficult to completely prevent someone from decompiling an app.
它是一个非常好的工具，可以增加“反转”代码的难度，同时缩小代码的占用空间 .
集成的ProGuard支持：ProGuard现在与SDK工具一起打包 . 开发人员现在可以将其代码混淆为发布版本的集成部分 .
在研究的过程中，我开始了解HoseDex2Jar . 此工具将保护您的代码免受反编译，但似乎无法完全保护您的代码 .
一些有用的链接，你可以参考它们 .
Proguard, Android, and the Licensing Server
Securing Android LVL Applications
Stack Overflow问题Is it really impossible to protect Android apps from reverse engineering?
Stack Overflow问题How to prevent reverse engineering of an Android APK file to secure code?
您的客户应该聘请知道自己在做什么的人，谁可以做出正确的决定并指导您 .
上面谈到你有能力改变后端的事务处理系统是荒谬的 - 你不应该被允许进行这样的体系结构更改，所以不要指望能够 .
我的理由是：
由于您的域名是付款处理，因此可以安全地假设PCI DSS和/或PA DSS（以及潜在的州/联邦法律）对您的业务非常重要 - 为了符合您的要求您必须证明您是安全的 . 为了不安全，然后找出（通过测试）你不安全，然后修复，重新测试，等等，直到安全性可以在合适的水平上验证=昂贵，缓慢，高风险的成功方式 . 做正确的事情，提前思考，让有经验的人才投入工作，以安全的方式发展，然后测试，修复（减少）等等（直到安全性可以在合适的水平上进行验证）=便宜，快速，低风险的成功之道 .
This isn't possible
当有人将.apk扩展名更改为.zip时，解压缩后，有人可以轻松获取所有资源（Manifest.xml除外），但使用 APKtool 可以获得清单文件的真实内容 . 再一次，没有 .
再一次，不，但你可以防止达到某种程度，即
从Web下载资源并执行一些加密过程
使用预编译的本机库（C，C，JNI，NDK）
始终执行一些散列（MD5 / SHA键或任何其他逻辑）
即使使用
Smali，人们也可以使用您的代码 . 总而言之，这不可能 .