Have you ever dreamed of an app to execute your favorite shell commands, whether it is for collection dmesg/logcat/dumpsys or set kernel parameters.
Well here comes CommandCenter, a generic app for grouping all your favorite commands.
CommandCenter is free with ads and can be downloaded from the Google Play (please be patient, it takes a while to update as I just published)
It is also open source and your can check my repo to inspect / review the code.
If you are a kernel developer you may want to provide a tool for your users to run certain commands without havint to maintain an app for that; if yes just submit a Command Set and have your users download it.
If you are a poweruser there are commands that you use all the time, wither from adb shell or in the terminal. Make one or multiple Command Set and enjoy the comfort of an Android app and the power of your favorite commands.
From version 0.10 a Locale / Tasker Plugin was added to execute command from actions.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
How it works
The command sets are stored of the sdcard in the app's private folder /sdcard/Android/data/com.asksven.commandcenter/files in the form of json files. On load the files are parsed and each file (Command Set) shown as a tab.
A single click on a Command displays its details, a long click pops up a dialog from where you can run the command (this is configurable in the preferences).
A command has two parts:
- the command to be executed itself: it may contain a variable and in that case a popup will ask for the value to be used
- an optional command to retrieve a status: if a status can be read it will be displayed
CommandCenter comes with two pre-configured Command Sets:
- general commands for logging / diagnosis
- a few command for Fracisco Franco's awsome GN kernel
Want to contribute?
If you want to create and distribute command set just drop me a PM. I would be happy to give you more details about the syntax of the command sets and there is a section in this thread to list authored Command Sets. I may also add some to the Market app.
Caution
Always check the command's before running them. CommandCenter support 'su' command and you should know what you do as those could harm your phone. I will not take any responsibility for any dammage caused by command run using CommandCenter
Contact
You can contact me here (PM, this thread) or on twitter
Release Notes
v0.11.0 2012-07-24
Major fix: added synchronization to avoid freeze conditions
#24: "refresh" reads changes on command collections from the external storage
#26, #27, #28: different error conditions from reports
v0.10.1 2012-05-06
#15: samples scripts were being re-created on every start instead of once at first install
#14: FC when turning to portrait
#16: FC when number of result lines for a command < 5
#17: Various FC conditions from google play logs
#21: error in one script should not cause the other not to load
v0.9.0 2012-03-10
Solved stability issues (threaded processing)
Tablet support
#8: new command dialog layout
v0.8.0 2012-02-24
#4 Popup menu was called "edit"
#5 added support for user defined and editable commands
#6 added support for commands returning data
v0.7.2 2012-02-12
#2: dumpsys missing su, and logcat files have zero-length
#3: A few issues with backward compat to Android 2.1/2.2 fixed
v0.7.1 2012-02-11
#1: fixed Android 2.1 compatibility issue
v0.7 2012-02-11 Initial release
Command Sets
If you want to create command set for CommandCenter please read this
FAQ
For future use
sounds quite nice, can't wait to try. Have been using Tasker + Secure Settings for that so far, let's see how it compares.
V0.7.1
Fixed a minor issue with Android 2.1 (getExternalFilesDir does not exist on Eclair)
When I try and dump logcat radio or logcat it creates the file but it's blank. Also when I dump alarms the file reads Permission Denial: can't dump AlarmManager from pid=5637, uid=10128. ComandCenter never ask for SU Permissions. I ran the dump alarms with su permission from the terminal and it worked fine. HTC Inspire running ICS.
harpo1 said:
When I try and dump logcat radio or logcat it creates the file but it's blank. Also when I dump alarms the file reads Permission Denial: can't dump AlarmManager from pid=5637, uid=10128. ComandCenter never ask for SU Permissions. I ran the dump alarms with su permission from the terminal and it worked fine. HTC Inspire running ICS.
Click to expand...
Click to collapse
Ok the alarm dump is fixed, it was a definition error in the command set (dumpsys did not require su).
Testing the other commands now on rooted and unrooted device
V0.7.2
Fix-Release is rolling out, see post #2 for release notes.
I did quite a lot of testing on 2.1, 2.2, 2.3 and 4 devices with and without root and I hope the fixes work for everyone.
chamonix said:
Fix-Release is rolling out, see post #2 for release notes.
I did quite a lot of testing on 2.1, 2.2, 2.3 and 4 devices with and without root and I hope the fixes work for everyone.
Click to expand...
Click to collapse
Thanks for fixing this so fast. Everything is working perfectly now. Great app.
Another great release from chamonix
I have been looking for an app like this..so thank you very much. Now I'll start study it to take full advantage from it
Sent from my sandwiched SGS
It's time to collect some feature requests and build some use cases. Do you guys have suggestions for feature or know a kernel dev who has no time to write a sexy "settings" app. I'd be happy to provide the command sets while finalizing the schema aiming at making it public for contributors
Should it be possible to add or modify the command sets? I don't seem to be able to do either. In Edit mode, my soft keyboard never open and I don't see any option to create a new command set. Maybe I'm just not looking in the right place?
This is on a Samsung Galaxy Nexus running a rooted AOSP ICS.
short/y said:
Should it be possible to add or modify the command sets? I don't seem to be able to do either. In Edit mode, my soft keyboard never open and I don't see any option to create a new command set. Maybe I'm just not looking in the right place?
This is on a Samsung Galaxy Nexus running a rooted AOSP ICS.
Click to expand...
Click to collapse
In fact the is no way of editing the commands from within the app. I have been thinking about that a lot and the functionality itselt is not the problem (it occurs to me that the popup menu is named "edit" and this is of course not correct).
The reason I did not provide edition of commands within the app is that I want to offer a distribution channel for authors to update their command sets. Those updates would overwrite the local changes.
What you can do to edit the commands is edit the json files located on the sdcard in Android/data/com.asksven.commandcenter/files (one file per command set).
Do you feel the need to have "local" commands as well that could be edited from the app and stored in a local database?
chamonix said:
In fact the is no way of editing the commands from within the app. I have been thinking about that a lot and the functionality itselt is not the problem (it occurs to me that the popup menu is named "edit" and this is of course not correct).
The reason I did not provide edition of commands within the app is that I want to offer a distribution channel for authors to update their command sets. Those updates would overwrite the local changes.
What you can do to edit the commands is edit the json files located on the sdcard in Android/data/com.asksven.commandcenter/files (one file per command set).
Do you feel the need to have "local" commands as well that could be edited from the app and stored in a local database?
Click to expand...
Click to collapse
Local commands would be handy also you can do generics for brand htc Samsung etc as the kernels tend to have commands in the same spot, also a log viewer would be cool but they are. Readily avaliable
Sent from my HTC Evo 3D using Tapatalk
Auto upload to paste bin would be sick and the ability to email to dev as well as adding the kernel version to the file name
Sent from my HTC Evo 3D using Tapatalk
chamonix said:
In fact the is no way of editing the commands from within the app. I have been thinking about that a lot and the functionality itselt is not the problem (it occurs to me that the popup menu is named "edit" and this is of course not correct).
The reason I did not provide edition of commands within the app is that I want to offer a distribution channel for authors to update their command sets. Those updates would overwrite the local changes.
What you can do to edit the commands is edit the json files located on the sdcard in Android/data/com.asksven.commandcenter/files (one file per command set).
Do you feel the need to have "local" commands as well that could be edited from the app and stored in a local database?
Click to expand...
Click to collapse
Yes, I'd like to have that. I can think of a few I'd like to have NOW as opposed to waiting for someone to come up with them
Code:
df -h /sdcard
df -h
ls -lrt /mnt/sdcard | tail
ls -lrt /sdcard/Download | tail
ping www.google.com
ifconfig lte_rmnet1
netstat -rn
netstat -l
netstat | grep CLOSE
uptime
And probably few others that I could come up with once I really thought about it. Why not have "protected" command sets which are updated thru the app or Market and "user" or, as you call them, "local"?
First of all, thanks for develop another great application.
I concur that having the possibility to add commands is really a 'must have'. Of course, if we are thinking about to create commands, this means all of us have already a terminal app installed to run them, but the purpose of this app is to make life easier for having our favorite commands ready to execute. Many of these commands are possibly a small subset of common ones, but even with that, I probably prefer to redirect the output to a diffferent place that abother user using the same command. So having a 'user tab' to be able to add, edit and delete commands (also maybe copy a command from other tab) will be very useful.
Anyway, congrats for comming up with this useful app.
short/y said:
Yes, I'd like to have that. I can think of a few I'd like to have NOW as opposed to waiting for someone to come up with them
Code:
df -h /sdcard
df -h
ls -lrt /mnt/sdcard | tail
ls -lrt /sdcard/Download | tail
ping www.google.com
ifconfig lte_rmnet1
netstat -rn
netstat -l
netstat | grep CLOSE
uptime
And probably few others that I could come up with once I really thought about it. Why not have "protected" command sets which are updated thru the app or Market and "user" or, as you call them, "local"?
Click to expand...
Click to collapse
One question about those commands: some of them return results that will not fit on one line and so would not fit in the space reserved for the status (lower line in the list).
How would you like to display the result?
- as a popup when running the command
- as a multi line status field 'growing' when required and updating automatically
pp1276 said:
First of all, thanks for develop another great application.
I concur that having the possibility to add commands is really a 'must have'. Of course, if we are thinking about to create commands, this means all of us have already a terminal app installed to run them, but the purpose of this app is to make life easier for having our favorite commands ready to execute. Many of these commands are possibly a small subset of common ones, but even with that, I probably prefer to redirect the output to a diffferent place that abother user using the same command. So having a 'user tab' to be able to add, edit and delete commands (also maybe copy a command from other tab) will be very useful.
Anyway, congrats for comming up with this useful app.
Click to expand...
Click to collapse
I am convinced: https://github.com/asksven/CommandCenter/issues/5
Shell script to disable read receipts for all your incoming Whatsapp messages
Even "better": Others won't see whether you've already read their message(s) or not. However, you will still be able to see the read receipts of others!
Code:
################################################################################
#
# Shell script to disable read receipts for all incoming Whatsapp messages.
#
# [ ANDROID AND ROOT ONLY ! ]
#
# Author: Stephan Schmitz <[email protected]>
# Source: https://gist.github.com/eyecatchup/9af90363732801b131bf
# Last Updated: 09. Nov 2014
#
# ABOUT
#
# You don't like that everyone in your Whatsapp contact list is now able to see
# whether you've already read their latest message(s) or not? Then feel free to
# use the following "work-around" that I found to disable sending read receipts
# globally. Once patched, whenever you get new messages, the senders will never
# see the 2 check marks in blue. They'll just stay gray, just like it was until
# recently. Well, almost. Because you'll still be able to see whether your chat
# partners have already read the messages you sent to them. ;)
#
# DESCRIPTION
#
# In early Nov. 2014, Whatsapp added a new "feature" - read receipts. It means,
# your chat partners will get a visual feedback (2 blue check marks) as soon as
# you've read their message(s).
#
# Unfortunately, Whatsapp's dev team forgot to implement a corresponding privacy
# setting for users to be able to turn off this feature. However, fortunately, I
# found it was fairly simple to disable the feature, since it is set in a public
# XML file in Whatsapp's app data directory.
#
# This script shall serve as a convenient wrapper for those Android users who do
# not live in userland - as well as for the lazy ones.
#
# PRE-REQUIREMENT
#
# Basically, all it needs is a working `sed` commandline utily in path.
# If you should not have "Busybox" installed yet, choose one of the available
# "Busybox" installer apps from Google Play Store and let it install busybox.
#
# USAGE
#
# - Save this script to your phone's sdcard as disable_whatsapp_read_receipts.sh
# - Open a terminal session on your device
# E.g. https://play.google.com/store/apps/details?id=jackpal.androidterm
# - In the console, login as root (type su, hit enter) and type:
# sh /sdcard/disable_whatsapp_read_receipts.sh
# (adjust the path, if required, to fit your's!)
# - Hit the enter button. Done. (Whatsapp will restart afterwards)
#
# If you get any error message a) make sure the /data partition is mounted /w rw
# permissions and b), if the permission for restarting WA is denied, 1st try to
# uncomment the last line of this script (append hash char "#" (without quotes))
# and run the again. Otherwise, consult me for help here:
# http://forum.xda-developers.com/android/development/script-disable-whatsapp-read-receipts-t2933467
#
# IMPORTANT NOTE
#
# The last successful test for this was run at 09. Nov. 2014 and on the Whatsapp
# Android version 2.11.399 and 2.11.432 only. Even though it should work for all
# Android versions, it was not tested. Also, Whatsapp might change their current
# implementation any time soon. So this work-around might stop working any time
# soon too. Keep that in mind!
#
################################################################################
Download
NOTE: This script requires the "sed" command line utily (ie "busybox") installed on the system, which pre-requires a rooted device!
NOTE: The gist requires an update, which I'll post tomorrow. For further details and a manual workaround see my post here: http://forum.xda-developers.com/showpost.php?p=56640205&postcount=9
External link to gist.github.com (see the inline comments for further instructions): http://goo.gl/EiOvO0
Download, run, done. Enjoy. Whatever.
PS: For those who understand German, here're some screenshots of testing this " hack". As you can see, my chat partners can't see the read status. http://imgur.com/a/kzQs3
Nice trick!
However, I've noticed that the preferences .XML files are reset to the original values once the application relaunches. So, basically, the changes do not stick.
Any workaround on this?
smartxdev said:
Nice trick!
However, I've noticed that the preferences .XML files are reset to the original values once the application relaunches. So, basically, the changes do not stick.
Any workaround on this?
Click to expand...
Click to collapse
That's kind of odd, since the script explictly restarts the Whatsapp package *after* applying the changes to the prefs xml. Which then, in turn, should result in no result at all (assuming a restart rewrites the xml), right!? But it does work. Now, the first question would be how you define restart (activity (re)launch, package force && start)?
Update: Just checked it and you're right. If I use the -S option on the am start call (to force stop Whatsapp before (re)starting the activity), running script has no effect at all - since the XML is being recreated. And that also means, that the change will gets lost with every device reboot.
The easiest solution I see here, to have a "permanent" effect, to wrap the script in a plain simple app and attach it an onboot service. (Also, looking at #4, some further checks should be added.) If Whatsapp will leave this current implementation of defining whether to send read receipts or not, I'll invest the time into an app version, I think. (Just don't want to have too much hustle with it. So want to wait whether it's worth to spend more time on this.) Thoughts?
hi, i have this problem:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
can you fix it?
Dj Mauro said:
hi, i have this problem:
can you fix it?
Click to expand...
Click to collapse
I had permission error too.
In the terminal, try to first run "su" command (without the quotation marks), it will obtain root permissions for the terminal.
Then run the actual command. That solved the permission error for me.
Bexton said:
That's kind of odd, since the script explictly restarts the Whatsapp package *after* applying the changes to the prefs xml. Which then, in turn, should result in no result at all (assuming a restart rewrites the xml), right!? But it does work. Now, the first question would be how you define restart (activity (re)launch, package force && start)?
Click to expand...
Click to collapse
Actually it never worked for me (I mean, script ran successfully, but i have no success in disabling the "read recipient" when i tested it).
Then, I tried to do it manually:
- make a backup copy of the target file (/data/data/com.whatsapp/shared_prefs/com.whatsapp_preferences.xml)
- and then set: "read_receipts" to value="0" in the original file
- save it
- and when i open whatsapp app again, the XML file is restored to the older values, and the "backup" copy gets erased.
And for the "restart" question, i tried the following:
1 - swipe the app away from the recents, make XML modifications, and relaunch
2 - kill the app, make XML modifications, and run it again
I also tried to set XML file permissions to read-only, but it still was replaced by original config. once i opened the app.
-----
I was thinking about another workaround:
Since the read receipt (and delivery too) is usually done by transmitting a small message by the application, back to the sender, once the conversation window is opened.
It may be possible to just block this outgoing communication on your side by XPrivacy.
But, i have yet to hunt down the specific permission/address to block, without crippling the app..
Dj Mauro said:
hi, i have this problem:
snip
can you fix it?
Click to expand...
Click to collapse
As a quick fix, this should work for you:
1.) Add the following line above the line with the sed command:
Code:
mount -o rw,remount /data
2.) Change the last line of the script to the following (if it still compains replace the user id value in the command with that from the error message. and if it still complains, it might even work when you just comment out the line):
Code:
echo `am start --user -2 -n com.whatsapp/com.whatsapp.Conversation`
3.) Back in the console again, login as root (su, enter) and run the script.
Let me know if it worked.
As said in my update to post #3, I'll probably add some automatisms for such issues soon.
Bexton Tnx !
how about an xposed module?
smartxdev said:
I had permission error too.
In the terminal, try to first run "su" command (without the quotation marks), it will obtain root permissions for the terminal.
Then run the actual command. That solved the permission error for me.
Click to expand...
Click to collapse
Yeah, recognized already that I completely forgot to mention that at all (to run the script as root). I updated the inline instructions accordingly.
smartxdev said:
Actually it never worked for me (I mean, script ran successfully, but i have no success in disabling the "read recipient" when i tested it).
Then, I tried to do it manually:
- make a backup copy of the target file (/data/data/com.whatsapp/shared_prefs/com.whatsapp_preferences.xml)
- and then set: "read_receipts" to value="0" in the original file
- save it
- and when i open whatsapp app again, the XML file is restored to the older values, and the "backup" copy gets erased.
And for the "restart" question, i tried the following:
1 - swipe the app away from the recents, make XML modifications, and relaunch
2 - kill the app, make XML modifications, and run it again
I also tried to set XML file permissions to read-only, but it still was replaced by original config. once i opened the app.
Click to expand...
Click to collapse
Sheesh. Okay, I think I got what's wrong here.
As far as I understood, you didn't even got to the point where the file
Code:
/data/data/com.whatsapp/shared_prefs/com.whatsapp_preferences.xml
stored the modified value, correct?
When I was looking at your manual procedure I recognized a small but probably crucial difference! Let's have a look at it. My initial, manual approach was:
# Login as root
Code:
[email protected]> [B]adb shell[/B]
[email protected]:/ $ [B]su[/B]
# Copy the original prefs xml file to /sdcard/.
# NOTE: We use cp as root user, but with the --preserve switch to copy a file owned by Whatapp's OS user.
Code:
[email protected]:/ # [B]cp -p /data/data/com.whatsapp/shared_prefs/com.whatsapp_preferences.xml /sdcard/[/B]
# So, at this point, the copied file /sdcard/com.whatsapp_preferences.xml is still owned by Whatapp's OS user.
# Now, my last 2 steps were to modify the read-receipts settings value in /sdcard/com.whatsapp_preferences.xml and copy back the modified file to its original location, which I did as follows:
Code:
[email protected]:/ # [B]sed -i'.bak' 's/^.*\bread_receipts\b.*$/ <long name="read_receipts" value="0" \/>/g' /sdcard/com.whatsapp_preferences.xml[/B]
[email protected]:/ # [B]cp -p /sdcard/com.whatsapp_preferences.xml /data/data/com.whatsapp/shared_prefs/[/B]
So all together, this was:
Code:
[email protected]> [B]adb shell[/B]
[email protected]:/ $ [B]su[/B]
[email protected]:/ # [B]cp -p /data/data/com.whatsapp/shared_prefs/com.whatsapp_preferences.xml /sdcard/[/B]
[email protected]:/ # [B]sed -i'.bak' 's/^.*\bread_receipts\b.*$/ <long name="read_receipts" value="0" \/>/g' /sdcard/com.whatsapp_preferences.xml[/B]
[email protected]:/ # [B]cp -fp /sdcard/com.whatsapp_preferences.xml /data/data/com.whatsapp/shared_prefs/[/B]
So what happened with the last 2 commands that made it work for me, but breaks in the script version?
The core problem here is, as I just learned, that GNU sed's -i extension does not actually edit files in place (--in-place is a misnomer, in my opinion); it creates a temp file, deletes the original file, then renames the temp to the name of the original. The result is a new file - much possibly with a different owner.
So in my manual procedure, the result of the sed command worked fine except for the fact that it changed ownership on all the files it went through. The only problem is that these files (or at least the backup file) were owned by the root user - the user I run the command as. However, then I used the -f switch (to force overwrite) and the -p switch (to preserve permission, ownership and timestamps) to copy back the prefs file from /sdcard/ back to its original location in the Whatsapp data folder. That means, as a result, in the Whatsapp data folder there was a) no new file from another user (the backup file) and b) the modified prefs xml file still had its original ownership information. Basically, this kind of "fixed" sed's -i mode behaviour on the prefs file plus didn't created a new file in Whatsapp's data folder.
The last step to solve the puzzle is fairly simple. I just tried the procedure manually - as defined upthread - with all my friends' phones. Thus, I didn't noticed the sed behaviour. Plus, the friend Iinitially wrote the script for didn't told me that it wasn't working for him.
Anyway. Let's finally come to how to fix.
A quick look into the sed manual unveils that -c switch should do the trick:
Code:
-c, --copy
use copy instead of rename when shuffling files in -i mode
(avoids change of input file ownership)
Unfortunately, this switch is not enabled in all the busybox sed's for Android. Also, this would still leave us with a new file in Whatsapp's data directory. Even if all ownership information of existing files can be preserved, we should also not create any files in the folder that are not known to the Whatsapp app.
So basically my manual approach is the way to go:
a) Save the backup of the original prefs file somewhere on /sdcard/
b) Preserve ownership and permissions for /data/data/com.whatsapp/shared_prefs/com.whatsapp_preferences.xml
NOTE: Even if you got the value in the prefs xml saved to "0" and with no changes to ownership and permissions, you still need to restart any running Whatsapp process. Otherwise the change will have no effect! And, rebooting the device, resets the prefs xml file!
I'll post an updated version later. Until then, probably the easiest way to test this, is the manual way using a text editor app on your device.
- Open any text editor app with root capabilities (I used https://play.google.com/store/apps/details?id=com.maskyn.fileeditor )
- From the menu choose "Open file", navigate to /data/data/com.whatsapp/shared_prefs/ and open the file com.whatsapp_preferences.xml
- Find the line that reads <long name="read_receipts" value="SOMENUMBER" /> (SOMENUMBER is a placeholder, of course)
- Replace SOMENUMBER with 0 (zero), so the line reads <long name="read_receipts" value="0" />
- Save the file
- Now, close Whatsapp from the recent apps view and restart it.
- You can verify the change by running the following command (as root) from a terminal on your phone:
Code:
cat /data/data/com.whatsapp/shared_prefs/com.whatsapp_preferences.xml |grep read
- You can verify the ownership and permissions by running the following command (as root) from a terminal on your phone:
Code:
ls -l /data/data/com.whatsapp/shared_prefs/com.whatsapp_preferences.xml
smartxdev said:
I was thinking about another workaround:
Since the read receipt (and delivery too) is usually done by transmitting a small message by the application, back to the sender, once the conversation window is opened.
It may be possible to just block this outgoing communication on your side by XPrivacy.
But, i have yet to hunt down the specific permission/address to block, without crippling the app..
Click to expand...
Click to collapse
Sure, feel free to share any suggestions!
Ather said:
how about an xposed module?
Click to expand...
Click to collapse
I guess that'd be possible too. Just that I never looked into it yet.
Thanks, @Bexton for your detailed explanation.
Manual editing by Turbo Editor did the work for me.
I tested it, and the blue check marks were indeed blocked.
And btw, Turbo Editor has a nice "recent files" list on the startup, so reediting of the parameter on restart should be simple and easy.
Then, i did Restart (full restart to the device), and.... ...it still holds!
The parameter in the XML is unchanged and read notifications are still blocked
So, it made me wonder, why it didn't work for me before? I used ES Text Editor to edit the XML, it was fine, but then i made a backup copy somewhere inside the /data/data/com.whatsapp/ folder. And I think that "foreign" file caused full rewrite of the xml files by the app.
I hope it may hold permanently, but, we'll see..
Ahoy everyone!
We're 2 students from the University of Milan who created a repository [https://github.com/phosphore/whatsapp-blue/wiki]
for an Android app with the aim of getting rid of those blue ticks. We're currently
considering and testing out all the possible solutions including the modification
of com.whatsapp_preferences.xml (as found by @Bexton) or the filtering of the TCP
packet responsible for the read receipt.
Although using Bexton's method greatly simplifies the solution, it is just a
temporary workaround before Whatsapp fixes it.
Having a proxy filtering the requests should be a permanent solution. We are
reverse engineering FunXMPP (WA proprietary protocol) to find that particular request.
We're open to contribution!
smartxdev said:
So, it made me wonder, why it didn't work for me before? I used ES Text Editor to edit the XML, it was fine, but then i made a backup copy somewhere inside the /data/data/com.whatsapp/ folder. And I think that "foreign" file caused full rewrite of the xml files by the app.
I hope it may hold permanently, but, we'll see..
Click to expand...
Click to collapse
Some editors use a similar internal workflow as GNU's sed in -i mode and without the c switch. Resulting in "corrupted" files (in the sense of ownership & contex)..
Th3Zer0 said:
Ahoy everyone!
We're 2 students from the University of Milan who created a repository [https://github.com/phosphore/whatsapp-blue/wiki]
for an Android app with the aim of getting rid of those blue ticks. We're currently
considering and testing out all the possible solutions including the modification
of com.whatsapp_preferences.xml (as found by @Bexton) or the filtering of the TCP
packet responsible for the read receipt.
Although using Bexton's method greatly simplifies the solution, it is just a
temporary workaround before Whatsapp fixes it.
Having a proxy filtering the requests should be a permanent solution. We are
reverse engineering FunXMPP (WA proprietary protocol) to find that particular request.
We're open to contribution!
Click to expand...
Click to collapse
Could you hook up via email? I'm working on an app as well and currently considering the possibilities. Maybe it's worth sharing thought.. Please send to [email protected], thanks!
This is why I waited before investing more time into it, hehe. So, time to relax for everyone. Here is news:
Whatsapp will soon get the ability to turn off the blue checkmark read indicator, according to an alleged Beta tester of the application.
Click to expand...
Click to collapse
Original tweet: https://twitter.com/0xmaciln/status/530294585072025600
Via: http://www.myce.com/news/whatsapp-w...ble-privacy-sensitive-blue-check-marks-73438/
Looks like this thread will be obsolete very soon.
Bexton said:
Whatsapp will soon get the ability to turn off the blue checkmark read indicator, according to an alleged Beta tester of the application.
Original tweet: https://twitter.com/0xmaciln/status/530294585072025600
Via: http://www.myce.com/news/whatsapp-wi...k-marks-73438/
Looks like this thread will be obsolete very soon.
Click to expand...
Click to collapse
Nice!
I think whatsapp(facebook?) expected this to come, they already had some bad experience with the "last seen" issue some time ago.
And it is already implemented as a simple switch inside XML prefs...
Bexton said:
Looks like this thread will be obsolete very soon.
Click to expand...
Click to collapse
Hm, maybe I was wrong and it will not become obsolete. Maybe I will still build an app for it. Why? I found more news on the matter, that pointed out a major difference to me.
The same person who confirmed the additon of the on/off toggle for the read receipts, Ihlan Pektas, actually blogged about the feature already a few days ago. The essential information given in his blog post here (in German language) for me is, that he says that early alpha builds already have an implementation for it, and when you disable sending your read status (so that others can't see if you've read a msg), you will, in return, NOT be able to see the read status of your chat partners! (What makes perfectly sense, becausee it's the same way they do it for the "last seen" status.)
That being said, I think there'll be interest in an alternative. An alternative that is capable of disable sending one's own read status, while still being able to see the read status for one's own msgs, sent to others?!
Well, we'll see. (But the party ain't over yet.. )
Thanks Bexton. Tried your manual method with ES File Explorer, without making a backup, and it works. Even survives a full reboot.
Bexton said:
That being said, I think there'll be interest in an alternative. An alternative that is capable of disable sending one's own read status, while still being able to see the read status for one's own msgs, sent to others?!
Well, we'll see. (But the party ain't over yet.. )
Click to expand...
Click to collapse
I see your point, but to make this happen, we need to look at another approach. Because, now we disable it by the pretty obvious flag in the pref. file, and once they release a "feature" it will be probably the same flag that will cause you not the deliver read receipts either.
The thing is, that in fact I barely use whatsapp, for various reasons. I'm here to help some non-techie friends of mine.
Anyways, I use Open WhisperSystems' TextSecure mostly (less polished and fewer features, but free, opensource, and actually secure).
So, a short while ago, they've introduced "delivery receipts". And for some reason, only I was able to get others' delivery receipts, but when others send me messages, they didn't receive a delivery receipt from me. (That's basically what we are trying to do here, just with read receipts)
At first, I was sure there is some bug in this. But then it turned out that I tuned XPrivacy too tight on restrictions, and this new feature could not get through and send the delivery notice. (unfortunately I don't remember what exactly the troublesome restriction was)
That's why i first thought about XPrivacy for this case as well.
Logically, the mechanism here might be the same, and once we find out what activity or address to block it will do the trick without letting the app itself know about it.
And it seems like @Th3Zer0 guys have the same direction in mind.
Bottom line: sounds like a good idea to find out how to "cheat" those things, and maybe build Xposed module/app on it
This seems to be the equivalent of downgrading whatsapp, letting you see blue ticks but other's cant see
It seems that it disables the part where you can highlight your own message and see who has seen the message though.
Working on 2.11.432.
Whatsapp just enabled a new feature a la Telegram where you can see who's typing in a group.
Contradictory to my previous report, I'm noticing that over time the "read_receipts" parameter keep reverting to a original value. What's weird though is that i was unable to pinpoint when it actually happening, since it happens without any kind of full phone restart in between.
Have you (@Bexton?) any insight on it?
And by the way, as I was talking about the sadly unpopular, but security-wise superior TextSecure, this post came out: Open Whisper Systems partners with WhatsApp.
Sounds promising, but it still remains to be seen how it all gets implemented and how much of a metadata leakage will be going on, since it is very unlikely that a proprietary and closed source SW company as WhatsApp will kill their business value (which is an insight on near 700M users' data) just like that.
INTRODUCTION
There was a time where “enlightned” people used to make fun of guys like me:
paranoid, conspirationist, tin foil hat, ha ha ha!
The thing is that there has never been any conspiracy theory, it's a term invented by those in power to ridicule people exposing their treacheries.
A conspiracy is a plot aimed at overthrowing a king or a government so how could those in power make any conspiracy against the people, us, since we are not in power?
A theory is something that has not been proven and well, after the Snowden's revelations things have been made clear, so long for the “conspiracy theory”.
The enlightened stopped laughing and started to realise what's going on, and that their dear government and their beloved google were not such a nice bunch to say the least.
Nowadays more and more people wake up and understand that their phones are heartlily spied upon and data mined all the time, and I decided to write a tutorial about how to gain back one's privacy on one's phone.
Remember, Android has not been build with privacy in mind and everybody wants our data, cuz data means money and money has been driving, is driving and will be driving humanity for a long time.
In a way it's ok if one doesn't mind ads and spams, one has to bear in mind that nothing comes for free and the costs to develop an app like let's say what's app or to maintain a site like facebook are huge so the money has to come from somewhere (as some say, if it's free than you are the product).
Plus, one is allways free not to use them, but unfortunately one needs an OS (google), and one needs an oem to manufacture the phone.
Then comes power, it has been driving humanity for even longer than money.
As @CHEF-KOCH said, data means knowledge and knowledge means power. In the past it was a hard task to manually gather data about people and one can easily understand that the present huge data sum that's on the web is of very significative importance for the agencies.
So of course they pressure google, facebook, apple, microsoft and the others to get access to your data, from their point of view it makes sense.
I have nothing to hide but as a matter of principle I have allways tried my best to be in control, and I have to admit that it's fun and interesting too, one learns many things in the process.
I don't know everything (who does anyway?) and everyone is welcome to add some more infos on the subject, let's share our privacy settings!!!
Let's start, with a brand new phone...
I - THE BASICS
1 - Don't give your real name when you buy a new phone (it sounds obvious but many people don't even think about it), and pay in cash in order not to leave any traces.
2 - Second, don't give your real name when you buy a SIM.
3 - DO NOT put any SIM in the phone for now, DO NOT connect to the internet through WIFI, and put your phone in plane mode. You'll be able to connect after you're done and secure.
4 - Root and install Busybox, flash a custom recovery (I won't cover that part, search the forum and you'll find all what you need).
5 – Let the fun begin, uninstall as many stock apps as you can!
Don't think that installing a custom ROM like AOSP or CM would be any better than your stock ROM privacy wise, custom ROMs don't have OEM bloatware but when it comes to privacy, data mining and outrageous system apps' permissions they are exactly the same than stock ROMs.
Before you start your uninstalling job, download Aroma File manager from here:
http://forum.xda-developers.com/showthread.php?t=1646108
Put it on your SD.
It will enable you, in case you get a bootloop, to push back from recovery the file (s) you removed that caused the bootloop, instead of restoring your backup and loosing all the work you did.
TWRP has a built in file manager that does the same, just make sure you have /system and /data mounted in the settings.
Uninstall gradually.
Start with the google apps and the OEM bloatware, reboot and see how it goes. If everything is ok then uninstall more stuff, again reboot and see how it goes, and keep on doing it until you feel it's ok.
You'll be wise, everytime you uninstall a bunch of apps, to copy them first on your SD and label it something like apps1, apps2 etc.
Now read carefully the folowing about safe to remove apps, in order you to know more precisely what can be done, and you will see that my phone works with only 10 system apps left.
(Tested on Samsung Mega I9200 XXUAMEE running JB 4.2.2)
I removed more than 150 system apks, and my Mega works like a charm.
You will notice that the google apks are missing, and that the contacts, video player, music player, file manager etc. are missing as well, I removed them because I don't like the way they spy on us and suck our private data. No worries, just keep on reading for some alternative apks...
IMPORTANT
1 - Before deleting any app do a Nandroid back up, and do a back up of your system/app folder (where all the system apps are) in case you want to reinstall a specific app later.
2 - If you decide to uninstall the filemanager apk, install first an alternative file manager, like let's say Ghost Commander, because if you don't then you won't have any app anymore to navigate to your files after having uninstalled the file manager.
Same story with the launcher, or you will get a bootloop.
3 - After you uninstalled all the apps do a cache and a dalvik cache wipe.
4 - Reboot and enjoy full speed and no lags, and 1% battery decrease every 10-12 hours when in stand by!!!
5 - Go to the data/data folder and erase the folders from the removed apps, or use SD Maid or whatever similar app to do it for you (you don't need to do it if you are on JB 4.2 or later since the system will take care of it for you when you reboot)..
IMPORTANT 2
Do not mess with system apps if you don't know what you are doing and if you don't know how to get back to the beginning in case things go wrong.
I won't take any responsability for any damage caused to your phone. All what I mention below has worked for me but once more, do not play with your system unless you know how to recover if things get out of control.
SAFE TO REMOVE APPS
Rather than giving a list of removed apps I will list here the apps I didn't remove, so that you can assume that any app that is not on the list is safe to remove. I do so because it's faster to list the remaining apps than the removed ones...
So, here are the apps I kept (I have to admit that it's a bit extreme, and you are of course not obliged to keep so few apps, but at least you'll know which ones are safe to remove):
-Default Container Service
-Fused Location
-Hybrid Radio (removable if radio is not your thing)
-Job Manager (the task manager)
-Package Access Helper
-Sec Phone
-Sec Settings
-Sec Settings Provider
-Sec Telephony Provider
-System UI
- Note -If you delete the Media Provider apk you won't be able to change your ringtone and your notification tone anymore (not a big deal for me but I don't know for you), and you will be stucked with the default tones. To change them manually you'll have to open the res/raw folder in framework-res.apk and replace the default tones with your own, not a big deal.
If you delete the camera then some third part cameras won't work, but A Better Camera does.
If you delete the MTP apk your device won't be detected by your computer anymore, use SG USB Mass Storage Enabler or something similar (only works on the external SD).
You can delete VPN Dialogs but then you won't have VPN access anymore.
ALTERNATIVE APPS- Play Store:
F-Droid offers open source apps and you'll find almost all what you need there. If you can't live without apps from the pay store download them on your computer using Racoon (found in XDA's games and apps section).
- Launcher:
Holo Launcher HD (very low RAM consumption and plenty of customisation), or ADW (open source up to v 1.3.6 standalone, found on F-Droid), but install it before you uninstall your stock launcher!
- Keyboard:
I use a modded Xperia keyboard but there are many others (install it as a /system app otherwise you may have problems if you encrypt your phone). Beware of Swift and Touch Pad, they have many outrageous permissions and are difficult to restrict.
- SMS:
Text Secure (open source), up to v 1.0.6.
- Bluetooth:
if you use it for speakers or headphones keep it, but if you use it only to transfer files then uninstall it and use Fast File Transfer (it works without WIFI connection and it's MUCH faster than the Bluethooth) and/or any open source FTP app (like Swiftp for example, but such apps require an active internet connection) instead.
- Contacts:
before to uninstall it back up your contacts, then install any third part contacts app. As for me, I made a file with all my contacts in alphabetical order and copied it as a note in Clipnote apk (a clipboard manager), and when I need to call someone I just have to click on the phone number within the file and it opens in the dialer.
- Dialer:
since Logs Provider has been uninstalled you probably don't have any more dialer, just install any third part dialer that you like.
- Video:
VLC. (open source)
- File manager:
Ghost Commander (open source, dual panel mode, root browser and more).
- Music player:
I like Gone Mad Music Player but VLC does the trick too.
- Browser:
Pale Moon for full desktop experience (it's open source and based on Firefox, but it has less permissions and no adds), Atlas or Lightning (open source) when I want to browse without leaving any cookies (I have changed its data/data/nextapp.atlas/databases' permissions to rx, rx, x (5, 5, 1) and I erased everything inside the folder, that way no cookies or history are recorded), Naked Browser to access my email.
Chrome? No thanks, the least google stuff I have in my phone the better I feel!!!
- Gallery:
Quick Pic.
- PDF reader:
Mantano or PDFReader (open source, found on F-Droid).
- Edit documents (doc., docx. etc.):
Office Suite or Kingsoft Office. Those apps need to be toroughly restricted, otherwise use a text editor like 920 Text Editor (open source, found on F-Droid).
- Gmail:
any email app will do, otherwise access gmail from Naked Browser or Atlas or Lightning, it's faster. Still, you'd better leave gmail and go for another email, just my two cents...
- Alarm:
Alarm Klock (open source, found on F-Droid).
- Google maps:
Rmaps (open source, found on F-Droid).
- Clipboard:
Clipnote.
- Calculator:
Arity (open source, found on F-Droid).
- Quick Notes:
Floating Stickies (open source, found on F-Droid).
- Html Viewer:
replacable by a third part html viewer or by most browsers as they can read html.
- Camera:
Open Cam (open source, found on F-Droid)
- Bonus:
Greenify (try it, it hybernates apps and saves juice, I'll explain about it later).
Done?
Cool, now go to post #3 and see what else can be erased...
- Note 2-On KK there are more apps that can't be uninstalled, about 30 or something, pretty annoying and I guess that it doesn't get any better with Lollipop, thanks to google's efforts to strenghten its grip on Android and on us.
As for me I came back to JB and you have to ask yourself whether you want to compromise your privacy to get the latest gimmick and the latest fancy color (that have anyway been made available on JB with Xposed modules) or whether you want to be safe.
There are small sacrifices to make and I think the game is worth the candle, but it's up to you...
You can read more on that topic in post #3
II – THE TOOLSNow you need some tools, namely:
- Xposed Installer:
http://repo.xposed.info/module/de.robv.android.xposed.installer
- Xprivacy:
http://repo.xposed.info/module/biz.bokhorst.xprivacy
- App Settings:
http://repo.xposed.info/module/de.robv.android.xposed.mods.appsettings
- AF+ Firewall:
https://f-droid.org/repository/browse/?fdfilter=af&fdid=dev.ukanth.ufirewall
- Network Log:
https://f-droid.org/repository/browse/?fdfilter=network+log&fdid=com.googlecode.networklog
- Greenify:
http://forum.xda-developers.com/apps/greenify
- Blue Box Security Scanner (apps and vulnerabilities scanner)
- SQ Editor
- Rom Toolbox Lite (free) or Pro (paid)
- Privacy Blocker (paid)
- First
Open Privacy Blocker.
Scan all your third part apks one by one, and see their dirty little secrets. Then mod the ones you don't like, it's easy, just follow the onscreen instructions.
- Second
Open Rom Toolbox.
Block adds, prevent apps from auto starting and disable any receiver you don't like, and try some build.prop and kernel tweaks while you're at it (be careful).
- Third
Open Greenify.
Greenify everything, except the launcher, the System UI, the Package Access Helper (you could greenify it but it does nothing since that app is ungreenifiable) and the Keyboard. You can greenify Settings and Settings Storage too, but it will slow down Settings when you lauch it.
DO NOT greenify Xprivacy and AF+ Firewall since you need them to run in the background (don't worry, those apps have a very low RAM footprint).
Create a “hibernate now” shortcut on your home screen, and don't forget to use it regularly to hibernate your apps.
Note that you'll need the donate version to greenify system apps, but it doesn't cost much and it's a nice way to support the dev.
- Fourth
Install Xposed, Xprivacy and App Settings.
Enable Xprivacy and App Settings in Xposed's menu (under modules), reboot, and make a new backup cuz from now chances to get in a bootloop will increase and dependingwhat you've done it may not be Aroma File manager recoverable..
Open App Settings and disable the apps' perms you don't like (be careful with System UI as it may result in constant force close).
To give you an idea I have attached some examples of what can be restricted. You will notice that stock apps (like contacts, phone, CSC, settings etc.) are the most restricted, that's because they have the most outrageous perms. The apps in the list don't use the name they have in the play store but the packages' names (to find them go to data/app and check there).
Done? Now, open App Settings' menu and make a backup of your current settings.
Open Xprivacy and do the same, but first have a read at its documentation here:
https://github.com/M66B/XPrivacy#xprivacy
and at the following tutorial I wrote some months ago (it was for an old version of Xprivacy, but you'll get the idea) :
This page is about generic settings that work with more or less any app.
USER APPS
After a new app is installed restrict everything in Xprivacy. Open the app and check if it crashes or not.
If it doesn't it's fine, you're all set.
If it does, go back to Xprivacy and look for which data the app has tried to access by looking for categories that have a triangle next to them, and subcategories written in bold with numbers on the right (the first number is today's date, the four digits after the slash mean the last time the app tried to access that data). Unrestrict the data it has tried to access and see what happens, it should most likely bring your app back to life.
BUT!
Some apps try to access data even if they don't really need it to work, which means that restricting it shouldn't be a problem (it's not because an app has tried to access this or that data that it needs it to function, and that's what Xprivacy is about).
Try selectively : restrict one subcategory, launch the app and see what happens. If it crashes or forces close it means that you shouldn't have restricted that subcategory, so just allow it again and go for the next one. If once opened the app doesn't crash and seems to have its basic functions working normally then you can go for more restrictions, but close the app first (not by hitting the back button, you need to really close/kill it, with a task killer or anything similar).
Back to Xprivacy, restrict one new subcategory's data access, launch the app again, see what happens and so on...
Usually, and as a rule of thumb, what causes apps to crash is restricting some subcategories in the Shell section (like "loadLibrary", "load", and sometimes "exec"), the Storage section (mainly "getExternalStorage", but it could be "sdcard" as well), and the System (installed apps) section. So look for the triangles and the subcategories in bold, because if it's ok to restrict a subcategory in let's say Accounts or Contacts even though you see it in bold, most of the time restricting such a subcategory in the Shell, Storage, and System sections will make the app force close, or at least prevent it from working normally.
Don't take my word for it though, in some cases it's possible to restrict even subcategories in bold in those three sections. But it's on a case by case basis, thus making it impossible to give a general rule. The only way to find out is to test by yourself...
Now let's see section by section.
The below settings are the ones I use for my phone and my tab, and you will probably notice that I'm a bit extreme and that I don't use some very popular apps. You are of course not obliged to be as restrictive as I am, but at least you will see what can be restricted and what can't be.
Accounts (Google, Facebook, etc) :
I don't want ANY app to know which accounts are registered on my phone so it's all restricted for all apps, even for the ones that try to access this data like Firefox (remember the triangle and the subcategories in bold?). Feel free to add whatever you think is relevant for people that use Facebook, Gmail, Google play, Yahoo or whatever similar app, as for me I can't since I don't use those apps.
Browser (bookmarks/history), Calendar, Calling (phone, SMS, MMS), Contacts, Dictionary (user), Email, Identification (device) :
those sections can be completely restricted (with all their subcategories), except for specific apps that need to access such data (but once more, always try to restrict first). Since I don't use such apps I can't tell anything about it, feel free to add some lines if you do.
Internet :
an app that needs internet shouldn't have it restricted, for obvious reasons. Most apps that need internet will work with only "inet" allowed, although some may need "isConnected" to be allowed as well.
Since version 1.7 more restrictions have been added, and I found out that besides "inet" some browsers may need "getAllByName", and/or “getbyName”, and/or “getActiveNetworkInfo” allowed.
Location (fine/coarse) :
I don't want ANY app to get my location so by me it's all restricted for all apps. Feel free to add whatever settings you have if you use apps that need to know one's location.
Media (audio, photo, video) :
the subcategories are pretty self explanatory, allow or restrict based on your apps. Restrict all for an app that doesn't need media access, allow "startRecording" and/or "setOutputFile" for a voice recorder, "takePicture" and/or "android.media.action.Image_Capture" for the camera etc., easy.
Messages (SMS, MMS) :
pretty self explanatory as well, all restricted for all apps, except SMS app.
On mine only "getAllMessagesFromIcc" and "VoiceMailContentProvider" have been restricted, I had to leave the three other ones allowed as my SMS app (Go SMS) crashes otherwise.
Network (addresses) :
all restricted, for all apps, except apps like FTP or Fast File Transfer (file transfer through WIFI). For those apps I left "getInetAddresses" and "getInterfaceAdresses" allowed. Some other similar apps may need "getScanResults" as well.
NFC :
all restricted, for all apps. If you use NFC you will have to find by yourself which one (s) can or can't be restricted but no biggie, there are only three subcategories.
Phone (ID, numbers, calls) :
all restricted, for all apps.
Shell (commands, superuser) :
root apps may or may not need "sh" and "su" allowed, look if they are in bold if an app crash. Same thing for "exec", "load", "loadLibrary" and "start" (root and non root apps alike), look if they are in bold but bear in mind that in some rare cases you still can restrict those subcategories even if you see them in bold (as said above).
Try selectively if like me you like to restrict just for the sake of it.
Storage (media, SD card) :
all restricted for all apps, except the ones that need to access data on the sdcard like media player, pdf reader etc.
Once more look for the subcategories in bold, and once more remember that this bold text doesn't necessarily mean that the app needs access to that data to be able to work. Generally apps that need sdcard access will need "getExternalStorageState", and/or "sdcard", and/or “media”, and/or “open” allowed, but surprinsigly sometimes they work even with some of those subcategories restricted. The "media" restriction is to prevent writing on the external sdcard, leaving it read only.
System (installed apps) :
all restricted, for all apps, except apps like Sidebar or Launcher that really need to know which apps are on the device. Those ones need some subcategories to be allowed and the bold text is sometimes your friend, but as usual, the fact that it's there doesn't mean that data access for this subcategory is really needed.
View (browser) :
restricted, for all apps. If you restrict it you have to know that it won't work anymore when you click on a link inside an app and want it to be opened in your favorite browser, and for this reason if you want to report an issue in Xprivacy you will need to have it unrestricted. You may have to enable “android.intent.action.View” to open files from your file manager
CAUTION!
We are talking about user (installed) apps. For those apps, wrongly restricting something in Shell, Storage or System is not a big disaster, since at the most it will force close repetitively but still leave you enough time between two force closes to get back to Xprivacy.
When it comes to system (stock) apps it's another story, and restricting the wrong one (s) could result in a bootloop.
SYSTEM APPS
As said above, restricting those apps is potentially dangerous and you need some tools beforehand, in case something gets out of control. Most people do a Nandroid backup but hey, it takes forever to restore, and if your backup is a bit old the latest changes you made in your ROM will be lost.
Use Aroma File Manager instead (look for it in XDA, all credits to its developer amarullz), a very nice little zip that enables you to copy, paste, delete and change files' permissions from within CWMR.
TWRP can do the same, without Aroma FM.
If you get in a bootloop, all you have to do is to boot into recovery and install Aroma File Manager. Once done it will open by itself and then you can navigate to the folder where Xprivacy is installed (/data/app if it's installed as an user app, /system/app if it's installed as a system app) and delete it. Just to be on the safe side delete as well the Xprivacy .dex in /data/dalvik-cache. I'm not sure whether it's really needed or not, if you have a definitive answer about it you are welcome to edit this article.
Now you can reboot. Of course Xprivacy is gone, and so are its settings, but if you had backed it up (hopefully you had) using the pro key or Titanium Backup you are good.
I have tested the following settings on Samsung Galaxy Grand I9082, Galaxy Tab 7 Plus P6210 and Galaxy Mega I9200, but I don't see any reason why it shouldn't work on other Samsung ROMs.
My ROMs are skinned to the extreme and to the extent that I only have a few system apps left, which implies that I only can talk about those apps. My settings are a bit extreme as well, and you may want to allow more subcategories than I did depending on what you want to do with your device in terms of sharing, social networks, location access, contacts and the like, this article has only been meant as a guideline to show what can be restricted under extreme conditions.
Android System, Settings Storage, Settings, Wlan Test :
Particular care must be taken here, it's the most dangerous package and the most prone to cause bootloops.
Remember that the following settings work for sure on Samsung Galaxy Grand I9082, Galaxy Tab 7 Plus P6210 and galaxy Mega I9200, but on other devices no one knows before one tries. Have your Aroma File Manager ready, and go for it...
All categories and subcategories are restricted, except :
"getDetailedState", and "isConnected" in Internet (on my devices restricting "getDetailedState" ended up in a bootloop),
update as for Xprivacy version 3.5, allowed:
“Connectivity.getActiveNetworkInfo”, “Connectivity.getNetworkInfo”, “InetAddress.getByAddress”, “InetAddress.getByName”, “NetworkInfo.getDetailedState”, “NetworkInfo.getState”, “NetworkInfo.isConnected”, “NetworkInfo.isConnectedOrConnecting”, “Wifi.getConnectionInfo”,
"getScanResults" in Location (if I restrict it my devices can't see new WIFI networks anymore, but on other devices it can be restricted without that annoying side effect. In any case it won't cause a bootloop so just try),
"getConfiguredNetworks" in Network,
update as for Xprivacy version 3.5, allowed:
“NetworkInfo.getExtraInfo”, “Wifi.get.ConfiguredNetworks”, “Wifi.get.ConfiguredInfo”, "Wifi.getScanResults",
all the Shell subcategories. It worked with "sh" and "su" restricted but I decided to allow them again by fear that it could lead to instability. Android System is one of the core app in your device and AFAIK it can bypass such restrictions, so there's no point restricting them, plus that doing so could cause instabilities (but I may be wrong, if anyone knows better please correct me). Regarding "exec", "load", "loadLibrary" and "start", I didn't even try to restrict them, for the same reasons as above,
all the Storage subcategories. I used to have them restricted and everything was still working, except that it erased most of my /data/data folders' contents,
"getInstalledApplications", "getInstalledPackages", "getRunningAppProcesses", "queryIntentActivities", "queryIntentActivitiesOptions" and "queryIntentServices" in System.
You can restrict those subcategories though, but if you do so the Application Manager in your device's Settings won't show your apps, and your keyboard (s) may not pop up.
If you use a Lock Screen that requires Device Administrator to be enabled you may have to allow "queryBroadcastReceivers".
Update as for Xprivacy version 3.5:
Overlay and Sensors categories, I let them all alowed.
Camera :
All categories and subcategories restricted, except :
"loadLibrary" in Shell,
"getExternalStorageState" and "sdcard" in Storage.
Certificate Installer :
All categories and subcategories restricted.
*'''com.sec.android.FlashBarService (Multi Windows Bar) :'''
All categories and subcategories restricted, except :
"queryIntentActivities" in System.
Contacts, Contacts Storage, Logs Provider :
All categories and subcategories restricted, except :
the whole Contacts section,
"loadLibrary" in Shell.
If you want to import/export your contacts list you will have to allow "sdcard" in Storage, but once it's done you can restrict it again.
Package Access Helper :
All categories and subcategories restricted, except :
"sdcard" in Storage.
Package Installer :
All categories and subcategories restricted, except :
"sdcard" in Storage.
Phone, Dialer Storage, Sim Toolkit, CSC :
All categories and subcategories restricted.
If the Phone app crashes the first time you run it after you restricted everything, just allow the bold subcategories in the Phone (ID, Numbers, Calls) section. In my case it was "getSubscriberID" and "TelephonyProvider", and the app actually crashed when I disabled plane mode for the first time (I had installed Xprivacy while in plane mode). Once everything was back to normal I restricted again the two above mentioned subcategories and everything has been fine ever since.
System UI :
All categories and subcategories restricted, except :
"isConnected" in Internet (this one is actually restrictable, but if you do so the WIFI icon won't show up anymore when you are connected), Inet.Address.getByAddress,
"getExternalStorageState" in Storage,
"getRecentTasks", "getRunningTasks" and "queryIntentActivities" in System.
Task Manager :
All categories and subcategories restricted, except :
"getRunningAppProcesses" and "getRunningTasks" in System.
Done with Xprivacy? Now, open its menu and backup its settings.
(To Be Continued)
(Continued From Last Post)
- Fifth
Open Blue Box Security scanner and let it scan for vulerabilities.
Most likely it will find some, patch them with Master Key and Fake ID Fix:
http://repo.xposed.info/module/tungstwenty.xposed.masterkeydualfix
http://repo.xposed.info/module/tungstwenty.xposed.fakeidfix
- Sixth
Get init.d support.
Make a script to disable some folders that are otherwise recreated each time the phone boots.
I give you the following as an example that works on Samsung 4.2.2 but you may have to edit it depending which phone you have and which ROM version you are on:
#!/system/bin/sh
rm -r /data/anr/*
rm -r /data/backup/*
rm -r /data/clipboard/*
rm -r /data/connectivity/*
rm -r /data/local/tmp/*
rm -r /data/log/*
rm -r /data/system/container/*
rm -r /data/system/dropbox/*
rm -r /data/system/netstats/*
rm -r /data/system/shared_prefs/*
rm -r /data/system/usagestats/*
rm -r /data/system/throttle/*
rm -r /data/tombstones/*
if [ -e dev/log ] ; then rm -r dev/log ; fi
busybox chmod 000 /data/anr/
busybox chmod 000 /data/log/
busybox chmod 000 /data/system/dropbox/
busybox chmod 000 /data/system/throttle/
busybox chmod 000 /data/system/usagestats/
busybox chmod 000 /data/tombstones/
If you decide to use this script paste it in a good editor like Note Pad Plus. Then edit it if needed and don't forget to set the EOL conversion (found in the edit menu on the toolbar) to Unix/OSX format.
You want to do it directly from your phone?
Try 920 Text Editor app, it does the job fine (when you save a file set "Convert Line Break" to Unix/Android) :
http://920-text-editor.en.uptodown.com/android
Here's another init.d script, done with Pimp My Rom app (credits @Androguide.fr), to protect your phone from various MIM (Man In The Middle) attacks :
#!/system/bin/sh
### Pimp my Rom : Block Redirects
busybox sysctl -e -w net.ipv4.conf.all.accept_redirects=0; ###ICMP broadcast
busybox sysctl -e -w net.ipv4.conf.default.accept_redirects=0;
busybox sysctl -e -w net.ipv4.conf.all.secure_redirects=0;
busybox sysctl -e -w net.ipv4.conf.default.secure_redirects=0;
### Pimp my Rom : Block Source-Routing
busybox sysctl -e -w net.ipv4.conf.default.accept_source_route=0; ### ICMP redirects
busybox sysctl -e -w net.ipv4.conf.all.accept_source_route=0;
### Pimp my Rom : IPv4 Tweaks
busybox sysctl -e -w net.ipv4.tcp_timestamps=0;
busybox sysctl -e -w net.ipv4.tcp_sack=1;
busybox sysctl -e -w net.ipv4.tcp_fack=1;
busybox sysctl -e -w net.ipv4.tcp_congestion_control=cubic;
busybox sysctl -e -w net.ipv4.tcp_window_scaling=1;
### Pimp my Rom : Avoid Time-Wait
busybox sysctl -e -w net.ipv4.tcp_tw_recycle=1;
busybox sysctl -e -w net.ipv4.tcp_tw_reuse=1;
### Pimp my Rom : Protection against SYN Attacks
busybox sysctl -e -w net.ipv4.tcp_syncookies=1;
busybox sysctl -e -w net.ipv4.conf.all.rp_filter=1; ###Forwarding traffic
busybox sysctl -e -w net.ipv4.conf.default.rp_filter=1;
busybox sysctl -e -w net.ipv4.tcp_synack_retries=2;
busybox sysctl -e -w net.ipv4.tcp_syn_retries=2;
busybox sysctl -e -w net.ipv4.tcp_max_tw_buckets=16384;
busybox sysctl -e -w net.ipv4.icmp_echo_ignore_all=1;
###Turn on protection for bad icmp error messages
busybox sysctl -e -w net.ipv4.icmp_ignore_bogus_error_responses=1;
busybox sysctl -e -w net.ipv4.tcp_max_syn_backlog=1024;
busybox sysctl -e -w net.ipv4.tcp_no_metrics_save=1;
busybox sysctl -e -w net.ipv4.tcp_fin_timeout=15;
busybox sysctl -e -w net.ipv4.tcp_keepalive_intvl=30;
busybox sysctl -e -w net.ipv4.tcp_keepalive_probes=5;
busybox sysctl -e -w net.ipv4.tcp_keepalive_time=1800;
busybox sysctl -e -w net.ipv4.ip_forward=0;
One more (credits @bazz77 – http://forum.xda-developers.com/showthread.php?p=40767777#post40767777 , do visit the thread as you will find infos about how to harden your system) :
###Avoid a smurf attack
sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1;
###ICMP redirects ipv4
busybox sysctl -e -w net.ipv6.conf.all.accept_redirects=0;
###ICMP redirects ipv6
busybox sysctl -e -w net.ipv4.conf.all.send_redirects=0;
### ICMP redirects
busybox sysctl -e -w net.ipv4.conf.all.forwarding=0;
###Forwarding traffic
busybox sysctl -e -w net.ipv4.conf.all.log_martians=1;
###filter martians
busybox sysctl -e -w net.ipv4.tcp_max_syn_backlog=1280;
###TCP syn half-opened
sysctl -w net.ipv4.ip_forward=0;
###Tune IPv6 and disable lol
busybox sysctl -e -w net.ipv6.conf.default.router_solicitations=0;
busybox sysctl -e -w net.ipv6.conf.default.accept_ra_rtr_pref=0;
busybox sysctl -e -w net.ipv6.conf.default.accept_ra_pinfo=0;
busybox sysctl -e -w net.ipv6.conf.default.accept_ra_defrtr=0;
busybox sysctl -e -w net.ipv6.conf.default.autoconf=0;
busybox sysctl -e -w net.ipv6.conf.default.dad_transmits=0;
busybox sysctl -e -w net.ipv6.conf.default.max_addresses=1;
busybox sysctl -e -w net.ipv6.conf.all.disable_ipv6=1;
busybox sysctl -e -w net.ipv6.conf.default.disable_ipv6=1;
busybox sysctl -e -w net.ipv6.conf.lo.disable_ipv6=1;
### Don't act as a router
busybox sysctl -e -w net.ipv4.conf.all.send_redirects=0;
busybox sysctl -e -w net.ipv4.conf.default.send_redirects=0;
- Seventh
Open AF+ and set it for WIFI, data, VPN and roaming.
I think using white list option (allow selected) is better than black list since newly installed apps are blocked by default.
Restrict all apps, including system apps, that don't need to have internet access, and restrict Linux kernel, Linux shell, Internet time servers, DHCP+DNS services, GPS and Media server.
Enable IPV6 support.
Now, make a script to block inbound and outbound unwanted connections, call it whatever you want (but don't forget to end it with the .sh extension, and to give it RWX, RX, RX (755) permissions), and put it in data/local or in data/data/dev.ukanth.ufirewall/app_bin.
Here's an example of such script :
# Necessary at the beginning of each script!
IP6TABLES=/system/bin/ip6tables
IPTABLES=/system/bin/iptables
## Force DNS (in this Case [OpenDNS](http://www.opendns.com/))
$IPTABLES -t nat -D OUTPUT -p tcp --dport 53 -j DNAT --to-destination 208.67.222.222:53 || true
$IPTABLES -t nat -D OUTPUT -p udp --dport 53 -j DNAT --to-destination 208.67.222.222:53 || true
$IPTABLES -t nat -I OUTPUT -p tcp --dport 53 -j DNAT --to-destination 208.67.222.222:53
$IPTABLES -t nat -I OUTPUT -p udp --dport 53 -j DNAT --to-destination 208.67.222.222:53
# Deny IPv6 only connections
$IP6TABLES -P INPUT DROP
$IP6TABLES -P OUTPUT DROP
#
# Google
$IPTABLES -A "afwall" --destination "8.8.8.8/32" -j "afwall-reject" || exit
$IPTABLES -A "afwall" --destination "8.8.4.4/32" -j "afwall-reject" || exit
$IPTABLES -A "afwall" --destination "64.233.0.0/16" -j "afwall-reject" || exit
$IPTABLES -A "afwall" --destination "66.102.0.0/16" -j "afwall-reject" || exit
$IPTABLES -A "afwall" --destination "66.249.0.0/16" -j "afwall-reject" || exit
$IPTABLES -A "afwall" --destination "72.14.0.0/16" -j "afwall-reject" || exit
$IPTABLES -A "afwall" --destination "74.125.0.0/16" -j "afwall-reject" || exit
$IPTABLES -A "afwall" --destination "173.194.0.0/16" -j "afwall-reject" || exit
$IPTABLES -A "afwall" --destination "209.85.0.0/16" -j "afwall-reject" || exit
$IPTABLES -A "afwall" --destination "216.239.0.0/16" -j "afwall-reject" || exit
#
# Others
$IPTABLES -A "afwall" --destination "23.4.92.33/32" -j "afwall-reject" || exit
$IPTABLES -A "afwall" --destination "23.32.0.0/11" -j "afwall-reject" || exit
$IPTABLES -A "afwall" --destination "23.64.0.0/14" -j "afwall-reject" || exit
$IPTABLES -A "afwall" --destination "23.253.56.120/32" -j "afwall-reject" || exit
$IPTABLES -A "afwall" --destination "64.207.128.0/18" -j "afwall-reject" || exit
$IPTABLES -A "afwall" --destination "68.232.32.0/20" -j "afwall-reject" || exit
$IPTABLES -A "afwall" --destination "91.103.140.0/24" -j "afwall-reject" || exit
$IPTABLES -A "afwall" --destination "104.16.0.0/12" -j "afwall-reject" || exit
$IPTABLES -A "afwall" --destination "104.64.0.0/10" -j "afwall-reject" || exit
$IPTABLES -A "afwall" --destination "116.214.0.0/16" -j "afwall-reject" || exit
$IPTABLES -A "afwall" --destination "118.214.0.0/16" -j "afwall-reject" || exit
$IPTABLES -A "afwall" --destination "198.232.125.88/32" -j "afwall-reject" || exit
#
# Turla
$IPTABLES -A "afwall" --destination "80.248.65.183/32" -j "afwall-reject" || exit
#
# Google
$IPTABLES -I INPUT -s 8.8.8.8/32 -j DROP || exit
$IPTABLES -I INPUT -s 8.8.4.4/32 -j DROP || exit
$IPTABLES -I INPUT -s 64.233.0.0/16 -j DROP || exit
$IPTABLES -I INPUT -s 66.102.0.0/16 -j DROP || exit
$IPTABLES -I INPUT -s 66.249.0.0/16 -j DROP || exit
$IPTABLES -I INPUT -s 72.14.0.0/16 -j DROP || exit
$IPTABLES -I INPUT -s 74.125.0.0/16 -j DROP || exit
$IPTABLES -I INPUT -s 173.194.0.0/16 -j DROP || exit
$IPTABLES -I INPUT -s 209.85.0.0/16 -j DROP || exit
$IPTABLES -I INPUT -s 216.239.0.0/16 -j DROP || exit
#
# Others
$IPTABLES -I INPUT -s 23.4.92.33/32 -j DROP || exit
$IPTABLES -I INPUT -s 23.32.0.0/11 -j DROP || exit
$IPTABLES -I INPUT -s 23.64.0.0/14 -j DROP || exit
$IPTABLES -I INPUT -s 23.253.56.120/32 -j DROP || exit
$IPTABLES -I INPUT -s 64.207.128.0/18 -j DROP || exit
$IPTABLES -I INPUT -s 68.232.32.0/20 -j DROP || exit
$IPTABLES -I INPUT -s 91.103.140.0/24 -j DROP || exit
$IPTABLES -I INPUT -s 104.16.0.0/12 -j DROP || exit
$IPTABLES -I INPUT -s 104.64.0.0/10 -j DROP || exit
$IPTABLES -I INPUT -s 116.214.0.0/16 -j DROP || exit
$IPTABLES -I INPUT -s 118.214.0.0/16 -j DROP || exit
$IPTABLES -I INPUT -s 198.232.125.88/32 -j DROP || exit
#
# Turla
$IPTABLES -I INPUT -s 80.248.65.183/32 -j DROP || exit
If you decide to use this script paste it in a good editor like Note Pad Plus. Then add you own values and don't forget to set the EOL conversion (found in the edit menu on the toolbar) to Unix/OSX format.
If you want to do it directly from your device look back at part six, I've put a link to a Text Editor app.
Bear in mind that by using it you will prevent google from accessing your phone, so google related web sites (youtube, blogspot, google search, play store etc.) won't work anymore.
Now it's up to you, if you want google access you'll have to erase the lines under #google (both inbound and outbound).
If you want to check where an IP adress belongs go to :
http://whois.domaintools.com/ (I like this one the most cuz it shows you the IP range to block)
http://www.hcidata.info/host2ip.htm
Want more?
Check here (credits @ukanth and @CHEF-KOCH ) :
https://github.com/ukanth/afwall/wiki/CustomScripts
.
While you're at it change the DNS in the system/etc/resolv.config file to Open DNS or whatever you wish (if you don't use Open DNS then edit the beginning of this script accordingly), and do the same for system/etc/dhcpd/dhcpd-hooks/20-dns.conf.
Note to Kit Kat users, credits @Primokorn :
On Nexus 5 - Kitkat 4.4.4 - I do not have the first file (resolv.config). At the end, I downloaded an app called DNS forwarder by Evan He (read the description for more details especially the information for KitKat users).
OpenDNS has been successfully tested through this URL: https://store.opendns.com/settings/
To check whether you are using Open DNS or not you'll have to enable cookies.
If you still see unwanted connections despite the Firewall check posts #71 and #72, big thanks to @optimumpro for the tip!
To stop the DNS resolve of, and HTTP request to clients3.google.com on every connection to any Wifi Access Point open your android terminal and type :
su -c "settings put global captive_portal_server 127.0.0.1"
su -c "settings put global captive_portal_detection_enabled 0"
To stop the resolve/request for 2.android.pool.ntp.org on every boot (even with network time disabled) type :
su -c "settings put global ntp_server 127.0.0.1"
(credits https://blog.torproject.org/)
- Eighth
Install a good host file in system/etc, it will block adds and unwanted web sites.
Check this link about MoaAB (Mother of All Ad Blocking), credits to @BSDgeek_Jake :
http://forum.xda-developers.com/showthread.php?t=1916098
You can add the following web adresses to whatever host file you decide to use, I have hand picked them one by one (but as above, don't forget to set the EOL conversion to Unix/OSX format):
127.0.0.1 localhost
::1 localhost
127.0.0.1 apis.google.com
127.0.0.1 ajax.googleapis.com
127.0.0.1 www.googletagservices.com
127.0.0.1...51-0-107.deploy.static.akamaitechnologies.com
127.0.0.1 a23-51-0-107.deploy.static.akamaitechnologies.com
127.0.0.1 pa-in-f109.1e100.net
127.0.0.1 pd-in-f109.1e100.net
127.0.0.1 sin04s02-in-f30.1e100.net
127.0.0.1 sin04s01-in-f30.1e100.net
127.0.0.1 sin01s14-in-f30.1e100.net
127.0.0.1 sin01s14-in-f1.1e100.net
127.0.0.1 sa-in-f95.1e100.net
127.0.0.1 2.android.pool.ntp.org
127.0.0.1 174.37.231.83-static.reverse.softlayer.com
127.0.0.1 208.43.122.142-static.reverse.softlayer.com
127.0.0.1 50.22.240.168-static.reverse.softlayer.com
127.0.0.1 108.168.180.116-static.reverse.softlayer.com
127.0.0.1 mqtt-shv-10-frc1.facebook.com
127.0.0.1 mqtt-shv-13-prn1.facebook.com
127.0.0.1 mqtt-shv-08-prn2.facebook.com
127.0.0.1 mqtt-shv-06-frc1.facebook.com
127.0.0.1 mqtt-shv-06-ash2.facebook.com
127.0.0.1 mqtt-shv-04-ash3.facebook.com
127.0.0.1 74-82-89-154.rdns.blackberry.net
127.0.0.1 74-82-91-166.rdns.blackberry.net
127.0.0.1 74-82-93-25.rdns.blackberry.net
127.0.0.1 74-82-93-39.rdns.blackberry.net
127.0.0.1 ec2-54-227-243-121.compute-1.amazonaws.com
127.0.0.1 ec2-54-235-74-151.compute-1.amazonaws.com
127.0.0.1 r-199-59-150-46.twttr.com
127.0.0.1 en.mywebzines.com
127.0.0.1 pnsen.dolphin-browser.com
127.0.0.1 tracken.dolphin-browser.com
127.0.0.1 jekyll.ispgateway.de
127.0.0.1 amazonaws.com
127.0.0.1 ads.yahoo.com
127.0.0.1 geo.query.yahoo.com
127.0.0.1 ucs.query.yahoo.com
If you restrict all those adresses you won't be able to connect to facebook, twitter and any google service (including youtube, blogspot, google search, play store) anymore, so filter first and remove the web sites you want to be able to access.
- Ninth
Open Network Log and connect to the internet.
Check all your connections (long press on an IP to know which web site it refers to, or check with the web sites I mentionned in part 7), some are legit, some are not.
Block the unwanted stuff using either the host file, or the firewall script, or both.
There's an apk called Blockit! that can help you find host names for some stubborn web sites that can't be blocked using their IP, and whose host name can't be found otherwise (like apis.google.com, ajax.googleapis.com, www.googletagservices.com, fonts.googleapis.com, google-public-dns-a.google.com, just to name a few that I found thanks to BlockIt!).
About one year ago I found out that my kernel was connecting to some google related IPs and to google's DNS (eventhough I had set the phone to use Open DNS in the resolv.conf file, eventhough I had removed over 150 system apps and eventhough I was already using AF+Firewall, App Settings and Xprivacy), and that my android system was calling home (read "at google's central office in Mountain View, California") everytime I connected (note that my phone had never been linked to any google account whatsoever).
From that day that I started to gather informations about host files and firewall scripts...
- Tenth
Open SQ Editor, and have a look at your apps' databases.
If you find anythig you dislike, erase it (it's located in data/data/yourappname/databases).
Some files, like google analytics or gaClientid, reappear once the app is reopened again, in this case you have to set their perms to 000 and fully erase their content (like this the files are still there and don't get recreated, but they are inactive).
You may have to suppress the write permissions on the folder that contains those files (use you file manager), ie something like rx, rx, x (5, 5, 1).
Some other potentially unwanted files could be in data/data/yourappname/files or in data/data/yourappname/shared_prefs, if that's the case do as above.
III - ADVANCED- I'll deliberately stay vague on those matters, only people that know what they are doing should mess with that kind of stuff. -
1- Decompile some of your system apps and some of your jars, and track lines refering to specific websites and DNS.
For a starter have a look at SecSystem.apk, framework.jar and framework2.jar...
2 - Xprivacy is a fantastic tool, but due to android limitations it can't restrict ids for the android system.
Have tou ever heard of android.id, build.serial, ro.boot.serialno, ro.serialno etc.?
And what about the serial_no and the mac in the efs folder? And the cpu info in proc? And the serial_number in sys?
Those are ids specific to your device and of course they identify you, that's what they are meant for!
An example, have a look at the wpa_supplicant.conf localised in data/misc/wifi. You'll see that it has your serial_number which means, and experts please correct me if I am wrong, that everytime you connect on the WIFI your serial_number gets sent.
You want to change it manually?
Yeah sure, edit it directly from the file. Now start you wifi and check again the serial_number, you are back to the original value.:cyclops:
I'm not sure whether, if your firewall script is well done and if Xprivacy has been well configured (read "VERY restrictively configured"), those ids leaks or not, but since I like to have more than one protection layer I've edited all of them.
Some ids are easily changed using the setprop command (with an android terminal) or the setpropex command (I've attached it at the end of this post, unzip it and depending your configuration put it in system/bin or system/xbin, and chmod it rwx, rx, rx or 7, 5, 5. Credits @goroh_kun -- http://forum.xda-developers.com/showthread.php?t=1201657 ). Then make an init.d script like:
#!/system/bin/sh
/system/xbin/setpropex ro.boot.serialno 1
/system/xbin/setpropex ro.serialno 1
echo 1 > /sys/devices/virtual/android_usb/android0/iSerial
echo 1 > /sys/devices/cpaccess/cpaccess0/cp_rw
echo 00000001 > /sys/devices/platform/wcnss_wlan.0/serial_number
(the last one will take care of the WIFI's serial_number I spoke about few lines above),
some will require editing in the efs folder (potentially dangerous, so back it up first!), and some will require boot.img tweaks, but I won't explain any further since as written above only people knowing what they do should play with that stuff.
IV – BASEBAND ISOLATIONThat's an important subject and here's an interesting link to start with :
https://blog.torproject.org/blog/mis...ty-and-privacy
You can uninstall STK.apk, LogsProvider.apk, CSC.apk, SecContacts.apk, SecContactsProvider.apk, SecPhone.apk and SecTelephonyProvider.apk altogether, problem solved, your phone isn't a phone anymore (obviously) but a WIFI only device.
Or, you can buy a WIFI only device and save some money compared to a GSM device.
As for me I solved the matter by uninstalling STK.apk, LogsProvider.apk, CSC.apk, SecContacts.apk and SecContactsProvider.apk, and by chmoding SecPhone.apk's and SecTelephonyProvider.apk's permissions to 000 in order to completely disables them (which is not the case when one freeze them, or when one uses the pm command, the apps are ineffective in the way that the user can't use them but they are on nevertheless). Then, I made a chmod 644/000 script to enable/disable them, done!
Of course it's not very practical, and if one only uses one's phone to call one's mum or one's girlfriend/boyfriend there's no need to turn to such extreme safety measures.
But if one lives in a rogue country and if one could be put in danger because of one's phone then it's something that one has to consider.
Otherwise, if you don't want anyone to know that you are using that phone then use a public phone, because whatever we do our provider allways knows who we are calling, for how long etc., everytime we use the phone functions, and AFAIK there's no way to prevent that. Except maybe by using those apps that encrypt communications but I can't comment on that since I don't use my phone to call or to text.
Well, the thing is that if security really matters you shouldn't have a GSM device but a WIFi only device, or a GSM device where STK.apk, LogsProvider.apk, CSC.apk, SecContacts.apk, SecContactsProvider.apk, SecPhone.apk and SecTelephonyProvider.apk have been uninstalled, the above link leading to Tor project's blog explains well why.
One more thing, have you ever heard about IMSI catcher AKA fake cell towers? Here's a very interesting project that deals with it :
http://forum.xda-developers.com/showthread.php?t=1422969
Oh yeah, you may like that one too :
http://www.wired.com/2014/10/verizons-perma-cookie/
ANDROID 5.0 (Lollipop)
Xposed is not yet compatible with ART, so no Xprivacy and no App Settings.
App Settings can be replaced by Permissions Denied Pro (paid), but make sure it's Lollipop compatible :
https://play.google.com/store/apps/details?id=com.stericson.permissions.donate&hl=en
Sorry for the play store link but that's the only non warez site I found about that app. If you want to purchase it you don't need to go through the play store though, just contact its dev and pay him with Pay Pal :
[email protected]
It's a powerfull app so before to start using it read its FAQ (when in the app swipe to the right until you get to it) and remember that you have to unlock permissions before you flash a new OS. Otherwise you may have a powerful bootloop, it happened to me once and believe me it wasn't funny.
You can use the settings examples I put for App Settings (in the second chapter part 4) since Permissions Denied works more or less the same way.
It's a bit more tricky, if doable at all, to replace Xprivacy. Have a look at Donkey Guard, its dev said that he will make it Cydia substrate compatible but I'm not sure he managed :
http://forum.xda-developers.com/xposed/modules/app-donkeyguard-security-management-t2831556
Alternatively, see if Pdroid is Lollipop compatible but AFAIK it isn't.
As for me I'll stay away from Lollipop, at least for now...
A FEW WORDS ABOUT COMMON SENSEStick to older Android versions, like 4.1 or 4.2.
From 4.2 google has strengthned its grip on Android, and added some very unpleasant stuff.
In 4.2 it added FusedLocation.apk, to know better where you are, basically a spying app eventhough google calls it an “enhancement”.
That apk can neither be uninstalled nor be frozen (or well, it actually can but then the phone doesn't boot), but fortunately its receivers can be desactivated with Rom Toolbox and it can be greenified.
In Kit Kat it got worse, you will understand by yourself when you start uninstalling system apps and/or when you have a look at what's inside the system folder.
As I already said in the first chapter, you have to ask yourself whether you want to compromise your privacy to get the latest gimmick and the latest fancy color (that have anyway been made available on JB with Xposed modules) or whether you want to be safe.
Forget about Kit Kat, I think the game is worth the candle but it's up to you...
Do not trust too much encryption and do not store sensitive data in your phone. If you have sensitive data keep it on an usb stick, or a hard disk, the idea is to have it on a support that is not web connected.
Do not link your phone with any account, and don't use apps like facebook, twitter etc... Access those web sites from your browser , and greenify your browser once done.
Use Tor to secure your IP, your operator will know that you use Tor but it won't know anything else.
Depending what you do, where you live or travel and who you are you may consider to have two phones, a secured one for your sensitive activities, and an insecure one to call mum.
Do not update your apps blindly, not all updates bring improvements. Sometimes they add more permissions and/or adds, sometimes the app got sold to a company and policies have changed, you see what I mean. So before you update make a backup of the current app's version, in case you want to get back to it later.
CREDITS AND THANKS
@rovo89 for Xposed, respect!
@M66B for the Xprivacy, respect!
@Tungstwenty for App Settings, Master Key Dual Fix, Fake ID Fix, respect!
@Chainfire for Super Su, respect!
@ukanth for AF+Firewall, respect!
@oasisfeng for Greenify, respect!
@THE Tor Project Team, respect!
@f-droid, respect!
@all the XDA people writing tutorials and sharing their knowledge, respect!
Did I forget anyone? If that's the case be insured that it was absolutely unintentionnal, send me a PM and I'll fix it
Last but not least, all those devs and groups have spent days, if not weeks or even months, coding, writing, tweaking, modding, in a word working, for us to enjoy better security on our devices.
They did it for free, in a materialistic, greedy and selfish world where gratuitousness and altruism are an oddity, so the least we can do is to support them.
Please consider sending them a donation, or buying the pro version/license of their app (s), we are talking about a few dollars which is not much compared to what they have given, are giving, and will give to us.
Remember that we are nothing, or let's say not much, without them!!!
Thanks in advance for them...
LINKS
http://repo.xposed.info/module/de.robv.android.xposed.installer]
https://github.com/M66B/XPrivacy#xprivacy
https://f-droid.org/repository/browse/
https://github.com/ukanth/afwall
http://forum.xda-developers.com/apps/greenify
https://www.torproject.org/
https://blog.torproject.org/
https://guardianproject.info/
https://prism-break.org/en/
CONCLUSIONThat's all what I can remember for now and that's it, my phone works fine...
An additional plus is that while in standby battery decrease is only 1% every 10-12 hours, it doesn't hurt
If all of the above has been done I don't think that anyone can get much data out of your phone, but I'm no security expert and I'd like to hear what the big guys on this forum have to say on that matter....
Feel free to add any settings, tips and tricks you have, thanks in advance:good:
Posts can't be more than 30000 words long, and since both post #1 and post #2 have reached that limit I have to put the last updates to OP here.
Sorry for the mess:silly:.
(Continued from the end of 'Safe To remove Apps" in Chapter I)
Before to proceed copy your system/etc/permissions, system/framework and system/lib somewhere safe, make sure you have aroma file manager ready at hand, and that you have a backup of your system.
Safe to remove jars in system/framework :
access.control.jar
allshare.jar
allshareJmDNS.jar
android.test.runner.jar
bmgr.jar (backup manager)
browsermanagement.jar
bu.jar
cneapiclient.jar
com.android.future.usb.accessory.jar
com.android.location.provider.jar (if you remove this jar then FusedLocation.apk will force close when the phone boots, greenify once the apk and click on the "hibernate all" widget everytime after booting to get rid of the annoyance)
com.android.nfc_extras.jar
com.broadcom.bt.jar
com.broadcom.nfc.jar
com.dropboxpartner.jar
com.google.android.maps.jar
com.google.android.media.effects.jar
com.google.widevine.software.drm.jar
com.quicinc.jar
com.samsung.android.sdk.bt.jar
com.samsung.device.jar
content.jar
CustFeature.jar
GlobalConfig.jar
ime.jar (stock keyboard)
javax.obex.jar
kies_feature.jar
libvtmanagerjar.jar
mmappframeworklib.lib.jar
mms-common.jar
monkey.jar
org.codeaurora.Performance.jar
org.simalliance.openmobileapi.jar
qcmmediaplayer.jar
requestsync.jar
sc.jar
scrollpause.jar
sec_feature.jar
sec_platform_library.jar
seccamera.jar
sechardware.jar
secmediarecorder.jar
secosp.jar
services-ext.jar
settings.jar
smartfaceservice.jar
smartfaceserviceapi.jar
smatlib.jar
stayrotation.jar
svc.jar
svi.jar
sws.jar
uiautomator.jar
videowall.jar
After you're done don't forget to wipe the dalvik-cache.
Bear in mind that it works for me cuz I removed nearly all the stock apps, but depending on your phone configuration you may have to keep more jars.
For example, the stock keyboard would probably not work anymore if ime.jar is gone, same story with the stock camera if seccamera.jar has been deleted.
The same applies to other apps and functionalities, but the good news is that most jars are self explanatory.
Safe to remove xmls in system/etc/permissions :
access.control.xml
allshare_library.xml
allshareJmDNS_library.xml
android.hardware.nfc.xml
android.hardware.wifi.direct.xml
android.software.live_wallpaper.xml
android.software.sip.voip.xml
com.android.location.provider.xml (warning, to remove this xml you'll need to mod FusedLocation.apk in order to force it not to need the xml anymore)
com.android.nfc_extras.xml
com.broadcom.nfc.xml
com.google.android.media.effects.xml
com.google.widevine.software.drm.xml
com.samsung.android.sdk.bt.xml
com.samsung.device.xml
com.sec.feature.hovering_ui (accelorometer sensor)
com.sec.feature.irda_service.xml
com.sec.feature.yosemite.xml (accelorometer sensor)
kies_feature_library.xml
mmappframeworklib_library.xml
org.simalliance.openmobileapi.xml
sec_feature.xml (may break the stock FM radio, dunno about third part radios like Spirit)
sec_mdm.xml
seccamera.xml
secmediarecorder.xml (may break the stock FM radio, dunno about third part radios like Spirit)
smartfaceservice.xml
smat_library.xml
svi_library.xml
sws.xml
usb_print2.xml
videowall_library.xml
vtmanager_library.xml
Bear in mind that it works for me cuz I removed nearly all the stock apps, but depending on your phone configuration you may have to keep more xml.
For example, the nfc would probably not work anymore if one of the xmls that have "nfc" in the title is gone, same story for stock camera if seccamera.xml has been deleted (but some third part cameras will still work).
The same applies to other functions, but fear not since most xmls are self explanatory.
Safe to remove files in system/lib :
the whole drm folder
all files that have "google" in it
More files can be removed (about 60 that I tested up to now), but risks to break this or that functionality increase, and since I don't think that many people use such a barebone phone like me I'll pass for now.
If you want to know which libs just tell me and I'll add them.
Miscellaneous :
- The system/etc/cmds folder.
- The system/etc/secure_storage folder.
- The system/etc/videotelephony folder.
- The system/tts folder (unless you use text to speech features).
- The system/usr/srec/en_US folder (unless you use google now's english offline typing features).
- The system/voicebargeindata folder.
- The system/wakeupdata folder
Special cases
Am.jar (Activity Manager)It can be removed, and then something interesting happens:
newly installed root apps can't get super user rights, but root apps that had previously been installed and are in the super su list work as usual.
I'm not 100 % sure, but that could prevent privilege escalation by malicious apps or processes.
Still, be careful and test it only with root apps that you know for sure are safe.
Actually this am.jar works as an activity manager that can be used remotely to start an activity or an app, force stop apps, kill processes, debug, broadcast an intent and more, through adb or directly from within your phone by using a terminal app.
To get an idea about what it can do type in your terminal:
su
am
and see by yourself.
If you are not into playing with such activities and if you don't use adb you won't feel any difference once you disabled am.jar, not to mention that preventing adb operations is one more step towards better security.
There's another am file in system/bin and it works as a trigger to activate am.jar, so disabling/chmoding 000 that system/bin/am prevents am.jar from starting/working without the need to remove am.jar.
Still, I rather take care of both, just to be on the safe side.
I made two scripts.
One to erase/disable the am functionalities (but before to proceed, copy system/framework/am.jar somewhere safe):
#!/system/bin/sh
mount -o remount,rw /system
rm /system/framework/am.jar
chmod 000 /system/bin/am
rm /data/dalvik-cache/[email protected]@[email protected]
One to restore/enable am (make a folder called scripts in your sd, and put am.jar inside):
#!/system/bin/sh
mount -o remount,rw /system
cp /sdcard/scripts/am.jar /system/framework
chmod 0644 /system/framework/am.jar
chmod 0755 /system/bin/am
Pm.jar (Package Manager)
Pm.jar can be removed too, and just like am.jar it has a triggering file located in system/bin. Disabling them will disable the package manager.
This package manager enables apps to be installed/uninstalled, apps' data to be cleared, apps' components to be enabled /disabled, apps' permissions to be granted/revoked and more, through adb or with an Android terminal app.
To know what it can do type :
su
pm
and see by yourself if you think it's worth keeping it or not.
If you don't use adb you won't feel any difference after you disabled pm.jar (you will still be able to install, uninstall and clear data manually) not to mention that preventing adb operations and specially remote installation/uninstallation of apps is pretty important security wise.
Still, you have to bear in mind that apps like Titanium backup, Rom Toolbox or App Settings use pm to freeze apps or disable apps' components and permissions, and for example when pm is desactivated it prevents me from disabling apps receivers/components (like start on boot, factory reset, etc.) with Rom Toolbox.
Not a big deal cuz pm can easily be enabled and disabled, but I report the issue nevertheless in case it happens to somebody else....
In theory, removing pm could enable one to install unsigned apps, which can be useful in some situations (particularly when one needs to edit the android manifest on system apps).
Remember that doing so is dangerous, since any dodggy app could be installed, so be cautious and test it only with system apps and/or apps that you trust.
As said above there's another pm file in system/bin and it works as a trigger to activate pm.jar, so disabling/chmoding 000 that system/bin/pm prevents pm.jar from starting/working without the need to remove pm.jar.
Still, I rather take care of both, just to be on the safe side.
Now, two scripts.
One to erase/disable pm (but before to proceed, copy system/framework/pm.jar somewhere safe):
#!/system/bin/sh
mount -o remount,rw /system
rm /system/framework/pm.jar
chmod 000 /system/bin/pm
rm /data/dalvik-cache/[email protected]@[email protected]
One to restore/enable pm (make a folder called scripts in your sd, and put pm.jar inside):
#!/system/bin/sh
busybox mount -o remount,rw /system
cp /sdcard/scripts/pm.jar /system/framework
chmod 0644 /system/framework/pm.jar
chmod 0755 /system/bin/pm
Disabling adb
This should do the trick :
#!/system/bin/sh
mount -o rw,remount -t rootfs rootfs /
chmod 000 /sbin/adbd
mount -o ro,remount -t rootfs rootfs /
If it doesn't work try this :
#!/system/bin/sh
mount -o remount,rw /system
chmod 000 /system/bin/adb
Safe to remove applets
Applets are like small programms or commands that can be performed by the system, sometimes with root permissions. They are located in system/bin and system/xbin, and this is where the heart of your root beats (su and sh). Some came preinstalled on your phone, others are installed along busybox (those ones are usually symlinked, and bear a different installation date than the stock applets).
We all have different interests and different needs, so here's some documentation in order to help you decide which applets you want to keep and which applets you want to remove (don't forget to make a backup) :
http://busybox.net/downloads/BusyBox.html
To start, you can delete the ones that are nothing but a trigger for framework jars (like am or pm they bear the same name than their framework counterpart, and they are very light, like 100-200 b, since all what's inside is a short command to trigger the jar).
Then, watch out for the ones that have internet access.
I will write more about it, and give some examples, in a few days when I have time...
Disable NFC and Bluetooth
#!/system/bin/sh
mount -o rw,remount -t rootfs rootfs /
chown 0.0 /dev/bcm2079x
chmod 000 /dev/bcm2079x
mount -o ro,remount -t rootfs rootfs /
That will disable NFC (it has to be ran as an init.d script cuz files recreate at each boot), but before to run this script bear in mind that it may be different on your phone. So, go to the /dev folder, see which files have nfc as owner, and edit the script accordingly.
The same applies to the following init.d script that disables bluetooth :
#!/system/bin/sh
mount -o rw,remount -t rootfs rootfs /
chown 0.0 /dev/smd2
chmod 000 /dev/smd2
chown 0.0 /dev/smd3
chmod 000 /dev/smd3
chown 0.0 /dev/smd7
chmod 000 /dev/smd7
chown 0.0 /dev/ttyHS0
chmod 000 /dev/ttyHS0
chown 0.0 /dev/uhid
chmod 000 /dev/uhid
chown 0.0 /dev/uinput
chmod 000 /dev/uinput
rm -r dev/socket/qmux_bluetooth
rm -f persist/.bt_nv.bin
mount -o ro,remount -t rootfs rootfs /
Alternatively, you can run the following once (but again, check that your files match the script and edit if needed):
mount -o remount,rw /system
chmod 000 /system/app/Bluetooth.apk
chmod 000 /system/app/BluetoothTest.apk
chmod 000 /system/etc/bluetooth
chmod 000 /system/etc/bluetooth/audio.conf
chmod 000 /system/etc/bluetooth/auto_pair_devlist.conf
chmod 000 /system/etc/bluetooth/auto_pairing.conf
chmod 000 /system/etc/bluetooth/blacklist.conf
chmod 000 /system/etc/bluetooth/bt_did.conf
chmod 000 /system/etc/bluetooth/bt_secure_manager_app_pub_key
chmod 000 /system/etc/bluetooth/bt_stack.conf
chmod 000 /system/etc/bluetooth/input.conf
chmod 000 /system/etc/bluetooth/iop_bt.db
chmod 000 /system/etc/bluetooth/main.conf
chmod 000 /system/etc/bluetooth/network.conf
chmod 000 /system/etc/permissions/com.samsung.android.sdk.bt.xml
chmod 000 /system/framework/com.broadcom.bt.jar
chmod 000 /system/framework/com.samsung.android.sdk.bt.jar
chmod 000 /system/framework/sec_feature.jar
chmod 000 /system/lib/libbluetooth_jni.so
rm /data/dalvik-cache/[email protected]@[email protected]
rm /data/dalvik-cache/[email protected]@[email protected]
rm /data/dalvik-cache/[email protected]@[email protected]
rm /data/dalvik-cache/[email protected]@[email protected]
rm /data/dalvik-cache/[email protected]@[email protected]
rm -r /data/data/com.android.bluetooth
rm -r /data/data/com.sec.android.app.bluetoothtest
mount -o remount,ro /system
Disable auto start on boot and receivers
Edit as per your needs:
#!/system/bin/sh
/system/bin/pm disable android/com.android.server.BootReceiver
/system/bin/pm disable android/com.android.server.DRMEventReceiver
/system/bin/pm disable android/com.android.server.TimaServiceEventReceiver
/system/bin/pm disable android/android.accounts.ChooseAccountActivity
/system/bin/pm disable android/android.accounts.ChooseAccountTypeActivity
/system/bin/pm disable android/android.accounts.ChooseTypeAndAccountActivity
/system/bin/pm disable android/android.accounts.GrantCredentialsPermissionActivity
/system/bin/pm disable android/android.content.SyncActivityTooManyDeletes
/system/bin/pm disable android/com.android.internal.app.ChooserActivity
/system/bin/pm disable android/com.android.internal.app.DisableCarModeActivity
/system/bin/pm disable android/com.android.internal.app.HeavyWeightSwitcherActivity
/system/bin/pm disable android/com.android.internal.app.NetInitiatedActivity
/system/bin/pm disable android/com.android.internal.app.PlatLogoActivity
/system/bin/pm disable android/com.android.internal.app.ResolverGuideActivity
/system/bin/pm disable android/com.android.internal.os.storage.ExternalStorageFormatter
/system/bin/pm disable android/com.android.server.DrmEventService
/system/bin/pm disable android/com.android.server.MasterClearReceiver
/system/bin/pm disable android/com.android.server.ShutdownActivity
/system/bin/pm disable android/com.android.server.TimaService
/system/bin/pm disable android/com.android.server.updates.CertPinInstallReceiver
/system/bin/pm disable android/com.android.server.updates.SmsShortCodesInstallReceiver
/system/bin/pm disable android/com.android.server.wifi_offload.AppRunnOverWifiDialog
/system/bin/pm disable android/com.carrieriq.iqagent.service.IQService
/system/bin/pm disable android/com.carrieriq.iqagent.service.receivers.EnableToggleImpl
/system/bin/pm disable android/com.carrieriq.iqagent.service.ui.ShowMessage
/system/bin/pm disable android/com.carrieriq.iqagent.service.ui.UserPage
/system/bin/pm disable android/com.carrieriq.iqagent.stdmetrics.survey.android.QuestionnaireActivity
/system/bin/pm disable android/com.carrieriq.iqagent.stdmetrics.survey.android.QuestionnaireLaunchActivity
/system/bin/pm disable ccc71.at.free/ccc71.at.receivers.phone.at_boot_receiver
/system/bin/pm disable ccc71.at.free/ccc71.at.receivers.phone.at_boot_script_receiver
/system/bin/pm disable ccc71.at.free/ccc71.at.receivers.phone.at_sd_link_receiver
/system/bin/pm disable ccc71.at.free/ccc71.at.receivers.phone.at_battery_plug_receiver
/system/bin/pm disable ccc71.at.free/ccc71.at.receivers.phone.at_battery_unplug_receiver
/system/bin/pm disable ccc71.at.free/ccc71.at.receivers.phone.at_media_receiver
/system/bin/pm disable de.esoco.android.clipboard/de.esoco.android.clipboard.ClipNoteBroadcastReceiver
/system/bin/pm disable com.jb.mms/com.jb.mms.transaction.MmsSystemEventReceiver
/system/bin/pm disable com.jb.mms/com.jb.mms.transaction.SmsReceiver
/system/bin/pm disable com.jb.mms/com.jb.mms.transaction.MmsSystemEventReceiver
/system/bin/pm disable com.jb.mms/com.jb.mms.ui.security.StartSecurityReceiver
/system/bin/pm disable com.ceco.gm2.gravitybox/com.ceco.gm2.gravitybox.BootCompletedReceiver
/system/bin/pm disable com.oasisfeng.greenify/com.oasisfeng.greenify.Startup
/system/bin/pm disable android/com.carrieriq.iqagent.service.receivers.BootCompletedReceiver
/system/bin/pm disable com.lostnet.fw.free/com.lostnet.fw.AutostartReceiver
/system/bin/pm disable com.googlecode.networklog/com.googlecode.networklog.BootCompletedReceiver
/system/bin/pm disable org.torproject.android/org.torproject.android.OnBootReceiver
/system/bin/pm disable org.palemoon.mobile/org.mozilla.gecko.background.announcements.AnnouncementsBroadcastReceiver
/system/bin/pm disable org.palemoon.mobile/org.mozilla.gecko.background.healthreport.upload.HealthReportBroadcastReceiver
/system/bin/pm disable eu.chainfire.pryfi/eu.chainfire.pryfi.BackgroundServiceReceiver
/system/bin/pm disable com.android.settings/com.android.settings.accounts.AccountReceiver
/system/bin/pm disable com.android.settings/com.android.settings.accounts.AddAccountSettings
/system/bin/pm disable com.android.settings/com.android.settings.accounts.ChooseAccountActivity
/system/bin/pm disable com.android.settings/com.android.settings.accounts.SyncSettingsActivity
/system/bin/pm disable com.android.settings/com.android.settings.wifi.WifiStatusReceiver
/system/bin/pm disable com.android.settings/com.android.settings.nearby.MountReceiver
/system/bin/pm disable com.android.settings/com.android.settings.SettingsIntentReceiver
/system/bin/pm disable com.android.settings/com.android.settings.powersavingmode.PowerNotiReceiver
/system/bin/pm disable com.android.settings/com.android.settings.nfc.SBeamStateReceiver
/system/bin/pm disable com.android.settings/com.android.settings.dormantmode.DormantModeNotiReceiver
/system/bin/pm disable com.android.settings/com.android.settings.ethernet.EthernetConfigure
/system/bin/pm disable com.android.settings/com.android.settings.ethernet.EthernetEnabler
/system/bin/pm disable com.android.settings/com.android.settings.EthernetSettings
/system/bin/pm disable com.android.settings/com.android.settings.FactoryResetBroadcastReceiver
/system/bin/pm disable com.android.settings/com.android.settings.FactoryResetDialog
/system/bin/pm disable com.android.settings/com.android.settings.KiesLocationReceiver
/system/bin/pm disable com.android.settings/com.android.settings.MasterClearModemReset
/system/bin/pm disable com.android.settings/com.android.settings.MediaFormat
/system/bin/pm disable com.android.settings/com.android.settings.MediaFormatSd
/system/bin/pm disable com.android.settings/com.android.settings.nearby.NearbySettings
/system/bin/pm disable com.android.settings/com.android.settings.nfc.NfcGateReceiver
/system/bin/pm disable com.android.settings/com.android.settings.UsageStats
/system/bin/pm disable com.android.settings/com.android.settings.UsbSettings
/system/bin/pm disable com.android.settings/com.android.settings.UserDictionarySettings
/system/bin/pm disable com.android.settings/com.android.settings.XmlBackup
/system/bin/pm disable com.android.settings/com.samsung.wfd.WFDSourceService
/system/bin/pm disable com.sec.android.app.controlpanel/com.sec.android.app.controlpanel.PackageIntentReceiver
/system/bin/pm disable com.keramidas.TitaniumBackup/com.keramidas.TitaniumBackup.schedules.BootReceiver
/system/bin/pm disable com.vipercn.viper4android_v2/com.vipercn.viper4android_v2.receiver.BootCompletedReceiver
/system/bin/pm disable com.vipercn.viper4android.xhifi/com.vipercn.viper4android.xhifi.receiver.BootCompletedReceiver
Upgrading to later Android versions?
Some people say that later Android versions are "safer" cuz vulnerabilities have been patched?
Nice one, that's what google and his friends want you to believe.
Like this you will jump on new versions as soon as you can, and they will tighten the knot.
Most vulnerabilities (except one or two) only work if one has installed a doddgy app, or has had a nasty app installed remotely hence the importance to disable pm, or opened a nasty sms through WAP push (WAP is anyway uninstalled if one has followed OP).
If you are the type of guy that installs apps from shaddy sources, and that clicks on any link on any sms that promises to increase your d...k's size to 25 inches then I agree, you should stick to later Android versions.
But as for me I'm not that type of guy, and anyway, what are those bad apps using those vulnerabilities we are talking about?
They are a few nasty bits, flooded amongst millions of Android apps on board over one billion Android devices, and those nasty bits account for something like 0.01% (even less if you only installs from trusted sources and don't click on 25 inches offer sms').
OTOH, google's tracking on Android is on 100 % of newly bought smartphones and wifi tablets, and its tracking becomes more and more sophisticated and harder and harder to remove as the Android version rises (it started with 4.2 and got much worse with 4.4).
Now think a bit, what kind of risk are you willy to take with your phone?
Still undecise? I don't have too much time to search the net about it, but since I'm a good uncle here's a link to start with:
http://www.greenbot.com/article/214...-is-on-android-but-good-luck-catching-it.html
ADDITIONAL LINKS
Wanna read more? Here are two interesting projects you may like (thanks @Froschohnenamen for reminding me of those).
Pri-Fy from @Chainfire, the great master of root:
http://forum.xda-developers.com/showthread.php?t=2631512
NOGAPPS, or how to replace google proprietary stuff with some open source equivalents:
http://forum.xda-developers.com/showthread.php?t=1715375
WIP:
- safe to remove system/framework jars (done),
- safe to remove system/etc/permissions xmls (done),
- safe to remove system/libs (done),
- safe to remove stuff in system/bin and system/xbin (done),
- annihilate bluethooth and nfc (done),
- search the baseband/modem for privacy leaks (started, but still a long way to go). That one will be a hard task, I'm new in that field and most of it is closed. Any help will be very much appreciated, thanks in advance!!!
- 2-3 things more
This is something....
Love the idea! Hope will be able to help!
Just one thought to add, instead of a boot script to delete files, I have a Tasker task which deletes them as soon as the screen turns of
Brilliant !!!
Even people used to (and some still) call me outdated. "You don't beleive in Cloud" "You don't beleive Google" "You think too much. Be cool".
Now many of them come to me to ask how they can secure their data.
Times are surely changing
Subscribed.
I really like the idea of this thread. Now if we could get some other people to chime in. Lately I've been wanting to lock down my note4 as much as possible.
Awesome job! We do see that you know what you are talking about.
A lot of good advice in this guide. One again the help from devs would be appreciated.
Added to my sign
Thanks everybody for your support!!:good:
I've edited the first post and attached a file with some examples of restrictions with App Settings, hope it helps
One again the help from devs would be appreciated.
Click to expand...
Click to collapse
Yep...
Added to my sign
Click to expand...
Click to collapse
Thanks mate!
Where are the DEVs and SECURITY experts?
It seems that DEVs and SECURITY experts are avoiding this thread! Why? Did this thread smell? Or it's not worth your DEVs capabilities? Hmmm
Subscribed :good:
On a side note, I guess it would be a good thing to mention MoaAB for the host file part.
Even if it's written in the Github of XPrivacy it's worth to mention it here (to avoid any leak of data during the process): How to update Xprivacy? & Procedure to update a ROM
The host file I put in OP has been carefully hand picked by unclefab, but hey, he's getting old the poor fella and he had forgotten to mention MoaAB:silly:
Thanks for remembering him, link to MoaAB thread added in the host section on the second post:good:
I'm learning how AFwall+ works. Regarding Turla (https://securelist.com/blog/research/67962/the-penquin-turla-2/ & http://arstechnica.com/security/201...x-trojan-may-have-infected-victims-for-years/) how you block the below DNS IP?
Hardcoded C&C, known Turla activity: news-bbc.podzone[.]org
The domain has the following pDNS IP: 80.248.65.183
Click to expand...
Click to collapse
Just add this in your script (there are other ways, with the "OUTPUT" command for instance, but at the end of the day it does the same):
#
# Turla outbound
$IPTABLES -A "afwall" --destination "80.248.65.183/32" -j "afwall-reject" || exit
#
# Turla inbound
$IPTABLES -I INPUT -s 80.248.65.183/32 -j DROP || exit
I've updated the script in OP with the above lines, and I added the following address (credits @ukanth and @CHEF-KOCH ) for anyone that wants to learn more about firewall scripts:
https://github.com/ukanth/afwall/wiki/CustomScripts
I've added the credits as well, I don't know why but I had forgotten to put them, I'm really getting old:silly:
unclefab said:
Just add this in your script (there are other ways, with the "OUTPUT" command for instance, but at the end of the day it does the same):
#
# Turla outbound
$IPTABLES -A "afwall" --destination "80.248.65.183/32" -j "afwall-reject" || exit
#
# Turla inbound
$IPTABLES -I INPUT -s 80.248.65.183/32 -j DROP || exit
I've updated the script in OP with the above lines, and I added the following address (credits @ukanth and @CHEF-KOCH ) for anyone that wants to learn more about firewall scripts:
https://github.com/ukanth/afwall/wiki/CustomScripts
I've added the credits as well, I don't know why but I had forgotten to put them, I'm really getting old:silly:
Click to expand...
Click to collapse
Ok, done.
It is very inconvenient to enter a custom script from within AF+, we can't scroll the lines. I don't know a good app (like Notepad+ on PC) to create a custom .sh file from my phone so I'll have to do it from my PC.
I use that one, it has all what we need:
http://920-text-editor.en.uptodown.com/android
While I'm at it I'll add it to OP...
unclefab said:
Just add this in your script (there are other ways, with the "OUTPUT" command for instance, but at the end of the day it does the same):
#
# Turla outbound
$IPTABLES -A "afwall" --destination "80.248.65.183/32" -j "afwall-reject" || exit
#
# Turla inbound
$IPTABLES -I INPUT -s 80.248.65.183/32 -j DROP || exit
Click to expand...
Click to collapse
I get "error applying IP tables rules" and AFWall+ becomes disabled.
Using these two lines works.
iptables -I INPUT -s 80.248.65.183 -j DROP
iptables -A OUTPUT -s 80.248.65.183 -j DROP
If you get "error applying IP tables rules" and AFWall+ gets disabled it means that there's something wrong in the way the script has been written (on my device it works fine).
It could be that the EOL converson has not been set to Linux/Android, or it could be that when you copied pasted a quotation mark ( " ) or a line break got lost, or something else in the same style.
Anyway, if it works with OUTPUT don't bother, the important is to have it to work, right?
Actually when I first wrote this script I only made it outbound, using "afwall" --destination "whatever IP" -j "afwall-reject" || exit.
Then I made it inboud and I used INPUT, and I must confess that I didn't change the original outbound part to use OUTPUT instead of "afwall" --destination "whatever IP" -j "afwall-reject || exit", out of pure lazyness. :cyclops:
unclefab said:
Anyway, if it works with OUTPUT don't bother, the important is to have it to work, right?
Actually when I first wrote this script I only made it outbound, using "afwall"
Click to expand...
Click to collapse
Maybe it's because it's now called AFWall+? Or maybe because I didn't do any EOL conversion as my Windows Notepad/Wordpad doesn't have it? I just copy pasted what you posted in this thread. I have no idea about the script. I only added in the IP from the block incoming request example.
But your post #2 is more comprehensive and I can't apply it but maybe I can pick out bits and edit using templates? For example:
Why is this necessary at the beginning of each script? I didn't put it in.
Code:
# Necessary at the beginning of each script!
IP6TABLES=/system/bin/ip6tables
IPTABLES=/system/bin/iptables
What's bad about IPv6 and why do we need to deny IPv6 only connections?
Code:
# Deny IPv6 only connections
$IP6TABLES -P INPUT DROP
$IP6TABLES -P OUTPUT DROP
What are some of those other non google IP destinations that need to be rejected?
P.S. Found the error. It was the line breaks.
I never finished this, please use Launcher Hijacker v3+ as it works much much better!
EDIT 09/23/16
I finally found a permanent solution to how to change fire launcher on the Amazon Fire without root. It works on any version (FireOS 5.3.1) on any tablet variant (7, HD 8, HD 10 etc...).
You can read the detailed tutorial at http://forum.xda-developers.com/ama...-remove-default-launcher-amazon-fire-t3288310 but basically you run one command, must be done after reboot currently via adb shell:
Noval Launcher on Amazon Fire no-root:
Code:
nohup logcat -c; logcat | grep --line-buffered 'flg=0x10200000 cmp=com.amazon.firelauncher/.Launcher' | while read line; do am start com.teslacoilsw.launcher/.NovaLauncher; done &
That's it. Once you paste that into your adb shell you're done; you now have a default launcher programmatically set via ADB.
Optionally, you can install the modded firelauncher.apk so you can finally delete it without root .
(this is optional, you wont have any launcher after doing this! backup your old APK!!)
Code:
adb install -r -d com.amazon.firelauncher.apk
... as you can now see this will -r reinstall and -d downgrade the launcher, causing it to crash and never open.
Thanks for your support guys, I love android!
EDIT:
I have updated with a new method that is much better, the only negative to this new method is when you hit the home button, for a brief moment you see the firelauncher. Performance, speed, and bugs are perfect.
Just paste this code in adb shell, I'm working on setting up nohup to work with it, when you close adb it will stop working.. Going to bed for now though.
Code:
#!/bin/bash
am monitor | while read -r line; do
if [[ $line == *"firelauncher"* ]]
then
am start [B]com.newlauncher.launcher[/B]
fi
done
I'm new to the whole Android scene, and recently I had acquired an Amazon Fire HD 8. The only complaint about this tablet is the lack of Google Play and the horrible firelauncher. There is currently no root options available for the Fire HD modles 8 & 10, so I have spent the time to develop a temporary workaround.
Please take a quick look at the developmental thread I previously created so we can collaborate to make a more efficient version of this:
http://forum.xda-developers.com/hd8...zon-fire-hd-8-10-remove-firelauncher-t3286646
Disclaimer:
If you plan on installing new applications/packages while this script is running you may have a hard time. Installing packages may take 2-10 minutes, or maybe not at all!
If you experience any problems you can undo everything by running the undo script attatched (unix), or by typing "adb shell ps | grep /system/bin/sh", you will see anywhere from 2-10 processes listed. For each type "adb shell kill -9 <pid>", pid would be the process ID, should be the first number you see on each line.
There is a small chance when you press the home button that it will load the regular firelauncher, do not fret, try again and it will go to whichever launcher you previously selected.
Performance may be slightly altered, if it becomes too bad to use try adjusting the script and change the interval at which it loops (set to 20 by default).
This is an alpha experiment, and I am a noob with Android so please bare with me
This is a noobish approach to disabling the firelauncher (com.amazon.firelauncher.apk), please do not judge it, this is also my first time releasing something for Android.
If you are using a unix operating system (like Linux or Mac), I have compiled a script that does the work for you! Windows users will have to wait and do it manually since I am unfamilar with batch (would someone like to help with this?)
Automatic Tool (easy, linux, mac only)
Step One:
Download the two script attachments:
remove_default_launcher.sh - disables amazon's firelauncher
re-endable_firelauncher(undo).sh - reverts the process, if you have any issues
Step Two:
Run the following commands to make the scripts executable:
Code:
chmod +x remove_default_launcher.sh
chmod +x re-endable_firelauncher(undo).sh
Here is a video showing you how to do this next step:
https://www.youtube.com/watch?v=1IVOa048UbY
Run the tool to remove amazon's nasty launcher!
Code:
./remove_default_launcher.sh
Step Three:
The script should automatically do everything, when it's done, check your Fire. Keep pressing the home button and switching between applications until you get the "Change default launcher" dialogue, make sure you have an alternative launcher installed beforehand or else you won't have a launcher! When it's all working how it should be go to step four!
Step Four:
Simply exit out of your terminal window, do not type anything, just exit ADB. The script will continue running!
This is what a successful window looks like, whenever you have confirmed it is working, close out of the ADB window and end that process.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Manually (harder, windows)
Step One:
Open up a new ADB shell window and type
Code:
adb shell
Step Two:
Once you are in the shell window, simply copy and paste this line of code and press return. It is just a simple bash script that loops the command "install -r -d "/system/priv-app/com.amazon.firelauncher/com.amazon.firelauncher.apk"" which will reinstall the firelauncher repeatedly, which temporary uninstalls it.
Code:
#!/system/bin/sh
nohup
while :
do
kill $!
sleep 1 & pm install -r -d "/system/priv-app/com.amazon.firelauncher/com.amazon.firelauncher.apk" & sleep 20; kill $!
kill $!
done &
exit
#press enter now
After pressing enter, you can watch it go to work, or you can close out of the adb window and unplug your device, it will continue to run until you kill the shell processes or reboot the device. Make sure you have an alternative launcher already installed so it can easily be set as default. EDIT: Reboot may not reset it, which is cool but could be annoying. To turn off this wonderful feature open up adb shell and use "ls | grep shell" and kill using "kill <pid>" all releated processes to /bin/shell or whatever. It may take up to a minute to reset.
If you have any issues at all please comment and I will send you a private message with detailed instructions catered to your specific issue!
If you are a dev, take a look at my unix auto-install script, it may help you figure it out yourself as well. I need someone who understands batch to help me write a windows version .
I literally spent about 45 minutes working on this noobish approach, so if you find bugs or want to modify the script, simply post in the comments your version and why you think it is more efficient. If you want to help make a dedicated and more efficient approach to this, check out the development thread here (there are alternative methods here too):
http://forum.xda-developers.com/hd8...zon-fire-hd-8-10-remove-firelauncher-t3286646
This appears to be a very stable system actually, I recommend everyone does this to the Fire HD tablets!
I hope this helps someone, if this helps you please give me a thanks so I know it
Just tried this on my HD 8. Works like a charm! Haven't noticed much of a performance decrease as I figured would happen. On occasions when I press home it likes to hang at a black screen until I press home again. Other than that its perfect. Thanks!
ZenPowerBuilder said:
Just tried this on my HD 8. Works like a charm! Haven't noticed much of a performance decrease as I figured would happen. On occasions when I press home it likes to hang at a black screen until I press home again. Other than that its perfect. Thanks!
Click to expand...
Click to collapse
I am working on a better version, I have noticed some performance issues that irritate me.. I also made the scripts better much better.
I am glad I was able to help you .
I have updated with a new method that is much better, the only negative to this new method is when you hit the home button, for a brief moment you see the firelauncher. Performance, speed, and bugs are perfect.
Just paste this code in adb shell, I'm working on setting up nohup to work with it, when you close adb it will stop working.. Going to bed for now though.
Code:
#!/bin/bash
am monitor | while read -r line; do
if [[ $line == *"firelauncher"* ]]
then
am start [B]com.newlauncher.launcher[/B]
fi
done
nyln said:
I have updated with a new method that is much better, the only negative to this new method is when you hit the home button, for a brief moment you see the firelauncher. Performance, speed, and bugs are perfect.
Just paste this code in adb shell, I'm working on setting up nohup to work with it, when you close adb it will stop working.. Going to bed for now though.
Code:
#!/bin/bash
am monitor | while read -r line; do
if [[ $line == *"firelauncher"* ]]
then
am start [B]com.newlauncher.launcher[/B]
fi
done
Click to expand...
Click to collapse
Has anyone had any luck finding a way to keep this script running? I am experimenting with Python..
I have not had too much time to work on this, but all the puzzle pieces are here if anyone wants to make a permanent solution.
nyln said:
I have not had too much time to work on this, but all the puzzle pieces are here if anyone wants to make a permanent solution.
Click to expand...
Click to collapse
I have used your manual method and during the execution of this process I could with the command "adb shell pm hide com.amazon.firelauncher" the amazon firelauncher set as permanent hidden. After that I could set the Nova Launcher as a standard launcher. As a substitute for home button (was not working) I set in the "overlays app" the Nova launcher as a foreground application. So I can select the foreground Nova launcher symbol as a home replacement. For me is that a good workaround.
schr01 said:
I have used your manual method and during the execution of this process I could with the command "adb shell pm hide com.amazon.firelauncher" the amazon firelauncher set as permanent hidden. After that I could set the Nova Launcher as a standard launcher. As a substitute for home button (was not working) I set in the "overlays app" the Nova launcher as a foreground application. So I can select the foreground Nova launcher symbol as a home replacement. For me is that a good workaround.
Click to expand...
Click to collapse
The package manager requires root or superuser in order to hide/disable the firelauncher package properly. You probably have the 7" model.
nyln said:
The package manager requires root or superuser in order to hide/disable the firelauncher package properly. You probably have the 7" model.
Click to expand...
Click to collapse
That is true, that the package manager requires root or superuser in order to hide/disable the firelauncher package.
But there must be a "time gap" when there is running in a first adb window (task) the following adb shell script
!/system/bin/sh
nohup
while :
do
kill $!
sleep 1 & pm install -r -d "/system/priv-app/com.amazon.firelauncher/com.amazon.firelauncher.apk" & sleep 20; kill $!
kill $!
done &
exit
and in a second adb window (task) is executed the "adb shell pm hide com.amazon.firelauncher" command.
Remark: I must multiple times repeat this command until I get the "TRUE" confirmation.
I has this done on my HD8 ( 5th generation) model. wiht the firmware 5.1.1.
nyln: awesome job!
now i bought this tablet for my son (6 yrs old) and the "child profiles" suck since they do not allow non amazon apps to be shown there. So having the nova launcher is the next best thing since i can hide the apps i dont want him touching. Problem is this if we are out somewhere and an app crashes the tablet, i have no way to get nova back on.
Is there a way to put this script on the tablet and run it that way?
5.1.4?
It is not working on 5.1.4?
XJimmyCaoQ99X said:
It is not working on 5.1.4?
Click to expand...
Click to collapse
You can downgrade to 5.1.2
@nyln can't wait to try this when i get home, can you install widgets on nova launcher now?
Sent from my HTC 10 using XDA Labs
ahac85 said:
@nyln can't wait to try this when i get home, can you install widgets on nova launcher now?
Sent from my HTC 10 using XDA Labs
Click to expand...
Click to collapse
How it actually works:
First of all, corrupting the firelauncher will prevent your system from loading it, which saves memory and cpu resources on these low-end devices. After that, in order to replace the system launcher I actually just intercept the home activity and allow a launcher of your choice to open. So it's really just a clean hack you won't notice. Only downside currently is the fact that it takes about 100ms for your home button to actually take you to the launcher of your choice.
tldr: It should work perfectly normally with widget.
XJimmyCaoQ99X said:
It is not working on 5.1.4?
Click to expand...
Click to collapse
It works on all versions, including 5.1.4. In fact, this will work on ANY device with ANY operating system. If you have 5.1.4 why don't you just root?
Can someone tell me if this works after reboot?
@nyln when i try to execute the script i get "syntax error: 'while' unmatched"
I saved the script to a file on my fire HD 8 and executed it with sh filename.sh, because with adb shell i pasted the text but i couldn't press enter to execute it. It just entered a new line to the script.
Here is how it looks:
aldileon said:
@nyln when i try to execute the script i get "syntax error: 'while' unmatched"
I saved the script to a file on my fire HD 8 and executed it with sh filename.sh, because with adb shell i pasted the text but i couldn't press enter to execute it. It just entered a new line to the script.
Here is how it looks:
Click to expand...
Click to collapse
The image looks good. You may need unix for this or cygwin.
But as i understood, the script runs on the fire tab? So why should it matter what OS I am pushing the script with? Or why should Unix work better than windows?
I'm not totally naive to the command line, nor to customizing android installations. This is my first experience with the Amazon tablets; I have the Fire HD8 6th-gen. I'm running the 5.3.1.1 firmware. I tried entering the command in the top post, entered into a terminal emulator, and it didn't seem to return anything -- no error, no nothing. Still having the same issue; I can run NovaLauncher and it's fine until I get into a different app or hit home, then it goes back to Amazon's junk launcher... am I doing something wrong in the terminal?