[Support] Privacy Inspector

[Diogenes]

Hey, Xeudoxus!

Let me say, I'm really impressed by Privacy Inspector. Definitely a must-have with all the traitorware showing up on the market these days.

I'm about to launch a new blog (a little F&F thing, since I keep running into facebook length limits) about that sort of thing, and I am planning on talking about said traitorware, and was hoping you could answer a few questions about PI and PB for me.

Particularly, how do they work? Since PI identifies potential nastiness that has no associated permission, it's clear to me that it goes beyond a cursory examination of the perms list. Does it scan the app itself for certain API calls? And how do PB's fixes work? Is it just a matter of blocking permissions, like the functionality that's showed up in Cyanogen recently, or something beyond that, so that it can stop the things that aren't associated with permissions to?

I confess, the second question is dual-purposed. It's not only for my article, but I'm also curious because I'm considering upgrading to PB.

Thanks!

-DD

[xeudoxus]

Hey, Xeudoxus!

Let me say, I'm really impressed by Privacy Inspector. Definitely a must-have with all the traitorware showing up on the market these days.

I'm about to launch a new blog (a little F&F thing, since I keep running into facebook length limits) about that sort of thing, and I am planning on talking about said traitorware, and was hoping you could answer a few questions about PI and PB for me.

Particularly, how do they work? Since PI identifies potential nastiness that has no associated permission, it's clear to me that it goes beyond a cursory examination of the perms list. Does it scan the app itself for certain API calls? And how do PB's fixes work? Is it just a matter of blocking permissions, like the functionality that's showed up in Cyanogen recently, or something beyond that, so that it can stop the things that aren't associated with permissions to?

I confess, the second question is dual-purposed. It's not only for my article, but I'm also curious because I'm considering upgrading to PB.

Thanks!

-DD

PB and PI never looks at any permission list .
It works by baksmali/smali , the apps will decompile the classes.dex and search each line of code for patterns that match the "definition list" once a snippet of code has been found, (in PB) you will have the option to "fix" it. Pb will then redo the scan and replace the code that "example: looks up your uid" and replaces it with default values (You can adjust the values if you want) so when the application is loaded and that section of code is used, it will return the values you want (So fake data). This is the best way to handle blocking "permissions" inside applications because you can select which sections of code you want or don't want (If 2 sections of code use the same permission and you only want to block 1). After PB is done modding the smali it recompiles, adds the modded classes.dex, resigns the .apk, then asks if you want to uninstall your "unmodded version" to install the modified one.

The risks of just blocking the permissions in AndroidManifest.xml are great because you don't know if it will cause the app to FC and there are other lines of code that do not even use permissions (Apps are not coded to handle "nulls" when they try and use code that has been blocked). Just blocking permissions is defiantly the most easy to implement. But when I first created PB/PI it was the first option I looked at and I had about 5% app success rate with the apps I tested. The method I use now has about a 90% success rate with the apps I tested. Continued work on PB/PI is needed to make sure it works on all apps (Which ill hopefully get to work on soon).

At this time, the PB/PI definition list is about 30%, in time all "bad code" will be added to the list.

If you have any other questions let me know.

-Matt