• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

Unlocking the Amazon G4 Play Bootloader

Search This thread

A.Fitz

Member
Oct 7, 2016
41
9
Chicago, IL
Hi everyone. While I haven't made huge progress on unlocking the Amazon G Play's bootloader, I do have a few leads.

First, there's Initroot. Initroot is a way to get root access on Moto phones that have locked bootloaders. In their GitHub repository, a community member confirmed this exploit to work on his G4 Play that has a locked bootloader. I'm still trying to figure out how to patch the init. I'm not good with IDA, so it's gonna be hard. I'd love some help. While yeah, root is awesome, it's not as awesome as unlocking your bootloader. That's where the next exploit below kicks in.

There's a Amazon Exclusive Blu R1 bootloader exploit that someone here on XDA made. It uses the dirtycow exploit to obtain root then overwrite. For a lot of us, dirtycow won't work because of security patches. But initroot will!

So, using knowledge from another XDA thread, we know that the third line of our get_unlock_data is a hash validated by Motorola to allow us to unlock our bootloader. Combining the initroot and the Blu R1 unlock exploit could allow us to unlock our device.

We need to first obtain root using Initroot, to do this we need to patch initramfs. After we obtain root, we need to replace either the frp or cid partition, sounds like cid, with another patched version. This is where community help is needed! I know y'all are smart, let's do this!
 
  • Like
Reactions: wrusry

gogozombiii

Member
Jan 13, 2017
18
4
Carthage
So far what I've got is a SCRATCH_ADDR of 0x80000000 and padding 0x01000000, ramdisk size 1010982.

Your fastboot command would be:
Code:
fastboot oem config fsg-id "a initrd=0x81000000, 10982"

I've tested it and it does survive reboot, no eternal bootloop with these values.

Here is the full information I got from the boot.img
Code:
kernel=kernel
ramdisk=ramdisk
dt=dt.img
page_size=2048
kernel_size=7220728
ramdisk_size=1010982
dtb_size=6492160
base_addr=0x80000000
kernel_offset=0x00008000
ramdisk_offset=0x01000000
tags_offset=0x00000100
cmd_line='console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.hardware=qcom msm_rtb.filter=0x3F ehci-hcd.park=3 vmalloc=400M androidboot.bootdevice=7824900.sdhci movablecore=160M'
board=""
format=gzip

Now whoever wants to patch init can take over because I'm tired lol
 
  • Like
Reactions: Poebat

ledothis

Senior Member
Nov 3, 2016
68
80
Seattle
Here are some notes I have for patching the init binary:
  1. I took the Athene stock rom from the motorolla website and extracted the init binary.
  2. I have taken the Athene image from the initroot github extracted the init binary.

Comparing the two binaries the only difference is highlighted in red below, stock on the left and the patched init on the right.
diff
lSZrU7j.png


I am guessing that changing 0xf0102001 to 0xf0102000 is referencing the second line in the difference that has 0xf0102000.

Searching for the same listing of instructions in the harpia (Moto G4 play) init I found the following:
listing
WUGpj6a.png


Assuming changing 0xf00f2001 to 0xf0102000 (2nd line) in a hex editor would be enough.
I don't know enough about assembly to truly know what going on here, maybe someone on the forum does.
 
Last edited:
  • Like
Reactions: A.Fitz

gogozombiii

Member
Jan 13, 2017
18
4
Carthage
I'm down to try it if you wanna change it and send it to me. I have a couple of these phones just to play with so not too worried if I mess one up.
 

onlykhaz

Senior Member
Sep 13, 2012
61
49
So, it seems to be a light at the end of the tunnel amz version without bootloader.
Keep it up guys \o/
 

A.Fitz

Member
Oct 7, 2016
41
9
Chicago, IL
Analysed aboot to find the SCRATCH_ADDRESS as described here: https://alephsecurity.com/2017/06/07/initroot-moto/#finding-the-scratch_addr-values

I can confirm the target_get_scratch_address is 0x9000000

I will try start my phone using the vanilla/unpatched copy of initramfs to see if I can boot.

So that scratch_addr is 0x9000000 not 8x as a post above said? How about padding? And if you'd like I have the xt1607 initramfs already made to flash if you want it.
 

ledothis

Senior Member
Nov 3, 2016
68
80
Seattle
So that scratch_addr is 0x9000000 not 8x as a post above said? How about padding? And if you'd like I have the xt1607 initramfs already made to flash if you want it.

I proved that it is possible to boot as described in the article by flashing a stock initrd.img (plus padding).
Code:
fastboot oem config fsg-id "c initrd=0x92000000,1010926"
fastboot flash aleph2 ./initroot-orig-harpia.cpio.gz
fastboot continue

I am failing when trying to boot off a custom initrd.img where I just unpack and repack it (using the steps on the github).
However when I compare my repacked initrd vs the original they are different which shouldn't be the case. I plan on figuring this issue next.

Also for the padding, I do not think that is explained well in the article. We can use any padding that we want, it is a precaution just to offset the image from the scratch address such that it doesn't get clobbered when the bootloader uses the scratch address for storing other data.

I have tried both 32MB (0x2000000) and 64MB (0x4000000) both of these work.

If you're on linux you can create the pad files using the following command, for e.g. 32MB
Code:
dd if=/dev/zero of=pad32  bs=1M  count=32
Then for my stock image I have:
Code:
cp pad32 init-orig-harpia.cpio.gz
cat initrd.img >>init-orig-harpia.cpio.gz
Then I would use 0x92000000 instead of 0x90000000 as the initrd offset.
 

kenoni

Member
Nov 11, 2014
9
2
XT1622 Amazon version

The same thing with the XT1622 Amazon version.
- Tried booting with the original initroot image everything loads fine.
- When trying with the adjusted image I get boot loops.
 
Last edited:

ledothis

Senior Member
Nov 3, 2016
68
80
Seattle
The patch for init is wrong..
The exampe had 0xf0102001 changed to 0xf0102000. Assuming the patch is just dropping the last bit.
For my harpia initrd image I have the data 0xf00f2001 so I changed that to 0xf00f2000 and this worked.

Running
Code:
adb shell getenforce
Permissive

Note: I was super wrong about the packing and unpacking being the issue.
 
  • Like
Reactions: tttony

tttony

Senior Member
Jul 20, 2012
56
7
The patch for init is wrong..
The exampe had 0xf0102001 changed to 0xf0102000. Assuming the patch is just dropping the last bit.
For my harpia initrd image I have the data 0xf00f2001 so I changed that to 0xf00f2000 and this worked.

Running
Code:
adb shell getenforce
Permissive

Note: I was super wrong about the packing and unpacking being the issue.

So, good news for XT1607 owners?
 

ledothis

Senior Member
Nov 3, 2016
68
80
Seattle
Im stuck now as I have never setup su before.

I copied su (version from android emulator) to /sbin/su in the image, but when i run:
Code:
$ adb shell su
su: setgid failed: Operation not permitted

Assuming thats why sepolicy and adb needs to be patched.
I tried using my sepolicy from the emulator and it still failed.
Maybe I should copy the adb from the github or the emulator.
 

gogozombiii

Member
Jan 13, 2017
18
4
Carthage
I mean, he could be right; I never claimed to know what the hell I was doing ;) I just like to tweak out on phones, definitely nowhere near a professional.
 

ledothis

Senior Member
Nov 3, 2016
68
80
Seattle
Root works now.
Code:
$ adb shell
[email protected]:/ # id
uid=0(root) gid=0(root) groups=0(root),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats) context=u:r:shell:s0

  1. /init patched as described above
  2. /sepolicy taken from the athene-m image on the github
  3. /xbin/su taken from the android arm emulator
  4. /sbin/adbd taken from the athene-m image on github
  5. /init.mmi.usb.rc changed "echo 1" to "echo 0" in two places
 
Last edited:

wrenhal

Senior Member
Sep 19, 2007
718
106
Root works now.
Code:
$ adb shell
[email protected]:/ # id
uid=0(root) gid=0(root) groups=0(root),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats) context=u:r:shell:s0

  1. /init patched as described above
  2. /sepolicy taken from the athene-m image on the github
  3. /xbin/su taken from the android arm emulator
  4. /sbin/adbd taken from the athene-m image on github
  5. /init.mmi.usb.rc changed "echo 1" to "echo 0" in two places
Woohoo. Is this permanent? Can it be used then to permanently enable the tethering? Does this wipe anything on the phone?
I wonder what will happen if we finally get nougat.

Sent from my Moto G Play using Tapatalk
 

ledothis

Senior Member
Nov 3, 2016
68
80
Seattle
Technically yes. You would have to flash the fake initrdimg before booting each time though. Furthermore, you still can't change much of the device because the boot sequence is still secure.

Looking at the original suggestion for unlocking the bootloader it is unfortunately for a BLU device not a motorolla device (even though it is Amazon controlled).
I originally though that was Motorola variant. The bootloader unlock for the BLU device won't work for a motorolla device.

We just need to hope someone figures out a way to hack the bootloader.
I remember reading way back that there are some guys on this forum that know how to get Motorlla bootloader unlock codes, but I think they charge money. (Seems dodgy).

With root access I have pulled the bootloader image, so I'll dig around for fun but doubt I will find anything.
 

wrenhal

Senior Member
Sep 19, 2007
718
106
Technically yes. You would have to flash the fake initrdimg before booting each time though. Furthermore, you still can't change much of the device because the boot sequence is still secure.

Looking at the original suggestion for unlocking the bootloader it is unfortunately for a BLU device not a motorolla device (even though it is Amazon controlled).
I originally though that was Motorola variant. The bootloader unlock for the BLU device won't work for a motorolla device.

We just need to hope someone figures out a way to hack the bootloader.
I remember reading way back that there are some guys on this forum that know how to get Motorlla bootloader unlock codes, but I think they charge money. (Seems dodgy).

With root access I have pulled the bootloader image, so I'll dig around for fun but doubt I will find anything.
So would a change to the build.prop survive a reboot?

Sent from my Moto G Play using Tapatalk
 

Top Liked Posts

  • There are no posts matching your filters.
  • 9
    Root works now.
    Code:
    $ adb shell
    [email protected]:/ # id
    uid=0(root) gid=0(root) groups=0(root),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats) context=u:r:shell:s0

    1. /init patched as described above
    2. /sepolicy taken from the athene-m image on the github
    3. /xbin/su taken from the android arm emulator
    4. /sbin/adbd taken from the athene-m image on github
    5. /init.mmi.usb.rc changed "echo 1" to "echo 0" in two places
    3
    Technically yes. You would have to flash the fake initrdimg before booting each time though. Furthermore, you still can't change much of the device because the boot sequence is still secure.

    Looking at the original suggestion for unlocking the bootloader it is unfortunately for a BLU device not a motorolla device (even though it is Amazon controlled).
    I originally though that was Motorola variant. The bootloader unlock for the BLU device won't work for a motorolla device.

    We just need to hope someone figures out a way to hack the bootloader.
    I remember reading way back that there are some guys on this forum that know how to get Motorlla bootloader unlock codes, but I think they charge money. (Seems dodgy).

    With root access I have pulled the bootloader image, so I'll dig around for fun but doubt I will find anything.
    2
    This looks very promising. My device is still at 6.0.1 so I will attempt the same process at that release version.
    2
    I was trying to locate a download link for the xt1609 firmware with the May update and couldn't find it. Thanks for sharing the link. :good:

    @ledothis, Here is the bootloader.img from the latest xt1609 stock vzw firmware with the May security update, which is the firmware I am currently running on my xt1609.
    Thanks to @codomir for providing the link for the firmware download for me to extract the bootloader.img from.

    No problem, I didn't upload it I just found the link here on the forums. Do not install the June update if you get it, it patches the exploit. According to this post on twitter: https://twitter.com/utoprime/status/884095279301091329

    In my tweet I was referring to MPIS24.241-2.35-1-17 as the "June security update" though above you refer to it as the "May update". I had not actually taken the update only pulled it once it tried to update my phone... but I had assumed it was the June Security Patch based on various blog posts found from Googling which all mentioned it was using the June update.. assumed it was using June security patch.

    For those that have flashed MPIS24.241-2.35-1-17, is it using the May or June security patch? If it is indeed the June patch then initroot should be well patched unless someone goofed.. but initroot was first mentioned in the May 2017 security bulletin: https://source.android.com/security/bulletin/2017-05-01#eop-in-motorola-bootloader

    If MPIS24.241-2.35-1-17 is actually using the May 2017 Security Patch then it would be interesting to see if initroot is patched and may come down to which patch level it's using, 2017-05-01 or 2017-05-05. I believe initroot security patch was part of the 2017-05-05 patch level so if MPIS24.241-2.35-1-17 is using patch level 2017-05-01 then initroot could actually still be open for those who took the latest update.

    To confirm if initroot is patched (besides looking at the security patch level) one could try:
    fastboot oem config fsg-id "a initrd=0x33333333,1024"
    This would cause a bootloop if unpatched (bootloop = good for those who want this exploit)
    To get out of bootloop: fastboot oem config fsg-id "a"

    So yeah, I suppose it's possible my tweet could be incorrect depending on the actual security patch level which I had assumed was June 2017 not May. Not going to flash it to test so I will rely on feedback here to confirm. :good:

    Also @classic757 the nice thing about initroot is that, unless you go out of your way, initroot is temporary so once you reboot the phone is no longer using that modded initramfs. So if loss of ADB or bootloop were to happen you can go back to unmodded android by just rebooting into fastboot and using the command: fastboot oem config fsg-id "a"
    This will undo the modification that was made to boot the initramfs at a specific location.

    Remember, the first command when flashing initroot initramfs is:
    fastboot oem config fsg-id "a initrd=<SCRATCH_ADDR+PADDING>,<initroot.cpio.gz size-PADDING>"
    so due to that command the phone will always require you to manually load the modded initramfs before boot if you want to avoid bootloops.. until you use the fastboot oem config fsg-id "a" command to tell the phone to boot normally.
    2
    i believe it has, but it is still a good read

    ---------- Post added at 07:15 PM ---------- Previous post was at 07:00 PM ----------



    do me a favor and pull the FRP and CID images from your device please

    Here are the FRP CID images