FORUMS
Remove All Ads from XDA

Sonim XP8 (Root?)

25 posts
Thanks Meter: 2
 
By ctradio, Junior Member on 7th October 2018, 02:36 AM
Post Reply Email Thread
22nd October 2019, 12:42 AM |#21  
Junior Member
Flag Tyler tx
Thanks Meter: 0
 
More
Well good to know well I have to wait as I'm not brave enough to embark I wish I can just pay someone to root it
23rd October 2019, 05:23 AM |#22  
Member
Thanks Meter: 2
 
More
Quote:
Originally Posted by smokeyou

Untested but should not be a problem. Bootloader unlocking only allows Fastboot flashing where this method uses EDL only.

Basically the same outcome though just without the option to use TWRP or custom recovery (easily).

Thanks. I'm pretty rusty with Android, but I think long time ago the locked bootloader was checking the boot image to be signed with a key and if it was not able to verify/decrypt it, it was failing to boot. Did it change now? Or Magisk is able to sign the patched boot image with the same key as the original image?

-albertr
23rd October 2019, 05:57 AM |#23  
Member
Thanks Meter: 3
 
More
Quote:
Originally Posted by albert.r

Thanks. I'm pretty rusty with Android, but I think long time ago the locked bootloader was checking the boot image to be signed with a key and if it was not able to verify/decrypt it, it was failing to boot. Did it change now? Or Magisk is able to sign the patched boot image with the same key as the original image?

-albertr

We are on the same page here! That's why I had related notes in the disclaimer. It does not seem to care but has not been verified either and I'm not an expert here so I cant say definitively.

According to Google.. It's not clear.. Or I'm not sure if Magisk would fall under "any root of trust" or "user-settable root of trust".
https://source.android.com/security/...boot/boot-flow

We have a way to unlock the bootloader.. Just it's not really a safe way.. So I'm hoping we can avoid that.

The XP5s was tested without touching the bootloader first however that one seems to have some variations in the custom fastboot implementation.

Make sure to keep a boot image backup before testing and by all means avoid flashing the keymaster!
23rd October 2019, 04:36 PM |#24  
Member
Thanks Meter: 2
 
More
@smokeyou, maybe you can dump the image of the unlocked bootloader (is it a single eMMC partition or multiple partitions?) and share it with the forum, so we can flash it to our phones?
-albertr
23rd October 2019, 07:44 PM |#25  
Member
Thanks Meter: 2
 
More
So, someone from SonimTech has confirmed that secure boot on XP8800 do verify both kernel and initrd files during boot sequence. So it looks like without unlocking bootloader we are out of luck? The phone will either go into boot loop or will trip “QFuse” and gets bricked. I'm not sure whether Magisk touches initrd or not, so beware of consequences.

-albertr
24th October 2019, 12:06 AM |#26  
Member
Thanks Meter: 3
 
More
Quote:
Originally Posted by albert.r

So, someone from SonimTech has confirmed that secure boot on XP8800 do verify both kernel and initrd files during boot sequence. So it looks like without unlocking bootloader we are out of luck? The phone will either go into boot loop or will trip “QFuse” and gets bricked. I'm not sure whether Magisk touches initrd or not, so beware of consequences.

-albertr

I guess to start with.. Secure boot and bootloader locking are 2 different things all together. Each does play a part in the others role but that is still 2 different topics. We have never had to disable secure boot for Magisk on any device that I know of - not even on a Pixel.

I wouldn't trust much of what they say unless you asked someone from the "Sonim Technologies (Shenzhen) Ltd" office where the phones are actually designed.. The US guys are only here to sell phones & make business relationships. Part of their relationship with carriers is to ensure the phones are locked to the carriers for where contractual agreements exist. They can and will tell you anything to prevent modification as it's not in their best interest. This is universal too if you take a look at other players, for example, Google said the Verizon Pixel bootloader was not unlockable - until people here figured out that was a lie . Having a manufacturer provide "Fluff" is very common unfortunately.

At the end of the day - according to public sources - they have 1 (possibly 2) firmware engineers and I highly doubt they have spare time to reinvent the wheel. It's much easier to copy what Qualcomm gives them in the dev kit. Hence why the XP8 is branded with QC_Reference_Design in many places. They design rugged phones, not rugged firmware.

If your hesitant though then I would strongly recommend avoiding any steps in the thread here. This is still alpha essentially intended only for developers and advanced users. As far as I know, I'm the only one with a rooted XP8 still and my results may not apply the same in your case. I don't personally have time to test for every unique scenario that we may see in the wild.

The QFuse is a good point also. Every possible fuse has gotta be blown in my phone at this point . Still works fine though. In most cases this is used for warranty verification only - rooting will void your warranty likely by blowing one of the QFuses. Because bootloader locking usually goes hand and hand with rooting this is where we typically see the QFuse blow. In short, don't expect Sonim (or anyone else) to replace a bricked phone!

---------- Post added at 11:06 PM ---------- Previous post was at 10:43 PM ----------

Quote:
Originally Posted by albert.r

@smokeyou, maybe you can dump the image of the unlocked bootloader (is it a single eMMC partition or multiple partitions?) and share it with the forum, so we can flash it to our phones?
-albertr

It's 2 parts or 4 in total for both a and b sides of xbl and abl

I'm not sure if I'm allowed to share it since I'm not technically licensed to own a dev kit. But since I do, I basically just compiled GSI using dev tools under snapdragon-high-mid-2017-spf. Completed signing with my own test keys and applied over EDL with ease. It's risky though because anything applied incorrectly to keymaster will hard brick the device. That's why I'm hoping to avoid this route because without having the Sonim private key, I cant provide it without also providing a keymaster.

That was a first stab though too. After further testing I came to the determination that a modified bootloader may not actually be needed since this does not impact secure boot directly. All in theory only.
24th October 2019, 01:43 AM |#27  
Member
Thanks Meter: 2
 
More
Hi @smokeyou, thank you very much for your work and for answering my questions. Your help is much appreciated. I'm not concerned with invalidating the warranty, however I'm afraid that Magics can alter initrd and it won't pass verification during secure boot. It's unclear to me whether it will just go into bootloop and can be corrected by re-flashing original firmware, or can trip a fuse and brick the device. Basically, I want to take the risks of trying to root it, but only if I'm sure I can restore it to the working state if anything fails.

Right now, it looks to me that your device has a modified bootloader, and mine does not. So something that works for you, might crash and burn for me... I'll try to research more on secure boot and Magics...
-albertr
24th October 2019, 03:46 AM |#28  
Member
Thanks Meter: 3
 
More
Hey @albert.r

I'm with you here yeah!! That's exactly where we are with testing.

The QFuse does not seem to do much if anything. It does have the potential to invalidate keys and such if the developer chooses to be an ahole. I'm pretty confident this will not be an issue though after everything performed on my device prior to the unlock with no apparent issues.

Backup and restore is fairly sound - Or carrier switching across Sprint and AT&T firmware was tested prior to unlocking the bootloader at least. We will definitely have to see if the patched boot.img gives us any trouble but we should be able to restore as long as we can still access EDL. A boot failure it does just that - it loops and loops - but hold down the power and vol buttons and you can get right back into EDL again. We need to be careful in terms of start sectors and partition sizes but for the most part we should always be able to re-access EDL to perform a restore unless we modify keymaster or provide a corrupt boot image in both A&B slots.

I learned the keymaster issue the hard way . After a large number various flash/restore operations, the only issue I ever had was after accidentally nuking the keystore on one of the test devices.. At least it was free!

For 7.1 we also need to parse the GPT before doing anything as they could have changed the partition layout between versions. All my testing was done on 8.x.
24th October 2019, 05:24 AM |#29  
Member
Thanks Meter: 2
 
More
I can upgrade from 7.1.1 over to 8.1.0, so firmware will be the same as yours except for the changes you made to your bootloader. I need to research more on secure boot and Magics, since I don't quite understand how Magics can work if phone has secure boot enforced.

1. If that's the case, then Magics should not modify kernel and initrd/initramfs images, overwise protection will get tripped.
2. However, Magics needs to disable DM-verify, otherwise phone get's I/O errors while reading the files during the boot and it needs to be disabled earlier into the boot process. However, see #1.

So looks like a chicken and egg dilemma to me... I guess I must be missing something.
-albertr
24th October 2019, 08:23 AM |#30  
Member
Thanks Meter: 3
 
More
Mine still says Secure Boot enabled if that matters. I never tried to disable that.

Wondering the same thing here myself. It seems that Magisk is able to cope with DM-Verity however I'm not sure how this works either. I'm used to Nexus/Pixel devices where my thought process is trying to follow the same basic methods just with variation around how to apply the patched image.

I had to disable DM-Verity in order to mount the system partition as rw.. Needed to remove pre-loaded apps manually over adb. I wonder if DM-Verity could be the determining factor for some kind of boot lock? Looking at the boot flow documentation seems to reflect this could be the case as it would hit "eio" and prevent boot if the boot loader is still locked. So keep that DM Verity option checked when patching in Magisk but be careful before you delete AT&T Device Help lol.

That's actually not a bad start though. Probably easier to force unlock the bootloader once you have su privilege.

7.1.1 should work also. It's just a matter of where to apply the patched boot.img since I believe 8.x is when they moved to the A/B layout. We would have to use FHLoader in read-only mode to pull the first several sectors from emmc to confirm. It's probably safer to start with 8.x though to ensure we have the A/B structure applied.. Then we always have B unmodified as a backup option.
24th October 2019, 08:05 PM |#31  
Member
Thanks Meter: 2
 
More
Quote:

I had to disable DM-Verity in order to mount the system partition as rw.. Needed to remove pre-loaded apps manually over adb. I wonder if DM-Verity could be the determining factor for some kind of boot lock? Looking at the boot flow documentation seems to reflect this could be the case as it would hit "eio" and prevent boot if the boot loader is still locked. So keep that DM Verity option checked when patching in Magisk but be careful before you delete AT&T Device Help lol.

That's actually not a bad start though. Probably easier to force unlock the bootloader once you have su privilege.

Do you mean we cannot remove any apps with Magics without tripping DM-verify and we need to keep DM-verify still enabled in Magics? But we should be able to get rid of AT&T Device Help (and other garbage) once DM-verify is disabled, correct?
Do you remember which specific options you have to change in Magics Manager for modifying boot.img?
-albertr
Post Reply Subscribe to Thread

Tags
sonim-xp8

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes