Android Vulnerability Test Suite (VTS) is a program that checks for known Android OS-level vulnerabilities.
https://github.com/nowsecure/android-vts
https://play.google.com/store/apps/details?id=com.nowsecure.android.vts
Creator:
Tag: Android
Android IoT: Google Brillo and Weave
Google has began an invite program for their Brillo/Weave IoT project, which they announced earlier this year at Google I/O:
Brillo:
“Since May, we’ve opened up the Brillo operating system (OS) and Weave communication platform to early access partners. Today, we’re extending this to the broader developer community as part of our invite program. Read on to find out how you can receive an invitation. Brillo brings the simplicity and speed of software development to hardware by offering you a lightweight embedded OS based on Android, core services, a developer kit, and a developer console. You can choose from a variety of hardware capabilities and customization options, quickly move from prototype to production, and manage at scale with over the air (OTA) updates, metrics, and crash reporting.”
Weave:
“Once you’ve built your connected device, you’ll need to find a way for it to communicate with other devices and allow users to interact with it. That’s where Weave comes in. With Weave, you can build interoperable communications directly into your devices. Weave provides a messaging service that enables phones and devices to talk to each other locally and remotely through the cloud. The Weave cloud server handles remote communication and access to your web-connected device, safely and at scale. With Weave you also get a set of services to securely set up the device and provide controlled access. Additionally, Weave works seamlessly with, and is actually built right into, Brillo; but, you can also use Weave libraries with your existing Linux-based OS.”
Intel already has their Edison board ready for Brillo:
http://newsroom.intel.com/community/intel_newsroom/blog/2015/10/27/intel-edison-module-offers-brillo-support-at-launch
https://software.intel.com/en-us/blogs/2015/10/27/intel-edison-board-and-brillo
“The Intel Edison compute module is one of the first platforms to support Brillo, which Google released source code for today via an invitation program. Newegg will be offering a Brillo-compliant solution built upon the Intel Edison kit for Arduino. Intel expects to support Brillo on additional SoCs (system-on-chip) and IoT maker boards in the future.”
More Information:
http://www.forbes.com/sites/janakirammsv/2015/10/29/google-brillo-vs-apple-homekit-the-battleground-shifts-to-iot/
http://liliputing.com/2015/10/google-launches-android-based-brillo-os-for-internet-of-things.html
http://www.androidauthority.com/imaginations-new-ci40-creator-iot-board-will-run-brillo-from-google-651920/
Android-based "Brillo" IoT OS arrives with hacker SBC support
Android 6.0 OEMs: support Verified Boot
Multiple news sites have a story about Android 6.0 and Google’s new security requirements for OEMs, such as including Android Verified Boot.
http://www.tomshardware.com/news/marshmallow-encryption-fingerprints-verified-boot,30369.html
http://www.zdnet.com/article/google-now-requires-full-device-encryption-on-new-android-6-0-devices/
http://www.androidauthority.com/new-google-oem-marshmallow-requirements-650266/
XDA Developers on Android security -vs- control
There is a good article over on XDA Developers about how device security comes at the cost of owner control. Article is focused on Android, but really applies to many platforms these days.
Walled Gardens: The Trade-off Between Security and Modifiability
With the recent changes in Android 6.0 (Marshmallow) looking set to make life much more difficult for tinkerers, tweakers and modders, a question people often ask me is “why?” – why does (Company name) want to stop me modifying my phone? In this article, I aim to give a (hopefully) complete run-down of many of the factors at play here, and the motivations of involved parties, and who they actually are. There’s no way I will manage to completely cover every angle, but I shall give it my best shot – feel free to add anything you think I forgot in the comments below. […]
Article:
http://www.xda-developers.com/walled-gardens-the-trade-off-between-security-and-modifiability/
Android Security: Q3 Quarterly Update
Adrian Ludwig of Google posted a message to the android-security-discuss mailing list with a quarterly summary of security events. I’m not going to bother excerpting this!, I’m just going to post the entire message body:
TL;DR I’m going to start sending out a quarterly summary of things the major events going on in Android Security. Wow, did I pick a doozey of a quarter to start doing this.
Below, I’ve compiled my top 10 android security events and activities from the Q3, 2015. The last 3 months have been amazing — any one of these might have been the most important item for Android Security during most quarters. But all of this really did happen in just the last three months.
1. Monthly updates – Announced Nexus support policy with monthly security updates for Nexus <http://officialandroid.blogspot.com/2015/08/an-update-to-nexus-devices.html>. Pushed Samsung <http://www.androidcentral.com/samsung-plans-offer-new-security-updates-every-month-its-android-devices> and LG <http://www.engadget.com/2015/08/07/lg-stagefright-monthly-security-updates/> to make similar announcement (albeit still not realized). Shipped three updates <https://developers.google.com/android/nexus/images> to Nexus, GPE, Android One and published the corresponding security bulletins <https://groups.google.com/forum/#!forum/android-security-updates>.We also expanded to Kirkland team and began to grow the team to handle our increasing incident response needs <http://go/android-vulns-dashboard>.
2. Unprecedented partner engagement in security – Executive meetings on security with all major US carriers and top 5 OEMs. Worked with APE / TAM / BD to build program for Ecosystem-wide Monthly Security updates <http://go/manic-monday-pitch>, rolled out our security program to all carriers, OEMs, and began to track rollouts <https://dashboards.corp.google.com/#/google::_45984543_fda2_458b_9a8a_3fe0c1130981> of security patches to devices. Here are highlights from a recent program review <https://docs.google.com/presentation/d/1c6xYbGkcIlHD-RPsv00U4vTMrzl4_CuOd-eJrU6Lf4M/edit#slide=id.g702e6832b_0_0>.
3. Stagefright. Stagefright Code Yellow <http://go/stagefright-cy-track>. Media Server Bugs and Hackathon <https://docs.google.com/document/d/1icuQabxBlBBfjjP967YMLliIdSSm798BO20xdYA8q9Y/edit#heading=h.enzv5yxtjeu3>. Also, thanks to aarya@ of Chrome Security for driving that continued expansion of fuzzing efforts <https://docs.google.com/a/google.com/presentation/d/1docwgWwqZL0wEO5R0U5oRyMdnUhg9a3HMhmb-e5vyTM/edit?usp=drive_web>.
4. Android M Security Enhancements <https://docs.google.com/presentation/d/1JfRZ5P-HmuaKJvN3SgZmXWhfoC3sirr8OVtDXPRBQZk/edit#slide=id.gaf51a6178_1_132>- I can’t believe this is #4. We shipped Verified Boot. Monthly Patch String. SeLinux IOCTL filtering. UsesClearTextTraffic. SELinux User separation. The broader Android team also shipped a major overhaul of permissions, fingerprint API, adoption of SD cards, protection for USB connections, and more.
5. Results from Android Security Regards Program <https://www.google.com/about/appsecurity/android-rewards/> – Android Security Rewards launched on June 16 <https://googleonlinesecurity.blogspot.com/2015/06/announcing-security-rewards-for-android.html> and by October 1, we’ve paid out over $100,000 for over 60 issues.
6. Massive Increase in Public Outreach — aludwig @ Blackhat (slides <https://docs.google.com/presentation/d/1U35ilLs3ca8AHNYXKZgl14VjS5Q-RSx3GNVQqCGQWkQ/edit>, press), jeffv@ about ioctl filter <https://docs.google.com/a/google.com/presentation/d/1_meUW-MtHdCQC2YuWnrtJ7W6WXh7CTxfHz_N0TksRY4/edit?usp=drive_web> at Linux Security Summit, paullawrence@ and mhalcrow@ about encryption <https://docs.google.com/a/google.com/presentation/d/1xD2Vs5hHkY8GZB4Y72QAxsPf5sraAAQmse_3IAS2UA4/edit?usp=drive_web> at Linux Security Summit, nnk@ Android Security Symposium in Vienna(slides <https://docs.google.com/a/google.com/presentation/d/1-BWUaMldBoTzd0Vx9BnjWFP69E3xF1Hk-52s2dFcioo/edit?usp=drive_web>), sporst@ on Russian Malware cleanup at Virus Bulletin (slides <https://docs.google.com/presentation/d/1CrqdAm7WKAXsMja1VHVXEVGbg1vUzvoyhC5qCrqiqsY/edit>, video, press <http://qz.com/514720/google-just-revealed-its-android-security-team-detected-and-defeated-a-steep-rise-in-mobile-banking-fraud-in-russia/>), cbrubaker@ on NoGotofail at University of Utah (slides <https://docs.google.com/a/google.com/presentation/d/12uJxPosU_dI-X4XUQZO2BwPXWl406ny-pGWN3xFC3JI/edit?usp=sharing>), smel@ spoke at Johns Hopkins (slides<https://docs.google.com/presentation/d/1dJWxs7GNUTSABYu08Yt-2eQXDaWBnTFA3DYIDGM1WDk/edit#slide=id.gca06805cf_17_22>)
7. Operational Focus on Malware in Play – Monthly reviews of top PHA installs (July <https://docs.google.com/a/google.com/document/d/1vwTMvOwL4I08GrB9dyLC7ex9fg2ydeqLEg3UBh3XuT4/edit?usp=sharing>, August <https://docs.google.com/document/d/197_ELrS8zhZhGxglF2aSaQq2P_0YBdDhkrlgDG5m_x4/edit>, September <https://docs.google.com/document/d/1lcKEIc3JySPryR2YhlNmNdgquitfQWF9qO-aIaHUCRc/edit?ts=5612e47f>) have helped drive our goal of less than 1 million installs being a PHA. (currently, the number is ~500 per million <http://go/phastats>)
8. Scale up of SafetyNet Attestation (including launch of Android Pay). See recent Program Review <https://docs.google.com/presentation/d/1SHeAt7bQX_OAoe99lwfn5IP9SSKyed7WJOWM-_B9v18/edit> for more details.
9. Greenhat <http://go/greenhat> – 2 day, google-wide summit with the best of Android Security. All the content and recordings have been stored here <https://drive.google.com/a/google.com/folderview?id=0B47yL4yVz8b3flhxSkRiemUyQ1dHRDFZblloYm9hZ3doWmJOQzFDTHAwa1RFekdRVExEVXM&usp=sharing>.
10. Last, but not least: Stinknet <http://go/stinknet>. Publicly known as Ghost Push <http://venturebeat.com/2015/09/18/cheetah-mobile-ghost-push-android-virus-infects-600k-users-a-day-with-unwanted-apps/>, (mostly) outside of Google Play we’re currently battling the largest coordinated rooting malware attack we’ve seen against Android. (We’re slowly winnning <http://go/stink>, but this will likely be a highlight again next quarter.)
Anyhow, those are just a few of the big things we’ve been up to recently.
AndCanGo project starting
Console Inc, an Android-based OS vendor, has started a new Github project for UEFI firmware for Android called AndCanGO:
AndCanGO: A project to unify the various UEFI & IA-capable fastboot and bootloaders, with its goal to deliver a custom, update-friendly Android recovery and GUI installer.
It is currently just created, an as-yet empty project. Watch for it to change in the upcoming days, along with some of their other related projects (which are not empty).
Android devices mostly insecure
Liam Tung has an article on ZDnet about Android device security (image from article):
Nearly 90 percent of Android devices are exposed to at least one critical vulnerability, because of Android handset makers’ failure to deliver patches, according to research from the UK’s University of Cambridge. Consumers, regulators, and corporate buyers face a common problem when assessing Android smartphones, in that no one knows which vendor will supply patches after Google develops fixes for Android security bugs.
http://www.zdnet.com/article/android-security-a-market-for-lemons-that-leaves-87-percent-insecure/
EFI Mixed Mode patchset for Android-IA
Christopher Price posted availability of a patchset to restore EFI Mixed Mode to the latest Android-IA release. Excerpt of announcement:
Enclosed you will find 19 patches that restore EFI Mixed Mode to the latest Android-IA release. We are still running through a BFD linker bug in KernelFlinger that is preventing activation – but it has tested well with GMIN64 and does not appear to block the kernel. Testing and review appreciated. We’d like it committed upstream because it would be very difficult without trunk access to maintain these patches going forward. While we’d like to take credit, Mark Gross and Intel UK really did an excellent job reviving this work – we’ve been incubating and testing for the past few months. This will allow Android-IA to run on the millions of BayTrail-T production tablets that depend on EFI Mixed Mode. Without these patches, Android-IA cannot run on virtually any Bay Trail tablet today, except for maybe IRDA, which isn’t available in many countries currently. These patches should no longer be necessary once Kernel 3.15 is integrated, at which point Mixed Mode will hit mainline… or at least, should hit mainline.
http://console.com.co/wp-content/uploads/mixed-mode.zip
https://lists.01.org/pipermail/android-ia/2015-October/001003.html
http://www.phoronix.com/scan.php?page=news_item&px=MTY0OTI
https://lwn.net/Articles/589193/
HTC finds monthly security Android updates unrealistic
Google recently started providing monthly updates to their Nexus devices, and some carriers are also following. As a few Android news sites are reporting, HTC is not following this monthly update model.
HTC notes monthly security updates for StageFright are “unrealistic”
I am constantly amazed at how badly carriers are w/r/t providing updates, some offer none.
Nexus status update
Tom’s Hardware has an article with an interview of a few Nexus engineers, talking about upcoming releases:
Nexus Engineers Reveal More Nexus 5X, Nexus 6P Details
by Lucian Armasu
Four members of the Google Nexus team, including Hiroshi Lockheimer, David Burke, Krishna Kumar and Sandeep Waraich, took the time to answer questions from Nexus 5X and Nexus 6P fans about the two new phones. Here’s a summary of the most important details. […]
http://www.tomshardware.com/news/nexus-5x-nexus-6p-ama,30208.html#xtor=RSS-999
Android Marshmallow shows security patch level
Android Police has an article on Android Marshmallow, and how the UI now can show you the security patch level.
Unrelated to the above Marshmallow news, but there is also this security tool for Android:
And if you have an Intel-based Android device, you may also be able to boot a Linux live-boot distros, like LUV-live, and run CHIPSEC, for Intel-specific firmware security tests. (I don’t have an Intel Android-IA-based device to verify if this works, speak up if you can confirm it does or does not work.)
Android SafetyNet and Device Verification
A few Android news sites have a story about why Google Pay won’t work on rooted Android devices, and how Jason Clinton of Google posted a message on the XDA forum with more details on why this happens. Excerpt of Jason’s post:
While the platform can and should continue to thrive as a developer-friendly environment, there are a handful of applications (that are not part of the platform) where we have to ensure that the security model of Android is intact. That “ensuring” is done by Android Pay and even third-party applications through the SafetyNet API. As you all might imagine, when payment credentials and–by proxy–real money are involved, security people like me get extra nervous. I and my counterparts in the payments industry took a long, hard look at how to make sure that Android Pay is running on a device that has a well documented set of API’s and a well understood security model. We concluded that the only way to do this for Android Pay was to ensure that the Android device passes the compatibility test suite–which includes checks for the security model. The earlier Google Wallet tap-and-pay service was structured differently and gave Wallet the ability to independently evaluate the risk of every transaction before payment authorization. In contrast, in Android Pay, we work with payment networks and banks to tokenize your actual card information and only pass this token info to the merchant. The merchant then clears these transactions like traditional card purchases.
A bit more on Android SafetyNet API, from their web site:
“SafetyNet provides services for analyzing the configuration of a particular device, to make sure that apps function properly on a particular device and that users have a great experience. The service provides an API your app can use to analyze the device where it is installed. The API uses software and hardware information on the device where your app is installed to create a profile of that device. The service then attempts to match it to a list of device models that have passed Android compatibility testing. This check can help you decide if the device is configured in a way that is consistent with the Android platform specifications and has the capabilities to run your app.”
https://source.android.com/compatibility/cts/index.html
https://developer.android.com/training/safetynet/index.html
Google security engineer explains why Android Pay doesn’t work on rooted devices
Android Bionic gets setjmp hardening
As found on Twitter feed of CopperheadSec, Bionic now has glibc-style setjmp hardening for x86, x86_64, ARM and AArch64:
Embedded Programming with Android’s U-Boot chapter
From about a week ago on the Pearson InformIT web site, Roger Ye published an article on using U-Boot with embedded Android, “Embedded Programming with Android: Using U-Boot to Boot the Goldfish Kernel“. The article mentions that this is a chapter from Roger’s book, “Embedded Programming with Android“, which is news to me. It appears the book came out in April.
In this chapter from Embedded Programming with Android: Bringing Up an Android System from Scratch, Roger Ye shows you how to build a goldfish Linux kernel and then how to boot Android from NOR flash and NAND flash using U-Boot and this kernel.
Once we have U-Boot ready for the goldfish platform, we can use it to boot the Linux kernel in the Android emulator. Ideally, the boot process starts from nonvolatile memory (such as flash memory). Many kind of storage devices can be used in an embedded system, though NOR and NAND flash devices are the most popular options. In this chapter, we will build a goldfish Linux kernel first. We then explore how to boot Android from NOR flash and NAND flash using U-Boot and this kernel. […]
http://www.informit.com/articles/article.aspx?p=2431417
http://www.informit.com/store/embedded-programming-with-android-bringing-up-an-android-9780134030005
Ext4 encryption
QuarksLab has a new blog on encryption support of Linux’s Ext4 file system:
Excerpting the beginning of the post:
Linux 4.1 has arrived with a new feature for its popular ext4 filesystem: filesystem-level encryption! This feature appears to have been implemented by Google since they plan to use it for future versions of Android and Chrome OS. Android filesystem encryption currently relies on dm-crypt. Google’s motivations for pushing encryption to ext4 seem:
* To avoid using a stacked filesystem design (for better performance?).
* To encrypt data with integrity.
* To allow multiple users to encrypt their files with different keys on the same filesystem.
More Information:
http://blog.quarkslab.com/a-glimpse-of-ext4-filesystem-level-encryption.html
Also see this article from April:
https://lwn.net/Articles/639427/
UPDATE: See-also this recent talk from Google at the 2015 Linux Security Summit:
Encrypting Android Devices
Paul Lawrence and Mike Halcrow, Google
EFIDroid
I just learned about EFIDroid, “a multiboot solution for mobile devices”. It is not new, EFIDroid was announced Feburary 2014 on the Xiaomi.eu mailing lists:
“Opensource (multiboot) Bootloader: Efidroid (formerly Grub4android):
This is the successor of GRUB4Android – a project to bring multiboot to Android. Even though most people hate UEFI on computers(users because of secureboot and devs because it doesn’t change many problems of BIOS afaik), Intel’s implementation (“EDKII”) actually is quite good and perfectly fits our needs. Also, it still allows you to boot GRUB – just in case you wanna do that.”
It is a Google+-based community, with over a hundred members. There’s been a lot of recent Github activity for the project, including an interesting Linux kernel module.
https://github.com/efidroid
https://plus.google.com/communities/114053643671219382368
http://xiaomi.eu/community/threads/dev-opensource-multiboot-bootloader-efidroid-formerly-grub4android.23615/
https://plus.google.com/u/0/MichaelZimmermann
http://mzimmermann.info/
August Android Security Update for Nexus
Ryan pointed out that Google just started announcing security updates for Nexus:
Android Security Updates: Nexus Security Bulletin (August 2015)
On August 5, 2015, we released an over-the-air (OTA) update for Nexus 4/5/6/7/9/10 and Nexus Player devices that includes several security fixes. The patches for these fixes have also been released to the Android Open Source Project (AOSP) source repository. These issues are categorized and provided in decreasing order of severity. We have also provided an assessment of each issue, given the information we have at the time of the publication of this bulletin.
Here are brief details on the 6 CVEs listed in this bulletin, see full announcement for full details:
CVE-2015-1538: Integer overflows during MP4 atom processing
ID: ANDROID-20139950
Versions: 5.1 and below
Severity: Critical
Partners notified: May 4, 2015 (Bulletin 2015-07)
Fixed in Nexus Build: 5.1.1 (LMY48I)
Credit: Joshua Drake
CVE-2015-1539: An integer underflow in ESDS processing
ID: ANDROID-20139950
Versions: 5.1 and below
Severity: Critical
Partners notified: May 4, 2015 (Bulletin 2015-07)
Fixed in Nexus Build: 5.1.1 (LMY48I)
Credit: Joshua Drake
CVE-2015-3824: Integer overflow in libstagefright when parsing the MPEG4 tx3g atom
ID: ANDROID-20923261
Versions: Android 5.1 and below
Severity: Critical
Partners notified: June 25th, 2015 (Bulletin 2015-09)
Fixed in Nexus Build: 5.1.1 (LMY48I)
Credit: Joshua Drake
CVE-2015-3827: Integer underflow in libstagefright when processing MPEG4 covr atoms
ID: ANDROID-20923261
Versions: Android 5.1 and below
Severity: Critical
Partners notified: June 25th, 2015 (Bulletin 2015-09)
Fixed in Nexus Build: 5.1.1 (LMY48I)
Credit: Joshua Drake
CVE-2015-3828: Integer underflow in libstagefright if size is below 6 while processing 3GPP metadata
ID: ANDROID-20923261
Versions: Android 5.0 and above
Severity: Critical
Partners notified: June 25th, 2015 (Bulletin 2015-09)
Fixed in Nexus Build: 5.1.1 (LMY48I)
Credit: Joshua Drake
CVE-2015-3829: Integer overflow in libstagefright processing MPEG4 covr atoms when chunk_data_size is SIZE_MAX
ID: ANDROID-20923261
Versions: Android 5.1 and below
Severity: Critical
Partners notified: June 25th, 2015 (Bulletin 2015-09)
Fixed in Nexus Build: 5.1.1 (LMY48I)
Credit: not listed
Full announcement:
https://groups.google.com/forum/#!topic/android-security-updates/Ugvu3fi6RQM
https://source.android.com/devices/tech/security/overview/updates-resources.html
Preparing for Android firmware updates
Kris Carlon of AndroidPIT has written an article for end-users to help them prepare for a system update for their Android phones. Not bad advice to give to your non-technical friends:
https://www.androidpit.com/what-to-do-before-an-android-update
On UEFI-based systems, like Intel-based Android-IA systems, I’d add:
- save your ROM with before the update, and again after the update, booting LUV-live and using CHIPSEC.
For ARM-based systems, I wish that ARM had both AArch32 and AArch64 ports of CHIPSEC. Linaro may be porting CHIPSEC to AArch64 as part of LUV. But Linaro seems more focused on AArch64 these days, so AArch32 systems may not have security tools. For x86, there’re extensive bibliographies by LegbaCore and other security researchers on x86 BIOS/UEFI vulnerabilities, but I’ve hard a hard time finding a similar list of ARM vulnerabilities. I presume that’s because most are hidden behind iOS/Android-centric vulnerability, and other ARM-based embedded devices, with the various ARM vendor variations. If there was security data for ARM users to watch for, then the community could help ARM/Linaro with the CHIPSEC ports.
AMI announces AMIDuOS 2.0
Today AMI announced AMIDuOS 2.0, with support for Windows 7-10 along with Android 5.0.1 (Lollipop). AMIDuOS lets you run both OSes at the same time, using hardware acceleration and emulation. AMIDuOS 1.x supports Android 4.3 (Jellybean), and is still available for $10, free upgrade to 2.0 if you bought 1.x before August 7th. AMIDuOS is a closed-source OS.
“People should be able to run their Android apps on any device they wish,” explained Subramonian Shankar, AMI founder and President. “We created AMIDuOS to make it easy for anyone to get the full Android experience on their Windows machines. Now, even the most recent Android apps developed for Android 5.0.1 will run smoothly and with full compatibility on the Windows platform.”
AMI has utilized its decades of expertise to build hardware acceleration support into the app and support direct hardware access whenever possible. Emulation is only used when needed – otherwise code runs natively. This, plus 3D acceleration support, means incredible performance, so games and video-intensive apps run smoothly and quickly. Since AMIDuOS can access native PC hardware and drivers, any apps installed in the Android environment can take advantage of the touchscreen, sensors, peripherals, GPS, camera and more – to deliver a fully immersive Android experience. AMI has tested AMIDuOS with over 4,000 apps and is continually releasing updates to improve its compatibility.
Some of the requirements include: x86 processor, 32/64-bit version of Windows 7/8/8.1/10, OpenGL 3.0 and above, and Hardware Virtualization Technology enabled in the system’s BIOS.
https://www.facebook.com/amiduos
http://ami.com/news/press-releases/?PressReleaseID=327&/American%20Megatrends%20Unwraps%20Lollipop%20%E2%80%93%20Run%20Android%205.0.1%20Apps%20on%20Windows%20PCs%20without%20Compromise/
DFRWS Android firmware research available
Earlier I pointed out DFRWS2015 conference:
Well, presentations of most are online now:
http://www.dfrws.org/2015/program.shtml
Amongst many interesting forensic presentations, one firmware-centric one that caught my eye was:
“New acquisition method based on firmware update protocols for Android smartphones”
Seung Jei Yang, Jung Ho Choi, Ki Bom Kim and Tae Joo Chang
Android remains the dominant OS in the smartphone market even though the iOS share of the market increased during the iPhone 6 release period. As various types of Android smartphones are being launched in the market, forensic studies are being conducted to test data acquisition and analysis. However, since the application of new Android security technologies, it has become more difficult to acquire data using existing forensic methods. In order to address this problem, we propose a new acquisition method based on analyzing the firmware update protocols of Android smartphones. A physical acquisition of Android smartphones can be achieved using the flash memory read command by reverse engineering the firmware update protocol in the bootloader. Our experimental results demonstrate that the proposed method is superior to existing forensic methods in terms of the integrity guarantee, acquisition speed, and physical dump with screen-locked smart-phones (USB debugging disabled).
Click to access DFRWS2015-8.pdf
Firmware Security 
You must be logged in to post a comment.