search

M66B / XPrivacy

XPrivacy - The ultimate, yet easy to use, privacy manager
http://forum.xda-developers.com/xposed/modules/xprivacy-ultimate-android-privacy-app-t2320783
GNU General Public License v3.0
2.08k stars 526 forks source link

Poweramp full version can't verify license #1340

Closed Lasermole closed 10 years ago

Lasermole commented 10 years ago

Since update to 1.99.42 poweramp won't load as its unable to verify license. Pretty upset as its my favorite music app. Tried everything I can think but the only thing that works to allow me to launch poweramp is to disable Xprivacy in xposed to use it. I don't want to compromise on privacy for the sake of poweramp's crappy license system.

M66B commented 10 years ago

Can you please provide a logcat?

Lasermole commented 10 years ago

I would love to. Haven't done one before. Hate to bother you but can you explain to me a quick way for me to grab one for you? On Feb 13, 2014 3:55 PM, "Marcel Bokhorst" notifications@github.com wrote:

Can you please provide a logcat?

Reply to this email directly or view it on GitHubhttps://github.com/M66B/XPrivacy/issues/1340#issuecomment-35024753 .

M66B commented 10 years ago

https://github.com/M66B/XPrivacy#FAQ14

Lasermole commented 10 years ago

Ok I got a logcat. Hope it's got the pertinent data.

--------- beginning of /dev/log/main [ 02-13 16:38:00.017 3964: 6387 I/XPrivacy/XRuntime ] get 10292/exec shell=!restricted (cached) [ 02-13 16:38:00.017 3964: 6387 I/XPrivacy/XRuntime ] get 10292/exec shell=!restricted (cached) [ 02-13 16:38:00.037 3964: 3964 I/XPrivacy/XContextImpl ] getSystemService display=android.hardware.display.DisplayManager uid=10292 [ 02-13 16:38:00.037 3964: 3964 I/XPrivacy/XContextImpl ] getSystemService window=android.view.WindowManagerImpl uid=10292 [ 02-13 16:38:00.047 3964: 3964 I/XPrivacy/XContextImpl ] getSystemService power=android.os.PowerManager uid=10292 [ 02-13 16:38:00.047 3964: 3964 I/XPrivacy/XActivity ] getSystemService power=android.os.PowerManager uid=10292 [ 02-13 16:38:00.087 3964: 3964 D/AbsListView ] unregisterIRListener() is called [ 02-13 16:38:01.097 3964: 3964 D/AbsListView ] unregisterIRListener() is called [ 02-13 16:38:02.007 3964: 3964 D/AbsListView ] unregisterIRListener() is called [ 02-13 16:38:02.037 3964: 3964 D/AbsListView ] unregisterIRListener() is called [ 02-13 16:38:02.067 3964: 3964 D/AbsListView ] onVisibilityChanged() is called, visibility : 4 [ 02-13 16:38:02.067 3964: 3964 D/AbsListView ] unregisterIRListener() is called [ 02-13 16:38:06.347 3964: 3964 I/XPrivacy/XActivity ] getSystemService layout_inflater=com.android.internal.policy.impl.PhoneLayoutInflater uid=10292 [ 02-13 16:38:06.347 3964: 3964 I/XPrivacy/XActivity ] getSystemService layout_inflater=com.android.internal.policy.impl.PhoneLayoutInflater uid=10292 [ 02-13 16:38:06.357 3964: 3964 D/AbsListView ] onVisibilityChanged() is called, visibility : 0 [ 02-13 16:38:06.357 3964: 3964 D/AbsListView ] unregisterIRListener() is called [ 02-13 16:38:06.357 3964: 6387 I/XPrivacy/XRuntime ] get 10292/exec shell=!restricted (cached) [ 02-13 16:38:06.357 3964: 6387 I/XPrivacy/XRuntime ] get 10292/exec shell=!restricted (cached) [ 02-13 16:38:06.367 3964: 3964 D/AbsListView ] unregisterIRListener() is called [ 02-13 16:38:06.367 3964: 3964 I/XPrivacy/XContextImpl ] getSystemService display=android.hardware.display.DisplayManager uid=10292 [ 02-13 16:38:06.367 3964: 3964 I/XPrivacy/XContextImpl ] getSystemService window=android.view.WindowManagerImpl uid=10292 [ 02-13 16:38:06.367 3964: 3964 I/XPrivacy/XContextImpl ] getSystemService power=android.os.PowerManager uid=10292 [ 02-13 16:38:06.367 3964: 3964 I/XPrivacy/XActivity ] getSystemService power=android.os.PowerManager uid=10292 [ 02-13 16:38:06.377 3964: 3964 D/AbsListView ] unregisterIRListener() is called [ 02-13 16:38:06.377 3964: 3964 D/AbsListView ] unregisterIRListener() is called

M66B commented 10 years ago

The (short) logcat does not contain useful information. I have check all the code for accidentally restricting this, without settings it, but I am quite sure this is not the case. So, either:

I am downgrading this issue from bug to question.

Lasermole commented 10 years ago

Sorry if that logcat was short. Just figured it would narrow down things to the moment poweramp tried and failed to verify the license. I don't have any restrictions set on poweramp when I launch it. Unless there is another app (system) that it's leveraging to obtain the information it needs to license itself. I just know I didn't have an issue until last 1.99.42. And after a reboot. The dev for poweramp said so long as the android id and Google account are detected as the same as the purchase it will verify correctly. Oddly it seemed every time I launched poweramp it detected my google account as my secondary work email account and not my primary. Again I didn't restrict account access either. I even removed my work account, rebooted and tried again. No good. Is there a way to be sure Xprivacy reports the actual device info and not random to poweramp specifically? On Feb 13, 2014 11:38 PM, "Marcel Bokhorst" notifications@github.com wrote:

The (short) logcat does not contain useful information. I have check all the code for accidentally restricting this, without settings it, but I am quite sure this is not the case. So, either:

  • there must be some restriction visible in the XPrivacy usage data causing this
  • Poweramp checks for XPrivacy and refuses to work if it finds XPrivacy
  • There is a bug in the Poweramp licensing I am downgrading this issue from bug to question.

Reply to this email directly or view it on GitHubhttps://github.com/M66B/XPrivacy/issues/1340#issuecomment-35055057 .

M66B commented 10 years ago

"Is there a way to be sure Xprivacy reports the actual device info and not random to poweramp specifically?" I have already checked XPrivacy for "rogue" restrictions and for bugs in the recent changes. My best guess is that this is a problem in Poweramp or some restriction, maybe of a system or Google component that is causing this issue.

Lasermole commented 10 years ago

Thank you so much for the response! Wish all devs were as awesome! On Feb 14, 2014 1:03 AM, "Marcel Bokhorst" notifications@github.com wrote:

" Is there a way to be sure Xprivacy reports the actual device info and not random to poweramp specifically?" I have already check XPrivacy for "rogue" restrictions and for bug in the recent changes. My best guess this is a problem in Poweramp or some restriction, maybe of a system or Google component that is causing this issue.

Reply to this email directly or view it on GitHubhttps://github.com/M66B/XPrivacy/issues/1340#issuecomment-35058816 .

paour commented 10 years ago

I also have the PowerAmp issue. Here's what I tried:

I've captured a log of events up to this point

What does this tell me: - the issue is primarily between the Play Store and Xprivacy and this merits attention from @M66B since it is likely just the tip of the iceberg and other less popular apps may be suffering from this

M66B commented 10 years ago

Can you post a link to the logcat?

paour commented 10 years ago

For some reason I thought GitHub would autolink it, sorry. Here it is: https://gist.github.com/anonymous/8997393

paour commented 10 years ago

You'll see a lot of scalpel error logging… It's a module that implements Jake Wharton's 3d layout view, pretty cool… I've just tested that with Scalpel disabled the same thing still happens.

M66B commented 10 years ago

Please post a new logcat with XPrivacy debugging enabled (main settings).

paour commented 10 years ago

Argh, this seems to have been another intermittent Play Store glitch (I replicated the problem twice this morning though). I can now download the unlocker from the Play Store even with XPrivacy enabled.

M66B commented 10 years ago

So, issue resolved?

paour commented 10 years ago

No, the unlocker still does not validate. But I had been under the impression that XPrivacy was causing issues in the Play Store (not just with PowerAmp), and that doesn't seem to be the case.

M66B commented 10 years ago

Then please provide another logcat with XPrivacy debug logging enabled.

M66B commented 10 years ago

This could be the reason:

02-14 09:01:43.195    8369-8369/com.maxmpz.audioplayer E/ActivityThread﹕ Activity com.maxmpz.audioplayer.dialogs.ExpiredActivity has leaked IntentReceiver pl.com.android.scalpel.inject.MainXposed$SettingsReceiver@429c4fc8 that was originally registered here. Are you missing a call to unregisterReceiver()?
    android.app.IntentReceiverLeaked: Activity com.maxmpz.audioplayer.dialogs.ExpiredActivity has leaked IntentReceiver pl.com.android.scalpel.inject.MainXposed$SettingsReceiver@429c4fc8 that was originally registered here. Are you missing a call to unregisterReceiver()?

But this is not caused by XPrivacy.

paour commented 10 years ago

https://gist.github.com/anonymous/8997893

This new log does not contain Scalpel (it's disabled) and no IntentReceiverLeaked either.

Unfortunately it seems pretty clear that the PowerAmp failure is indeed due to XPrivacy: it's been reported by multiple users, and one even pinpointed the issue to a change between .39 and .40.

I went back to .39 with latest poweramp all is fine. Update to .40 poweramp issue showed up. Updated to .43 disabled all system apps and poweramp same issue. Disabled XPrivacy from Xposed reboot all is fine with poweramp. On .43 poweramp works without the unlocker, once unlocker installed got the issue. Went back to a older poweramp same outcome, don't work with .40 an above.

M66B commented 10 years ago

Could you please try again with this version: https://github.com/M66B/XPrivacy/releases/tag/1.99.43-2 I like to see a new logcat, whether it works or not.

an0n981 commented 10 years ago

Here a logcat with 43-2

https://gist.github.com/an0n981/997d44741b5416720fc4

At the end I uninstalled and reinstalled the unlock key.

Edit: Github cut off about 10,000 lines here part 2: https://gist.github.com/an0n981/ffa467e3cf5def3bd395

M66B commented 10 years ago

I thought we were talking about totally unrestricted:

I/XPrivacy( 4113): Load package=com.maxmpz.audioplayer.unlock uid=10124
I/XPrivacy( 4113): get 10124/SERIAL identification=restricted

As the reply of the Poweramp author pointed out the IDs should always be the same. So, please try again without restricting the unlocker.

an0n981 commented 10 years ago

both poweramp and unlocker (same uid) were totally unrestricted (check to restrict set to off)

but I will remove all restrictions and capture again

M66B commented 10 years ago

Maybe the template got applied while installing the unlocker (again) ?

paour commented 10 years ago

Shouldn't be, the unlocker uses the same process id as the main app. What does Xprivacy do in these circumstances? On 14 Feb 2014 12:31, "Marcel Bokhorst" notifications@github.com wrote:

Maybe the template got applied while installing the unlocker (again) ?

Reply to this email directly or view it on GitHubhttps://github.com/M66B/XPrivacy/issues/1340#issuecomment-35076039 .

an0n981 commented 10 years ago

here another one with uid 10124 completely unrestricted

https://gist.github.com/an0n981/a1ea54985f32a972c0ec

M66B commented 10 years ago 
D/ActivityThread( 5418): Loading provider com.maxmpz.audioplayer: com.maxmpz.audioplayer.unlock.DataProvider
W/XPrivacy/XContentResolver( 5418): Before uri=content://com.maxmpz.audioplayer.data/queue
W/XPrivacy/XContentResolver( 5418): Before uri=content://com.maxmpz.audioplayer.data/queue
W/XPrivacy/XContentResolver( 5418): After uri=content://com.maxmpz.audioplayer.data/queue
W/XPrivacy/XContentResolver( 5418): After uri=content://com.maxmpz.audioplayer.data/queue

Winamp seem to use a content provider for unlocking. 1.99.40 has a new implementation of content provider restrictions. I have already checked the code about five times for flaws, but I don't see them. I have also compared the old and new code line by line and still I have no explanation for this issue. The content URI content://com.maxmpz.audioplayer.data/... should not be restricted in any way by XPrivacy. I like to see the same log again with XPrivacy debug log enabled, maybe that reveals the cause.

M66B commented 10 years ago

In an earlier provide log I found this message:

W/PackageManager﹕ Couldn't delete native library directory /data/app-lib/com.maxmpz.audioplayer.unlock

Maybe it is worth trying this:

an0n981 commented 10 years ago
  1. Winamp is Dead. AOL killed it a few months ago ;)
  2. will do
an0n981 commented 10 years ago

do you want a log of the entire process or just the install part after reboot?

M66B commented 10 years ago

Just the install part of the unlocker, but with XPrivacy debug logging enabled.

an0n981 commented 10 years ago

weird that the debug log automatically got turned off between the first and second logcat

an0n981 commented 10 years ago

https://gist.github.com/an0n981/57df38508a8ab47b9a5f

M66B commented 10 years ago

Two more versions to try (thanks for your patience!):

https://github.com/M66B/XPrivacy/releases/tag/1.99.43-3 Has extra logging and I like to see a logcat of the unlock process again.

https://github.com/M66B/XPrivacy/releases/tag/1.99.43-4 Has content provider restrictions disabled, to see if this is the problem or not.

an0n981 commented 10 years ago

43-3: https://gist.github.com/an0n981/974d8ca9e56f6da41af7

an0n981 commented 10 years ago

43-4: https://gist.github.com/an0n981/7cc9376cb1561752831c https://mega.co.nz/#!lpJllI6J!-t_0uZKws9URr99715RqT3EISGOp-lNKJc8oRDKae00

M66B commented 10 years ago

Does the -4 version work?

an0n981 commented 10 years ago

yes sir

M66B commented 10 years ago

Thanks, that will reduce the scope to search within. To be sure: -3 didn't work?

an0n981 commented 10 years ago

nope

M66B commented 10 years ago

If I want to try this myself, what do I need? Both these or just one of the two? Or maybe something else? https://play.google.com/store/apps/details?id=com.maxmpz.audioplayer https://play.google.com/store/apps/details?id=com.maxmpz.audioplayer.unlock

an0n981 commented 10 years ago

both

M66B commented 10 years ago

Hopefully I don't need to wait 15 days for the trial to expire ...

Lasermole commented 10 years ago

Thanks for all this! Glad you are getting somewhere, I had all but given up on poweramp hah. On Feb 14, 2014 10:07 AM, "Marcel Bokhorst" notifications@github.com wrote:

Hopefully I don't need to wait 15 days for the trial to expire ...

Reply to this email directly or view it on GitHubhttps://github.com/M66B/XPrivacy/issues/1340#issuecomment-35091212 .

M66B commented 10 years ago

I have bought the Poweramp unlocker and with a few tests I determined that as soon as I hook this function:

[http://developer.android.com/reference/android/content/ContentProviderClient.html#query(android.net.Uri, java.lang.String[], java.lang.String, java.lang.String[], java.lang.String)](http://developer.android.com/reference/android/content/ContentProviderClient.html#query%28android.net.Uri, java.lang.String[], java.lang.String, java.lang.String[], java.lang.String%29)

and even with doing nothing in the hook (an empty function), the unlocker doesn't work anymore.

This means that Poweramp has some method to detect that this function has been hooked.

Seen from the perfective of XPrivacy I cannot do much. This hook is needed for a lot of restrictions. It worked until version 1.99.39, because I hooked into another place. I don't want to change this back, because this method of hooking is better.

Lasermole commented 10 years ago

Agh,... Damn. Well from my research on poweramp's side many users are furious with the dev's way of license verification. Waste of money now I guess since the dev seems to care less about changing things. I guess I'll have to use another music app until things get more reasonable with the licensing.

Thank you so much again! On Feb 14, 2014 12:20 PM, "Marcel Bokhorst" notifications@github.com wrote:

I have bought the Poweramp unlocker and with a few tests I determined that as soon as I hook:

http://developer.android.com/reference/android/content/ContentProviderClient.html#query(android.net.Uri, java.lang.String[], java.lang.String, java.lang.String[], java.lang.String)

and even with doing nothing in the hook (an empty function), the unlocker doesn't work anymore.

This means that Poweramp has some method to detect that this function has been hooke.

Seen from the perfective of XPrivacy I cannot do anything. This hook is needed for a lot of restrictions. It worked until version 1.99.39, because I hooked into another place. I don't want to change this back, because this method of hooking is better.

Reply to this email directly or view it on GitHubhttps://github.com/M66B/XPrivacy/issues/1340#issuecomment-35104351 .

M66B commented 10 years ago

You are welcome. I did what I could, but I cannot fix this without giving up important features of XPrivacy.

Lasermole commented 10 years ago

Exactly. I wouldn't compromise Xprivacy for the sake of this one app. I'll just have to reinforce my disdain to the dev. On Feb 14, 2014 12:26 PM, "Marcel Bokhorst" notifications@github.com wrote:

You are welcome. I did what I could, but I cannot fix this without giving up important features of XPrivacy.

Reply to this email directly or view it on GitHubhttps://github.com/M66B/XPrivacy/issues/1340#issuecomment-35105006 .

VorpalBlade commented 10 years ago

Could it not be a bug in Xposed Framework causing this hooking to fail? Surely there is no way for an application for detect that it is being hooked? Or if there is, couldn't you hook that code to prevent it from discovering that?

M66B commented 10 years ago

The hook doesn't fail, else a whole lot of restrictions wouldn't work.

Maybe it is similar to the LBE Security Master incompatibility, the Poweramp unlocker seems to use a native library to do or to aid the license verification process. The reason is probably that a native library is more difficult to reverse engineer. Maybe the native library interferes with Xposed, like LBE seems to do (although for LBE the problem is worse, because it takes down the whole system). This is just another theory, maybe the Poweramp developer found a way to check for hooks or something.