Hi!
I have created a kernel module (and insmod it at the start of the device) to control /dev/xx and only the system can access /dev/xx.
Thank to the code I have added, /dev/xx can be controlled from the Framework .
I now want to create a system service to handle this.
Which permission should be used for permissionGroup so that the service can access /dev/xx?
I have read the documentation (I am not able to post the link since I have less than 10 posts) but it doesn't help me to guess the right permission group for the system service
PS: I am working on Marshmallow
Related
Wechat Share Editor is a module for Wechat that allows you to change the sharing content or even create a custom share in Wechat. This includes share link, share logo link, share title and others...
Features
Change the Sharing Content of Wechat.
Requirements
Your phone must be rooted
Xposed framework must be installed first repo.xposed.info/module/de.robv.android.xposed.installer
Wechat Required
Instructions
Install the module
Run Xposed Installer and enable the module Wechat Share Editor
Reboot the phone
Open the module in Launcher or Xposed, and set up the content you want to share.
Open Wechat to share someone else’s Moment, and check the result
Permissions
network
Limitations & supported devices
I developed this module based on Wechat 5.3 source code and tested only on my RedMi device with Wechat Version 4.51 and 5.3. I expect it to work also on Wechat 4.0-latest.
Credits
I used XLED’s SettingsHelper class, hope you don’t mind.
Supports & troubleshooting
If you want me to add support for other Wechat version, please send me the following:
Xposed log file
Your device model
Android, ROM, Wechat version
Source code
You can find source code for this module from github.com/diwulechao/WechatShareEditor
hi, can you be specify more or provide a short video clip for some intro about it? im still having some confusing about this...
Sent from my GT-I9300 using Tapatalk
i love this apps.. can you update it for latest wechat apps?? tq
Sent from my GT-I9100G
This mod allows to use /system/etc/hosts file on configurations/ROMs (mostly symlinked hosts file on Android 4.4+) where it is ignored.
Hosts file usually gets ignored on some ROMs due to SELinux restrictions if it is a symlink to file on different partition.
Technically it works by attaching to all packages/apps and hooking DNS resolution API. On first name resolution API call hosts file is read and stored in memory (in HPPC OpenHashMap structure).
Additional features of hosts file:
use of IP address 127.0.0.0 allows to fail name resolution of associated hosts
use of DNS names instead of IP addresses (these DNS names are passed directly to DNS resolver - they are not looked up in hosts file recursively)
Known limitations:
JNI libraries are not affected (some applications may still ignore hosts file)
hosts file is read in memory of each application when it makes first DNS query (time and memory used depends on size of hosts file; time is logged in logcat with tag "hostsEnabler")
hosts Enabler uses HPPC: High Performance Primitive Collections for Java library which is distributed under Apache License 2.0.
This mod requires Xposed framework to be set up and hosts Enabler enabled as Xposed module.
Disclaimer: I am not responsible for anything that may happen as a result of using this mod.
Xposed Module Repository page:
http://repo.xposed.info/module/lv.id.dm.hostsenabler
For changelog see next post, for download links see downloads section.
XDA:DevDB Information
hosts Enabler, Xposed for all devices (see above for details)
Contributors
DavisNT
Xposed Package Name: lv.id.dm.hostsenabler
Version Information
Status: Stable
Current Stable Version: 1.0
Stable Release Date: 2014-08-30
Created 2014-08-30
Last Updated 2014-08-31
Changelog:
v 1.0
* Initial release.
@DavisNT: Seems you missed UnbelovedHosts ...
defim said:
@DavisNT: Seems you missed UnbelovedHosts ...
Click to expand...
Click to collapse
Actually I was aware of that module, but I wanted to restore full functionality of hosts file (name resolution, use with third party updater tools etc.) with main focus on name resolution.
DavisNT said:
Actually I was aware of that module, but I wanted to restore full functionality of hosts file (name resolution, use with third party updater tools etc.) with main focus on name resolution.
Click to expand...
Click to collapse
Both seem technically more or less the same: Reading an file with blocked hosts and answer name resolution requests with its contents. Btw with some devices (like Nexus 7) there is the issue that the /etc/hosts file is sometime reverted at reboot, what was the cause for me to use Xposed
defim said:
Both seem technically more or less the same: Reading an file with blocked hosts and answer name resolution requests with its contents. Btw with some devices (like Nexus 7) there is the issue that the /etc/hosts file is sometime reverted at reboot, what was the cause for me to use Xposed
Click to expand...
Click to collapse
I won't say they are the same:
UnbelovedHosts: full featured ad blocking solution
hosts Enabler: enables use of /system/etc/hosts file (for manually added name resolution entries (home PC etc.) or, if you wish, with any 3rd party updater software)
I will test it thanks :good:
So could I use this MOD to fix my google play store from have a no connection error caused by a change in the /ect host file?
Sent from my T0LTE using XDA Free mobile app
bossgamethegreat said:
So could I use this MOD to fix my google play store from have a no connection error caused by a change in the /ect host file?
Click to expand...
Click to collapse
I suppose best solution is to undo the change in /system/etc/hosts file.
DavisNT said:
I suppose best solution is to undo the change in /system/etc/hosts file.
Click to expand...
Click to collapse
Yes, I understand and did that. What I'm trying to ask is if this would help make the change constant. It's getting really bothersome to half to keep making the change every time the Play Store feels like it doesn't want to work.
Sent from my T0LTE using XDA Free mobile app
bossgamethegreat said:
Yes, I understand and did that. What I'm trying to ask is if this would help make the change constant. It's getting really bothersome to half to keep making the change every time the Play Store feels like it doesn't want to work.
Click to expand...
Click to collapse
/system/etc/hosts by default should contain only localhost entry. If Google Play needs additional entries then, most likely, there is a problem with DNS servers of your network/provider. If there "appear" some entries which block Google Play then, most likely, you have installed an ad blocker (e.g. AdAway) and you are using some custom blocking lists (which include entry(-ies) that accidentally block Google Play).
BTW This is completely off-topic here. If you wish we can continue discussion in a new thread in form of your device (create the thread and send me PM with link to it).
Would this allow for ad blockers to work even if you enable Chrome bandwidth saver that hijacks all dns requests?
jawz101 said:
Would this allow for ad blockers to work even if you enable Chrome bandwidth saver that hijacks all dns requests?
Click to expand...
Click to collapse
No, this module shouldn't be able to allow ad blockers to work with Chrome bandwidth saver.
...
Sent from my SM-G550T1 using XDA-Developers mobile app
Hi!
This module may be mainly interesting for developers. This module alone does nothing if not properly used together or within another app. Only use it if you know what you are doing.
Overview:
I created a Xposed module which overrides the Access Rule Checks within the SIMalliance Open Mobile API. These checks normally determine which app is allowed to access a SIM-card based Secure Element (SE) and which is not. Normally within the Secure Element (SIM card) there exists a special "Access Rule File" (also called "ARF") or a special card applet called "Access Rule Application Master" (also called "ARA-M") which has the AID A00000015141434C00) and (basically) contains application signatures and according access rules. So the maintainer of the Secure Element can define (and also update) the access rules with these mechanisms: which app is allowed to access the SE and which not. (see reference [1] for details below).
So while the access rules are securely stored in the hardware module (SE) the enforcement of these rules is done in software (within the Open Mobile "SmartcardService.apk"). And this is where this Xposed module hooks into. By using this module (or by integrating it into your app) you may access the SIM-card-based Secure Element with your app, even if the access rules within the SE would not allow it.
Here's the code:
https://github.com/johnzweng/XposedOMAPIOverrideSEAccessRules
This module does not globally disable the access rule checks but instead only grants full access to a single package name (app) which you manually have to define in code as TARGET_APPLICATION_PACKAGE_NAME.
More details and background story:
A few months ago the banks here in Austria started to roll out NFC-based tap'n'pay solutions which allow you to pay with your Android smartphone worldwide at every NFC-capable payment terminal. In contrast to Android Pay this is not a cloud-based software solution (using Host Card Emulation) but instead really uses a hardware-based secure element (like the chips used within EMV (chip'n'pin) plastic NFC banking cards). Austrian Banks decided to use Secure Elements located within the SIM-card (which is basically the same technology as your banking-card chip) so they don't need cooperations with all the phone manufacturers (and also not with Google), but only with the three mobile network operators (MNOs) here in Austria (which control all the SIM cards).
Unfortunately Google has not included an API in current Android which allows accessing SIM-card-based Secure Elements from an app (I guess they don't want banks and MNOs to develop their own independent payment solutions but instead want to push Android Pay). For this reason one of the largest smartcard manufacturers (Giesecke & Devrient - G&D) started to work on a third-party system API which is nowadays known as SIMalliance OpenMobile API (OMAPI). The SIMalliance is a group of industry players which want to push the use of Secure Elements in mobile phones. See also: Members of SIMalliance.
As this API is not part of official Android API the phone manufacturers (OEMs) have to include this API additionally on the phones. A lot of manufacturers do this already. You can check on your phone if this 3rd-party API exists by looking for these files:
/system/etc/permissions/org.simalliance.openmobileapi.xml
/system/framework/org.simalliance.openmobileapi.jar
/system/priv-app/SmartcardService/ (which hosts "SmartcardService.apk")
(and optionally in newer versions: /system/priv-app/UiccTerminal/)
As Google currently doesn't support this type of access to the SIM-card Secure Element you will not find this API on the Nexus phones. One exception was the Nexus 6 running Lollipop where Google included the SIMalliance Open Mobile API because they supported the Softcard (formerly Isis Mobile) wallet. After Google has acquired Softcard in 2015 they removed again the OpenMobile API from Nexus 6 in Android 6.
As I personally used a LG Nexus 5 and now use the Motorola Nexus 6 I started to work on integrating the Open Mobile API myself (which should be possible now on every phone since Android Lollipop (API level 21) as the TelephonyManager system class has got a few interesting new methods including one for sending APDUs over a logical channel to the SIM card: iccOpenLogicalChannel(String AID). As every phone running Android 5 or newer must implement this API you now can get the OMAPI working on every phone running Android 5 or newer (with minor restrictions). (Also the phone needs to have a special hardware wiring between the SIM card and the NFC chip - see "Single Wire Protocol" for details - to get a NFC payment working). But this is a different story which doesn't belong in this thread. For the interested, look at my Github repo which contains a fork of OMAPI working on unmodified Android versions (and two pre-built releases for OMAPI 2.05 and OMAPI 3.0 under the "releases" section - including a short How-To). This worked for me on a Nexus 5 and a Nexus 6.
But back to this topic:
After I had worked out the integration of OMAPI into Android 6.0.1 I finally was able to use tap'n'pay with my Nexus 6 using the banking card within my SIM card Secure Element. But as I am curious I was also interested in exploring my banking-card within the SIM Secure Element using a self-written app. This was when I realized that there is some kind of access control within the Secure Element which blocks my own test-app but not the app of my bank. (See reference [1] for details on these access rules.) To circumvent this I wrote this Xposed module and voilá, now we also have the possibility to talk with the Secure Element over OMAPI.
Final notes:
This Xposed module will only work if your device has the SIMalliance Open Mobile API (OMAPI) installed
This Xposed module may not work if the OMAPI on your device has been compiled using code obfuscation or was modified otherwise by your phone OEM (as the OMAPI is not part of official Android, every OEM may include its own version)
This Xposed module also may not work on other versions of OMAPI (it was tested with OMAPI v2.05 and should also work with OMAPI V3.0)
I hope this might be useful for someone. Have a nice day.
References:
[1] GlobalPlatform Device Technology - Secure Element Access Control (PDF)
[2] Open Mobile API specification - V2.05 (PDF)
[3] Open Mobile API specification - V3.0 (PDF)
[4] my Github repository for this Xposed module: XposedOMAPIOverrideSEAccessRules
[5] my Github repository with OMAPI fork for working on unmodified Android 5 or newer
I'm very impressed! Love your 'investigations'
I installed OMAPI 2.05 with adb on my xperia sp with cyanogenmod 13 (android 6.0.1).
After that I installed the elba-pay app, but it's not working. May you help me?
polo_joe said:
I installed OMAPI 2.05 with adb on my xperia sp with cyanogenmod 13 (android 6.0.1).
After that I installed the elba-pay app, but it's not working. May you help me?
Click to expand...
Click to collapse
Hi polo_joe:
This doesn't directly match the topic of this thread. But send me a PM then we can continue to communicate on a different channel (email, etc.). Most interesting would be a output of "logcat":
On your computer enter the command: "adb logcat -v time > logcat_debug.txt" in a terminal window then try to start the ELBA Pay app and afterwards look in the "logcat_debug.txt" logfile for errors.
john
androcheck said:
Hi polo_joe:
This doesn't directly match the topic of this thread. But send me a PM then we can continue to communicate on a different channel (email, etc.). Most interesting would be a output of "logcat":
On your computer enter the command: "adb logcat -v time > logcat_debug.txt" in a terminal window then try to start the ELBA Pay app and afterwards look in the "logcat_debug.txt" logfile for errors.
john
Click to expand...
Click to collapse
thanks, will do!
Hi,
I am trying to use android SingnatureOrSystem , for some permission I didn't get access to it.
I have created one system application where I have defined Android shared user id in manifest : android:sharedUserId="android.uid.system"
Requested permission at runtime.
I have put that apk in system/priv-app.
Also I have signed it with device key .
As per my consideration if application is in system/priv-app , then it will grant for all permission , but didn't seems like that.
Please guide me where I am doing wrong.:
i have app called "SuperSMS" FROM 2016
and when i upload the new version and fill the declartion form
i get this message
Hi Developers at Dustfall,
Thanks for contacting the Google Play team.
I’ve reviewed your appeal request and found that your app, SuperSMS - Text Messages (com.Dustfall.SuperSms), does not qualify for use of DEFAULT_SMS.
We are unable to verify permissions prompt in your app. If these permissions (e.g. READ_SMS, RECEIVE_MMS, RECEIVE_SMS, and SEND_SMS) are not required, please remove them from your app.
Your app does not appear to prompt the user to be a default handler prior to requesting related permissions as required by the policy. Please make necessary changes in order to comply with policy requirements and resubmit your app through a Declaration Form.
Permission requests should make sense to users. You may only request permissions that are necessary to implement critical current features or services in your application. You may not use permissions that give access to user or device data for undisclosed, unimplemented, or disallowed features or purposes. For additional guidance, please review the Permissions policy and this Play Console Help Center article.
Please let me know if you have any other questions.
Best Regards,
Anya
The Google Play Team
NOW WHAT THE HELL THEY WANT ?
AND THERE IS NOBODY TO TALK WITH HIM