Related
I'm looking for some screen locking and encryption software for Windows Mobile 6 (or 6.1).
I'm looking for software that will lock the screen and buttons when the PDA is turned on, and require a password, either PIN or button entry.
I would also especially like a poison pill where the system would hard reset after a number of password failures, or failing that, at the very least it would autodelete the internal memory and PIM data. It would also be great if such a program had an OEM install for adding to one of DCDs ROMs, but that's more wishful thinking than an actual requirment.
I would be willing to pay for this software, but freeware is my first choice for obvious reasons.
Thanks to anyone who can help out.
Currently running Telus P4000 (aka Titan) with DCD 2.3.2, but willing to reflash to get the security software runing if necessary.
ncotton said:
I'm looking for some screen locking and encryption software for Windows Mobile 6 (or 6.1).
I'm looking for software that will lock the screen and buttons when the PDA is turned on, and require a password, either PIN or button entry.
I would also especially like a poison pill where the system would hard reset after a number of password failures, or failing that, at the very least it would autodelete the internal memory and PIM data. It would also be great if such a program had an OEM install for adding to one of DCDs ROMs, but that's more wishful thinking than an actual requirment.
I would be willing to pay for this software, but freeware is my first choice for obvious reasons.
Thanks to anyone who can help out.
Currently running Telus P4000 (aka Titan) with DCD 2.3.2, but willing to reflash to get the security software runing if necessary.
Click to expand...
Click to collapse
I don't know about a program will hard reset the phone on failure to authenticate, that is a hard one. But your phone should already have a security feature were you can add a pin to lock your phone or add a longer password.
Every time you boot up it will prompt you for a password.
built in security
The built in security can be bypassed by connecting to activesync, which is one of the reasons I want to replace it.
ncotton said:
The built in security can be bypassed by connecting to activesync, which is one of the reasons I want to replace it.
Click to expand...
Click to collapse
How can you bypass it through active sync?
I mean when I set the password and connected through active sync, it wouldn't sync or read unless i typed in the pin on my phone. It prompted me first and if i was unsuccessfull it would kick me off and not let active sync work.
PIN entry on PC
It's also possible to enter the PIN from the PC side (at least with WMDC on vista), which means it's easy to brute force the PIN.
There are programs that can do this, matter of fact, there are security programs out there that can remotley flash your phone should it ever get stolen or lost. Normally they are set up that you send a certain text mesage to your phone and it wipes itself clean. I just did a google search and found this: mSecure PDA
Features:
Function
Enforces security policies Windows Mobile, Palm OS and Symbian devices
Broad platform support including Windows Mobile, Palm OS
Reliable and automatic data protection, without downgrading the user experience
Protection on device or removable media using centrally-controlled, policy-based security
Remote data destruction if device is lost, stolen or subject to misuse
Sadly
"You're just a couple of steps away from an mSuite trial... Remeber that mSuite is for Enterprises only, requires a minimum of ten users for purchase and as an installer you will need Administrator rights to your corporate server. "
Click to expand...
Click to collapse
Cite
The price is ok, if I only had to buy it once that is. It seems like most of the software that does this is enterprise only.
There's another one called SafeGuard PDA but they discontinued the single user version before they got to WM6 compatability (and the WM5 version absolutely kills a WM6 device).
WM5
For anyone running WM5 who's looking at this thread someday, PocketSecure is a great program that does pretty much everything I was looking for but sadly isn't compatible with WM6 (or at least, the version I'm using anyway).
And I thought the cold war was over.
It seems if you guys want to get some James Bond gadgetry on your phones.
I understand this because we keep highly value data in our phones, but even if we do lose our phone they are is always a way to crack any locking mechanism or security measure if they have physical access to your device.
I mean if the other person is smart enough to do so.
True enough
I'm not planning on keeping national secrets on my PDA, it's just that I would like to keep some phone numbers on there that I don't want someone stumbeling upon if I'm draft enough to lose my phone or someone is quick enough to lift it.
The annoying thing is that there's a lot of decent software like this for Palm platforms. (TealLock, etc).
ncotton said:
I'm not planning on keeping national secrets on my PDA, it's just that I would like to keep some phone numbers on there that I don't want someone stumbeling upon if I'm draft enough to lose my phone or someone is quick enough to lift it.
The annoying thing is that there's a lot of decent software like this for Palm platforms. (TealLock, etc).
Click to expand...
Click to collapse
All security measures should start at the physical level. By not allowing others to steal our phones or lose them, but if you feel that you need software to secure your phone in any way check out.
http://www.handango.com/SoftwareCat...E97X&platformId=2&osId=993&N=4294913805+95886
they have many types of software that could help you. It is a start, better to be protected then not.
[email protected]$
Sorry mate, I'm not sure if I'm just missing something there or if I didn't what I'm looking for properly...
I've looked through the handango store and while it's got plenty of good software for encrypting a file (word doc etc) and plenty of good stuff for storing extra data like passwords and credit card info, all I really want is something that will lock the PDA and the built in PIM (contacts mainly) inforamation.
I'm *not* looking for a way to encrypt my storage card or individual files in main memory (and I've already got a password managent program that encypts that data and syncs it with my laptop).
P.S. It's not like I don't plan on keeping my phone secure, but the idea is that good security STARTS with physical security, it doesn't end there.
ncotton said:
Sorry mate, I'm not sure if I'm just missing something there or if I didn't what I'm looking for properly...
I've looked through the handango store and while it's got plenty of good software for encrypting a file (word doc etc) and plenty of good stuff for storing extra data like passwords and credit card info, all I really want is something that will lock the PDA and the built in PIM (contacts mainly) inforamation.
I'm *not* looking for a way to encrypt my storage card or individual files in main memory (and I've already got a password managent program that encypts that data and syncs it with my laptop).
P.S. It's not like I don't plan on keeping my phone secure, but the idea is that good security STARTS with physical security, it doesn't end there.
Click to expand...
Click to collapse
Hmm I have looked for some apps that describe your needs and found some, but they are for WM5 ...... you can try it out and see if it works. As some cabs from WM5 still work..
Well here is another website that might help out..
http://pocketpccentral.net/software/security.htm
Other then that I would recommend using google to search for your needs due to the fact that not many people here post about this.
http://www.truecrypt.org the windows version can install a program to mount a truecrypt encoded card on your PPC, but so far I dont think it can encrypt on it.
also found this http://www.microsoft.com/downloads/...CF-EF96-4567-B817-215E24668F75&displaylang=en
Dont know if these help, worth a look maybe.
Someone mentioned this in another thread, but this is a topic that should have it's own separate thread.
Some of you may have already read the news: Michigan: Police Search Cell Phones During Traffic Stops
Don't assume it won't come to your town.
I can't say I plan to do anything that would warrant police suspicion, yet I don't like the idea of anyone being able to easily pull data from my device. And we know cops won't be the only ones with these devices. So I've been wondering, how can we protect our Android devices from the CelleBrite UFED?
Check out this video that shows some of the features it has, keep in mind it does much more and can even extract DELETED data.
See the company's product page here: http://www.cellebrite.com/forensic-products/ufed-physical-pro.html
This research paper talks about the CelleBrite UFED and other extraction methods. (CelleBrite UFED is talked about starting on page 9.) I doubt there's a means to prevent all of those methods given some involve long term handling of the device, but CelleBrite UFED can extract data when a device is retained by the CelleBrite UFED user for a short period of time. It looks like HTC Android type devices can only be extracted from via the (micro)USB Port and it requires USB Storage and USB Debugging turned on. The CelleBrite UFED has to gain Root Access. It can get by screen passwords and root even a device that was not yet rooted.
There's another thread where someone was requesting a ROM that would not work with the CelleBrite UFED. I'm not sure how to make a ROM or anything else that would not work with the CelleBrite UFED without limiting certain features we all may use from time to time.
Over on Slashdot, someone said they hacked their device (Nexus One) to not do USB client mode. This is another option that would limit some features many of us may use.
So, how can we protect our privacy and our data? Does it mean sacrificing some features like USB storage mode?
The biggest problem is what's missing from Android itself. Meego might be protected but not Android.
You would need an encrypted boot loader that retains root for some users.
A kernel and os files that support different users so the default user is not root like Linux and a prompt with a password for superusers not just an Allow like now for Android.
Encryption libraries that would support truecrypt encryption of both internal and external (SD card) encryption in toto not just individual files.
A true trash system that overwrites files like srm in linux and sswap for wiping the swap file after every system reboot.
Ultimately I don't see it happening. In theory if you were running Ubuntu on your phone then yes cellbrite would just crap out not knowing what to do with your phone. Same possibly with meego. But then no real app support, no navigation and driver support is crap even for ROMs using the same os let alone a different OS like true linux.
It's amazing how many don't even bother deleting thumbnails hanging around on their computers or securely wiping files on their computer. Same with swap files retaining passwords or even website cookies that have the same password as their computer.
Best thing to do, don't keep anything that could be bad on your phone. Use a cloud system or home server sync that requires a seperate login every time and keeps no local files. Or as I do, encrypt the hell out of anything you find valuable, which currently is only my complete backups...
Sent from my Xoom the way it should be, rooted and with SD card.
This is where that cheap Boost Mobile phone comes in, or any other prepay phone. Just hand the officer that one. Store your personal data on your smartphone.
chbennett said:
Best thing to do, don't keep anything that could be bad on your phone. Use a cloud system or home server sync that requires a seperate login every time and keeps no local files. Or as I do, encrypt the hell out of anything you find valuable, which currently is only my complete backups...
Sent from my Xoom the way it should be, rooted and with SD card.
Click to expand...
Click to collapse
Hello, All. This is my first post at xda-developers!
Since I'm new to Android, data security has concerned me. Climbing the learning curve of rooting and tweaking my SGH-T989, I've focused on control, security, and privacy. So far pretty good, thanks largely to members' posts at this site. Thank you very much!
Then this thread crushed me. Visions of "1984", "THX 1138", "Terminator", etc.
I considered the suggestions here. Thoughts about the OS seem right to me, but that's beyond my abilities. I did try following chbennett's advice: I enabled encryption in my backups and moved them to the internal SD.
But I don't yet know how to do the 'home server / log in on demand' scheme for contacts and calendar. I will appreciate any help with that.
Meanwhile, I looked for a way to make a 'panic button' that would let me wipe my phone immediately. What I chose was making a contact whose phone number is the USSD code for Factory data reset.
Maybe Tasker, etc. could streamline this approach; but my trials showed that, unlike MMI codes (e.g., to toggle caller ID blocking), USSD codes cannot be submitted to the OS indirectly. So swiping a contact, direct dial shortcut, etc. did not work. On my phone, all that worked was either 1. manually dialing the code, or 2. dialing the contact name, then tapping the contact.
So the routine to use this 'panic button' is:
1. launch Dialer
2. dial the contact name
3. tap the contact name in the search results
4. tap "Format USB storage" in the "Factory data reset" dialog
5. tap "Reset phone" button in the "Factory data reset" dialog.
It sounds clunky, but it's actually pretty quick. I named the panic button contact "XXX" to avoid confusability when dialing (it needs only "XX" for a unique match.)
If you can suggest improvements to this scheme, or think it is misguided, please let me know. Thanks.
Any updates on this? I'm curious as to how to guard against ufed.
I think an instant hard brick option would be better so theres nothing to recover as i dont believe the factory reset is a secure wipe
Possibly a voice activated secret phrase or keypress u could say/do super fast in a tricky situation that autoflashes a corrupt/incompatible bootloader and recovery to device after secure superwipe that should stump them for awhile
im still interested in this i disabled usb debugging on my phone but unsure if the UFED can still access anything on my ICS full encrypted passworded evo3d im assuming they could dump the data at most but i highly doubt they could access the decrypted data unless you used an insecure pass
If you have encryption enabled for your data partition, then all you need to do is to turn off your phone when you see a cop. If they take it from you, they can turn it on and hook up their device, but they will only be able to snarf the system partition, which does them no good. They'd need your password to mount the data partition.
If you look around on this forum, you can find the steps necessary to switch the lock screen back to a simple pattern lock while leaving the disk encryption enabled.
Are you sure Cellebrite and UFED or w/e can't access encrypted data partion? I know it can take an image of the phone "hard drive". They then can run password tools against image to unlock it no?
dardack said:
Are you sure Cellebrite and UFED or w/e can't access encrypted data partion? I know it can take an image of the phone "hard drive". They then can run password tools against image to unlock it no?
Click to expand...
Click to collapse
I'd like to know about this too. I am about to set up encryption on my device and I'd like to know more about what type of attacks it can beat.
Edit to add: I assume brute force attack protection is like any other type of encryption.....dependent on the strength of your password. But, assuming we all know that already, I'm still curious about this.
If the question is how to protect your device when you think someone would scan your phone, you'd have to have some sort of inclination that a scan is about to happen. I'm assuming this is many people's concern as they're considering wiping their device through a quick process. In that scenario, just turn off your device. Unless you warrant suspicion of something fairly bad, they wouldn't be confiscating your cell phone.
smokeydriver said:
...Unless you warrant suspicion of something fairly bad, they wouldn't be confiscating your cell phone.
Click to expand...
Click to collapse
We all wish all law enforcement was just and honest, but so far in world history that has not been the case. Even a pretty woman may have her phone scanned by a curious cop snooping for pics.
Sent from my HTC One using Tapatalk 2
I would still like to know if there is an answer here...
So I recently had some dealing with assisting in a Cellbrite search. We initiated and enlisted the help of law enforcement for an employee who was doing some illegal activity which is not relevant to this discussion other than the person used an iphone. Anyway, the investigator came in and wanted to know if I can enable the bypass for the automatic screen lock in 5 minutes because when it locked, it disabled the Cellbrite copy.
Now, couple things here, he was only doing what he was "allowed' to do in the local municipality, and he did say they sell a more expensive Cellbrite device which would be able to crack it. I did find it interesting that the simple corporate Activesync policy I have set up was actually having this effect. Anyway I removed the policy and it worked. Funny thing is he could have done it himself had he known anything about that kind of thing. He was presented to us as an expert but I guess that mainly covered a basic Cellbrite expertise.
So, I do think encryption would be a great answer as the partition would be hard to bust in to. Nothing is impossible but I would rather not smash my phone on the highway next time I get pulled over so I would like to know definitively that this is the right approach. This is definitely not paranoia as there are at least 3 states where it looks like it happens regularly.
Time to look at a 2600 group for stuff like this I guess. I am early in my investigation
Later
Samsung's site indicates the sgs2 has hardware encryption, but I can't find anything describing how to use it. Can anyone here offer any guidance or leads?
If anything it looks like the GS2 might be "Self Encrypting". Self Encrypting devices generate an internal random "key" when initialized and then use that to encrypt-and-store/decrypt-and-read data to/from the physical storage media (in the case of an HDD, a disk platter, in the case of an SSD or the Phone, Flash Chips).
You (the user) can't control the process, there's no way to specify the key or whether or not the encryption occurs. But if you were to disassemble the phone and remove the Flash chips, you wouldn't be able to (easily) extract data from those components.
If you password protect/lock you phone, if someone wanted to get data off the internal Flash chip(s), this prevents them from doing so. Accessing the data unencrypted would require the phone to be unlocked, first.
The external Flash doesn't have any capability to encrypt as far as I can tell, but if Sammy put an AES-certified encryption engine in to the phone's silicon, odds are there's a method to gain access to the HW, and applications could probably be written to take advantage of it for something like "external" storage...
I don't remember of voice traffic is encrypted or not. I suspect "not", at least not by default. But it's certainly possible Sammy included the feature for this purpose as well.
hchxoom said:
Samsung's site indicates the sgs2 has hardware encryption, but I can't find anything describing how to use it. Can anyone here offer any guidance or leads?
Click to expand...
Click to collapse
Seach the Dev forum for the Galaxy S 2 Hack Pack posted by AdamOutler - if there's any documentation on HW AES it'll be in the Exynos TRM.
How can Android system be hacked just by one MMS? I heard from news sites that there was found an exploit for 95% of Android phones (Android 2.3+) that can take control of the whole device just for one MMS and without letting you know. How can it be possible and how I can prevent it?
P.S.: I don't want to hack nobody's phone as I have no friends. Just curious.
Sent from my GT-I9301I using XDA Forums Pro.
mihai.apostu98 said:
How can Android system be hacked just by one MMS? I heard from news sites that there was found an exploit for 95% of Android phones (Android 2.3+) that can take control of the whole device just for one MMS and without letting you know. How can it be possible and how I can prevent it?
P.S.: I don't want to hack nobody's phone as I have no friends. Just curious.
Sent from my GT-I9301I using XDA Forums Pro.
Click to expand...
Click to collapse
Heres some useful info:
http://www.cnet.com/news/researcher-finds-mother-of-all-android-vulnerabilities/
That's some info, but not really anything useful. Does this mean Google has a patch, will they be pushing that our or will there be ways to patch custom ROMs sooner even? These are all unanswered, though would be nice to know...
"As soon as the malicious text is received, features built into Stagefright to reduce lag time for viewing videos process the video to prepare it for viewing. That processing apparently is enough for bad guys to get their hooks into the platform and take control." - cnet
I see it like this:
1. MMS with video arrives
2. Messaging app loads the video in Stagefright where it will processed for better playback.
3. Video is ready for playing.
As I figure out from Google's Android site about Stagefright, it is a service that take care of video/audio/other media related stuff offline and local.
How can hackers connect with Stagefright if Stagefright is an offline service? And anyway how can an media service recive code to execute as an remote command execution for whole system?
Sorry but I just don't get it at all.
mihai.apostu98 said:
How can Android system be hacked just by one MMS? I heard from news sites that there was found an exploit for 95% of Android phones (Android 2.3+) that can take control of the whole device just for one MMS and without letting you know. How can it be possible and how I can prevent it?
P.S.: I don't want to hack nobody's phone as I have no friends. Just curious.
Click to expand...
Click to collapse
Here's further info. Google has apparently already sent the patches, 7 in all, to the various phone manufacturers.
Because of fragmentation, though, some of them may never send out these fixes. Since these have assumedly been committed to the source code online, they should theoretically be available for download at some point as well. However, you'd (likely) need to be rooted to apply them.
In the meantime, go into your SMS application (usually Hangouts these days) and turn off automatic MMS retrieval. Then, do not accept any photos or videos from anyone you don't know. I am not sure, but I worry it's also possible you might get it from someone do know who is already infected, so just operate with an abundance of caution overall, I guess. And keep an eye out for news here, because it will probably be one of the first places they become available.
mihai.apostu98 said:
"As soon as the malicious text is received, features built into Stagefright to reduce lag time for viewing videos process the video to prepare it for viewing. That processing apparently is enough for bad guys to get their hooks into the platform and take control." - cnet
I see it like this:
1. MMS with video arrives
2. Messaging app loads the video in Stagefright where it will processed for better playback.
3. Video is ready for playing.
As I figure out from Google's Android site about Stagefright, it is a service that take care of video/audio/other media related stuff offline and local.
How can hackers connect with Stagefright if Stagefright is an offline service? And anyway how can an media service recive code to execute as an remote command execution for whole system?
Sorry but I just don't get it at all.
Click to expand...
Click to collapse
People connect with Stagefright by sending you the malicious code contained within the MMS. Once that code gets (usually automatically) processed by the Stagefright service already locally present, it exploits security vulnerabilities to hand control of your device over to whomever is waiting on the other end. As for a media service being able to control the whole system, think of how Flash (a media service) and Microsoft had those zero-day UaE bugs that would allow someone to take over your PC. The logistics may be different, but the concept is the same.
If I remember correctly, there are ways to turn stagefright on/off by editing your build.prop file (easily found on XDA). I don't know if there is another subservice or what that could be running, and I haven't devved since Android 4 dropped, so don't get your hopes up.
Hope that helps.
I gather that Google has a patch. Has it been pushed out to Nexus devices?
pomeroythomas said:
If I remember correctly, there are ways to turn stagefright on/off by editing your build.prop file (easily found on XDA). I don't know if there is another subservice or what that could be running, and I haven't devved since Android 4 dropped, so don't get your hopes up.
Click to expand...
Click to collapse
Excellent idea, +thanks. Et voilà, what appears to b-e in my KitKat:
media.stagefright.enable-player=false
media.stagefright.enable-meta=false
media.stagefright.enable-scan=false
media.stagefright.enable-http=false
media.stagefright.enable-rtsp=false
media.stagefright.enable-record=false
Now, this can break all kinds of things if you don't know what you're doing. Use a build.prop editor from the Play Store.
I don't know that they all need to be false to plug this hole. But those are the relevant lines.*
UPDATE [10 Aug 2015]: This doesn't affect what the Zimperium scanner says is vulnerable, which may indicate the edit won't protect you. It's unclear at this point.... read the latest posts in this thread for possible info. You can turn off auto-retrieve in MMS, but SF exists at other levels of the operating system. I suppose it couldn't hurt to do the build.prop, but don't rely on it.
voxluna said:
Excellent idea, +thanks. Et voilà:
media.stagefright.enable-player=false
media.stagefright.enable-meta=false
media.stagefright.enable-scan=false
media.stagefright.enable-http=false
media.stagefright.enable-rtsp=false
media.stagefright.enable-record=false
Now, this will probably break all kinds of things, and I don't know that they all need to be false to plug this hole. But those are the relevant lines.
Click to expand...
Click to collapse
Thanks for the thanks!
You probably won't break much of anything; 90% of today's phones are powerful enough that you don't REALLY need Stagefright handling the media unless you're playing very intensive games on your device. The most you'll likely experience is not-quite-as-good benchmarking numbers.
pomeroythomas said:
Thanks for the thanks!
You probably won't break much of anything; 90% of today's phones are powerful enough that you don't REALLY need Stagefright handling the media unless you're playing very intensive games on your device. The most you'll likely experience is not-quite-as-good benchmarking numbers.
Click to expand...
Click to collapse
I had honestly never heard of StageFright, and I've been using Android since the very first device came out. But if it's possible to run all the usual media, just with a performance penalty, I'm going to change it right now (I did, and this happened).
Also, I just read an article claiming that fragmentation is not so much of an issue these days, because Google Play Services is mandatory. I wonder if it can proactively change something like this, on its own?
voxluna said:
I had honestly never heard of StageFright, and I've been using Android since the very first device came out. But if it's possible to run all the usual media, just with a performance penalty, I'm going to change it right now.
Click to expand...
Click to collapse
The only reason I even know about Stagefright is because my very first, 550MHz, resistive touchscreen Kyocera Zio shipped with Stagefright disabled by default. Haha.
Also, I just read an article claiming that fragmentation is not so much of an issue these days, because Google Play Services is mandatory. I wonder if it can proactively change something like this, on its own?
Click to expand...
Click to collapse
I would assume it's possible (this is just an arbitrary code execution issue, I think), but having had that vulnerability built into pretty much every ROM for the last 5 years could be a problem in that I'm not 100% sure that Google Play Services has the access to shut down the Stagefright service (no root access, etc), so I'm pretty sure Google Play Services would be less of a fix than a piece of software that actively tries to mitigate the breach.
I could be wrong, though; I'm basically guessing as I haven't looked into the malicious code.
Xposed Android will no doubt have either a module for this or existing bugfix modules will be updated to include this vulnerability in the coming days, and due to the nature of Xposed modules taking over services the ROM is trying to run without actually messing with your ROM, I'm sure it'll be a universal fix.
Personally, I just shut off the Stagefright service using my build.prop and am patiently awaiting someone more skilled than I to create a fix.
i could see this as a useful root method for lollipop, and other versions that don't have root methods yet.
Morlok8k said:
i could see this as a useful root method for lollipop, and other versions that don't have root methods yet.
Click to expand...
Click to collapse
Here's hoping!
Morlok8k said:
i could see this as a useful root method for lollipop, and other versions that don't have root methods yet.
Click to expand...
Click to collapse
pomeroythomas said:
I'm not 100% sure that Google Play Services has the access to shut down the Stagefright service (no root access, etc), so I'm pretty sure Google Play Services would be less of a fix than a piece of software that actively tries to mitigate the breach.
Click to expand...
Click to collapse
Come to think of it, if this exploit allows any kind of root, I suppose it'd be possible for Services itself to use that hole, and therefore be able to patch StageFright. A weird workaround, but entirely possible. Something tells me they won't use it, though, as technically feasable as it may be. I'm really hoping for that Xposed fix, just like GravityBox can patch FakeID. Which, indeed, Services eventually mitigated (for the most part).
commits on android.googlesource.com
Has anyone tracked any commits in android.googlesource.com related to stagefright?
Is this really a viable fix for this? I copied it from another website
If you turn off the following settings in your messaging app/apps on your device:
Auto-retrieve MMS. Check to automatically retrieve multimedia messages that you receive. If auto-retrieve is unchecked in your Messenger MMS settings, you must touch Download to view the message.
Roaming auto-retrieve. Check to automatically retrieve multimedia messages while roaming.
Then when you receive the text with this exploit it will not download to your phone unless you hit the download button. So looks like this can be turned off without a patch but patches are needed cause not everyone is smart enough to turn these off.
iverson3-1 said:
Is this really a viable fix for this? I copied it from another website
Auto-retrieve MMS. Check to automatically retrieve multimedia messages that you receive. If auto-retrieve is unchecked in your Messenger MMS settings, you must touch Download to view the message.
Roaming auto-retrieve. Check to automatically retrieve multimedia messages while roaming.
Then when you receive the text with this exploit it will not download to your phone unless you hit the download button. So looks like this can be turned off without a patch but patches are needed cause not everyone is smart enough to turn these off.
Click to expand...
Click to collapse
That should be one way to disable the hack. It's unclear from what I've read if it only affects Hangouts, or all SMS clients. What I've done is disable any auto MMS retrieve in my own messaging app, which in my case is mySMS. I suppose it couldn't hurt to do it in Hangouts as well.
This should cover it, but I think you still run the risk of someone you know sending (probably without their knowledge) an infected video -- much like trojans that take over a PC, and use the internal contact list to send mail as though they were your friend, they could exploit your trust.
Patching the build.prop theoretically protects from this, which I've personally done, but it's not for the faint of heart. If you screw it up, you could render your phone a mess. I wish I knew more about app development, because I would write something that did all this stuff automagically.
voxluna said:
Patching the build.prop theoretically protects from this, which I've personally done, but it's not for the faint of heart. If you screw it up, you could render your phone a mess.
Click to expand...
Click to collapse
Aaaaaand that's what I just did. I'm in a boot loop after changing the build.prop file. This is going to be really fun with an encrypted data partition that holds the backup I just made.
Be warned.
UPDATE: I had to reflash the ROM, and the entire experience took about 2.5 hours because I couldn't get a KDZ to work. I decided that since it was going to be a full wipe, at least I would upgrade to Lollipop, but I'll have to set up the entire phone all over again. I suspect the problem was that I didn't pay attention to the permissions of that file when I edited and transferred it from another machine. Ugh. I just went back and put warnings on all my posts about the build.prop lines.... and it would be better to just wait for patches, IMO. This thread is progressing quickly now.
i tried tracking the fix on android source repo. but the only recent commit against libstagefright is on July 7th.
Fix global-buffer-overflow in voAWB_Copy.
Copy() in frameworks/av/media/libstagefright/codecs/amrwbenc/src/util.c always
overreads the buffer by 4 bytes to the right, which, if we are very unlucky,
can even hit an unmapped memory page (in this case it is just a global
variable).
Click to expand...
Click to collapse
Hi all,
in my case, as I plainly don't use the MMS feature, I simpl deleted the MMS apn. Is this a possible workaround for this problem (at least, until it gets fixed somehow)?
Hi!
I've written another Xposed module for my LEX720 for a very specific purpose, so probably it won't be of much use for the most. But I'm still publishing it for reference reasons.
Background:
First the good news: The stock firmware of LeEco includes the "SmardcardService" (which also often is referred to as "Open Mobile API" or short "OMAPI") which is an extension API to plain Android (i.e. not existing in the Nexus devices or the Pixels) to allow apps accessing Secure Elements (i.e. secure applications embedded in a tamper-resistant hardware) within the SIM-card.
A real world example: in Austria some banks (in cooperation with the 3 largest network operators) support Tap'n'Pay with your phone by installing the NFC-capable banking card as an additional application into the SIM card (which is the same secure chipcard technology as a banking card). This means you get a new SIM card and then you can tap'n'pay with your phone (without Google, without VISA or MasterCard, just as with the Austrian NFC banking cards). AFAIK in some other countries the same concept is used for public transport and others.
The main difference to Android Pay is, that this system is backed by the chipcard (the SIM) and not by a cloud service. But this just as background information.
The problem:
The LEX720 is a dual-sim phone, and so the (banking) apps could read SIM-cards from either SIM1 or SIM2 slot (I tested, SmartcardService works with both). But if you also want to use NFC for payment it has to be inserted into SIM1 (as it seems that only the SIM1 slot ist connected over an SWP line to the NFC chipset). Unfortunately the Austrian banking apps don't seem to handle the dual-SIM situation correctly and only try to read SIM2 (which is empty for me) and therefore don't work.
Additionally, at the end of an transaction, when the application running within the SIM card signalizes that it just had finished a payment transaction to the Android system, the NFC service (/system/vendor/app/NQNfcNci/NQNfcNci.apk) broadcasts this message as an intent to the relevant (banking) app, so that the app can display a transaction result activity.
Unfortunately this mechanism is implemented often very different by different OEMs and so also by LeEco. There exists a standard (GSMA NFC Handset APIs Requirement Specification) but it seems there are a lot of different implementations in the wild.
(Note: this is probably the case because this type of functionality is not part of the official reference Android source code. Plain open source Android like it is running on all Nexus phones and the Pixels just doesn't support these type of applications - which is very unfortunate).
My workaround:
TL;DR I just made an Xposed module which fixes these 2 issues for me. Look into the README on Github for more details.
Source on Github: https://github.com/johnzweng/XposedOmapiBankcardFix
Download Xposed Module: Xposed-module-OMAPI-BankcardMobil-Fix-1.1.apk
Maybe it's also useful for other applications which use the SIM card as secure storage for keys of any type. Use at your own risk.
As a reference: these are the Austrian banking apps this module should work with:
Bank Austria Mobile Geldbörse
BankCard Mobil
Oberbank Bankomatkarte Mobil
Raiffeisen ELBA-pay
VKB-Pay - Bankomatkarte mobil
The module might also help to get other similiar apps working which have problems with Dual-SIM or don't show Transaction confirmation screens. I am talking here about apps which use a special SIM card for payment, ticketing or similiar use-cases via NFC. This has nothing to do with "normal" NFC apps or cloud-based HCE (host card emulation) NFC apps. This module is only for apps which use special SIM cards.
[edit]
Updated download link to version 1.1.
For details see the CHANGELOG in the Github repoistory.
[/edit]
Btw, during debugging I noticed another small bug in the LeEco NFC service:
The package com.android.nfc (/system/vendor/app/NQNfcNci/NQNfcNci.apk) declares a permission which allows apps to receive Intents about EVT_TRANSACTION events. On the LeEco LePro 3 (LEX720, running 5.8.018S, WAXCNFN5801811012S) this permission looks like this
Code:
declared permissions:
com.gsma.service.nfc.permission.TRANSACTION_EVENT: prot=dangerous, INSTALLED
You can check this easyily yourself with this adb command:
Code:
adb shell pm dump com.android.nfc > dump-nfc-service.txt
This will dump all infos into a file named dump-nfc-service.txt. Open the file with an editor and search for "declared permissions:".
The problem with this permission is, that its name is missing a letter!
Correctly it should be called: com.gsma.services.nfc.action.TRANSACTION_EVENT (note the missing "s").
This is specified in the GSMA NFC Handset APIs Requirement Specification (see at the top of page 13 in the PDF)
Funny enough the specification in the PDF also contains a typo in the very same permission name the Intent action name (the dot "." after the word "gsma" is a comma "," in the PDF). It must be really hard to type this correctly.
Nevertheless this typo leads to errors like:
Code:
W/PackageManager( 2357): Unknown permission com.gsma.services.nfc.permission.TRANSACTION_EVENT in package ......
and prevents applications of requesting the correct permission.
Does anybody know if and how it's the best way to report bugs to LeEco?
[edit1]
I contacted them on Twitter. I hope they will forward this issue to developers.
Btw, it seems that also LG had included the same typo in some of its devices:
Devices without the "s": https://census.tsyrklevich.net/permissions/com.gsma.service.nfc.permission.TRANSACTION_EVENT
vs.:
Devices with the "s": https://census.tsyrklevich.net/permissions/com.gsma.services.nfc.permission.TRANSACTION_EVENT
[/edit1]
Hi androcheck,
first i am really impressed that somebody found a solution for that problem (i already have several posts with no answer at all)
But now i have a problem as when i install the fix i stuck in a boot loop. Is this maybe cause i am on custom ROM (Turbo MIUI) ?
Hope you have an idea
thanks
Robert
viercp said:
Hi androcheck,
first i am really impressed that somebody found a solution for that problem (i already have several posts with no answer at all)
But now i have a problem as when i install the fix i stuck in a boot loop. Is this maybe cause i am on custom ROM (Turbo MIUI) ?
Hope you have an idea
thanks
Robert
Click to expand...
Click to collapse
So far seems a "one time bug" - all ok with patch but i still get the very same error mssg
Any poss to tell me where i can check if entries provided by fix are really done ?
viercp said:
So far seems a "one time bug" - all ok with patch but i still get the very same error mssg
Any poss to tell me where i can check if entries provided by fix are really done ?
Click to expand...
Click to collapse
Hi!
Sorry for the delayed answer.
First of all the ROM you are using must have the SmartcardService (=implementation of OpenMobile API), the corresponding library (org.simalliance.openmobileapi.jar) and permission manifest (org.simalliance.openmobileapi.xml) installed. I downloaded miau_destroyer_v12.zip from this thread here, extracted it and it seems that it contains all three of them.
My Xposed module "XposedOmapiBankcardFix" doesn't do very much besides forcing the apps which are using the OpenMobile API to always use "SIM1" as SmartcardReader. This was necessary because at the time of writing the Bankcard apps in Austria from PSA (Payment Services Austria) didn't correctly check for multiple SIM slots. So in fact this was a bug in the PSA apps, not in the phone.
Back then I reported this back to the developers (of the banking app) and today it seems to be fixed (I didn't check in detail but the Bank Austria app now is working for me on Android 7 without Xposed installed - with the SIM inserted in slot 1).
Another point I realized: By looking into the build.props of the miau_destroyer_v12 ROM it seemed to me that this ROM is configured for single SIM use. This means that the SmartcardService also only sees one cardreader (SIM slot). Maybe this also interferes with the Xposed module?
For clarification:
Before I wrote my Xposed module, the Bank Austria banking app worked already perfectly (no errors displayed, recognized the NFC SIM card, personalization of the bankcard worked ok) when I inserted the SIM card into slot 2. It just didn't work when the SIM card was inserted in slot 1. The problem is that it must be inserted in slot 1 if you want to use it over NFC. This is why I decided to work around this limitation with my Xposed module.
The second feature ("Fix EVT_TRANSACTION Intent") of my module was just a gimmick "on the way". I realized that the confirmation dialog after paying is not displayed, but this was just a "cosmetic" problem. Payments did still work, even if the confirmation dialog on the phone is not displayed.
Another sidenote:
As I have mentioned before I have switched already to an Android 7.1 based ROM on my personal phone (as a developer I want to use some of the new APIs) so I don't have Xposed anymore (as Xposed is not available for Android 7). So at the moment I cannot really test anything.
Which error exactly do you get? What do you see in logcat?
Kind regards,
john
androcheck said:
Hi!
Another point I realized: By looking into the build.props of the miau_destroyer_v12 ROM it seemed to me that this ROM is configured for single SIM use. This means that the SmartcardService also only sees one cardreader (SIM slot). Maybe this also interferes with the Xposed module?
Click to expand...
Click to collapse
Changed in build.prob to enable Dual SIM
Which error exactly do you get? What do you see in logcat?
Click to expand...
Click to collapse
Havent worked with before - which entry you are looking for ?
Lot Of Thanks for your great work！
Btw,Do you use AOSP 8.1(such as AICP8.1)
On these roms,after add SmartCardService.apk ,it still cann't work with these bank apps. Actually,it can read other nfc tags,but it's HCE (Host-based Card Emulation) can not work
Could you have a try to fix it?
My post:
https://forum.xda-developers.com/le...a-zl1-x727-x720-t3698058/page356#post76274677
Hi,
Google says that Pixel 7 series don't support SWP-SIM while Pixel 6 and others supported.
So I started googling that if there's any 'Magisk way' to solve this issue, then I find your xda posts.
If you happen to be a Pixel 7 user, are you interested in looking into this issue?
I'd like to buy you a $30 coffee or more if I can use the SWP-SIM for payment on my Pixel 7.
jasonlee0315 said:
Google says that Pixel 7 series don't support SWP-SIM while Pixel 6 and others supported.
So I started googling that if there's any 'Magisk way' to solve this issue, then I find your xda posts.
Click to expand...
Click to collapse
Hi!
I don't have Pixel 7 and currently I am not working in this field, but for clarification:
"SWP-SIM support" is (also) a hardware feature.
To be able to use SWP-SIMs there must be a physical connection between the SWP pin of the NFC controller (this is a separate chip on the mainboard of your phone, not the main application processor, where Android runs on) and the respective pin of the SIM card slot.
Google in the past tended to not connect these 2 pins. I don't know if the Pixel 7 has this connection. I just wanted to let you know, that if this connection does not exist, there is no way to solve this in software.
[edit]
(see also this old question on stackexchange, this was about the Nexus 5X and 6P: https://stackoverflow.com/questions...-to-the-uicc-on-the-nexus-5x-and-the-nexus-6p)
[/edit]
androcheck said:
Hi!
I don't have Pixel 7 and currently I am not working in this field, but for clarification:
"SWP-SIM support" is (also) a hardware feature.
To be able to use SWP-SIMs there must be a physical connection between the SWP pin of the NFC controller (this is a separate chip on the mainboard of your phone, not the main application processor, where Android runs on) and the respective pin of the SIM card slot.
Google in the past tended to not connect these 2 pins. I don't know if the Pixel 7 has this connection. I just wanted to let you know, that if this connection does not exist, there is no way to solve this in software.
[edit]
(see also this old question on stackexchange, this was about the Nexus 5X and 6P: https://stackoverflow.com/questions...-to-the-uicc-on-the-nexus-5x-and-the-nexus-6p)
[/edit]
Click to expand...
Click to collapse
Thanks for replying. I guess I might give up trying to get SWP-SIM working on Pixel 7.