I have been toying around a bit with the feature of full phone encryption (not just the apps and data but also the "sdcard" internal storage partition.
Observation 1 (which may or not be known or evident to you already, but which I still find odd): It is possible to encrypt a "full" or half full device, but it seems to be not possible to go and decrypt the device again later on while retaiing the data (assuming the right password of course). Being a long time user of Truecrypt I find this irritating, one could of course argue it is safety measure of some kind, but I really would see no harm in enabling the possibility. As the password would of course be required to get into the system and initiate the decryption process there is no additional risk - if the attacker already has the password he can use it to gain access and copy the plaintexted data someplace else anyways. So is this caused by architecture of the pre boot authorization, just sloppy and careless coding or am I missing something vital here?
Observation 2: The performance impact with encryption enabled is worse than I would have dared to believe. I used two different SD Card Speed measurement apps from the market to test speed on a regular, non-encrypted setup and on an encrypted setup.
{
"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"
}
Encryption enabled
Plaintext operation
All other settings in the apps and the device were identical.
Is this sloppy coding or are the Snapdragon CPU just ill-equipped to handle encryption algorithms efficiently enough? I don't really want to get into a grassroots debate here over how useful encryption may or may not be on a device that most of us want s-off and rooted, therefore allowing all sorts of exploits etc. but I am honestly surprised by the heavy performance hit.
Does anyone know what algorithms are used? I assume some run of the mill AES?
Related
By now, some you have seen reports about the latest bit of under-the-covers eavesdropping, this time by HtcLoggers.apk. In case you haven't, this post on Android Police details the whole thing pretty well.
One thing that really caught my attention was the graphic showing all the different ways various bits of Android snoop on you:
{
"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"
}
Those of us not running HTC software don't have to worry about most of these. The one that remains for all of us, at least according to the research so far, is Google Checkin, part of GoogleServicesFramework.apk. You can see in the graphic what kind of information Checkin collects and where it puts it. I've seen /data/system/dropbox before, occasionally I clear it out because it collects a huge number of files. I hadn't really paid much attention to /data/system/usagestats.
Using Root Explorer, I see that the permissions on both these directories is rwx------. As an experiment, to see if I can block whatever Checkin is collecting, I deleted their contents and then removed all permissions on these directories (and rebooted for good measure). I did this about an hour ago. So far, the directories have remained empty.
My G2 (running ILWT CM7 build 216) appears to be functioning normally, including the Market. If anything malfunctions, I'll report here.
Update. More directories to block: /data/anr, /data/tombstones, /data/dontpanic. File to block: /data/system/userbehavior.db (I first used SQLite Editor to empty the file).
Do not attempt this procedure on /data/system/throttle -- this caused my phone to enter a boot loop, which I had to repair by booting into recovery and then reverting my permissions change through ADB.
Quick follow-up... Looks like removing all permissions on the two directories has no effect on the phone's behavior. I've seen no breakage and the directories remain empty. So if you want to thwart some data collection, this looks like a decent approach.
So now that some time has passed, what is veridict? Were there any averse affects on the phone? Does everything still work?
Still seeing no problems. I did the same thing to my Nook Color, and it's also behaving normally.
This is very interesting, I'll try changing the permissions too.
Updated original post: added a few more directories to block based on additional information reported by the Carrier IQ Logging Test App.
I also gave this a try...
And so far so good! Thanks!
SDCard Watcher
Market Link: https://play.google.com/store/apps/details?id=com.desaster.sdcardwatcher
Description / Reasoning
Anyone who installs a lot of apps will soon find their SDCard cluttered with strange directories that don't seem to relate to any app you know. You could just remove them all, but how do you know which directories are from apps you are still using, and might contain some important data?
Since the sdcard filesystem lacks ownership info, there's really no easy way of knowing which app to blame. This app is my approach to the problem.
Basically the app lets you monitor any chosen directory for changes, and when a new file or directory is created, it checks which app is currently visible to the user, and saves this information in a database. This way, next time some app leaves an obscure directory rotting on your sdcard, you will know exactly which app to blame.
Why should you care?
Actually, you probably shouldn't. The extra bits of data often don't take any significant space on your memory card. However, it irritates me, and this app gives me a bit more of a sense of control. The XDA forum is probably the best place for me to post this app, since I know there are at least a few other like-minded people here who care about tweaking little things like these
Battery usage
The app's background process uses the kernel's inotify feature to catch changes in the filesystem, and thus uses virtually no processing power, and will not drain your battery.
Reliability
There are essentially two ways for an app to run a background service; as a background service, and as a background service with a notification icon. My app supports both ways, but the default is to run without a notification icon.
I am still unsure if android lets the service run reliably enough without the notification icon, so if you think you're missing file changes, I'd love to hear about it. In any case, the notification icon can be enabled in the settings and should help with the issue (should there be an issue).
{
"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"
}
Good day, fellow XDA citizens.
Here's my problem. My phone's external storage cannot be detected by apps when they are browsing as root. See screens:
This is what it looks like when the apps are browsing as root: (i.e. granted su permissions)
{
"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"
}
This is what it looks like when the apps are not browsing as root: (and the way things are supposed to be)
Note that these issues are not limited only to this Script Manager app, but others as well, including Android Tuner, TiB, and the likes (most apps that access the external storage)
I've noticed that fuse in external storage becomes "RO rootfs" when browsing as root, and fuse remains intact for internal storage whether or not it was given su permissions.
I've tried googling around for answers, a few articles and discussions mention fuse but I can't make a certain sense out of them, most likely because I am a scrub on linux usage.
What things can I do to try fix this issue? Any help will be much appreciated.
regards, Ocenyx
SD card not detected
I have Samsung Wave2 GT-s8530. whenever I am installing badadroid on my set whatever the ROM is my external SD card was not detected. it showed 0 MB only. Details of my phone and installation as follows:
Installed at Downloader v5.67
Fat32 is the format of SD card.
Anyone please?
By the way, this phone is running 4.4.2 version of Android. This issue was not present in 4.2.2 before.
To anyone else having this issue,
It seems to be a well-known symptom of Kitkat for MT6582 devices. I'm not certain if this problem exists on any other chip.
While we wait for any official fix for SuperSU app regarding this issue (if any), the only fix I have ever known to have worked is by using KingRoot. I'm aware that many advanced android people always discourage users from installing chinese stuff but it addresses the issue at least. It's much much better than living through this inconvenience.
Regards
FOR ALL ROOTED ROMS
This thread may eventually hold multiple apps related to general tools for the G3. I am happy to take suggestions on future apps that we can all use that we might find interesting. My apps are going to have a simple bare bones layout with no bells or whistles. I can't develop everything in the world but I will give it a try.
TEMPS apk
Temps is simple lightweight app that gives a data readout of all temp sensors within the G3. All data is listed per zone and refreshed every second for an accurate reading. Please don't ask me what each zone designation is. I simply don't know, and its not listed anywhere to my knowledge. The purpose of the app is simply to collect data. Nothing more.
I made it for some testing I was doing and figured maybe somebody else might have a use for it.
[emoji2]
DOWNLOAD
http://d-h.st/0KW
System Sampler application
REQUIREMENTS.
Must be rooted.
Set SeLinux to Permissive.
System Sampler is a tool to allow you to sample data deep in the system. It's great for developers and Android enthusiasts who have an interest what's happening in real time.
FEATURES.
- Adjust sampling time from 1-10 seconds.
- Set file permissions if needed to read data.
- Status bar readout viewable in any screen.
HOW TO USE.
1. Enter the file path in the box located at the top of the screen.
2. Turn on the sampling button.
3. If you are unable to read the file, use the "chmod" button to set file permissions to 777 and try again.
TIPS.
It's much easier to copy and paste the file path using the "getFilePath" application. Get it here..https://play.google.com/store/apps/details?id=net.fro9.android.app.getfilepath
POSSIBLE ISSUES.
This is a beta release!
System Sampler was built on Tasker and has only been tested on my LG G3. That being said, their may be issues with different devices with screen resolutions and the status bar readout.
{
"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"
}
[DOWNLOAD.
Beta version 1
https://www.androidfilehost.com/?fid=23991606952615006
Future
Future2
Future3
This. Is. Major.
So, I have been meaning to create an xda-developers account for a while. And one of the reasons is this - a major security vulnerability potentially usable for data theft.
On all versions of android, If you have root, you can find information for ALL (previously, i think even if you press forget) wifi networks you have connected to. Even by WPS. The same goes for p2p. The file is located in /data/misc/wifi/ and is called wpa_supplicant.conf (p2p_supplicant.conf for p2p). This file contains a lot of sensitive information like the mac addresses, ssid's and passwords/passkeys. Keep in mind that these are ALL entirely unencrypted and are plain text format.
Here is an example of mine:
{
"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"
}
You may be wondering: so this only affects root users?
Well, the answer is no.
An app could perform temporary root and send a copy of the wpa_supplicant.conf file to an attacker
and of course, an ordinary user would be none the wiser, for the root would be gone on the next boot up and they would not even have a clue what root is.
I do alot of root projects and it is my passion. This is something I have come across over time. I know this is the case from as far back as android eclair (2.1) to android oreo (8) but dont have an older android device to test it with.
Also, please try to mark this as a helpful post. I think I have made a breakthrough in Htc Wildfire Buzz (and potentially other devices) Network Unlocking via Root, but I cant post it here.
huh? This is not an exploit, if you say so then all the devices running an operating system is potentially exploitable. It all comes down to application's trust and system firewall to prevent this from happening.
Besides you don't need to root/administrator privileges to get MAC ID, wifi password on any operating system.
SpiritBreak3r said:
huh? This is not an exploit, if you say so then all the devices running an operating system is potentially exploitable. It all comes down to application's trust and system firewall to prevent this from happening.
Besides you don't need to root/administrator privileges to get MAC ID, wifi password on any operating system.
Click to expand...
Click to collapse
Ah yes sorry i confused it! Either way, this is major, root or no root