yashsingh1/xdaforums huggingface dataset:
[Magisk] bangheader:
I'm seeing the same thing with 15.7.2, first install on a new Android 13 phone with stock ROM.

Fails MEETS_DEVICE_INTEGRITY but passes MEETS_BASIC_INTEGRITY.

I can see that G is picking up the fingerprint because it sent me an email saying "A new sign-in on (spoofed device)"

First version I've installed so I don't know if it would have passed DEVICE using an older version.

I should add that the spoof is of an older Android 8 phone, so I don't see how it could be banned.
[Magisk] Umgak:
Print restriction is, far as we can tell, based on statistics. As far as we can tell, they look at what prints are making a lot of checks versus their actual current market penetration, and apply restrictions to prints that are being used by many users. My guess is that the reason they don't just restrict every fingerprint is that there would be some downside to doing so; perhaps restrictions have some man-hour investment required, or extra computation time server-side, which would make doing so costly. But, if you picked a print that others have used in the past, it increases the odds that the print will be blacklisted.

Try +/-1 version of the ROM it was from, or roll the dice on PIFS again if you got it from there.

EDIT: Also if you're using a custom ROM/Kernel make sure that your uname -r string isn't on the banlist.
[Magisk] zgfg:
It's nothing new. Since I use Xiaomi.eu for years, and for the last half a year PIF, and earlier USNF - I have had it many times in the past

From time to time I have to login to m G profile to clean various 'Pixel' phones etc, that 'I used last time' in 2020, in 2021, few months ago and so on (I never reall had any of those makes and models)

It's just something that I still didn't figure out at which point they do or not.

In Find My Device, my phone is now showing as 'Pixel'. And it's old alter ego below is 'Asus' - although in fact, I use (and already for weeks) totally different <vendor name removed> spoofs
[Magisk] rodken:
Not to mention the possibilities of false positives which falls into the overly aggressive restrictions which could inadvertently block essential browser features or website functionalities, creating frustration for users and businesses alike.

Along with ads which is a significant revenue stream for Google, relies on some level of user profiling. Completely eliminating fingerprinting might impact the effectiveness of their ad platform.

At the end of the day, Google faces a complex balancing act between protecting user privacy and maintaining functionalities and business considerations.

Let the constant game of whack-a-mole commence.
[Magisk] Captain_Throwback:
Oh no! I thought I was alone on the ??? devices. I figured only a few people would even consider them...
[Magisk] Umgak:
Wrong type of fingerprinting. This is referring to strings containing information about a phone's OS and hardware, such as:

OnePlus/OnePlus5T/OnePlus5T:10/QKQ1.191014.012/2010292059:user/release-keys

which contains information like the manufacturer, device, and version.

And no, before anyone asks, this one doesn't work.
[Magisk] V0latyle:
For those of you who are only passing BASIC, do you pass CTS in YASNAC?
[Magisk] deechte:
Please remove your post. No need to draw focus to a specific print.
[Magisk] zgfg:
I do rotate now, from time to time one from my collection

I did mining (with my own script in Terminal Emulator) at the beginning of December - I left the phone over night and in the morning I would have an eighty or so new working PIFs

It would be interesting to retest now how many from those several hundredths still work now. But I believe most of those 'special' ones (I don't want to further comment on that <vendor name removed> still work and will do for long
[Magisk] Captain_Throwback:
There is no specific print in my post?
[Magisk] zgfg:
Anyway, please better remove - I did in my two last posts and also in the text where I quoted you 😁
[Magisk] Captain_Throwback:
Seems a bit paranoid. It's no different then mentioning Samsung or Google, but whatever, I edited anyway so as to keep the peace...
[Magisk] majorfigjam:
As far as I know, the 20 or so <vendor-name-removed> prints I have all still work in Osm0sis fork, although I'm currently on another well known brand.

I have shared some of them with quite a few others, and so far only two reports of failure that are kernel related.
[Magisk] Umgak:
Honestly I don't think that's super necessary.

I've been using the same exact print for over 2 months now, I haven't tried to be cagey about where I got it (OnePlus), and I even sent it to another user as a known good print for testing purposes at the start of the kernel banning stuff. It's still not restricted. I just did a couple integrity checks to validate -MoRoKernel, as well as my goofy +b
[Magisk] zgfg:
At that time I did mining out of curiosity, I wanted to see about patterns (and did find some interesting things but they are now in the public domain anyway)

It's still good to have although there are now so many scripts, tools, modules and distilled instructions that make the mining almost trivial

IMO, Google will sooner or later implement more systematic approach instead od this current ad-hoc, and then we'll again see The Hunger Games here

Eg (as already pointed out earlier) they still 'ban' pretty much primitively. They now ban custom kernel names - but if you have spoofed prints from another phone combined with the stock kernel from your own phone (although those spoofs and your kernel come from totally different 'worlds' like diff chipsets,, or kernel is two years newer then what you claim about the ROM by your spoofed prints, etc), that still goes under their radar
[Magisk] bangheader:
Yes, mine does!
[Magisk] Spartacus500:
@Umgak

Thank you, fixed 😉👍
[Magisk] HippoMan:
But you usually can shorten the name by just replacing rightmost characters with binary zeros.

The following probably will work:

For example, if your kernel name is HippoKernel, and you want to use a shorter name, such as Potamus, you can do the following:

Original bytes...... H i p p o K e r n e l

Updated bytes....... P o t a m u s * * * *

... where I'm using the * character to represent a binary zero.

Do not pad the name on the left with binary zeros; only pad it on the right.

This is likely to work, although there could be some kernels for which this might fail.

UPDATE: I answered too soon. I see now that this was already answered. But I'll leave this message here, just in case.
[Magisk] Umgak:
This works. You can even lengthen the string - in every image I've seen, it's a 64 byte buffer. You can make your kernel name longer up to 64 characters, or shorter by overwriting with nulls.

My kernel name is currently just +b
[Magisk] Turtvaiz:
I don't myself. My kernel is 4.14.325-NeptunePlayground. CTS fail, BASIC passes, but DEVICE doesn't. Does that mean it's banned?
[Magisk] HippoMan:
Just to play it safe, I think it should be limited to 63 characters with a trailing null.
[Magisk] Umgak:
Actually, I just noticed. They're all char[65] with the last byte reserved for a trailing null. So, you can go all the way to 64.
[Magisk] badabing2003:
No it is not banned
[Magisk] zgfg:
It's not a text that you can cut or insert. It's binary code where the data, structures and routines have their addresses - their offset from the beginning

When you cut out only a single character (byte), everything behind that shifts one byte to the left

Hence, if you originally had 0x12345678 somewhere, after the shifting, you will have there 0x345678..., hence totally different bytes with different values (and meaning)
[Magisk] HippoMan:
Yes, but also see the most recent messages here by me and by @Umgak ... starting with message #11,051.
[Magisk] purgy:
I just assumed it was safest to keep the length of the string the same, so I just went from sultan to stupid.

I think it only takes changing one letter in the string to make pi happy anyway, so there shouldn't be any need to change the length at all.
[Magisk] zgfg:
Of course, ,but that's not what I commented
[Magisk] HippoMan:
Understood. That's why I wrote "of course" and just pointed out some additional, related info.
[Magisk] zgfg:
Of course, (and that should have been clear from the veginning) ,but that's not what I commented

However, from the practical point of view thar would be enough, one does not need to understand the structure of the binary code
[Magisk] Klappp:
My fp from early december stopped working... maaaan screw this

I'll pay 5 bucks for a working fp
[Magisk] Nergal di Cuthah:
Just use the freeman script, you'll find a new one in a few tries.
[Magisk] osm0sis:
For free! (Though one could certainly still show their appreciation. 🙂)
[Magisk] Klappp:
Ok it's not the fp actually. I switched devices.

So it's working fine on my s20 fe running Android 13 with kernelsu, but it doesn't work on my OnePlus Nord running Android 14 with Magisk. The kernel is fine. Latest play integrity fix is working fine, but my custom fp isn't. It's only working on devices with kernelsu.

Am I missing something?

Basic pass

Cts fail
[Magisk] Klappp:
So I have to look for a new one...
[Magisk] Nergal di Cuthah:
Likely
[Magisk] Matthew3955:
How to fix it
[Magisk] badabing2003:
Fixed
[Magisk] Matthew3955:
But strong integrity test failed
[Magisk] purgy:
Strong will fail unless you have a locked bootloader, basic and device integrity are enough to pass.
[Magisk] bangheader:
I might give that a try with +/- version of the ROM using an img extractor.
[Magisk] bou1l3m:
I have a problem what is the solution please
[Magisk] tom1807:
Solution No. 1

Solution No. 2

Cheers
[Magisk] :
@osm0sis In your description of PIFork you state that if using Magisk (with Zygisk) denylist must be enforced if not also using shamiko.

But it's working without both. What am I doing wrong? 😉

Or is this just for v7 and following?
[Magisk] osm0sis:
It's definitely not working if you have Zygisk disabled. Enforce DenyList is just best practice to hide from other apps without using Shamiko, but shouldn't directly impact Play Integrity.
[Magisk] :
I meant enforced denylist and shamiko. But thank you for clarification. 🙂
[Magisk] osm0sis:
Same same. Best practice for hiding from other apps. Fewer misdirected complaints this way.
[Magisk] Zilla0617:
I'm facing the same issue as the person you responded to, i went with solution #2. I placed the custom.pif in the file in the appropriate location (/data/adb/pif.json) However, when running play integrity checker through the play store it sees the fingerprint as my P8P instead of my custom pif. Why is that?
[Magisk] sawdoctor:
As i understand it (stand to be corrected) if you enforce deny list then although shamiko is enabled it's not working. Only one or the other can work at a time but both require zygisk enabled same as PIF
[Magisk] Umgak:
The spoofed fingerprint is only passed to the DroidGuard process, which is responsible for the Play Integrity check on the backend. The Play Integrity checker in Play Store displays your device's real print, this is purely visual. PIF (as well as former modules like SNFix) work not by spoofing device-wide, but instead by targeting only the DroidGuard process.
[Magisk] Zilla0617:
So when you using a custom print, the only way you know that the print failed is if you don't see basic and device integrity in the play integrity checker
[Magisk] osm0sis:
Y'all need to read, and direct people to, the FAQ. 👇

PIF FAQ

PIF FAQ Abbreviations DG = DroidGuard (SafetyNet/Play Integrity) GMS = Google Mobile Services (Google Play Services) PIF = Play Integrity Fix Frequently Asked Questions Q: What is a fingerprint and where does it come from? A: A fingerprint...

xdaforums.com
[Magisk] Craftyawesome:
I'm having trouble patching my kernel. kr_offset can't find any offsets. I don't think it is managing to decompress the kernel. If I decompress it in 7zip windows it complains about data after the payload but it does now show 3 instances of the kernel string in HxD.

Spoiler content hidden.

magiskboot also doesn't want to decompress it

Spoiler content hidden.

Kerpat explicitly says "Input file is not a supported compressed type!"

Spoiler content hidden.

Any tips on what to try next/how to decompress/recompress it correctly?

EDIT: Managed it. See https://xdaforums.com/t/rom-t320-t3...fi-lte-mondrianwifi-lte.4523723/post-89349968
[Magisk] Umgak:
What device/ROM/kernel? Hard to help without knowing what we're even looking at.
[Magisk] Adanaliisot:
Hey dear developer . İ have an Xiaomi 13 . İ installed yesterday lastest play integrity fix release ( 15.7.2 ) . İt caused to suddenly reboot my phine . İ lived this problem 2 times and when i uninstall this module , problem has been solved . How can i fix that ? Thank you for helps :) . İf i said wrong thing please forgive me , my English is not so good 🥹

Note : i am using now magisk v27. İ dindt try on kernelsu , should i try ?
[Magisk] tom1807:
Use the @osm0sis fork, and your mobile won't reboot.

If it still does it, then there is a bigger problem.

Cheers

Tom
[Magisk] Craftyawesome:
Tab pro 8.4 (an old device) on this rom
[Magisk] Adanaliisot:
ı tried fork v7 but my devices stucked bootloop . after ı uninstalled magisk and installed kernelsu . ı tried play integrity fix v15.7.2 on kernelsu . ı havent had any suddenyl reboot problem so far . ı think magisk v27 has a problem :)
[Magisk] tom1807:
Maybe related to the tablet, I run Magisk v27 and Fork v7 successful on my mobile.

Cheers

Tom
[Magisk] gazdajezda:
Hi. Last A14, with osm0sis PI fix v.7 on Magisk 27 getting me working BASIC + DEVICE integrity. Great! Thanx to all devs, modders, hackers there :)
[Magisk] Klappp:
Freeman's script got me a working one eventually. Cheers all. I know where my 5 bucks are going
[Magisk] rogers11:
Same here, Pixel 7a and Galaxy Tab S5e, both on LOS 20.
[Magisk] pndwal:
There's one serious 27 issue current ATM: magisktmp gone during boot... Causes root loss...

Not sure if it's yours but... Link:

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

👀 PW
[Magisk] Umgak:
The kernel is in an LZMA2 compressed zImage. I can extract the kernel just fine with 7zip, but I'm not exactly sure how to recompress it.

The kernel is made up of several parts - the program to decompress it (written in ARM assembly, probably compiled from C), the compressed image, and then a footer. This was probably done specifically to make it smaller due to that device's low memory. Someone else might know more on how to stitch these back together properly after editing.

EDIT: Might honestly be easier to just rebuild the kernel from source, though. No idea.
[Magisk] osm0sis:
magiskboot can't handle it? 🤔
[Magisk] Itroublve:
Updating from v15.5 to v15.7.2 sent my phone into bootloop. Great progress 🙂

went back to 15.5 and everything seems fine 🙂🙂

Apologies for the lack of information, the information requested: https://xdaforums.com/t/module-play-integrity-fix-safetynet-fix.4607985/post-89332184
[Magisk] Nergal di Cuthah:
If you were to give more information, maybe we can help figure out why it happened.
[Magisk] Itroublve:
I don't know, I've got Magisk Canary (27001), updated and restarted, the phone booted, and shut off and went into a bootloop state. S21 running Android 14 (December patch).

Downgrading to 15.5 works fine, the new update doesn't matter much to me so it's fine.
[Magisk] sawdoctor:
Can you give more information than that please to help the Devs and other users?

What device, software/ROM/android version and what root method?

Did you manage to grab any logs?
[Magisk] badabing2003:
Is this it?

View attachment 6066920
[Magisk] kevin01523:
HMP might be also blacklisted
[Magisk] osm0sis:
Wasn't last time I checked, just -EAS- and -eas-
[Magisk] simplepinoi177:
simplepinoi177 said

MOD ANNOUNCEMENT

​

As per Forum Rule 3 (quoted below), Please "Post using a clear and descriptive...message." with one "...that describes your problem and a message that

explains in detail, what your problem is and what you've done to try solving it

." as "You're most likely to receive a helpful answer to your question..." doing that.​

We would like to keep & maintain the thread and site (XDA Developers Forum) to a higher standard (from certain other [paper airplane] apps & sites).​

​

​

Your cooperation is appreciated,​

simplepinoi177​

Forum Specific Moderator​

XDA Developers Forum Rules said​

3. Post using a clear and descriptive subject and message.​

​

You're most likely to receive a helpful answer to your question, if you use a short subject title that describes your problem and a message that explains in detail, what your problem is and what you've done to try solving it.​

[/QUOTE]​

particularly the "'You're most likely to receive a helpful answer to your question...' doing that."
[Magisk] Umgak:
Figured out why.

The boot partition is really small on that device, too small to actually store the kernel itself. So the kernel is stored as a compressed image, with a decompressor prepended.

Magiskboot doesn't like this, probably because the file doesn't start with the magic bytes of any format - because they're after the decompressor, at 0x34E0. The kernel.xz file is 0x4D1F73 bytes long, and then here's a little 0x3B footer.

By trimming the decompressor program and footer out, you can get a normal .xz image, which magiskboot will happily accept (or you can do it with 7-zip from the get-go, because it will ignore the errors and just brute force its way through).

After patching the name, the file is ~300kb bigger, and I hope that won't be an issue. The .xz compressor looks like it isn't hard-coding any offsets, so as long as magiskboot's compression settings are good, it should be fine.

For reference, the boot images on my OnePlus 5T are 22MB, and on my OnePlus 9 Pro they're over 200MB! The boot image extracted from the Tab Pro is only 7.5MB! o_O The kernel image is almost 3 times that when decompressed by itself!
[Magisk] zgfg:
Amazing debugging analysis 👍

Btw, I remember, with nostalgia, the days of 32 MB boot.img

Actually, when I saw that first time, I was also surprised since my previous devices had it with up to 16 MB (Boot partitions were 16 MB, padded with zero bytes)

I used to keep tens of patched images (by various Magisk versions) stored on the phone (for easy switching by TWRP between the versions of Magisk Canaries, Stable and early Alpha, back and forth) - but then came my next A10 phone with the boot.img monster of 192 MB and so...
[Magisk] CZ.Kostra:
Information for @chiteroman

I tried to install Play Integrity Fix v15.7.2 and found that it can't disable Xiaomi.eu Injector. The .replace files created are in the wrong directories.

current paths is:

/data/adb/modules/playintegrityfix/product/app/XiaomiEUInject/.replace

/data/adb/modules/playintegrityfix/product/app/XiaomiEUInject-Stub/.replace

correct paths is:

/data/adb/modules/playintegrityfix/system/product/app/XiaomiEUInject/.replace

/data/adb/modules/playintegrityfix/system/product/app/XiaomiEUInject-Stub/.replace
[Magisk] osm0sis:
Oh interesting, so instead of a zImage it's an xzImage with "piggy", I wonder if there are many examples of this format. 🤯

Jeez, who would keep such a collection... seems excessive... 😅
[Magisk] oslohes123:
Hi I noticed that this doesn't work with pixel experience december realease for poco f4 in eu is there something specific about that ROM?

15.7.2
[Magisk] badabing2003:
I'm sure you're grateful for the developer's work, is the sarcasm really necessary.
[Magisk] badabing2003:
Nice work.
[Magisk] kevin01523:
yeah i was on blacklisted signature for now i only know one working and nothing else so no backups rip. did recompile my lineage kernel and replaced lineage w android lol
[Magisk] oslohes123:
I'm kinda stuck on generating a .pif file

I've got two different sets of 3 build.prop files from two different ROM's and I've got PF setup fully and I'm on the PIF manager and then I click process build.props and put in all 3 build.props, but then the output is just empty both times?

Am I missing something am I supposed to download the full ROM?

I've just labelled each of the build.prop's build1,build2,.. is there supposed to be a specific name?

Am I supposed to modify the prop files if they are missing any information, are there any fields that I should be looking out for, and in which ones of the build.prop files?
[Magisk] chiteroman:
One question to everyone using PIF (and other forks).

If you try to login into your Google account and use one of your devices as 2FA it works ? Do you receive the notification to approve the login ?

I think spoofing Android Keystore is a bad idea... But I think I have the solution.
[Magisk] immortalwon:
New droidguard update, failing all 3 checks even with a custom kernel name
[Magisk] osm0sis:
Works fine here.
[Magisk] immortalwon:
Actually let me correct myself, there's something in the evolutionx rom they blacklisted for android 13
[Magisk] chiteroman:
Check kernel release name: uname -r

Basic verdict can fail if DG detects root or injection.
[Magisk] osm0sis:
Ah, maybe they finally added it to the ban list, or block a prop from it or something.

Yeah `uname -a` please,

I had wondered why daboynb just added them to his copy of my banned list: https://github.com/daboynb/PlayInte...af932deb3b626f2aabc00#commitcomment-138507973

So maybe it's incorrect but related. 🤔
[Magisk] immortalwon:
Can one of you smarter gentlemen help me fix this kernel string? How would I go about modifying the strings here

The red part is something I added, but IDK how to get rid of the blue section to something differrent.

View attachment 6067209
[Magisk] immortalwon:
Original name of kernel

5.4.254-qgki-ge05079273a6d-dirty
[Magisk] Umgak:
I receive the notification and can approve it normally, it just shows up as the wrong device because I need to log in unspoofed.

-qgki isn't banned and never will be, you didn't need to change that.

If you want to remove the rest, replace it in the left pane of your hex editor with 00 bytes.

That said, -dirty is also not banned (and neither is -immo, I checked).

Have you tried changing your fingerprint spoof? That may be your issue.
[Magisk] sawdoctor:
I've had issues before especially with my device being recognised as the wrong device. Seems to be ok now, i did a wipe of Google play services with PIF disabled let everything update and then re enabled PIF. No issues since touch wood
[Magisk] oslohes123:
Also a general thing, what is stopping google banning all PIF's coming from a unlocked device? Are there any manufacturers offering unlocked ROM's from beginning? If they do then let's say only locked ROM's aren't banned, isn't it better to find a way to spoof whether the ROM is locked or not.

Further is it possible to patch google wallet to bypass the play protect api checks? And just have it go to the bank

I am quite new to this whole thing so I appreciate that I might have oversimplified the system here.
[Magisk] immortalwon:
You are correct, it was something with KSU unmount bug. I wonder why it just suddenly stopped working?
[Magisk] immortalwon:
Thank me later if you are using Kernelsu