Introduction: Why Audit Your Custom Android ROM?

Developing or flashing a custom Android ROM offers unparalleled flexibility and control over your device. However, this freedom comes with increased responsibility, particularly concerning security. Unlike stock Android, custom ROMs are often built by diverse teams or individuals, potentially introducing subtle vulnerabilities or misconfigurations that could compromise your device. A basic security audit is crucial to identify and mitigate these risks, ensuring your custom ROM is as secure as it is functional. This guide provides a detailed, expert-level walkthrough on performing a fundamental security audit.

Prerequisites for a Successful Audit

Before diving into the audit process, ensure you have the following tools and knowledge:

• Rooted Android Device: The custom ROM you intend to audit must be installed and rooted to access system-level files and commands.
• ADB & Fastboot: Android Debug Bridge and Fastboot tools installed on your host machine for device interaction.
• Basic Linux Command Line Knowledge: Familiarity with common shell commands.
• Decompilers/Analyzers: Tools like APKTool, JADX, or Ghidra for analyzing APKs and binaries.
• Text Editor: A powerful text editor for reviewing configuration files.
• Internet Access: For checking CVE databases and documentation.

Key Areas of Focus for Your Audit

A comprehensive audit involves examining several critical components of your custom ROM:

• Kernel Security: The foundation of your Android system.
• System Application Permissions: Over-privileged applications are a common attack vector.
• SELinux Policy Enforcement: Ensuring proper access control.
• Root Access Management: How root privileges are granted and controlled.
• Encryption Status: Protecting your data at rest.
• Build Configuration: Debugging flags and secure properties.

Step-by-Step Audit Process

1. Setting Up Your Audit Environment

First, ensure ADB is properly configured and your device is recognized:

adb devices

You should see your device listed. Then, gain a root shell:

adb rootadb shell

Now you are ready to explore the device’s filesystem.

2. Kernel Analysis

The kernel is the core of the operating system. Vulnerabilities here can lead to full system compromise.

Check Kernel Version and Source

Identify the running kernel version:

cat /proc/version

Compare this version against public databases for known Common Vulnerabilities and Exposures (CVEs). If your ROM builder provides the kernel source, inspect it for custom patches or deviations that might introduce weaknesses.

Review Kernel Messages (dmesg)

Examine kernel boot messages for unusual warnings or errors that might indicate misconfigurations or potential exploits:

dmesg | less

Look for messages related to security features being disabled or critical components failing to initialize correctly.

3. System Application Review

Many custom ROMs include pre-installed system applications. These can be a source of vulnerabilities if not properly secured.

Extract and Decompile System APKs

Identify pre-installed system apps, usually found in /system/app and /system/priv-app:

ls /system/appls /system/priv-app

Pull suspicious or unknown APKs to your host machine:

adb pull /system/priv-app/SomeApp/SomeApp.apk ~/audit/apks/

Use APKTool or JADX to decompile them and review their AndroidManifest.xml for excessive permissions, hidden services, or unusual components. Pay close attention to permissions like android.permission.INTERACT_ACROSS_USERS_FULL, android.permission.WRITE_SECURE_SETTINGS, or any custom permissions.

Analyze App Permissions

You can get a detailed list of permissions granted to all packages using dumpsys:

adb shell dumpsys package permissions > ~/audit/package_permissions.txt

Review this file for any system app having unnecessary or overly broad permissions. For example, a simple calculator app should not require camera access or location services.

4. SELinux Policy Enforcement

SELinux (Security-Enhanced Linux) provides mandatory access control, confining applications and processes to specific security contexts. A misconfigured SELinux policy can render the entire system vulnerable.

Check SELinux Status

Ensure SELinux is enforcing:

adb shell getenforce

The output should be Enforcing. If it’s Permissive or Disabled, your device’s security posture is significantly weakened.

Review SELinux Logs

Examine audit logs for denied operations:

adb shell auditctl -l # List active rules (may need busybox)adb shell cat /sys/fs/selinux/denials # Or similar path for denials

Frequent denials might indicate a poorly written policy that constantly grants exceptions, or a legitimate application being blocked. Excessive avc: denied messages might suggest the ROM builder has set SELinux to permissive mode to avoid debugging policy issues.

Analyze Policy Files

If you have access to the ROM’s source, inspect the SELinux policy files (usually in /sepolicy or similar directories in the AOSP build tree) for any custom rules that might loosen security controls.

5. Root Access Management

Root access is a powerful feature in custom ROMs, but its management must be secure.

Inspect SU Binary

Locate and examine the su binary:

adb shell which suadb shell ls -l $(which su)

Verify its permissions. Typically, it should be owned by root and have appropriate permissions (e.g., -rwsr-xr-x). An insecure su binary or one with overly broad permissions can be exploited. Check its version and ensure it’s from a reputable source (e.g., Magisk, LineageOS’s AddonSU).

Review Root Management Application

If your ROM includes a root management app (e.g., Magisk Manager, SuperSU), ensure it’s up-to-date and its configuration is secure. Check its settings for any options that might inadvertently grant root access too broadly or silently.

6. Encryption and Lock Screen Security

Data at rest encryption is vital for protecting your personal information.

Check Disk Encryption Status

Verify if your device is encrypted:

adb shell getprop | grep encrypt

Look for properties indicating encryption status. Full Disk Encryption (FDE) or File-Based Encryption (FBE) should be enabled. If not, your data is vulnerable if the device falls into the wrong hands.

Lock Screen Security

Ensure your lock screen uses a strong PIN, pattern, or password. Avoid trivial or easily guessable combinations. Check if there are any settings allowing easy bypass of the lock screen (e.g., smart lock features that are too permissive).

7. Build Configuration Analysis

Certain build properties can expose your device to debugging or insecure behavior.

Examine build.prop

The build.prop file contains crucial system properties:

adb shell cat /system/build.prop

Pay attention to these properties:

• ro.debuggable=1: Indicates a debuggable build, which allows anyone with ADB access to gain root on some versions or bypass security restrictions. This should ideally be 0 for a production ROM.
• ro.secure=0: Similar to ro.debuggable, indicates an insecure build, often used for development. Should be 1 for production.
• ro.adb.secure=0: Allows ADB without authentication. Should be 1.

Any custom properties in build.prop should also be scrutinized for potential security implications.

Conclusion

Performing a basic security audit on your custom Android ROM is an ongoing process, not a one-time task. This guide covers fundamental steps to help you identify common vulnerabilities in the kernel, system applications, SELinux policies, root management, encryption, and build configurations. By diligently following these steps and staying informed about the latest Android security practices, you can significantly enhance the security posture of your custom ROM, ensuring a safer and more private mobile experience.