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

Search This thread

Everton007z

New member
Aug 16, 2022
4
1
Good morning guys. Does anyone know how I can add a custom uniqueDeviceId in:

MediaDrm.getPropertyByteArray

By default it is a string AAAAAAAA...

20220816_133047.jpg


Please, thank you in advance if you can help me.
 

EngineerMind

Senior Member
May 5, 2007
719
187
Probably, yes.
First, you need to know which methods for hooking on Android's source.
Here are source codes for 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?
 

EngineerMind

Senior Member
May 5, 2007
719
187
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?
 

VD171

Senior Member
Jun 21, 2012
2,818
2
2,078
127.0.0.1
LG K10
Samsung Galaxy J7
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:
So, you just need to create a new array containing the bytes you want to return in setResult, as you can see here:
Just set a new content inside the array, like this:
arrayClass:set(fake, index_element_here, content_element_here)
As you can see here:
 
Last edited:

Everton007z

New member
Aug 16, 2022
4
1
MediaDrm.getPropertyByteArray returns byte[], as you can see here:
So, you just need to create a new array containing the bytes you want to return in setResult, as you can see here:
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 🙏😀😀
 
  • Love
Reactions: VD171

VD171

Senior Member
Jun 21, 2012
2,818
2
2,078
127.0.0.1
LG K10
Samsung Galaxy J7
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).
 
Last edited:

EngineerMind

Senior Member
May 5, 2007
719
187
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.
 
Last edited:

EngineerMind

Senior Member
May 5, 2007
719
187
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.
 
  • Like
Reactions: bush911

bush911

Senior Member
Oct 12, 2012
804
341
重庆
Google Nexus 5
Google Pixel
@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

Senior Member
May 5, 2007
719
187
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.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 16
    Version 1.33 is available via GitHub now:

    https://github.com/M66B/XPrivacyLua/releases

    Edit: and also via the Xposed repo.
    13
    Version 1.34 is available on GitHub now:

    https://github.com/M66B/XPrivacyLua/releases

    Thanks @VD171 for contributing a number of Android 13 hook definitions.

    The Xposed repo is currently unreachable for me. Maybe it is completely offline now?
    11
    The Xposed repo is currently unreachable for me. Maybe it is completely offline now?
    Xposed repo is unavaiable for me too for a long.
    Since it is hosted by XDA may @Oswald Boelcke tell us why
    Gentlemen, I think I owe you a response. I approach our Forum Administrator @MikeChannon with this question and the information I've received is that it is no longer available and is no longer being developed. I'm convinced you're also aware that SRD @rovo89 who owned the repo hasn't been posted for more than 4 1/2 years. I suggest not to rely at all that any file, which was made available for download in that repo in the past, might be available in the future there.

    Personally but XPL is my one and only Xposed module, I download updates from Marcel's Github. Marcel, thanks very much for your continous support and presence.
    10
    Can you please create a pull request for this?

    Note that the existing definitions should be marked with "maxSdk": 32 and the new hook definitions with "minSdk": 33.
    Yes, for sure.
    I've created a tool for reading Android source code files and then parsing all methods in JSON as seen in XPrivacyLua.
    I will find all updates from existing definitions and create a pull request.
    10
    Thanks, that's great, also to prevent mistakes, and I am sure other people will be happy with this too!
    Done.
    I've fully updated hooks.json and created a pull:
  • 312
    XPrivacyLua

    banner_play_store.png


    Really simple to use privacy manager for Android 6.0 Marshmallow and later (successor of XPrivacy).

    Revoking Android permissions from apps often let apps crash or malfunction. XPrivacyLua solves this by feeding apps fake data instead of real data.

    Features:

    • Simple to use
    • Manage any user or system app
    • Extensible
    • Multi-user support
    • Free and open source

    See here for all details, including installation instructions and download link.

    Please read the frequently asked questions before asking a question.

    This XDA thread is about using the latest version of XPrivacyLua. Off topic comments are allowed as long they are related to XPrivacyLua and are in the general interest of the followers of this thread, but anything not related to privacy is not allowed.

    If XPrivacyLua doesn't work and/or when "module not running or updated" is shown, this is almost always caused by an Xposed problem.

    Discussions about purchases are not allowed here, please contact me via here instead.

    XPrivacyLua is being maintained and community supported, but new features won't be added anymore.

    Custom hook definitions will always be part of XPrivacyLua, but there will be community support only. This means that I won't respond to questions about defining custom hooks anymore. See this thread for the reasons.

    If you value your privacy, please consider to support this project with a donation or by purchasing pro features.


    XPrivacyLua is not a permission manager, but a privacy manager. XPrivacyLua doesn't block things and doesn't revoke permissions, but does replace real data by fake data. This means you can grant Android permissions to an app and still let XPrivacyLua prevent the app from seeing privacy sensitive data. Revoking permissions can result in an app refusing to work and/or to crash. However, replacing real by fake data generally doesn't let an app crash.

    Currently restrictions are quite crude because they mostly replace real data by no data. For example restricting the contacts app from getting contacts will result in an empty contact list. In the near future it might be made possible to select the data an app may see, for example just one group of contacts.

    About feature requests and bug reports:

    The goal is to have a tool that can properly protect the privacy of many in the near future. However, it isn't paid work, so I do whatever I like whenever I like it.

    You can request features in this XDA forum. I will read them, but I will not respond to them and they might or might not be implemented. If I know for sure something will not be implemented, I will let you know.

    You can report any problem you have here. There will be no issue tracker on GitHub.

    For now I have decided to not implement restrictions that are useful to prevent tracking only. There are simply too many data items that can be used for tracking and it would take too much time to develop restrictions for all these data items.

    The basic idea is to restrict only things that 'define' you, so which contacts you have, where you are, which apps you use, etc.

    Maybe we can widen the definition of things that the core of XPL covers to "What defines you, and what can be used to spie on you"? This would include camera/audio, but not tracking.

    XPrivacyLua is pretty feature complete and will be maintained and supported and when there is a need new hook definitions will be added to better protect your privacy. For the rest this FAQ applies:

    https://github.com/M66B/XPrivacyLua/blob/master/FAQ.md#FAQ4

    As said before, development will also depend on Xposed development, which is just minimal unfortunately.

    XDA thanks and donations are appreciated.

    XPrivacyLua is supported with Xposed only. There is no support for VirtualXposed and TaiChi.
    68
    I have just released beta version 0.5 in the Xposed repository.

    The XPrivacyLua framework and user interface seems to be stable enough to call this a beta release.

    Besides several bug fixes and improvements two new restrictions were added:
    • Read account name, which mostly holds your e-mail address and will be replace by '[email protected]' when restricted
    • Read clipboard, which will be replaced by the text 'Private' when restricted

    Furthermore the ability to restrict Android system (be careful!) and to restrict system apps was added. It is possible to restrict all of these individually (XPrivacy could not do that).

    Be sure to take a look at the help page in the app again (use the ?-icon), since there were some useful hints added.

    If you appreciate what I am building here, please let me know by means of an XDA thanks and/or a donation, so that I don't get the feeling 'What am I doing this for?'.
    59
    I have just released alpha version 0.12 in the Xposed repository.

    This version has been redesigned for Android Oreo compatibility. The user interface and the restrictions work properly for me, but be aware that a lot has been changed on the inside ("it is bigger on the inside", lol), also for earlier Android versions. There is one thing I know of that needs improving and that is that the user interface might be updated too often with a lot of restrictions, which might cause delays and hangs. I will look into this tomorrow.

    This change was necessary, but it was a lot of work, so XDA thanks and donations are appreciated.
    56
    I have just released beta version 0.25 in the Xposed repository.

    Changelog:

    With this release XPrivacyLua restriction's can be compared with XPrivacy's. There are now over 100 restriction definitions!

    XDA thanks and donations are appreciated.
    53
    @CHEF-KOCH You have been given enough time to respond here. Now I just think it is pretty cowardly to write critical about XPrivacyLua, but not to tell what can actually be improved, especially because you were invited to do so.

    I still like to hear how XPrivacyLua can be improved, but I don't want to hear what is wrong with XPrivacyLua. You'll need to keep the scope of XPrivacyLua in mind (in short: privacy, not security), see the opening post and previous discussions about this for more information.

    Also, if you really know better, I like to see an original work from your hands to prove that. Actions speak louder than words.

    As it is now, you are discouraging one of the few people in the world who really did something substantial to improve privacy on Android. And don't go talking about VPNs, TOR, etc because your private information, like your contacts, will still leak.

    I also think you are pretty ungrateful for what I did so far.

    To others: if you see someone reference one of his blogs, please reference this comment in response.

    Edit: if you agree with this, please add an XDA thanks to this comment, so it will show up in the right column as a reference for others.