The Busy Coder's Guide to Android Development Version 6.0 Released
Subscribers now have access to the latest release of The Busy Coder’s Guide to Android Development, known as Version 6.0, in all formats. Just log into your Warescription page and download away, or set up an account and subscribe!
This largely completes the Big Book Pivot of 2014, adding Android Studio coverage to all of the core chapters (including the tutorials) and some of the trails.
Along the way, this includes:
build.gradle files for all projects
De-Sherlocking all projects, except those that are specifically demonstrating ActionBarSherlock
Removing the chapter on IntelliJ IDEA and replacing it with material more specific to Android Studio
This book update also:
Adds a chapter on the manifest merger process, with particular emphasis on Gradle for Android and how manifests from different sourcesets plus libraries combine to create the generated manifest for the app itself
Adds a number of small improvements to the core chapters, as part of a more thorough review of that material
Tweaks the tutorials, partly to deal with Android Studio issues, and other minor changes to improve the instructions
Various errata fixes
Updates should now return to their normal every-four-to-six-weeks cycle, emphasizing new APIs, tools, and the like. I am planning on three updates yet in 2014, with Version 6.1 due out in early October.
If you are not a subscriber, you may wish to learn what the Warescription has to offer. The book, plus a year’s updates and other Warescription benefits, costs $45 (credit card/debit card/PayPal) or its equivalent in Bitcoin.
—Sep 03, 2014
Defending Against "Camera Peeking" Attacks
Yesterday, I blogged about a research paper describing various attacks. In yesterday’s post, I covered defending against another activity popping up and masquerading one of your critical activities.
Another attack outlined by the paper is easier for an attacker to use… but is also easier to defend against. The paper’s authors refer to it as the “camera peeking” attack.
A camera, as identified by an instance of
android.hardware.Camera, can only be used by one app at a time. The attack is simple:
monitor for when an app that might use the camera for something important comes to the foreground
at that point, start watching for the
Camera object to become unavailable
Camera is unavailable, then available again, grab the
Camera and take a picture, in hopes that the camera is still pointing at the confidential information
The example cited by the paper’s authors is to watch for a banking app taking a photo of a check, to try to take another photo of the check to send to those who might use the information for various types of fraud.
Polling for camera availability is slow, simply because the primary way to see if the camera is available is to
open() it, and that takes hundreds of milliseconds. The paper’s specific technique helped to minimize the polling, by knowing when the right activity was in the foreground and therefore the camera was probably already in use. Then, it would be a matter of polling until the camera is available again and taking a picture. Even without the paper’s specific attack techniques, this general attack is possible, and it would not surprise me if there are more efficient ways to see if the camera is in use.
On the other hand, the defense is simple: if your app is taking pictures, and those pictures may be of sensitive documents, ask the user to point the camera somewhere else before you release the
Camera object. So long as you have exclusive control over the camera, nothing else can use it, including any attackers.
A sophisticated implementation of this might use image-recognition techniques to see, based upon preview frames plus the taken picture, if the camera is pointing somewhere else. For example, a banking app offering check-scanning might determine if the dominant color in the camera field significantly changes, as that would suggest that the camera is no longer pointed at a check, since checks are typically fairly monochromatic.
Or, just ask the user to point the camera somewhere else, then release the
Camera object after some random number of seconds.
General-purpose camera apps might offer an “enhanced security” mode that does this sort of thing, but having that on by default might annoy the user trying to take pictures at the zoo, or at a sporting event. However, document-scanning apps might want to have this mode on by default, and check-scanning apps might simply always use this mode.
—Aug 26, 2014
Defending Against Activityjack Attacks
A number of media outlets reported on a research paper and USENIX conference presentation describing a way by which your users could be tricked into providing confidential information — passwords, credit card information, and such — to a piece of malware, rather than to your app.
The paper points out that there are ways of writing malware such that:
the malware can pop an activity in front of yours, and
do so at just the right time, to mimic one of your activities, such that the user thinks that the malware’s activity is actually yours and enters the confidential data into the malware activity
For the purposes of this blog post, I’ll refer to this as an “activityjack” attack. Just as a clickjacking attack tricks Web users into clicking on the wrong things, and just as a tapjacking attack steals Android touch events via a transparent layer on top of the screen, an activityjack attack steals input destined for your activity by interposing another activity on top of yours.
The particular means of implementing the activityjack attack outlined in the paper is a bit esoteric. What it does do, though, is illustrate that such an attack is possible. Half the battle with security is knowing what you need to defend against.
The paper outlines solutions to their particular flavor of activityjack attack that require OS modifications. That’s fine, and perhaps the Android project will implement that stuff. But it will take years for such changes to percolate through the Android device ecosystem. For example, tapjacking was “solved” in Android 4.0, but there are millions of people using devices older than that, even today. Hence, we need to think as much, if not more, about application-level solutions.
Let’s ignore the details of the particular approach from the paper. Let’s merely assume that an attacker can get their activity in front of ours at the right time, as there are less-esoteric ways of doing the same thing (e.g., via an
AccessibilityService). How do we defend against that for critical activities, such as “login” activities that require the user enter a passphrase?
An activityjack attack has two key weaknesses:
The attacker cannot see the screen, because on non-buggy devices, the attacker has no means of capturing a screenshot of our activity as it comes into the foreground. Hence, while the attacker can create an activity that tries to mimic ours, they can only do so statically, analyzing our activity’s UI on their development machine and creating their own lookalike.
We know that our activity has left the foreground, as we are called with
onPause() (and perhaps other lifecycle methods, depending upon the nature of the attacker).
Hence, one defense can be to include in our activity a secure element that cannot be mimicked ahead of time, then hide that element (or our whole UI) when we are no longer in the foreground.
This concept of a secure element is not new. Some financial services Web sites have taken this approach. As part of the user setting up their online banking account, the user chooses an image from a collection of clipart. On the Web page that collects the user’s passphrase, the page also shows this secure element. The user is taught that if they do not see their chosen image, then the Web page they are looking at is not really from their bank, and therefore they should not type in their passphrase.
This is not that hard to implement in Android. You too would allow the user to choose a piece of clipart, displaying that in an
ImageView on your secure activity in
onPause() you would hide that
setVisibility(View.INVISIBLE). That way:
Since the image is chosen by the user, the attacker is unlikely to mimic the same image
Since you are hiding the image when you are not in the foreground, the attacker cannot use a transparent region in their activity to have your image “peek through” their attacking activity
As a result, if the user is paying attention, the user should see either the wrong image or no image at all, and the user should realize that they are being activityjacked and therefore fail to proceed.
You might be tempted to do something else in response to your secure activity being replaced in the foreground by another app’s activity, such as pop up a warning dialog. However, there are plenty of valid scenarios when this would occur, such as an incoming phone call, and you have no reliable means of whitelisting all possible valid scenarios. There will be a high incidence of false positives, and that may not help the user. Having this as an user-selectable option is fine, but I would not go this route by default.
With luck, somebody will come up with a better defense, one that makes it more likely that the user will not provide confidential information to the attacker, yet not be so onerous that they get fed up with your app and uninstall you. However, this approach should be reasonably easy to implement and help defend your users from activityjacking attacks in critical activities.
—Aug 25, 2014
The Return of "Gradle for Android... and You!"
“Gradle for Android… and You!” is back!
Earlier this year, I offered a 30-minute free webinar on Gradle for Android: what it is and why it will be important for you, here in 2014 and beyond.
I am running “Gradle for Android… and You!” again in September and early October, with two changes:
It is now a 45-minute webinar, getting into more about how Android Studio and Gradle for Android are related, how Gradle for Android relates to the larger Android development ecosystem, and more.
To register, you need to make a donation to the Electronic Frontier Foundation. Proceeds from these webinars — minus Eventbrite processing fees — will be contributed to the EFF once the webinars are done. Eventbrite’s minimum donation is $1.
So, if you have been hearing about Gradle for Android and are trying to determine what it gives you and why you should be considering it, sign up for the webinar!
Note that this is not a deep technical dive into how to use Gradle for Android. Gradleware and I have an online training course for that, plus the material in my book on the subject.
—Aug 20, 2014
Want to Review a Beta Book?
UPDATE: This program is now closed – thanks to all who responded!
Version 6.0 of The Busy Coder’s Guide to Android Development should be released around September 4th. At the suggestion of a subscriber, I am offering early access to a draft of the book to 10 active subscribers who are interested in reviewing the new Android Studio coverage. I should be delivering this draft late this week, so reviewers would have a bit over a week to examine the draft and provide any feedback.
Besides the cap of 10 reviewers, there are some limits on this program:
It is open to active subscribers only, not to former subscribers or the general public.
The draft will only be published in PDF form. In particular, I am testing smallpdf’s PDF compression service, which so far has worked remarkably well in reducing the PDF file size while not seeming to wreck images and whatnot.
I will offer a limited version of the Book Bug Bounty program, where any reviewer who reports bugs in the draft gets a six-month Warescription extension. The normal bounty program offers six months per emailed bug report, but as I will not have completed my own review of the changes by the time I deliver the draft, I am capping the bounty for the draft to one bounty per reviewer.
This is a one-time program, to help with the extensive changes going into this book update. If this program is a success, I may do it for future changes of similar scope, but there will be a fresh call for reviewers at that point.
I reserve the right to cancel the program, though I have no idea why I would.
If you are interested in reviewing the draft of Version 6.0 of my book, please send me an email, stating that you are interested in this program, along with your Warescription user ID. I will reply to let you know if you successfully qualified. I will update the blog post once I have 10 reviewers to indicate that the program is not accepting new candidates.
Thanks in advance to everyone who reviews the draft!
—Aug 18, 2014