Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
What is the different between ART And Dalvik security, cause Google using Art after Kitkat (4.4.2) ?
Just for these two options?
Ahead-of-Time (AOT) compilation, which improves speed (particularly startup time) and reduces memory footprint (no JIT)
Improved Garbage Collection (GC)
and what about the security?
On a general basis, the distinction between just-in-time and ahead-of-time compilation is not relevant to security. One can see things as performance trade-offs. For an application, that consists in a sequence of small instructions meant for the abstract sort-of-Java virtual machine:
In pure interpretation, individual instructions are parsed when they are to be executed, and the parsing of any instruction is done every time that instruction is executed.
In AOT compilation, during a preparatory phase (e.g. when the application is installed in the phone), the instructions are translated into the opcodes that the actual hardware CPU understands. Thus, the "parsing" is done once. Performance is much better, at the expense of a one-time translation done at installation.
In JIT compilation, you get something in-between these two models. Translation is not done in advance, but it is still done by whole chunks (a complete function in one go) instead of instruction per instruction. Compared to AOT, more compilation occurs, basically whenever the application is launched, instead of once. On a rather theoretical basis, JIT compilation may optimize things based on the actual execution pattern and could produce a better (faster) sequence of native opcodes than AOT; in practice, this effect tends to be nullified by the constraints under which JIT compilation must operate (in particular, since JIT occurs when the application is being used and the user is waiting, the JIT compilation must be fast).
In all of the above, the security properties of the Java VM are maintained: all array accesses are still checked, all method calls are verified to happen only on objects that indeed offer the said methods.
If we want to nitpick, then we might argue that ART somewhat reduces security, not because it uses AOT compilation, but because it is new, and new software tends to have more bugs than old software (a large user base represents a lot of testing, so old software has been naturally tested thoroughly). Conversely, we might pretend that AOT compilation is simpler to implement than JIT compilation (because AOT does not have to deal with translating a live application and already allocated objects) and therefore an AOT-based JVM implementation would be less likely to have bugs than a JIT-based JVM. But these considerations are just idle speculation under the usual assumption of "all other things being equal", and it is known that all other things are never equal.
From the Mobile Application Hacker's Handbook:
Dealing with ART
Android devices making use of the new Android Runtime (ART) convert DEX files into OAT files at installation time. OAT files are essentially ELF dynamic objects that are run on the device and one would assume that they would have to be treated like native code when reverse engineering them. A tool named oatdump performs a similar disassembling function for OAT files as dexdump does for DEX files. Explore the options provided by this tool if you are interested in disassembling an OAT file. However, similarly to dexdump the output is provided in quite a raw manner.
One simple fact that can be used is that the APK file of each installed application is still stored on the device. This means that the DEX file of your target application is still accessible in the normal way even when the converted OAT file is being used on the device. Another interesting detail is that every OAT file contains the original DEX file(s) embedded inside it. Pau Oliva created a script called oat2dex that can extract the DEX file(s) from within a given OAT file. This script relies on radare2 (see http://www.radare.org/) and can be found at https://github.com/poliva/random-scripts/blob/master/android/oat2dex.sh. This can be used if the original APK containing the DEX is no longer available.
