0

When I did a root integrity check on my InFocus Epic 1 from recovery mode, it shows too many errors and at the end it says:

Error:found 432 new files.
Error:found 63 lost files.
Error:found 15 modified files.

System check FAIL!!

What should I do now?

3
  • 1
    What is root integrity check? Nov 24, 2019 at 10:04
  • @IrfanLatif Root Integrity Check AFAIK, is an option available in some devices recovery mode which lets you verify the integrity of some system files and whether they've been modified by a third person (Ex:root) or not.
    – M. A.
    Nov 24, 2019 at 11:07
  • Similar issue on Asus Forum: ROOT integrity - myth: "So user's Dont even bother to check root integrity via recovery. Root integrity check will fail because recovery is not able to "locate/find" some pre defined files which should be there but there isn't. Reason behind not able to locate those file are because they are either replaced by new files or are obsolete now [...] and they are removed but unfortunately the recovery isn't updated yet with new stuff. So yes there is nothing to worry about security of your devices."
    – Andrew T.
    Nov 24, 2019 at 12:02

1 Answer 1

2

My reply is built on my assumption that the OP want to ask about his device's root status, and if it's been altered or not


Check Selinux Status:

Selinux defines which process can access a given resource on your device. AFAIK, all Android device manufacturers companies ship their devices with Selinux Enforcing (Default), in some custom ROMs you may find Selinux Permissive or Selinux Disabled, in those cases system will grant any permission requested by any app.

  • To verify Selinux status, type the following on your command line:

    adb shell getenforce
    
  • Possible Output values:

    • Enforcing
    • Permissive
    • Disabled
  • Default Value (general consumer products):

    • Enforcing

Check ROM/Firmware signing keys:

Check if you have a ROM/Firmware signed with release-keys or test-keys. The main difference is that test-keys are available for Public and everyone know them, but release-keys are kept secret by the person who signed the ROM/Firmware, hence those ROMs signed with release-keys are more secure than ROMs signed with test-keys.

  • To verify your signature, type the following on your command line:

    adb shell getprop ro.build.fingerprint
    
    • test-keys
    • release-keys
  • Default Value (general consumer products):

    • release-keys
  • Example (general consumer products):

    • samsung/dreamqltevl/dreamqltecan:9/PPR1.180610.011/G950WVLS6CSG1:user/release-keys

Check ROM/Firmware build type:

Check if you have a Production built ROM (or not: maybe a debugging version)

  • To verify your build, type the following on your command line:

    adb shell getprop ro.build.fingerprint
    
    • user Build: It has a limited access; no su binary and used for production.
    • userdebug Build: It's similar to user build but it has su binary, thus it's root access and debugging capability; it's used to debug technical issues, and it's a bit slower than user build in performance
    • eng Build: It's a development build with lot of debugging tools, and generally it's the lowest in performance compared to other builds, not used for production.
  • Default Value (general consumer products):

    • user
  • Example (general consumer products):

    • samsung/dreamqltevl/dreamqltecan:9/PPR1.180610.011/G950WVLS6CSG1:user/release-keys

Check if your device is Encrypted:

  • To verify your device encryption, type the following on your command line:

    adb shell getprop ro.crypto.state
    
  • Possible Output values:

    • Encrypted
    • Unencrypted
  • Default Value (general consumer products):

    • Encrypted

Check dm-verity Status:

Verity is used to check the integrity of your device, and device manufacturers using verified boot have a their methods for verifying the integrity of the kernel with an unchangeable key which is burned on the device at factory level.

  • To verify if you're able to change dm-verity status, type the following on your command line:

    adb enable-verity
    
  • Possible Output values:

    • Enabled
    • Disabled
  • Default Value (general consumer products):

    • Enabled
  • Example (general consumer products):

    • enable-verity only works for userdebug builds
      verity cannot be disabled/enabled - USER build


Check Security Level Patch Date:

Security Patch Level is another layer of security, to protect users from latest CVEs and exploits, Google works with partners and the public to provide patches for any Android devices to receive security updates at least once every 90 days.

  • To verify Security Patch Level date, type the following on your command line:

    adb shell getprop ro.build.version.security_patch
    

You may also check SafetyNet CTS Test, but it may be bypassed by Magisk Systemless root.


If your device has it's default values with a user build signed with release-keys then you should not be worried about root integrity check.

2
  • 1
    +1 nice details. But you may consider improving it further, some pieces of the puzzle are missing. A device can be rooted even if SELinux is enforcing, ROM build is user and signed with release keys, dm-verity and encryption are enabled. Also it's very easy to alter ro.build.fingerprint and ro.build.version.security_patch on rooted devices. Nov 25, 2019 at 1:52
  • 1
    @IrfanLatif I will improve it with more details ASAP!
    – M. A.
    Nov 25, 2019 at 14:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .