- Home
- Techniques
- Mobile
- Modify OS Kernel or Boot Partition
Modify OS Kernel or Boot Partition
If an adversary can escalate privileges, he or she may be able to use those privileges to place malicious code in the device kernel or other boot partition components, where the code may evade detection, may persist after device resets, and may not be removable by the device user. In some cases (e.g., the Samsung Knox warranty bit as described under Detection), the attack may be detected but could result in the device being placed in a state that no longer allows certain functionality.
Many Android devices provide the ability to unlock the bootloader for development purposes, but doing so introduces the potential ability for others to maliciously update the kernel or other boot partition code.
If the bootloader is not unlocked, it may still be possible to exploit device vulnerabilities to update the code.
Procedure Examples
| Name | Description |
|---|---|
| OldBoot |
OldBoot uses escalated privileges to modify the init script on the device's boot partition to maintain persistence.[1] |
Mitigations
| Mitigation | Description |
|---|---|
| Attestation | |
| Lock Bootloader | |
| Security Updates |
Detection
The Android SafetyNet API's remote attestation capability could potentially be used to identify and respond to compromised devices. Samsung KNOX also provides a remote attestation capability on supported Samsung Android devices.
Samsung KNOX devices include a non-reversible Knox warranty bit fuse that is triggered "if a non-Knox kernel has been loaded on the device" [2]. If triggered, enterprise Knox container services will no longer be available on the device.
As described in the iOS Security Guide [3], iOS devices will fail to boot or fail to allow device activation if unauthorized modifications are detected.
Many enterprise applications perform their own checks to detect and respond to compromised devices. These checks are not foolproof but can detect common signs of compromise.