如何避免反向工程的APK文件？
我正在开发Android的付款处理应用程序 ，我想阻止黑客访问APK文件中的任何资源，资产或源代码。
如果有人将.apk扩展名更改为.zip，那么他们可以将其解压缩并轻松访问所有应用程序的资源和资产，并使用dex2jar和Java反编译器，还可以访问源代码。 这是一个非常简单的反向工程Android APK文件 – 欲了解更多信息，请参阅堆栈溢出问题反向工程从APK文件到项目 。
我已经使用了Android SDK提供的Proguard工具。 当我使用签名的密钥库和Proguard对生成的APK文件进行逆向工程时，我得到了混淆的代码。 但是，Android组件的名称保持不变，某些代码（如应用程序中使用的键值）保持不变。 根据Proguard文档，该工具不能混淆清单文件中提到的组件。
现在我的问题是：
- 我怎样才能完全避免 Android APK的逆向工程？ 这可能吗？
- 我怎样才能保护所有的应用程序的资源，资产和源代码，使黑客无法以任何方式破解APK文件？
- 有没有办法使黑客更加困难，甚至不可能？ 我还能做些什么来保护我的APK文件中的源代码？
1.如何完全避免Android APK的逆向工程？ 这可能吗？
AFAIK，完全避免逆向工程没有任何窍门。
而且@inazaruk也说得很对： 无论你对代码做什么，潜在的攻击者都可以以任何可能的方式改变它 。 你基本上不能保护你的应用程序不被修改。 而且你放在那里的任何保护都可以禁用/删除。
2.我如何保护所有应用程序的资源，资产和源代码，使黑客无法以任何方式破解APK文件？
你可以做不同的技巧，使黑客更难。 例如，使用混淆（如果它是Java代码）。 这通常会显着减缓逆向工程。
3.是否有办法使黑客更加困难甚至不可能？ 我还能做些什么来保护我的APK文件中的源代码？
正如大家所说，也许你知道，没有100％的安全。 但是，Google已经build立起来的Android平台是ProGuard。 如果您可以select包含共享库 ，那么您可以在C ++中包含所需的代码来validation文件大小，集成等。如果您需要在每个构build中将外部本机库添加到APK的库文件夹，则可以使用它由下面的build议。
将库放在默认为项目文件夹中的“libs”的本机库path中。 如果您为“armeabi”目标构build本机代码，则将其放在libs / armeabi下 。 如果它是用armeabi-v7a构build的，那么把它放在libs / armeabi-v7a下。
<project>/libs/armeabi/libstuff.so AFAIK，你不能保护/ res目录中的文件，而不是保护它们。
但是，您可以采取一些措施来保护您的源代码，或者至less如果不是所有的事情都可以采取措施。
- 使用ProGuard之类的工具。 这些会混淆你的代码，反编译时难以阅读，如果不是不可能的话。
- 把服务中最关键的部分从应用程序中移出，然后放到一个web服务中，隐藏在像PHP这样的服务器端语言之后。 例如，如果你有一个algorithm，你花了一百万美元来写。 你显然不希望有人偷你的应用程序。 移动algorithm，让它在远程服务器上处理数据，并使用应用程序简单地提供数据。 或者使用NDK将它们本地写入到.so文件中，这些文件比反编译的可能性要小得多。 我不认为.so文件的反编译器现在甚至还存在（即使这样做，也不会像Java反编译器那样好）。 另外，正如评论中提到的@nikolay，你应该在服务器和设备之间进行交互时使用SSL。
- 在设备上存储值时，不要以原始格式存储它们。 例如，如果您有一个游戏，并且您正在SharedPreferences中存储用户所拥有的游戏货币数量。 我们假设它是
10000硬币。 （而不是直接保存10000，请使用((currency*2)+1)/13等algorithm进行保存。 因此，而不是10000，您保存1538.53846154到SharedPreferences中。 然而，上面的例子并不完美，你必须努力想出一个方程，不会失去舍去错误等的货币。 - 您可以为服务器端任务做类似的事情。 现在举一个例子，让我们来看看您的付款处理应用程序。 假设用户必须支付
$200。 而不是发送一个原始的$200价值的服务器，发送一系列较小，预定义的价值，加起来$200。 例如，在您的服务器上有一个文件或表格，将文字与值相等。 那么让我们说Charlie对应$47，John对$3。 所以，不要发送$200，你可以发四次Charlie和John四次。 在服务器上，解释他们的意思，并把它加起来。 这可以防止黑客发送任意值到你的服务器，因为他们不知道什么字对应什么值。 作为安全措施的附加措施，您也可以有类似于第3点的公式，并每n天更改一次关键字。 - 最后，你可以插入随机无用的源代码到你的应用程序，以便黑客在干草堆中寻找针。 从互联网插入包含摘录的随机类，或者只是计算随机事件的函数，如斐波那契数列。 确保这些类被编译，但不被应用程序的实际function使用。 添加足够的这些错误的类，黑客会很难find你真正的代码。
总而言之，没有办法保护你的应用程序100％。 你可以让它更难，但不是不可能的。 您的networking服务器可能会受到攻击，黑客可以通过监控多个交易金额和您发送的关键字来计算出您的关键字，黑客可以通过源代码精心查找哪个代码是虚拟的。
你只能反击，但永远不会赢。
在计算的历史中，从来没有人可能在向攻击者提供工作副本时防止对软件进行逆向工程。 而且，大多数情况下， 这是不可能的 。
据了解，有一个明显的解决办法： 不要把你的秘密给你的攻击者。 虽然您无法保护APK的内容，但是您可以保护的是您不分发的任何内容。 通常这是服务器端软件，用于激活，支付，规则执行和其他多汁的代码。 您可以通过不在 APK中分发这些资源来保护有价值的资产。 相反，build立一个响应来自你的应用程序请求的服务器，“使用”资产（不pipe这可能意味着什么），然后将结果发送回应用程序。 如果这种模式不适用于您所考虑的资产，那么您可能需要重新考虑您的策略。
此外， 如果您的主要目标是防止应用程序盗版 ：甚至不打扰。 你们已经在这个问题上花费了更多的时间和金钱，而不是任何反盗版措施都可能希望拯救你。 解决这个问题的投资回报如此之低，甚至连想都没有意义。
应用程序安全性的第一条规则：攻击者获得无限制的物理或电子访问的任何机器现在属于您的攻击者，而不pipe其实际位置在哪里，或者您付了什么。
应用程序安全的第二条规则：无论您花费多less时间对代码进行编码，任何使攻击者无法穿透的物理边界的软件都属于您的攻击者。
第三条规则：任何留下攻击者无法穿透的物理边界的信息都属于你的攻击者，不pipe它对你有多大的价值。
信息技术安全的基础就是基于这三个基本原则。 唯一一台真正安全的电脑是锁在一个安全的法拉第笼内，钢笼内。 有些电脑的服务大部分时间都处于这种状态; 每年一次（或更less），他们为受信任的根证书颁发机构生成私钥（在许多目击者面前，使用摄像机logging他们所在房间的每一寸）。
现在，大多数计算机不在这些types的环境下使用; 他们身体状况良好，通过无线电频道连接到互联网。 简而言之，他们和软件一样脆弱。 因此他们不被信任。 计算机及其软件必须知道或做某些事情才能起作用，但必须注意确保它们永远不会知道或造成足够的损害（至less在单机的范围之外不会造成永久性的损害） ）。
你已经知道了这一切; 这就是为什么你要保护你的应用程序的代码。 但是，这是第一个问题。 混淆工具可能会使代码变得混乱，以至于人们尝试去挖掘，但程序仍然需要运行; 这意味着应用程序的实际逻辑stream程及其使用的数据不受混淆。 给予一点韧性，攻击者可以简单地解开代码，而在某些情况下，甚至不需要他所看到的东西不是别的，而是他正在寻找的东西。
相反，你应该试图确保攻击者不能对你的代码做任何事情，不pipe他是多么容易获得清晰的副本。 这意味着，没有硬编码的秘密，因为这些秘密一旦离开你开发它的build筑物就不是秘密。
这些硬编码的键值应完全从应用程序的源代码中删除。 相反，他们应该在三个地方之一。 设备上的非易失性内存，攻击者获取脱机副本比较困难（但仍然不是不可能的）; 永久性地在服务器群集上，用铁拳来控制访问; 或与您的设备或服务器无关的第二个数据存储区（如物理卡或您的用户存储器中（意味着它最终将存储在易失性存储器中，但不必太长时间）。
考虑下面的scheme。 用户从内存中input他们的应用程序凭据到设备中。 不幸的是，您必须相信用户的设备没有被键盘logging程序或木马程序破坏; 在这方面你所能做的最好的办法就是通过记住关于用户使用的设备（MAC / IP，IMEI等）的难以辨认的信息来实现多因素安全，以及至less提供一个附加信道可以validation陌生设备上的login尝试。
一旦进入，凭证被客户端软件（使用安全散列）模糊处理，并丢弃明文凭证; 他们已经达到了目的。 混淆后的凭证通过安全通道发送到证书authentication服务器， 再次散列它们以产生用于validationlogin有效性的数据。 这样，客户端永远不会知道与数据库值相比的实际内容，应用程序服务器永远不会知道validation所接收到的明文凭证，数据服务器永远不会知道它存储用于validation的数据是如何产生的，即使安全通道受到威胁，中间也只能看到乱码。
一旦通过validation，服务器就会通过该通道传回一个令牌。 令牌仅在安全会话中有用，由随机噪声或会话标识符的encryption（因此可validation）副本组成，并且客户端应用程序必须在相同的信道上将该令牌作为任何请求的一部分发送到服务器做某事。 客户端应用程序将执行多次这样的操作，因为它不能做任何涉及金钱，敏感数据或任何可能损害自身的东西; 它必须要求服务器完成这个任务。 客户端应用程序永远不会将任何敏感信息写入设备本身的持久性内存，至less不能以纯文本格式; 客户端可以通过安全通道向服务器请求对称密钥来encryption服务器将会记住的任何本地数据; 在稍后的会话中，客户端可以向服务器请求相同的密钥来解密用于易失性存储器的数据。 这些数据也不会是唯一的副本; 客户端存储的任何内容都应以某种forms传输到服务器。
显然，这使得您的应用程序严重依赖于Internet访问; 如果没有服务器的正确连接和authentication，客户端设备不能执行其任何基本function。 没有什么不同于Facebook，真的。
现在，攻击者要的电脑就是你的服务器，因为它而不是客户端的应用程序/设备是可以使他赚钱的东西或者让他人为他的享受而痛苦的事情。 没关系; 与保护所有客户端相比，为了保护服务器而花费大量金钱和精力，你会得到更多的回报。 服务器可以放在各种防火墙和其他电子安全设备的后面，还可以在钢铁，混凝土，钥匙卡/引脚接入以及24小时video监控之后进行物理固定。 你的攻击者需要非常复杂，直接获得对服务器的任何访问权限，并且你应该立即知道它。
攻击者可以做的最好的方式是窃取用户的电话和凭据，并以客户端的有限权限login到服务器。 如果发生这种情况，就像丢了信用卡一样，应该让合法用户拨打一个800号码（最好容易记住，而不是在他们的钱包，钱包或公文包中可能携带的卡的背面）从他们可以访问的任何电话旁偷走移动设备），直接连接到您的客户服务。 他们说他们的电话被盗，提供了一些基本的唯一标识符，并且账户被locking，攻击者可能处理的任何交易都被回滚，攻击者又回到原点。
1.如何完全避免Android APK的逆向工程？ 这可能吗？
这是不可能的
2.我如何保护所有应用程序的资源，资产和源代码，使黑客无法以任何方式破解APK文件？
当有人将.apk扩展名更改为.zip时，解压缩后，可以轻松获得所有资源（ Manifest.xml除外），但使用APKtool可以获取清单文件的实际内容。 再次，一个没有。
3.是否有办法使黑客更加困难甚至不可能？ 我还能做些什么来保护我的APK文件中的源代码？
再次，不，但是可以防止达到一定的水平，也就是说，
- 从网上下载资源并进行一些encryption过程
- 使用预编译的本地库（C，C ++，JNI，NDK）
- 总是执行一些哈希（ MD5 / SHA键或任何其他逻辑）
即使在Smali ，人们也可以玩你的代码。 总而言之，这是不可能的。
100％避免反向工程的Android APK是不可能的，但你可以使用这些方法来避免提取更多的数据，如源代码，资产forms的APK和资源：
-
使用ProGuard来混淆应用程序代码
-
使用使用C和C ++的 NDK将您的应用程序核心和部分代码保存在
.so文件中 -
要保护资源，请不要在APK资源文件夹中包含所有重要资源。 在申请首次启动时下载这些资源。
开发人员可以采取以下措施防止APK以某种方式被盗，
-
最基本的方法是使用
ProGuard工具来混淆他们的代码，但是直到现在，要完全阻止某人反编译应用程序还是相当困难的。 -
我也听说过一个工具HoseDex2Jar 。 它通过在Android APK中插入无害代码来阻止
Dex2Jar，混淆和禁用Dex2Jar并保护代码免受反编译。 它可以以某种方式防止黑客将APK反编译成可读的Java代码。 -
只有在需要时才使用某个服务器端应用程序与应用程序进行通信。 这可能有助于防止重要的数据。
毕竟，你不能完全保护你的代码免受潜在的黑客攻击。 不知何故，你可以使他们难以和令人沮丧的任务反编译你的代码。 最有效的方法之一是编写本地代码（C / C ++）并将其作为编译库存储。
1.如何完全避免Android APK的逆向工程？ 这可能吗？
那是不可能的
2.我如何保护所有应用程序的资源，资产和源代码，使黑客无法以任何方式破解APK文件？
开发人员可以采取诸如使用ProGuard这样的工具来混淆他们的代码，但是到目前为止，要完全阻止某人反编译应用程序是相当困难的。
这是一个非常棒的工具，它可以增加代码“倒序”的难度，同时缩小代码的占用空间。
集成的ProGuard支持：ProGuard现在与SDK工具一起打包。 开发人员现在可以将其代码作为发布版本的集成部分进行混淆。
3.是否有办法使黑客更加困难甚至不可能？ 我还能做些什么来保护我的APK文件中的源代码？
在研究的同时，我开始了解HoseDex2Jar 。 这个工具将保护您的代码免受反编译，但似乎无法完全保护您的代码。
一些有用的链接，你可以参考他们。
- Proguard，Android和许可服务器
- 保护Android LVL应用程序
- 堆栈溢出问题真的不可能保护Android应用程序免受逆向工程？
- 如何防止Android APK文件的逆向工程来保护代码？
这里的主要问题是，dex文件可以反编译，答案是可以“sorting”。 有像dedexer和smali反汇编。
ProGuard，正确configuration，将混淆您的代码。 ProGuard的商业扩展版本DexGuard可能会帮助更多。 但是，您的代码仍然可以转换为smali，具有逆向工程经验的开发人员将能够从smali中找出您正在做的事情。
也许select一个好的执照，并以最好的方式依法执行。
1.如何完全避免Android APK的逆向工程？ 这可能吗？
不可能
2.我如何保护所有应用程序的资源，资产和源代码，使黑客无法以任何方式破解APK文件？
不可能
3.是否有办法使黑客更加困难甚至不可能？ 我还能做些什么来保护我的APK文件中的源代码？
更强硬 – 可能，但实际上，对于普通用户来说，这种攻击会更加困难。 如果有人真的想破解你的应用程序 – 迟早会被黑客入侵。
这里有几个方法可以尝试：
- 使用混淆和ProGuard等工具。
- encryption源和数据的一部分。
- 在应用程序中使用专有的内置校验和来检测篡改。
- 引入代码以避免在debugging器中加载，也就是让应用程序能够检测debugging器并退出/终止debugging器。
- 将身份validation作为在线服务分开。
- 使用应用多样性
- 在对设备进行authentication之前，使用手指打印技术来处理来自不同子系统的设备的硬件签名。
你的客户应该雇用一个知道自己在做什么，谁可以做出正确的决定，并可以指导你的人。
上面谈到你有能力改变后台的事务处理系统是荒谬的 – 你不应该被允许做这样的架构改变，所以不要指望能够。
我的理由是：
由于您的域名是付款处理，因此可以安全地假设PCI DSS和/或PA DSS（以及潜在的州/联邦法律）对您的业务至关重要 – 为了遵守规定，您必须certificate您是安全的。 为了不安全，通过testing发现你并不安全，然后进行修复，重新testing等等，直到安全性得到validation，达到合适的水平=昂贵，缓慢，高风险的成功之道。 为了做正确的事情，先把事情思考一下，把有经验的人才投入到工作中，以一种安全的方式发展，然后再testing，修正（less）等等，直到在合适的水平上validation安全为止。低风险的成功之路。
如果我们想要逆向工程（几乎）不可能的话，我们可以将应用程序放在一个高度防篡改的芯片上，在内部执行所有敏感的东西，并与某些协议进行通信，从而在主机上控制GUI。 即使防篡改芯片也不是100％防裂的; 他们只是设置了一个比软件方法高很多的栏。 当然，这是不方便的：应用程序需要一些小的USB疣，它将芯片插入到设备中。
这个问题没有揭示出想要如此保护这个应用程序的动机。
如果目的是通过隐瞒申请可能存在的任何安全缺陷（已知的或其他方式）来改善付款方式的安全性，则完全是错误的。 如果可行的话，安全敏感的位应该是开源的。 您应该尽可能简单地让任何审查您的应用程序的安全研究人员查找这些位并仔细检查其操作并与您联系。 支付应用程序不应包含任何embedded式证书。 也就是说，不应该仅仅因为它具有来自工厂的固定证书而信任设备的服务器应用程序。 应仅使用用户的证书进行支付交易，使用正确devise的端对端身份validation协议，该协议排除了信任应用程序，平台或networking等。
如果目的是为了防止克隆，那么就没有防篡改的芯片，那么就没有什么办法可以保护程序不被反向工程和复制，这样就有人将兼容的支付方法整合到自己的应用程序中，上升到“未经授权的客户”。 有办法使开发未经授权的客户很困难。 一个是根据程序完整状态的快照创build校验和：所有状态variables。 GUI，逻辑，不pipe。 克隆程序不会有完全相同的内部状态。 当然，这是一个状态机，它具有类似的外部可见状态转换（可以通过input和输出来观察），但几乎没有相同的内部状态。 一个服务器应用程序可以询问程序：你的详细状态是什么？ （即给我一个你所有的内部状态variables的校验和）。 这可以与在服务器上并行执行的虚拟客户端代码进行比较，通过真正的状态转换。 第三方克隆将不得不复制真实程序的所有相关状态变化，以给出正确的响应，这将阻碍其发展。
作为在支付平台上广泛开展工作（包括一个移动支付应用程序（MyCheck））的人，我想说您需要将此行为委托给服务器，不应该存储支付处理器的用户名或密码（无论哪一个）在移动应用程序中进行硬编码，这是你想要的最后一件事情，因为甚至当你混淆了代码时，也可以理解源代码。
此外，您不应该在应用程序中存储信用卡或支付令牌，所有事情都应该再次委派给您所build立的服务，稍后还会允许您遵守PCI标准，信用卡公司也会获得奖励不要让你的脖子呼吸（就像他们为我们做的那样）。
其他有争议的答案在这里是正确的。 我只是想提供另一种select。
对于您认为重要的某些function，您可以将WebView控件托pipe在您的应用程序中。 该function然后将在您的Web服务器上实现。 它看起来像是在你的应用程序中运行。
I suggest you to look at Protect Software Applications from Attacks . It's a commercial service, but my friend's company used this and they are glad to use it.
Basically it's not possible. It will never be possible. However, there is hope. You can use an obfuscator to make it so some common attacks are a lot harder to carry out including things like:
- Renaming methods/classes (so in the decompiler you get types like
aa) - Obfuscating control flow (so in the decompiler the code is very hard to read)
- Encrypting strings and possibly resources
I'm sure there are others, but that's the main ones. I work for a company called PreEmptive Solutions on a .NET obfuscator. They also have a Java obfuscator that works for Android as well one called DashO .
Obfuscation always comes with a price, though. Notably, performance is usually worse, and it requires some extra time around releases usually. However, if your intellectual property is extremely important to you, then it's usually worth it.
Otherwise, your only choice is to make it so that your Android application just passes through to a server that hosts all of the real logic of your application. This has its own share of problems, because it means users must be connected to the Internet to use your app.
Also, it's not just Android that has this problem. It's a problem on every app store. It's just a matter of how difficult it is to get to the package file (for example, I don't believe it's very easy on iPhones, but it's still possible).
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.
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).
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
webviewprotect resource + code on server
Multiple approaches; this is obvious you have to sacrifice among performance and security
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
There is no way to completely avoid reverse engineering of an APK. To protect application assets, resources, you can use encryption.
- Encryption will make harder to use it without decryption.choosing some strong encryption algorithm will make cracking harder.
- Adding some spoof code into your main logic to make more harder for cracking.
- If you can write your critical logic in any native language and that surely make harder for decompile.
- Using any third party security frameworks like Quixxi
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?
An APK file is protected with the SHA-1 algorithm. You can see some files in the META-INF folder of APK. If you extract any APK file and change any of its content and zip it again and when you run that new APK file on an Android machine, it will not work, because the SHA-1 hashes will never match.
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.
If your app is this sensitive then you should consider the payment processing part at server side. Try to change your payment processing algorithms. Use android app only for collecting and displaying user information (ie account balance) and rather than processing payments within java codes, send this task to your server using a secure SSL protocol with encrypted parameters. Create fully encrypted and secure API to communicate with your server.
Of course, It can also be hacked too and it has nothing to do with source codes protection but consider it another security layer to make it harder for hackers to trick your app.
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.
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.
I am developing a payment processing app
Google have been very successful in avoiding malicious hackers in general by using a simple financial method to "protect" Google Chrome , and I quote:
We have a standing $50,000 reward for participants that can compromise a Chromebook or Chromebox with device persistence in guest mode
Your best bet to actually get closer to 100% "security" is picking the right fight for your money's worth.
Now, that won't protect you from lunatics and lucky pranksters, but… The later group will only enjoy little time in while the system readjusts. While a lunatic is something you only need to worry in case you're big enough to have a nemesis. And that would make a great story! 🙂
Invest in Ai. Identifying patterns in money flow to predict potential risks is much more "secure" than trying to prevent money leakage.
I tried writing more about all the above in my "blog" , such as why I'm putting "security" and "protect" in quotes (what do they even really mean?).
In other words, instead of asking " how to avoid reverse engineering " try asking " how to engineer a bullet proof payment processing app ".
Finally, as a processing app you shouldn't care less for whatever fake security you think you can create in your binary code. Worry about your server instead. Make a strict communication protocol to make monitoring the server easier, for instance. Now that can be reliable!
