Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How accurate is the report on used permissions? #10

Open
IzzySoft opened this issue Aug 22, 2016 · 5 comments
Open

How accurate is the report on used permissions? #10

IzzySoft opened this issue Aug 22, 2016 · 5 comments

Comments

@IzzySoft
Copy link
Contributor

For the app CameraFilter, LibRadar found the library Android Support v4 being used and accessing functions requiring the permissions android.permission.ACCESS_NETWORK_STATE, android.permission.WAKE_LOCK and android.permission.VIBRATE. However, the app itself just declares CAMERA, READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE in its Manifest – not a single match here.

So how should the permissions reported for a library be interpreted?

(Note: if you want to check for yourself, the .apk can be downloaded from the page behind the first link)

@pkumza
Copy link
Owner

pkumza commented Aug 25, 2016

Yes. I've checked and found permissions are always different.
LibRadar's permission detection is based on API. We referred database of Pscout
Apps' permissions are written in the manifest file.
They are sometimes different because some permissions that an API need are not recorded in manifest file. Maybe that API can be ignore or the function is not very important, but it really exists in the code, so we take the permission as existence though the permission is not applied in manifest file.

@IzzySoft
Copy link
Contributor Author

OK, thanks. Thought something along those lines already – having read of some "intrusive ad modules" having few "hard requirements" (e.g. INTERNET only) – but grabbing anything the app itself has access to (e.g. READ_CONTACTS) if available. So basically, they try to access it – but have a catch block in case they fail. That's the same you're pointing at?

@pkumza
Copy link
Owner

pkumza commented Feb 22, 2017

in the lastest Pscout website, many APIs uses permission android.permission.DUMP and I don't know why.
It appears that after this update, many libraries will contains permission android.permission.DUMP.

@IzzySoft
Copy link
Contributor Author

I somehow doubt they really do use that. Rather unlikely. Not that usual, this permission.

@avahidi
Copy link

avahidi commented Apr 29, 2019

Not sure if this is still relevant, but I found this in the "REAPER: Real-time App Analysis ..." paper:

When comparing the mappings of PScout and AXPLORER, we find various differences in their results;
in API 22 AXPLORER registers the function getWifiState() in net.wifi.WifiManager with the
ACCESS_WIFI_STATE permission. On the contrary, PScout registers the same function with the
DUMP permission. As such, it is important to dynamically validate the permission mappings ...

see https://github.com/reddr/axplorer

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants