Vault7: CIA Hacking Tools Revealed
Navigation: » Latest version
RoidRage Bootstrap Methods
Background
For referennce on Android Internals (important in understanding roles of the system daemons referenced below), see: Android Internals: A Confectioner's Cookbook
History
Originally, RoidRage started up exclusively through rebuilding the 'rild'1 system daemon. The reasons for this were:
- rild started up as root (though it changed user to radio later on)
- rild has access to hook radio functions (for things like SMS interception)
- rild didn't change through a range of OSOperating System versions (an assumption that is no longer accurate)
For several versions of the OS, this worked quite well, but once dual-sim devices started coming out, this became more problematic. Furthermore, when SELinux became common on Android, this became more problematic since the radio SELinux context that rild started with was too restrictive for the implant to function.
Objectives
The objectives of any method which loads and starts the RoidRage implant are (ideally):
- Load the RoidRage precore library, which then loads RoidRage modules from the module database
- Execute as root user and root group
- Execute with 'init' SELinux context
- If this is impossible, the next best contexts are 'system', followed by 'zygote'
- Avoid creating any alerting behavior or signaling that the system has been modified
- This might occur by the Samsung 'sysscope' service triggering the device status as "custom" in settings or by DMVerity signaling that the system partition (on devices where DMVerity is enabled)
- This might occur by the Samsung 'sysscope' service triggering the device status as "custom" in settings or by DMVerity signaling that the system partition (on devices where DMVerity is enabled)
If the device does not use DMVerity and does not have flash locking, then the easiest way to achieve these goals is by rewriting a system binary on the system partition. If it does have either of these, then without a bypass for either, you will need to start up with some other method.
Currently Supported Bootstrap Techniques
-
rild
- Rebuilds the rild system daemon from source code, supports 4.0 - 4.2.X
-
debuggerd (kitkat)
- Rebuilds the debuggerd system daemon from source code, supports 4.3.X-4.4.X
-
debuggerd (ics-jellybean)
- Rebuilds the debuggerd system daemon from source code, supports 4.0.X-4.2.X
-
sysmon
- Creates a new system daemon and uses the fact that the 'init.rc' on certain devices has an entry to start /system/bin/sysmon, even though this file doesn't actually exist. This method can also be used whenever there is any other system daemon that is started from the 'init.rc' on a device that does not actually have that system daemon and does not implement DMVerity.
-
sysmon (with cadmium)
- Uses a method akin to the above sysmon startup, but uses cadmium to circumvent DMVerity
Proposed Bootstrap Techniques
- crocanaw
- uses the wpa_supplicant to persist on the data partition as user wifi, would require priviledge escalation
- totadile
- uses the feature in 4.4.X to switch between ART and Dalvik runtime environments in order to persist on the data partition, limited to 4.4.X
- limestone
- trojans the boot.oat file in the dalvik cache in order to gain execution in zygote, limited to 5.X+, runs from the data partition
Footnotes:
1) Radio Interface Layer Deamon = RIL provides abstraction between Android telephony services (android.telephony) and radio hardware.