How to avoid reverse engineering of an APK file?
我正在为Android开发一个支付处理应用程序，我想防止黑客从APK文件访问任何资源、资产或源代码。
如果有人将.APK扩展名改为.zip，那么他们可以解压缩它并轻松访问所有应用程序的资源和资产，并且使用DeX2JAR和Java反编译程序，它们也可以访问源代码。对android apk文件进行反向工程非常容易——有关更多详细信息，请参阅从apk文件到项目的堆栈溢出问题反向工程。
我使用了Android SDK提供的Proguard工具。当我反向工程使用签名的密钥库和proguard生成的APK文件时，我得到了模糊的代码。
但是，Android组件的名称保持不变，一些代码(如应用程序中使用的键值)保持不变。根据Proguard文档，该工具无法混淆清单文件中提到的组件。
现在我的问题是：
1. How can I completely avoid reverse engineering of an Android APK? Is this possible?
阿法克，没有任何技巧可以完全避免逆向工程。
@inazaruk也很好地说：无论你对代码做什么，潜在的攻击者都可以以任何方式更改它，她或他认为这是可行的。您基本上无法保护您的应用程序不被修改。你放在那里的任何保护都可以被禁用/移除。
2. How can I protect all the app's resources, assets and source code so that hackers can't hack the APK file in any way?
不过，您可以使用不同的技巧来提高黑客攻击的难度。例如，使用混淆(如果它是Java代码)。这通常会显著降低逆向工程的速度。
3. Is there a way to make hacking more tough or even impossible? What more can I do to protect the source code in my APK file?
正如每个人所说，正如你可能知道的，没有100%的安全保障。但是谷歌内置的安卓系统的起点是Proguard。如果您有选择共享库的选项，您可以在C++中包含需要的代码来验证文件大小、集成、等等。如果您需要在每次构建时将外部本机库添加到APK的库文件夹中，然后你可以通过下面的建议来使用它。
将库放在本机库路径中，该路径默认为您的项目文件夹。如果您为"armeabi"目标构建了本机代码，那么将其在libs/armeabi下。如果它是用ARMEABI-V7A建造的，那么把它放在libs/armeabi-v7a。
1 | <project>/libs/armeabi/libstuff.so |
afaik，您不能再保护/res目录中的文件，因为它们现在受到保护。
但是，您可以采取一些步骤来保护源代码，或者至少保护它的功能(如果不是全部)。
总之，没有办法100%保护你的应用程序。你可以让它更难，但并非不可能。你的网络服务器可能会受到威胁，黑客可以通过监控多个交易量和你发送给它的关键字来找出你的关键字，黑客可以费心地浏览源代码，找出哪个代码是虚拟的。
你只能反击，但永远不会赢。
在计算历史的任何时候，当你把软件的工作副本给攻击者时，都不可能阻止软件的逆向工程。而且，在大多数情况下，这是不可能的。
明白了这一点，有一个显而易见的解决方案：不要把你的秘密告诉攻击者。虽然你不能保护你的APK的内容，但是你可以保护的是你没有分发的任何东西。通常这是服务器端的软件，用于诸如激活、支付、规则执行和其他多汁的代码。您可以通过不在APK中分配来保护宝贵的资产。相反，设置一个服务器来响应来自应用程序的请求，"使用"资产(不管这意味着什么)，然后将结果发送回应用程序。如果这个模型不适用于您所考虑的资产，那么您可能需要重新考虑您的策略。
此外，如果你的主要目标是防止应用程序盗版：甚至不用麻烦。在这个问题上，你花费的时间和金钱已经超过了任何反盗版措施都有可能拯救你。解决这个问题的投资回报是如此之低，以至于想都没有意义。
First rule of app security: Any machine to which an attacker gains unrestricted physical or electronic access now belongs to your attacker, regardless of where it actually is or what you paid for it.
Ok.
Second rule of app security: Any software that leaves the physical boundaries inside which an attacker cannot penetrate now belongs to your attacker, regardless of how much time you spent coding it.
Ok.
Third rule: Any information that leaves those same physical boundaries that an attacker cannot penetrate now belongs to your attacker, no matter how valuable it is to you.
Ok.
信息技术安全的基础基于这三个基本原则；唯一真正安全的计算机是锁在保险箱、法拉第笼、钢笼中的计算机。有些计算机的大部分使用寿命都是在这种状态下度过的；每年(或更少)一次，它们为受信任的根证书颁发机构生成私钥(在大量目击证人面前，摄像机记录他们所在房间的每一英寸)。好的。
现在，大多数计算机不在这些类型的环境中使用；它们在物理上是开放的，通过无线广播频道连接到互联网。简而言之，他们和他们的软件一样容易受到攻击。因此，它们是不可信的。为了有用，计算机及其软件必须知道或做某些事情，但必须注意确保它们永远不会知道或做得足够造成损坏(至少不是单台机器界限之外的永久性损坏)。好的。
您已经知道了所有这些；这就是您试图保护应用程序代码的原因。但是，这是第一个问题；模糊工具可能会让代码变得一团糟，让人难以理解，但程序仍然必须运行；这意味着应用程序的实际逻辑流及其使用的数据不受模糊的影响。只要有一点韧性，攻击者就可以简单地解开代码，在某些情况下，这甚至不是必需的，因为在某些情况下，他所看到的不能是他所寻找的。好的。
相反，您应该尝试确保攻击者不能对您的代码做任何事情，无论他获取代码的清晰副本有多么容易。这意味着，没有硬编码的秘密，因为一旦代码离开开发它的大楼，这些秘密就不是秘密了。好的。
这些硬编码的键值应该完全从应用程序的源代码中删除。相反，它们应该位于三个位置中的一个；设备上的易失性内存，攻击者很难(但仍然不可能)获得的脱机副本；永久位于服务器群集上，您可以用铁拳控制对其的访问；或者位于与设备或服务器无关的第二个数据存储区，如物理卡或U中。SER的记忆(意味着它最终会在易失性记忆中，但不需要很长时间)。好的。
考虑以下方案。用户将应用程序的凭据从内存输入设备。不幸的是，您必须相信用户的设备没有受到键盘记录器或特洛伊木马程序的影响；在这方面，您可以做的最好的是实现多因素安全性，记住用户使用的设备的难以伪造的识别信息(MAC/IP、IMEI等)，并提供至少一个额外的通道，通过该通道，可以使用户的设备在一个不熟悉的设备上的GIN尝试可以被验证。好的。
输入凭据后，客户端软件(使用安全散列)会混淆这些凭据，并丢弃纯文本凭据；它们已经达到了它们的目的。模糊的凭证通过安全通道发送到经过证书身份验证的服务器，该服务器再次对它们进行散列，以生成用于验证登录有效性的数据。这样，客户机就永远不知道与数据库值相比实际值是多少，应用服务器永远不知道它接收到的用于验证的明文凭据，数据服务器永远不知道它存储用于验证的数据是如何生成的，中间的人即使安全通道受到破坏，也只会看到乱七八糟的信息。好的。
一旦验证，服务器就通过通道发送回令牌。令牌仅在安全会话中有用，由随机噪声或会话标识符的加密(因而可验证)副本组成，并且客户端应用程序必须在同一个通道上将此令牌作为执行某项操作的任何请求的一部分发送到服务器。客户机应用程序将多次执行此操作，因为它不能执行任何涉及金钱、敏感数据或任何其他可能对自身造成损害的操作；它必须要求服务器执行此任务。客户机应用程序永远不会将任何敏感信息写入设备本身的持久内存，至少不会以明文形式；客户机可以通过安全通道向服务器请求对称密钥来加密服务器将记住的任何本地数据；在以后的会话中，客户机可以向服务器请求相同的密钥来解密用于易失性存储器的数据。这些数据也不是唯一的副本；客户机存储的任何内容都应该以某种形式传输到服务器。好的。
显然，这使您的应用程序严重依赖于Internet访问；如果没有与服务器的正确连接和身份验证，客户机设备将无法执行其任何基本功能。真的和Facebook没什么不同。好的。
现在，攻击者想要的计算机是你的服务器，因为它而不是客户端应用程序/设备是可以让他赚钱或让其他人为他的享受而痛苦的东西。这没关系；比起试图保护所有客户机，花费金钱和努力保护服务器会让您的开销更大。服务器可以位于各种防火墙和其他电子安全之后，此外还可以在钢铁、混凝土、钥匙卡/密码访问和24小时视频监控之后进行物理安全保护。您的攻击者需要非常复杂，才能直接访问服务器，您应该立即知道这一点。好的。
攻击者能做的最好的事情就是窃取用户的电话和凭证，并以客户机的有限权限登录到服务器。如果发生这种情况，就像丢失信用卡一样，合法用户应该被指示从他们可以直接连接到您的客户的任何电话拨打800号码(最好是易于记忆的，而不是在他们钱包、钱包或公文包中的卡背面，因为这些卡可能在移动设备旁边被盗)。R服务。他们声明他们的电话被偷了，提供了一些基本的唯一标识符，并且帐户被锁定，攻击者可能已经能够处理的任何事务都将被回滚，并且攻击者将恢复到正常状态。好的。好啊。
1. How can I completely avoid reverse engineering of an Android APK? Is this possible?
这不可能
2. How can I protect all the app's resources, assets and source code so that hackers can't hack the APK file in any way?
当有人将.apk扩展名更改为.zip，然后解压后，有人可以轻松地获取所有资源(manifest.xml除外)，但使用apktool，也可以获取清单文件的真实内容。再一次，没有。
3. Is there a way to make hacking more tough or even impossible? What more can I do to protect the source code in my APK file?
再说一次，不，但是你可以在某种程度上阻止，也就是说，
- 从Web下载资源并执行一些加密过程
- 使用预编译的本地库(C，C++，JNI，NDK)
- 总是执行一些散列(MD5/SHA键或任何其他逻辑)
即使使用
100%避免对Android APK进行反向工程是不可能的，但您可以使用这些方法来避免提取更多的数据，如源代码、来自APK的资产和资源：
使用proguard混淆应用程序代码
使用NDK使用C和C++把你的应用程序核心和安全部分代码放在EDCOX1×3文件中
要保护资源，请不要将所有重要资源包括在带有APK的资产文件夹中。在应用程序首次启动时下载这些资源。
开发人员可以采取以下步骤，以某种方式防止APK被盗，
最基本的方法是使用像
ProGuard 这样的工具来混淆他们的代码，但到目前为止，完全阻止某人反编译应用程序已经相当困难了。我也听说过一个工具hosedex2jar。它通过在android apk中插入无害的代码来阻止
Dex2Jar ，这会混淆并禁用Dex2Jar ，并保护代码不被反编译。它可以阻止黑客将APK分解成可读的Java代码。仅在需要时使用服务器端应用程序与应用程序通信。它可以帮助防止重要的数据。
总之，您不能完全保护您的代码免受潜在黑客的攻击。不知怎么的，你可能会让他们很难和有点沮丧的任务来反编译你的代码。最有效的方法之一是编写本地代码(C/C++)，并将其存储为编译库。
1. How can I completely avoid reverse engineering of an Android APK? Is this possible?
不可能的
2. How can I protect all the app's resources, assets and source code so that hackers can't hack the APK file in any way?
不可能的
3. Is there a way to make hacking more tough or even impossible? What more can I do to protect the source code in my APK file?
更难-可能，但事实上，这将更难-主要是对普通用户，谁只是谷歌黑客指南。如果有人真的想破解你的应用程序——它迟早会被破解。
1. How can I completely avoid reverse engineering of an Android APK? Is this possible?
那是不可能的
2. How can I protect all the app's resources, assets and source code so that hackers can't hack the APK file in any way?
开发人员可以采取一些步骤，例如使用proguard之类的工具来模糊代码，但到目前为止，完全阻止某人对应用程序进行反编译是相当困难的。
这是一个非常好的工具，可以增加"反转"代码的难度，同时减少代码的占用空间。
集成的Proguard支持：Proguard现在与SDK工具打包在一起。开发人员现在可以将其代码作为发布构建的一个集成部分而混淆。
3. Is there a way to make hacking more tough or even impossible? What more can I do to protect the source code in my APK file?
在调查的时候，我开始了解hosedex2jar。此工具将保护您的代码不被反编译，但似乎不可能完全保护您的代码。
一些有用的链接，您可以参考它们。
- Proguard、Android和许可服务器
- 保护Android LVL应用程序
- 堆栈溢出问题是否真的不可能保护Android应用程序不受反向工程的影响？
- 堆栈溢出问题如何防止反工程的安卓APK文件的安全代码？
这里的主要问题是DEX文件是否可以被反编译，答案是它们可以是"某种类型"。有像DedExer和Smali这样的拆卸器。
正确配置的proguard将混淆您的代码。DexGuard是Proguard的商业扩展版本，可能会有更多帮助。但是，您的代码仍然可以转换为smali，具有逆向工程经验的开发人员将能够从smali中了解您正在做什么。
也许可以选择一个好的许可证，并以最好的方式通过法律加以实施。
您可以尝试以下几种方法：
你的客户应该雇佣一个知道他们在做什么的人，他可以做出正确的决定，并且可以指导你。
上面所说的您有一些能力更改后端的事务处理系统是荒谬的-不应该允许您进行这样的体系结构更改，所以不要期望能够进行这样的更改。
我的理由是：
由于您的域是支付处理，因此可以安全地假设PCI DSS和/或PA DSS(以及潜在的州/联邦法律)对您的业务具有重要意义-要符合要求，您必须证明自己是安全的。为了不安全，然后发现(通过测试)您不安全，然后修复、重新测试等，直到在适当的级别上验证安全性=昂贵、缓慢、高风险的成功方法。为了做正确的事情，要提前认真考虑，把有经验的人才投入到工作中，以安全的方式发展，然后测试、修复(更少)，等等，直到在适当的水平上验证安全性=廉价、快速、低风险的成功方式。
这里的另一个赞成的答案是正确的。我只想提供另一个选择。
对于您认为重要的某些功能，您可以在应用程序中托管WebView控件。然后，该功能将在您的Web服务器上实现。它看起来像是在应用程序中运行。
如果我们想使逆向工程(几乎)不可能，我们可以将应用程序放在一个高度抗篡改的芯片上，该芯片在内部执行所有敏感的东西，并与一些协议进行通信，以使控制GUI在主机上成为可能。即使是防篡改的芯片也不是100%防裂的；它们只是把标准设置得比软件方法高得多。当然，这是不方便的：应用程序需要一些小的USB疣，它可以将芯片插入设备。
这个问题并没有揭示出想要如此嫉妒地保护这个应用程序的动机。
如果目的是通过隐藏应用程序可能存在的任何安全缺陷(已知或其他)来提高支付方法的安全性，则完全错误。如果可行的话，安全敏感位实际上应该是开源的。您应该尽可能地让任何审查您的应用程序的安全研究员找到这些位并检查它们的操作，并与您联系。付款申请不应包含任何嵌入的证书。也就是说，不应该有任何服务器应用程序仅仅因为设备具有来自工厂的固定证书而信任设备。支付交易应仅在用户凭证上进行，使用正确设计的端到端认证协议，以避免信任应用程序、平台或网络等。
如果目的是防止克隆，除了防篡改芯片，没有任何措施可以保护程序不被反向工程和复制，因此有人将兼容的支付方式纳入自己的应用程序，从而导致"未经授权的客户"。有一些方法使开发未经授权的客户变得困难。一种方法是基于程序完整状态的快照创建校验和：所有状态变量，所有内容。图形用户界面，逻辑，随便什么。克隆程序将不具有完全相同的内部状态。当然，它是一个状态机，具有相似的外部可见状态转换(可以通过输入和输出观察到)，但几乎没有相同的内部状态。服务器应用程序可以询问程序：您的详细状态是什么？(也就是说，给我一个关于所有内部状态变量的校验和)。这可以与在服务器上并行执行、经过真正状态转换的虚拟客户机代码进行比较。第三方克隆必须复制真正程序的所有相关状态更改，以便给出正确的响应，这将妨碍其开发。
作为在支付平台上广泛工作的人，包括一个移动支付应用程序(mycheck)，我认为你需要将这种行为委托给服务器，支付处理器的用户名或密码(无论是哪个)不应该存储或硬编码在移动应用程序中，这是你最不想要的，因为即使混淆了代码，也可以理解source。
此外，您不应该在应用程序上存储信用卡或支付令牌，一切都应该，再次，委托给您建立的服务，它也将允许您稍后，更容易遵守PCI，信用卡公司不会呼吸你的脖子(就像他们为我们做的)。
我建议您考虑保护软件应用程序免受攻击。这是一项商业服务，但我朋友的公司使用了它，他们很高兴使用它。
安卓N中的APK签名方案v2
PackageManager类现在支持使用APK签名方案v2验证应用程序。APK签名方案v2是一个完整的文件签名方案，通过检测对APK文件的任何未经授权的更改，显著提高了验证速度并增强了完整性保证。
为了保持向后兼容性，在使用v2签名方案签名之前，必须使用v1签名方案(jar签名方案)对apk进行签名。使用v2签名方案时，如果在使用v2方案签名后使用附加证书对apk进行签名，则验证将失败。
稍后将在N开发者预览中提供APK签名方案v2支持。
http://developer.android.com/preview/api overview.html_apk_signature_v2
与@muhammad saqib达成一致：https://stackoverflow.com/a/46183706/2496464
而且@mumair提供了一个良好的启动步骤：https://stackoverflow.com/a/35411378/474330
假设您分发给用户设备的所有内容都属于用户，这是安全的。简单明了。你也许可以使用最新的工具和程序来加密你的知识产权，但是没有办法阻止一个有决心的人"研究"你的系统。即使当前的技术可能使他们很难获得不需要的访问，明天甚至下个小时可能会有一些简单的方法！
因此，方程式如下：
1 | When it comes to money, we always assume that client is untrusted. |
即使是在游戏经济中。(尤其是在游戏中！那里有更多"成熟"的用户，漏洞在几秒钟内就扩散了！)
我们如何保持安全？
大多数(如果不是全部)我们的关键处理系统(当然还有数据库)都位于服务器端。在客户机和服务器之间，存在加密通信、验证等，这就是瘦客户机的概念。
没有办法完全避免APK的逆向工程。为了保护应用程序资产和资源，可以使用加密。
- 如果不解密，加密将使其难以使用。选择一些强加密算法将使破解更加困难。
- 在您的主逻辑中添加一些欺骗代码以使破解更加困难。
- 如果你能用任何一种本地语言编写你的关键逻辑，那肯定会使反编译变得更加困难。
- 使用任何第三方安全框架，如quixxi
完全避免RE是不可能的，但是通过在内部使其更复杂，您使攻击者更难看到应用程序的清晰操作，这可能会减少攻击向量的数量。
如果应用程序处理高度敏感的数据，则存在各种技术，这会增加逆向工程代码的复杂性。一种技术是使用C/C++来限制攻击者的简单运行时操作。有足够的C和C++库，它们非常成熟，易于与Android集成，提供JNI。攻击者必须首先绕过调试限制，以便在较低级别上攻击应用程序。这使攻击更加复杂。Android应用程序应该在应用程序清单中设置android:debuggable="false"，以防止攻击者或恶意软件轻松操作运行时。
跟踪检查-应用程序可以确定它当前是否由调试器或其他调试工具跟踪。如果被跟踪，应用程序可以执行任意数量的可能的攻击响应操作，例如丢弃加密密钥以保护用户数据、通知服务器管理员或其他此类类型的响应以试图进行自卫。这可以通过检查进程状态标志或使用其他技术来确定，例如比较ptrace attach的返回值、检查父进程、进程列表中的黑名单调试器或比较程序不同位置上的时间戳。
优化-为了隐藏高级数学计算和其他类型的复杂逻辑，利用编译器优化可以帮助混淆对象代码，使其不容易被攻击者分解，使攻击者更难理解特定代码。在android中，这可以通过使用本地编译的带有ndk的库更容易实现。此外，使用LLVM模糊器或任何保护器SDK将提供更好的机器代码模糊。
剥离二进制文件–剥离本机二进制文件是一种有效的方法，可以增加攻击者所需的时间和技能水平，以便查看应用程序低级别功能的组成。通过剥离二进制文件，可以剥离二进制文件的符号表，这样攻击者就无法轻松地调试或反向工程应用程序。您可以参考GNU/Linux系统上使用的技术，如sstripping或upx。
最后，您必须了解模糊和Proguard等工具。
基本上是不可能的。这是不可能的。然而，还是有希望的。您可以使用模糊器来进行攻击，因此一些常见的攻击很难执行，包括：
我相信还有其他的，但那是主要的。我在一家名为.NET模糊器抢占解决方案的公司工作。他们还有一个Java的混淆器，用于Android，也叫做DASHO。
不过，混淆总是有代价的。值得注意的是，性能通常会更差，而且通常需要一些额外的发布时间。然而，如果你的知识产权对你来说非常重要，那么它通常是值得的。
否则，您唯一的选择就是让您的Android应用程序通过一个服务器，该服务器承载您应用程序的所有实际逻辑。这有其自身的问题，因为这意味着用户必须连接到互联网才能使用你的应用程序。
而且，不仅仅是Android有这个问题。这在每个应用商店都是个问题。这只是一个很难找到软件包文件的问题(例如，我不认为在iPhone上很容易，但它仍然是可能的)。
Nothing is secure when you put it on end-users hand but some common practice may make this harder for attacker to steal data.
- 把你的主要逻辑(算法)放到服务器端。
- 与服务器和客户机通信；确保通过SSL或HTTPS保护服务器和客户机的通信；或使用其他技术密钥对生成算法(ECC、RSA)。确保敏感信息始终是端到端加密的。
- 使用会话，并在特定时间间隔后过期。
- 加密资源并根据需要从服务器获取它们。
- 也可以通过
webview 制作混合应用程序，在服务器上保护资源+代码。
多种方法；很明显，您必须在性能和安全性之间做出牺牲
TPM芯片(可信平台模块)不应该为您管理受保护的代码吗？它们在个人电脑(尤其是苹果电脑)上越来越普遍，并且可能已经存在于今天的智能手机芯片中。不幸的是，目前还没有可供使用的操作系统API。希望有一天Android会为这一点增加支持。这也是清洁内容DRM(Google正在为WebM开发)的关键。
How can I protect all the app's resources, assets and source code so that hackers can't hack the APK file in any way?
APK文件受SHA-1算法保护。您可以在APK的META-INF文件夹中看到一些文件。如果您提取任何APK文件并更改其任何内容，然后再次对其进行压缩，并且当您在Android机器上运行新的APK文件时，它将无法工作，因为SHA-1哈希永远不会匹配。
如果你的应用程序如此敏感，那么你应该考虑服务器端的支付处理部分。尝试更改您的付款处理算法。仅使用Android应用程序来收集和显示用户信息(即账户余额)，而不是在Java代码中处理支付，将该任务发送到使用加密参数的安全SSL协议的服务器。创建完全加密和安全的API以与服务器通信。
当然，它也可以被黑客攻击，这与源代码保护无关，但考虑到它是另一个安全层，使黑客更难欺骗你的应用程序。
虽然我同意没有100%的解决方案可以保护您的代码，但是如果您想尝试一下，hosedex2jar的v3现在已经启动了。
当他们手机上有这个应用程序时，他们就可以完全访问它的内存。因此，如果你想防止它被黑客入侵，你可以尝试使它，这样你就不能直接使用调试器获得静态内存地址。如果它们有地方可写并且有限制，那么它们可以进行堆栈缓冲区溢出。所以当他们写东西的时候，如果你必须有一个限制，如果他们发送的字符多于限制，如果(输入>限制)，那么忽略，所以他们不能把汇编代码放在那里。
我可以从这条线索中看到那个好答案。此外，您还可以使用facebook
工具：在您的应用程序中使用proguard，它可以限制为反向工程您的应用程序。
只是上面已经很好的答案的一个补充。
我知道的另一个诀窍是把有价值的代码存储为Java库。然后将该库设置为您的Android项目。和c.so文件一样好，但android lib可以。
这样，这些存储在Android库中的宝贵代码在反编译后就不可见了。
基本上，有5种方法可以保护您的APK。隔离Java程序，加密类文件，转换为本地代码，代码混淆和在线加密我建议你使用在线加密，因为它是安全和方便的。你不必花太多时间来实现这一点。如apk protect，它是apk的在线加密网站。它提供Java代码和C++代码保护，以实现反调试和反编译的效果。操作过程简单易行。
I am developing a payment processing app
谷歌已经非常成功地通过使用一种简单的金融方法来"保护"谷歌Chrome来避免恶意黑客，我引用：
We have a standing $50,000 reward for participants that can compromise a Chromebook or Chromebox with device persistence in guest mode
你最好的选择是为你的钱的价值选择正确的战斗，以接近100%的"安全"。
现在，这不会保护你免受疯子和幸运的恶作剧者的伤害，但是…当系统重新调整时，后一组只享受很少的时间。当一个疯子是你只需要担心的事情，以防你大到有一个复仇者。那将是一个伟大的故事！：)
投资Ai。识别货币流动模式以预测潜在风险比试图防止货币泄漏更"安全"。
我尝试在我的"博客"中写更多关于以上所有内容的文章，比如为什么我要在引号中加上"安全"和"保护"(它们实际上是什么意思？).
换句话说，与其问"如何避免逆向工程"，不如问"如何设计防弹付款处理应用程序"。
最后，作为一个处理应用程序，你不应该忽视你认为你可以在二进制代码中创建的任何虚假安全。而要担心你的服务器。例如，制定一个严格的通信协议，使监视服务器变得更容易。现在这是可靠的了！