Java 真的不可能保护 Android 应用免受逆向工程吗?

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/4336637/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-08-14 16:05:37  来源:igfitidea点击:

Is it really impossible to protect Android apps from reverse engineering?

javaandroidreverse-engineeringdecompiling

提问by Android Eve

As we know, Android apps are written in Java. In Java, no matter what you do, it is impossible to protect compiled code from decompilation or reverse-engineering, as the Stack Overflow question How to lock compiled Java classes to prevent decompilation?suggests.

众所周知,Android 应用程序是用 Java 编写的。在 Java 中,无论您做什么,都不可能保护已编译的代码免遭反编译或逆向工程,如 Stack Overflow 问题如何锁定已编译的 Java 类以防止反编译?建议。

How would one go about protecting an app that contains algorithmic trade secrets from reverse-engineering?

如何保护包含算法商业机密的应用程序免遭逆向工程?

By "how" I mean not only software techniques, but also other creativeapproaches.

我所说的“如何”不仅指软件技术,还指其他创造性方法。

采纳答案by willjcroz

The first stop for me would be to optimise and obfuscate the code with ProGuardwhich is known to work with byte code targeted at Android's DalvikVM (via Dex). It's a really great tool and can increase the difficulty of 'reversing' your code while shrinking your code's footprint (in some cases dramatically: a recent applet of mine went from about 600 KB down to about 50 KB).

对我来说,第一站是使用ProGuard优化和混淆代码,众所周知,ProGuard可以处理针对 Android DalvikVM(通过 Dex)的字节码。这是一个非常棒的工具,可以增加“反转”代码的难度,同时缩小代码的占用空间(在某些情况下非常显着:我最近的一个小程序从大约 600 KB 减少到大约 50 KB)。

Like others are saying, you will never get 100% security of your algorithm's details while its implementation is being distributed to clients. For that, you'd need to keep the code on your servers alone. Attempts to near 100% percent security for client code effectively amount to DRMand can make your client code fragile in the face of network outages and just generally frustrate (legitimate) users.

就像其他人所说的那样,在将算法的实现分发给客户端时,您永远无法获得算法细节的 100% 安全性。为此,您需要将代码单独保留在您的服务器上。尝试使客户端代码接近 100% 的安全性实际上相当于DRM,并且会使您的客户端代码在面临网络中断时变得脆弱,并且通常会使(合法)用户感到沮丧。

The Android developers blog has some usefularticleson the matter of 'tamper resistant' Android apps (and they recommend the use of ProGuard as part of the overall approach).

Android 开发者博客上有一些关于“防篡改”Android 应用程序问题的有用文章(他们建议使用 ProGuard 作为整体方法的一部分)。

With regards to 'creative' approaches: some developers employ debugger detection techniquesto prevent run-time analysis and combine this with encryption of portions of binary code (to deter static analysis), but to be honest, a determined enough attacker can circumventthese, while it can cause legitimate user frustration as illustrated by the Windows KB article Games: Error Message: A Debugger Has Been Detected: Unload the Debugger and Try Again. My girlfriend's 'Learn to drive' DVD software will not run under VirtualBoxfor this reason, but she blames Linux of course!

关于“创造性”方法:一些开发人员使用调试器检测技术来阻止运行时分析,并将其与二进制代码部分的加密相结合(以阻止静态分析),但老实说,一个足够坚定的攻击者可以绕过这些,虽然它可能会导致合法用户感到沮丧,如 Windows 知识库文章游戏:错误消息:检测到调试器:卸载调试器并重试。由于这个原因,我女朋友的“学习驱动”DVD 软件无法在VirtualBox下运行,但她当然责怪 Linux!

OpenRCEand Wikipedia's article on obfuscated codemay be good starting points if you want to look into this further. But be warned, you may lose more through over zealous use of these techniques frustrating your users than you would through loss of trade secrets by reverse engineering. Like Anton S says, maybe the most 'creative' approach lies with tweaking the business model rather than the technology.

如果您想进一步研究,OpenRCE维基百科关于混淆代码的文章可能是很好的起点。但请注意,与通过逆向工程丢失商业机密相比,过度狂热地使用这些让用户感到沮丧的技术可能会造成更多损失。正如Anton S 所说,也许最“有创意”的方法在于调整商业模式而不是技术。

The latest Android SDK updateon 6th Dec 2010 (coinciding with Android 2.3 Gingerbread release):

2010 年 12 月 6 日的最新 Android SDK 更新(与 Android 2.3 Gingerbread 版本一致):

Integrated ProGuard support: ProGuard is now packaged with the SDK Tools. Developers can now obfuscate their code as an integrated part of a release build.

集成 ProGuard 支持:ProGuard 现在与 SDK 工具一起打包。开发人员现在可以将他们的代码作为发布版本的一个集成部分进行混淆。

回答by Anton S

Make it so cheap to bother and don't build your business model on top of secrets that are executed on the client side. In other words, don't share your secrets.

让麻烦变得如此廉价,并且不要在客户端执行的秘密之上构建您的业务模型。换句话说,不要分享你的秘密。

回答by jcomeau_ictx

If it's a possibility: remote procedure calls to a well-protected server (the server has the code you want to protect).

如果有可能:远程过程调用受良好保护的服务器(该服务器具有您想要保护的代码)。

回答by CodesInChaos

It is impossible to protect any client side code from reverse engineering. You can just use more or less efficient ways of obfuscating your code. And optimized x86 assembler happens to be a pretty good obfuscation.

不可能保护任何客户端代码免受逆向工程。您可以使用或多或少有效的方法来混淆您的代码。优化的 x86 汇编器恰好是一个很好的混淆。

So if you have algorithmic secrets put them on the server-side.

因此,如果您有算法秘密,请将它们放在服务器端。

回答by Stephen C

How to lock compiled Java Classes to prevent decompilation

如何锁定已编译的 Java 类以防止反编译

You can't. Any scheme can be defeated by someone with sufficient skills, time and motivation.

你不能。任何计划都可以被拥有足够技能、时间和动力的人打败。

(Incidentally, this also applies to software that is compiled to binary. The only difference is in the amount of effort involved in decompiling.)

(顺便说一句,这也适用于编译为二进制的软件。唯一的区别在于反编译所涉及的工作量。)

My question is how one would go about protecting an app that contains algorithmic trade secrets from reverse-engineering?

我的问题是如何保护包含算法商业机密的应用程序免遭逆向工程?

Simply don't install the app on the user's phone. Or (more usefully), run the code that contains the trade secrets on a remote (properly secured) server.

只是不要在用户的手机上安装该应用程序。或者(更有用),在远程(适当保护)服务器上运行包含商业机密的代码。

回答by oezi

No matter what you do, maybe at least you can make it very hard to decompile, but: If something gets executed/calculated in a program, the information about the algorithm has to be there, and there will always be a possibility to find out how to get that (enough skill and motivation on you opponents side assumed). Always.

不管你做什么,也许至少你可以让反编译变得非常困难,但是:如果在程序中执行/计算某事,关于算法的信息必须在那里,并且总是有可能找出如何获得(假设你的对手有足够的技巧和动力)。总是。

回答by Jimmy

You can't protect your application completely, as there will always be someone who will crack it...

您无法完全保护您的应用程序,因为总会有人破解它...

However you could hinder them doing this by making your application free, or at least dirt cheap so people won't be bothered.

但是,您可以通过使您的应用程序免费来阻止他们这样做,或者至少非常便宜,这样人们就不会被打扰。

Alternative, try to keep your Android application "dumb", as in keep all the secretive business logic on a backend server, and just have you app display data using some form of exposed service.

或者,尝试让您的 Android 应用程序保持“哑巴”状态,就像将所有秘密业务逻辑保留在后端服务器上一样,让您的应用程序使用某种形式的公开服务显示数据。

回答by David

I have my algorithm on a server and I invoke that service from my smartphone app. A perpetrator can reverse engineer my smartphone app to see my protocol with my server. I can protect my algorithm but I can not protect against unauthorized use of my service. I have to accept this reality without a solution. I have to be content that as long as I am making money with my own service, then I have to live with the potential of others siphoning my service.

我在服务器上有我的算法,我从我的智能手机应用程序调用该服务。犯罪者可以对我的智能手机应用程序进行逆向工程,以查看我与服务器的协议。我可以保护我的算法,但我无法防止未经授权使用我的服务。我不得不接受这个没有解决方案的现实。我必须满足,只要我通过自己的服务赚钱,那么我就必须忍受其他人利用我的服务的潜力。

回答by KrisWebDev

You want a creative approach, here's one.

你想要一种创造性的方法,这是一个。

What is the main program on phones that haven't been decompiled today? Radio firmwares. Why? It doesn't run on the ARM chipset of the phone but instead on a separate Qualcomm Hexagonthat is more and more present in smartphones. It's not x86, it's not ARM, it uses a Qualcomm proprietary architecture and instructions.

今天没有反编译的手机上的主程序是什么?无线电固件。为什么?它不是在手机的 ARM 芯片组上运行,而是在智能手机中越来越多的单独的Qualcomm Hexagon上运行。它不是 x86,也不是 ARM,它使用 Qualcomm 专有架构和指令。

  • Java decompilation is easy.

  • ARM decompilation is more difficult (Hex-Rays Decompiler licences start at 1129 USD... and the mix between thumb code and standard ARM code in binaries is a pain) => you could try compiling with the Android NDK.

  • There is currently no Hexagon decompilers! And QDSP specifications are not publicly available, even pirated versions.

  • Java反编译很容易。

  • ARM 反编译更困难(Hex-Rays Decompiler 许可证起价为 1129 美元……并且在二进制文件中混合拇指代码和标准 ARM 代码是一种痛苦)=> 您可以尝试使用Android NDK 进行编译

  • 目前没有 Hexagon 反编译器!而且 QDSP 规范是不公开的,即使是盗版。

Question is, can an independant software vendor use the Hexagon firmware included in the mass-market phones? It seems to be the direction Qualcomm takes. Check out their website and the SnapDragon products.

问题是,独立软件供应商可以使用大众市场手机中包含的 Hexagon 固件吗?这似乎是高通的方向。查看他们的网站和 SnapDragon 产品。

NB: I'm not pro-Qualcomm nor pro-closed-source. But this thread appeals to this kind of solution.

注意:我既不支持高通也不支持封闭源代码。但是这个线程对这种解决方案很有吸引力。

回答by M.Noman

You can't 100% secure you android code from reverse engineering. If you want to secure some key then you can take help from integrating server that give you encrypted key while calling web service and use that key into your code.

你不能 100% 地从逆向工程中保护你的 android 代码。如果您想保护一些密钥,那么您可以从集成服务器中获得帮助,该服务器在调用 Web 服务时为您提供加密密钥,并将该密钥用于您的代码。