Database Users

Possible Google Wallet Fix

I've seen a couple posts regarding getting Google Wallet to work (and hopefully I'm not being redundant with this post). I've had Google Wallet working on my own 2.3.5 source ROM for quite some time now and I figured I'd share what got it working for me. As a matter of disclosure, I do have the 4G, but I haven't seen anything in the code that would give reason for why this wouldn't work.
While I'm able to build a ROM, I for some reason, don't know how to put together a flashable update. Maybe somebody with a little more know-how can piece this together and try it out, or at least tell me I'm wrong.
Files needed from the GWK74 ROM:
system/etc/permissions/com.google.android.nfc_extras.xml
(I just added the permission entry to the existing com.android.nfc_extras.xml file instead to keep the clutter down).
system/framework/com.android.nfc_extras.jar
The version in the GWK74 ROM contains code that has yet to be released, since korg is down and all. The extra file has something to do with NFC emulation, but I've only glanced at it, so I really couldn't tell you what it does.
system/app/Wallet.apk
Obviously.
Here's the catch: The Wallet app requires permissions from Nfc.apk (NFCEE_ADMIN). By default, the Nfc.apk is signed with the "platform" key, but as long as these two files are signed with the same key, it will grant it the proper permissions to Wallet.apk no matter what key that may happen to be. Considering that Nfc.apk also requests other permissions from "platform" as well, certificate consistency would be advisable.
Hope this works out or at the very least, gets the ball rolling.

Hopefully, someone can make like a flashable zip for CM7 or at least let us know which files need to be copied to our GSM phones so we can extract those files and copy it to system

do you mind zipping up the files used and posting them here?

They're basically the stock files from GWK74 with Wallet.apk and Nfc.apk signed with the same key. My only concern is that since I've used a private key on my own ROM for a while now, I don't remember/know how many or which non-stock ROMs are signed with anything other than the testkeys or which key would be the best for (most) everyone. If the testkeys work universally, I could do that, but I'd hate for someone with differing platform keys getting upset that it's still doing the same FC as before.
For those familiar with using the Android Kitchen, it can do the signing and packaging with testkeys if you're willing to reflash. Might be an easier step for some to take if the command line method seems overwhelming.

As far as Google Wallet working on a GSM Nexus S. I believe there is more protection than it appears. I firmly believe Google has not only modified the NFC drivers and added NFC security to both the drivers and the Firmware. But I also think they added security to the rils and network checks.
How did I get to these conclusions? Well I actually ported the whole NS4G rom over to the GSM. The only things I really had to change were ril libs and the build.prop. Everything else is pretty similar between the two phones. NFC worked and I was able to start up Google Wallet, however, when attempting to add a card to Google Wallet, it kept loading for like 10 minutes until it gave an error. No real description of the error and logcats revealing nothing. Taking out my sim card, I was greeted with a message in Google Wallet that I should check my sim card and insert it if its not inserted. Why would Google Wallet even have anything to do with carriers even connected to wifi? There must be some other things added.
Then I went ahead and decided to revert to a backup of my CM7. I noticed NFC no longer would turn on, it kept giving me an error. Looking at a logcat it looked like it was trying to download and install firmware but failed. Other NS4G users have experienced this same error. Logcats show that it is downloading firmware but failing to be able to install it. My theory: Google added extra security to the firmware located directly onto the NFC chip itself. So now no ROMs (including the new 2.3.6) give me working NFC except for that 2.3.7 rom. I'm still working on trying to fix.
Now I am happy you posted this thread, because maybe if I backport these additions to a GSM rom I might be able to fix NFC. I'm not sure as of yet. I am going to attempt Odin next, but I can already guarantee Formatting System, Boot, Cache, Data did not resolve the issue.

They definitely added something to the firmware. After flashing GWK74 nfc no longer works on 2.3.5. If I flash back to GWK74 it works no problem.
Sent from my Nexus S 4G using xda premium

U could test that driver theory with a chip that hasnt gotten the 2.3.7 update.

apreichner said:
As far as Google Wallet working on a GSM Nexus S. I believe there is more protection than it appears. I firmly believe Google has not only modified the NFC drivers and added NFC security to both the drivers and the Firmware. But I also think they added security to the rils and network checks.
How did I get to these conclusions? Well I actually ported the whole NS4G rom over to the GSM. The only things I really had to change were ril libs and the build.prop. Everything else is pretty similar between the two phones. NFC worked and I was able to start up Google Wallet, however, when attempting to add a card to Google Wallet, it kept loading for like 10 minutes until it gave an error. No real description of the error and logcats revealing nothing. Taking out my sim card, I was greeted with a message in Google Wallet that I should check my sim card and insert it if its not inserted. Why would Google Wallet even have anything to do with carriers even connected to wifi? There must be some other things added.
Then I went ahead and decided to revert to a backup of my CM7. I noticed NFC no longer would turn on, it kept giving me an error. Looking at a logcat it looked like it was trying to download and install firmware but failed. Other NS4G users have experienced this same error. Logcats show that it is downloading firmware but failing to be able to install it. My theory: Google added extra security to the firmware located directly onto the NFC chip itself. So now no ROMs (including the new 2.3.6) give me working NFC except for that 2.3.7 rom. I'm still working on trying to fix.
Now I am happy you posted this thread, because maybe if I backport these additions to a GSM rom I might be able to fix NFC. I'm not sure as of yet. I am going to attempt Odin next, but I can already guarantee Formatting System, Boot, Cache, Data did not resolve the issue.
Click to expand...
Click to collapse
Thanks for chiming in. Appreciate the info
Hmm, that's odd because aside from those three files and the vendor binaries, everything else on my ROM is from the 2.3.5 source files (since I don't have a choice for source files, really). The first thing I tried when Wallet was giving me fits was to poke around the APKs to see if they were holding any additional files, but I didn't locate any in Wallet and the NFC app file is too small to hold any additional files (and doesn't, since I checked anyway). The 2.3.7 nfc_extras JAR file only contains three java files (compared to the two from 2.3.5) so I don't suspect anything warranting investigation.
It's hard to imagine Google going through so much trouble to block their own product on their own phone. Unfortunately, I don't have access to a non-Sprint Nexus S, so I cannot account for the SIM message you experienced, but the hardware vendor for the NFC component appears to be the same (NXP) for both phones and it just doesn't make sense for them to use two different components for the same model of nearly identical phones. I'll try using the libpn544_fw.so binary from the standard crespo and see what kind of (ill) effects I experience.
I did notice during my trial-and-error period that the error messages and the manner in which they would show up seemed to vary slightly. Adding the JAR file alleviated the persistent com.google.android.apps.walletnfcrel FC during startup and use. After that, the signing took care of the persistent 'insufficient system privileges' (or something to that effect) on startup.
I'd be interested in what is in your log readout. Personally, logcat gets visually overwhelming to me, so I just use ddms to filter out the other processes and error messages from obfuscating what I'm looking for. The thing that Wallet is trying to access is NFC permissions, which Nfc.apk appears to have sole (or at least primary) responsibility for. All of the protests coming from Wallet that I observed were related to its inability to be granted permissions from Nfc for NFCEE_ADMIN, which is specified in its AndroidManifest file as being under protectionLevel="signature", of which it is assigned to "platform" by default. That would explain why people with the stock ROM can get it to work, since it still retains the Google signature keys structure. I suspect most of the alternative ROMs are running some varying key structure, but that is just speculation on my part. I suppose modifying the AndroidManifest file to explicitly give permission to Wallet would also address that, but at the time, I considered that unnecessarily tedious.
I'm still betting on certificate-connected privileges being the primary culprit, but I'll give the NFC binary file a run and see what happens.
Update:
Ran with the libpn544_fw.so from crespo and Wallet initially FCed. I pulled the file through ADB first to make sure it was the one installed and it was, but after the FC, I pulled the file again and it was the regular one for crespo4g. So, unless I misread it or made a mistake somewhere, something is replacing the file. I pushed the original file back, ran it, and pulled it again and it seemed to stick, but I suspect it's running from cache. So basically, it appears that the binary from crespo is insufficient, as I got numerous errors in ddms as a result. I don't know if it has the same effect both ways though. Has anybody tried the crespo4g NXP binary yet with any luck?
Also, I do apologize for some misinformation earlier. The 2.3.7 NfcGoogle.apk does contain a libnfc_jni.so file, but it's already in system/lib, so I don't know if that has to do with anything relevant.

Need some help i get this error message when i push the files to newest Cm7 nightly based on 2.3.7. Any ideas?

XK72 said:
It's hard to imagine Google going through so much trouble to block their own product on their own phone.
Click to expand...
Click to collapse
Well keep in mind it's not just Google that's involved, but MasterCard, Citi, MoneyNet or whatever that service is that processes the transactions... they may have mandated that some extra security measures be taken to keep the initial rollout limited to a relatively small specific group.

david279 said:
Need some help i get this error message when i push the files to newest Cm7 nightly based on 2.3.7. Any ideas?
Click to expand...
Click to collapse
I encountered the same issue a while back. It's related to the signature keys on Wallet, which is signed with Google's key out of the box. If the rest of your build is signed with testkeys (which appears to be the case), you can resolve that by signing Wallet.apk with testkeys as well.

tobiasly said:
Well keep in mind it's not just Google that's involved, but MasterCard, Citi, MoneyNet or whatever that service is that processes the transactions... they may have mandated that some extra security measures be taken to keep the initial rollout limited to a relatively small specific group.
Click to expand...
Click to collapse
While Google Wallet is a proprietary application, and as such, Google or the forces that be could possibly be responsible for what's occurring and I wouldn't be able to discern whether or not that is true, I personally don't believe that is the reason behind what is happening.
(This is just as I understand it). There certainly are security measures in place for NFC, which the Android system is responsible for handling. The Wallet app is essentially an interface that is PIN secured on the user end and requests relevant permission from Nfc.apk that manages interaction with the NFC-related subset on its behalf. If anything, the credit card companies are concerned with unauthorized transmissions that could result in financial liability on their end. The fact that Wallet requires signature-protected permission authorization from Nfc to access the NFC element shows that Android is not leaving security duties up to the Wallet app alone.
I think the hindrances in getting this to work for everyone is that the people who could develop a fix probably don't have access to the Nexus S hardware variants. I started with the same or similar issues that people faced when trying to incorporate Wallet into their build and eventually got it to work on a 2.3.5 sourced build was the steps above, but I also don't own a standard Nexus S for me to test with, so I couldn't proclaim that it was a definitive fix. I was hoping, at the very least, that it might be contributive towards finding a fix for everyone.

XK72 said:
I encountered the same issue a while back. It's related to the signature keys on Wallet, which is signed with Google's key out of the box. If the rest of your build is signed with testkeys (which appears to be the case), you can resolve that by signing Wallet.apk with testkeys as well.
Click to expand...
Click to collapse
How do I sign apks? Can you send me a wallet apk signed with test keys?
Sent from my Nexus S 4G using xda premium
---------- Post added at 06:03 PM ---------- Previous post was at 05:39 PM ----------
Ok i found a app in the market for signing apks, zips, etc. but im getting the same error.

XK72 said:
While Google Wallet is a proprietary application, and as such, Google or the forces that be could possibly be responsible for what's occurring and I wouldn't be able to discern whether or not that is true, I personally don't believe that is the reason behind what is happening.
(This is just as I understand it). There certainly are security measures in place for NFC, which the Android system is responsible for handling. The Wallet app is essentially an interface that is PIN secured on the user end and requests relevant permission from Nfc.apk that manages interaction with the NFC-related subset on its behalf. If anything, the credit card companies are concerned with unauthorized transmissions that could result in financial liability on their end. The fact that Wallet requires signature-protected permission authorization from Nfc to access the NFC element shows that Android is not leaving security duties up to the Wallet app alone.
I think the hindrances in getting this to work for everyone is that the people who could develop a fix probably don't have access to the Nexus S hardware variants. I started with the same or similar issues that people faced when trying to incorporate Wallet into their build and eventually got it to work on a 2.3.5 sourced build was the steps above, but I also don't own a standard Nexus S for me to test with, so I couldn't proclaim that it was a definitive fix. I was hoping, at the very least, that it might be contributive towards finding a fix for everyone.
Click to expand...
Click to collapse
I will attempt to port it over. Good news is there's some 2.3.7 source available now to build with. I don't have much hope though because a full port didn't even work on a GSM device. Although newer libs might help.
Sent from my Nexus S using xda premium

apreichner said:
I will attempt to port it over. Good news is there's some 2.3.7 source available now to build with. I don't have much hope though because a full port didn't even work on a GSM device. Although newer libs might help.
Sent from my Nexus S using xda premium
Click to expand...
Click to collapse
Do you know where they're hosting the 2.3.7 source? I just realized that they released the 2.3.7 binaries for both crespo and crespo4g, so between those two, there really shouldn't be anything else getting in the way of making this work.

Here: http://forum.xda-developers.com/showthread.php?t=1284517
People are reporting that Wallet works just fine on I902x phones and stock rooted 2.3.6. I'm only one there unable to add prepaid card. Guess it's because my IMEI is generic, and i'm pretty sure that google is using IMEIs for authentication and similar processes...

One factor may be branch of code. In build numbers, the letters have meanings. First letter is Android version (G for Gingerbread). Second letter is branch. Usually this is R for Release. The build for NS4G is W. I don't know what this W branch is. Maybe special "Wallet" branch.
http://source.android.com/source/build-numbers.html
Sent from my Nexus S using XDA App

Major Security Hole in Google Wallet

There are two major holes in Google Wallet's security. One that gives a person access to your pin by using a rooted app, and the other that gives a person the ability to change your pin.
http://thesmartphonechamp.com/security-flaw-found-in-google-wallet/
This one is the biggest security hole as it effects all users regardless of if they are rooted or not.
http://thesmartphonechamp.com/secon...le-wallet-rooted-or-not-no-one-is-safe-video/

I'm not worried in the slightest.. Android Central made a very good point.
You'll need to have a phone with Google Wallet, AND have rooted your device, AND have not set a secure lock screen, AND then lose your phone. The person who finds it THEN can use the app the fellows at zvleo have made and since distributed to brute-force the PIN and THEN can use your phone to make payments, just like they could if they found your credit card, which likely would be quicker and easier than any of this.
Click to expand...
Click to collapse

adaimespechip said:
I'm not worried in the slightest.. Android Central made a very good point.
Click to expand...
Click to collapse
That's true only for the method where you try to discover the person's pin. With the changing the pin method, all you need to do is lose your phone and it not have a pin lock on it. Look at the video in that link, it's pretty easy to change the pin in Google Wallet. You don't need root, you don't need any special apps or anything to do it. All they need is access to your phone. In other words if your phone is stolen and you don't have a password to keep someone from logging into it, they can very easily access your Google Wallet.

Yes, true. But you have to admit that anyone who uses their phone for confidential data (such as credit card info or payments) and who doesn't set a single security feature is kind of a silly person.

Android central updates:
"The zvelo study was conducted on their own phone on which they disabled the security mechanisms that protect Google Wallet by rooting the device. To date, there is no known vulnerability that enables someone to take a consumer phone and gain root access while preserving any Wallet information such as the PIN.
We strongly encourage people to not install Google Wallet on rooted devices and to always set up a screen lock as an additional layer of security for their phone."
Click to expand...
Click to collapse
Google are right.. If you don't want to be at risk, don't root your phone.

its still a million times safer than NFC card.
Sent from my Nexus S using Tapatalk

Does anyone think it could be possible to develop a malicious app that requires root privileges (say a program that most rooted uses would use like Root Explorer), and use it to send your Google Wallet info at the time your phone is making a purchase using Google Wallet? So instead of one purchase for $5 it would also add another. Google wants you to make in person and online purchases with Wallet, as it has replaced Google Checkout.

It's not google's fault. it's user's fault.
DON'T ROOT YOUR PHONE IF YOU WANT SECURITY!!!

First off anyone worried about security doesn't have their phone rooted. Google is storing the pin encrypted on the phone. Of course it is accessible if you have your phone rooted and of course a brute force attack will work. It's really a non-issue.

adaimespechip said:
Android central updates:
Google are right.. If you don't want to be at risk, don't root your phone.
Click to expand...
Click to collapse
kerry_xu_cs said:
It's not google's fault. it's user's fault.
DON'T ROOT YOUR PHONE IF YOU WANT SECURITY!!!
Click to expand...
Click to collapse
bozzykid said:
First off anyone worried about security doesn't have their phone rooted. Google is storing the pin encrypted on the phone. Of course it is accessible if you have your phone rooted and of course a brute force attack will work. It's really a non-issue.
Click to expand...
Click to collapse
You guys are all thinking only of the brute force method that requires root. But the other method that you just simple clear Google Wallet's storage allows you to change the pin without having ever known the pin in the first place. The method used in that video doesn't require any sort of system level access at all. In other words it doesn't matter if you're rooted or not, that method will still gain access to your Google Wallet.

canca14 said:
You guys are all thinking only of the brute force method that requires root. But the other method that you just simple clear Google Wallet's storage allows you to change the pin without having ever known the pin in the first place. The method used in that video doesn't require any sort of system level access at all. In other words it doesn't matter if you're rooted or not, that method will still gain access to your Google Wallet.
Click to expand...
Click to collapse
Again, someone has to break the lock on your phone and steal your phone. If someone steals my computer, they can probably get many of my passwords. It is as much a security concern as any personal device.

bozzykid said:
Again, someone has to break the lock on your phone and steal your phone. If someone steals my computer, they can probably get many of my passwords. It is as much a security concern as any personal device.
Click to expand...
Click to collapse
Right but I was responding to the people who stated this only effects rooted phones. What I am saying to those people is that there are two methods listed on the link I provided. The second method doesn't require root and effects 100% of all Google Wallet users. Of course pin locking your device would add a level of security that would provide a barrier for someone to cross before they can compromise your device.

canca14 said:
That's true only for the method where you try to discover the person's pin. With the changing the pin method, all you need to do is lose your phone and it not have a pin lock on it. Look at the video in that link, it's pretty easy to change the pin in Google Wallet. You don't need root, you don't need any special apps or anything to do it. All they need is access to your phone. In other words if your phone is stolen and you don't have a password to keep someone from logging into it, they can very easily access your Google Wallet.
Click to expand...
Click to collapse
if you lose your wallet it is easier for a thief to use your credit cards then to try and change your pin on Google wallet if you lose your phone.
Sent from my Nexus S 4G using xda premium

Also since Google Wallet supports so few credit card companies, about the most a thief could do is use your prepaid card. You can't add money to the prepaid card without the CV2 code anyways.

first of all, if i lose my phone, i'm wiping the freaking data.
Second of all, I have like $10 on google wallet. if they steal my phone and use the $10, i'm gonna be more pissed about the phone being stolen then them buying lunch.
this is just stupid.

bozzykid said:
Also since Google Wallet supports so few credit card companies, about the most a thief could do is use your prepaid card. You can't add money to the prepaid card without the CV2 code anyways.
Click to expand...
Click to collapse
All the more reason why this flaw is more potentially damaging. Most people who use Google Wallet are going to be using the Google pre-paid card, meaning whatever funds are in the account are going to be compromised.
derekwilkinson said:
first of all, if i lose my phone, i'm wiping the freaking data.
Second of all, I have like $10 on google wallet. if they steal my phone and use the $10, i'm gonna be more pissed about the phone being stolen then them buying lunch.
this is just stupid.
Click to expand...
Click to collapse
How much you keep in the account doesn't matter. The bottom line is they have a gaping hole in their security. The level of inconvenience for you doesn't change that this is a major hole they need to fix ASAP. Google stated that they are working on getting more cards to work with Google Wallet. I for one would not want to link my bank card knowing that a person who steals my phone would have full unfettered access to my account.

canca14 said:
All the more reason why this flaw is more potentially damaging. Most people who use Google Wallet are going to be using the Google pre-paid card, meaning whatever funds are in the account are going to be compromised.
Click to expand...
Click to collapse
How is it more damaging? I'm pretty sure the limit on credit cards is much higher than what is in an average Google Wallet prepaid card. I doubt people keep much money on prepaid cards since it can only be used with your phone.
---------- Post added at 01:21 PM ---------- Previous post was at 01:20 PM ----------
canca14 said:
How much you keep in the account doesn't matter. The bottom line is they have a gaping hole in their security. The level of inconvenience for you doesn't change that this is a major hole they need to fix ASAP. Google stated that they are working on getting more cards to work with Google Wallet. I for one would not want to link my bank card knowing that a person who steals my phone would have full unfettered access to my account.
Click to expand...
Click to collapse
At most, they could add a way to disable cards from the Google Wallet web site. I don't see them adding any major new security measures in the app itself.

canca14 said:
How much you keep in the account doesn't matter. The bottom line is they have a gaping hole in their security. The level of inconvenience for you doesn't change that this is a major hole they need to fix ASAP. Google stated that they are working on getting more cards to work with Google Wallet. I for one would not want to link my bank card knowing that a person who steals my phone would have full unfettered access to my account.
Click to expand...
Click to collapse
lol are you serious dude? you completely ignored me saying i'd wipe my data. and it isn't a "gaping hole in the security". do you know how few people actually root their phones??? it's a small number.
secondly, what if someone steals your wallet? it falling out of your pocket or being pick-pocketed is a major security hole. Wallet makers need to add a lock to the wallet.
Stop being so damn paranoid.

bozzykid said:
How is it more damaging? I'm pretty sure the limit on credit cards is much higher than what is in an average Google Wallet prepaid card. I doubt people keep much money on prepaid cards since it can only be used with your phone.
Click to expand...
Click to collapse
The point isn't how much money people have in it. The point is that anything in your account is at risk regardless of if you keep a large amount in it or not. A hole is a hole and this one needs to be plugged regardless of how much you keep in the account.

derekwilkinson said:
lol are you serious dude? you completely ignored me saying i'd wipe my data. and it isn't a "gaping hole in the security". do you know how few people actually root their phones??? it's a small number.
secondly, what if someone steals your wallet? it falling out of your pocket or being pick-pocketed is a major security hole. Wallet makers need to add a lock to the wallet.
Stop being so damn paranoid.
Click to expand...
Click to collapse
You obviously didn't read the link I provided. Having root has no bearing on someone being able to access your Google Wallet account. BTW if they access your Google Wallet they could easily turn the radio on the phone off and you wouldn't be able to wipe it, but the could still use Google Wallet since it doesn't use data to make purchases.

[Q] Possible to lock phone in case of theft?

My Galaxy 1 was stolen from me in Feb, after that i went through a lent s3 and now proud owner of an s4 (i9500).
So i have two questions on this:
1) is there an equivalent for what a bios password is in a PC?
(have to go short something in hardware to bypass, only is asked upon powerup/hard reboot).
2) Is is technically possible for an app to lock on custom sim? (possibly modifying efs folder)
Thanks!

Abrojo said:
My Galaxy 1 was stolen from me in Feb, after that i went through a lent s3 and now proud owner of an s4 (i9500).
So i have two questions on this:
1) is there an equivalent for what a bios password is in a PC?
(have to go short something in hardware to bypass, only is asked upon powerup/hard reboot).
2) Is is technically possible for an app to lock on custom sim? (possibly modifying efs folder)
Thanks!
Click to expand...
Click to collapse
http://bit.ly/174zPh6

LeJolly said:
http://bit.ly/174zPh6
Click to expand...
Click to collapse
Thank you for patronizing me but that didnt answer my question, already been through pages of results when i previous galaxy was stolen (even tried locking from google play). None of the apps listed on a google search for locking and tracking do what i ask.
Centralized cloud based locking doesnt work (a blacklisted imei can get reinstated fairly easy), neither does the standard password Operating System level password.
Thats why i am asking for specific alternative ways of locking the phone that should be (if possible) more tampering resistant.
1) bios equivalent password.(requiering hardware shorting to bypass)
2) custom simlock

I use avast! free mobile security (https://play.google.com/store/apps/details?id=com.avast.android.mobilesecurity&hl=en),
the anti-theft module has option to block the phone if the sim card is changed

LeJolly said:
http://bit.ly/174zPh6
Click to expand...
Click to collapse
What a woeful answer. Try reading before you be a ****.
In answer, no there is nothing similar to a BIOS lock on Android phones, however like mist813 said, Avast is quite good. If you have root access you can install it as a system apk then even if the thief wipes your phone, it's still there.

You could also try lookout its free. Can do tracking, remote wipe and also takes a photo of anyone trying to unlock your phone.
I don't think there is anything that can prevent someone from just flashing a new firmware and wiping the phone completely.
Sent from my Nexus 10 using Tapatalk 2

I don't think there is an equivalent to BIOS lock in Android. I'm not sure if you tried Lookout or the native Samsung remote control under security settings. Both gives you the options to locate, lock, scream or wipe your data. I tried the locate and scream options and they work. Never tried lock or wipe, but they should also work! Now going to the fact of wether someone can bypass or overcome these security measures, then I personally think it's possible and whatever we do he can find a way to go around it depending on how smart and resourceful he is! If my phone is stolen, frankly speaking I won't waste my time trying to find it or just lock it. All what I'll care about is to wipe the data off, and hopefully these softwares will work if needed!
Sent from my SGS IV using Tapatalk 2

Abrojo said:
Thank you for patronizing me but that didnt answer my question, already been through pages of results when i previous galaxy was stolen (even tried locking from google play). None of the apps listed on a google search for locking and tracking do what i ask.
Centralized cloud based locking doesnt work (a blacklisted imei can get reinstated fairly easy), neither does the standard password Operating System level password.
Thats why i am asking for specific alternative ways of locking the phone that should be (if possible) more tampering resistant.
1) bios equivalent password.(requiering hardware shorting to bypass)
2) custom simlock
Click to expand...
Click to collapse
Okay lets not be a **** this time.
1) There's nothing equivalent to that bios thing
2) http://stackoverflow.com/questions/...-the-device-on-removal-of-sim-card-or-sd-card
There are also apps that just notify you if sim card is changed for example this https://play.google.com/store/apps/details?id=instigate.simCardChangeNotifier&hl=fi
And of course there are some apps that let you remotely control your phone for example http://forum.xda-developers.com/showthread.php?p=7567932

Abrojo,
You don't really need a third-party app for this.
Please check out the Samsung Dive service. (www.samsungdive.com)
You can track your phone, lock it with a custom password, sound an alarm, etc...
The problem is, the phone needs to have Internet access.
I am using the Cerberus app (https://play.google.com/store/apps/details?id=com.lsdroid.cerberus&hl=en)
This is the best rated Anti-theft app you can find for your Android.
a license costs 3USD if I remember correctly. With one license you can secure up to five Android phones.
Featuers:
Track your phone
Remote lock
Remote wipe
And a lot more options...
A couple of things that I think are extremely useful:
When a wrong password or pattern is drawn to unlock your phone, a picture is taken with the front camera and emailed to you together with the location of the phone.
When the SIM is swapped, you can configure up to three phone numbers that will receive an SMS with the new SIM card number and the location of the phone.
You can hide the app from the App Drawer.
Check it out... very useful

i use also cerberusapp 4 years now. everything is perfect. when u install as system app u can do everything.
Sent from my ThL W8 using xda premium

Apparently there is also rumors of LoJack already being built into these phones, with the possibility to activate it some time in the near future. Don't remember all the details, but I just read an article about that. Not being patronizing when I say it, but Google Galaxy S4 LoJack and look into it.
Also, I am on Verizon, and am testing out their mobile security app that is preinstalled. It's $1 a month, but they allow you to remotely lock your phone, wipe it, and track it should you lose it. I don't believe it embedded at the hardware level, but it is something that gives me a little piece of mind.
Edit: I went to switch to the Norton Mobile Security app, since I use it for all of my other devices, and discovered that the Verizon Mobile Security App - once activated - cannot be uninstalled, force stopped, you cannot clear the data, and you cannot disable it. In order to do so, I first have to go into my Verizon account online, sign in, and unsubscribe from the service. After realizing that, I have chosen to keep the Verizon security app, because it has that extra layer of security. Are there ways of bypassing that, I'm sure there are. But assuming that my phone is stolen by some low level thief and not some crazy high level criminal circuit, I should have no problem retrieving it.

Samsung Dive down?
I cant seem to have this page load up www.samsungdive.com
Is it down for you too?

Sm007hCriminal said:
I cant seem to have this page load up www.samsungdive.com
Is it down for you too?
Click to expand...
Click to collapse
It's working with me.
Sent from my SGS IV using Tapatalk 2

Securing Moto G4 for my son.

I just purchased the Amazon Moto G4 edition for my son who is 8yrs old, and I understand he's a little young for a phone. However, a few of his buddies have phones and I thought it was a great way to help him read and type better through texting. I'm also not planning on paying for Cell service but rather use Wifi for SMS and Calls through hangout. And maybe get him freedom pop for in an emergency.
Now, with that said I created a gmail account that I control (my password, my recovery email/phone #, etc.) and then used this to setup the Play store. I set up all the restrictions in the play store to what I believe is appropriate and of course I locked it by setting up my own PIN code so he couldn't change them.
I also setup his own google voice number and tied it to google hangouts/dialer but I can also monitor what he is doing on my phone periodically if I wanted. I'm not interested in him using Snapchat, WhatsApp, or any other kind of social network.
I've also setup OpenDNS on the wifi account he uses at home. So I think I have things pretty much locked down with the exception of installing from Unknown sources. And although he probably isn't computer savvy enough yet, at some point he will be.
So, with that said is there anyway I can build a rom that disables installing from Unknown Sources? Also, any other recommendations and tips from others are welcome.
Thanks.

He can get rid of everything you did if he could factory reset

seth.dean02 said:
He can get rid of everything you did if he could factory reset
Click to expand...
Click to collapse
Of course he could, but he's 8! He's probably not savvy enough to circumvent my efforts yet and when he is I'll change my approach.

pabdaddy1995 said:
Of course he could, but he's 8! He's probably not savvy enough to circumvent my efforts yet and when he is I'll change my approach.
Click to expand...
Click to collapse
Try one of the apps that allows you to lock apps. One is Applock and you may be able to lock down settings. That would prevent him from changing anything. You've probably thought of it already but some type of tracking app is a necessary safety measure for a child's phone. LOL, when he becomes a teenager you'll need the tracking for many more reasons.

SafetyNet bypassing via Magisk is officially getting over. Now what?

More on this thread by TopJohnWu
https://twitter.com/topjohnwu/status/1237998444800663553?s=20
https://twitter.com/topjohnwu/status/1237656705850212352?s=20

What exactly does this mean? Will it be impossible to run rooted applications once Google finishes rolling out this SafetyNet update?
Does the bootloader need to be unlocked to run rooted apps?

You know, I've come to the realization that this safetynet crap really just doesn't matter.
After all, it comes down to;
goober pay,
banks.
goober pay is so utterly pointless that while I managed to set it up just for the fun of setting it up, I never actually bothered to TEST it to see if it actually works, because frankly, its a lot simpler to wave a credit card near the terminal than to UNLOCK a cell phone and THEN wave it near the terminal.
And banks... well they're never going to stop their website from working, so you don't actually lose anything there.
Is there anything else? Some stupid game that wont work? Who cares.

96carboard said:
You know, I've come to the realization that this safetynet crap really just doesn't matter.
After all, it comes down to;
goober pay,
banks.
goober pay is so utterly pointless that while I managed to set it up just for the fun of setting it up, I never actually bothered to TEST it to see if it actually works, because frankly, its a lot simpler to wave a credit card near the terminal than to UNLOCK a cell phone and THEN wave it near the terminal.
And banks... well they're never going to stop their website from working, so you don't actually lose anything there.
Is there anything else? Some stupid game that wont work? Who cares.
Click to expand...
Click to collapse
There are those few times that I don't have my wallet on me but need to pay for something, or needed money in a crunch and used my device to pay.

Also apps like Netflix won't work I think Amazon might but some apps require you to pass safety net from what I understand

Doesnt mean the end for all devices, at least for now, although that could be because i own and old one they arent too interested in
Certainly hasnt affected my Note4, i do have to use magiskhide props config (to install a valid fingerprint) on Android 10 to get my Note to pass CTS - something that wasnt needed until Android 10, but once done, i just use my GPay SQLite Fix magisk module (just packages the well known Google Pay SQL hack into a module for easy install) and Google Pay works fine. I will likely be moving to a Pixel 2 XL next week as my Note 4 is finally at EOL, so will test then
For the curious, my Gpay SQLite Fix module is linked in my sig, my post and download are hosted in the original thread for the SQL hack, so read the OP as well to know what it does if youre curious
Note: i also use magiskhide props config to add a few build.prop lines to change my manufacturer to google so my Samsung Buds+ will work....failing to do this will error under Samsung Wear complaining about an altered Samsung device - just tell it its not a Samsung device and all is good

Afaik the Pixel 2 has basic attestation, more likely to be an issue with devices using hardware attestation...
I just tested it in magisk with the new inbuilt test and confirmed its still passing and on basic attestation...