yashsingh1/xdaforums huggingface dataset:
[Google Pixel 7 Pro] pxlkeshi:
I've only ever gotten custom roms on my OnePlus 8t that I use as a mp3 player, but I wanted to know if any of you guys use custom roms would highly recommend me to switch to another room and how has the experience been with it (battery life, ui fluidity etc) there are so many options to look from and they all look really interesting so a discussion on this would be great
[Magisk] simplepinoi177:
Spoiler content hidden.
[Magisk] simplepinoi177:
Spoiler content hidden.

Spoiler content hidden.
[Magisk] simplepinoi177:
This by far is not a final complete version of this guide.

If any experts can further direct and/or elaborate/illuminate/correct any aspect of this guide it’d be much appreciated (by me foremost, but any member/reader who it may help)!

Many of you experts are most likely going to tell me I am making this more complicated than it has to be -- because it was simpler for you – but like I stated previously; this is just the way that worked for me (from my very ignorant noob level of experience), the way I went about it, and my reasonings for it. Hopefully, with this, other noobs can relate, feel less self-conscious, and more confident.

Also, if anyone feels there is something you wanted expanded/reworded/better-explained/or-even-simplified, please post here or send a PM and I’ll be sure to improve it in the OP.

I want this to also be a safe space for discussing and assisting finding your own custom fingerprints (so if you experts can also help in that as well, we would all be so very grateful!)! I just want to help any other person who feel as helpless as I did.

I really believe, as I am a completely ignorant noob on these things, that if I was able to figure this out, anyone can if they simply apply themselves a little bit (because I was completely surprised I was able to figure it out and get it to work successfully!). And hopefully this guide/walkthrough with its could-be-more tips can give anyone the confidence to go for it and make things easier/more-understandable for them going forward.
[Magisk] sawdoctor:
Thanks for all your hard work on this. Really think you should make this a sticky
[Magisk] osm0sis:
The details linked-to in your supplemental POST link aren't correct. I corrected them a few pages later: https://xdaforums.com/t/module-play-integrity-fix-safetynet-fix.4607985/page-298#post-89206122

Those maxes aren't correct.

My guide doesn't even put a cap on it, just says they "don't work out of the box", then later I mention a number of higher API numbers (i.e. newer Android versions) and what to lower them to to try to get things working.
[Magisk] simplepinoi177:
Heh...I don't know about that...if anything, the PIF thread should be one...Maybe @chiteroman might consider putting this in the OP of his, if anything...

More just want to create a safe space for noobs that I am who found this almost too daunting to attempt; as well as share my experience on how I got my single one working 😅

Thanks for pointing this out. I'll amend the OP. I haven't kept up with that thread since it's just too much overwhelming how many posts come in in just 24 hours! Hard to keep up with any/all updates on anything.

If anything, while what you say is true enough (it should be; it comes "straight from the horse's mouth"), but as I had complete noobs in mind when writing this, I want to keep it as uncomplicated as possible -- so I imagine going for & limiting to possibilities that are more likely to "work out of the box" is best as a first step. I left wording for going beyond that if anything...

Please, if there's any more, let me know. I want this to be an accurate resource to already very unknowledgeable noobs like me.
[Magisk] sawdoctor:
At the very least it needs to be in the OP of chiteromans thread. Such a great idea and full of useful information+resources, don't want it to get lost in the forum
[Magisk] osm0sis:
No worries!

A couple other things!

"no Nexus ROMs nor Pixel’s 3 or 4 (I can’t recall which one has finished receiving updates) or older"

That's not what my guide said. I said shamu (Nexus 6) and older completely fail CTS/BASIC, which means Nexus 5X and 6P are still viable.

All Pixel models First API 32 and lower are viable as well, but the no-longer-supported ones (Pixel 4 and 4a or older) have some banned already.

For both of these discontinued ones (Nexus & Pixel) you simply must avoid using the last ROM release, i.e. the final build Google released for the device, since it's already banned by default it seems.

Also all your "war" links (and Nov 30 one in OP) are just to an empty edited post now, so probably unnecessary.

Fun read! Thanks for explaining my explainer. 🙂🙌
[Magisk] simplepinoi177:
Sorry....I know nothing of the Nexus line (before my time; only came into Google phones at Pixel 2 taimen). I'll change that from "no Nexus ROMs"...

As I mentioned earlier, I couldn't recall which Pixels had stopped being supported -- I figured it was Pixel 4 or 3. That's a pretty narrow window then...I had a Pixel 5. If Pixel models Pixel 4 or older and First API has to be 32, in the few fingerprints I looked at, that would mean Pixel 5 and just slightly into Pixel 6 (depending on the ROM version).

Again, sorry uber noob here if I'm not understanding right and there's more that needs to be considered and what's possible...

Yes, thank goodness you made that clear, or I might've tried a couple of them (I'm partial to Pixels) and/or indicates something on how Google is picking what to ban...

Yeah I saw -- it was hell trying to find his reference/wording to that after he edited it -- but I just wanted to show that these aren't my words but one's that came straight from the creator of PIF -- and that at one point it was there. But thank you for pointing it out! Anything you can do to help my humble thread/guide is very much appreciated!

I'm very proud of your approval! Must've been fun to see/read it from a utterly complete noob's perspective ;)
[Magisk] razz0s:
Fantastic read, after some time fiddling with my devices and whatnot, I finally managed to pass the dreaded Play Integrity :)

Thanks so much for the effort that went through creating this!
[Magisk] beeshyams:
Another useful tip (which I may have missed on quick read on mobile) is changing API level and sometimes this works.

Recently, somebody posted a very useful tip related to this (wish I could search and quote them, thanks to whoever it was) - if at all the FP can pass by lowering the API level instead of experimenting with several levels, just put "00" in first API level. After reading this I tried and got 2 or 3 FPs with API level as 00 (in quotes). Hope Google doesn't see this
[Magisk] zgfg:
This will work only with Chiteroman's PI Fix - his PIF will then force the hardcoded 1st API level 23.

So you can do the same by putting "23"

On the other side, Osm0sis PI Fork module does not force any default/hard-coded values, hence if you use "" or if you delete the whole FIRST_API_LEVEL line, his PI Fork module will leave whatever is 1st API Level of you own phone (it might be eg 29, 31, 33)

Therefore, to force lower FIRST_API_LEVEL, better explicitly set to "23". Chiteroman may also change his hard-coded value in the future, when he changes his hard-coded spoofs once they get banned by Google
[Magisk] sawdoctor:
Think this is why @osm0sis fork is the better long term option. He's trying to make the module future proof so we'll only ever have to change the json file and won't have to keep updating the guide when something changes. I appreciate the time effort etc chiteroman has committed to the course but all the changes make it harder to follow
[Magisk] beeshyams:
I use Osm0sis fork v3 not Chitteroman.

I used to set it to 23 but found setting it to 00 is a kind of litmus test to determine if lowering the value of API makes it pass. But I must admit that I tried this trick on about a dozen samples only of which 2 or 3 worked fine.

I am not inclined to accumulate more FPs so others can validate this. Close to 30 prints is a bit too much and neither do I feel it is a matter of bragging. I am equipped for near future and beyond that Google decides

Edit: I just read your post above and it's precisely for this API level lowering test, this comes in handy. Nice script and I am sure others will use it 👍
[Magisk] zgfg:
It might have been hardcoded 23 in his v3, but no more in his v4

To make sure what's going on and how the module interprets your eg empty FIRST_API_LEVEL, read the logcat.

If you find inside eg -> 23, it was lowered to 23. If you find that FISRT_API_LEVEL was not found and thus ignored, then you know that it was not changed/injected by the module
[Magisk] zgfg:
There around a number of build.props with alike:

ro.system.build.fingerprint=qti/missi/missi:12/SKQ1.220303.001/22.9.14:user/release-keys
ro.product.system.model=missi system image for arm64

Then, they have also vendor-build.prop with a more meaningful values:

ro.vendor.build.fingerprint=Xiaomi/lisa/lisa:12/RKQ1.211001.001/22.9.14:user/release-keys
ro.product.vendor.model=2107119DC

but the build.prop from /system is missing and the proper JSON files cannot be made of

In fact, JSON files generated from the above then look like:

{
"PRODUCT": "missi",
"DEVICE": "missi",
"MANUFACTURER": "qti",
"BRAND": "qti",
"MODEL": "missi system image for arm64",
"FINGERPRINT": "qti/missi/missi:12/SKQ1.220303.001/V13.1.22.9.28.DEV:user/release-keys",
"SECURITY_PATCH": "2022-10-01",
"FIRST_API_LEVEL": "31"
}

and they just make no sense (look at the MODEL - you immediately see it cannot represent a certified, stock ROM) and cannot pass DEVICE, sometimes fail even with NO_INTEGRITY

They can be found in the collections under the 'brands/manufacturers' named qti and then in subfolders related to particular phone models from the other vendors that are based on Qualcomm chipsets

Even worse, they can be found under Xiaomi, OnePlus etc build.prop collections

Eg, for Xiaomi, these prints appear for A11 and newer models - for older phones there are usually correct build.props around (and JSONs that can sometimes pass DEVICE), although those phones are also based on Qualcomm chipsets

If you really have a lot of time and you do automated testing, then you could test QTI props (probably from the real Qualcomm phones) to find maybe only a few passing JSON files under the 250 QTI prints, but generally don't waste your time

Better test when you find some never-heard-of brands. There is a chance that some pass DEVICE and then you will have really unique JSON, not used by others and Google (unless they put in place a procedure to ban all cheaters) will never bother to ban that rare one

On the other side, under eg. Pixels, you can find FINGERPRINTs/SEQURITY_PATCHes that still work, while the others (for the same Pixel models) have already been banned. (as built into the previous PIF versions)

But Xiaomi.eu have now there own injector app for spoofing PI, they have lot of users, they use the same injector (same spoofs( for all A13 and A14 custom ROMs - they are an easy target for Google and they burn now every few days one more Pixel or Asus FP
[Magisk] simplepinoi177:
@nicoco19 , I'd like to help you and continue here as to not be too off-topic in that thread (this is my thread so I get to choose how off-topic it can be) as well as you refer to this guide so it's still applicable/relatable here...

If you've read all the pre-requisite posts, and have read through the OP at least once and have a good base of knowledge on the subject, you can go to Section 1 for places to find your own fingerprints (or you can do the Get TheFreeman193 Random Pif button), skip Section 2, and go to Section 3 to implement and test.

Most of the questions you have below can be answered in the PixelFlasher OP (from how to connect, what to Browse, what to use, etc.). I suggest you read through it all again (not just the top of Post #4 that deals with PIF Manager, but the bottom that deals with handling/dealing with the PIF modules and what not, & the other posts that show how to use the tool in general).

That "Browse" button is not looking for a file, but for the platform-tools folder -- which you can obtain if you click on the button next to "Android Platform Tools Version 34.0.5..." . After downloading and extracting that, you can point that Browse button towards that folder where you extracted (which holds the adb.exe and fastboot.exe files)

Your computer needs to be able to detect and read your phone -- however it usually does. I believe you mentioned you are using a Samsung, so you will need to download the Samsung USB drivers (may be specific to your device model) and install them, then install the drivers to read your device. Once you can see and read your device on your computer (on Windows, best bet is when you can see it correctly [no yellow triangle] in Device Manager), you will be able to click SCAN and see your device.

On your computer.

As explained above, it's not looking for a specific/one file, but just the folder that holds the adb.exe & fastboot.exe files .

The SCAN button will be gray until/unless you download the platform-tools & your computer can read your device (USB drivers)

if you have any other questions...feel free to ask here! Especially if they are in regards to following this guide; the other one would be best for dealing with passing and bypassing to get MEETS_DEVICE_INTEGRITY
[Magisk] nico89b:
Hi and first of all thanks for all your effort in writing this post, I have been reading through for weeks and helped me finally understand what a fingerprint is and everything else.

I just started the process of finding a ROM to spoof but, unsurprisingly, no luck with the first 2 or 3.... I do have a question: the ROM has to be on Android 8 or as long as that phone has been updated to Android 8 it's fine? Cause some of the ROMs I got are Marshmellow or Nuguat.

Second: if the build.prop does not pass Device Integrity at first try, should I start trying different values for both

"DEVICE_INITIAL_SDK_INT" and "*api_level"? So start from 25 going down for both of those?
[Magisk] Wolfcity:
api _level around 25 seems to be a sweet spot, so if you pass 1/3 try lowering to 25 and maybe lower.

There has been users who had luck with A9 and above but A8 or A7 to A8 seem to be the most successful attempts.

That's just a rule of thumb.
[Magisk] nIsmoAddict:
Hi, thanks for taking the time to write out the guide.

I was hoping I can get some help. I have 2 old devices, the LG G3 and LG G6. In the adb tools, I typed in the command: adb shell getprop. A long list of data comes out. I copied that into a notepad. I follow that with changing the name and extension into build.prop.

I open pixelflasher with the pif tools. I press the button "process build.prop(s). I select either build prop file from either devices, and all I get is the following:

I was wondering if there is something I'm doing something wrong here.

Any help would be really appreciated.
[Magisk] simplepinoi177:
sorry everyone... real-life has forced me to be a bit MIA. I don't have a working computer and i don't really like to do XDA on mobile browser.

like mentioned before, 25 is the "sweet spot" (i like to call it the magic or "Goldilocks" # -- not too high, not too low). Earlier, there was a member who reported going down to 00 was just as successful, but i imagine whether 25, lower, all the way to 00 would be just as successful as 25 if the fingerprint was dependent on it to pass...

When my current custom fingerprint finally fails and i have to mine my own again, if it doesn't pass right away, what i plan on doing is changing those fields before giving up on them simply not working/passing...

that is peculiar...

the way i would go about it is the thought that maybe the required fields & values aren't in that particular build.prop; I've come to learn recently that (mentioned in Section 3.1.2, step 3) PF can process

ANY

file with the extension *.prop -- so it will go through each and everyone of them and see if the required fields reside in them. So i would go back into the firmware extracted folder or dump and get all the *.prop files you can find and load them all in PIF Manager of PF.

I would do that or use osm0sis' gen_pif_custom.sh script (attached to this post) to process the build.prop for you as well. Remember, as mentioned at the bottom in Section 1.2; you might have to check multiple places and/or deeper levels to find a, or the-right, build.prop file...

hopefully this helps. I'll try to log on more frequently while I'm fixing my computer, to give if you need any/more help...
[Magisk] badabing2003:
This was asked and answered in PF thread.

📳🔥 PixelFlasher, a GUI tool for flashing / updating / rooting / managing Pixel phones.

DESCRIPTION As the name suggests this is an application to flash (update) Pixel™ phones (possibly all Google™ made phones/tablets, YMMV.) PixelFlasher at its core is a UI layer (with bells and whistles) on top of adb / fastboot commands, hence...

xdaforums.com
[Magisk] V0latyle:
Feel free to quote this quick and easy guide in one of the first posts.
[Magisk] simplepinoi177:
Thank you @V0latyle ! and thanks for writing that up...i'm sure it'll be most helpful...

Originally, I kept this walkthrough as a simply how I got mine to work -- as newer methods came out and I'd never used them, i wasn't going to speak to them; as well as they all have their own instructions/walkthrough/guides....

but it seems now that mine isn't really a walkthrough/guide anymore, but more a resource to get "noobs" a good understanding on how things go and the reasons why -- if they read it in its entirety, they'll know how everything is and applies.

So i think i'll add yours to the OP...I just don't know where to place it exactly. Maybe i'll create a post and make a 4th section for PIFS and PINext/playcurl/"fp_downloader"/whatever-else-TG-clones....

So please allow me some time to consider things as you don't see it in the OP right away....
[Magisk] V0latyle:
Completely up to you my friend, it was just a quick 5 minute guide that I thought should help most people get started.
[Magisk] Nergal di Cuthah:
I made it my first intraXDA bookmark of it,for when mine fails. now if i can just figure out if i can see bookmarks in app.
[Magisk] nico89b:
Still no luck for me, I have downloaded what I believe are not-so-popular devices ROM (either Nuguat or Oreo) but almost all of them appear to be in weird formats, such as this Asus with a single .raw file (~4GB). Anyone knows what am i supposed to do with it?
[Magisk] simplepinoi177:
I don't know anything about Apple, but I imagine that's what the .dmg file is for...

https://github.com/badabing2005/PixelFlasher/releases/download/v6.7.1.0/PixelFlasher.dmg

But since I don't know anything about Apple's, it might be a better idea to bring any support questions to the main support thread (and you're lucky because the dev is very involved and active there to help)

📳🔥 PixelFlasher, a GUI tool for flashing / updating / rooting / managing Pixel phones.

DESCRIPTION As the name suggests this is an application to flash (update) Pixel™ phones (possibly all Google™ made phones/tablets, YMMV.) PixelFlasher at its core is a UI layer (with bells and whistles) on top of adb / fastboot commands, hence...

xdaforums.com
[Magisk] simplepinoi177:
can't say I've encountered a .raw file when going through Asus firmware files...usually just parsed/split .img files....
[Magisk] badabing2003:
Yes it works, and it's what @simplepinoi177 is pointing to.
[Magisk] otraver:
Thanks a lot.

This whole thread has been very useful to me.
[Magisk] rogerty:
!HOSTIAPUTA!

That is what we say in Spanish in the case something is impressive, or causes a huge positive or negative emotional impact.

I ask the universe to provide me with enough patience to read and understand the necessary steps to be able to pay with google wallet again using my crdroid custom rom in mi mix 2, as it stopped working a few days ago.

***** Just that simple *****

THANKS for your enormous effort, time and dedication !
[Magisk] simplepinoi177:
I'm flattered by your words and I appreciate them.

But it seems Google has banned more than 95% of custom fingerprints, so this thread/guide has kind been laid to the wayside. But it's still a great resource to understanding the foundations of fingerprints and all that...

There is a very active discussion on just your issue on the main PIF thread (linked below). I suggest you read through what they're doing and developing over there since it's started discussions on it last Thurs..

BUT

it's more reading than even my OP/guide -- it's like 25 pages of full discussion! But it has something to do with signed/unsigned keys on crdroid and something or other -- may also include Google screening/banning based off of vanity strings...

🔧 [MODULE] Play Integrity Fix (SafetyNet fix)

PLAY INTEGRITY FIX This module tries to fix Play Integrity and SafetyNet verdicts to get a valid attestation. BEFORE YOU START: - Your ROM must be signed with a private key from maintainer, you can check with this command: unzip -l...

xdaforums.com
[Magisk] badabing2003:
In addition, crdroid rom is probably not signed, which now makes it fail device integrity even if the print is good.

That needs to be addressed, the referenced thread talks about it.
[Magisk] cunproha333:
I'm stuck with extracting system.img of super.img file, even I have tried to use simg2img, ImgExtractor & packsparseimg, SuperImg_Unpacker

My device is: Samsung Galaxy A25

Does anyone have any experience with Samsung devices

When I open system.img file by 7zip, it shows like this
[Magisk] simplepinoi177:
@cunproha333 i think it's because you're opening up the file with 7zip. I feel it's probably that those images are in EXT4 format and need to use the imgextractor.exe or Ext2Explore; you'll find my experience in Section 1.1.2 How-To & Basics for extracting spoiler
[Magisk] osm0sis:
No nothing was ever hardcoded in mine, since I forked it from PROPS v2.1, just before the 14.0 ugly merge+rewrite.
[Magisk] osm0sis:
One last nugget of (possible) wisdom I think it's likely okay to share publicly...

DEVICE_INITIAL_SDK_INT/FIRST_API_LEVEL is magical?

>32 triggers HARDWARE_BACKED evaluationType on all prints

>25 triggers HARDWARE_BACKED evaluationType on some prints

By the way, my preferred testing method is now YASNAC first to see if it passes with BASIC evaluationType and then try PI API Checker/Play Store Integrity Check to see MEETS_DEVICE_INTEGRITY.

YASNAC showing HARDWARE_BACKED evaluationType instead of BASIC is invaluable for knowing whether your DEVICE_INITIAL_SDK_INT/FIRST_API_LEVEL needs to be lowered more for your print. Once passing SN on BASIC then PI API Checker can still fail DEVICE, but then in that case you can probably safely say you're just looking at a banned print.

It'll be a shame when SN is complete it's "full turndown", because as far as I can tell we'll be losing a lot of insight into how Play Integrity works under the hood, and it'll be harder to interpret pass/fails from bans, or DEVICE_INITIAL_SDK_INT/FIRST_API_LEVEL shenanigans without being able to see evaluationType anymore.
[Magisk] zgfg:
But FIRST_API_LEVEL, if not present, or "", was pushed to "23"?

O have just retested 46 jsons that worked previously with v3 and 44 passed with v4 right away

2 failed but they one did not have FIRST_API_LEVEL, for the other was "".

I added "23" for both and now they now also work with v4
[Magisk] osm0sis:
No it was not. Check the code.

PlayIntegrityFork/app/src/main/cpp/main.cpp at v3 · osm0sis/PlayIntegrityFork

Fix Play Integrity (and SafetyNet) verdicts, allowing custom fields and props - osm0sis/PlayIntegrityFork

github.com

Presumably it's the weird nullptr logic I removed/fixed in v4. nulls can never make it to GMS in any way now, and DEVICE_INITIAL_SDK_INT/FIRST_API_LEVEL is a required field.