Strengthening the current market various manufacturers in the strengthening of the common App has done quite mature and stable, but also very high intensity. After the program but does not seem to xposed a plug for reinforcement, the author tried several reinforcement, will lead to the collapse xposed plug-in, plug-in function or is invalid, or lead to significantly affect the operating performance App interception when the giant card.
Forced, for the safety of practitioners itself is the author, I can only think of ways to solve their own hands, and to provide the following two ideas, I also have a simple demo run through, but the stability may also need to polish, this we all need to study.
Of course, if there has emerged a mature strengthening tripartite program xposed plug-ins, you can also buy used, after all, now is the era of resource integration, no need to have every aspect of their own hands to achieve development, focus on their business just fine.
The first scenario: Memory dynamically loaded mode
is well known that the xposed plug-in essence, is a APK file, but can be configured to specify a xposed_init HOOK entry class, in fact, the entrance class or in the APK package in the assets of DEX file directory, we find ways to protect the DEX files.
If the original package DEX file encryption to protect them, and that's HOOK xposed you will not find the entrance class is bound to run when problems arise. At this time, we also corresponding to the specified entry xposed_init replace class, a class can be replaced with reinforcing shell.
When xposed plug injection occurs, the first to enter the class reinforced shell, so we took over control. Do some initialization operations, the dynamic decryption DEX and dynamically load the original package, and then return control to the original inlet HOOK class, so that subsequent operations will be able to maintain active the HOOK.
DEX from the visual point of view, DEX file xposed plug the reinforcement is not the original package, so to protect a certain extent the code, but not decompile, timely decompile, displayed code is the shell code, the core code logic xposed plug is hidden encrypted together.
The dynamic run-time, HOOK function xposed plug-in is not lost, but also remain in force.
In summary, this is a viable way of strengthening protection, can effectively prevent xposed plug-in is analyzed, the core code was stolen to some extent. However, the method of memory dynamically loaded there are ways shelling, easy to dump out the original DEX file at run time, the need to enhance the strength, let's look at the second option.
The second option: java2c of native mode
as the name suggests, java2c will actually be counter-DEX originally compiled to Java code is converted to binary instructions native layer, not on the Java language source code into C language.
Popular speak again, the DEX code is converted to binary instructions SO file.
Ideological source java2c can roughly say something:
The first time, Android limited hardware performance of the machine, combined with the Java language compiler from App code needs to run on the Java virtual machine, resulting in a lot of wasted performance, so early in the Android App to use mobile phones and are not very smooth. And absolutely can not directly use the object-c language development App of the iPhone compared to Android phones is still very bad experience.
Later, Google may also find the problem, then try to start ART in Android4.4 system mode, in this mode, the system will first DEX files into a large file with this ELF machine instructions relevance to a certain extent ( It can be simply understood as the binary file similar sO), so there is a big speed improvement.
After the phone is switched to ART restart mode, the system will find all the App will be a conversion, the conversion process is performing a binary code conversion, it is more time-consuming.
The idea is essentially: the time-consuming waste App runtime, in a one-time move to phase conversion, so the conversion phase is relatively slow, but once the conversion is successful, then run late App is more fluent.
This is a good idea, but have not found it bad? That is why the local translation conversion on the customer's mobile phone terminal, rather than directly in the development stage of the conversion package is good?
The issues related to the Android ecosystem, and had to quickly seize the Android mobile operating system market, leading to a fragmentation of the market is very large models, large to Google can not control the stage. How one can not control it? That is, if you convert (DEX can be assumed to change the packet format) at compile time, a compiler package directly approaching native binary package, Google can not guarantee its own stability can be run on a machine so massive fragmentation. If the cause of instability, it will lose a lot of the mobile operating system market and reputation, so Google can not do that, to be wanted stability, even if the iPhone is not so smooth Andrews machine does not matter.
So the final strategy is to allow the terminal to compile the machine, which is why when switching ART mode, the system requires conversion of App, this process is the process of compiling its own terminal machine (precisely Translate operation). Moreover, it must be dual-mode exist, namely ART dalvik mode and mode coexist, once the translation or conversion failed conversion run ART App mode in question, or the user can switch back at any time under stable dalvik mode.
Over time, Android system version has iterated a lot of generations, ART mode is also gradually mature and stable, and indeed the performance of the App has substantially improved, so in subsequent versions of Android's system, has been the default mode is ART a.
The Android system is stable, and the stability of the Android operating system market share, leading to the above question again revealed: Why not put the machine translation process on the terminal out, make out in the packing stage?
Based on this idea, java2c model is the reinforcement of the earliest manufacturers, it is to dex code into native instructions, drawn to the SO to run.
After many years, Huawei's Ark is the compiler of birth, say this behind us. java2c Reinforcement first xposed plug-reinforced finished.
java2c specific implementation, with reference to the conversion process is in the early ART mode, the process out from the user's terminal equipment, into the reinforcing phase to do away. As the current Android phones are more common CPU architecture is basically a completely fragmented era is not a big way, so there is a guarantee compatibility, the instruction after the conversion can easily compatible, and can stably run up.
However java2c only help reinforce the idea of converting the above, since the purpose is to improve the strength of protection, not the pursuit of performance, so java2c strengthening performance reinforcement Although VMP compared to (this is another reinforcement mode, do not start speaking here) there is in a very big upgrade (correspondingly, the volume becomes larger, it can be considered to take space for a time), but has not reached the performance limit, and this limit who chase performance to take? That mobile phone manufacturers, this is to say behind Huawei's Ark compiler.
Repeatedly said many times above, why not make the translation process on the terminal off the machine out to do?
To put out what stage do it?
If java2c Reinforcement strengthening links do put out, and that is reinforced vendor needs to be done, that is.
If you are out on the compiler stage to do (for example, when the package is AndroidStudio after a performance optimization package, which is excellent), it would need to Google and IDE and many other manufacturers to push, but it may be more difficult, because you need further updated format all the major mobile phone manufacturers recognize, that is, on their mobile phones to be able to run out of it, even if Google to push unilaterally, and that it could be before the "ART mode with dalvik mode coexist slowly transition "Similarly, the emergence of a" NEW ART mode and mode coexist "down.
Google did not do the above, Huawei do, and want to do it, we need to mature a lot of conditions. The most important thing is the mobile phone market share, Huawei as a major mobile phone manufacturers, there should be enough lung power to do. However, Huawei aims to do this? Also repeatedly mentioned above, it is the pursuit of maximum performance, and so to consolidate and enhance the market competitiveness of their own cell phone, so as to further improve their market share.
This is why an ark, panicked other mobile phone manufacturers. Millet showed the "suspension Calculator" against Huawei "Ark compiler," From this point of view, see the Huawei millet should be routine, it is also no way, than to watch a batch churn Well you gotta worthy of its own brands and fans.
So for developers, there is no need to panic, there is no need to study the ark compiler, except of course interested. Because life is not its appearance developer of leather, leather Google is not life, it is the life of leather other mobile phone manufacturers, it is not so great, just to improve their competitive card only.
I love the country, I use millet, do not like do not spray. But while the author is very optimistic about Huawei, the compiler is not the Ark itself, but behind the Ark to disclose compiler message: that is willing to Huawei on the basis of technical research investment capital in the era of fame and fortune, everything about money, to the front look benefits, few companies can layout the long term, the huge technological research spending through the Ark compiler, which alluding Huawei is a company willing to invest in basic technology research company, so it is still a great company, very We expect it to go further! Also hope that other domestic companies like Huawei, like, bigger and stronger!
So no matter where on the one hand say, millet had to play a card, otherwise it can only be to get rid of, whether it is the underlying technology or market.
But I think it better to launch Google, just like the original ART patterns, there are two modes of transition, to further enhance the advantages of the Android system. Of course, Huawei do so, there will be a continued App format compatible with mainstream models.
End:
above describes two reinforced ideas, demo I also have run through, of course, can also be combined string encryption, anti dynamic debugging, anti-decompile, combined with a variety of encryption methods to increase the accessibility garbage junk code instructions, etc. to increase strength.