[Android Software/Hacking General [Developers Only]] zgfg:
Finally, having some time to follow-up and to close my 'private investigation' here.

I've tested in and out, with the following observations, setup and results:

- Tested all folders in dedyn (back in Nov/Dec last year, dedyn was based on tadiphone dumps) where its custom.pif.json show DEVICE as:

qssi and missi (Qualcomm chipsets), mssi (Mediatek chipsets) or essi (Samsung phones and chipsets)

DEVICE is also encoded to the FINGERPRINT, eg:

qti/missi_phone_cn/missi:13/TKQ1.220829.002/V14.0.1.0.TKMCNXM:user/release-keys

and in tadiphone/dedyn it is easy to recognize them by looking to the subfolder names, eg:

missi_phone_cn-user-13-TKQ1.220829.002-V14.0.1.0.TKMCNXM-release-keys

Hence, instead of those 'generic' prints (from /system/build.prop = build.prop in tadiphone):

"MANUFACTURER": "QUALCOMM",

"MODEL": "missi system image for arm64",

"BRAND": "qti",

"PRODUCT": "missi",

"DEVICE": "missi"

reading from /vendor/build.prop (vendor-build.prop in tadiphone) provides vendor.pif.json with:

"MANUFACTURER": "Xiaomi",

"MODEL": "2106118C",

"FINGERPRINT": "Xiaomi/odin/odin:13/RKQ1.211001.001/V14.0.1.0.TKMCNXM:user/release-keys",

"BRAND": "Xiaomi",

"PRODUCT": "odin",

"DEVICE": "odin"

Find that Model '2106118C' and Codename 'Odin' also in the Specs, (and encoded in this URL):

https://phonedb.net/index.php?m=dev...ual_sim_td-lte_cn_512gb_2106118c__xiaomi_odin

These are the real prints that user with that genuine phone and ROM will obtain by querying:

getprop ro.product.manufacturer

getprop ro.product.model

getprop ro.build.fingerprint

etc

- I also looked to the Kirin DEVICEs (Huawei/Honor phones with Kirin chipsets) but there are only few in dedyn (and they don't pass), not enough for further investigation

- Hence, I obtained:

(a) up to a dozen of working prints (meeting Device Integrity) that I already had (287 working prints from various sources)

(b) and discovered (but only) four new working prints.

Interestingly, I found for two of my old custom.pif.json files/prints that used to meet Device Integrity just a month or so ago, that they stopped working (meeting now No Integrity).

However, when I refreshed them by this method and obtained the same/old FINGERPRINT but now with the 'new' (and apparently better) DEVICE and BRAND values, they meet now Device Integrity again

Here I'm also refreshing the scripts that I used:

- gen_pif_custom.sh (update: extended set of props to read from the given vendor-build.prop)

- pif-gen-vendor-json-files.sh (update: looks for vendor-build.prop files only in subfolders with essi, missi, mssi and qssi in the names)

- pif-test-json-files.sh (update: can be provisioned to test only vendor.pif.json files [or only custom.pif.json or all *.json files])

- my_migrate.sh (update: can FORCE to refresh DEVICE, BRAND and other fields from FINGERPRINT even when those fields are already present in the json file)

Hence my testing procedure was:

i) Have all the four scripts on the phone, like in my PIF folder on the Internal memory.

my_migrate.sh must be renamed to migrate.sh (pif-test-json-files.sh looks for the script under its original Osm0sis name)

ii) Have a subfloder, like Testing

iii) Copy a part of dedyn collection to the Testing folder and run pif-gen-vendor-json-files.sh

Wait to finish (few minutes) and read the resulting pif-gen-vendor-json-files.txt file

At the bottom it shows how many ess/missi/mss/qssi subfolders it found with vendor-build.prop files)

and how many vendor.pif.sh files it created (search through the txt file for 'not found' (without quotes), ie, for vendor-build.prop files that were missing props for MANUFACTURER, MODEL or FINGERPRINT as a minimum to create the vendor.pif.json file), eg:

folders=120, created=118

iv) Test by pif-test-json-files.sh - first, open the file and provision your wanted options like:

FOLDERS_DEPTH="5"

MIGRATE_JSON="yes"

DELETE_FAILED="yes"

PIF_JSON="vendor.pif.json"

and wait to finish and read the results pif-test-json-files.txt

To run the script (pif-gen-vendor-json-files.sh or pif-test-json-files.sh), I simply select the script file in MiXPlorer and take Execute from the MiX menu (no need for chmod, command line with the su, path, etc)

As a rule of thumb, I chunk from the dedyn collection to have: created=80-120 in the pif-gen-vendor-json-files.txt in (iii), since their automated testing by (iv) usually requires 30-70 minutes (better put the phone aside during that testing time)

The resulting pif-test-json-files.txt will show, eg:

folders=118

tested=118, setApi25=97, passed=4

failed=101, inconclusive=13

Here, 4 meet Device Integrity, 101 meet Basic Integrity only or No Integrity and testing of 13 messed up by using the phone (eg, phone calls) and bringing other apps to the foreground or by moving around and shortly loosing Internet conection or something (someetimes I test with the phone in my pocket and by riding a car or e-scooter)

On top, pif-test-json-files.txt also displays like:

PID=13118

hence you can always kill the testing (if cannot wait to finish) from Terminal Emulator by (use the right PID):

su -c kill -9 13118

Since I use pif-test-json-files.sh with DELETE_FAILED="yes", all failed json files are automatically deleted, hence I can just re-run the script to retest only those that were not deleted: those that passed, were inconclusive or the process was killed before they were tested

For those that passed, search in pif-test-json-files.txt for MEETS_BASIC_INTEGRITY to find the full path and file names, like:

/storage/emulated/0/PIF/Testing/pif.dedyn.io_prints/<SOMETHING>/vendor.pif.json

SN Basic: Pass, CTS: BASIC: Pass

"SECURITY_PATCH": "<SOMETHING>"

"*api_level": "<SOMETHING>"

MEETS_DEVICE_INTEGRITY

Here there is also a link to the mp4 screenrecording demo from an earlier automated testing and playing with custom json files (not about these vendor.pif.json prints). It basically shows how you can do everything on the phone and from MiXPlorer:

107.35 MB file on MEGA

mega.nz

---

Btw, grabbing form tadiphone GitLab was no use for me since I would have to manually download one by one vendor-build.prop file (ten times slower than their automated testing). Moreover, for some devices there are several build.prop files (with various names and different prints) in the /vendor folder, see eg:

https://dumps.tadiphone.dev/dumps/r...17.001-V816.0.5.0.UMWEUXM-release-keys/vendor

Still, it would be interesting to test all those *ssi prints and combinations