Tag Archives: Android

Smartphone kill switches – a bad idea

A recent Star Tribune article noted that state and federal lawmakers are attempting to pass legislation mandating a “kill switch” for smartphones.  On the surface, this seems like a pretty good idea – after all, many of us are walking around with handheld devices worth hundreds of dollars, and those devices are a natural target for thieves.  If a customer can contact their service provider and get the device permanently shut down, the smartphone loses its value on the black market, deterring the theft in the first place.

But there’s a downside to this kill switch technology, which may not be obvious at first glance.  Some might call it a useful feature, but others see a bug which is more likely to impact users than the problem it solves.

Let’s remember that it’s only the idea of a kill-switch which is useful – the concept is to have it act as a deterrent.  The thief suddenly chooses not steal your phone because the market for stolen phones is depressed; customers are now able to contact their service provider and have that phone shut down.

Since technical details are still unclear at this early stage, it’s impossible to outline all the ways this concept is flawed.  But there are a few different scenarios which should be outlined in order to note how this kill switch would harm consumers.

The first is the most obvious – that this feature will be abused by law enforcement.  The kill switch will undoubtedly be asked to be activated against someone suspected of committing a crime, and possibly against those who have contacted a suspect.  Taking videos of a police officer is now an act that could revoke your cellular privileges.  Participating in a protest could also result in your phone being shut off since you could use it to communicate with others about where riot police are gathering – it’s for your own safety.

The second thing to remember is that the kill switch is permanent.  So when you’ve lost your phone and may have left it in a cab or between the couch cushions, once your phone has been disabled (which is a good idea if you have an sensitive data on your phone, such as access to your email), you’ll be buying a new one, which is exactly what the kill switch is supposed to prevent.  In the Marketplace article linked above, the subject mentions he’s had his phone stolen three times, and gotten it back twice.  Why bother getting it back if you’ve reported the theft and the carrier has had it rendered permanently inoperable?

There are those out there who think that carriers are refusing to install kill switches on their phones because they sell more phones this way, that phone thefts are a good way to keep reaching into their customers’ pockets.  A reminder about the players in this game is in order: carriers still essentially buy phones from manufacturers like HTC and Apple, and resell them at very little markup – the carriers still make a bulk of their profits through plans.  In fact, the addition of a kill switch to smartphones would negatively impact the used-phone market and force consumers to buy new devices – you really want to take a chance buying a used phone on ebay if it can be turned off at a moment’s notice or is already bricked?

Next, let’s look at another problem – shadowy hackers!  Anyone out there know how cheaply a fake cell tower can be constructed?  At DEFCON in 2010, it was about $1500.  And if you’ve seen more recent videos of people making these things, you know they’re cheaper and more effective now – there’s no way to stop your phone from connecting to them if properly created.  What happens when a fake cell tower transmits a kill signal to every phone that connects to it?  Some police departments already have these fake cell towers – they’re generically called “IMSI catchers” and one commercial model is called KingFish.

If kill switches are mandated by law, expect problems such as those listed above.  Worse yet, if these phones that have kill switches are ever able to be re-activated, thieves will figure it out, the deterrent effect is gone, and phone theft will continue.  Your phone will be almost the same as before, but now could be shut down at any time.

So how do we prevent smartphone theft?  Well, most of us carry objects worth hundreds or thousands of dollars every day – they’re called wallets.  They have IDs, credit cards, and cash in them.  Wallets are often secured in a similar manner to a cell phone – in a pocket or a purse.  But when I get on the bus to go to work, no one is mindlessly playing Candy Crush on their wallet.

I know legislators are well-intentioned, and they’re probably just trying to help.  And they always score points when they take on companies that are generally reviled, like phone companies.  But there are more important battles to fight than this one, and the idea of a  cellphone kill switch creates more problems than it solves.

Eclipse – R cannot be resolved to a variable

I’ve never really played with Android development too much, but I decided to give it a shot last night.  I found a few YouTube tutorials, but decided to start with Google’s Android dev tutorial.  I ran into a problem almost immediately, but my usual Google searches weren’t too helpful.  Rather than just give up and watch 80’s videos on youtube, I decided to tackle the problem.

Basically, the error message that I received was “R cannot be resolved to a variable” – there are pages after pages of questions with this exact phrase from Stack Overflow.  There were a few common steps recommended, including one where the user was instructed to “Clean” the project.  This advice actually works, but not if you just “Clean” according to the default settings.  The default is to “Clean All Projects” which did not work for me, but changing the setting to “Clean Selected” then selecting my project actually did work.

I’m guessing it’s a bug within Eclipse, but it took me an hour to figure out, and hopefully there’s a chance Google will look favorably upon this humble blog post and promote it to users who are having the same problem.

So you want to root your phone?

One thing I really enjoy in life is learning how things work – I might not be the world’s most gifted programmer and not everything I do is groundbreaking, but I do know that if I get the sense that I don’t fully grasp some aspect of technology, I’m probably going to tackle it at some point. While often this involves some relatively short-lived pain, the end reward of knowledge is always worth it. So this is a tale of upgrading the Android operating system on my T-Mobile Samsung Galaxy S II, and the (many) mistakes I made along the way.

So there are a couple of reasons I wanted to upgrade my phone to Ice Cream Sandwich, which is Google’s cutesy codename for the 4.0 version of the Android operating system. Encryption is now built-in, Face Unlock is now enabled as a security option, and some improvements in the NFC capabilities (which I admit, my first thought was that it could be a potentially powerful pentesting weapon) were enough to convince me that upgrading to ICS was the right thing to do.

At this point, I was unaware that Samsung/T-Mobile was supporting an ICS distribution for the Galaxy S II. They were not pushing this update OTA, but rather through Samsung’s Kies software, which is a basic smartphone management utility. I had received previous incremental Gingerbread updates OTA, so had no reason to think they would not do the same for ICS. So if you want ICS without the hassle of rooting and installing a 3rd-party Android distro, download Kies and take that route.

So the first thing I needed to do was to gain root on the phone (I’m not totally sure if this is necessary, but the instructions I followed over at Cyanogenmod implied this). I actually got some information from a somewhat unlikely source (in general, I don’t trust domains that are so narrowly focused, probably a remnant from my SEO days), but the information given was good and it introduced me to ODIN, one of many tools whose name I would curse before the day was done.

Using ODIN I was able to replace the factory “recovery” mode with a custom one called ClockWorkMod Recovery – this method seemed like the first one to emerge (as opposed to using ClockWorkMod’s ROM Manager), so I used this, figuring there would be more documentation available should I run into problems.

So far, so good – got ClockWorkMod Recovery installed, and I’m ready to flash a new ROM onto my phone, hopefully from CyanogenMod. But here’s where I was thrown for a multi-hour, head-slamming-into-wall tailspin. Apparently there are several distinct models of phone which are all known colloquially as a Samsung Galaxy S II. Looking at the list of phones on the left side of the CyanogenMod Downloads page, I think I want the “galaxys2”, seeing as the other obvious possibility is the “galaxys2att” (the AT&T model).

Unfortunately, I notice that the only stable CyanogenMod ROMs for the Galaxy S2 are for version 7 of CyanogenMod, which equates to the Gingerbread build, not ICS. So I grab a copy of one of those, and a copy of the nightly build (not stable) for CM9, hoping that the build can actually run on my phone and that I’ll be an Alpha tester. I follow the instructions for flashing, and…my phone ends up in a reboot loop. Worse, I can no longer enter ClockWorkMod Recovery on my phone, and my phone displays a screen which says to recover using the Samsung Kies recovery mode.

So I run Kies, plug in my phone to the computer and…nothing. Kies doesn’t even recognize that I have a phone plugged in, so basically the phone is either constantly rebooting and I can’t enter any kind of recovery mode. Now I’m maybe starting to panic just a little. I try a few other things that I learn from Googling, but most of the message boards are dead ends, so I take a step back and fire up ODIN again.

During my search, I was also able to find a slightly more up-to-date version of ClockWorkMod Recovery, so I instruct ODIN to load that onto my phone and am relieved that this works and I’m able to get back to the CWM Recovery screen. So I follow the wiki instructions again and load the CM7 ROM – again, I’m faced with an endless reboot, an indication that things did not go so well.

Now I’m actually starting to panic, as I can’t even load the STABLE version of this software onto my phone, and I’m definitely following the wiki to the letter. So I have effectively transformed my phone into an expensive paperweight and am already starting to think about how I’m going to broach this subject at my local T-Mobile store.

So after trying a couple other ROMs, I decide to stop digging and backtrack a little bit. I go back to that first article on rooting the phone on my specific device (SGH-T989). Hmmm…what was that tarball called again – “recovery-cmw-hercules.tar”? Hercules, eh? So I head back to the CyanogenMod download page and sure enough, I hover over the word “hercules” and it says “Samsung Galaxy S2”! Hooray! My hopes are dashed seconds later, when I realize there are NO stable builds for my phone. I try installing the nightly, but without any luck – another endless reboot loop.

After some additional frantic googling, I finally stumble across AOKP, a group who has been working on implementing hardware support for the Hercules model of Samsung Galaxy S2. Apparently, they have developed a working ROM, but there were a few other hoops to jump through first, including using an additional wiping utility and flashing an update to the “modem” (I hate that term because it’s not an modulator-demodulator but I digress). You can take a look at some of their supported devices here and check out their open-source code as well.

Now, a few pros and cons about this install, compared to the stock Android 2.3.6 rev that T-Mobile pushed out. First, swype (or the swype equivalent used by T-Mobile) is not present, so I went ahead and installed the beta, and it seems to work well. It’s a little too permission-hungry for my tastes, so I am going to search out one of the apps that lets you restrict an application’s permissions and see how it holds up.

One thing I really like about the new install is that the bottom buttons light up if you get a text message. Maybe there is a way to set this up somewhere in my previous Android install, but it’s very handy to glance at your phone and see if you have a message rather than lighting up the entire phone’s screen. The UI is easier to customize now – a setting called ROM Control allows changes to the UI on a very granular scale. As I mentioned previously, the disk encryption seems to work as well.

Overall, I’m glad I went through the process, though at the time I questioned my sanity. I learned quite a bit about the Android development scene and the very talented people that help create this wonderful software.