How to hack any Whatsapp account

 The Dalvik Virtual Machine

The DalvikVM is register-based, as opposed to stack-based. Although Dalvik is

said to be Java-based it is not Java insofar as Google does not use the Java logos and

the Android application model has no relationship with JSRs (Java Specifi cation

Requirements). To the Android application developer, the DalvikVM might look

and feel like Java but it isn’t. The overall development process looks like this:

 1. Developer codes in what syntactically looks like Java.

 2. Source code is compiled into .class fi les (also Java-like).

 3. The resulting class fi les are translated into Dalvik bytecode.

 4. All class fi les are combined into a single Dalvik executable (DEX) fi le.

 5. Bytecode is loaded and interpreted by the DalvikVM.

As a register-based virtual machine, Dalvik has about 64,000 virtual regis-

ters. However, it is most common for only the fi rst 16, or rarely 256, to be used.

These registers are simply designated memory locations in the VM’s memory

that simulate the register functionality of microprocessors. Just like an actual

microprocessor, the DalvikVM uses these registers to keep state and generally

keep track of things while it executes bytecode.

The DalvikVM is specifi cally designed for the constraints imposed by an

embedded system, such as low memory and processor speeds. Therefore, the

DalvikVM is designed with speed and effi ciency in mind. Virtual machines,

after all, are an abstraction of the underlying register machine of the CPU. This

inherently means loss of effi ciency, which is why Google sought to minimize

these effects.

To make the most within these constraints, DEX fi les are optimized before

being interpreted by the virtual machine. For DEX fi les launched from within

an Android app, this generally happens only once when the application is fi rst

launched. The output of this optimization process is an Optimized DEX file (ODEX). It should be noted that ODEX fi les are not portable across different 

revisions of the DalvikVM or between devices.

Similar to the Java VM, the DalvikVM interfaces with lower-level native code 

using Java Native Interface (JNI). This bit of functionality allows both calling from 

Dalvik code into native code and vice versa. More detailed information about the 

DalvikVM, the DEX fi le format, and JNI on Android is available in the offi cial 

Dalvik documentation at http://milk.com/kodebase/dalvik-docs-mirror/docs/.

Zygote

One of the fi rst processes started when an Android device boots is the Zygote

process. Zygote, in turn, is responsible for starting additional services and

loading libraries used by the Android Framework. The Zygote process then

acts as the loader for each Dalvik process by creating a copy of itself, or forking.

This optimization prevents having to repeat the expensive process of loading

the Android Framework and its dependencies when starting Dalvik processes

(including apps). As a result, core libraries, core classes, and their corresponding

heap structures are shared across instances of the DalvikVM. This creates some

interesting possibilities for attack, as you read in greater detail in Chapter 12.

Zygote’s second order of business is starting the system_server process. This

process holds all of the core services that run with elevated privileges under the

system AID. In turn, system_server starts up all of the Android Framework

services introduced in Table 2-1.

NOTE

 The system_server process is so important that killing it makes the device

appear to reboot. However, only the device’s Dalvik subsystem is actually rebooting.

After its initial startup, Zygote provides library access to other Dalvik pro-

cesses via RPC and IPC. This is the mechanism by which the processes that

host Android app components are actually started.