avoid getting incorrect path from other plugin apk about stunning-signature

[alexcohn]

the non 'base' APKs are also signed with the same key

Sure they are, unless there has been some tampering. I am not sure what you are looking for, but if you care about malicious or accidental inconsistencies, you must analyze all of them.

[xwf20050250]

@xwf20050250 Thanks for this, Just wondering if you know how robust this is, have you tested on many devices or in the wild? Are we sure it will always reside in /data/app or /mnt/?

@emileb
yes, in some of lowlevel android devices(e.g. Bird M6...) the path of base apk is in /mnt/...

if there is some plugin apk in our package, maybe we will get incorrect path(e.g. /data/data/com.dw.fff.uc/ucgamesdk/modules/update-1/cn.uc.gamesdk.loader.apk) which is matched to the plugin.

therefore, we should restrict path to /data/app or /mnt/.

of course, it works fine on production env until now.

[emileb]

@xwf20050250 Thanks for this, Just wondering if you know how robust this is, have you tested on many devices or in the wild? Are we sure it will always reside in /data/app or /mnt/?

[alexcohn]

will always reside in /data/app or /mnt/?

Well, yes. It will be either under /data/app or /mnt/asec… But there may be more matching lines in your /proc/self/maps. E.g. experitest injects the tester APK into your process. Another concern is that for app bundles, you must find the 'base' APK.

[alexcohn]

another concern is that if you have process attribute, it will override /proc/self/cmdline.

[emileb]

Thanks for the info @alexcohn. In my limited testing it appears the non 'base' APKs are also signed with the same key, so I believe it's acceptable to find any of the APKs in the bundle (which appears to happen randomly on my test devices)