yashsingh1/xdaforums huggingface dataset:
[Android Software/Hacking General [Developers Only]] zgfg:
In dedyn, there are no product-build.prop.

But I caught some cases where ro.product.vendor.cert, ro.product.mod_device, ro.bootimage.build.fingerprint, or ro.bootimage.build.date.utc were present in vendor-build.prop, and I added them

For some of them (but not recalling exactly anymore) there were no duplicates with other props.

Therefore I put to read all of them, but pushing that reserves/substitutes as the last choice, if those fields cannot be found among the first-choice props

It's kind of guessing...

I first had a warning in the script to tell me if some of the fields were not found. Then I cought those cases and analyzed what was present or not in the vendor-build.prop. files. I added the reserve values, and in future I had less cases where the pif could not be created. But with the low rate of passing Device Integrity, it is hard to pick up a case to prove which of the possibilities are really better - eg, to read DEVICE from the 'reserve' or to extract from FINGERRPRINT

But if FINGERPRINT is missing, then the game is over - hence I put everything I manually found for the FINGERPRINT (besides, when I had the 'reserves' for FINGERPRINT, they were equal to the first-choice)

Similarly for some others - when the two or three were present in the particular vendor-build.prop I was looking to initially, they were equal. But later when I wrote the script to read through all the choices in that order, I stopped analyzing each or the hundreds of the prop files does it have first, second, third choice, and if several are present are they equal or with which of them there is a better chance to pass Device Integrity:-(
[Android Software/Hacking General [Developers Only]] osm0sis:
More fresh utility updates!

I work on these projects in my limited time off, so if you like the progress I'm making, or enjoy anything else I've done on xda, please consider sponsoring my ongoing work using my GitHub Sponsors profile. For a one-time donation you can hit the donate link from my profile. Thanks for your support!

UPDATE-nano.Terminal.Editor.v8.0-signed.zip:

- update to latest libncursesw.a (v6.5) from upstream GNU ncurses official source

- update to latest nano official source

UPDATE-mtd-utils.Installer.v2.2.0-signed.zip:

- update to latest mtd-utils official source

Build scripts updated accordingly.

Happy hacking! 🤘
[Android Software/Hacking General [Developers Only]] osm0sis:
PIFork v9 Release Candidate post over in the PIF thread:

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

Please test and report any issues. 🙌
[Android Software/Hacking General [Developers Only]] osm0sis:
Is no news good news? 🤔
[Android Software/Hacking General [Developers Only]] zgfg:
Some news :)

Can you add -i option to the migrate.sh Help (line 4):

-h|--help|help) echo "sh migrate.sh [-i] [-f] [-o] [-a] [in-file] [out-file]"; exit 0;;

Btw, tested an older CI but the Zygisk mode (+ autopif and migrate scripts), everything ok.

Also, maybe you could release before the (scripts-mode) becomes obsolete
[Android Software/Hacking General [Developers Only]] osm0sis:
-i|--install|install mode is an internal option to make migrate output less verbose (for use during the module's installation and now autopif), intentionally undocumented for the public help. 😛

Yeah, was waiting for some feedback before release but none came until now! 😆

I did some more dogfooding a couple days ago and tightened up autopif integration a bit more for the new RC, #221, so hopefully all is well for everyone and I'll start working on the release documentation...
[Android Software/Hacking General [Developers Only]] zgfg:
Dropping down some ideas, altough thinking a big picture there is probably not much use in that (G stopped banning and maybe they'll soon shift dieections):

- service.sh (yeah, it will do only on every reboot and that might be already too late) can check the timestamp when rhe last time autopif checked was there a new XEU injector

- so, eg, upon 15 days (1st reboot thereafter) trigger autopif to download the new injector; or just forget the timestamp and do that every time when running service.sh

- if there was no new injector (it can be recognized even by checking the injector app on the XEU store before downloading), do nothing

- otherwise, download the new injector, migrate and inatall the new prints

- kill gms to put the new prints in use for the next PI attestation

- service.sh can even (that's cool) push-notify the user that prints were updated

(Btw, you could similarly make it for the BB NDK module, to enforce auto-updating the binary/applets, with no needs for updating the module)

My (old) ToyBox module service.sh attached with the described functionality. Search eg for PASSEDTIME, wget and notification key words (to point how it was implemented - you'll need only the trick for push-notification from the script)
[Android Software/Hacking General [Developers Only]] osm0sis:
Agreed could be useful, but fully automatic isn't the way I want to go with it. That said, a couple notes in return anyway:

- No Wi-Fi to do anything at service.sh timing I think, and I wouldn't want to use mobile data either if it happens to be working at that point.

- killgms already auto-runs at the end of autopif now when it's in the module directory.
[Android Software/Hacking General [Developers Only]] zgfg:
Yeah, at that time I searched a lot trying to find how to make script to know if the phone was already connected to WiFi

At the end I postponed few more seconds upon booting was completed

and when I was at home it was on the edge to get connected to my WiFi before running the wget, and I also limited for how long wget should attempt downloading

Btw, I had to enforce using BB wget, since the built-in wget version misses the -c and/or -T options:

/data/adb/magisk/busybox wget -c -T 20 ...

The cool thing was push-notification from the script but it required switching to shell (su 2000), it didn't work from root:

su -lp 2000 -c "cmd notification post -S bigtext -t 'My Notification' 'Tag' 'This is a push notification'"

And I was not able to make working the additional customization options like shortcut etc:

Notification(channel=shell_cmd shortcut=null contentView=null vibrate=null sound=null flags=0x0 color=0x00000000 vis=PRIVATE)
[Android Software/Hacking General [Developers Only]] bigknowz:
Is upping wallet min API?

Google Wallet dropping support for old Android & Wear OS versions

Starting next month, Google is increasing the minimum OS version for Wallet on Android phones and Wear OS with security cited as the reason.

9to5google.com
[Android Software/Hacking General [Developers Only]] zgfg:
Yeah, see there was some discussion in the PIF thread. We will see what comes next, when and if
[Android Software/Hacking General [Developers Only]] trevtdogg:
just wanted to add yet another thank you out in public @osm0sis for all of your efforts!

it was so simple just now to find this thread, find autopif.sh, download it, run it, and be up and running with device integrity again.

i really appreciate it :)
[Android Software/Hacking General [Developers Only]] fbirraque:
Anyway back to the game with previous V8.

But I'll update to v9 now and will feedback if any issue found.

Thanks again for your always amazing .sh to import custom.pif... 👍🏻
[Android Software/Hacking General [Developers Only]] Wolfcity:
Seen this a little bit late but because of the need to change my print :oops:I used your RC #221 to do the job and the module worked out perfectly as it did since it's appearance.

Thanks for adding some goodies like the killgms.sh script and updating autopif and Co.

Good job as usual.

Thanks!
[Android Software/Hacking General [Developers Only]] pershoot:
@osm0sis I just installed your v8 PIF fork from GH and will give it a whirl :) Thx!
[Android Software/Hacking General [Developers Only]] osm0sis:
v9 RC build #222 up now: https://github.com/osm0sis/PlayIntegrityFork/actions/runs/9105622630

Basically done except for updating documentation for the new features. 👍
[Android Software/Hacking General [Developers Only]] pershoot:
Nice, thx; updated.

lynx:/data/adb/modules/playintegrityfix # cat module.prop

<snip>

version=v8

versionCode=80001

</snip>
[Android Software/Hacking General [Developers Only]] zgfg:
If he already put v90000 and built the RC with, then you, once you install that RC would not see the Update for the final v9 when v9 would be released

Your installed versionCode (coming with module.prop in the installation zip) must be lower than the versionCode in the update (in update json), for the Update button in Magisk app, Modules tab to work properly
[Android Software/Hacking General [Developers Only]] pershoot:
Yup, all good; I usually update manually. This is to prevent potential uncoupling of patched magisk kernel / unrooting, which I noticed in a past version (uncertain if it still occurs on latest but have gotten in to a routine with it).
[Android Software/Hacking General [Developers Only]] zgfg:
Good that it works - and it does

Btw, you can manually edit your

/data/adb/modules/playintegrityfix/module.prop

and put v10 in - once you reopen Modules tab in Magisk app it will show as that you 'have' v10 installed

But that's only a presentation and playing with module.prop can spoil further notifications for the updates
[Android Software/Hacking General [Developers Only]] fbirraque:
Updated from #221 to #222

It was flawless and still working flawlessly.

Thanks for always improve what's not broke, :)
[Android Software/Hacking General [Developers Only]] Wolfcity:
Updated too, everything's perfect.

A11 /Magisk 27000.

Thanks!
[Android Software/Hacking General [Developers Only]] fbirraque:
I also update from #222 to the #223 and the Play Integrity (Basic and Device) are working flawlessly.

I don't think it's related with the CI# PI module but my Poco F3 without any apparently reason lost the Wallet certification yesterday as mentioned in the other thread

Nothing changed in the apps or root and I never had this issue when PI previously certified.

I appreciate if anyone know how to handle it.

Maybe the PIF by XiaomiEU (Clark)?
[Android Software/Hacking General [Developers Only]] osm0sis:
Nothing's been changed since v7 on the hooking side, so all should work the same. Has your ROM updated? Is there a new update to the Xiaomi.eu Injector that needs uninstalling?
[Android Software/Hacking General [Developers Only]] zgfg:
I've only seen a similar report on Xiaomi.eu, but IMO that's not you (than another senior there)

https://xiaomi.eu/community/threads/installing-magisk-and-play-integrity-fix.70553/post-727277

Possiblity related to Clark?!

I'm on private prints...
[Android Software/Hacking General [Developers Only]] fbirraque:
I'm 100% confident that is not related with your PI CI #

Yeah everything right in my settings and I didn't change anything since last December.

The NFC Payments always worked perfectly but after Clark installed the Wallet and the Bank app are complaining that device isn't secure to use fingerprints.

Already cleaned Bank app, NFC, Play Services, Store and update my fingerprint but didn't solve.

I had same behavior in the past when using a PIF from some Android TV. So I'm almost sure that with another PIF things could work smoothly again but I lost my 30 private fingerprints in the last Google blocks ... 🤷
[Android Software/Hacking General [Developers Only]] CamoGeko:
Thanks for the amazing zips! Saved so much time :D
[Android Software/Hacking General [Developers Only]] mikeoswego:
[MENTION=4544860]osm0sis[/MENTION] or anyone.

When updated GApps are installed in a CM rom, somehow the apps in /data/app that have been dl'd from the play store and are equal to or older than the installed GApps are deleted and packages.xml is updated with the updated info. Can you or anyone point me to where this is accomplished?

I'm working with roms for the MotoX xt1096 using mofo where we have root but no write access to /system except when the image is mounted on a pc. I'd like to update the GApps in the rom but that is not as attractive if things aren't cleaned up in /data. There is an init script that runs post boot that I've modified and I can identify the version of the apps in the rom that are set as updated in packages.xml. Then I can use "pm -k uninstall $packagename" which works but user settings are not retained and play services is denied. I've also tried "am start -n "com.android.packageinstaller/.UninstallerActivity" -d "package:$packagename"" but this raises dialog boxes for each app and still won't handle play services.

I know this is an off the wall question but somehow CM roms do this cleanup even for play services but I'm stuck and hope someone more knowledgeable than me can point me in the right direction.
[Android Software/Hacking General [Developers Only]] osm0sis:
We were just discussing this the other day in the TK GApps Discussion thread. Give a search there for the relevant part of the ROM code. It's part of AOSP and recently (Lollipop) changed so that the current version doesn't get removed from /data/app, only old versions. This is apparently to pave the way for multi-part APKs.

I'm not sure what the function of your script is if you don't have write access, but cleanup should happen on its own during "Android is upgrading..." if you're updating the GApps in /system by any method.

Can you point me to your script? I was looking at writing something similar to integrate /data/app GApps into /system, complete with libs (unlike Titanium Backup), for KK and JB (for now).

Tonight, so far, I've got the following (untested)...

/system/etc/init.d/000gappsintegrator:

[code]

Edit: Did some testing on this and it has a few issues I'm working to resolve. I'm going to remove it until I do.
[Android Software/Hacking General [Developers Only]] osm0sis:
[MENTION=1162986]Captain_Throwback[/MENTION]

<36>[ 5.592661] type=1400 audit(10666621.200:10): avc: denied { search } for pid=231 comm="00test" name="/" dev="fuse" ino=0 scontext=u:r:init_shell:s0 tcontext=u:object_r:fuse:s0 tclass=dir permissive=0

Pulled that from my dmesg. 00test is an init.d script I was using to test if init.d support was working and it didn't execute, so it looks like the logwrapper init.d support injector we came up with is having SELinux troubles. Any ideas to get around it without going Permissive?
[Android Software/Hacking General [Developers Only]] osm0sis:
Really I think the problem is all your methods, in practice, are trying to uninstall the apk; that's why you're losing the app data. All Android does that I can see is old-fashioned delete the actual older /data/app apk, dex/oat the new /system apk then clean up packages.xml, leaving the app data intact for the new /system apk to continue using.

So if I were you, I'd try just switching out the am/pm command you were trying for simply "rm -rf /data/app/$apkname" or whatever and see what happens with the rest.
[Android Software/Hacking General [Developers Only]] mikeoswego:
No, no, it can't be that simple! :p I found another script in the rom to modify that runs early enough that it is using the rom date instead of the actual date when writing files; I think that is early enough for this purpose.

When I rm -rf the app copy in /data/app, packages.xml is not updated, even if the dalvik-cache is cleared so the app is effectively removed from the system. Unless there is an am/pm command that would force a rebuild of packages.xml, I'm pretty sure what I need to do now is remove the apps "<package name=" entry in packages.xml and modify the "<updated-package=" name entry to remove the "updated-" part, and change the version number to finally have this working the way I want.
[Android Software/Hacking General [Developers Only]] osm0sis:
Packages should get rebuilt on the next reboot after the init.d runs.
[Android Software/Hacking General [Developers Only]] mikeoswego:
Agree that this should happen and does in other roms. Unfortunately not with this one.

I found that if I manually edit pacakges.xml to remove the <package entries for the app and then change the <updated-package entries to <package; and reboot, the system sees this, presents the updating apps dialog for those apps, places the correct version into packages.xml, all settings are preserved. So, now I'm working on doing that in the script and will post back my resulsts.
[Android Software/Hacking General [Developers Only]] osm0sis:
Nice job! Cool to figure out the mechanics of how packages.xml relates to Android optimizing. :D
[Android Software/Hacking General [Developers Only]] osm0sis:
I'll just leave this here... ;)

All credit to [MENTION=4793042]pkgnex[/MENTION] for the time and effort spent on this thorough Lollipop(+) refresh of the old "Dev Team" init.d scripts. Thank his post below. :highfive:

Edit: Rehosted - https://basketbuild.com/devs/osm0sis/scripts/

Edit 2: BasketBuild seems dead again, so attaching the old installer (with outdated scripts) below for posterity, and also pkgnex's updated versions in a simple (non-flashable) zip. :good:
[Android Software/Hacking General [Developers Only]] pkgnex:
Thanks, osm0sis.

Glad to contribute a little something to your awesome work.

If anyone has any questions, I'll be glad to answer if I can.
[Android Software/Hacking General [Developers Only]] Captain_Throwback:
Unfortunately I don't know enough about SELinux to know how to fix it. That would explain why it stopped working for me, though.
[Android Software/Hacking General [Developers Only]] osm0sis:
Yeah, in no particular order.. :)

1) Mine doesn't need editing of packages.xml because Android does it itself afterwards when it does the Dalvik stuff.

2) Version number doesn't matter because this is only for people who don't want to flash GApps more than once and just let Play Store keep them up to date and then let the script keep them integrated to save space.

3) If CM updates things on the Play Store with com.android too, I'd thought of that and decided it's fine, it'll get integrated and its not a big deal.

4) /data only houses the libs in Lollipop+, so yeah, if/when I go to add support for that it should make it faster/easier, but for now this is KitKat and Jelly Bean (and possibly Ice Cream Sandwich) only.

So for my purposes mine works great, but for your purposes, by the sounds of it, you need yours. I wasn't trying to duplicate your functionality for your specific case. :good:
[Android Software/Hacking General [Developers Only]] mikeoswego:
Right, I got mixed up. You are integrating updated apps in /data into /system where I'm wanting to delete apps in /data that have been updated in a read-only /system environment. From your example, it looks like maybe I just need to rm -rf the old apps in /data and not worry about rewriting packages.xml (which I spent a lot of effort figuring out how to do!) I'll test that out.
[Android Software/Hacking General [Developers Only]] mikeoswego:
At the risk of talking to myself.. :silly: I found that in my application, that simply doing an rm -rf on the apps in /data/app was not enough, the apps were not available and packages.xml was not updated and there was no optimizing apps process. Running the original script with the packages.xml editing routine still in place, caused the built-in optimizing aps routine to run and packages.xml was updated.

So I'm not sure at this point if simply touching packages.xml causes the built-in optimizing to fire or if the 5.1 system always validates the packages in /system/app & /system/priv-app against packages.xml updating any changes found and fires the optimization unless the package entry is marked as updated in which case it is ignored. And apparently there is no validation of the packages in /data/app since it happily ignored the deleted apps, did not automatically fix packages.xml and didn't load the app in /system.
[Android Software/Hacking General [Developers Only]] osm0sis:
This seems like it could be the when and why of it (comments):

https://01.org/jira/browse/BA-262

If I'm right, the logwrapper command itself shouldn't be crucial to the script, (it's just a nice way to output script errors to the dmesg like run-parts does), so I can just remove it. I'll mess around with other ways, or, at worst we can just do away with the logging and hopefully still have our simple init.d work. :good: ;)

Edit

: Seems like logwrapper wasn't the whole problem, find was failing too, so I switched it to ls and that seems to get the scripts to run, and I can funnel them out to kmsg to preserve the logging, but still we have permission problems in the scripts themselves:

<4>[ 4.513739] /system/etc/init.d/00test[3]: can't create /sdcard/test.txt: Permission denied
<36>[ 4.513827] type=1400 audit(11880703.140:15): avc: denied { search } for pid=230 comm="00test" name="/" dev="fuse" ino=0 scontext=u:r:init_shell:s0 tcontext=u:object_r:fuse:s0 tclass=dir permissive=0

Edit 2

: I've even tried invoking su and allowed su during boot in SuperSU settings but things still get blocked somehow.. :confused:

Given that, the only real solution I can think of is to set SELinux permissive as part of the flashing process.

This is the most functional version I've come up with so far; I've also simplified it a bit where I hadn't thought to before:

# Execute files in /system/etc/init.d before booting
service run-parts /system/bin/sh -c "for i in /system/etc/init.d/*; do if [ ! -d $i ] && [ -x $i ]; then . $i > /dev/kmsg 2>&1; fi; done;"
class late_start
user root
group root
oneshot

Edit 3

: And more bad news.. It seems as if there's no way to disable SELinux in stock Lollipop kernels, or at least stock ramdisks, which would likely mean heavier modifications like swapping out init for the AOSP version, at which point we might as well just go back to putting busybox in /sbin and try executing run-parts to keep things simple. :(

Edit 4

: Nope..

root@hammerhead:/ # dmesg | grep busybox
<3>[ 4.433790] init: cannot execve('/sbin/busybox'): Permission denied

Well I'm out of ideas. I guess I'll make it non-stock only with the slim version above to at least update support for KitKat and lower, and also add this SELinux permissive cmdline chunk at the bottom before repack to hopefully support non-stock Lollipop(+) ramdisks:

# add SELinux commandline only in KitKat and newer
android_ver=$(mount /system; grep "^ro.build.version.release" /system/build.prop | cut -d= -f2; umount /system);
case $android_ver in
4.4*|5.*|6.*) cmdtmp=`cat $split_img/boot.img-cmdline`;
case "$cmdtmp" in
*selinux=permissive*) ;;
*) echo "androidboot.selinux=permissive $cmdtmp" > $split_img/boot.img-cmdline;;
esac;;
esac;
[Android Software/Hacking General [Developers Only]] fbirraque:
I lost all my private fingerprints in the last Google blocks... and didn't have time the search for new ones. 😔

That's why I'm currently using Clack even suspecting that it could be the source of the strange behavior.