August 15, 2014 By: Jimmy McGee
The “secure” Blackphone has been rooted! That and much more news is covered by Jordan when he reviews all the important stories from this week. Included in this week’s news is the Qualcomm Security Exploit being demonstrated at Blackhat Conference and the article talking about Code Syntax Highlighting being enabled on the XDA Forums! That’s not all that’s covered in today’s video!
Jordan talks about the other videos released this week on XDA Developer TV. XDA Developer TV Producer TK released an Xposed Tuesday video for YourTube. Then Jordan showed off how to root the Nvidia SHIELD Tablet. And later TK gave us a an Android App Review of HandyCall. Pull up a chair and check out this video.
August 11, 2014 By: Faiz Malkani
The annual Blackhat conference, now in its 17th year, took place in Las Vegas last week. The conference is an assembly of security-focused individuals at which a number of devices such as home automation systems, smart cars, etc are hacked, in addition to a line up of speakers discussing information security. This year’s event turned out to be rather momentous with the SilentCircle’s Blackphone being rooted by XDA Senior Recognized Developer jcase. Another interesting development was Dan Rosenberg’s discussion, which popped up on the speakers list as ““including a live demonstration of using it to permanently unlock the bootloader of a major Android phone,”.
As it turned out, Dan Rosenberg, also known as XDA Recognized Developer DJRBliss, published a report which detailed a security vulnerability in ARM’s TrustZone, which is used by Qualcomm as a security layer on its Snapdragon line of processors. Rosenberg stated that this vulnerability existed on all Android devices that supported TrustZone and used a Snapdragon SoC, except the Samsung Galaxy S5 and HTC One M8, both of which have already been patched. He demonstrated his claim by unlocking a Moto X bootloader on stage, going on to say that a number of devices including Nexus 4 and Nexus 5, LG G2, Samsung Galaxy Note 3 were vulnerable.
While this is a notable discovery, it poses no immediate threat since Rosenberg did not release his exploit to the public, which allows manufacturers to patch it before any serious damage is done. Have a look at his full report in this summary image.
August 4, 2014 By: Jimmy McGee
Android 4.4.3 KitKat has been released for the Verizon G Pad 8.3! That and much more news is covered by Jordan when he reviews all the important stories from this weekend. Included in this week’s news is the article talking about getting Navigation on your Samsung Gear 2. Also, be sure the check out the article talking about the Android Fake ID vulnerability! That’s not all that’s covered in today’s video!
Jordan talks about the other video released this weekend on XDA Developer TV, where TK released a video showing you how to root the OnePlus One and the addition of the experimental Linux Kernel 3.10 defconfigs for some SoCs. So pull up a chair and check out this video.
August 2, 2014 By: Tomek Kondrat
While Android is considered a pretty stable and safe operating system, there are some vulnerabilities that pop up from time to time. Some of them are pretty nasty, and force Google to release a minor revision to their OS. But developers here on XDA don’t like to wait, so they often take matters into their own hands before Google officially addresses the problem.
One of the recently discovered bugs is known as the Android Fake ID, and it has been present in Android’s source code since 2010. The bug allows malicious apps to pretend to be signed by trusted providers. This in turn allows them to be loaded as extensions in several contexts such as NFC access, browser plugins, and more. Unfortunately, it seems that the bug affects all devices. XDA Recognized Contributor Tungstwenty, co-creator of Xposed Framework, came to the rescue and created a module that squashes the vulnerability in seconds. Simple as that, without changing a line in the source code or modifying a single binary.
The fix will work only on rooted devices with Xposed Framework installed and running. To make use of this module, you need to enable it in Xposed Installer and reboot your device. Once the process is completed, your device will be free of the Android Fake ID vulnerability.
So without further ado, you can find the module by visiting the FakeID vulnerability fix thread. If you want to read more about the Android Fake ID vulnerability, head over to this article on bluebox.com.
July 19, 2014 By: Tomek Kondrat
Software is never completely secure. If you think otherwise, you are in for a rude awakening. Every now and then, hackers will find a way to take control of an app or expose private data–for money, fun, or fame. Motives varies, but these types of hackers are extremely talented, and often their potential is wasted to illegal activities. One of good guys in finding and neutralizing security flaws is Google. Current efforts have been focused mainly on their own products like Chrome OS or Chrome browser. But now, the whole idea of protecting the Internet has gone to a new level.
The Android Open Source Project is a good example of how the community can be used to make a big project used by millions safer and more complete. Android isn’t made only by developers gathered together in Mountain View. We’ve seen some contributions made by multiple XDA developers like Senior Recognized Developers jcase and Chainfire. Google obviously found out that some talented hackers are spread all over the world, so they came up with a new initiative, Google Project Zero. It’s a team made of top Google security researchers that have a sole mission to keep the world safe–free of security flaws, like the Heartbleed bug in OpenSSL project. Google Project Zero’s mission is to try and expose every security vulnerability and let companies know to fix them.
Google has already recruited some hackers from their own company and even XDA. New Zealander Ben Hawkes discovered dozens of bugs in software like Adobe Flash or Microsoft Office 2013. English researcher Tavis Ormandy discovered some zero-day vulnerabilities in antivirus software. Finally, George Hotz, for us known more as XDA Recognized Developer GeoHot, the creator of the Towelroot root exploit compatible with almost every device using an unpatched kernel. Before creating Towelroot, GeoHot was involved in iOS Jailbreaking and won the Pwnium hacking competition last March. Last but not least is Ian Beer. With such an All-Star team, Internet users will one day be a bit more safe.
It’s remain unanswered whether Google Project Zero will be a successful initiative. That said, exposing the flaws in order to encourage and allow companies to fix them is an innovative project, and other companies should follow the Google’s path in making the Web a safer place to work, communicate, and simply have fun.
July 18, 2014 By: Jimmy McGee
We’ve already reported on two of the speakers scheduled for XDA:DevCon 2014. Sony’s Alin Jerpelea and Mozilla’s Alex Lakatos are joining us, as we go international with xda:devcon ’14. If you haven’t heard, it will be held in Manchester, UK on the weekend of September 26-28.
Today, we are happy to announce another great speaker that will be at xda:devcon ’14. With many different governments spying on you, Android security is a big topic. So to cover the important information of Android security, full-time master student engineering at the department of Computer Science at the KU Leuven University Dario Incalza will be presenting. Incalza has been involved with Android development for four years and passionate about security since the age of 13-14. He has been combining both of these over the last few years. His studies have him majoring in the development of secure software with a master thesis focusing on the security of web-based Android applications.
At xda:devcon ’13, we had a great presentation about how the very exploits we often use to root our phones expose us and others to malicious software such as spyware, bots, keyloggers, and other forms of malware. This year, Incalza offers up another excellent presentation talking about Android Security with a presentation entitled, “Android Security Overview and Safe Practices for Web-Based Android Applications.” The talks will give you a brief overview of the different layers of the Android platform, with a focus on the parts attackers find interesting. Next, the presentation will talk about the several attack surfaces for Android, like remote, physical and more. Finally, the presentation will segue into Web-based apps, as Web applications have different security implications. This talk aims to give developers the information and motivations to take better care of security when developing.
June 25, 2014 By: Pulser_G2
With the announcement of Android L now finished at Google I/O, there are still a number of unanswered questions as to what’s actually likely to be coming in Android L. We mentioned some of the changes we know are coming earlier, as well as a bit more about the new design philosophy on the way, but there wasn’t much detail given over some of the new changes.
We’ve been taking a look to see what we could find, and XDA Senior Recognized Developer XpLoDWilD helped us root out what looks to be an interesting new feature–tucked away among all the other information about Android L and the new design philosophy are a few interesting gems. One of these gems comes in the form of a screenshot, which appears to suggest that the Android permissions system will be introducing some “at-time-of-use” prompts, somewhat like iOS.
As shown in the image above, it appears that the Permissions UI is extending to cover a prompt issued at time of use, allowing the user to allow or deny the location information. While these don’t, at a glance, appear hugely different to the existing prompts to enable Location Services, we suspect these are different and tie into the new Unified Data Controls discussed in the keynote. The wording indicates this permission prompt affects only the one app, which would appear to indicate that there will be some iOS permissions prompts when apps seek to access sensitive data, or use features which require permissions.
This would certainly be an interesting step forwards, as it would raise user awareness of what apps have access to, and also give users an option to disable an app’s access to the permission, if they feel it is excessive. We’ll know for sure tomorrow though, when the Android L developer preview lands.
June 16, 2014 By: Will Verduzco
If you’ve ever tried to modify and reinstall a system application, you probably encountered application signature checks in one form or another. Either you removed the original app before proceeding, or you gave your modified APK another package name in order to get it to install without first removing the old application. And in either case, you also had to re-sign the application yourself in order to get it to install in the first place.
You can get around all of these behaviors by temporarily disabling application signature checks. But before we get into the metaphorical meat and potatoes of this article and tell you how to do so, it’s critical that we talk a little bit about application signature checks, what they do, and why you should never remove them in the vast majority of cases. READ ON »
June 11, 2014 By: Pulser_G2
After yesterday’s article about Google’s recent changes to the Play Store that post a number of privacy concerns for users, today we are going to look at the three most popular options for users to protect their own privacy on their Android devices. First though, let’s take a look at how they work, and what they are for.
Since the start, Android has had a permissions system, to allow users to control what apps are able to do on their device. When an application is installed, the user is prompted to agree to the permissions that an app requires. The Android operating system ensures apps cannot use permissions they have not requested, and the user is responsible for deciding if an app can be installed.
At first this worked well, as users could see what data an app could access. Unfortunately, however, developers found that very few users paid much attention to the permissions prompts, and it became more common for developers to use more and more permissions–presumably to either improve user experience or monetize their apps.
In light of this, today we have reached a point where a front-page featured game from the Play Store makes use of the following permissions:
All this for a game that lets you play some fantasy football? At this point, I must open up a few questions to the reader (feel free to discuss in the comments below): Is there any possible justification for about half of these permissions? Is it necessary for this app to see what other apps a user is using? Or to see what accounts the user has on his/her device? Or to access your exact location in the world using GPS? Or to read your IMEI number, and the phone number of someone you are on a phone call with?
This is not an isolated incident. It is just the first app I selected on the front page of the Play Store. Select another, and have a look for yourself! Because of the fact that the vast majority of apps are now making use of what I argue to be excessive permissions, a growing number of users feel it’s no longer enough to simply not use applications that use excessive permissions. That gives rise to a common request, which is for users to select which permissions an app can access. This returns the balance of power towards the user, whose phone is running the app, rather than the developer, who was previously free to dictate the permissions their app required to run.
The obvious solution for the tech community is to develop ways to have greater control over what apps are able to do, and to prevent them from using all of the permissions which they request. The three most common ways to revoke permissions are App Ops, Privacy Guard, and XPrivacy.
The first way to get more control over your device is via a feature known as “App Ops.” This was originally introduced by Google in Android 4.3 as a hidden feature. With the release of KitKat, Google made it more difficult to access App Ops, but continued to introduce new improvements to the feature. Ultimately in Android 4.4.2, Google removed access to App Ops. However, it’s still possible to access with root and an Xposed modification or custom ROM.
The main limitation of App Ops is that, being made by Google, it only lets you block access to things that they are willing to let you block. Notably, App Ops doesn’t provide any ability to control whether an application should have access to the Internet. It’s also not possible to prevent apps from uniquely identifying your device, or you as a user, via your third party accounts. This means that an app can still tie together all of your account identities on your device and access your IMEI and other unique device identifiers with the appropriate permissions, and it’s not possible to prevent this using App Ops.
A cynic could argue that Google has a serious ulterior motive to prevent users from blocking apps from accessing the Internet. After all, Google has incentive to push their in-app advertising and gather information about users for Google Analytics. Likewise, Google is proficient at creating a profile of its users, which would explain why it’s not possible to block your identity from applications via your account names. The ability to access unique device identifiers only helps to allow other applications to track your usage (and thus allow Google to track your usage across applications).
For this reason, we believe that while App Ops is a lot better than nothing (you can control access to your contacts, messages, location, and so on), it is definitely not the best solution for protecting your privacy. There are a number of types of data that cannot be blocked, and it appears these may be related to Google’s motives in tracking and gathering data on its users. As such, we recommend you look at alternatives.
Privacy Guard is a feature originally developed by CyanogenMod to place a simple user interface over App Ops with a single “on/ off” toggle to control it. As such, Privacy Guard is subject to the same criticisms as App Ops in its limitations. It also imposes a notification at all times while running an application protected by Privacy Guard, supposedly to remind users that it is in operation.
Unfortunately, however, Privacy Guard makes no attempt to anonymize users or prevent apps from tracking their sessions via device identifiers or Internet access. With a single on-off control however, it’s certainly easy to use for beginners, and the default settings should be fairly good. The only downside is the lack of granularity, meaning that an app needing access to your location cannot be allowed that, while still blocking contacts and calendar access. Nonetheless, as a one-click solution, it works nicely. It does require the user to install a custom firmware though, which spoils the benefits of one-click appeal.
XPrivacy is the Swiss Army Knife of Android privacy protection. Compared to the other solutions we’ve looked at here, XPrivacy is much more customizable, but also much more complicated as a result. If you’re unfamiliar with Android permissions, XPrivacy is probably not the best place to start. It requires the Xposed framework, which means you also need a rooted device. However, XPrivacy should work on almost any ROM.
The main advantage of XPrivacy over alternatives is the sheer breadth and granularity of restrictions you can impose on apps. You can restrict an app to only be able to access and see certain accounts on your device, block access to your clipboard (to stop an app from accessing copied data), and even block access to the Internet, both directly, and via the web browser (to prevent any means of covert data exfiltration from your device). If there’s something you want to restrict, it’s almost guaranteed XPrivacy can restrict it.
Despite being a very powerful tool, there’s a large learning curve behind XPrivacy. I’d suggest reading through all the documentation on XDA Recognized Developer m66b’s Github repository (did I mention it’s fully open source?), and his thread on the XDA forums, for more information.
Overall, if you want absolute control over your private data, I’d recommend you check out XPrivacy. It takes a lot of getting used to, but it gives you unparalleled choice. If you are not quite as certain about what you’re doing, using App Ops will give you good control, albeit without the ability to control Internet access and data that identifies you as the user of the device. Both App Ops and XPrivacy are available on any ROM, via Xposed plugins. Privacy Guard is good for someone who simply wants a one-click solution, but the need to install a custom ROM to achieve it is a limitation in this regard, as you cannot (currently) find an implementation on stock firmwares.
June 6, 2014 By: Tomek Kondrat
A good developer is always concerned about the security of his/her users. Revealing your app’s private data to the public is generally a bad thing, and should almost always be avoided. As such, there are various ways to strengthen your app’s privacy, and every new method should be evaluated. Privacy protection is especially important with Android applications, as there are frequent reports of app-related phishing and similar shady activities.
You application’s private data can now be stored a bit safer, thanks to XDA Forum Moderator Jonny. He provides a Java class that protects your app’s data using the SHA-512 hashing algorithm to convert a string into a raw bit format. After that, it’s converted into hex strings. In plain English, the data sent to the application will be quite safe. The class provided by Jonny also adds a salt to the hash function, which makes your users’ private data even more secure.
If you are developing apps that use sensitive data such as logins, passwords, and other personal information, make your way to the original thread and consider enhancing the security of your project with this class.
Smartphones are undoubtedly the most “personal” of our personal computers. We use them to access our Email, banking information, and pretty much the rest of our private data. Luckily, there are quite a few file locker applications available to help keep prying eyes away from our Gmail. However, things get a bit trickier if you’re looking to hide files that reside on your device’s storage.
Sure, you can easily encrypt your internal storage through Android’s security settings menu, but what about your external storage? And what about those who want to let others casually access their devices but don’t want their tech savvy friends viewing their naughty selfies? Luckily, XDA Senior Member Doplgangr offers up a great app to encrypt files of your choosing.
Secrecy, as its name implies, allows you to hide and encrypt various files of your choosing. These can be pictures, videos, or any other file type. And unlike many other available options, Secrecy actually encrypts the files in question, rather than simply storing them as raw data in a hidden location.
Now there is one caveat here, and it’s a big one. While this application states that every file is encrypted with AES256, it is not open source. Thus, you can never truly be sure how securely your files are being stored. But for the casual user simply looking to make certain files inaccessible when a device is mounted to a PC, Secrecy certainly does the trick.
If you’re looking for a simple and user-friendly way of hiding your files, head over to the application thread and give Secrecy a shot.
April 10, 2014 By: Will Verduzco
Back in October of last year, we talked in depth about malware on Android and the platform’s multiple layers of defense. One of the final pieces of puzzle is of course Android’s Verify Apps feature. And while only around 0.5% of applications end up triggering this security mechanism, it’s still a great safety net to have when dealing with closed source applications of untrusted origin.
The Verify Apps feature, which is available on devices running Android 2.3 Gingerbread or later, has traditionally scanned apps against known malware signatures as they are installed. Now, Google has expanded the functionality of Verify Apps with constant device monitoring. This means that in addition to messages while installing applications with known malicious signatures (left two screenshots), your device will constantly search its installed applications for malware (right two).
In practice, the new functionality shouldn’t have too great of an impact on end-user security. Google states that after receiving a warning, only 0.18% of users actually end up installing the potentially malicious application. But then again, the list of known malicious signatures is constantly expanding, so even users who diligently deny installation to flagged apps will benefit.
The update to Verify Apps will be rolling out to your device through Google Play Services shortly, if it hasn’t already. Have you ever fallen victim to malware on Android? Have you seen any of the warnings above? Let us know in the comments below!
[Source: Official Android Blog]
March 13, 2014 By: Will Verduzco
Earlier today, we talked about how the Replicant team found a potential backdoor in Samsung’s proprietary radio software. As demonstrated in a proof-of-concept attack, this allowed certain baseband code to gain access to a device’s storage under a specific set of circumstances. But upon closer inspection, this backdoor is most likely not as bad as it was initially made out to be.
A few hours after posting our previous article on the alleged backdoor, a highly respected security expert who wishes to remain anonymous approached us, stating that the way in which the proof-of-concept attack was framed by the Replicant team was a bit misleading. Essentially, it boils down to the POC requiring a modified firmware with with security features disabled. Thus, if a user is running an updated version of the official firmware, this attack will not work. To that end, the Replicant team even states in their write-up that SELinux would considerably restrict the potential files that the modem can access, such as those on the /sdcard partition.
Now, another highly trusted security researcher (XDA Recognized Developer djrbliss) has gone on record with Ars, stating that there’s “virtually no evidence” that this is indeed a true backdoor, although his reasons are a bit different. There is absolutely no indication at this time that the baseband file access can be controlled remotely. Rather, this is only a “possibility,” since the baseband software is proprietary. Instead, it’s far more likely that this was only ever intended to write radio diagnostic files to the /efs/root directory, as that is is the radio user’s home directory.
In summary, we shouldn’t rush to replace our Samsung phones just yet. There is absolutely no evidence to state that this can be controlled remotely. And even if it were possible, using SELinux, which is set to Enforcing in stock firmware, would restrict the radio user’s access.