[Magisk] simplepinoi177:
A way you can look at “fingerprint” is that Play Integrity Fix [PIF] (an extension of Universal SafetyNet Fix Displax’s MOD which, I believe, employed somewhat of the same implementations) employs a .json file that holds certain values from identifying data fields that is used to misidentify to Google what your device is (as opposed to what it actually is; because if it sees that it is as new of a device, it will require more stringent Integrity [Play] checking (HARDWARE_BACKED evaluationType), which is triggered when rooted, and as it will fail, will keep services & apps to not run for fear of being compromised [hence, “integrity” is compromised]).

So you can think of it as the .json file as the finger, the fields/values as the fingerprints of said finger (identifying marks). I explain the reason you want to represent/pretend you have a different “fingerprint” (earlier & later) in this post…

It does. It(the values & fields) has to match an Android device, and what Google’s records has for that device.

It matches the same fields that are shown in Section 3.1.2 in the "Spoiler: last part of his post" within the "Click to Show Content".

Yes, you can choose a fingerprint from that device or a device like that or an Android device. One of the first fingerprints I tested was an Vivo X7 – but my device is a Google Pixel 7 Pro.

So as you surmised, no, you cannot make up a device fingerprint – simply because, as stated above, you need the requisite value data to match with what Google has for a given device to allow it to pass.

Sometimes that’s just how the game goes; a lot of it depends on fortunate luck – there are some users who get it within 5 tries/tests and/or 5 minutes, some that it takes 50 or even 200 fingerprints before landing on one. It took me (using the manual method) 2 and a half days, and probably 30-ish fingerprints. We all hate that this is the “nature of the game”. Just because none have passed doesn’t mean anything in particular (in most cases; caveat to “most cases” being that the whole process is being done properly -- your pif.json is correctly placed/implemented/formatted, devices that aren’t too old or new, formatting is correct, FIRST_API_LEVEL has been lowered, etc.).

As stated before, it’s referenced in Section 3.1.2 in the "Spoiler: last part of his post" within the "Click to Show Content", what Google is looking for is the values in those fields.

And the attributes of a working fingerprint is the whole second section of "the required reading" that is osm0sis’ guideline, which was the whole point & purpose of the reason he was putting that post up and disclosing the considerations he’s gleaned from his own experience & testing.

As osm0sis stated in his post (which is covered in the guide Section 1.1.3),

you may need root to retrieve the values. And as you stated, your wife’s is “totally stock, bootloader locked, never rooted”.

And that’s the point of Play Integrity – for Google and other apps to determine that the device hasn’t been modified in any way; for security reasons and whatever other reasons they have. But for many/most devices, one must unlock the bootloader to root and/or simply just want to have an unlocked bootloader, and as those that choose to root aren’t able to get many services/apps functioning/allowed unless they trick the app or Google in having the various levels of Play Integrity.

So the fact that her device has has a locked bootloader and is not rooted, other than some very specific, rare circumstances, it can be counted/bet on that your wife's device passes (use any of the Play Integrity checkers that it will/should show all 3 MEETS_..._INTEGRITY, which is something any device with an unlocked bootloader and/or is rooted shouldn't be able to achieve!)

Because once you put values in, the function of the PIF module is to change how your device is identified (“fingerprint”), and if the values in the fingerprint aren’t ones to make CTS pass in SafetyNet (which is the precursor to Play Integrity) – whether because the fingerprint is simply one that isn’t enough to trick passing or it is incorrectly implemented – then that just logically shows how it is said values that cause CTS to no longer pass.

As intimated earlier in this post, the pif.json holds values of fields that PIF uses to pretend/”represent” your device as something Google allows to pass MEETS_DEVICE_INTEGRITY (and at the very least MEETS_BASIC_INTEGRITY), which, in essence can be looked at as if it stands as sort of a substitute for a props.config.

@Alpha_Geek1, hopefully this is all at the very least understandable, but let me know if I can/need-to make anything clearer (I know I can make things more complicated sometimes; as you can see in the OP)….

I hope you and any visitor to this thread can see that this is a noob-friendly space…