[Android Software/Hacking General [Developers Only]] zgfg:
For many Qualcomm based Xiaomi ROMs, the original gen_pif.custom.sh script that reads prints from build.prop (/system/build.prop) and product-build.prop (/product/build.prop), results with strange custom.pif.json files, eg:

{
"MANUFACTURER": "Xiaomi",
"MODEL": "missi",
"FINGERPRINT": "Xiaomi/missi_phone_global/missi:13/TP1A.220624.014/V14.0.5.0.TLOMIXM:user/release-keys",
"BRAND": "Xiaomi",
"PRODUCT": "missi_phone_global",
"DEVICE": "missi",
"SECURITY_PATCH": "2023-07-01",
"FIRST_API_LEVEL": "31"
}

However, if reading the prints from vendor-build.prop (/vendor/build.prop) instead (and some of them under the slightly different prop names there), you will obtain the meaningful prints:

{
"MANUFACTURER": "Xiaomi",
"MODEL": "xaga",
"FINGERPRINT": "POCO/xaga_global/xaga:12/SP1A.210812.016/V14.0.5.0.TLOMIXM:user/release-keys",
"BRAND": "POCO",
"PRODUCT": "xaga_global",
"DEVICE": "xaga",
"SECURITY_PATCH": "2023-07-01",
"DEVICE_INITIAL_SDK_INT": "31"
}

The above is an example for the Poco ROM, and here the first, custom.pif.json (extracted from build.prop) fails both the Basic and Device Integrity, while the second, vendor.pif.json (extracted from vendor-build.prop) passes Basic Integrity

Or another, more drastical example, actually from Lenovo, and observe here its descriptive MODEL 'name' in the custom.pif.json (have you ever heard of that 'model'):

{
"PRODUCT": "qssi",
"DEVICE": "qssi",
"MANUFACTURER": "QUALCOMM",
"BRAND": "qti",
"MODEL": "qssi system image for arm64",
"FINGERPRINT": "qti/qssi/qssi:12/SKQ1.211019.001/13.5.332_220407:user/release-keys",
"SECURITY_PATCH": "2022-02-01",
"FIRST_API_LEVEL": "30"
}

While the vendor.pif.json extracted from vendor-build.prop gives: different prints:

{
"PRODUCT": "doom",
"DEVICE": "doom",
"MANUFACTURER": "Lenovo",
"BRAND": "Lenovo",
"MODEL": "Lenovo L70081",
"FINGERPRINT": "Lenovo/doom/doom:12/SKQ1.211019.001/13.5.332_220407:user/release-keys",
"SECURITY_PATCH": "2022-02-01",
"DEVICE_INITIAL_SDK_INT": "30"
}

Again, vendor.pif.json passes the Basic Integrity (unfortuunately, not Device Integrity), whereas the custom.pif.json fails already on Basic

API levels must be usually downgraded to 25...

---

Below is attached my modified gen_pif_vendor.sh script, tailored to Xiaomi/Redmi/Poco ROMs (but from the Lenovo example it seems that it could apply to the more phones with Qualcom chipsets), that:

- reads from vendor-build.prop file (see in the source for which props)

- creates vendor.pif.json custom files (you can later rename as you wish but I wanted to have different name to be able to compare and test them in parallel)

- moreover, script can be called with the path argument where to read the vendor-build.prop file (and to create the resulted vendor.pif.json)

Attached is also an outer script pif-gen-vendor-json-files.sh that crawls through the folders, looks for the downloaded vendor-build.prop files, calls the inner script gen_pif_vendor.sh to create vendor.pif.json files, and prints the results with how many vendor-build.props were found and how many vendor.pif.json have been created (cannot create the JSON if MANUFACTURER or FINGERPRINT were not found from the vendor-build.prop)

If you still have the old, good, tadiphone dumps, here you have something for this weekend...

---

So far I tested dumps from about 200 ROMs, unfortunately did not find a new prints to pass Device Integrity, but the results are interesting (and maybe promissing)

For the testing I used in parallel both the custom.pif.json (created by the original gen_pif_custom.sh script, from build.prop and product-build.prop) and vendor.pif.json (created by this 'new' gen_pif.vendor.sh script, reading from vendor-build.prop), and then used my pif-test-json-files.sh (new version) to crawl through the folders, and for each JSON file to call first migrate.sh script (osm0sis) and then to test them with his PI Fork v8, and retests with the downgraded API level if needed

- One ROM that passes Device Integrity with the original custom.pif.json, passes now also with this 'new' vendor.pif.json and the prints in the JSON files are actually identical

- For all ROMs where original custom.pif.json pass Basic Integrity, the new vendor.pif.json pass also the Basic Integrity, however:

-- in some cases, prints are identical

-- in some cases prints are identical except for the Security Patch Dates

-- in some cases prints are totally different (similarly like in the examples above)

- Vice versa, whereas vendor.pif.json fails Basic Integrity, the 'old' custom.pif.json fails, too

- And of course, in some cases this new vendor.pif.json passes Basic Integrity while the 'old' custom.pif.json fails even the Basic :)

- Originally I didn't enable testing SN with Yasnac, hence having for now only the SN results for about twenty ROMs that pass Basic Integrity with both custom.pif.json and vendor.pif.json, and all those pass of course SN Basic, some failing CTS with BASIC and some with HARDWARE_BACKED evaluation

PS: I see that osm0sis has released a newer version of gen_pif.custom.sh (that doesn't need to be followed by migrate.sh), but the point here is in different prints that gen_pif.custom.sh (old or new) reads from build.prop and product-build.prop vs different prints that gen_pif.vendor.sh reads from the vendor-build.prop

However, this alternative gen_pif.vendor.sh script applies to (some) phones with the Qualcomm chipsets, where the build.prop files contain genetic prints for the given Qualcomm board, while vendor-build.prop files provide actual prints for the real vendor and model ROM

Btw, also the corresponding build UTC timestamps are different. in some cases the (generic) from build.prop is older for only few hours, and in some cases for days or few weeks (resulting with a month older Security Patch date)

Edit

gen_pif.vendor.sh script updated on Apr 16, 2024