yashsingh1/xdaforums huggingface dataset:
[Magisk] chiteroman:
bruh
[Magisk] mihalis1983:
I just swithed to Enforcing, with a magisk module called "Selinux-Changer",

but still Play Integrity/safetynet not passing.

Any idea where the problem is?

Thanks
[Magisk] pndwal:
If you have a (bad) ROM with security enhancements disabled (selinux permissive) you often can't switch it on... Even if you can things often break as ROM is half baked (permissive allows stuff to work for development/testing only before those functions become compatible with security features)... The switch will work fine the other way (running permissive on a good selinux compatible ROM) for testing apps etc... PW
[Magisk] mihalis1983:
You mean that i'll never pass Play Integrity, with my Permissive rom, even if i switch it to enforcing ?

The developer of the rom writes that both Pesmissive and Enforcing are working.

The defaut was permissive.
[Magisk] Homeboy76:
I think this is the link you want: scroll down to Updating Pixel 6, Pixel 6 Pro, and Pixel 6a devices to Android 13 for the first time.

I think they wrote this when Android 13 first appeared for the Google pixel 6: 13.0.0 (TP1A.220624.021, Aug 2022)

Why?

The flash-all.bat file doesn't flash the bootloader to both slots:

13.0.0 (TP1A.220624.021, Aug 2022)

@Echo off

:: Copyright 2012 The Android Open Source Project

::

:: Licensed under the Apache License, Version 2.0 (the "License");

:: you may not use this file except in compliance with the License.

:: You may obtain a copy of the License at

::

:: http://www.apache.org/licenses/LICENSE-2.0

::

:: Unless required by applicable law or agreed to in writing, software

:: distributed under the License is distributed on an "AS IS" BASIS,

:: WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

:: See the License for the specific language governing permissions and

:: limitations under the License.

PATH=%PATH%;"%SYSTEMROOT%\System32"

fastboot flash bootloader bootloader-oriole-slider-1.2-8739948.img

Note:

Easy fix, edit the flash-all. bat file (above line) to fastboot flash bootloader --slot all bootloader-oriole-slider-9.9-9999999.img

fastboot reboot-bootloader

ping -n 5 127.0.0.1 >nul

fastboot flash radio radio-oriole-g5123b-102852-220720-b-8851166.img

fastboot reboot-bootloader

ping -n 5 127.0.0.1 >nul

fastboot -w update image-oriole-tp1a.220624.021.zip

echo Press any key to exit...

pause >nul

exit
[Magisk] badabing2003:
Yes, definitely every Pixel phone has dual bootloaders.

Download any firmware and check the flash-all script,

The very first thing it flashes is the bootloader.

Here's a proof of it

I just downloaded the latest for redfin and executed this:

fastboot --slot all --verbose flash bootloader bootloader-redfin-r3-0.5-9825705.img

And here's the output being written to both slots

fastboot: verbose: Do flash bootloader_a bootloader-redfin-r3-0.5-9825705.img
fastboot: verbose: target reported max-download-size of 268435456 bytes
Sending 'bootloader_a' (8762 KB) OKAY [ 0.359s]
Writing 'bootloader_a' (bootloader) Flashing Pack version r3-0.5-9825705
(bootloader) Flashing partition table for Lun = 0
(bootloader) Flashing partition table for Lun = 1
(bootloader) Flashing partition table for Lun = 2
(bootloader) Flashing partition table for Lun = 4
(bootloader) Flashing partition table for Lun = 5
(bootloader) Flashing partition xbl_a
(bootloader) Flashing partition xbl_config_a
(bootloader) Flashing partition aop_a
(bootloader) Flashing partition tz_a
(bootloader) Flashing partition hyp_a
(bootloader) Flashing partition abl_a
(bootloader) Flashing partition keymaster_a
(bootloader) Flashing partition devcfg_a
(bootloader) Flashing partition qupfw_a
(bootloader) Flashing partition uefisecapp_a
(bootloader) Flashing partition featenabler_a
(bootloader) Flashing partition logfs
OKAY [ 0.318s]
fastboot: verbose: Do flash bootloader_b bootloader-redfin-r3-0.5-9825705.img
Sending 'bootloader_b' (8762 KB) OKAY [ 0.348s]
Writing 'bootloader_b' (bootloader) Flashing Pack version r3-0.5-9825705
(bootloader) Flashing partition table for Lun = 0
(bootloader) Flashing partition table for Lun = 1
(bootloader) Flashing partition table for Lun = 2
(bootloader) Flashing partition table for Lun = 4
(bootloader) Flashing partition table for Lun = 5
(bootloader) Flashing partition xbl_b
(bootloader) Flashing partition xbl_config_b
(bootloader) Flashing partition aop_b
(bootloader) Flashing partition tz_b
(bootloader) Flashing partition hyp_b
(bootloader) Flashing partition abl_b
(bootloader) Flashing partition keymaster_b
(bootloader) Flashing partition devcfg_b
(bootloader) Flashing partition qupfw_b
(bootloader) Flashing partition uefisecapp_b
(bootloader) Flashing partition featenabler_b
(bootloader) Flashing partition logfs
OKAY [ 0.257s]
Finished. Total time: 1.881s

Bootloader is versioned, and it doesn't change that often, but it definitely does specially when a vulnerability is discovered.

In fact one of the main reasons of many bricks when the last time the bootloader anti rollback was triggered was because Google failed to inform / enforce users to flash both bootloaders.
[Magisk] zgfg:
If it still finds Permissive, then the module you used for switching to Enforcing didn't switch (properly)

Check with developer how he meant that both modes are working - and how to switch from Permissive to Enforcing (maybe at the time of installing the ROM, if not at his time of building)

I remember that HuskyDG did discuss about in Magisk General thread (?), saying that several parameters keep info is it Permissive or Enforcing and he mentioned that some methods do not switch properly, hence as a result it can still appear as Permissive.

If I recall correctly, he even provided a code for Terminal Emulator to check if all params properly show Enforcing (Permissive) mode

However, I don't remember details (personally I never use Permissive ROMs), I'm not sure was it like a half a year or more ago, was it in the Magisk General thread (or Magisk New Zygisk thread, or some threads about PlayIntegrity or USNF)

Try to search in the mentioned threads about Permissive mode. Other users had similar problems with Permissive ROMs
[Magisk] frenksisco:
Thank you very much I will keep it in mind (y)(y)(y)
[Magisk] WhoIsJohnGalt1979:
Followed by a reboot. Just clearing data doesn't do the job. Yeah it's a pain but please do reboot after you have cleared all data
[Magisk] ipdev:
Perfect that you note Pixel 5. 🙃

How do I boot Pixel 5 (redfin) into the prior bootloader?

I f**ked up last year and broke my golden rule.

Do NOT flash critical partitions when tired.

I updated my 4a (sunfish), and forgot to switch directories when I updated my 5 (redfin).

My 5 (redfin) is a brick now since it will not boot with sunfish's bootloader.

I only flashed it once so, if there are two bootloader partitions, I should theoretically be able to switch back to the working bootloader.

The initial concept of A/B partition scheming.

Cheers. :cowboy:
[Magisk] beeshyams:
When you say "bricked", what exactly happens when you try to boot it?

1. If it is recognizable by adb use the Pixel Flasher by @badabing2003 to flash to both slots

2. If the best you can do is go to fastboot mode (where you can't use option 1) search for "Fastboot enhance 4.x" on Github and from fastbootd or otherwise boot into recovery and sideload the correct ROM. Very scanty info on how to use it, so keep trying

3. There is also a tool "All in one" or something similar on XDA that may help

4. If you are fine with losing data use the Google provided flasher

Now, don't mistake me for an expert. I just manage through hit and try and a notch above noob.

I recall all these options because last week I bricked by 6a trying to flash a custom kernel and a combination of 1 and 2 and nearly 6 hours later was able to get back to just as it was before with no data loss, root intact, all magisk and Edxposed modules!

All the best

Edit: I was severely sleep deprived and in an effort to divert myself flashed the custom ROM... It took me 6 hours to fix because I was disoriented, tired and illogical - all this is to support your thought of not doing things when you aren't alert. In retrospect, I should have been able to fix that in an hour or so
[Magisk] AndDiSa:
@ipdev probably I've got you wrong, but can't you simply switch the active slot in fastboot?

Checking the current active slot with

fastboot getvar current-slot

and then setting active the other one with

fastboot set_active a / fastboot set_active b
[Magisk] beeshyams:
Not to butt in your convos but without getting into fastboot, if your device is rooted you can use Boot Control

Some more info here... https://android.stackexchange.com/a/252480/131553
[Magisk] Bladius:
My validation stops working after a while. Oddziwo only on 1 of 2 devices. Everything done identically.
[Magisk] shoey63:
Can't switch slots without entering fastboot.

Can't enter fastboot on wrong bootloader.

Catch 22🤷‍♂️
[Magisk] Homeboy76:
<<Edit>>

Post deleted see post #772. :rolleyes:
[Magisk] badabing2003:
@ipdev

I'm afraid this is my sentiments as well.

I fear the only option is EDL mode, seeing that this is Qualcomm chipset.

Although finding the right tools would be near impossible task, but if you do, definitely let us know.

Qualcomm EDL mode - Wikipedia

en.wikipedia.org

You can also keep an eye on this thread where they discuss various tools and approaches to unbrick a Pixel 6 phone.

https://xdaforums.com/t/guide-unbri...ixel-6-pro-raven.4441245/page-7#post-88824253
[Magisk] pndwal:
Many thanks for your insight!... The subject confuses me because Google speaks of the bootloader controlling slots (as well as seperate bootloaders existing in each... 😬), but I'm starting to understand your references a bit more...

My current understanding is that bootloader has both a/b parts (looks like quite a number of partitions according to your posted output) and single partition (common) parts (or why should Google warn for P6 that after flashing (A13) update incl. B/L (even to only one slot) you will no longer be able to boot previous (A12) builds (even in the previously bootable slot where neither the ROM nor the B/L have been updated) due to the anti-roll back version for B/L having been incremented in the opposite slot only?... At least the provisioning for anti-roll back version enforcement must be in a common partition*), but I have only dug into what the single partition designations are very generally as yet...

* From @Homeboy76's earlier link:

... Eg this:

https://xdaforums.com/t/info-boot-process-android-vs-linux.3785254/post-76407669

... The only common B/L partition in your P5 update seems to be /logfs, but looks that's actually "a Linux log-structured and scalable flash file system" or something to do with that.

But some common partition must contain the common current anti-roll back version (with some type of anti-tampering/encryption)... Seems there are many other common B/L partitions that simply aren't included in B/L updates necessary... The statement "The bootloader should also determine which slot to load" must refer to a common bootloader it seems.

https://source.android.com/docs/core/architecture/bootloader/updating#slots

Anyway, despite Google references to bootloader's in each slot, it appears that like anti-roll back versions, OEMlock settings/flags are also stored/set in common B/L partitions and that implementing a setup where both a rooted system and a stock system meeting either PI deviceIntegrity or strongIntegrity (both of which would require a 'locked' bootloader) exist in seperate slots on the same device may be virtually impossible even if two 'bootloaders' exist...

Then again, as we "unlock" simply by bypassing the primary bootloader (which is actually always 'locked'), perhaps a way may be discovered to 'un-bypass' the primary bootloader on only one slot to cause one OS to boot as properly locked while the other doesn't... (😋)... Seems highly improbable to me ATM however... 🙃 PW
[Magisk] bombadier:
Pixel 7a, today I just noticed that it has started failing device integrity, i am only passing basic integrity, has Google changed something? I know that strong integrity was passing for a short time, google wallet still seems to be working at the moment, anybody else suddenly started failing device integrity?

Using Displax 2.4.0-MOD_2.0 and everything was working fine
[Magisk] anthonnyb98:
I'm the same, pixel 7 pro stopped passing the integrity of the device.
[Magisk] Lord Sithek:
Take a look here: https://xdaforums.com/t/module-play-integrity-fix.4607985/post-88829773

So go back to 1.3 version
[Magisk] anthonnyb98:
Now working with version 1.3. Thank you bro!
[Magisk] bombadier:
Thanks for the advice have switched back to version 1.3 and all is good in the hood once more, I like fixes that are easy :D
[Magisk] crypticc:
Are you UK?

I have nearly identical setup but can't get Citi working. Others are fine
[Magisk] crypticc:
Is there downside to defining for all subprocesses? I always expand and pick the subprocesses in addition to the unexpanded/main.

E.g. includes the the "...isolated" and "...zygote" processes of the various wallet, store, Banking, etc.

The app with a "...zygote" subprocess fails whether I pick all, none, or just the main process. Really getting to the point of thinking about unrooting.

All other apps and wallet etc works although MS portal has timing issue and complaining on first open, but with option to recheck passes.
[Magisk] Bad Bimr:
No I am in the USA. Some have had success by unrooting, getting everything to work and rooting again. Others have tried using older versions of the app. Your miles will vary with both as currently everything seems like a crapshoot. Good luck.

BB
[Magisk] immortalwon:
I don't upgrade my android security patches, and never had a problem with the original k-drag0n patch
[Magisk] crypticc:
I meant all the way to relock bootloader which wipes device. I take it you don't mean that.

I'm rooted for sole purpose that devices found unlocked bootloader. I didn't even have root but for that precaution. So if I unroot without locking bootloader won't app then find that and SN fail, etc.

I can try again tonight.
[Magisk] V0latyle:
Yes, you are correct - you can only "hide" the unlocked bootloader to a certain degree by using root + mods; there are some things that can't be hidden or spoofed, such as the chain of trust that unlocking the bootloader breaks.

I tried to explain that a bit here under What causes a device to fail Play Integrity Checks?

Locked bootloader on OEM firmware should pass everything - unless pre Android 8, then it will only pass BASIC+DEVICE

Unlocked bootloader on OEM firmware without any other modifications such as root will fail STRONG and BASIC, probably DEVICE

@pndwal any thoughts on locked bootloader + custom root of trust? I assume this would either have similar result as unlocked bootloader, or fall back to basic attestation?

Also I made some changes to the OP, let me know if there's anything you think I should address
[Magisk] zgfg:
What do you mean here by custom root of trust - and how would you install if the BL is locked (or keep it if you first install and then relock BL?
[Magisk] V0latyle:
Some custom firmwares such as CalyxOS include a custom root of trust; locking the bootloader on these results in YELLOW state:

We are able to spoof the bootloader state via props, but the chain of trust itself is separate, and I'm not sure how this affects it

I believe the USNF mod disables DenyList on Play Services

While Play Services can detect root itself, I'm not sure if this is used in any other way but for the PI verdict, so I don't know if it would affect whether your banking app works
[Magisk] zgfg:
It's not only about the locked BL but also about a certified ROM.

Hence IMO, if that custom ROM was not certified, even Basic Integrity couldn't pass
[Magisk] Lughnasadh:
Just some information I ran into that I thought some in here may be interested in...

https://twitter.com/i/web/status/1628786488187179010

Accurately attest the integrity of devices with DICE | Trusted Computing Group

With 20 billion connected devices expected to be in use by 2030, the increasingly digitised world requires more advanced technological innovations to combat the proliferation of cyber-attacks. With more Internet … Continue reading "Accurately attest the integrity of devices with DICE"

trustedcomputinggroup.org
[Magisk] V0latyle:
I know. But. Anyone can potentially apply for GMS certification...
[Magisk] Nergal di Cuthah:
Excuse my ignorance but it seems that is for hardware releases not custom ROMs
[Magisk] V0latyle:
Not necessarily:

So, it would be entirely possible for a vendor such as CalyxOS to get their software GMS certified, since they use already approved devices such as Google Pixel
[Magisk] zgfg:
When I opened that Google's https://g.co/ABH = https://support.google.com/android/answer/6185381 page from your yellow warning attachment, it looks to me as a chicken or egg problem

Ie, if the custom ROM was indeed certified, then IMO the yellow warning shouldn't apply
[Magisk] V0latyle:
I think we are talking about two separate things here.

I get what you're saying - that a device + software combo is generally certified. But the yellow bootloader warning applies when a custom root of trust has been set by the user. The bootloader is evidently able to determine whether the root of trust is OEM or custom. This is separate from GMS certification, which is more oriented towards compatibility. The open nature of the Pixel/Nexus devices lends themselves easily to custom firmware, so I would imagine that one could potentially get a custom ROM certified for GMS when it's intended to be used on such a third party platform.

So at least from my perspective these are two pieces of the puzzle:

* if a custom root of trust is set, could it be used to provide hardware backed attestation?

* Android running on an approved device such as Google Pixel should be capable of passing BASIC

* Android built that is GMS certified and has passed CTS should be capable of passing DEVICE
[Magisk] zgfg:
I see what are you saying. We don't know how Google would treat that in practice
[Magisk] KProject:
Good!

V1.2 is PASS SN in Feb security patch 👍
[Magisk] pndwal:
Yup... Hardware will still attest to custom keys/signing used / custom root of trust set, ie. Yellow state... And that's still technically a Verified Boot issue (verified boot failed) category...

https://source.android.com/docs/sec...ow#communicating-verified-boot-state-to-users

You'll need verified Green state to pass strongIntegrity...

... I don't think google will ever facilitate fallback to basic except for broken attestation implementations... The whole point is reliable/true measurements... The hardware backed signals were always correct; we just need basic fallback to allow us to intercept and spoof. 😜

- In other words, I'm pretty sure Yellow state needs much the same spoofing to pass deviceIntegrity despite locked bootloader on devices like Pixel and OnePlus that allow this.

... I'll be sure to take a look at that later. 👍 PW
[Magisk] pndwal:
That potential was actually mooted by Shawn Willden, 'Tech Lead for Android hardware-backed security subsystems' in a conversation with Luca Stefani, 'Director for LineageAndroid & Developer' on twitter some 3 years ago that I commented on a number of times here, eg originally here:

https://xdaforums.com/t/magisk-general-support-discussion.3432382/post-82011917

and here:

https://xdaforums.com/t/magisk-general-support-discussion.3432382/post-83281243

here:

https://xdaforums.com/t/magisk-general-support-discussion.3432382/post-85047869

... and I put a link to the conversation here:

https://xdaforums.com/t/magisk-general-support-discussion.3432382/post-85136019

... Seems the potential is there, but still no serious takers among custom ROM Devs... And I was hoping that that old convo might grow legs...

Well it simply can't pass this as things stand with user keys / custom root of trust...

However, if a solution was arrived at such as Shawn W proposed to Luca S, LineageOS would boot with Google certified keys (not user/custom keys) and this means it could be run on any supported/compatible device as it would have native certification giving AVB green state, ie both PI deviceIntegrity and strongIntegrity passing natively! 😋

Of course, Luca's concerns about ability to sideload gms/GApps (which Google allows end users to do but not custom ROM providers to include with ROMs, although many ROMs do do this, even XDA hosted ones) and mods would need addressing... The GApps issue seems easy as certification would allow LOS to bundle gms/GApps... I'm guessing any add-on mods would need to be assessed on a case by case basis however, and it may only be possible to allow these if integrated in ROM and approved as part of ROM for practical reasons... And obviously it would require a quantum policy shift to allow either Magisk flashing or built-in Magisk/root as this will clearly break "the compliance tests" and would certainly "subvert the security model"...

This means with the right commitment and investment in persuing Google certification, a custom ROM/OS may well be not only achievable but within reach!...

However these builds could never offer ability to add/sideload the custom mods custom modders are used to with locked bootloader as I see it... It would still be a choice between certified custom ROM w/ green verified boot attested to by hardware key-backed verdicts, or Magisk/mods/root...

This is much the same choice we have with stock ROMs... but I think I'd much prefer certified LineageOS to any OEM's stock offerings, especially w/ bootloader locked! 😜

Well, with certification (whether from 3PLs or Google technicians) all verdicts incl. strongIntegrity would pass natively... AVB state is green, not yellow since the root of trust (verification key) is not set/settable by user...

Recommended boot flow:

https://source.android.com/docs/security/features/verifiedboot/boot-flow

See also:

https://android.googlesource.com/platform/external/avb/+/master/README.md

🤠 PW
[Magisk] Malik Sayriii:
Thank you so much , it worked so good ❤️

CTS passed ✅

But my 1 banking App is still detecting root despite in denylist, tried to hide Magisk App as well but no luck...

Samsung Note 10+

oneUI 4.1

Custom rom

Android r
[Magisk] Homeboy76:
You should be using Displax's safetynet-fix-v2.4.0-MOD_1.3-...zip module.

Are you using that version?
[Magisk] V0latyle:
2.4.0 Mod 2.0 still working for me on Pixel 5. Had to reset device fingerprint - was spoofing Pixel 2 using MHPC
[Magisk] V0latyle:
@pndwal if you want more information on the whole Pixel 6 / 6P / 6a bootloader anti roll back thing, I wrote some PSAs on the topic:

Here is the one for the Pixel 6. Might be a better place to discuss this issue so we aren't derailing this thread
[Magisk] sawdoctor:
Strange it only passes basic integrity on the pixel fold and others but safetynet-fix-v2.4.0-MOD_1.3-...zip passes both on nearly all. Wonder what Google changed? It's only been the last few days people have started to fail device integrity on devices
[Magisk] V0latyle:
Well, after seeing the recent revelations here, I ran a Play Integrity check and only passed device. After restoring default props in MHPC I'm now passing basic again. So maybe it has something to do with devices that have first_api_level=33?
[Magisk] Displax:
Yes. Google finally removed buggy "walleye" fingerprint from whitelist.
[Magisk] V0latyle:
Yeah, I know. I was answering @sawdoctor's question
[Magisk] Displax:
There were two stages of fixes. In the first Google fixed the STRONG passing, in the second (a couple of days ago) untied this fingerprint from the dependency with ro.product.first_api_level, that's why DEVICE_INTEGRITY starts failing too on devices with ro.product.first_api_level >= 33.
[Magisk] V0latyle:
Interesting how we were able to pass STRONG but this just goes to show how much they can tinker with things on their end