yashsingh1/xdaforums huggingface dataset:
[Magisk] Iridule:
I also asked it if it could help me search for working prints and how to modify TEE to pass Strong with unbanned keybox. It told me some long lecture about ethics and how it couldn't help me bypass security measures. :(
[Magisk] chiteroman:
View attachment 6079340

Thank you so much 🤗😝
[Magisk] Vision:
@chiteroman

We must say a Big Thank you for all your contribution and great work in all your projects. Keep the good work (i hope and wish this with Strong go well)

We Appreciate.

We all know where to go for a donation
[Magisk] osm0sis:
Your keybox got banned and you had to find a new one? :p
[Magisk] Vision:
Yeah, classic AI :cry::ROFLMAO:
[Magisk] chiteroman:
Nope, I had lost the fingerprint to pass Strong 😂😂😂
[Magisk] Vision:
As always we confused again 😂🤣
[Magisk] Vision:
@chiteroman

A question, can make your BootloaderSpoofer work standalone with Dobby or Shadowhook, like your PIF and no need LSPosed ?
[Magisk] chiteroman:
Yes, it's possible, but app may detect code injection :(

Also, some apps may crash injecting code.

It isn't a reliable solution, that's why I didn't do it.
[Magisk] eac5:
This is old stuff. Can be done on many current devices, but not going forward. RKP has already defeated this very strategy. See https://www.xda-developers.com/google-remote-key-provisioning/
[Magisk] Vision:
Oh understand, i ask because i don't use LSposed, and as understand either as magisk module can work because apps detects the injection.

Thanks for answer. I appreciate
[Magisk] BrimoFan123:
I really like your vision of what the war with Goolag could look like :)

Honestly, it's a war.

Other guys have already mentioned this: what security does it provide to use Wallet on phones with stock ROMs over 10 years old and blocking the use of rooted phones but fully patched with the latest Android security fixes?

Are Goolag obsessed with people who are much more security aware and just want more control over their devices?

If so, the idea of making their miserable lives more miserable by burning the encryption keys seems like the right response.
[Magisk] V0latyle:
I'd be less worried about code injection and more worried about getting keys revoked. Granted, I don't really understand how this whole experiment works, but Google has already made it clear that they will revoke any compromised or leaked keys, so I have some serious reservations about the longevity and long term effectiveness of this endeavor...
[Magisk] CZ.Kostra:
FP XEU Checker

Minor improvements and bug fixes.
[Magisk] Flr Power:
But switching Sim card for using that other phone is not really practical 🥺
[Magisk] dmenezes:
Thank you for that; I had heard about Remote Key Provisioning but did not know the details.

To anyone else following this, that's the critical part:

A unique, static keypair is generated by each device, and the public portion of this keypair is extracted by the OEM in their factory and submitted to Google's servers.

(...)

When a device is first used to connect to the internet, it will generate a certificate signing request for keys it has generated, signing it with the private key that corresponds to the public key collected in the factory. Google's backend servers will verify the authenticity of the request and then sign the public keys, returning the certificate chains. The on-device keystore will then store these certificate chains, assigning them to apps whenever an attestation is requested.

@eac5 is right, this would make it easy for Goolag to defeat the SoC-decapping guy in the scenario I described, because he would not be extracting an OEM-wide key pair, neither a model-wide key pair: the keys in the SoC of each and every phone would be unique to that individual phone.

So when Google detects this key pair being used simultaneously by more than one phone, and then ban this particular key pair: then only the device used by the SDG (and anyone he distributed the extracted key pair to) would be affected.

Devious! And apart from breaking into the OEM and compromising the key pair generation/submitting process, I don't see a way to bypass it.

But... this is a very complex process, and there are tons of ways for Goolag to fail in implementing it properly (and Google managed to fail in their much simpler SafetyNet scheme, with that security bug that allowed us to have perfectly verified SafetyNet phones for ages before they got around to fix it).

Also, the part about each device securely generating its own key pair in the factory, the factory extracting *only* the public key and submitting it to Goolag, looks specially onerous for the OEM -- so I'm sure many (most?) of them will take shortcuts here, specially with the narrow profit margins they have to operate under.

So, between Goolag's own incompetence in implementing this complex design and the OEMs obvious self-interest in cutting corners to get their part done, I'd bet there's going to be plenty of opportunity for things to break and be exploited.

I guess we will all see eventually.

Thanks again @eac5.
[Magisk] dmenezes:
I would keep the sim card in the rooted phone and turn on its hotspot, and have the unmodded phone access the internet through it.

No need to swap sim cards that way...
[Magisk] asisandroid:
It is still mind boggling to me that google is worse than apple when it comes to rooting now, at least when it comes to the normal user who does not have a 2nd phone for many apps
[Magisk] dmenezes:
And then when you told it to go eff itself in the lake by stuffing that lecture where the sun never shines, how did it react? 🤣
[Magisk] Flr Power:
True, but you would still have to switch around once in a while for some apps that requires SMS registration.
[Magisk] dmenezes:
Or you could simply enter the SMS code manually into the app; I haven't seen one yet that doesn't allow it.

Or are there any apps that require the SIM to be physically present in the phone where it's being installed/activated?
[Magisk] pndwal:
I think WhatsApp and/or TG(?) do for selecting primary device... PW
[Magisk] pndwal:
If you mean legitimately (both these passes can be had with spoofing, but not STRONG using PIF), it's only essential for DEVICE...

BASIC can pass without a CTS/VTS certified fingerprint and is intended to verify basic security/integrity for custom ROMs... Basic security is broken by compromised (eg permissive) selinux, root and many other non-standard configurations however. 👀 PW
[Magisk] Vision:
Yeah, i have done this many times, works for me, only if change something recently
[Magisk] simplepinoi177:
Hi thread. Due to certain "technical difficulties" circumstances, I've been away from XDA since the 29th (two Thursdays ago), right about when the whole big 95% mass banning hit.

I'm trying to catch up now, but it's literally 69 pages of catching up. I've caught up to Page 611, so I don't know if what I'm about to say has been broached already, but, I don't know if I'll be able to read all the pages left today and/or by the time I am back consistently, so I don't wish to wait....

But based on what I've been reading since Page 580-611,

it doesn't seem anyone has brought up the idea/possibility that Google might be banning/getting-triggered by something of Play Integrity Fix's & Play Integrity Fork's code or "injection" than it is actually banning (most) fingerprints...!

I mean, this would make the fact that the xiaomi.eu fp isn't banned (yet) even though it's the most used (seems to be the only one working), and how most (all?) of the fingerprints from even the most obscure devices (like even Chinese or Indian; those that aren't in any dumps) can't even pass, make more sense than banning 95% of all fingerprints. And, I imagine, it's easier for them to have found something in the module(s) to simply block when detected & triggered than it would be to ban by OEM, devices, fields/values from fingerprints -- however P.I.G. goes about it.

Although I did remember reading how someone jokingly theorized that the xiaomi.eu people made a secret arrangement with Google for theirs to be banned with a good amount of delay than everything else....😅 . Hey, you never know.... 😝

Just a thought.

I'm now going to try and catch back up with everything on XDA I've missed, as well as still having difficulties being able to be on a working system and connect to the site -- so I may not see or be-able-to reply to this post. Again, it was just a thought to bring up (maybe even lead to a discussion here), just in case it hadn't been brought up yet in the further 38 pages/10 days.

Cheers everyone!
[Magisk] Vision:
You remember right 🤣😂

Post in thread '🔧 [MODULE] Play Integrity Fix (SafetyNet fix)' https://xdaforums.com/t/module-play-integrity-fix-safetynet-fix.4607985/post-89376413
[Magisk] HippoMan:
The following thread was meant for ranting about this. It's totally on-topic there ...

https://xdaforums.com/t/discussion-magisk-the-root-hiding-and-mod-hiding-cat-and-mouse-game.4425939/
[Magisk] trevtdogg:
I don't really understand how if as you possibly suggest google are detecting something in the PIF modules and using that to block device integrity, how does using the xiaomi FP still work then?

if it's module specific then all fp's should fail with those modules regardless, right?
[Magisk] markfm:
I suppose that's possible, however my two current good jsons were both harvested after the leap-day banning round, and testing similar make/model prints from the same vintage as the two good ones (phones that had monthly firmware releases) has produced json files that fail Device (while those two good json still work).

Given I have two post-mass-ban prints that work while a bunch of similar ones don't indicates to me that Google likely really did go all-in on a boatload of bans, but happened to leave out a print here-or-there (why, I do not know, but am thankful they left a few un-banned).
[Magisk] HippoMan:
The definition of the word "evil" encompasses some extremely despicable acts, and therefore that now-abandoned "Don't be evil" watchword always seemed to me to be setting a very low bar. :)
[Magisk] simplepinoi177:
I was thinking more along the lines of that might be the reasoning for why such a massively used FP is passing but none of the obscure not-from-a-dump-site aren't. I think Google hasn't mass banned every single fingerprint because they still haven't figured out how to

for-sure

block it without accidentally also blocking devices that aren't rooted/actual-non-spoofed-fingerprints (i.e. build.prop) -- which is why not every fp is failing that uses the module. So, I imagine (as an alternative theory), instead of banning fingerprints, they're going after the way the module works instead. I imagine it's how they got 95% on even obscure/not-from-dumps but not the one most used.

Fascinating about how you got the 2 -- it helps to know what to look for when/if the xiaomi.eu one (the one after current) ends up not working in the future.

I'm actually thinking the inconsistencies of what ends up working and doesn't (the 5% or yours) speak towards something about the module that they weren't able to counter or not willing to risk accidentally banning all of that OEM rather than them banning by OEMs and ROMs -- otherwise you would think similar ROM (just different "vintage"s) would all pass as the ones you have found or the 5%.

EDIT: I'm sure this is fairly obvious, but in case it still needs to be stated, I have absolutely no knowledge or experience module developing or the inner workings of coding anything. So please forgive if these are pure ignorant suspicions/theories...
[Magisk] markfm:
What still passes is kind of weird, for the prints I've been harvesting. A print from Oct 2020 might pass, while those on either side of it fail Device. Same manufacturer/model..., same Android version, etc.

It's almost like the backend logic that generates the bans has a random glitch, allowing some escapes. Either that or somewhere someone keeps exactly one sample device of a given make/model, with one specific firmware load, and doesn't ban that print because they want it for testing things.
[Magisk] osm0sis:
Today I was thinking about it and was wondering if it's like actual decimation, i.e. eliminating all but 10% to make a point. Except in our case it's more like 5% were allowed to survive.
[Magisk] vMAC:
Just to close the loop on this. I was able to take OTA today as normal.
[Magisk] chiteroman:
What? Pls don't...

View attachment 6027819
[Magisk] chiteroman:
I think the problem was system STL + LTO, linking to default Android libstdc++.so and LTO seems to be unstable in few devices.
[Magisk] Exbadboy:
Hi.

This fix the issue where my Wi-Fi calling was not working, thank you very much! 😊
[Magisk] alfian89:
Magisk is still detected in several banking applications and forced to close. even in virus scanner apps like malwarebytes, root is detected. I am using the latest Magisk Delta
[Magisk] V0latyle:
Many apps use a third party security engine to specifically detect the presence of Magisk. There is no guaranteed workaround. You can try Shamiko and HideMyAppList but they may not work.

The only thing that will work for sure is to reflash factory firmware and lock the bootloader.
[Magisk] immortalwon:
I am confused why people still use Delta when Alpha is much better and closed source. Google devs and other developers cannot see the source code without extensive reverse engineering. If the purpose of using Delta is to hide apps, why not just use alpha with hidemyapplist?
[Magisk] chiteroman:
The purpouse of this module is for passing Play Integrity and SafetyNet, not for hiding root.
[Magisk] chiteroman:
KernelSU >>>>> Magisk Alpha
[Magisk] immortalwon:
I want to try KernelSU badly on my A11 one plus 9 device, but I need to spend time learning linux. Can't wait until I figure it out unless someone has an easy guide in english for me on how to compile kernel sources?
[Magisk] alfian89:
Not all ROMs can use KernelSu
[Magisk] alfian89:
Yes, it is true. but thanks to that module some applications cannot detect Magisk. but some banking applications that I think are cheap applications 😅 they are really afraid of Magisk. In my country, BCA Bank doesn't really care about Magisk. so they pass all certificates even though magisk is not hidden.
[Magisk] alfian89:
I think alpha is more risky. Very rarely are alpha users visible, even in discussion channels or in groups
[Magisk] alfian89:
Saya sudah melakukannya, masih tidak berhasil.

Mod Edit: English Translation Below

I've done it, still doesn't work.
[Magisk] iruiz2:
Some people don't trust closed source software with root capabilities on their phone. If the dev is tempted by the dark side...
[Magisk] immortalwon:
valid point, but the worst that can happen they keylog or change your password. All which can easily be reversed with a fresh firmware flash and changing your details. It's tedious but not impossible to fix.
[Magisk] shoey63:
Paranoia about Magisk Alpha being untrustworthy on account of it being closed source is unfounded.

The Devs are huge contributors to the Magisk source code and are even recognised as such in the official app under Follow Us
[Magisk] zgfg:
Open Kernel.su and follow their instructions - better than if somebody gives you third-hand (what is also off-topic here)
[Magisk] sawdoctor:
It really is a double edge sword though isn't it. If you make it open source then your making it easier for Google/app Devs to block it. If you leave it closed source then you are basically giving a complete stranger the ability to do anything they want to your phone. I do also get your point about how much they contribute to the official Magisk
[Magisk] wolfsoft81:
Hello ! Can you add this prop in to your main.cpp. Some app check debug mode enabled

'init.svc.adbd=stopped'
[Magisk] chiteroman:
You can add it by yourself in service.sh or system.prop
[Magisk] osm0sis:
And you do or don't have a PIF module installed? And which Pixel device?
[Magisk] bdr127:
What is that package name for the Magisk app ("tvycpm.ifub")? Is that one of the Magisk forks? Internet search came up with nothing...
[Magisk] beeshyams:
Yes, all Indian banks I and my wife deal with (four of them) require the SIM to be on the phone the bank app is installed... I'd guess probably alll Indian banks work same.

UUnfortunately, the Hotspot Idea wouldn't work but it's a good idea!
[Magisk] osm0sis:
It's just hidden..
[Magisk] niko26:
You mean a randomized name so that it is not found thus hidden. ;)
[Magisk] osm0sis:
Magisk's settings refer to it as "Hide the Magisk app", so yeah, tomayto tomawto.
[Magisk] Nergal di Cuthah:
PIG is Thanos, he's just making the universe better by eliminating 95% of working fingerprints.
[Magisk] MPK99:
Hello. What's the point in validating BASIC & DEVICE, when STRONG doesn't ? What are the use cases of validating the first two?
[Magisk] sawdoctor:
Google wallet/Google pay and rcs messages work with passing device and basic they don't need strong. If you don't pass the 2 they won't work
[Magisk] sawdoctor:
I only answered your question as to why people wanted basic and device
[Magisk] shoey63:
Good for you.

But your particular set-up and app usage is irrelevant here as you don't need, or intend to use PIF.
[Magisk] MPK99:
Yup. I'm like either put both foot in the dirt or none. I don't like putting only one.

Then I'm not sure why so much hazzle just for these to work. Aren't there any other important usecases you're missing ?

What I believe is once a device bootloader is unlocked, that's where strong integrity is borked.
[Magisk] makeyourself:
It's mainly for Google Pay. Where I am that's basically the only contactless payment method available on Android.

What you say about STRONG is true but as already stated you don't need to pass STRONG for Google Pay, just DEVICE.
[Magisk] dmenezes:
Working on a browser (specially a FOSS one) is how it's supposed to be.

Unfortunately one of the banks l use won't even load its banking page in a mobile browser (even if the browser is set to desktop mode), and its app won't even show up in Google Play, much less work, unless they phone has at least DEVICE_INTEGRITY.

Also, there's quite a few apps (even non-banking ones) that behave exactly in the same way; Netflix and Uber Driver are two that come to mind.

So, consider yourself extremely lucky if you can do everything you need on a mobile using a browser; that's definitely not the rule out there.
[Magisk] Vision:
Yeah, even more apps and games now not showning in Google Play if not pass 2/3

The first time happens this, i figure out even games not show it and try for hours to see what happens, before learning for need pass 2/3
[Magisk] V0latyle:
@sawdoctor explained this to you already. Many of us use Google Pay and RCS. This may not be relevant to you, but it's relevant to us, and this is the only fix we have available on rooted devices. Your situation is evidently different, but you are the exception rather than the rule in this thread.

My point is, if it doesn't apply to you, don't argue against it because it's still important to us.
[Magisk] Vision:
I tired with all this.

Go back to Java Apps&Games (i hope Google can't block it) 😂🤣🥲
[Magisk] sawdoctor:
Some banking apps seem to require both device and basic to work and yes to some people Google pay/wallet is really important as it's their only method of contactless payments (other than card). Some countries rcs is extremely popular others not but the point being gpay and rcs is extremely important to some users simple as that
[Magisk] osm0sis:
Hmm, looks like the ZygiskNext MOD needed for APatch support has disappeared... 😲😬

GitHub - Yervant7/ZygiskNext: Standalone implementation of Zygisk For APatch

Standalone implementation of Zygisk For APatch. Contribute to Yervant7/ZygiskNext development by creating an account on GitHub.

github.com

Have people switched to a different unofficial fork? I see official ZygiskNext still won't support APatch for.. reasons.. 🤔
[Magisk] Vision:
@dmenezes @Flr Power

For those discussion about sim, depending on the country, you can have a nano twin sim, 2 sim with the same number, and depending the devices you want to use switch the airplane mode for the other
[Magisk] krakout:
I've been following the proceedings with interest, but, as I said a couple of months back, the weird thing for me is:

Things seem to be working pretty much ok for me, even though I've never fiddled with fingerprints, my module is still at 14.3 and I only pass Basic integrity! I keep paying every other day with no issues and today I went to send an SMS and it turned out RCS was working (but I'm not sure how unique that is).

What gives? How can it be?
[Magisk] osm0sis:
From what I have found so far this fork may have APatch support working still:

GitHub - Admirepowered/Zygisk_mod: Standalone implementation of Zygisk

Standalone implementation of Zygisk. Contribute to Admirepowered/Zygisk_mod development by creating an account on GitHub.

github.com

But I'm still curious to know if there's another people have switched to from Yervant7's.
[Magisk] rodken:
... and Wear OS.
[Magisk] Captain_Throwback:
The "official" ZygiskNext works with the latest version of APatch (10533) now, so the "MOD" version is no longer needed.

As per usual, there was some TG drama that led to Yervant removing the repo. The APatch TG group has also been deleted, and only the release channel remains.
[Magisk] intel_core_i7:
Agreed. This dude probably comes from place where PI in apps hasn't been a norm yet, like most developing countries so argument may happen. And then I can't confidently say it will stay like this for long anymore, there's one or two smaller banks here started implementing this in different levels.

I hope it can be backwards compatible with those Series 60 Nokias. Those were the best

Not recommended. You have to pay to have a secondary (or the 3rd, 4th sim card) and then have a monthly fee to keep it working. Then the clones you registered with the carrier also have restrictions, e.g. unable to receive OTP codes or run USSD codes. That's how it works in my country, I don't know if it applies to other but I expect the same outcome. I use the service just because my primary device has its SIM tray permanently stuck unless I use pliers to pull it out, and I have multiple devices to play around with legacy 2G/3G networks. Pulling out my SIM card whenever I want is a torturing work for both myself and my primary phone, the SIM tray cover has already been damaged

AS spoofing is quite unreliable. Some apps with region locking, PI and device exclusives may not show up at all no matter how I set the device in spoofing options or how I had a VPN connection to the correct country & account options in AS settings.
[Magisk] osm0sis:
Oh really? That would be (overall) good news! Interesting that they left this PR and that issue open if it's already supported:

apatch support by Admirepowered · Pull Request #88 · Dr-TSNG/ZygiskNext

Standalone implementation of Zygisk. Contribute to Dr-TSNG/ZygiskNext development by creating an account on GitHub.

github.com
[Magisk] shoey63:
How about tap and pay through a checkout?

Can your bare bones setup do that?
[Magisk] Captain_Throwback:
That's because the fix wasn't done on the ZygiskNext end; it was done in APatch. So while it's not technically "proper" support, it does function now, whereas it didn't work at all before.

If the pull request is merged, then the module would actually report root as "APatch" rather than "None" as it currently does. Fortunately, that doesn't affect functionality.
[Magisk] dosbuddy:
No one can ban Xaiomi fingerprints, because there is no manufacurer with this name.
[Magisk] markfm:
I want to see osm0sis ban-proof fingerprints now :)
[Magisk] Vision:
Yeah, and my old Sony Ericcson Aino

Oh in my country buy the twin sim with same money and that's it, after you have 2 with the same number, and you can have it in 2 phone same time, 1 of 2 devices in airplane mode and if you want the other device just switch