Has anyone been able to get this working with Root? I install fine, enter my pin and it goes through but since I have root it doesnt sync. Im running liberty, any suggestions
matt1313 said:
Has anyone been able to get this working with Root? I install fine, enter my pin and it goes through but since I have root it doesnt sync. Im running liberty, any suggestions
Click to expand...
Click to collapse
Checking for root is configurable by your IT area. My account is not setup to check for root but I have had other problems. Can you easily unroot and reroot your device so Good would work except for the rare times that you actually need root? One problem I have had is the initial setup would never complete (stops at retrieving policies) unless I go back to stock eclair, get it working and back it up via Titanium backup, then upgrade to Froyo or GB, and then restore it. Mine continues to work via root though. The other problem I have had is if I ever restore to an earlier state (using the same PIN), it will stop syncing. I need a new PIN issued to get it working again.
I'm reading that IT admins can lock your phone camera, wipe SD card, etc.
What other kinds of things can they do once "Good for Enterprise" is installed on your personal phone?
Nate2 said:
I'm reading that IT admins can lock your phone camera, wipe SD card, etc.
What other kinds of things can they do once "Good for Enterprise" is installed on your personal phone?
Click to expand...
Click to collapse
I was involved in piloting "Good for Enterprise" for my company. I do know that the possible "controls" vary depending on the platform. Good for Enterprise on the IPhone will have much more control because the devices (hardware) and OS are very limited compared to Android. Keep that in mind as you read some of these items if they don't mention which platform. Also, the Good application would have to be granted root access to your phone "I believe" in order to do any of the items you mentioned. If you are running a custom ROM and have the "SuperUser" app, you would see if it had that access. I "think" it will be very hard for Good to implement some of those controls unless the Android OS provides an API for it because the underlying hardware can vary so much. I'm not a developer but I think that is correct.
Also, if you work for any decent sized company, they will be very concerned about the legal aspects of company provided software deleting (or even reading) personal information outside the "Good container". I mention the word container because Good provides encryption of everything within the app so it can not be read by anything outside the app (such as root explorer). I have successfully backed up and restored the encrypted data to another ROM but it is just bits to Titanium Backup or anything else. Feel free to PM me if you have any other questions on it that I might be able to answer. I know the admin for Good for our company that I could ask other questions.
I'm reading that the installation can detect jailbroken iPhones and rooted Android devices, and if the IT admins decide, they can configure it to refuse installation on such devices to prevent compromising Good's security/integrity of its resources.
(I'm not rooted, and don't plan to root my DroidX, so it is a moot point for me)
I heard from Verizon that IT admins can remotely control hardware components, including cameras, Bluetooth and IR ports, SD Cards, and more.
Things I'd like to know... can IT admins:
Track/monitor internet usage on the device?
Track/monitor GPS usage?
Copy non-Good related resources (e.g. files) from the device or SD card?
Lock the device?
Locate the device?
Wipe non-Good related resources?
Does the Good app send device System Logs to the IT folks?
Phone call logs?
App Permissions:
YOUR ACCOUNTS
ACT AS AN ACCOUNT AUTHENTICATOR Allows an application to use the account authenticator capabilities of the AccountManager, including creating accounts and getting and setting their passwords.
MANAGE THE ACCOUNTS LIST Allows an application to perform operations like adding, and removing accounts and deleting their password.
SERVICES THAT COST YOU MONEY
DIRECTLY CALL PHONE NUMBERS Allows the application to call phone numbers without your intervention. Malicious applications may cause unexpected calls on your phone bill. Note that this does not allow the application to call emergency numbers.
NETWORK COMMUNICATION
FULL INTERNET ACCESS Allows an application to create network sockets.
YOUR PERSONAL INFORMATION
READ CONTACT DATA Allows an application to read all of the contact (address) data stored on your device. Malicious applications can use this to send your data to other people.
READ SENSITIVE LOG DATA Allows an application to read from the system's various log files. This allows it to discover general information about what you are doing with the device, potentially including personal or private information.
WRITE CONTACT DATA Allows an application to modify the contact (address) data stored on your device. Malicious applications can use this to erase or modify your contact data.
PHONE CALLS
READ PHONE STATE AND IDENTITY Allows the application to access the phone features of the device. An application with this permission can determine the phone number and serial number of this phone, whether a call is active, the number that call is connected to and the like.
STORAGE
MODIFY/DELETE USB STORAGE CONTENTS
MODIFY/DELETE SD CARD CONTENTS Allows an application to write to the USB storage. Allows an application to write to the SD card.
SYSTEM TOOLS
RETRIEVE RUNNING APPLICATIONS Allows application to retrieve information about currently and recently running tasks. May allow malicious applications to discover private information about other applications.
PREVENT DEVICE FROM SLEEPING Allows an application to prevent the device from going to sleep.
YOUR ACCOUNTS
DISCOVER KNOWN ACCOUNTS Allows an application to get the list of accounts known by the device.
HARDWARE CONTROLS
CONTROL VIBRATOR Allows the application to control the vibrator.
NETWORK COMMUNICATION
VIEW NETWORK STATE Allows an application to view the state of all networks.
VIEW WI-FI STATE Allows an application to view the information about the state of Wi-Fi.
SYSTEM TOOLS
READ SYNC STATISTICS Allows an application to read the sync stats; e.g., the history of syncs that have occurred.
AUTOMATICALLY START AT BOOT Allows an application to have itself started as soon as the system has finished booting. This can make it take longer to start the device and allow the application to slow down the overall device by always running.
KILL BACKGROUND PROCESSES Allows an application to kill background processes of other applications, even if memory isn't low.
Sent from my unrooted DroidX using XDA App
I've been using EVO CM7 nightlies for quite a while now and never had issues with Good for Enterprise. With last 3 versions of nightlies, Good hasn't worked. When trying to reinstall Good, it says there is no phone network when trying to register. When looking at Device Info in Good setup screen, it doesn't have a phone number. Tried clearing, data, all cache, etc.
Is anyone else having this issue? It's like CM7 is not sending the phone string to Good when calling it.
A coworker also uses CM7 (not nightlies) and has no issues with Good on EVO. The phone number shows up in Good device info on his EVO.
I had the same problem, but I'm luckily an admin at our company on the good software. After messing around with it... this is what I had to do.
1. Uninstall Good from your phone on CM7 (Must be uninstalled at first for this to work....)
2. Reboot into Recovery and make a Nandroid Backup
3. Wipe the both Caches and Data, Install a Sense Rom
4. Install Good Mobile and have you admin resend you the email to enroll your phone
5. After entering the code and entering a password.. the Good will try to pull emails... kill the good app before this.
6. With Titinium Backup, backup Good and its Data.
7. Reboot into recovery.
8. Wipe the both Caches and the Data... Recover your previous CM7 Nandroid backup.
9. In CM7 launch Titanium backup and restore Good Mobile and its Data.
Worked after that... this way Good would communicate with the phone during the enrollment... which for some reason with CM7 it doesn't work... and just complains about not being connected to your mobile network.
Coincidentally I've just put up another post relating to IMSI numbers which was prompted by Good refusing to activate as some devices are reporting the same 1st 6 digits of their IMSI rather than the full 15 that Good uses to authenticate the license relative to the specific SIM card the license is for. Has anyone else come across this issue with Good?
matt1313 said:
Has anyone been able to get this working with Root? I install fine, enter my pin and it goes through but since I have root it doesnt sync. Im running liberty, any suggestions
Click to expand...
Click to collapse
Mine quit syncing after the first day. I had to upgrade my personal unlimited data plan to a corporate/enterprise data plan for an additional $15/month with Verizon, and reinstall Good.
Sent from my unrooted DroidX using XDA App
Sievers said:
I had the same problem, but I'm luckily an admin at our company on the good software. After messing around with it... this is what I had to do.
1. Uninstall Good from your phone on CM7 (Must be uninstalled at first for this to work....)
2. Reboot into Recovery and make a Nandroid Backup
3. Wipe the both Caches and Data, Install a Sense Rom
4. Install Good Mobile and have you admin resend you the email to enroll your phone
5. After entering the code and entering a password.. the Good will try to pull emails... kill the good app before this.
6. With Titinium Backup, backup Good and its Data.
7. Reboot into recovery.
8. Wipe the both Caches and the Data... Recover your previous CM7 Nandroid backup.
9. In CM7 launch Titanium backup and restore Good Mobile and its Data.
Worked after that... this way Good would communicate with the phone during the enrollment... which for some reason with CM7 it doesn't work... and just complains about not being connected to your mobile network.
Click to expand...
Click to collapse
I previously had a similar problem that I mentioned above - on custom FROYO ROMs it would stop at retrieving policies but flashing to stock eclair, I could finish the setup (and let all current emails come in) and then backup via TB, flash to custom FROYO, then restore and it would be all set. However, when I recently reinstalled Good on Continuum 5.5, I decided to try to let it complete the setup and it did with no problem. I only tried that since my IT admin setup "self-service" for me. I can access a link where I can send a new PIN for my account since it can easily stop syncing. The PIN goes to your corporate email so it is safe to allow.
@Nate2 - sorry I didn't see your post previously. Yes, there are Good policies that can be setup to detect "jailbroken" IPhones, etc. At my company, Good on Android is still not a standard offering because corporate policies are limited to what they can do on Android due to the numerous OS and hardware combinations. However, I have been pushing simply putting trust in the Good encryption (AES 256 if I remember right). Looking at the permissions of the app makes it look at first glance like it can do anything. However, I don't think it is as extensive as it seems. The only "data" outside the Good container that can be read by the app "to my knowledge" is the contact info. This is because your IT administrator can allow Good to sync corporate contact info (in Good) to your phone's contact info. This allows you to easily see who is calling (rather than a phone #) if it is one of your corporate contacts. Although it can access (modify/delete) SD contents, it doesn't say "Read". I don't think I am "reading" too much into that... For internet access, I know Good is working on adding in internet access (from inside the Good container) so browser access is allowed. I am "guessing" this is mostly for IPhones, etc. where the IT admin could stop internet access outside the Good container. That way they could control internet access on a "corporate" device. This is speculation on my part, though. I do think it can send device logs which is required "I think" to detect root access. Look over all the permissions listed keeping in mind READ access to system logs and contact info only and it seems to fit. Therefore, I think they probably can detect that you enabled/disabled GPS but I "doubt" they can detect where you went since I don't "think" that goes in system logs that they pull. If you still have any question, send me a PM since I don't frequently check this thread.
Thanks RichMD.
I once worked in a large company where a sysadmin was fired for accessing the corporate e-mail of an employee (his ex-girlfriend). She reported the incident to HR. Possible access to additional sensitive resources on the phone makes these kinds of incidents worse, and that's why we should be cautious.
Sent from my unrooted DroidX using XDA App
All,
I am trying to test the water to see what is possible for an enterprise tablet deployment we are working on.
We are working on a dual persona device - which enables the user to switch between two android instances.
I want to be able to notify the user which persona they are using, and an ideal way to do that would be via the "System Bar" at the bottom of the screen. I am thinking of a couple of options:
1) Change the colour of the system bar
2) Add some text to the status bar (that is always there)
If I understand correctly, the settings for this menu are in SystemUI.apk, and i have pulled this using adb from the device. I believe I know how to go about changing the colour, by searching out the relevant png's and swapping them.
How would i go about implementing option 2, for example I may want the string "Home" or "Work" displayed dependant on the instance the user has loaded. Would this be a case of changing a layout XML definition? If so which one?
Regards,
Andy
Why not just use the system notification services that already exist in android? You can have persistent notification icons, text etc. and no need to build a custom ROM, just use an app.
DigitalMD said:
Why not just use the system notification services that already exist in android? You can have persistent notification icons, text etc. and no need to build a custom ROM, just use an app.
Click to expand...
Click to collapse
Good question - I am open to all suggestions - the key requirement is that an item of text would be visible at all times to the user, and couldn't be dismissed.
Wasn't looking at a custom ROM - we have to make some changes to the device anyway which need us to Root it - so was thinking while we were there to mount the Filesystem read/write and swap SystemUI.apk to solve this issue.
As I say open to good ideas.
This may be what you're looking for...
http://www.androidpolice.com/2012/11/14/android-4-2-feature-highlight-multiple-user-accounts/
LeftyGR said:
This may be what you're looking for...
http://www.androidpolice.com/2012/11/14/android-4-2-feature-highlight-multiple-user-accounts/
Click to expand...
Click to collapse
Hi, interesting but not quite what we are trying for just yet. These devices will be single user devices (currently) which we intend to run dual persona's on, essentially we will be running a micro hypervisor, that allows a user to switch between virtual OS's.
So - we are just trying to find a decent feedback mechanism to present the user with an "always visible" way of telling them which persona they are in.
patonar said:
Hi, interesting but not quite what we are trying for just yet. These devices will be single user devices (currently) which we intend to run dual persona's on, essentially we will be running a micro hypervisor, that allows a user to switch between virtual OS's.
So - we are just trying to find a decent feedback mechanism to present the user with an "always visible" way of telling them which persona they are in.
Click to expand...
Click to collapse
Ok. So I think what you are looking for is this:
* Single User sign-on - where one person (considered the owner) logs into the device.
* Switching profiles (essentially) between two user interfaces.
**Where in one environment the owner has a general setup to use as a personal device, for lack of a better term.
**And in another environment the owner has a cusomized setup that is more optimized for work purposes. Not necessarily "different than the first environment, but obvious enough that when they unlock the device they will know which environment they are in.
Basically correct?
If so, what about this as a general solution: Using multiple Launcher Apps.
Basically, use the system default as one environment. Setup/arranged for the purpose of general use. Use a second (3rd party) Launcher as the second environment. 3rd party launchers are very customizable and most are themeable. And there are a few Launcher Manager apps on the market that allow for faster switching between them. Even provide desktop shortcuts on each launcher to quickly do between. Lock the 3rd party launcher from being able to be uninstalled easily by placing it into system/app folder. And if you want to take certain functionality away, modify it so an owner can't change the theme or settings you choose for it.
LeftyGR said:
Ok. So I think what you are looking for is this:
* Single User sign-on - where one person (considered the owner) logs into the device.
* Switching profiles (essentially) between two user interfaces.
**Where in one environment the owner has a general setup to use as a personal device, for lack of a better term.
**And in another environment the owner has a cusomized setup that is more optimized for work purposes. Not necessarily "different than the first environment, but obvious enough that when they unlock the device they will know which environment they are in.
Basically correct?
If so, what about this as a general solution: Using multiple Launcher Apps.
Basically, use the system default as one environment. Setup/arranged for the purpose of general use. Use a second (3rd party) Launcher as the second environment. 3rd party launchers are very customizable and most are themeable. And there are a few Launcher Manager apps on the market that allow for faster switching between them. Even provide desktop shortcuts on each launcher to quickly do between. Lock the 3rd party launcher from being able to be uninstalled easily by placing it into system/app folder. And if you want to take certain functionality away, modify it so an owner can't change the theme or settings you choose for it.
Click to expand...
Click to collapse
Yes basically correct, but I have a solution for the device "persona" switching - imagine I am actually running two completely separate ROM's running on VM's.... so each ROM behaves as its own device, unaware of the other...
All I want to do - is add some text to the system bar that is always there....
patonar said:
Yes basically correct, but I have a solution for the device "persona" switching - imagine I am actually running two completely separate ROM's running on VM's.... so each ROM behaves as its own device, unaware of the other...
All I want to do - is add some text to the system bar that is always there....
Click to expand...
Click to collapse
Ok. Two completely separate OS running at same time. I could see that as possible, save the problem you may run into with internal space in the current format. Would you need to completely repatriation the entire device to achieve this? Or maybe you could use an AOSP base, which is considerably lighter. I'm saying two completely autonomous systems would essentially duplicate all files needed to run to make them truely separate. Actually, I think that's what you're saying...
LeftyGR said:
Ok. Two completely separate OS running at same time. I could see that as possible, save the problem you may run into with internal space in the current format. Would you need to completely repatriation the entire device to achieve this? Or maybe you could use an AOSP base, which is considerably lighter. I'm saying two completely autonomous systems would essentially duplicate all files needed to run to make them truely separate. Actually, I think that's what you're saying...
Click to expand...
Click to collapse
The implementation of the virtualised android is being done by a company for me... that isn't the issue.
I have been making some kernel mods, to beef up encryption, but also wanted while i am there to make some mods to the system bar / task bar.
Forget about the two OS issue - imagine a single device, one OS, ICS 4.0.4 - i want to add some text to the task bar (static text) how could i do it?
Just bought a new Galaxy Tab S 10.5 Wifi and I have been debating whether to enable full disk encryption. I know that the stock android implementation of encryption is entirely software based, but Samsung mentioned in their documentation that their ODE (On Device Encryption) system supports hardware accelerated encryption. However, information on the topic is scarce, and I cannot confirm which models actually support acceleration.
Does anyone know of a list of android devices that supports hardware accelerated encryption?
snapper.fishes said:
Just bought a new Galaxy Tab S 10.5 Wifi and I have been debating whether to enable full disk encryption. I know that the stock android implementation of encryption is entirely software based, but Samsung mentioned in their documentation that their ODE (On Risk Encryption) system supports hardware accelerated encryption. However, information on the topic is scarce, and I cannot confirm which models actually support acceleration.
Does anyone know of a list of android devices that supports hardware accelerated encryption?
Click to expand...
Click to collapse
Go to Settings/Security and if it says Storage Type-Hadrware Backed, then your device has crypto module. However, big warning here: if your master encryption key sits in hardware (like in Iphones), there is nothing easier for a sophisticated attacker to get the key directly from there. If, like in Lollipop, the master key is salted on hard drive and crypto module holds another key used to sign the master key, that provides an additional layer of protection against brute force attack. In other words, someone can take an image of your entire hard drive and then brute force your password offline or in the case of Iphone, just get the key from hardware. In lollipop, it is impossible. So, sometimes google does good things (by mistake)...
In lollipop, it is impossible.
Click to expand...
Click to collapse
Android disk encryption is based on dm-crypt, which means it's at the block device layer. The encryption algorithm used is AES-128 with cipher-block chaining (CBC) and ESSIV:SHA256. The master key is encrypted with 128-bit AES via calls to the OpenSSL library. New Lollipop devices encrypted at first boot cannot be returned to an unencrypted state.
The unlock PIN/password is used to derive the AES disk encryption key which is stored in the volume header. As from 4.4, scrypt is used to derive the keys in order to make brute force attacks a little harder, but using a strong password instead of a stupid PIN remains highly recommended. On certain Nexus devices, the key is hardware-protected (likely TEE).
Nothing is impossible but's harder:
http://www.bbc.com/news/technology-31765672
http://www.washingtonpost.com/blogs...-apple-and-google-users-researchers-discover/
http://www.bbc.com/news/technology-31729305
CHEF-KOCH said:
Nothing is impossible but's harder:
http://www.bbc.com/news/technology-31765672
http://www.washingtonpost.com/blogs...-apple-and-google-users-researchers-discover/
http://www.bbc.com/news/technology-31729305
Click to expand...
Click to collapse
What have these news to do with Android encryption?
Seriously, there was a clear question by the OP and you didn't even try to answer at all. Instead you copy and paste text fragments from other websites and post irrevelant links...
@bastei
And how your post helps here? I explained very well that FDE is vulnerable with several attacks. It isn't worth to use it, especially on such hardware, because it costs a lot of performance for nothing.
FDE isn't secure to use, especially if you have a mobile device which allows the attacker to get physical access to it + the mentioned attacks.
But to answer the question:
Hardware accelerated encryption is dependent on which hardware (needs to support special flags like AES/AES-NI/AVX) you use and if your os supports it (minimum Android 3.x) or not. And no there is no list, because all new hardware after (and some of them before) Android 3.x comes with support for it, the Tab S uses AES 256-Bit Encryption according to the specs.
ODE (On Risk Encryption)
Click to expand...
Click to collapse
It's Samsung On-Device Encryption (ODE) and not on Risk ...
Yup that's a typo. Going to check the settings when I get home today.
CHEF-KOCH said:
@bastei
I explained very well that FDE is vulnerable with several attacks. It isn't worth to use it, especially on such hardware, because it costs a lot of performance for nothing.
FDE isn't secure to use, especially if you have a mobile device which allows the attacker to get physical access to it + the mentioned attacks. .
Click to expand...
Click to collapse
With all due respect, but your explanation is wrong. If encryption is properly implemented, you reduce vulnerability to virtually none. Users just have to understand how encryption works and what it is designed for. Contrary to popular beliefs, disk encryption is not designed to protect the device that is live/running, it only prevents access to your data, when your phone is off. By the way, the term "full disk encryption" , as it applies to Android, is highly misleading, because unlike in Linux, Android only provides for data encryption.
However, Android allows to implement encryption in a way that it is virtually impossible to break. You can have separate passwords short for screen and long/strong for boot and encryption. In addition, Android Lollipop provides an extra layer of protection by putting a second key, which is used to sign the master key in crypto module (hardware). This is much better than in IOS (iphones) where the master key simply sits in hardware crypto module and therefore could be easily obtained by a sophisticated attacker (think back doors in crypto module and weak hardware assisted random number generation).
Let me give you an example with my Sony Xperia Z1 running custom lollipop. I have enabled 256 bit encryption; I have increased the length of various keys, as well as the number of iterations for random number generation; then I have disabled in kernel hardware based weakened random number generator and enabled all other methods inactive by default (thanks to google and sony for making it easier to break for spooks); I then disabled hardware overlay option, which causes slow down, so, now, there is no visible difference in performance with unencrypted device. And finally, I have encrypted the phone via adb shell by using a long pass phrase, so that screen pin was not used in encryption in any way, including its salted traces on the device. By the way, when you encrypt lollipop via adb shell, you don't input your raw passphrase, but rather its hexed version, and guess what, I hexed it on my computer, as opposed to the phone. So, when I turn my phone off, I know that no sophisticated spook can get access to my data even if they take an image of all my partitions and try to brutforce the password off the phone. They simply can't. No one can break properly implemented 256 bit AES encryption. That is why the spooks need backdoors in hardware and weak random number generation (the latter is disabled in kernel on my Z1).
So, properly implemented encryption (and Android Lollipop provides for that) does not visibly slow down the device and can make it impossible for spooks to break. .
With all due respect, but your explanation is wrong. If encryption is properly implemented, you reduce vulnerability to virtually none. Users just have to understand how encryption works and what it is designed for. Contrary to popular beliefs, disk encryption is not designed to protect the device that is live/running, it only prevents access to your data, when your phone is off. By the way, the term "full disk encryption" , as it applies to Android, is highly misleading, because unlike in Linux, Android only provides for data encryption.
Click to expand...
Click to collapse
But Android is not a Computer which is on the same place all the time which means that it is a lot of easier to get physical access to it. That means an attacker have all the time to crack it, which in fact is only a matter of time. With or without additional protection mechanism - it will be cracked soon or later, and if you asking me it's not worth to use FDE on a mobile device, it coasts performance (as said for nothing).
The focus should be to protect data, correct but these kind of protection not protect against usage data stealing if most aps need internet connection which never use any secure way to send and receive data - So the risk here is much higher that a attacker can collect all necassary data if your phone is unlocked and a app xyz is running in the background which logs all stuff, such as Pin, passwords for website logins or whatever.
However, Android allows to implement encryption in a way that it is virtually impossible to break. You can have separate passwords short for screen and long/strong for boot and encryption. In addition, Android Lollipop provides an extra layer of protection by putting a second key, which is used to sign the master key in crypto module (hardware). This is much better than in IOS (iphones) where the master key simply sits in hardware crypto module and therefore could be easily obtained by a sophisticated attacker (think back doors in crypto module and weak hardware assisted random number generation).
Click to expand...
Click to collapse
It's very easy breakable there a several tools out there, exploits and poc's - and why need to crack something if you better steal data that are necessary over internet? Which tactic is easier - sure the last. Yes, lollipop is the first secure os, but not all people use it right now or the oem rolls out the update for every device. But I generally agree in the aspect that lollipop fix most stuff which are vulnerable compared to Android 4.x.
There are several attacks which affects all Android versions even latest lollipop:
- First, the encryption doesn't help much if you haven't set a passcode!
- Limitations in lollipops encryption explained over here
- Only the /data partition and all stuff in there will be protected (only the sdcard is protected if it's non-removable)
- The attacker boot to recovery and factory reset the device.
- If your phone is rooted and booted up, they'll use adb to copy your unencrypted data (e.g. sdcard). If it's not booted, they're stuck.
- The attack can use a download mode from there they flash a custom recovery or custom kernel (rooted) image. Most custom recovery's allows root adb which is needed to bypass the lockscreen.
- The attacker can simply use some software holes to bypass the pin and of course several known tools to crack the image master password.
- Military-grade encryption just doesn’t matter if an attacker has access to the key already.
- Nobody use a strong password (eg 20 chars) since you can't use a hardware token + the fact it's too long to type on the phone (and this each time).
- Android just required you to use a strong password/passphrase when starting up the device, but for some absurd reason they also require that you use the same password as your screen lock password
So, properly implemented encryption (and Android Lollipop provides for that) does not visibly slow down the device and can make it impossible for spooks to break. .
Click to expand...
Click to collapse
Yes and no, you right if you say the stuff about the implementation but overall encryption always takes performance for e.g. if you use AES 256 encryption anything that needs to decrypt constantly during the read and write process will causes performance impacts examples are give over here and here. But AES is most common used which is already "optimized".
The conclusion is that the performance of your device will take a slight hit if you enable encryption (dependency which hardware you use and which encryption algo was used + possible bugs/implementation problems) but to fight with this only for a technique that will be cracked it the near feature is really not worth to use or recommend if you asking me. It's more like a placebo, nothing is really secure as long the user is to lazy to use a very strong passcode/password
CHEF-KOCH said:
But Android is not a Computer which is on the same place all the time which means that it is a lot of easier to get physical access to it. That means an attacker have all the time to crack it, which in fact is only a matter of time. With or without additional protection mechanism - it will be cracked soon or later, and if you asking me it's not worth to use FDE on a mobile device, it coasts performance (as said for nothing).
The focus should be to protect data, correct but these kind of protection not protect against usage data stealing if most aps need internet connection which never use any secure way to send and receive data - So the risk here is much higher that a attacker can collect all necassary data if your phone is unlocked and a app xyz is running in the background which logs all stuff, such as Pin, passwords for website logins or whatever.
It's very easy breakable there a several tools out there, exploits and poc's - and why need to crack something if you better steal data that are necessary over internet? Which tactic is easier - sure the last. Yes, lollipop is the first secure os, but not all people use it right now or the oem rolls out the update for every device. But I generally agree in the aspect that lollipop fix most stuff which are vulnerable compared to Android 4.x.
There are several attacks which affects all Android versions even latest lollipop:
- First, the encryption doesn't help much if you haven't set a passcode!
- Limitations in lollipops encryption explained over here
- Only the /data partition and all stuff in there will be protected (only the sdcard is protected if it's non-removable)
- The attacker boot to recovery and factory reset the device.
- If your phone is rooted and booted up, they'll use adb to copy your unencrypted data (e.g. sdcard). If it's not booted, they're stuck.
- The attack can use a download mode from there they flash a custom recovery or custom kernel (rooted) image. Most custom recovery's allows root adb which is needed to bypass the lockscreen.
- The attacker can simply use some software holes to bypass the pin and of course several known tools to crack the image master password.
- Military-grade encryption just doesn’t matter if an attacker has access to the key already.
- Nobody use a strong password (eg 20 chars) since you can't use a hardware token + the fact it's too long to type on the phone (and this each time).
- Android just required you to use a strong password/passphrase when starting up the device, but for some absurd reason they also require that you use the same password as your screen lock password
Yes and no, you right if you say the stuff about the implementation but overall encryption always takes performance for e.g. if you use AES 256 encryption anything that needs to decrypt constantly during the read and write process will causes performance impacts examples are give over here and here. But AES is most common used which is already "optimized".
The conclusion is that the performance of your device will take a slight hit if you enable encryption (dependency which hardware you use and which encryption algo was used + possible bugs/implementation problems) but to fight with this only for a technique that will be cracked it the near feature is really not worth to use or recommend if you asking me. It's more like a placebo, nothing is really secure as long the user is to lazy to use a very strong passcode/password
Click to expand...
Click to collapse
I agree with you regarding weaknesses, but they all are rellated to improperly implemented encryption or user's misunderstanding. You have acknowledged that if the phone is off "they are stuck." That's what I call properly implemented encryption, and no tool can help including their super fast computers. By the way, if they do it on the device, in lollipop, data will be erased after 10 attempts, not to mention that there is a slowdown mechanism to prevent brutforce. Stealing online: yes, this is true, but again, it is possible to restrict any app from contacting the internet (afwall that was recently updated for lollipop and Xprivacy). On my phone, only web browser, mail client and sip client (all non google) have access to the internet; and since I have no Gapps, there is no "phoning home" Google's servers. Performance: it is true that encryption degrades performance somewhat, but again, if it is properly implemented, human's eye wouldn't notice. By the way, I think the reason Google is back pedalling on default encryption is that they have realized they really created something that is difficult to crack. Hence, they'll "modify" it soon to help their sponsoring spooks.
"Nobody use a strong password (eg 20 chars) " I use a boot pass phrase that has over 60 characters. This one was used for encryption, as opposed to a screen pin. You can only do it via adb shell.... Again, it is all about implementation. And by the way, most of the time I use soft reboot, which does not require me to use the long phrase at all.
A lot of people over-estimate spook's abilities. Despite the recent revelations: they can't do magic, meaning breaking encryption and they know it. That's why they are colluding with everyting that "moves" to put backdoors, weaken number generation, force weaker ciphers and so on.
May I ask you if using an xposed module is a risk for the whole system itself? It shouldn't be too hard to abuse it and to bypass xprivacy itself and the Android firewall.
Funny stuff, you not use gapps but you trust goggles encryption even if they already worked together in the past with GCHQ/NSA ...
Stealing online: yes, this is true, but again, it is possible to restrict any app from contacting the internet (afwall that was recently updated for lollipop and Xprivacy)
Click to expand...
Click to collapse
Again apps are not the first line of defense, they are the last. Xprivacy can't protect/or fake mac address, ID's or your imei/phone number (please read the whole FAQ) and on Lollipop there are a lot of more restrictions generally and they are not all implemented yet.
Since Xprivacy needs root (or should I say the Xposed framework) this is also a possible security risk, the attacker can use adb (which can be rescricted by an app) to disable/uninstall/freeze XPrivacy or any other app even if you use them as admin (the app will once crash and not restart).
...and no tool can help including their super fast computers
... data will be erased after 10 attempts
Click to expand...
Click to collapse
Erased? Are you sure? I don't think so I guess the os will just shutdown but to erase something would be horrible.
On my phone, only web browser, mail client and sip client (all non google) have access to the internet; and since I have no Gapps, there is no "phoning home" Google's servers.
Click to expand...
Click to collapse
Yes, and this is a mistake here in this thread, people forgett that most users are not experts, they not even know about XPrivacy/AFWall+ or root. The benefit of encryption should that all people even without bigger knowledge can handle it without disadvantages or other hints. So that already failed, google now reverted there own statement which means the encryption will not default enabled for all (see my links for there statement: In short - OEM complaining about performance!).
So security isn't activated from the beginning which is also a possible risk.
Performance: it is true that encryption degrades performance somewhat, but again, if it is properly implemented, human's eye wouldn't notice.
Click to expand...
Click to collapse
No it's not and you not understand it the I/O performance is slower, that can be a little bit different from device to device (due other hardware) but it's definitely noticeable (and not only in benchmarks) - please read the links. Not every use high end devices, never forget it -> again security should be available for all and the fact google reverted it clearly shows that we are not ready yet.
By the way, I think the reason Google is back pedalling on default encryption is that they have realized they really created something that is difficult to crack. Hence, they'll "modify" it soon to help their sponsoring spooks.
Click to expand...
Click to collapse
It's a matter of time anyone found a solution, the only thing we can do is to upgrade the OS to fix the possible holes asap - but that won't protect anyone who not update direct after each new release. And oem's usally needs aslo time to update there stuff, if they not already gave up due the massive fragmentation.
I use a boot pass phrase that has over 60 characters. This one was used for encryption, as opposed to a screen pin. You can only do it via adb shell.... Again, it is all about implementation.
Click to expand...
Click to collapse
Yes and because of implementation there are always security holes, possible risk and negative side-effects and because of this there will always a way to crack thinks as long if you're rooted.
And again because you use that it not means the mass use this - I'm not the only one who complains about that several known security experts and on several sites a lot of people saying that the length of the password is always a problem. Sure there are a lot of tools, but in our case they only works after a login and again ... mostly only experts using them.
A lot of people over-estimate spook's abilities. Despite the recent revelations: they can't do magic, meaning breaking encryption and they know it. That's why they are colluding with everyting that "moves" to put backdoors, weaken number generation, force weaker ciphers and so on.
Click to expand...
Click to collapse
Maybe, maybe not. Maybe NSA already have the ability to crack it with some exploits, maybe not - but we can bet on it they are working on it right know we talking about it. But why holidng on stuff that is placebo? There are already problems which can't be denied.
So we are now a bit off-topic, but if you believe the myth that it can't be bypassed you must be naive it was done in the past and it will be soon or later with lollipop with tools every script kiddy can use (like on 4.x). That's not what I call implementation related, it's also not encryption related it's the fact that as long users can side-load stuff or execute root it's only a matter of time - that was and ever will a possible security risk (not only on Android).
pikatchu said:
May I ask you if using an xposed module is a risk for the whole system itself? It shouldn't be too hard to abuse it and to bypass xprivacy itself and the Android firewall.
Click to expand...
Click to collapse
Don't use any xposed module that is not open source
Use Afwall built in iptables binaries, as opposed to system ones or better move builtin iptables into your system
Prevent any xposed module including xprivacy and xposed framework from internet access
---------- Post added at 04:39 PM ---------- Previous post was at 03:50 PM ----------
CHEF-KOCH said:
Funny stuff, you not use gapps but you trust goggles encryption even if they already worked together in the past with GCHQ/NSA ...
Again apps are not the first line of defense, they are the last. Xprivacy can't protect/or fake mac address, ID's or your imei/phone number (please read the whole FAQ) and on Lollipop there are a lot of more restrictions generally and they are not all implemented yet.
Since Xprivacy needs root (or should I say the Xposed framework) this is also a possible security risk, the attacker can use adb (which can be rescricted by an app) to disable/uninstall/freeze XPrivacy or any other app even if you use them as admin (the app will once crash and not restart).
Erased? Are you sure? I don't think so I guess the os will just shutdown but to erase something would be horrible.
Yes, and this is a mistake here in this thread, people forgett that most users are not experts, they not even know about XPrivacy/AFWall+ or root. The benefit of encryption should that all people even without bigger knowledge can handle it without disadvantages or other hints. So that already failed, google now reverted there own statement which means the encryption will not default enabled for all (see my links for there statement: In short - OEM complaining about performance!).
So security isn't activated from the beginning which is also a possible risk.
No it's not and you not understand it the I/O performance is slower, that can be a little bit different from device to device (due other hardware) but it's definitely noticeable (and not only in benchmarks) - please read the links. Not every use high end devices, never forget it -> again security should be available for all and the fact google reverted it clearly shows that we are not ready yet.
It's a matter of time anyone found a solution, the only thing we can do is to upgrade the OS to fix the possible holes asap - but that won't protect anyone who not update direct after each new release. And oem's usally needs aslo time to update there stuff, if they not already gave up due the massive fragmentation.
Yes and because of implementation there are always security holes, possible risk and negative side-effects and because of this there will always a way to crack thinks as long if you're rooted.
And again because you use that it not means the mass use this - I'm not the only one who complains about that several known security experts and on several sites a lot of people saying that the length of the password is always a problem. Sure there are a lot of tools, but in our case they only works after a login and again ... mostly only experts using them.
Maybe, maybe not. Maybe NSA already have the ability to crack it with some exploits, maybe not - but we can bet on it they are working on it right know we talking about it. But why holidng on stuff that is placebo? There are already problems which can't be denied.
So we are now a bit off-topic, but if you believe the myth that it can't be bypassed you must be naive it was done in the past and it will be soon or later with lollipop with tools every script kiddy can use (like on 4.x). That's not what I call implementation related, it's also not encryption related it's the fact that as long users can side-load stuff or execute root it's only a matter of time - that was and ever will a possible security risk (not only on Android).
Click to expand...
Click to collapse
GAPPS vs. Google encryption: I can't examine or modify GAPPS, but I can Google encryption, which is open source
Xposed modules: Xposed framework needs root once only during installation. After that you can revoke root permission
Attacker use of ADB: no matter what attacker does, he can't mount Data. Even on a live device, if pings are disabled, as well as all incoming connections, there is no way to reach the system over the internet. Now, I am not talking about baseband or simcard exploits, but if you face that kind of an attacker, then you don't use cell phones at all. The point stands: if your phone is off and it is properly encrypted, there is virtually no way to get the data. And I say virtually only because of baseband/simcard exploits.
Erasing data: If you look at lollipop's /system/vold/cryptfs.c and .h, you will see that erasing data is implemented after 10 unsuccessful attempts (the number could be reduced).
Low end devices vs. high end; regular user vs. advanced: you can't have a product that will satisfy all. You can't lower safety standards to satisfy the low end regular user. 2015 Mercedes is safer on the road than 1976 Honda. If you have advanced knowledge, you'll benefit more than a regular user. And if that user refuses to help himself, he will have to face the consequences.. That's the way Linux (and Android is its ugly daughter) is built...
GAPPS vs. Google encryption: I can't examine or modify GAPPS, but I can Google encryption, which is open source
Click to expand...
Click to collapse
Open source isn't a guarantee for security. I'm tired to saying this over and over again here on xda and in other forums. And no, it's not open source since most devices comes with own stock android builds which may use other hardware/drivers and maybe other or touched encryptions. There is also no guarntee that it hold what it promise as long nobody can proof or deny it.
Xposed modules: Xposed framework needs root once only during installation. After that you can revoke root permission
Click to expand...
Click to collapse
Once is more than enough, to get infected by faked Xposed Installers or other possible attacks. You scenarios are very unrealistic, nobody only use root only for one single module - You can't tell me that. Attackers don't need to mount data if you installed apps on external sdcard which isn't encrypted.
as well as all incoming connections, there is no way to reach the system over the internet.
Click to expand...
Click to collapse
Incoming connections are not necessary, outgoing is more important to send data to a eg. C&C.
The point stands: if your phone is off and it is properly encrypted, there is virtually no way to get the data. And I say virtually only because of baseband/simcard exploits.
Click to expand...
Click to collapse
Sure but it's unrealistic too, I will use the phone and not use encryption which can be attacked or bypassed except the phone is offline.
Erasing data: If you look at lollipop's /system/vold/cryptfs.c and .h, you will see that erasing data is implemented after 10 unsuccessful attempts (the number could be reduced).
Click to expand...
Click to collapse
Please give me the source, thanks. According to this normal userdata not getting any wipe on encryption fail and on other systems then EXT4 or F2FS nothing will be done (no access). And as long /data is not mounted there is also no access, that's the reason android temporary mount /data each time to promt for passwords, other processes and such (for more look in the documents)
I didn't know that but nvm it's unimportant since the master key is still on the device itself - which will definitely not erased and as said it not protect against privacy data stealing which is more important, nobody want you android files, only you passwords etc ...
Use Afwall built in iptables binaries
Click to expand...
Click to collapse
Iptables are not installed on every system and not working anymore since Android 5 need some extra flags like -pie and to replace the system own or installing them needs root too - oh, and to fix possible startup data leaks also needs root for init.d.
Low end devices vs. high end; regular user vs. advanced: you can't have a product that will satisfy all.
Click to expand...
Click to collapse
I'm not saying other stuff but you are the one which said that the performance impact is minimal and I'm the one which said encryption should work out of the box for all on any device - sure it's definitly an implementation thing, but as a workaround older devices may just simple lower the encryption e.g. 256 -> 128 Bit.
You can't lower safety standards to satisfy the low end regular user. 2015 Mercedes is safer on the road than 1976 Honda. If you have advanced knowledge, you'll benefit more than a clueless user who refuses to help himself....
Click to expand...
Click to collapse
I'm not comparing cars I only compare the encryption algos which haven't much changed over the years (just some fixes here and there but under the hood the car still needs 4 wheels).
We talked about encryption and possible attacks and you still can't deny them all. You try to find some excuses but under the line it will be cracked - and not in 10 years, this or next year I promise because of this reasons:
- Cracking the pins normally takes only seconds: they are simply to short or follow patterns due to being the same as the lock screen password. Practically speaking, the security of this entire story depends on the passphrase the user sets. If it is very long, it makes brute forcing difficult. But most people would set a 4/6/8 digit PIN, because who would want to enter a 20 digit password with alphabets and special characters every time you want to make a call or send a message?!
- Cracking Encryption in general -> Encrypted Master Key + Salt stored in footer and they are usually stored at the end of the partition or in a footer file on other partitions
- OEM's may use a different key management module
- Some forensic boot images are available which makes it possible to start early in the boot chain before the whole system loads ->
- Keyloggers or memory catcher allowing the attacker to capture unencrypted data -> including encryption keys and passwords for non encrypted content
- If the device is already compromised with malware it will be possible send things into the internet
- Some root kits already breaking most of all hard disk encryption such as the "Stoned" bootkit on TrueCrypt
- A factory reset also resets the master key
optimumpro said:
I have enabled 256 bit encryption; I have increased the length of various keys, as well as the number of iterations for random number generation; then I have disabled in kernel hardware based weakened random number generator and enabled all other methods inactive by default (thanks to google and sony for making it easier to break for spooks); I then disabled hardware overlay option, which causes slow down, so, now, there is no visible difference in performance with unencrypted device.
Click to expand...
Click to collapse
You already mentioned some of these things over at unclefab's "How To Secure Your Phone"-thread. Any chance to get some more detailed steps or even diffs of your changes?
Thanks!
CHEF-KOCH said:
Open source isn't a guarantee for security. I'm tired to saying this over and over again here on xda and in other forums. And no, it's not open source since most devices comes with own stock android builds which may use other hardware/drivers and maybe other or touched encryptions. There is also no guarntee that it hold what it promise as long nobody can proof or deny it.
Once is more than enough, to get infected by faked Xposed Installers or other possible attacks. You scenarios are very unrealistic, nobody only use root only for one single module - You can't tell me that. Attackers don't need to mount data if you installed apps on external sdcard which isn't encrypted.
Incoming connections are not necessary, outgoing is more important to send data to a eg. C&C.
Sure but it's unrealistic too, I will use the phone and not use encryption which can be attacked or bypassed except the phone is offline.
Please give me the source, thanks. According to this normal userdata not getting any wipe on encryption fail and on other systems then EXT4 or F2FS nothing will be done (no access). And as long /data is not mounted there is also no access, that's the reason android temporary mount /data each time to promt for passwords, other processes and such (for more look in the documents)
I didn't know that but nvm it's unimportant since the master key is still on the device itself - which will definitely not erased and as said it not protect against privacy data stealing which is more important, nobody want you android files, only you passwords etc ...
Iptables are not installed on every system and not working anymore since Android 5 need some extra flags like -pie and to replace the system own or installing them needs root too - oh, and to fix possible startup data leaks also needs root for init.d.
I'm not saying other stuff but you are the one which said that the performance impact is minimal and I'm the one which said encryption should work out of the box for all on any device - sure it's definitly an implementation thing, but as a workaround older devices may just simple lower the encryption e.g. 256 -> 128 Bit.
I'm not comparing cars I only compare the encryption algos which haven't much changed over the years (just some fixes here and there but under the hood the car still needs 4 wheels).
We talked about encryption and possible attacks and you still can't deny them all. You try to find some excuses but under the line it will be cracked - and not in 10 years, this or next year I promise because of this reasons:
- Cracking the pins normally takes only seconds: they are simply to short or follow patterns due to being the same as the lock screen password. Practically speaking, the security of this entire story depends on the passphrase the user sets. If it is very long, it makes brute forcing difficult. But most people would set a 4/6/8 digit PIN, because who would want to enter a 20 digit password with alphabets and special characters every time you want to make a call or send a message?!
- Cracking Encryption in general -> Encrypted Master Key + Salt stored in footer and they are usually stored at the end of the partition or in a footer file on other partitions
- OEM's may use a different key management module
- Some forensic boot images are available which makes it possible to start early in the boot chain before the whole system loads ->
- Keyloggers or memory catcher allowing the attacker to capture unencrypted data -> including encryption keys and passwords for non encrypted content
- If the device is already compromised with malware it will be possible send things into the internet
- Some root kits already breaking most of all hard disk encryption such as the "Stoned" bootkit on TrueCrypt
- A factory reset also resets the master key
Click to expand...
Click to collapse
Wipe after 10 attempts, see here https://github.com/CyanogenMod/android_device_qcom_common/blob/cm-12.0/cryptfs_hw/cryptfs_hw.c
A factory reset wipes data, so whatever happens to master key is not significant. But even if the master key is reset, there is no use of it in terms of trying to get previously encrypted data. And by the way, the term reset is not correct: if you do a regular reset, the master key is not touched, as it is not sitting on data partition and if you wipe system and data, your master key is gone and the new one will be generated only when you enable encryption again.
I don't understand your consistent point that users won't bother with long passwords, when Android provides for separate passwords one for boot/encrption and another for screen (which is not used for encryption). As I have already said, I use an over 60 character boot password and a short screen pin. If I need to reboot the device, I use soft reboot, which does not require the password at all. So, having a long password does not create any undue burden.
Again, data/disk encryption is valuable, because it protects your device when it is off, meaning, no one can access your data... I have close to personal experience with "sophisticated attackers": they can do nothing with properly encrypted device that is turned off...
Closed source vs. open source. I am not saying open source is secure. I am saying that open source could be examined unlike proprietary one.
My last words on this:
Well in the source nothing to user data gets wiped, only stuff that protects android system related files which proofs that the user data aren't safe if someone use forensic image and cloned everything.
Short screen pins can be cracked in minutes so as long we can sideloading anything before or after a boot especially if not all stuff is mounted it is still a risk.
Fastboot/softboot or whatever you want to call it isn't available on every device so you whole argumentation about complex passwords are useless (for example a friend of mine recently got the LG G3 which had fastboot deactivated). And of course if you got an error like kernel panic or other crash you can't fast reboot which also required that complicated and complex password - especially on mobile devices this is pretty annoying.
Again FDE on Android is placebo that's all, as long the user can dump the whole system and crack it on a PC which is powerful enouth it will be always useless. Apple use a unique key (if we can believe it) which can't be extracted with any tool or read out during the boot (maybe some day but I don't know any tool yet) so everything like brute force must be directly on the device which takes a lot of more time compared to a computer with an external powerful nvidia card and tools like hashkill/hashcat.
About explaining closed source, if you are good enouth you can reverse engineering most of the code - you don't even need to deobfuscate all stuff but in most time if you know the basics you know which weakness e.g. the encryption may have.
As long you not understand that sideloading is the biggest problem in android you not understand that all can be cracked soon or later and because you use xyz do not means that millions of stock users doing such complicated steps too to "secure" the phone which do not protect all stuff except the os itself. Android has defenses yes, but it is more to protect itself and not the private data that's the conclusion. It's a good step what was made with lollipop but there are still attacks which can't be that easily blocked, especially if the user doesn't know how or most if the mechanism are deactivated or simply to complex.
CHEF-KOCH said:
My last words on this:
Well in the source nothing to user data gets wiped, only stuff that protects android system related files which proofs that the user data aren't safe if someone use forensic image and cloned everything.
Short screen pins can be cracked in minutes so as long we can sideloading anything before or after a boot especially if not all stuff is mounted it is still a risk.
Fastboot/softboot or whatever you want to call it isn't available on every device so you whole argumentation about complex passwords are useless (for example a friend of mine recently got the LG G3 which had fastboot deactivated). And of course if you got an error like kernel panic or other crash you can't fast reboot which also required that complicated and complex password - especially on mobile devices this is pretty annoying.
Again FDE on Android is placebo that's all, as long the user can dump the whole system and crack it on a PC which is powerful enouth it will be always useless. Apple use a unique key (if we can believe it) which can't be extracted with any tool or read out during the boot (maybe some day but I don't know any tool yet) so everything like brute force must be directly on the device which takes a lot of more time compared to a computer with an external powerful nvidia card and tools like hashkill/hashcat.
About explaining closed source, if you are good enouth you can reverse engineering most of the code - you don't even need to deobfuscate all stuff but in most time if you know the basics you know which weakness e.g. the encryption may have.
As long you not understand that sideloading is the biggest problem in android you not understand that all can be cracked soon or later and because you use xyz do not means that millions of stock users doing such complicated steps too to "secure" the phone which do not protect all stuff except the os itself. Android has defenses yes, but it is more to protect itself and not the private data that's the conclusion. It's a good step what was made with lollipop but there are still attacks which can't be that easily blocked, especially if the user doesn't know how or most if the mechanism are deactivated or simply to complex.
Click to expand...
Click to collapse
And here are my last words. Click the link in the previous post and you will see code to wipe user data. There is annotation that says we will wipe everything related to encryption followed by the code itself that contains the words "wipe user data":
} else {
if(ERR_MAX_PASSWORD_ATTEMPTS == err)
wipe_userdata();
With regard to cracking everything soon, this is just your opinion that is not based on known facts. And one of the facts is that if spooks could break the encryption, they wouldn't need back doors and weakening.
Again, I fail to understand your point about users not using long screen passwords. You don't need long ones for your screen. But let's leave it there and agree to disagree.
bastei said:
You already mentioned some of these things over at unclefab's "How To Secure Your Phone"-thread. Any chance to get some more detailed steps or even diffs of your changes?
Thanks!
Click to expand...
Click to collapse
Look here for kernel changes:
https://github.com/AOSP-Argon/android_kernel_sony_msm8974/commit/29d918c1f11247602c58096a62084811bccc328f
// When device comes up or when user tries to change the password, user can
// try wrong password upto a certain number of times. If user enters wrong
// password further, HW would wipe all disk encryption related crypto data
// and would return an error ERR_MAX_PASSWORD_ATTEMPTS to VOLD. VOLD would
// wipe userdata partition once this error is received.
#define ERR_MAX_PASSWORD_ATTEMPTS -10
#define QSEECOM_DISK_ENCRYPTION 1
#define MAX_PASSWORD_LEN 32
Click to expand...
Click to collapse
It won't touch userdata at all, it wipes only (as written) disk encryption related data stuff but I'm talking about sideloading user data and this will never be wiped since this will destroy other stuff too - so this prevents only some attacks if you just start you're phone. - Or if you dump the data without - in a locked state - the master key.
The stuff you linked is also different from my link from AOSP project since it's CM, also a mistake, because CM isn't stock or based on OEM's firmware. So all you're stuff may applies only to custom firmwares - I'm talking again about stuff which use the mass and not only certain "expert" people.
Look here for kernel changes:
Click to expand...
Click to collapse
This is also from CyanogenMod which also only affects /cache/recovery which doesn't matter if the system was already booted success and (as shown) some stuff was already compromised or running in the background.
With regard to cracking everything soon, this is just your opinion that is not based on known facts. And one of the facts is that if spooks could break the encryption, they wouldn't need back doors and weakening.
Click to expand...
Click to collapse
Yes and your wrong opinion is that it isn't crackable, same was said years ago about TrueCrypt which now is labeled as unsafe and I already mentioned tools which break it.
Seems you're to ignorant to understand which possible negative effects may comes with side-loading. As long you not understand this we can stop the entire discussion here (I already gave up because you don't know s much as I do which tools can break stuff) - it will be cracked and the the dm-crypt stuff was already cracked in Android 4. because of some fixes that doesn't mean anything. Again, because you use xyz that doesn't mean all use the same stuff you already ignored this several times now and I already said that - but okay.
CHEF-KOCH said:
It won't touch userdata at all, it wipes only (as written) disk encryption related data stuff but I'm talking about sideloading user data and this will never be wiped since this will destroy other stuff too - so this prevents only some attacks if you just start you're phone. - Or if you dump the data without - in a locked state - the master key.
The stuff you linked is also different from my link from AOSP project since it's CM, also a mistake, because CM isn't stock or based on OEM's firmware. So all you're stuff may applies only to custom firmwares - I'm talking again about stuff which use the mass and not only certain "expert" people.
This is also from CyanogenMod which also only affects /cache/recovery which doesn't matter if the system was already booted success and (as shown) some stuff was already compromised or running in the background.
Yes and your wrong opinion is that it isn't crackable, same was said years ago about TrueCrypt which now is labeled as unsafe and I already mentioned tools which break it.
Seems you're to ignorant to understand which possible negative effects may comes with side-loading. As long you not understand this we can stop the entire discussion here (I already gave up because you don't know s much as I do which tools can break stuff) - it will be cracked and the the dm-crypt stuff was already cracked in Android 4. because of some fixes that doesn't mean anything. Again, because you use xyz that doesn't mean all use the same stuff you already ignored this several times now and I already said that - but okay.
Click to expand...
Click to collapse
I guess we speak different languages. My point is (and it stands) that if encryption is properly implemented, there is no way to get data from unmounted encrypted partition. Let's forget about wiping, any sophisticated attacker will take an image of the device and then try to break a copy. However, to mount data, he will have to bruteforce my 60 character password that will unlock master key or break 256 bit AES. Good luck on either front. And I am not talking about stock, aosp or Cm roms. It makes no difference, the bottom line is he won't be able to do either of the above. I also don't care about careless users. They have a right to be ignorant and most enjoy it very much. Linux (on which Android is based) was not created for ignorant users...
Hello guys,
I have been searching for answers to some of the tech stuff, but couldn't find them.
Here are some of those questions. Hope some of you would have answers to these. Thanks in advance!
ANDROID
1. How to share files between multi-users on Android 11?
Before Android 11, it was possible to save files inside the Android/ obb folder, and these files were visible for all users on the device. In Android 11, this is no longer working as the 'obb' folder appears to be exclusive to each user.
I know this is possible via USB OTG or a cloud service, but is there a solution without these?
2. How to copy/ backup game data for non-rooted devices?
Helium Backup doesn't seem to work. I have played a game for long on my Mediapad, and I would like to copy that game to my phone. Unfortunately, my Mediapad is not rooted and losing all that game progress has become a nightmare. I have written to the app developer to provide some sort of backup using either Google Play Games or social media integration like Facebook/ Twitter, but haven't received any response.
3. How to force apps (esp. file managers & gallery apps) to use in-app media viewer without changing system default.
For example, I may use the stock gallery app as default for viewing media. But if I am using another gallery app or a file manager that is capable of viewing media files using its own media viewer, I would rather want it use it than open the default app. Is there a way to do it?
4. Replace stock file manager (a system app) with another app from Google Play Store or other sources. Is this possible?
I am not asking how to convert a user app into system app. I know that part. I tried replacing the apk file of the stock file manager with a 3rd party apk, even renamed it, but it didn't work.
5. Extract a system app from one device and install it on another device without root. Is this possible?
I have tried it, but apk installation fails. For example, Samsung Gallery app on OnePlus phones.
iOS
1. How to install .ipa (iPhone app) on an iPhone (not jail-broken) without a laptop (iTunes)?
2. Is it possible to have SFTP server for iPhone?
All Operating Systems
1. How to provide LAN only access for non-rooted devices as well as in Windows & iOS?
For rooted devices, we have apps like AFWall+ that can do it. But is there a way to do it for devices without root, as well as for Windows and iOS?
For non-rooted devices, we have apps like Netguard that support 'Allow LAN access' whilst blocking internet access.
Are there any alternatives and solutions for other platforms?
2. How safe is it to enter login credentials in an app to allow it access to network drives?
I use several apps (on various platforms) to connect to my laptop over SMB. This requires me to provide the app with my Windows Login Credentials, which is a Microsoft account. Am I risking my account by providing this info to the app? Is it safe to enter login credentials of cloud services in file manager apps?
Just bumping this thread as it seems to have been lost/ unnoticed.
@Ultramanoid can you answer some of these?
Sridhar Ananthanarayanan said:
@Ultramanoid can you answer some of these?
Click to expand...
Click to collapse
Can't help much, sorry. As to Android, some notes :
1. Never have used an OEM / Google's version of Android, or anything other than rooted single-user systems.
2. In addition to the previous answer, I'm not a gamer.
3. I usually don't ever set defaults with some rare exceptions, so I am always given a choice of what I want to use to handle a file. It may vary depending on many things; I may want to edit an SVG file as text, or view it as an image, for instance. There are applications / services that will intercept intents to allow you to do this sort of thing as well, but I can't recommend a specific one, never use them myself.
4. Possible, but will break Android as by now the system requires it as a file picker in many instances without recognizing alternatives and developers of most applications do expect it as well and their services will not work without it. Don't do it. With recent Android storage changes, including the scoped storage debacle, this is not a viable option anymore.
5. Depends, but not likely as a general rule, specially for OEM garbage, which relies on their own proprietary modifications of Android, their libraries, frameworks, et al. You'd have to carry those over to the destination too, which may not even be possible. Use OEM-independent and not Google Services reliant applications. ( Edit : you'll find some of those applications built to install on all devices here on XDA by single developers, "SONY camera for all devices" and that sort of thing, not recommended anyway, not well supported or long-lived experiments. )
Ultramanoid said:
Can't help much, sorry. As to Android, some notes :
1. Never have used an OEM / Google's version of Android, or anything other than rooted single-user systems.
2. In addition to the previous answer, I'm not a gamer.
3. I usually don't ever set defaults with some rare exceptions, so I am always given a choice of what I want to use to handle a file. It may vary depending on many things; I may want to edit an SVG file as text, or view it as an image, for instance. There are applications / services that will intercept intents to allow you to do this sort of thing as well, but I can't recommend a specific one, never use them myself.
4. Possible, but will break Android as by now the system requires it as a file picker in many instances without recognizing alternatives and developers of most applications do expect it as well and their services will not work without it. Don't do it. With recent Android storage changes, including the scoped storage debacle, this is not a viable option anymore.
5. Depends, but not likely as a general rule, specially for OEM garbage, which relies on their own proprietary modifications of Android, their libraries, frameworks, et al. You'd have to carry those over to the destination too, which may not even be possible. Use OEM-independent and not Google Services reliant applications. ( Edit : you'll find some of those applications built to install on all devices here on XDA by single developers, "SONY camera for all devices" and that sort of thing, not recommended anyway, not well supported or long-lived experiments. )
Click to expand...
Click to collapse
Thanks very much. But I wish you answered the last 2 questions as well.
If time permits, would you be interested in telling us how you use your phone? I mean which device, which OS and what apps you use. I would like to give that a try (on a spare device) and see if it is possible for me to live without Google.
Sridhar Ananthanarayanan said:
Thanks very much. But I wish you answered the last 2 questions as well.
If time permits, would you be interested in telling us how you use your phone? I mean which device, which OS and what apps you use. I would like to give that a try (on a spare device) and see if it is possible for me to live without Google.
Click to expand...
Click to collapse
Didn't answer because it won't be helpful.
As to the 1st, I don't use LAN, and I don't keep data in any device or computer unless in use. External independent encrypted storage to be used wherever, whenever, independent of device, cables if needed.
As to the second, it's a matter of common sense, being informed of vulnerabilities and aware of reputation, and trust. Would you trust Chrome or Mozilla with data if you're online banking ? Seems reasonable -- but be aware of major vulnerabilities that may be going on. Would you trust an application released yesterday by a single developer for the same ? Probably not a good idea.
Finally, I doubt what I use and how I use it would be acceptable for you, or most people. In essence you could : Install latest firmware, wipe device, install latest security patched Lineage build for it, remove vendor / Lineage applications, get full root, remove anything you don't need or use which could have vulnerabilities; frameworks, libraries, binaries, etc ( Bluetooth, SMS, Android system-wide downloader, system-wide WebView, NFC, and on and on .. ), install your own binaries, fonts, hosts file, and applications where appropriate ( /bin /etc et al ), install Termux and all Linux packages required for your use, everything open source whenever possible, and stay away from any Google services / Play / applications with ANY trackers, analytics, data mining or even crash report capabilities; zero tolerance. Internet permission only for a secure web browser -- and terminal if / when needed. Half of what I do or use goes through terminal to be honest. In short, for me an Android device is a full Linux laptop replacement with added perks : Always on and on me, camera, GPS, pedometer, unlimited LTE data, and emergency calls for medics / police. ( Edit : And Japanese EEW alarm of course ! Only notification I use. We learned our lesson well in 2011. )
You can use ApkExport to extract any apk including system apks. I've transferred apks between other devices devices with it.
Never had need of doing that though with a system apk.