[CLOSED][APP][XPOSED][6.0+] XPrivacyLua - Android privacy manager [UNSUPPORTED]

[EngineerMind]

Probably, yes.
First, you need to know which methods for hooking on Android's source.
Here are source codes for android.location.*

https://cs.android.com/android/platform/superproject/+/master:frameworks/base/location/java/android/location/

I understand that I will probably be able to fake that the location is on.

But how would I simulate/generate the android location broadcast intent before the android system is actually able to lock into the satellites?

 

[VD171]

I understand that I will probably be able to fake that the location is on.

But how would I simulate/generate the android location broadcast intent before the android system is actually able to lock into the satellites?

That is the point.
If kernel blocks requests, there is nothing to do.

 

[EngineerMind]

That is the point.
If kernel blocks requests, there is nothing to do.

I think we are not on the same page, so let me try to just confirm something first...

Do you agree with my theory that the device needs to first lock in via satellites (which can take a few minutes if wifi/bluetooth assistance is turned off) before it will provide location data to apps?

Meaning an app can request location data, but it has to wait for the device to first lock in it's position via sattellites (which can take a few minutes) before android will provide any location data to an app - do you agree with my theory?

 

[Everton007z]

Select the hook, click on "lua script" and then edit fake result.

Could you tell me where in the code I put the fake result? I'm trying several ways but I can't.

I have little knowledge about the Lua language.

 

[VD171]

Could you tell me where in the code I put the fake result? I'm trying several ways but I can't.

I have little knowledge about the Lua language.

MediaDrm.getPropertyByteArray returns byte[], as you can see here:

https://developer.android.com/reference/android/media/MediaDrm#getPropertyByteArray(java.lang.String)

So, you just need to create a new array containing the bytes you want to return in setResult, as you can see here:

XPrivacyLua/app/src/main/assets/mediadrm_unique_id.lua at master · M66B/XPrivacyLua

Really simple to use privacy manager for Android 6.0 Marshmallow and later - M66B/XPrivacyLua

github.com

Just set a new content inside the array, like this:
arrayClass:set(fake, index_element_here, content_element_here)
As you can see here:

https://developer.android.com/reference/java/lang/reflect/Array#set(java.lang.Object,%20int,%20java.lang.Object)

 

[Everton007z]

MediaDrm.getPropertyByteArray returns byte[], as you can see here:

https://developer.android.com/reference/android/media/MediaDrm#getPropertyByteArray(java.lang.String)

So, you just need to create a new array containing the bytes you want to return in setResult, as you can see here:

XPrivacyLua/app/src/main/assets/mediadrm_unique_id.lua at master · M66B/XPrivacyLua

Really simple to use privacy manager for Android 6.0 Marshmallow and later - M66B/XPrivacyLua

github.com

Just set a new content inside the array, like this:
arrayClass:set(fake, index_element_here, 'content here')

Thank you very much brother, I did it. Thanks

 

[VD171]

I think we are not on the same page, so let me try to just confirm something first...

Do you agree with my theory that the device needs to first lock in via satellites (which can take a few minutes if wifi/bluetooth assistance is turned off) before it will provide location data to apps?

Meaning an app can request location data, but it has to wait for the device to first lock in it's position via sattellites (which can take a few minutes) before android will provide any location data to an app - do you agree with my theory?

Yes, but your last position keeps "cached".
So, app knows your last postion before to know your current position.
But, if Location is disabled, probably the system blocks it at kernel level, so there is nothing to do.
Certainly, it would be easier to keep Location enabled and let an app think the Location is turned off (or the device is located at another fake position).

 

[EngineerMind]

Yes, but your last position keeps "cached".
So, app knows your last postion before to know your current position.
But, if Location is disabled, probably the system blocks it at kernel level, so there is nothing to do.
Certainly, it would be easier to keep Location enabled and let an app think the Location is turned off (or the device is located at another fake position).

Ok, now I know where you are coming from.

Yes, I agree with the caching. However, even when I enable Location on my device, it will still take 2-3 minutes before the app will "see" *any* GPS coordinates (even the fake one) because it seems the device first needs to lock into the satellites. So this is giving me the impression that the way apps get gps coordinates is via a system broadcast intent from android (after it locks into the satellites), and then XPLUA can intercept that broadcast and substitute the real coordinates with the fake ones so the app will only get the fake ones.

And yes, this delay wouldn't happen if I kept location on all the time because it would always be "locked in" after the initial lock. But for privacy/security reasons, I only turn on the location for this app, then turn it back off then I am done using it. So, I just looking for a solution so I don't have to wait the 2-3 minutes before the app fully works correctly.

So, my main goal is to get the app to see the "fake" coordinates immediately and not wait the 2-3 minutes for the device to lock into the satellites.

But, if my theory is correct (that apps receive gps coordinates via a broadcast intent only *after* the device locks in), then that means I must somehow generate my own broadcast intent, so that the app doesn't have to wait the 2-3 minutes for android to generate it.

But it doesn't seem that XPLUA can do a broadcast intent.

 

[bush911]

it seems that the latest 1.32(1.33) does not work on Android 13

 

[M66B]

it seems that the latest 1.32(1.33) does not work on Android 13

Besides that any details are missing about why not, this depends mostly on XPosed.
I say it works, until proven otherwise.

 

[bush911]

Besides that any details are missing about why not, this depends mostly on XPosed.
I say it works, until proven otherwise.

I am going to try to update lsposed to see if there is any change

 

[bush911]

Besides that any details are missing about why not, this depends mostly on XPosed.
I say it works, until proven otherwise.

I am using Pixel 6 Android 13, xprivacylua 1.32 with zgisk lsposed 1.83 6597.
Could you please let me know which lsposed build you are using.
And how can I help you to identify the 'issue'?

 

[EngineerMind]

I am using Pixel 6 Android 13, xprivacylua 1.32 with zgisk lsposed 1.83 6597.
Could you please let me know which lsposed build you are using.
And how can I help you to identify the 'issue'?

@M66B was asking *you* what are the issues you are running into (besides you just saying that "it doesn't work on A13")

So, why do you think it is not working? Any error messages?

Please provide details.

 

[bush911]

@M66B was asking *you* what are the issues you are running into (besides you just saying that "it doesn't work on A13")

So, why do you think it is not working? Any error messages?

Please provide details.

Restrictions don't work as expected. Before upgrading to Android 13, there are many restrictions logs available on xprivacylua pro app.
Now no log appears.
Sorry for my English

 

[EngineerMind]

Restrictions don't work as expected. Before upgrading to Android 13, there are many restrictions logs available on xprivacylua pro app.
Now no log appears.
Sorry for my English

XprivacyLUA depends on Xposed (edXposed, Lsposed) working, so if your Xposed is not working, XprivacyLUA won't work.

So, you need to first make sure your lsposed is working correctly - you may need to update your lsposed so it will work with A13.

 

[bush911]

XprivacyLUA depends on Xposed (edXposed, Lsposed) working, so if your Xposed is not working, XprivacyLUA won't work.

So, you need to first make sure your lsposed is working correctly - you may need to update your lsposed so it will work with A13.

Thank you mate, Lsposed works well for other modules on Android 13.

 

[EngineerMind]

Thank you mate, Lsposed works well for other modules on Android 13.

Try disabling, rebooting, then enabling the Xprivacy in lsposed, then reboot again and see if it starts working.

 

[bush911]

Try disabling, rebooting, then enabling the Xprivacy in lsposed, then reboot again and see if it starts working.

Thank you for your patience and kindness. Tried and ended up with no luck.
For now I have to live with this

 

[VD171]

Ok, now I know where you are coming from.

Yes, I agree with the caching. However, even when I enable Location on my device, it will still take 2-3 minutes before the app will "see" *any* GPS coordinates (even the fake one) because it seems the device first needs to lock into the satellites. So this is giving me the impression that the way apps get gps coordinates is via a system broadcast intent from android (after it locks into the satellites), and then XPLUA can intercept that broadcast and substitute the real coordinates with the fake ones so the app will only get the fake ones.

And yes, this delay wouldn't happen if I kept location on all the time because it would always be "locked in" after the initial lock. But for privacy/security reasons, I only turn on the location for this app, then turn it back off then I am done using it. So, I just looking for a solution so I don't have to wait the 2-3 minutes before the app fully works correctly.

So, my main goal is to get the app to see the "fake" coordinates immediately and not wait the 2-3 minutes for the device to lock into the satellites.

But, if my theory is correct (that apps receive gps coordinates via a broadcast intent only *after* the device locks in), then that means I must somehow generate my own broadcast intent, so that the app doesn't have to wait the 2-3 minutes for android to generate it.

But it doesn't seem that XPLUA can do a broadcast intent.

Just block location totally for all other apps using XPrivacyLua.
Did you already try FakeGPS ?
You can spoof simulated location detection using XPrivacyLua too.

 

[EngineerMind]

Just block location totally for all other apps using XPrivacyLua.
Did you already try FakeGPS ?
You can spoof simulated location detection using XPrivacyLua too.

I am very hesitant in trying to block all "other apps", because I once had a bad experience trying to block some system apps (using the original Xprivacya while back) and it boot-looped by device. I know that XPLUA is safer, but I still don't feel comfortable in keeping location on 24/7.

I think the solution (to eliminate the delay) might be to get my device to lock into a position quicker than 2-3 minutes. I'm looking into aGPS which seems like it will help speed-up GPS lock on devices.

Thanks for your help.