Develop Bugs

[Q] Q: Detection of Rooted Devices by Security Appliances

My question is an academic one, of sorts.
My workplace has recently permitted the use of personal devices at the workplace, and they are using a Mobile Iron appliance to "secure" and manage these devices.
A recent change to these appliances resulted in my rooted Incredible being blocked access to the system. The one answer I cannot seem to get a clear response on is how this was detected, as my device had been working in this capacity before a recent change to both the back-end appliance and the client on the device. Clearly, though, this is not the case for all devices, as I know of someone who is still successfully using a rooted Samsung Galaxy S.
I tried a couple of iterations to determine how it detected my rooted device, and, at this point I have returned it to stock with S-OFF. I am pretty confident that the latter is what triggered my device being detected and blocked.
So, anyone have any insight as to how these appliances/devices detect root? Are they inspecting at the hardware level as opposed to a scan of applications?
Looking forward to the discussion.

Assuming superuser no longer on the device?
Sent from my ADR6300 using XDA Premium App

Correct. I returned the device to stock FroYo (2.2), with no SuperUser.

On the sd card there is a log file that says s-off maybe it see that

That must not be the case, as I did not format my SD card when I returned to stock. The soff.log file is still there.
So, perhaps it is not looking at that low a level. Given what I am seeing, though, it is certainly not looking at the applications either.

jasonjthomas said:
That must not be the case, as I did not format my SD card when I returned to stock. The soff.log file is still there.
So, perhaps it is not looking at that low a level. Given what I am seeing, though, it is certainly not looking at the applications either.
Click to expand...
Click to collapse
I'm no expert by any means but I would think that its some type of script that runs asking for access permission to the phone that only a superuser would have. I have an authenticator for a blizzard account that always pops up with a message that running it on a rooted phone is dangerous, so I'm asuming there is some type of script imbedded in the app that lets it know its on a rooted phone by querrying for su access. Why your buddies phone is not being blocked has me stumped.

[Q] LUKS Full Disk Encryption

Has any one done any work on getting LUKS working on the Galaxy Nexus yet? I know ICS has encryption but it is not the same (It is file level; dm-crypt encryption and leaves room for data leaks).
For that reason does any know of a WhisperCore alternative?
Thanks!

ICS encryption is dm-crypt based whole partition encryption. See ht tp://source.android.com/tech/encryption/android_crypto_implementation.html for details.
Now it does seem to have lots of drawbacks, but i don't think luks would be much safer. Well, it seems they differ in the used encrypted key headers. Google could have got that insecure.
Just using the lockscreen password strikes me as a bad choice in googles solution.

textshell said:
ICS encryption is dm-crypt based whole partition encryption. See ht tp://source.android.com/tech/encryption/android_crypto_implementation.html for details.
Now it does seem to have lots of drawbacks, but i don't think luks would be much safer. Well, it seems they differ in the used encrypted key headers. Google could have got that insecure.
Just using the lockscreen password strikes me as a bad choice in googles solution.
Click to expand...
Click to collapse
You can tell the whole OS is not encrypted since you can make emergency calls when at the preboot authentication screen.Only /data is encrypted and thus leaves room for data leakage. WhisperCore just managed it perfectly- just like LUKS on a computer. Preboot authentication, ENTIRE disk encrypted (minus /boot), and secondary lock screen (login) password that can be anything include "pattern".
Not to mention ICS is only AES-128 bit, I mean c'mon why not just use 256 bit like everyone else? It's cleared by FIPS for a reason.

x942 said:
You can tell the whole OS is not encrypted since you can make emergency calls when at the preboot authentication screen.Only /data is encrypted and thus leaves room for data leakage. WhisperCore just managed it perfectly- just like LUKS on a computer. Preboot authentication, ENTIRE disk encrypted (minus /boot), and secondary lock screen (login) password that can be anything include "pattern".
Not to mention ICS is only AES-128 bit, I mean c'mon why not just use 256 bit like everyone else? It's cleared by FIPS for a reason.
Click to expand...
Click to collapse
changing the key length for encryption should be an easy thing when compiling from source. Not sure what's the performance impact and security gain.
Having different crypto passphrase and screen unlock code might be a good thing, but if i start caring about encryption of my phone i'd try to push the key into the smartcard inside every phone (SIM card) and just enter the smartcard pin. Depends on amount of paranoia wrt security of these cards though.
But i don't understand why you would like to encrypt /system with a stock ROM. Nothing gained there. /system is read only so it can't really leak data. And as the kernel in the boot partition is unencrypted and unauthenticated anyway the OS code is open for changes anyway.
Without special hardware help or keeping the boot media separate and very safe, encryption will always only work against simple thiefs. If your attacker can get the phone do something to it and return it without you getting suspicious you lost anyway. Assuming he can get it again once you booted and used the phone again.

textshell said:
changing the key length for encryption should be an easy thing when compiling from source. Not sure what's the performance impact and security gain.
Having different crypto passphrase and screen unlock code might be a good thing, but if i start caring about encryption of my phone i'd try to push the key into the smartcard inside every phone (SIM card) and just enter the smartcard pin. Depends on amount of paranoia wrt security of these cards though.
But i don't understand why you would like to encrypt /system with a stock ROM. Nothing gained there. /system is read only so it can't really leak data. And as the kernel in the boot partition is unencrypted and unauthenticated anyway the OS code is open for changes anyway.
Without special hardware help or keeping the boot media separate and very safe, encryption will always only work against simple thiefs. If your attacker can get the phone do something to it and return it without you getting suspicious you lost anyway. Assuming he can get it again once you booted and used the phone again.
Click to expand...
Click to collapse
Not true. You an relock the bootloader on the Nexus phones, this completely prevents evil maid attacks. Secondly if I ever lose my phone and "happen to get it back" the first thing I am doing is wiping it and selling it for another one.
If you have ever use encryption you would know that the less an attacker knows the better. Hence encrypting the entire system is better than only encrypting a partition.
I don't like how Google implements dm-crypt. It would be more secure if the entire device was encrypted as it would completely look like random data to an attacker.
Why would you only encrypt your home folder and not every thing BUT /boot?
I prefer the whispercore way of doing it. I poweroff and you can't access anything except the login screen.

x942 said:
Not true. You an relock the bootloader on the Nexus phones, this completely prevents evil maid attacks. Secondly if I ever lose my phone and "happen to get it back" the first thing I am doing is wiping it and selling it for another one.
Why would you only encrypt your home folder and not every thing BUT /boot?
Click to expand...
Click to collapse
I don't think trusting the locked bootloader is a good idea. Look for e.g. "unbrickable mod" for an example how a lot of samsung phones can be forced to bypass the bootloader on the internal flash and forced to load arbitrary code from outside. So if somebody is willing to do an evil maid attack, they will likely do enough research to know these kinds of backdoors in your hardware platform. JTAG is another usual way. Or whatever the phone manufacturer uses to unbrick phones. I think it prudent to assume any sufficiently founded attacker will have unrestricted read/write access.
And why only encrypt real data? Speed gain for no measurable loss in security. At least from the google perspective. Google will rightfully assume customers are using official ROMs and the exact bit patterns of there are publicly available to everyone. So why waste cpu cycles to encrypt them. What could be useful would be integrity protection.
But while a fully integrity protected boot under the control of the enduser would be very nice (with a bootloader that's unlocked but needs a key or password) if only the manufacturer gets to authorise new software it's evil.

textshell said:
I don't think trusting the locked bootloader is a good idea. Look for e.g. "unbrickable mod" for an example how a lot of samsung phones can be forced to bypass the bootloader on the internal flash and forced to load arbitrary code from outside. So if somebody is willing to do an evil maid attack, they will likely do enough research to know these kinds of backdoors in your hardware platform. JTAG is another usual way. Or whatever the phone manufacturer uses to unbrick phones. I think it prudent to assume any sufficiently founded attacker will have unrestricted read/write access.
And why only encrypt real data? Speed gain for no measurable loss in security. At least from the google perspective. Google will rightfully assume customers are using official ROMs and the exact bit patterns of there are publicly available to everyone. So why waste cpu cycles to encrypt them. What could be useful would be integrity protection.
But while a fully integrity protected boot under the control of the enduser would be very nice (with a bootloader that's unlocked but needs a key or password) if only the manufacturer gets to authorise new software it's evil.
Click to expand...
Click to collapse
Yes but as I said any one that would put that effort in would have to get the phone from me (which I carry 24/7) and once I know I no longer have control of it I would (as I said) reset it and sell it. You are basically saying all Full Disk Encryption (including on computers) is useless because someone can modify the bootloader. I hate to say it (and this is not directed to any one in this thread) but only a true ignorant person would fall victim to a evil maid attack, It is common sense NOT to trust something that you lost control of.
My situation is different: I run a non-profit organization and my employees need to carry sensitive data with them. Why risk security with the built in dm-crypt when something like WhisperCore is much better? I don't won't an attacker knowing ANYTHING about the device.
ICS built in encryption is just as useful as Home folder encryption in Linux. Your data may be safe but an attacker can ascertain how much data is there. And in some case use this information to infer what data may be present on the device. This is why most people using encryption use FDE and not just home folder encryption. When you are done there should be absolutely no way for anyone to tell the encrypted partition from random data (wiped data).

No, i'm just saying the full partition encryption of /data is enough on galaxy nexus and that you can't protect from an evil maid attack except by drastic measures after you lost control of your phone.

Understandable but I respectfully disagree. I want FULL DISK Encryption not Partition encryption. Take a look here: http://en.gentoo-wiki.com/wiki/DM-Crypt_with_LUKS#Security_levels
Either way (even if it is secure enough) It's not going to get approved for me to use in a work environment (FIPS 140-2). This is why I need some like WhisperCore. We handle sensitive data at my company.

[Q] Can you secure Photos on SDCARD?

With everything going on in the news with apps being able to read your media I was wondering how easy it is for someone to access your information from your phone.
While on the phone you can use a pin or password to prevent someone from going into your phone and I know that there are apps that will individually allow you to password protect individual apps or even "hide" your media if someone gets your phone. You can do a remote wipe of the card with some of the security software but you have be quicker than the "thief" in activating the wipe.
What I have not been able to figure out is how I would protect the SD Card on the phone if someone pulled it out before I had a chance to do a remote wipe. I have not seen anything, with a general search, that will block access on the SD Card if someone puts it in a computer. Other than not loosing my phone what options are out there?
I am running a rooted EVO 4G using the Senseless version of tommytomatoes Classic Rom.
Thanks for any suggestions.
Doc
Thanks for any suggestions.

Encrypt the card?
-------------------------------------
Sent from my Dell Streak 7

Yes Encrypt the card
HTC Desire HD
with
iCeColdSandwich
by LorD ClockaN

If I encrypt the card won't it prevent the other apps from accessing data on the card? Also what will that do to the function of the apps that have been partially moved to the SD Card?
Is there a step by step on how to encrypt?
Thanks,
Doc

What I feel we really need is an app that manages permissions instead of having to blanket allow an app it would be nice if I had another app that could block some of those permissions if I feel like it , sure it may break the app using those apps but control and security are more important, maybe a toggle feature so you can toggle permissions for various apps and sort them by permission type. I have no idea if this can be done, I'm just an end user that sees a need. What do you guys think?
As for the op , in some cases your just screwed , nothing can ever be 100% secure , who is to say even if encrypted it can't be cracked ? And encrypting the sd card but allowing apps access defeats the purpose if the thief can access the data through those apps before you can start a remote wipe.
Sent from my SCH-I510 using Tapatalk

I wish someone would solve this problem as soon as possible, looking forward to it

I realize that not everything is 100% but it seems silly that no matter what precautions I take by using a pin lock or pass-phrase, it can be circumvented just by removing the SD Card. Of course if I encrypt the card then many of the apps may not work unless they have the functionality to decrypt/encrypt on the fly.
I just need to make sure to remotely wipe the card if I ever loose the phone.
Thanks to everyone who responded.
Doc

.
Thread moved. Would advise you to read forum rules and post in correct section.
Failure to comply with forum rules will result in an infraction and/or ban depending on severity of rule break.

You can store it at Meero instead. It's free and the storage is unlimited. The most advanced portal for pro photographers at the moment guaranteed.

[Q] Copy tag to phone

Hi
Here at the university we use a NFC card to check in. Is it possible to copy the tag to my phone so I don't have to carry my student card around?

Depends
Sent from my LS670 using XDA

Shark_On_Land said:
Depends
Sent from my LS670 using XDA
Click to expand...
Click to collapse
Wow, helpful much?
I'd like to know this too.

thx
arjun rajput

+1
I like to know this to.

(Here at the university we use a NFC card to check in. Is it possible to copy the tag to my phone so I don't have to carry my student card around?)
Hi Samuel
I believe this is not possible right now, as there are security measures in place to prevent fraudulent use, but give it a couple of months there will be apps you can download , to copy re-writeable NFC tags to your phone, making your phone work as an emulator of some sort.

virus007 said:
(Here at the university we use a NFC card to check in. Is it possible to copy the tag to my phone so I don't have to carry my student card around?)
Hi Samuel
I believe this is not possible right now, as there are security measures in place to prevent fraudulent use, but give it a couple of months there will be apps you can download , to copy re-writeable NFC tags to your phone, making your phone work as an emulator of some sort.
Click to expand...
Click to collapse
To emulate cards with your NFC phone, you have to have full control of the secure element. In the Nexus phones, access to the secure element is restricted to Google - only they have the codes to access it. In non-Nexus phones like the SGS2, they don't even have built-in secure elements and therefore have to rely on SIMs, which are in turn controlled by operators. Without access to the secure element, you won't be able to emulate another card. So, no, even in a few months you won't be able to copy a tag and emulate it from your phone. Unless Google opens up the secure element to, which is unlikely.
To OP: Even if you could actually copy the contents of the card and then emulate it, this might not be enough. Many schools use just the UID of the card to associate it with your account on their system. This means that there's a good chance that your card actually has no data on it. Furthermore, phones aren't currently able to emulate UIDs. You're out of luck.

LoveNFC said:
To emulate cards with your NFC phone, you have to have full control of the secure element. In the Nexus phones, access to the secure element is restricted to Google - only they have the codes to access it. In non-Nexus phones like the SGS2, they don't even have built-in secure elements and therefore have to rely on SIMs, which are in turn controlled by operators. Without access to the secure element, you won't be able to emulate another card. So, no, even in a few months you won't be able to copy a tag and emulate it from your phone. Unless Google opens up the secure element to, which is unlikely.
To OP: Even if you could actually copy the contents of the card and then emulate it, this might not be enough. Many schools use just the UID of the card to associate it with your account on their system. This means that there's a good chance that your card actually has no data on it. Furthermore, phones aren't currently able to emulate UIDs. You're out of luck.
Click to expand...
Click to collapse
Clearly, a direction NFC will follow. There's no way users will allow something like that to remain as neutered as it currently is. It just (seemingly) has not worked that way in the past.

thanks
thanks

External SD Card not writeable in TB on 8.4?

I know it's early on but I rooted my Samsung galaxy tab 8.4 and I am trying to do a backup of my apps and I cant do a backup to my external sd card. TB is saying it isn't writeable. I have used the back button and such to manually change the directory. I'm familiar with doing that. I can backup to internal storage but obviously I don't want to waste the space when I have a 64gb micro sd card. Thanks for the help.

bckrupps said:
I know it's early on but I rooted my Samsung galaxy tab 8.4 and I am trying to do a backup of my apps and I cant do a backup to my external sd card. TB is saying it isn't writeable. I have used the back button and such to manually change the directory. I'm familiar with doing that. I can backup to internal storage but obviously I don't want to waste the space when I have a 64gb micro sd card. Thanks for the help.
Click to expand...
Click to collapse
I can confirm the same issue. I've verified that the root directory is set to R/W using "Root Explorer" from the play store. For some reason, I can't get TB to see it as R/W, though.
Saving other items to the external card seems to work just fine. Camera saves there, no issues. Weird.

leatherneck6017 said:
I can confirm the same issue. I've verified that the root directory is set to R/W using "Root Explorer" from the play store. For some reason, I can't get TB to see it as R/W, though.
Saving other items to the external card seems to work just fine. Camera saves there, no issues. Weird.
Click to expand...
Click to collapse
It will get figured out soon enough. im just happy to be able to do a titanium backup. Lots of work installing stuff

I couldn't even create a Nova backup to the external SD card
Sent from my SM-T320 using Tapatalk

CAR1977 said:
I couldn't even create a Nova backup to the external SD card
Sent from my SM-T320 using Tapatalk
Click to expand...
Click to collapse
It is a 4.4 permissions issue. I found a possible fix if it works I will post it.
This worked for me. You have to be rooted to do it though.
http://forum.xda-developers.com/showthread.php?t=2617921

nrage23 said:
It is a 4.4 permissions issue. I found a possible fix if it works I will post it.
This worked for me. You have to be rooted to do it though.
http://forum.xda-developers.com/showthread.php?t=2617921
Click to expand...
Click to collapse
Confirmed, this works. Nice find!

Where did you find root?
Sent from my GT-I9505 using XDA Premium 4 mobile app

uberboyd said:
Where did you find root?
Sent from my GT-I9505 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
Root was achieved yesterday. CF Auto Root

i am rooted and using es file explorer. when i try to save it a box keeps coming up saying an error occurred cannot save.
got it. have to mount the system.

bckrupps said:
i am rooted and using es file explorer. when i try to save it a box keeps coming up saying an error occurred cannot save.
got it. have to mount the system.
Click to expand...
Click to collapse
Root explorer works much better for modifying root directory the ES does.
Sent from my SM-P600 using XDA Premium HD app

nrage23 said:
Root explorer works much better for modifying root directory the ES does.
Sent from my SM-P600 using XDA Premium HD app
Click to expand...
Click to collapse
Yea thats what i figured out. So nice to be able to back up to the sd card and the process literally took a minute. Cool find.

I was able to fix this issue by simply installing Folder Mount. When you first open folder mount will offer to repair this permission issue for you. I said yes and it worked. Folder mount also stated this is specific to Sammy 4.4 roms... Just an FYI. Thought I would share.
Sent from my SM-T320 using Tapatalk

Unfortunately, it's not something that Samsung decided to do, it's something Google started back in Android 3.2 and is now apparently asking OEMs to follow their lead on - or else the OEMs aren't reading the codebase much, which I think is also a problem.
The external storage permssions were spotted and commented on by Chainfire (he who gave us root, hallowed be his name ) in 2012!
https://www.xda-developers.com/andr...-preventing-write-access-to-external-storage/
http://www.chainfire.eu/articles/113/Is_Google_blocking_apps_writing_to_SD_cards_/
I'm not 100% on this, but I think that the Samsungs are one of the first sets of devices to get KitKat and to have sdcards. (don't know what the status of the gpad 8.3 is) It will be interesting to see if the Gpad 8.3 does the same thing; I'm pretty sure the Tegra Note did, and then EVGA pulled back on their KitKat update due to bugs, of which this was one (glad they called it a bug, but if they'd looked at the code before implementing the changes...)
This issue goes way beyond the sdcard. Remember when your device could be connected to your computer and turn up as a mass storage device, not a media player or a camera?
The MTP protocol originally implemented by Google was hugely troublesome on that score when it was first introduced. There were absolutely insane failure modes. To get an accurate readout of what was on your device you couldn't disconnect from your computer and reconnect, you couldn't disconnect, reboot the Android device and reconnect - nope, you had to reboot your computer.
I haven't thoroughly tested failure modes but at least the warning on copy from PC to Android works correctly now.
When first implemented by Google, file deletions on in Android were not reported to the computer connected to it if they occurred while connected. So you could move a folder and then try to copy files that didn't exist, and Android wouldn't report the file was not there.
This is an example of silent failure, which is the worst possible failure mode. It gets beaten into the heads (or once did) of programmers that you always produce and report an exception on failure. Not doing so is negligent and might be actionable depending on the context.
I just deleted a file from the Samsung and it's taken more than 30 seconds for the Windows system to get information on what's on the Samsung.
Great - I also couldn't enumerate my local disk drives while I waited, more than 3 minutes (i7-2600k, 8 G ram - not a PC side issue!) I finally disconnected and reconnected the USB cable and was able to get my disks to populate immediately on disconnect, and an accurate poll from the Samsung on reconnect.
I suspect that Google's 'fix' for the not-notifying-on-delete bug is to throw a disk not ready message back at the host system.
So, why does Google not see any of the following as important?
- easy local disk mounting
- viable sdcard use
- well-written MTP implementation
I don't think it's about the cash - sure, Google's selling a few books and a few movies and such, but they're really an advertising broker; the revenue from that isn't why they're worth gazillions.
I think it's actually much more insane than that: Google is all about big data and the supremacy of databases over all else.
Including files themselves - Google wants to drive toward a world where files don't exist, only pointers in databases exist.
http://glasskeys.com/2011/02/28/why-google-uses-mtp-instead-of-usb-file-transfer-on-android-3/
is a perspective on MTP that is essentially diametrically opposed to mine - it's quoting Google as pointing out that there is both simplicity and allegedly a greater degree of security from MTP.
The security comes from the filesystem retaining 'nix style ACLs and helping to maintain sandboxing between applications by not exposing storage as a fat32 filesystem and thereby giving up granular access controls.
---------
(As an example of silent failure that I think may be the subject of civil litigation: the flaw that broke SSL/TLS validation on most Apple devices - phones, tablets and OS X based computers. If you look at the code, it's blindingly clear what happened.
http://appleinsider.com/articles/14...pdate-is-present-in-os-x-fix-coming-very-soon
http://arstechnica.com/security/201...aw-in-ios-may-also-affect-fully-patched-macs/
This flaw may well explain the Snowden documents that indicate that the NSA has access to any Apple device at will. When those documents were first being reviewed, there were two responses:
- it isn't true
- Apple is in bed with the NSA.
Ignoring a bug that easy to spot in a functional test for years tends to make me wonder if the second explanation may not hold water.)

Hopefully this can help someone. I couldn't edit my *.xml file even though I am ROOTED. But I found this:
https://play.google.com/store/apps/details?id=nextapp.sdfix
and it worked!! Now Titanium Backup is able to write successfully to my sdcard.

The app works great. I would recommend it for anyone on 4.4
Sent from my SM-T320 using XDA Premium HD app

PRESOLVED: My Tab is possessed by the devil!
When I tried to write a file to my Galaxy Tab Pro 8.4's external SD card with Astro and it wouldn't work I was flustered. A little research turned up the crippled SD support in KitKat and how to fix things with the simple platform.xml hack. I did that, and all was right with the world again.
Then I got another 8.4, and actually cloned the first one to the second one with a nandroid backup. I also moved my SD card from the first to the second. Eventually I sold the first one and am just left with the second one. But somewhere along the way I lost the ability to write to the SD card, and I can't get it back!
The hacked platform.xml file was of course cloned along with everything else, but it just doesn't work. What's just as bad, or worse, is that apps which should write to external SD even without the hack (and which did, prior to this issue developing), such as Samsung's My Files, and Root Explorer, also are no longer able to!!!!
So to try and fix things, I flashed this ROM to my Tab: http://forum.xda-developers.com/showthread.php?t=2698460 But I still can't write to external SD, even with My Files!
Here's another problem, which may or may not be related: I also can't write to the external SD with the Tab connected to my computer. With a small file, the progress bar immediately jumps to 100% but then freezes and after a long time the copy times out with the message, "The device has either stopped responding or has been disconnected". With a large file the progress bar plods along, first at a normal speed but gradually getting slower and slower, until at some point it stops moving and the copy times out.
Please, I beg of you, help me exorcise my demon Tab!
SOLUTION: Before actually posting this plea for help, I re-formatted my SD card (in the Tab) and all functionality is restored. I post this at risk of making myself look like an idiot, in hopes that it might save someone else's hair.

Good on you for posting the problem and the solution. I doubt you'll be the only person to experience this.
Sent telepathically to my Galaxy S4

droidmark said:
... I post this at risk of making myself look like an idiot, in hopes that it might save someone else's hair....
Click to expand...
Click to collapse
From that comment it seems we need more bald users as no risk testers.
Sent from my Nexus 10 using XDA Premium HD app

droidmark said:
When I tried to write a file to my Galaxy Tab Pro 8.4's external SD card with Astro and it wouldn't work I was flustered. A little research turned up the crippled SD support in KitKat and how to fix things with the simple platform.xml hack. I did that, and all was right with the world again.
Then I got another 8.4, and actually cloned the first one to the second one with a nandroid backup. I also moved my SD card from the first to the second. Eventually I sold the first one and am just left with the second one. But somewhere along the way I lost the ability to write to the SD card, and I can't get it back!
The hacked platform.xml file was of course cloned along with everything else, but it just doesn't work. What's just as bad, or worse, is that apps which should write to external SD even without the hack (and which did, prior to this issue developing), such as Samsung's My Files, and Root Explorer, also are no longer able to!!!!
So to try and fix things, I flashed this ROM to my Tab: http://forum.xda-developers.com/showthread.php?t=2698460 But I still can't write to external SD, even with My Files!
Here's another problem, which may or may not be related: I also can't write to the external SD with the Tab connected to my computer. With a small file, the progress bar immediately jumps to 100% but then freezes and after a long time the copy times out with the message, "The device has either stopped responding or has been disconnected". With a large file the progress bar plods along, first at a normal speed but gradually getting slower and slower, until at some point it stops moving and the copy times out.
Please, I beg of you, help me exorcise my demon Tab!
SOLUTION: Before actually posting this plea for help, I re-formatted my SD card (in the Tab) and all functionality is restored. I post this at risk of making myself look like an idiot, in hopes that it might save someone else's hair.
Click to expand...
Click to collapse
Just wanted to add a postscript for anyone who might have a similar issue. I thought this problem was solved, as described above. Then a few days later when I booted up my tab, the SD card was shown as blank/unformatted. At that point I did some more digging and determined that it was actually a counterfeit 32GB card, based on an 8GB card. Got a refund, threw it in the trash and ordered a new 64GB card. Caveat emptor!