My company thinks my sideloaded e os is rooted

/e/OS Devices Asus
1

Regain your privacy! Adopt /e/OS the deGoogled mobile OS and online services

phone
phone427×374 173 KB

Hello I have an unlocked Motorola G5 2024 I sideloaded the latest OS …all good but when I Iy to use DUO with my company it denys the MFA push I need for accessing company networks nor do my DUO 6 digit codes work …all because the phone has a reloaded OS and says my phone is either rooted or tampered with it is definitely not rooted ..do we try to lock the phone? Without it reverting to stock OS?..what do I need to do to make this phone appear safe for DUO. and company use?

2

have you tried to modify buil.prop ?

ro.debuggable=0
ro.secure=1

not sure it will be enough…

3

Hi Piero, according to chatgpt, and this could be verified or denied , here is what is speculated:

Short answer: there is no single “file” DUO is reading. It’s querying Android security state via system APIs. Your /e/ OS + unlocked bootloader combo trips those checks, even if the phone is encrypted and not rooted.

Now the practical breakdown :backhand_index_pointing_down:

What DUO is actually checking

Duo Security doesn’t inspect your filesystem. It asks Android (and sometimes Google services) questions like:

  • Is the bootloader locked?

  • Is verified boot intact?

  • Does hardware-backed keystore exist?

  • Does this device meet enterprise integrity requirements?

That information comes from system properties, keystore status, and attestation APIs, not a file you can edit.

The smoking guns (what fails on your phone)

Because your phone is bootloader-unlocked, Android reports this state:

:red_circle: Bootloader / Verified Boot

  • ro.boot.verifiedbootstate = orange

  • ro.boot.flash.locked = 0

  • ro.boot.vbmeta.device_state = unlocked

These come from AVB (Android Verified Boot) and vbmeta, not a normal file.

Even if:

  • :cross_mark: Not rooted

  • :cross_mark: Encrypted

  • :cross_mark: Secure OS

→ Unlocked bootloader = automatic enterprise fail

:red_circle: Hardware-backed keystore (critical)

DUO expects:

  • TEE / StrongBox-backed key storage

  • Keys generated after boot verification

Unlocked bootloader → keys are flagged as untrusted
So:

  • Push approvals fail

  • 6-digit & 3-digit codes rejected server-side

This is invisible to you but fatal to DUO.——————————————————————

So there you have it. May I ask how I can at least bypass that warning screen I see after the ‘Hello Moto” splash .

its the warning screen that says bootloader is unlocked.

  1. can I either bypass this screen or somehow relock the bootloader now that I have the OS?

than k youi

4

don’t trust chatGPT blindly.

on my FP3 running stock “community” /e/OS with unlocked bootloader i got :

piero@HP-p6-2038fr:~$ adb shell getprop ro.boot.verifiedbootstate
green
piero@HP-p6-2038fr:~$ adb shell getprop ro.boot.flash.locked
1
piero@HP-p6-2038fr:~$ adb shell getprop ro.boot.vbmeta.device_state
locked
piero@HP-p6-2038fr:~$ adb shell getprop ro.debuggable
0
piero@HP-p6-2038fr:~$ adb shell getprop ro.secure
1
5

Hi,

Agree,

I do not just accept chatgpt, and verify things like this. But is it in essences saying what is correct. That DUO looks at a multiple of things. Your output is interesting. But what is it inferring?

That we can set our phones to be detected as safe for DUO? That we can lock our side-loaded /e OS and initiate the Trust that is required?

Chatgpt is mostly correct.

it also gave the same output

  • ro.boot.verifiedbootstate = orange

  • ro.boot.flash.locked = 0

  • ro.boot.vbmeta.device_state = unlocked

what does it take to render a home grown version of /e integrity safe so DUO doesn’t complain.

Thank you.

6

you may temporary boot to TWRP without installing it

fastboot boot twrp.img

and modify build.prop

7

As a Cisco Security app it is likely to do thorough security checks.

If latest attestation APIs, secured by keystore are required, this will be beyond current /e/OS and micro-G as potentially illegal [1] hacking of the Google proprietary keystore is required to get highest attestation level amounting to “just like Google”.

[1] Legal / illegal: ‘Tricky Store - Bootloader & Keybox Spoofing’ https://xdaforums.com/t/tricky-store-bootloader-keybox-spoofing.4683446/post-89641247

8

It’s a long shot, but as someone who manages Duo both for work and for personal usage…The Duo environment can be set to ignore a phone’s root state…one can do it environment-wide, or on a per-device basis.

It might be worth:

  1. asking the IT department to grant your device an exception and disable the anti-tamper qualification for your device,

  2. asking your immediate supervisor for a work-issued phone if they won’t,

  3. having the IT department set your device to phone call verification mode where they verify login via phone call (Duo does support this), or

  4. getting the absolute-cheapest Wal-Mart garbage phone who’s only task is to run Duo; you don’t even need phone service tied to it, just install Duo, have them send you an activation link, get that activation link to your garbage phone, and activate the program there. As long as you have wi-fi, you can receive push notifications.

Depending on context and position, it probably makes the most sense to go down this road. Even if you manage to successfully hide your phone’s config state, it’s a cat-and-mouse game that’s going to be more headache than it’s worth long-term. If IT won’t grant you an exception, I wouldn’t recommend trying to keep a step ahead.

1 Like
9

Thank you. Agreed I’ve been in deep conversation with the DUO folks. We did discover I could use another old /e wifi only phone, a galaxy 9 but if I had my way they wouldn’t be using my personal phone at all. But they do have an alternative.

A YubiKey 5C usb for encrypted mfa and certificates. I can authenticate with it as it plugs into THEIR coorate laptop. The naivete, and sheer stupidity. It boggles the mind that a corporation puts the load of security authentication on employees personal phones. REALLY?

As a security and data privacy professional since when did peoples private phones become the new key to the kingdom.

And “They never expected someone out of thousands of employees to have a phone that DUO failed on?” what then? no plan B, Even getting the Yubikery-manager application loaded on my company laptop requires one to have DUO working on the phone, Sheer illogical falles, Companies truly take audacity to new levels. organisation like this that think people personal phones are safe should have their heads examined .

I hope someone who reads this realises that people phones get stolen and destroyed. Then what you want to loos your preciousd productivity while they scramble to get a new phone. I have had it up to here with these GD phones.

Are they living in a fantasy bubble land. ans. yes

Sorry had to vent. Thank you all! and happy New Year All

10

It boggles the mind that a corporation puts the load of security authentication on employees personal phones. REALLY?

This ultimately does make sense…the point of the 2FA is that the person attempting to log in is the person possessing an agreed-upon phone, and vice-versa. Now yes, I do agree that in a perfect world, companies would issue either work phones or keyfobs, but I’m not one to say that authentication in isolation is somehow an unreasonable intrusion. In fairness, and to your point, I think that they should be willing to accommodate your choice to use /e/OS if they’re going to have that expectation, but I don’t think it’s somehow a huge security hole to allow a personal phone to function as a second factor in a 2FA setup.

As a security and data privacy professional since when did peoples private phones become the new key to the kingdom.

They didn’t - they’re one of two keys, the other being the password one must type in so the Duo push is sent. For maximum pedantry, one’s mind is also required to remember the password.

And “They never expected someone out of thousands of employees to have a phone that DUO failed on?”

THIS part, I completely agree with. One of my deployments involved a user with a phone still running Android 7, which Duo doesn’t support. We ultimately set him up to get voice calls. To me this is a bigger security concern than running Duo on a rooted phone; the latter requires a passcode or biometric unlock to approve a Duo push, while the former does not. Still, we knew there would be exceptions and we did our best to work with them. I see no reason they can’t disable the tamper exclusion in your case.

Even getting the Yubikery-manager application loaded on my company laptop requires one to have DUO working on the phone, Sheer illogical falles,

Again, agreed - it should be possible to work around this for the initial install; can’t they log in as admin for a few minutes, or add the phone of another user provisionally to get past the prompt for the initial config? I’ve done both of these where needed.

organisation like this that think people personal phones are safe should have their heads examined .

I don’t think the phones need to be “safe” in this context; they aren’t housing company data, or at least they shouldn’t be. Phones need to be able to verify that the ‘something you know’ (the password) matches the ‘something you have’ (the phone), so in my opinion, a rooted phone readily fits that bill and should not be a problem if the only thing the personal phone is responsible to do is to handle 2FA.

I hope someone who reads this realises that people phones get stolen and destroyed. Then what you want to loos your preciousd productivity while they scramble to get a new phone. I have had it up to here with these GD phones.

Agreed; that’s indeed a cost/benefit analysis; if a user loses their phone and they can’t work because of it, because the company chose to save money over provisioning them work phones, that shouldn’t be a problem. I’m sorry your management structure is revealing its messy mindset in this manner.

Sorry had to vent. Thank you all! and happy New Year All

Same to you my friend.

Cheers!