Azimuth Security: Exploiting Samsung Galaxy S4 Secure Boot <body onload='MM_preloadImages(&apos;http://www.azimuthsecurity.com/images/a_02.gif&apos;,&apos;http://www.azimuthsecurity.com/images/r_02.gif&apos;,&apos;http://www.azimuthsecurity.com/images/t_02.gif&apos;,&apos;http://www.azimuthsecurity.com/images/s_02.gif&apos;)'><script type="text/javascript"> function setAttributeOnload(object, attribute, val) { if(window.addEventListener) { window.addEventListener('load', function(){ object[attribute] = val; }, false); } else { window.attachEvent('onload', function(){ object[attribute] = val; }); } } </script> <div id="navbar-iframe-container"></div> <script type="text/javascript" src="https://apis.google.com/js/platform.js"></script> <script type="text/javascript"> gapi.load("gapi.iframes:gapi.iframes.style.bubble", function() { if (gapi.iframes && gapi.iframes.getContext) { gapi.iframes.getContext().openChild({ url: 'https://www.blogger.com/navbar.g?targetBlogID\x3d509652393303233687\x26blogName\x3dAzimuth+Security\x26publishMode\x3dPUBLISH_MODE_HOSTED\x26navbarType\x3dBLUE\x26layoutType\x3dCLASSIC\x26searchRoot\x3dhttp://blog.azimuthsecurity.com/search\x26blogLocale\x3den\x26v\x3d2\x26homepageUrl\x3dhttp://blog.azimuthsecurity.com/\x26vt\x3d1038547295672672920', where: document.getElementById("navbar-iframe-container"), id: "navbar-iframe" }); } }); </script>
azimuth security services training resources about BLOG
project zeus
"You will not be informed of the meaning of Project Zeus until the time is right for you to know the meaning of Project Zeus."
Archives
Current Posts
April 2010
May 2010
August 2010
September 2012
February 2013
March 2013
April 2013
May 2013
June 2013
December 2013
March 2014
January 2015
Posts
Exploiting Samsung Galaxy S4 Secure Boot
Exploiting Samsung Galaxy S4 Secure Boot
posted by Dan Rosenberg @ 5/23/2013 10:36:00 AM  

Launched in April 2013, the Samsung Galaxy S4 is expected to be one of the top-selling smartphones of the year, having sold 10 million units in its first month of sales. While the majority of released models include an unlocked bootloader, which allows users to flash custom kernels and make other modifications to the software on their own devices, AT&T and Verizon branded devices ship with a locked bootloader that prevents these types of modifications. In this post, I'll provide details on how Samsung implement this locking mechanism, and publish a vulnerability in the implementation that allows bypassing the signature checks to run custom unsigned kernels and recovery images.

Both the AT&T (SGH-I337) and Verizon (SCH-I545) models utilize the Qualcomm APQ8064T chipset. As described in my previous blog post on Motorola's bootloader, Qualcomm leverages software-programmable fuses known as QFuses to implement a trusted boot sequence. In summary, each stage of the boot process cryptographically verifies the integrity of the subsequent stage, with the trust root originating in QFuse values. After the early boot stages bootstrap various hardware components, Samsung's APPSBL ("Application Secondary Bootloader") is loaded and run. This bootloader differs between "locked" and "unlocked" variants of the Galaxy S4 in its enforcement of signature checks on the boot and recovery partitions.

A quick glance at aboot (adopting the name of the partition on which this bootloader resides) revealed that it is nearly identical to the open source lk ("Little Kernel") project, which undoubtedly saved me many hours of tedious reverse engineering. By locating cross-references to strings found in both lk and aboot, I was able to quickly identify the functions that implement signature verification and booting of the Linux kernel.

The central logic to load, verify, and boot the Linux kernel and ramdisk contained in either the boot or recovery partitions is implemented in the boot_linux_from_mmc() function. First, the function determines whether it is booting the main boot partition, containing the Linux kernel and ramdisk used by the Android OS, or the recovery partition, which contains the kernel and ramdisk used by the Android recovery subsystem. Then, the first page of the appropriate partition is read into physical memory from the eMMC flash storage:

  if (!boot_into_recovery) {
    index = partition_get_index("boot");
    ptn = partition_get_offset(index);
    if (ptn == 0) {
      dprintf(CRITICAL, "ERROR: No boot partition found\n");
      return -1;
    }
  }
  else {
    index = partition_get_index("recovery");
    ptn = partition_get_offset(index);
    if (ptn == 0) {
      dprintf(CRITICAL, "ERROR: No recovery partition found\n");
      return -1;
    }
  }

  if (mmc_read(ptn + offset, (unsigned int *) buf, page_size)) {
    dprintf(CRITICAL, "ERROR: Cannot read boot image header\n");
    return -1;
  }

This code is straight out of lk's implementation. Next, after performing some sanity-checking of the boot image, which contains a custom header format, the function loads the kernel and ramdisk into memory at the addresses requested in the boot image header:

  hdr = (struct boot_img_hdr *)buf;

  image_addr = target_get_scratch_address();
  kernel_actual = ROUND_TO_PAGE(hdr->kernel_size, page_mask);
  ramdisk_actual = ROUND_TO_PAGE(hdr->ramdisk_size, page_mask) + 0x200;
  imagesize_actual = (page_size + kernel_actual + ramdisk_actual);
 
  memcpy(image_addr, hdr, page_size);
 
  offset = page_size;

  /* Load kernel */
  if (mmc_read(ptn + offset, (void *)hdr->kernel_addr, kernel_actual)) {
    dprintf(CRITICAL, "ERROR: Cannot read kernel image\n");
    return -1;
  }

  memcpy(image_addr + offset, hdr->kernel_addr, kernel_actual);

  offset += kernel_actual;

  /* Load ramdisk */
  if (mmc_read(ptn + offset, (void *)hdr->ramdisk_addr, ramdisk_actual)) {
    dprintf(CRITICAL, "ERROR: Cannot read ramdisk image\n");
    return -1;
  }

  memcpy(image_addr + offset, hdr->ramdisk_addr, ramdisk_actual);

  offset += ramdisk_actual;

This is still essentially identical to lk's implementation, with the addition of code to copy the individual pieces of the boot image to the image_addr location. Finally, the function performs signature verification of the entire image. If signature verification succeeds, the kernel is booted; otherwise, a tampering warning is displayed and the device fails to boot:

  if (check_sig(boot_into_recovery))
  {
    if (!is_engineering_device())
    {
      dprintf("kernel secure check fail.\n");
      print_console("SECURE FAIL: KERNEL");
      while (1)
      {
        /* Display tampered screen and halt */
        ...
      }
    }
  }
 
  /* Boot the Linux kernel */
  ...

The is_engineering_device() function simply returns the value of a global variable that is set at an earlier stage in the boot process based on whether or not the chipset ID (an unchangeable hardware value) of the device indicates it is an engineering or production device.

Examining the check_sig() function in more detail revealed that aboot uses the open-source mincrypt implementation of RSA for signature validation. The bootloader uses an RSA-2048 public key contained in aboot to decrypt a signature contained in the boot image itself, and compares the resulting plaintext against the SHA1 hash of the boot image. Since any modifications to the boot image would result in a different SHA1 hash, it is not possible to generate a valid signed boot image without breaking RSA-2048, generating a specific SHA1 collision, or obtaining Samsung's private signing key.

The astute reader will have already noticed the design flaw present in the above program logic. Notice the order in which the steps are performed: first, aboot loads the kernel and ramdisk into memory at the addresses requested by the boot image header, and then signature validation is performed after this loading is complete. Because the boot image header is read straight from eMMC flash prior to any signature validation, it contains essentially untrusted data. As a result, it's possible to flash a maliciously crafted boot image whose header values cause aboot to read the kernel or ramdisk into physical memory directly on top of aboot itself!

Exploitation of this flaw proved to be fairly straightforward. I prepare a specially crafted boot image that specifies a ramdisk load address equal to the address of the check_sig() function in aboot physical memory. In my malicious boot image, I place shellcode where the ramdisk is expected to reside. I flash this image by leveraging root access in the Android operating system to write to the boot block device. When aboot reads the supposed ramdisk from eMMC flash, it actually overwrites the check_sig() function with my shellcode, and then invokes it. The shellcode simply patches up the boot image header to contain sane values, copies the actual kernel and ramdisk into appropriate locations in memory, and returns zero, indicating the signature verification succeeded. At this point, aboot continues the boot process and finally boots my unsigned kernel and ramdisk. Victory!

Thanks to ralekdev for the helpful exchange of ideas and suggestions.

56 comments:

At May 23, 2013 at 11:16 AM , Anonymous Anonymous said...

Thank you very much for this. I won't be getting an SGS4, but in general I find it exponentially more valuable to have understanding and an exploit, than simply believing in magic.

At May 23, 2013 at 11:41 AM , Blogger Michael Berger said...

Thank D.R. for letting us know about the technical details. Awesome find with the Little Kernel OSP! Excellent security research.

At May 23, 2013 at 12:09 PM , Anonymous Anonymous said...

Thank you sir, you rock.
Well written and executed.

At May 23, 2013 at 12:54 PM , Anonymous Anonymous said...

That's a great hack. Thank you for this.

At May 23, 2013 at 1:09 PM , Anonymous Anonymous said...

It is ridiculous how good you are at this stuff.

Thanks from the entire SGS4 community!

At May 23, 2013 at 2:11 PM , Anonymous mdeslaur said...

Dan, as usual, you rock ;)

At May 23, 2013 at 3:42 PM , Blogger Unknown said...

Hopefully you are well compensated for your intelligence :)

At May 23, 2013 at 4:49 PM , Blogger MR. Green said...

Very nice! This is a great expoit and pretty easy one too :) good job on noticing the lk similarities.

At May 23, 2013 at 6:21 PM , Blogger RPFerg said...

does this root the phone?

At May 23, 2013 at 9:42 PM , Anonymous Anonymous said...

Good post . Thanks a lot.

At May 23, 2013 at 9:52 PM , Anonymous Anonymous said...

hey could you take a crack at the pantech bootloader for the flex

At May 23, 2013 at 11:10 PM , Blogger Anonymous said...

I will never be this smart.

At May 24, 2013 at 12:00 PM , Anonymous Anonymous said...

the correct design would likely not solely involve verifying the signature on eMMC but also when copying into RAM calculating a SHA2 and comparing with the verified image. This will be to mitigate a TOCTOU style attack.

At May 24, 2013 at 7:58 PM , Blogger Unknown said...

Could Samsung have signature-checked the boot header to make sure it doesn't load ontop of aboot, not overwriting checkSig()?

At May 25, 2013 at 2:32 PM , Anonymous Unlock iPhone 5 said...

Can you do some hack to unlock iPhone 5? Thank you!

At May 25, 2013 at 10:17 PM , Blogger Unknown said...

Nice explanation,
Cheers.

At May 26, 2013 at 12:26 PM , Anonymous Anonymous said...

So we have learned today that it is otherwise POINTLESS for carriers and manufacturers to 'lock' their bootloaders, or roms, etc.

the lesson to be learned here: if you are designing something make it possible to 'lock' your ROM and bootloaders with cryptographic keys of extreme and lengthy strength. Otherwise, just GIVE USERS THE DARN KEYS FROM THE START!

At May 26, 2013 at 5:28 PM , Anonymous Anonymous said...

Can you do the same thing to a iPad mini?

At May 27, 2013 at 6:31 AM , Anonymous Sam said...

YES please. Thank you! Was so tired of touchwiz. NOW I can see why you waited until Verizons phone was out.

At May 27, 2013 at 10:34 AM , Blogger heroe13 said...

Would you elaborate more on how to Root SGs4? Thanks a million.

At June 3, 2013 at 1:50 PM , Anonymous Anonymous said...

So I'm curious, why couldn't this exploit be use to replace the aboot image with an image that is patched to always see the qfuse unblown? thus effectively unlocking the bootloader without needing loki to flash kernels and recoveries.

At June 4, 2013 at 10:58 AM , Blogger Dan Rosenberg said...

Anonymous:
I'm not sure what QFuse you're talking about, since whether a Galaxy S4's aboot is "unlocked" or not is not dependent on a QFuse.

You can't replace aboot itself because signatures are validated at each stage of the boot chain (pbl -> sbl1 -> sbl2 -> sbl3 -> aboot). Writing a tampered aboot would cause sbl3 to fail signature validation.

At June 5, 2013 at 1:13 AM , Anonymous Anonymous said...

Dan I meant the QFuse for loading kernels or recoveries not a QFuse for aboot. But the second part of your reply answered my question. I thought maybe aboot would check the signature when loading a new aboot I didn't know it checked it every time you boot.

At June 6, 2013 at 2:05 AM , Anonymous iphone & ipad & ipod repairs in toronto said...

I like this blog and the statements which you have used in this blog.I found so many things in this page so i saved it in my favourite.

At June 11, 2013 at 11:19 PM , Anonymous accessoire-galaxy-note said...

Thanks for the info :)

At August 16, 2013 at 2:45 PM , Blogger Garron Shepherd said...

Any chance you'll take a crack at any of their new firmwares?

At August 26, 2013 at 6:55 AM , Blogger Park said...

I have brand new galaxy, "galaxy s4 lte-a(E330S)".
but your program can not find check function in its aboot.img
Is there any way to crack this?

At September 13, 2013 at 7:38 PM , Blogger Armus said...

I'd like to know what changed in the vzw update that killed this.

At September 24, 2013 at 8:07 PM , Blogger stretched2thin said...

Any chance you can apply your talents to the LG Optimus L9. All dev attempts have failed.

At September 28, 2013 at 6:58 PM , Anonymous Roanne Holmes said...

Very informative post about Exploiting Samsung Galaxy S4 Secure Boot, Galaxy S4 users will once again be able to move apps to their SD car, assuming the apps allow the option. There has been a Secure Boot Image added for use with Knox, but the bootloader itself still isn't locked and is still easily rooted. Thanks for sharing.

At September 30, 2013 at 11:18 PM , Blogger Unknown said...

I don't think he will. Everyone has given up on the new locks.

At October 6, 2013 at 6:22 AM , Blogger joao said...

It is possoble you turn a i9505 to i9505g?

At October 6, 2013 at 8:24 AM , Anonymous justme said...

I'd love to see this masterpiece working ;)
Please share your work at http://forum.xda-developers.com/
Great Work!

At October 6, 2013 at 9:03 AM , Blogger Unknown said...

Thank you for the light in tunnel. Now we can override this Knox Crap.

At October 9, 2013 at 11:29 AM , Blogger Byron Tsigaras, EE said...

Can you please share your ida pro aboot.mbn loader plugin?

At October 26, 2013 at 9:42 PM , Anonymous Anonymous said...

very very clever nice to have a little insight into how it works,thanks for the info

At October 27, 2013 at 3:25 PM , Anonymous Anonymous said...

I am having a "Samsung Galaxy S4-i337 AT&T" which i got as a gift from US.
Model no: SAMSUNG-SGH-I337
ANDROID VERSION: 4.2.2
BASEBAND VERSION: I337UCUAMDL
KERNAL VERSION: 3.4.0-453947
SE.INFRA@SEI-46#1
SAT APR 27 17:06:05 KST 2013
BUILD NO: JDQ39.I337UCUAMDL
IMEI : XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX (I AM HESITANT TO POST IT)
NETWORK UNLOCK CODE : 5XXXXXXX

Currently i am staying in India, When i put a new 3g BSNL sim card in it , phone asked for network unlock code, unfortunately i didn't know the importance of it and i entered some random numbers(more than 5 times) and now my network unlocking is permanently blocked by AT&T. I have contacted them they saying my phone is permanently locked and can use only with AT&T network sim card. I have tried to unlock with the method mentioned in XDA forums but unfortunately negative result. I have contacted Samsung , AT&T and BSNL service centers nobody could give a solution to my problem.
What can i do with my phone now to use it with BSNL sim card in India...
Thanks in advance.....all genius people out there help me please........
this post is last hope...

At October 28, 2013 at 10:34 AM , Anonymous Anonymous said...

I‘am using S4(SC-04E,DCM) now, my nuild is SC04EOMUAMF2, I am trying to modify the "aboot.mbn", can you help to locate the entry point by IDA, or give me some tips about mbn file?

I have already locate the strings in mbn by IDA, but I can find cross-references.

At November 1, 2013 at 6:28 PM , Blogger jake alstad said...

Nice read Dan! I am a developer interesting in researching an MF3 bootloader exploit. Any tips?

At December 12, 2013 at 12:47 AM , Blogger seesemichaelj said...

Great work Dan. I hate to be a noob (and I really should know the answer to this question..), but how did you figure out the aboot.mbn entry points? How big are the RAM/ROM sections, header, signature, and program? Are these features of ARM in general that I'm somehow missing, or is this specific to the partition? I've explored lk and still not finding a way to successfully disassemble the image. On another point, how would I know if the image is encrypted? I'm guessing I wouldn't see legible output when I run the binary through 'strings', correct?

Cheers,
Mike

At December 12, 2013 at 12:12 PM , Blogger Augusto Ferronato said...

Thanks so much Dan, but i have a problem
Well, i try to make my patch, but i have the response:

[+] loki_patch v2.1
[-] Failed to find function to patch.

Using SCH-i545 4.3

Some news about this?

At December 28, 2013 at 3:04 PM , Anonymous Anonymous said...

Dan, would you care to take a look a little at this thread on XDA and give us some feedback if the (accidental) presence of SECUREBOOT:NONE would be of any help in fully unlocking the N9005? Thank you very much!

http://forum.xda-developers.com/showthread.php?p=48579747

At January 15, 2014 at 1:53 PM , Anonymous Anonymous said...

Samsung ... naturally stupid

should be used in their next commercials ....

At January 21, 2014 at 12:47 PM , Anonymous InfoTech Review said...

Thank for sharing your idea about secure boot Galaxy S4

At February 8, 2014 at 2:29 AM , Anonymous iPhone network check said...

Galaxy S4 is the best model of all Notes and SX models

At February 28, 2014 at 9:07 AM , Blogger spiderio said...

Can you do this for LG G2 kitkat version?

At February 28, 2014 at 11:32 PM , Blogger Unknown said...

Can you please look into the Lg g flex

At June 22, 2014 at 8:03 AM , Blogger Apavayan said...

Hey will it work for galaxy grand 2

At June 30, 2014 at 7:42 AM , Blogger Zibri said...

Please do the same on Samsung Galaxy Note3 SM-N9005

At July 6, 2014 at 9:23 PM , Anonymous Anonymous said...

Please help us out with the AT&T and Verizon note 3

At July 30, 2014 at 11:24 PM , Anonymous Anonymous said...

Dan is there a place I can download this unsigned image from, that you used to make your s4 boot?

At February 17, 2015 at 9:29 AM , Blogger Unknown said...

Unlocking your AT&T HTC Aria by remote unlock code is 100% safe. These phones were built to accept unlock codes. It is the same method service providers will use to unlock their devices. Cellphone unlocking is also 100% legal and will not void warranty on your device.
http://www.attphoneunlockingshop.us/

At March 10, 2015 at 4:16 PM , Anonymous Anonymous said...

Hi Dan! How can I use this information to actually unfuse a smartphone? I'm programmer and enrolled in a Automation Engineering course, I already done some custom ROMs but I don't know the firsts steps that I need to take in order to break the secure boot. I must enter in shell (via adb), debug some kernel object (with gdb) and call this function? Or must I change the kernel source, put this function call, recompile the ROM and upload? Or I need to change the machine code of the ROM binaries to hack this? Or I need to do this via a JTAG? Or I need to pull a partition and save to a file, edit this binary file in machine code to force that call and update the partition with this edited file? I know how to do things like this, but I don't know how path I have to take.

At March 27, 2015 at 3:41 PM , Blogger Unknown said...

i have a s4 build i545vrufnk1 i have tried everything i could on line when in odin everything connects but when i try and start odin it fails any help would be great

At June 5, 2015 at 4:42 AM , Anonymous Corky said...

Do you have a tool to unloki? I am trying to edit my boot, but it's got loki and I'm new to this. I compiled loki_tool but came to realize this is for patching when a mod is already ready.

At June 7, 2015 at 11:22 AM , Anonymous Anonymous said...

Hello, Dan,
great exploit. Do you know can it be applied to NEC Terrain? Or other way around: do you know that it cannot by the different nature of the boot lock? For the moment it was a problem that even root (temporary) cannot write to partitions. I found a snaky way and CAN write, so I can flash whatever on the internal memory. I can provide I hope everything upon your request.
Now I'm waiting for my other guys to disasm and decompile the aboot binary. Everything suggests that the story is VERY similar or identical to your findings in S4, LG, etc. I hope to find the address of the important function myself.
Will you, however, be able to help by supporting (or correcting) my findings about the function address. My problem is that I'm quite new for arm, android, etc. I'm pc c/c++/assembler guy.
What might you need? aboot image I guess and the boot image (or atleast it first portion as the image itself is big, 10M), correct?
Thanks in advance, Alex alex-kas at altaray dot com

Post a Comment

Subscribe to Post Comments [Atom]

<< Home

© Copyright 2013 Azimuth Security Pty Ltd