yashsingh1/xdaforums huggingface dataset:
[Android Software/Hacking General [Developers Only]] zgfg:
I had a similar issue with Griffin, I don't remember if it was by the end of March or in April. I was using Griffin, not private prints and one day it was still passing SN with CTS Basic but it stopped passing PI

I tested couple of times, it was the same. I experimented with API level, re-migrating, by removing unnecessary fields from json, by autopif-again, no success.

I switched to private prints

Next morning I pulled again Griffin prints from the same zip archive with my other working json files (hence it was absolutely the same json that I originally started to have problems a day ago), and it was passing again, like there never was a problem

I think it coincded with the day when ppl reported RCS issues. Then, one day later than PI started to work again with Griffin to me, that problem with RCS and Griffin for others was resolved

I think they experiment something on the server side and since we have different environments it can affect somebody and somebody not. Maybe it's also kind of A/B testing for DroidGuards submitting Griffin (now Clark) prints
[Android Software/Hacking General [Developers Only]] fbirraque:
Confirmed that the NFC Payments issue on Poco F3, XiaomiEU MIUI14.0.8.0 are related with current "Clark" PIF. After move to a private PIF and reboot everything are working flawlessly again.

Really thanks for your valuable inputs, 🙏

🔧 [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

•
[Android Software/Hacking General [Developers Only]] pershoot:
No issues with Clark and contactless payment (last used ~12-13h ago) on 7A (Lynx), over here.
[Android Software/Hacking General [Developers Only]] zgfg:
If you don't mind, you could include gen_pif_custom.sh to the PI Fork, under the module scripts - it's not part of the module but it is related to, and it will be easier to find the latest version
[Android Software/Hacking General [Developers Only]] osm0sis:
I don't really want to clutter up with more scripts than it needs. That one specifically is cross-platform, isn't part of the module, and doesn't even require root to run on device.

Latest is where it always has been:

[TOOLS][ZIPS][SCRIPTS] osm0sis' Odds and Ends [Multiple Devices/Platforms]

osm0sis' Odds and Ends -- Misc./Batch Tools, Flashable Zips, Scripts, etc. General Information In a nutshell, I just wanted a single thread to gather links to some of my other, larger projects, but also serve as a spot I could put some smaller...

xdaforums.com

It's already updated in anticipation of v9, by the way. Working on the documentation for hopeful release later today tomorrow this next week month. 👍
[Android Software/Hacking General [Developers Only]] pershoot:
@osm0sis Your stuff in real-world use: Updated to CI 224, used bundled-in autopif to acquire new FP from usual place ... done! Removed my tmp-local autopif.

:)
[Android Software/Hacking General [Developers Only]] pershoot:
Clark is dead.
[Android Software/Hacking General [Developers Only]] zgfg:
Besides

essi, missi, mssi and qssi

there are one more generic TSSI fingerprints:

/system/build.prop:

https://dumps.tadiphone.dev/dumps/i...-379072-release-keys/system/system/build.prop

ro.product.system.manufacturer=INFINIX
ro.product.system.model=
ro.system.build.fingerprint=Infinix/TSSI/FULL-64-ARMV82:13/TP1A.220624.014/230714V87:user/release-keysPRODUCT=TSSI
ro.product.system.brand=Infinix
ro.product.system.name=TSSI
ro.product.system.device=FULL-64-ARMV82
ro.build.product=tssi_64_armv82_infinix

/vendor/build.prop:

https://dumps.tadiphone.dev/dumps/i...624.014-379072-release-keys/vendor/build.prop

ro.product.vendor.manufacturer=INFINIX
ro.product.vendor.model=Infinix X6815D
ro.vendor.build.fingerprint=Infinix/X6815D-GL/Infinix-X6815D:12/SP1A.210812.016/230714V175:user/release-keys
ro.product.vendor.brand=Infinix
ro.product.vendor.name=X6815D-GL
ro.product.vendor.device=Infinix-X6815D

Similarly for Infinix devices: Infinix-X671B, Infinix-X6815, Infinix-X6815C, Infinix-X6815D, Infinix-X688B, Infinix-X695D

Btw, by GSMArena, that Infinix devices have Mediatek chipsets, eg this Infinix Zero 5G:

Infinix Zero 5G - Full phone specifications

www.gsmarena.com
[Android Software/Hacking General [Developers Only]] osm0sis:
Interesting that it's identified by PRODUCT where all the other OEM GSIs are DEVICE. Do the vendor values generate a working print?
[Android Software/Hacking General [Developers Only]] zgfg:
Not passing Device Integrity with vendor_build.prop prints

Btw, MODEL from system_build.prop is empty
[Android Software/Hacking General [Developers Only]] fbirraque:
Poco F3 (alioth), MUI14 by XioamiEU updated from CI #223 to #224 flawlessly.

Passing BASIC and DEVICE Integrity as it should.

Note: Yeah, my Wallet is still working! LOL

🤣
[Android Software/Hacking General [Developers Only]] fbirraque:
Poco F3 (alioth), MUI14 by XioamiEU updated from CI #224 to #226 flawlessly.

Passing BASIC and DEVICE Integrity as it should.
[Android Software/Hacking General [Developers Only]] casouzaj:
Same for me, on a Sony Xperia 1 II, running LineageOS 21.
[Android Software/Hacking General [Developers Only]] fbirraque:
Poco F3 (alioth), MUI14 by XioamiEU updated from CI #226 to #227 flawlessly.

Passing BASIC and DEVICE Integrity as always. Keep searching for perfection... ;)
[Android Software/Hacking General [Developers Only]] osm0sis:
Hahah thanks for the ongoing confirmations. Between Scripts-only mode, autopif+killgms and the new testkey and RCS bans there's quite a lot of documentation to update, so it's daunting and been hard to find time/energy to sit down to it all!
[Android Software/Hacking General [Developers Only]] pershoot:
No issues with #227 (been running for a bit). Thx!
[Android Software/Hacking General [Developers Only]] pershoot:
#228 fine on Jun. patch set (Lynx). SHIPIT! ;)
[Android Software/Hacking General [Developers Only]] osm0sis:
I got started on the updated documentation the other night! So, soon I think! 🤞😛

History for README.md - osm0sis/PlayIntegrityFork

Fix Play Integrity (and SafetyNet) verdicts, allowing custom fields and props - History for README.md - osm0sis/PlayIntegrityFork

github.com
[Android Software/Hacking General [Developers Only]] fbirraque:
#228 flawless for me

Note: Just a short input. I would like to confirm that RCS is working fine for me on Sony Xperia 10 Plus, LineageOS 21, Kitsune 27001, Play Integrity Fork CI #all and a "private" custom.pif.json
[Android Software/Hacking General [Developers Only]] osm0sis:
I've never seen that blue message before. 😵
[Android Software/Hacking General [Developers Only]] osm0sis:
Updated my custom pif script!

- add proper escaping for json values containing "

- add support for extracting proper vendor build.prop values for qssi/missi (Qualcomm), mssi (MediaTek), essi (Samsung) and TSSI (Infinix) OEM GSI devices (thanks @zgfg)

Example output using my Pixel 8 Pro .prop files and "advanced" argument:

system build.prop to custom.pif.json/.prop creator
by osm0sis @ xda-developers

- Using format: json

- Parsing build.prop(s) ...
google/husky/husky:14/AP1A.240505.005/11677807:user/release-keys

- Parsing build UTC date ...
Fri Apr 5 17:25:56 UTC 2024

- Build date newer than March 2018, adding SECURITY_PATCH ...
2024-05-05

- Parsing build first API level ...
34

- First API level 33 or higher, resetting to 32 ...

- Writing new custom.pif.json ...
{
// Build Fields
"MANUFACTURER": "Google",
"MODEL": "Pixel 8 Pro",
"FINGERPRINT": "google/husky/husky:14/AP1A.240505.005/11677807:user/release-keys",
"BRAND": "google",
"PRODUCT": "husky",
"DEVICE": "husky",
"RELEASE": "14",
"ID": "AP1A.240505.005",
"INCREMENTAL": "11677807",
"TYPE": "user",
"TAGS": "release-keys",
"SECURITY_PATCH": "2024-05-05",
"DEVICE_INITIAL_SDK_INT": "32",

// System Properties
"*.build.id": "AP1A.240505.005",
"*.security_patch": "2024-05-05",
"*api_level": "32"

// Advanced Settings
"verboseLogs": "0"
}
[Android Software/Hacking General [Developers Only]] HippoMan:
On my A13 device running Alpha 27002, I just now successfully updated to PI Fork version 9 by clicking on "Update" in the module list for version 8 of that utility. After the update, version 9 is indeed up and running, and I still have DEVICE-level integrity using my custom FP.

Good work! ... as usual! Thank you!

I'm running Zygisk and Shamiko, and so I don't have "Enforce DenyList" enabled, and I don't see anything that even remotely resembles GMS unstable in the DenyList window, neither selected nor unselected. And I understand that this is expected, given that I didn't enable scripts-only mode.

I'm wondering, however, if there's any advantage to switching to scripts-only mode, given that the current set-up already gives me DEVICE-level integrity.

If so, I guess I would have to disable Shamiko and Zygisk and then enable "Enforce DenyList", correct?
[Android Software/Hacking General [Developers Only]] osm0sis:
You're on Android 13 so odds are Scripts-only mode won't work for you. Enforce DenyList is not necessary with Shamiko, same as when in normal mode.

A bit more in the updated README:

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

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

github.com
[Android Software/Hacking General [Developers Only]] HippoMan:
OK. I see. Thank you!

Anyway, all is well for me with non-scripts-only mode, so I'm happy.

Keep up the good work! (Actually, I'm sure you will.)
[Android Software/Hacking General [Developers Only]] Nergal di Cuthah:
Is scripts only "less than android 10" or "less than or equal to 10" asking for the sailfish device user in pi thread
[Android Software/Hacking General [Developers Only]] osm0sis:
Less than is less than. 😛
[Android Software/Hacking General [Developers Only]] Nergal di Cuthah:
So no go for them, well poo :cool::sick::poop:
[Android Software/Hacking General [Developers Only]] fbirraque:
Updated from CI #228 to v9

Everything working flawlessly (private pif)
[Android Software/Hacking General [Developers Only]] pershoot:
v9 works fine (from #228). Thx!

However, I noticed an issue which I havent encountered in a while, when updating Magisk modules. I used to update via UI but noticed it would knock out the patched kernel (losing elevated priv.), requiring a re-flash. I then started updating by hand (disabling -> removing -> update from downloaded GH file -> reboot) and haven't faced it in some time. I just faced this, again, during module upgrade, using this manual process. I'll take note to monitor for subsequent actions of this sort and perhaps report it in, if it resurfaces.
[Android Software/Hacking General [Developers Only]] pndwal:
👍 Nice...

Didn't XiaomiEU just adopt the @chiteroman print/set last time? 🤔

Maybe this should be clearer; could be misleading too... Eg, won't work for A8 or 9 ROMs if device launched with A8 or 9 and has working Keymaster 3+ implementation. Also, will [may/should] work for any A10+ ROM if device launched with A7 or less!... Android launch version (and good Keymaster) is key (excuse pun), not running version.

Really this:

Nice that it's automatic. 👍

... Actually, will need DenyList enforced or Shamiko or another proper hiding module like DenylistUnmount or Zygisk_Assistant.

Also, you may want to add root hiding for GMS core process also, since some devices need this in addition to the DroidGuard/attestation ('unstable') process... We always needed to hide root from DroidGuard (com.google.android.gms.unstable) but MagiskHide also used to add the core process (com.google.android.gms) for devices where Magisk no longer resided in /sbin, basically devices running Android 11+... Since then, with major refactoring for Magisk tmpfs mount path (randomseed no longer used), I wondered if hiding root from GMS core was still needed but others confirmed that modern devices continued to require root hidden from both GMS processes... (Has more recent refactoring made this redundant? 🤔)

🤠 PW
[Android Software/Hacking General [Developers Only]] osm0sis:
A module update doesn't touch your boot.img/init_boot.img so that's super bizarre. Sounds more like a bug in your Magisk app. Also literally nothing changed from #228 to v9 (#229) except the version. 🤔
[Android Software/Hacking General [Developers Only]] pershoot:
Yea, I presume its some longstanding edge case in Magisk itself.
[Android Software/Hacking General [Developers Only]] D€INOS:
Did my first run of 100 fp.

One quick question, does the script work faster if the device screen is on, i.e. not password locked? I ask because I felt it took way longer for 100 fp than 30-70 minutes. I get that the script redo the test of a fp with api_level 25 if the fp is higher, but it felt like it took quite long time.
[Android Software/Hacking General [Developers Only]] zgfg:
The script calls SPIC, PIC or TB Checker and they must run in foreground because the script simulates taps to the Test buttons and it must grab then the screen to 'read' what SPIC, TB Checker displayed (Basic and Device Integrity passed or not)

Hence device screen will be on - it cannot test anything without. Script even locks the orientation to portrait while testing because it taps to the given coordinates that are adjusted to where SPIC, TB Checker etc have the buttons you would otherwise manually press to test PI. In the landscape, buttons would have different coordinates or would not even fit to the screen without scrolling

When it simulates taps, the app that is in the foreground at that moment will take the taps. And when it 'reads', it reads from whatever is displayed on the screen at that moment

Think of your own finger and your own eye reading from the phone. When you tap, you command to the foreground app and you cannot read from the background apps. And SPIC, PIC, etc do not provide an API you could communicate with them - they are the apps written for the on-screen user

That's why I commented about 'inconclusive" results during the time when a phone call takes over the foreground, etc

Also, during the night I always found in the morning that the script was paused after 3 hours of testing or so. It wasn't killed, when I grabbed the phone in the morning, script just automatically resumed to test after some time.

Btw, I had to keep the phone on charger, it's about the scren-on-time battery consumption

Btw, find in the script:

PI_WAIT_VERDICT="10" # Play Integrity verdict usually returns in 5-6 seconds, but if you decrease and verdict arrives later, script will miss to read

and as commented shorten that on your own risk. But in case of the network issues or Google server not responded on time with the verdics, you will have inconclusive results, and you will have to retest the same PIF json files - bcs the script will "'read' the screen after exactly those PI_WAIT_VERDICT seconds whatever is at that moment on the screen
[Android Software/Hacking General [Developers Only]] D€INOS:
Thanks buddy, great points!

Having the brightness a 1% is a good idea since almost all devices are oled, and such things as status bar icons etc, is pretty static.
[Android Software/Hacking General [Developers Only]] zgfg:
Yeah, brightness does not matter, you can minimize it

The script does not optically read the screen. It uses the uiautomator service that is built to the Android. uiautomator dumps the active screen in the XML format (if you prematurely kill the script you will find the XML file with the last 'screenshot', you can open as a textual file and try to find yourself where the PI testing results are written and how)

Similarly for taps it uses like

input tap 380 560

that again calls the service in Android that simulates the tap to the given coordinates on the screen

---

Btw the app cannot call directly PI attesting API from Google Play Services. For that you would have to write your own app, submit that app to Google and obtain from them a quota for how many times from that app (all users together) can call the PI API tests

That's why the script uses SPIC, PIC, etc, but then it must communicate with them via the screen

Actually big thanks to @badabing2003, he had similar script that runs from PC and communicates to the phone via adb and I picked the ideas from him and through the private communication with him (it's not copycat code - I made my changes, specially how I 'read' the dumped XML files, adapted that to several apps where reading from their XML dumps is very different, etc). Later I added more and more staff to the script, to automate everything, whatever I needed for my own testing. All together I probably spent as much time on developing the script as for using it
[Android Software/Hacking General [Developers Only]] pr3dicament:
I'll go ahead and ask. I'll probably just be yelled at but.. what is dedyn? I have the scripts in my PIF folder, but I made a Testing folder and have no clue what dedyn is. I looked and there's no github or anything for it, searched xda and there were four posts, all in this thread.. what do I do here? I don't know where this collection is.. I honestly am trying to follow instructions here but don't know where this dedyn collection is located.
[Android Software/Hacking General [Developers Only]] D€INOS:
It was (I think its gone) an online collection.

The first time private prints was needed (the time when it was super easy), I scraped the site for 5000 prints, and have never, until now, had a reason to go through them. Since back in the day, an easy dl of a pixel 8.1 print from Googles own site was all that was needed for me to get passing "device integrity".

Oh the times have changed...
[Android Software/Hacking General [Developers Only]] pr3dicament:
Oh well.
[Android Software/Hacking General [Developers Only]] pr3dicament:
Apparently this collection is now gone. So I can't even use this.
[Android Software/Hacking General [Developers Only]] D€INOS:
There certainly are OTHER repo out there, and like mentioned multible times, a pool of 5000 may often not produce a single working print. I'm pretty certain my collection is dead, I'm just running it for making sure, and because I have a spare device collecting dust.

The real deal for me at least, is to find more RARE prints, these I got are surely duds. These 5k and the Freeman scraped. Just making sure.

So the real challenge is to find working prints online, not testing them.

IMO.
[Android Software/Hacking General [Developers Only]] pr3dicament:
I was looking at TheFreeMan193, his "PIF" repo... if that's what you mean..to my knowledge that's the "pickaprint" script... there's some other repos he has. I'm not sure we're even talking about the same thing here though. I'm starting to lose my mind here.. I was supposed to be following instructions but I can't follow them if something is nonexistent and this is on me for assuming otherwise.
[Android Software/Hacking General [Developers Only]] HippoMan:
Actually, it turns out that with Tasker in conjunction with AutoInput, it's indeed possible to fully automate the UI interaction in order to go to the PlayStore screen, navigate through Settings to Developer Options, and then to select Check Integrity.

I've had that set up since last year, and I always use it to reliability query my device's integrity level.
[Android Software/Hacking General [Developers Only]] osm0sis:
TheFreeman193's PIFS/pickaprint json repo was intentionally only a portion of tadiphone in case it got scraped by Google and banned, which later it apparently did.

dedyn was also mostly just a complete dump of json files generated from tadiphone+MHPC, and presumably its creator took it down. It's long gone. MHPC prints were completely banned as well.

So you can decide where to spend your time... As I've mentioned before, there are indeed still 4 working fingerprints in all of tadiphone, then 2 working ones are from specdevice, and then the majority of the other remaining working found prints we've got were from another place which has also been referenced by me before in the PIF thread (mobi).

That said, tadiphone and specdevice are also constantly being updated, things added and removed, so there are potentially new ones that have been added since we dumped it in December which could potentially work, (but I also wouldn't bet on that).
[Android Software/Hacking General [Developers Only]] pr3dicament:
I'm not gonna bet on it.. I mean IF I'm being pointed to a guide (just saying) about how a video is gonna show how to fix it then I would at least make sure it's got what it needs on it, that it's working.. I wasn't even told about it being dead, regarding dedyn, so that's why I had questions about that. I'm the type to follow instructions with documentation, etc..I wasn't aware, I'm sorry if I seem *****y. I'm upset that I thought I was going to possibly straighten this out.
[Android Software/Hacking General [Developers Only]] osm0sis:
Well I just told you where 6 are, so you can go hunting for them using the script now, or you can use the thread search in the PIF thread to try and figure out the other place I mention, but won't name it anymore since I don't want the source of the majority of our remaining prints to get crawled and banned by Google. 🤷‍♂️
[Android Software/Hacking General [Developers Only]] osm0sis:
[ quoted post removed by moderator ]

You're repeating yourself and you're posting everywhere, multiple posts in a row, so yeah, you need to slow down and read (sometimes between the lines) and search. I've explained my reasons pretty clearly.

You're also being obtuse. You're basically cross-posting here and in the PIF thread right now, so you absolutely know where the PIF thread is. Searching that thread for my old posts aside, if you can't even put tadiphone and specdevice into Google to get started on finding the 6 working prints between them which I just outright told you about, then I don't think anyone can help you. I'm certainly done.
[Android Software/Hacking General [Developers Only]] pr3dicament:
Now I do. Alright, see, I just wanted to make sure. I'm sorry about the cross-posting. I was trying to figure it out is all.. that's what I want to do.. figure this out... I apologize. I normally would delete posts but apparently I can't. or believe me, I'd be deleting many. You're right. I do need to slow down and ease up. I just wanted an answer that I could at least understand and even make sure of.. I'm sorry, once again. I'm trying my best.
[Android Software/Hacking General [Developers Only]] jq555888:
Darn... really got hit by Google hard this time :/ thank you for testing though
[Android Software/Hacking General [Developers Only]] osm0sis:
Thanks should go to @zgfg, @TraderJack and @TheFreeman193 for their ongoing testing efforts! 👏🍻
[Android Software/Hacking General [Developers Only]] osm0sis:
I just had someone confirm to me that there are indeed some new dumps added to tadiphone which also have prints passing PI, so there're more than the 4 left there that we originally thought!

Edit: Yep, we found 34 working prints from recently. 2 from tadi so that makes at least 6 working there currently. One of those is special, perhaps for obvious reasons, and that one should lead people to the bulk of the other new ones that aren't on tadi.
[Android Software/Hacking General [Developers Only]] markdewet:
Hi all, so I have a perhaps dumb question, but something I have JUST noticed on my SM-G955F, after updating to PIF v9 (thank you Osm0sis!!!) and rechecking integrity in TB Checker, is that TB Checker shows under "device build fingerprint" that I have xxxx/xxxx/release-keys (not putting full details in as it may get blocked!!). Does anyone perhaps have ANY idea where this could come from? The last time I checked the ROM it was signed with test-keys, or am I getting confused??