Overcoming the Android OS Pattern Lock, a Practical Approach

Image

Pattern lock screen on Android OS mobile phone.

The Android pattern lock feature found sudden fame when it recently became the focus of  a federal search warrant petition. FBI investigators referred to the pattern-locking mechanism  when they asked that the court require Google to provide either access to the suspect’s account that the fail-over unlock code was maintained by or to “turn over a Samsung default code” or instructions to pass the pattern lock and gain access to the device.

The Android pattern lock is an incredibly user-friendly, and safe, method of locking an Android device’s screen. During set-up of the pattern lock users connect a series of dots in the pattern of their choice and set the lock.  Other options for locking include the conventional entry of a pass code consisting of letters, numbers and special characters.

Several mobile phone forensics groups commented publicly that the Android pattern lock was a force to be reckoned with from a technical perspective.  Most experts cited the lock-out effect, meaning that the phone will stop allow attempts to enter the correct pattern after repeated failed attempts.  Once this stage is reached the remedy for the average user is to use their Google email account to reset the lock. The lock out effect also means that a brute force attack on the lock pattern will only repeat in a fast shut-out of future attempts to guess the pattern.

Overcoming the Android pattern lock does not have to mean a brute force attack or a resulting lock out. The most important part of the Android pattern lock workaround is the understanding that the pattern lock does not encrypt the device data, it simply protects access to the data. This places the emphasis on gaining access to the underlying system and file data and not cracking the lock. By using a forensics tool to root the device and engage the USB debugging mode, the reviewer is able to create a replica of the full file system, application data, logs, cached information, databases, and past geo-data.

Replacing the current pattern lock with a new, known pattern lock entirely is also easily achieved when the device is rooted. The critical dependencies for the pattern lock are the pc.key and gesture.key files in the data/system/ folders. Replacing the pattern sequence in that file with a new pattern sequence will allow for entry post reboot. Replacing the pattern sequence becomes easier if the reviewer copies a the sequence from a test device’s pc.key or gesture.key file. It is important to note that injecting new files into an evidence phone file system is not best-practice but practical knowledge of what these files look like and where they are located can be helpful during an actual forensic device review.

For many types of reviews, the above workaround will provide the level of information necessary. However, rooting a device with any tool has inherit risks and some evidence-gathering procedures require that the system files, including rooting of the device, remain unchanged during the collection of evidence as was the case with the recent FBI search warrant. Barring these issues, the workaround presented here cuts to the chase and gains access to the information behind a pattern lock quickly and in most cases without complication.

Finally, a great tool for reviews and performing discovery is the Oxygen Forensics Suite. And remember, if your agency or prosecution team has a policy against the rooting of a device, ie. changing the phone settings in any way, be sure to turn off the auto-rooting function of your tools or use the tools manually instead of running the wizards.

Author Carol Glennon

iOS Development, XCode

Distributing iOS Applications for Private Testing, The Magic of Ad Hoc

The design, build and testing process for an iOS application should be extensive and iterative.  Combining excellent human-interface design with well-functioning code are the visible hallmarks of the best iOS store applications. 
A large part of the behind-the-scenes magic for top iOS applications is the manner in which they are tested long before being submitted to iTunes for final approval.
Ad hoc distribution makes private testing readily available to stakeholders on their personal iOS devices.

The typical development cycle for an iOS application will include rounds of testing, bug fixes and more testing. Once most major bugs are cleared, user acceptance testing takes place. This step gets difficult for brands that have distributed stakeholders or a combination of internal and external stakeholders.
Faced with the issue of distributing a test build of an application to disparate stakeholders many developers choose to undergo an early submission to the iTunes store to achieve easy distribution to the stakeholders for approval. The hope with this approach is that the submission goes largely unnoticed by the general public and that the stakeholders will have time to review the application after being asked to download it via the public store. The stakeholders provide feedback, normally under a tight deadline, in turn the development and product teams make an iterative update to the application incorporating the feedback. After the update to the application is successful the brand formally announces the launch to the public.
The risk of wide-spread, early public exposure and the tight response times required of stakeholders create a perfect storm that can be avoided by using ad hoc distribution or in-house distribution.
Ad hoc distribution allows for limited distribution, for up to 100 devices, of a fully-functioning iOS application. Stakeholders receive a private, ad hoc application file, install it using iTunes and can test without pressure.
To create the ad hoc application for distribution developers must build an Xcode archive of the application. They should then locate the archive in the archive organizer and select “Distribute.” Choose “Save for enterprise or ad hoc deployment” and then save the resulting .ipa file to send to stakeholders for installation. User installation consists of dragging and dropping the .ipa file into the Application folder in iTunes and then connecting their iOS device.
The ad hoc process requires that the stakeholders submit their iOS device’s ID or UDID, a unique 40 character string, to developers for addition to the iOS provisioning portal. This process allows 100 devices per calendar year, for each Standard iOS development membership. At the beginning of the calendar year old devices may be deleted to make room for new devices to be added for that year.
Developers enrolled in the iOS Enterprise program are able to distribute applications in-house to an unlimited number of devices using the same process. Files distributed in this fashion should be protected as the file is able to be installed on any iOS device without requiring a pre-registration of the device ID. The enterprise distribution method is also appropriate for applications that are built and designed for permanent internal use by an organization.
Ad hoc application distribution encourages significant stakeholder involvement in the iterative process. This behind-the-scenes iOS magic makes all the difference between simply getting an application out the door and building a truly great application with stakeholder buy-in.

Author Carol Glennon