Database Users

Resources for Samsung Galaxy TAB A 7.0 (2016) SM-T285

I've just got a new Samsung Galaxy TAB A 7.0 LTE SM-T285, For some reason I can't seem to find any resources for this hardware yet in this forum, anyone know where I could find one? I'll try to find out if the current methods (custom recovery and root) for other tab versions work on this.
CUSTOM ROMS
============
Android 5.1.1 Lollipop (Stock)
Tinker V5 Edition based on the Samsung Stock Rom SM-T280/T285
Android 6.0 Marshmallow
Cyanogenmod 13 for the SM-T285 Only
OMNIRom for the SM-T285 Only
Android 7.1 Nougat
Cyanogenmod 14.1 for the SM-T285 Only (Experimental, things are broken, depcrated in favor of LOS 14.1)
LineageOS 14.1 for the SM-T285 Only
Other Operating systems
Porting for Sailfish OS is currently in progress for the SM-T285, stay tuned
TWRP RECOVERY AND ROOT
=======================
TWRP is available for both the T280 and T285. You should find the relevant threads in this Galaxy Tab A forum.
If you want to root stock, easiest way is to install TWRP and go for SuperSU. Please see the TWRP threads for SM-T280/T285 on how to root after TWRP is installed.
KERNEL
======
Custom kernel with working sources for the SM-T285 can be found Here
DEVELOPMENT
============
If you want to build LineageOS 14.1 on your SM-T285 LTE device, you can use this manifest, not that this is still a work in progress:
https://github.com/jedld/android.git
UPDATE 10/06/2016
================
After a couple of weeks of trial and error and tinkering, I've been able to compile a kernel for the SM-T285 from source and so far it seems to work flawlessly!
Screenshot here: http://imgur.com/a/HRgsq
link to my kernel sources here: https://github.com/jedld/kernel_samsung_gtexslte.git
You can also thank samsung for giving us a "broken by default" kernel source. I had to mix and match defconfigs from their other kernel releases just to make this thing work. Download modified boot.img here:
http://forum.xda-developers.com/galaxy-tab-a/development/kernel-galaxy-tab-7-0-2016-lte-sm-t285-t3474967
UPDATE 09/20/2016
================
This device is now ROOTED!
http://forum.xda-developers.com/galaxy-tab-a/help/resources-samsung-galaxy-tab-7-0-2016-t3431022/post68777842#post68777842
Download Pre-rooted Tinker Edition V5 in this thread: Tinker Edition Thread
Post Root Post Mortem Analysis for the SM-T285 (09/21/2016)
=========================
Q: How were you able to find root? What did you do?
A: Surprisingly the SM-T285 bootloader isn't actually locked like we thought it was (Once you OEM unlock of course and disable FRP). The bottomline is that
we simply needed patches to mkbootimg to properly package a boot image for this device as there were additional fields and sections not found on a normal boot image. There were even minor breaking difference between the tab 4 and the boot image for this device.
Q: I thought the bootloader was locked?? Why did it take so long?
A: I blame it on the really vague errors the bootloader shows when loading an improperly packaged boot image. What helped was my faith to open up a hex editor when I needed to, and really look at the stock images and the images we were making. What really pushed me to investigate further was the fact that I was able to make a really small modification to the ramdisk and use the abootimg -u update function instead of the create options.
Q: So the bootloader doesn't really check the image?
A: Yup, The bootloader doesn't do any check. I haven't checked if that is the case for the recovery partition though. Even without the SELINUXENFORCE headers at the end it still continues like other samsung devices do.
Q: So the mkbootimg patches are all that we need?
A: Yup, if you have CM, AOSP build env ready you can simply add the modified mkbootimg to system/core:
https://github.com/jedld/degas-mkbootimg/commit/b63ae38e2ab7040cc7ddaef777652a56b2e48322
Sample usage below:
Code:
degas-mkbootimg -o boot.img --base 0 --pagesize 2048 \
--kernel boot.img-zImage --cmdline "console=ttyS1,115200n8" --ramdisk boot_kitchen/boot.img-ramdisk-new.gz --dt boot.img-dt
Next challenge will be getting Cyanogenmod on this device as well as TWRP.

You won't because it has a locked bootloader, therefore not currently rootable and certainly no custom recovery.

jaritico said:
any idea to unlock bootloader?
Click to expand...
Click to collapse
Not unless Samsung provides one.

jaritico said:
any idea to unlock bootloader?
Click to expand...
Click to collapse
Probably no hope for root. the PIT, boot and recovery are basically untouchable, selinux enforcing enabled also does not help. You can still debloat and customize the system partition though:
http://forum.xda-developers.com/android/development/guide-samsung-galaxy-tab-7-0-sm-t285-t3438296
I'm working on getting CM 12.1 to run on this device.

jedld said:
Probably no hope for root. the PIT, boot and recovery are basically untouchable, selinux enforcing enabled also does not help. You can still debloat and customize the system partition though:
http://forum.xda-developers.com/android/development/guide-samsung-galaxy-tab-7-0-sm-t285-t3438296
I'm working on getting CM 12.1 to run on this device.
Click to expand...
Click to collapse
Yes at least the saving grace is that Samsung left Dm-verity off for this device.
If only they'd have left out the root restriction in the kernel too we'd have a rootable device.
I have an idea for this that I haven't tried yet.
Basically Samsung sends out security Policy updates via OTA, they recently released an SEPOLICY update to most devices breaking root. Chainfire patched this.
As this policy is stored in DATA and over rides the one in the boot.img it may be possible to use a patched SEPOLICY by creating a flashable DATA image with the patched SEPOLICY thereby removing the SElinux root restriction.
I ran it by Chainfire and he said in theory it should work except for that fact that the SEPOLICY in DATA is signed.
I have yet to try this out.
I think it would be difficult to get CM running as the kernel may need some patches and as we know that can't be touched.

ashyx said:
Yes at least the saving grace is that Samsung left Dm-verity off for this device.
If only they'd have left out the root restriction in the kernel too we'd have a rootable device.
I have an idea for this that I haven't tried yet.
Basically Samsung sends out security Policy updates via OTA, they recently released an SEPOLICY update to most devices breaking root. Chainfire patched this.
As this policy is stored in DATA and over rides the one in the boot.img it may be possible to use a patched SEPOLICY by creating a flashable DATA image with the patched SEPOLICY thereby removing the SElinux root restriction.
I ran it by Chainfire and he said in theory it should work except for that fact that the SEPOLICY in DATA is signed.
I have yet to try this out.
I think it would be difficult to get CM running as the kernel may need some patches and as we know that can't be touched.
Click to expand...
Click to collapse
I ran it by Chainfire and he said in theory it should work except for that fact that the SEPOLICY in DATA is signed.
I have yet to try this out.
Click to expand...
Click to collapse
Would probably need to brush up on se policies in linux. If there are already files available that I just need to flash over to /data I can try it out and also a means to test it if it works.

I've created a petition here:
https://www.change.org/p/samsung-unlock-the-bootloader-for-the-samsung-galaxy-tab-a-7-0-2016?recruiter=286570213&utm_source=petitions_show_components_action_panel_wrapper&utm_medium=copylink&recuruit_context=copylink_long
Not sure if samsung is the type that listens to this sort of thing though.

ashyx said:
As this policy is stored in DATA and over rides the one in the boot.img it may be possible to use a patched SEPOLICY by creating a flashable DATA image with the patched SEPOLICY thereby removing the SElinux root restriction.
I ran it by Chainfire and he said in theory it should work except for that fact that the SEPOLICY in DATA is signed.
I have yet to try this out.
Click to expand...
Click to collapse
I made an attempt to patch sepolicy using data however all I got in the logs was
Code:
E/SELinux ( 733): Function: fileToArray, File Open Unsuccessful:
E/SELinux ( 733): Function: getVersionhash, signature is NULL
I/SELinux ( 733): Function: selinux_init_verify_sepolicy, getVersionhash return false
E/SELinux ( 733): Function: VerifyPolicy , selinux_init_verify_sepolicy is failed
So far I have no indication that my patch worked
Code:
sepolicy-inject -s shell -t system -c file -p read -P sepolicy -o sepolicy
The error above only comes up if I place sepolicy in /data/security and sepolicy_version in /data/security/spota
sha256 hashes were also updated in the version file so I'm not sure what I'm missing.
If I could have a copy of a samsung ota that actually updates the policies I can probably have better direction

jedld said:
I made an attempt to patch sepolicy using data however all I got in the logs was
Code:
E/SELinux ( 733): Function: fileToArray, File Open Unsuccessful:
E/SELinux ( 733): Function: getVersionhash, signature is NULL
I/SELinux ( 733): Function: selinux_init_verify_sepolicy, getVersionhash return false
E/SELinux ( 733): Function: VerifyPolicy , selinux_init_verify_sepolicy is failed
So far I have no indication that my patch worked
Code:
sepolicy-inject -s shell -t system -c file -p read -P sepolicy -o sepolicy
The error above only comes up if I place sepolicy in /data/security and sepolicy_version in /data/security/spota
sha256 hashes were also updated in the version file so I'm not sure what I'm missing.
If I could have a copy of a samsung ota that actually updates the policies I can probably have better direction
Click to expand...
Click to collapse
Finally found a way to patch the kernel on this device. Stay tuned...

jedld said:
Finally found a way to patch the kernel on this device. Stay tuned...
Click to expand...
Click to collapse
Turns out I was just able to modify files in the boot.img, though when I try to update the sepolicy itself, it won't boot.

jedld said:
Turns out I was just able to modify files in the boot.img, though when I try to update the sepolicy itself, it won't boot.
Click to expand...
Click to collapse
Can you at least explain a bit further?
What modifications allow you to create a boot able image?
How have you overcome image signing?
Only way I can think of is hex editing the signature, however I was under the impression this was crc based.

ashyx said:
Can you at least explain a bit further?
What modifications allow you to create a boot able image?
How have you overcome image signing?
Only way I can think of is hex editing the signature, however I was under the impression this was crc based.
Click to expand...
Click to collapse
Yeah I was able to flash a modified boot.img using heimdall, turns out that you just need to use abootimg -u boot.img -r yourmodifiedramdisk so that you don't overwrite the SELINUXENFORCE headers appended at the end of the boot.img file, it appears the bootloader only checks for the presence of those headers but does not actually compute the sig.
Modifying ramdisk works, haven't tried modifying the kernel itself.

I tried to modify the sepolicy files after using sepolicy-inject but it throws a KERNEL not SEnforced error. I am not certain if this is just a blanket error if the kernel doesn't boot due to modifying the policy files incorrectly or if there is legit checking going on. Nevertheless I am able to modify the init.rc files now.

jedld said:
I tried to modify the sepolicy files after using sepolicy-inject but it throws a KERNEL not SEnforced error. I am not certain if this is just a blanket error if the kernel doesn't boot due to modifying the policy files incorrectly or if there is legit checking going on. Nevertheless I am able to modify the init.rc files now.
Click to expand...
Click to collapse
Continued checking it out. So even though I can modify the ramdisk, I am unable to add more than 1000 - 2000 bytes before setting off the SEAndroid enforce error on bootup. Might be some headers on the boot.img that I fail to update when the ramdisk size gets bigger. Trying to modify the sepolicy in any way even if there is minimal change in size prevents it from booting. I have no idea what is checking it, I'll try to hexedit and see what happens.

jedld said:
Continued checking it out. So even though I can modify the ramdisk, I am unable to add more than 1000 - 2000 bytes before setting off the SEAndroid enforce error on bootup. Might be some headers on the boot.img that I fail to update when the ramdisk size gets bigger. Trying to modify the sepolicy in any way even if there is minimal change in size prevents it from booting. I have no idea what is checking it, I'll try to hexedit and see what happens.
Click to expand...
Click to collapse
So I used a hexedit on the sepolicy file and was able to modify one byte of it effectively changing its sha256sum... and it worked. So the sepolicy file CAN be changed, however current sepolicy-inject and supolicy tools does something to it that trips it, looks like samsung has again added a proprietary modification sepolicy format.

I've never known a kernel not boot due to the kernel not SEANDROID enforcing warning.
It's a meaningless warning and easily bypassed.
However this is on bootloader unlocked devices.
So just let me get this straight, you have been able to repack the boot.img with modifications to the ramdisk then force flash it via Heimdall and it still boots?

ashyx said:
I've never known a kernel not boot due to the kernel not SEANDROID enforcing warning.
It's a meaningless warning and easily bypassed.
However this is on bootloader unlocked devices.
So just let me get this straight, you have been able to repack the boot.img with modifications to the ramdisk then force flash it via Heimdall and it still boots?
Click to expand...
Click to collapse
yup. that's correct. I'll post my modified boot.img in a while

jedld said:
yup. that's correct. I'll post my modified boot.img in a while
Click to expand...
Click to collapse
note that using the update only method of abootimg "abootimg -u boot.img -r xxxxxx " is the only one that works for repacking the ramdisk. Trying to build the boot.img from scratch using any other method has so far failed for me.

Here is a flashable boot.img for the SM-T285.
It contains the following modifications to the ramdisk:
a file at /this_device_is_owned
and a modified init.rc that creates a /tmp folder

jedld said:
Here is a flashable boot.img for the SM-T285.
It contains the following modifications to the ramdisk:
a file at /this_device_is_owned
and a modified init.rc that creates a /tmp folder
Click to expand...
Click to collapse
now managed to patch sepolicy using chainfire's supolicy tool. needed to use a customized mkbootimg due to changes in the Tab A image format for this. now attempting to root the device... wish me luck

Universal (Dirtycow-based) TA Backup v2

Dirtycow-based TA Dumper for Sony Xperia Devices. (v2.0)
Author:
Jens Andersen
Xda: rayman
Twitter: https://twitter.com/EnJens
GitHub: EnJens
Source can be found on https://github.com/EnJens/backupTA.
Must be built within AOSP (e.g. checkout to external/backupTA)
Changelog:
More devices supported. The dreaded "Permission denied" should be long gone
Stability improved
TA dump is now verified before pulling
An error message is correctly shown when the process fails.
Requirements:
Phone running a dirtycow capable OS (E.g. recent N builds won't work).
If you have already upgraded, downgrading (temporarily) should be possible.
It should work on all recent xperia phones, but there might be exceptions.
It works on Linux, Windows and Mac (OS X)
Instructions:
Ensure you have adb access (e.g. drivers installed, enabled etc)
Run backupTA.sh (linux) or backupTA.cmd (windows) in the root directory.
TA will be saved as TA-ModelNumber-Serial-Timestamp.img in
the backupTA.sh directory.
On failure, the TA file should be missing, but please check that the file is 2.097.152 bytes
Download:
backupTA.zip
Credits:
rayman
Bumble-Bee (Testing)
Myself5 (Testing and some scripts)
oshmoun (Testing)
Androxyde (Testing)
munjeni (checkta source)
Tested on:
Xperia Z1
Xperia ZL
Xperia Z2
Xperia Z3
Xperia Z5
Xperia Z5 Compact
Xperia E5
Xperia M5
Xperia M4 Aqua
Xperia C5
Xperia X
Xperia XA
Xperia XA Ultra
Xperia X Performance
Xperia X Compact
Xperia XZ
XDA:DevDB Information
Universal (Dirtycow-based) TA Backup, Tool/Utility for the OEM Cross Device Development
Contributors
rayman, rayman
Source Code: https://github.com/EnJens/backupTA
Version Information
Status: Stable
Created 2016-12-07
Last Updated 2020-07-27

FAQ:
Q: Why is the backup different between reboots?
A: There is other data stored in the TA partition than just the TA Units. On some devices, the bootloader bootlog is stored there along with other pieces of data.

How it works
A very quick primer on how backupTA works now the source is out:
Sony's devices are extremely locked down with SELinux, and even getting root (with dirtycow) leaves you with very little access to the system.
Other than true root (which is rather difficult to get, although not impossible), only the Sony TA daemon has access to the partition required. But the TA daemon has no access to write any files anywhere on the device where we can pull them...
The basic approach is:
* Overwrite run-as binary with a custom binary
* When executed it switches to root and sets platform_app permissions, which for some bizarre reason is allowed from run-as explicitly. (See note 1)
* Once it has these privileges, it has access to dirtycow /sbin/tad_static
* It overwrites tad_static with a special daemon that allows reading the entire TA partition over the tad socket already used by the system. (See note 2)
* The run-as replacement reads the TA dump over the tad socket and pipes it to stdout to write to a file. (See note 3)
Note 1:
Dirtycow cannot increase the size of any binaries on the system, so to make things actually work, this solution also overwrites screenrecord binary (which is significantly bigger). run-as then executes this after setting up root and does all the fancy things. On some devices the platform-app context with root does not allow reading or writing files anywhere. To get around this, it reads the replacement tad_static from stdin and writes the dump to stdout. The script that runs run-as handles the piping.
Note 2:
When tad_static is first executes during boot, it's cached by linux. For efficiency reasons and because it's on a read-only filesystem, it's executed from this cache in memory. When dirtycow replaces the binary on /sbin, it actually replaces the running binary's code in memory, forcing it to crash. Init automatically restarts it, but now it's the replaced binary running which allows us to dump what we need.
Note 3:
The tad socket is actually quite limited permission-wise too. Only a limited subset of selinux contexts are allowed to read/write to it and the same goes for users. Luckily, root user with some supplementary groups, and the platform_app selinux context does have access to it, so we abuse that fact to talk to the replaced TA daemon.

Awesome. was waiting for this.thanks

Second!

wow nice find! I'm a bit bumped out I allready unlocked my booloader but this is great news!

Awesome... Congrats!!
XP F8131 output :good:
Code:
Picking 64-bit version
Running on F8131 on 64-bit platform
Pushing files
886 KB/s (9984 bytes in 0.010s)
743 KB/s (6088 bytes in 0.008s)
1072 KB/s (14280 bytes in 0.013s)
901 KB/s (10184 bytes in 0.011s)
122 KB/s (876 bytes in 0.006s)
Running scripts to dump ta to "TAIMG" on device
Overwriting run-as
Attempting to dirtycow
Done dirtycowing
Overwriting secondary payload (screenrecord)
Attempting to dirtycow
dirtycow failed
Attempting to dirtycow
Attempting to dirtycow
Done dirtycowing
Attempting exploit
Attempting to dirtycow
dirtycow failed
Waiting for result....
Bad reply received, failing...
Attempting exploit
Attempting to dirtycow
Attempting to dirtycow
dirtycow failed
Waiting for result....
Got a total of 2097152 bytes
Exploit successful!
Dumped TA as TA_F8131_CB512AD0TJ_06122016-2207.img
Pulling image
735 KB/s (2097152 bytes in 2.784s)
Cleaning up
TA Sucessfully pulled to TA_F8131_CB512AD0TJ_06122016-2207.img
****NOTE: Please verify filesize is 2MB ****
Pressione qualquer tecla para continuar. . .
Just a quick heads up. The first attempt failed because /data/local/tmp was not empty! It has two "flat..." files inside it (Stock fw).
Fix can be to change .sh and .cmd scripts to chmod each pushed file separately (instead of *), or even clear that folder.
Code:
Picking 64-bit version
Running on F8131 on 64-bit platform
Pushing files
180 KB/s (9984 bytes in 0.054s)
742 KB/s (6088 bytes in 0.008s)
1983 KB/s (14280 bytes in 0.007s)
1421 KB/s (10184 bytes in 0.006s)
213 KB/s (876 bytes in 0.004s)
[COLOR="DarkRed"]chmod: chmod '/data/local/tmp/flatland' to 100755: Operation not permitted
chmod: chmod '/data/local/tmp/flatland64' to 100755: Operation not permitted[/COLOR]
Running scripts to dump ta to "TAIMG" on device
...
Anyways... It did work like a charm! Respect!!

rayman said:
Dirtycow-based TA Dumper for Sony Xperia Devices.
Author:
Jens Andersen
Xda: rayman
Twitter: @droidray
GitHub: EnJens
Source will follow later this week.
Requirements:
Phone running a dirtycow capable OS (E.g. recent N builds won't work).
If you have already upgraded, downgrading (temporarily) should be possible.
It should work on all recent xperia phones, but there might be exceptions.
Instructions:
Ensure you have adb access (e.g. drivers installed, enabled etc)
Run backupTA.sh (linux) or backupTA.cmd (windows) in the root directory.
TA will be saved as TA-ModelNumber-Serial-Timestamp.img in
the backupTA.sh directory.
Download (Temporary. Will be moved, so please don't link to it):
https://skumler.net/backupTA.zip
Credits:
rayman
Bumble-Bee
Myself5 (Testing and some scripts)
oshmoun
Tested on:
Xperia Z3
Xperia Z5
Xperia Z5 Compact
Xperia X
Xperia XP
Xperia XC
Xperia XZ
Click to expand...
Click to collapse
So just to confirm, this fully backs up the TA partition including DRM keys on the Xperia XZ. So it's okay for me to now unlock the bootloader and restore everything with this? If so this is just what I've been waiting for!

Just to confirm, after TA (including DRMs) is backed up, I can unlock -> root -> then relock + restoring TA so I can have both root and DRMs working flawlessly? including OTA updates?

I don't think root with locked bootloader is possible. But if you got TA backup you can restore whenever you want and relock bootloader. Maybe important if you want to sell phone or if you need guarantee. @rayman
Will it be possible to create. ftf to flash drm key just like in Z5 line?

Whats the difference?

Difference to what? Your in German "android-hilfe", right?

serajr said:
Awesome... Congrats!!
Just a quick heads up. The first attempt failed because /data/local/tmp was not empty! It has two "flat..." files inside it (Stock fw).
Fix can be to change .sh and .cmd scripts to chmod each pushed file separately (instead of *), or even clear that folder.
Anyways... It did work like a charm! Respect!!
Click to expand...
Click to collapse
Good point. I went lazy-mode and just chmod'ed it all and assumed everything there would be shell-user owned...I guess that doesn't always stand true. I'll fix it up.
Sonic Dash said:
So just to confirm, this fully backs up the TA partition including DRM keys on the Xperia XZ. So it's okay for me to now unlock the bootloader and restore everything with this? If so this is just what I've been waiting for!
Click to expand...
Click to collapse
In theory. I've verified it makes a 100% accurate copy of the TA Partition. I can't realistically guarantee anything else, but yes, it *should* work like that. That's kind of the point.
boydzethuong said:
Just to confirm, after TA (including DRMs) is backed up, I can unlock -> root -> then relock + restoring TA so I can have both root and DRMs working flawlessly? including OTA updates?
Click to expand...
Click to collapse
Probably not... The second you flash back the locked TA, signed boot images will be required again and signed boot images mean dm-verity, meaning verified /system partitions, so it wouldn't boot anymore without 100% stock firmware.
DannyWilde said:
I don't think root with locked bootloader is possible. But if you got TA backup you can restore whenever you want and relock bootloader. Maybe important if you want to sell phone or if you need guarantee. @rayman
Will it be possible to create. ftf to flash drm key just like in Z5 line?
Click to expand...
Click to collapse
I don't see why not, but YMMV. It's certainly possible to extract the DRM key from the backup created by this tool and if Flashtool/bootloader allows flashing the data to a TA unit, it'll be possible.

Aaskereija said:
Whats the difference?
Click to expand...
Click to collapse
Difference to what? As of now, there is no tool to backup the TA on Android Versions above 5.1.1 (last Version where iovyroot worked on), exept this one
rayman said:
Good point. I went lazy-mode and just chmod'ed it all and assumed everything there would be shell-user owned...I guess that doesn't always stand true. I'll fix it up.
Click to expand...
Click to collapse
But shouldn't it just go on? I had the chmod failure during the final tests yesterday too, but I'm pretty sure it was just going on at that time.

How can I restore TA? I Backed up TA.

Heesue said:
How can I restore TA? I Backed up TA.
Click to expand...
Click to collapse
Unlock bootloader, flash TWRP, boot to TWRP, adb shell and use dd command to flash TA image back. Then power off and flash stock system, fotakernel and kernel with flashtool.

thanks great work friend, tested in xperia z5 premium

shoey63 said:
Unlock bootloader, flash TWRP, boot to TWRP, adb shell and use dd command to flash TA image back. Then power off and flash stock system, fotakernel and kernel with flashtool.
Click to expand...
Click to collapse
Thanks a lot!

AWESOME!!!
Very Good Job Guys!
BIG THANKS

Xperia X Compact
Seemed to work on Xperia X Compact:
Running 34.1.A.1.198 firmware
Really nice work
Output
Code:
Running on F5321 on 64-bit platform
Pushing files
[100%] /data/local/tmp/dirtycow
[100%] /data/local/tmp/run-as
[100%] /data/local/tmp/exploitta
[100%] /sdcard/dumpta
[100%] /data/local/tmp/backupTA.sh
Running scripts to dump ta to "TA_F5321_QV705K140B_20161207-1151.img" on device
Overwriting run-as
Attempting to dirtycow
Done dirtycowing
Overwriting secondary payload (screenrecord)
Attempting to dirtycow
dirtycow failed
Attempting to dirtycow
Attempting to dirtycow
Done dirtycowing
Attempting exploit
Attempting to dirtycow
dirtycow failed
Waiting for result....
Bad reply received, failing...
Attempting exploit
Attempting to dirtycow
Attempting to dirtycow
Attempting to dirtycow
Attempting to dirtycow
Done dirtycowing
Waiting for result....
Error connecting to unix socket: No such file or directory
Attempting exploit
Attempting to dirtycow
Attempting to dirtycow
Attempting to dirtycow
Attempting to dirtycow
Done dirtycowing
Waiting for result....
Error connecting to unix socket: No such file or directory
Attempting exploit
Attempting to dirtycow
Attempting to dirtycow
Attempting to dirtycow
Attempting to dirtycow
Done dirtycowing
Waiting for result....
Got a total of 2097152 bytes
Exploit successful!
Dumped TA as TA_F5321_QV705K140B_20161207-1151.img
Pulling image
[100%] /data/local/tmp/TA_F5321_QV705K140B_20161207-1151.img
Cleaning up
TA Sucessfully pulled to TA_F5321_QV705K140B_20161207-1151.img
****NOTE: Please verify filesize is 2MB ****

Just purchaced a Note 3 verizon, Pls suggest best practices to Root & unlock

Hello good peoples of Xda ,
I just purchased a Note 3 verizon I believe 900v on swappa It will arive in the next few day's and I want to get all my ducks in a row by that I mean aquire all the root and unlocking tools nessary for a best practices root and if nessary unlocking of my boot loader.
Goals for root are mostly to debloat the phone and hotspot mod's for no hassle teathering.
I may dip my toes into custom rom for this phone but mostly I am just looking for a clean lean experiance for my note 3. I have been pouring over the many many pages of the various rooting guids and I am just not sure witch method to use is the safest / most reliable .
thank you for your time and helpful suggestions.
This is what I have found so far.
ArabicToolApp : Root for lolipop
Odin3 v3.12.3 : flash tool is this latest ? best to use ?
Samsung usb drivers v1.5.45.0 : are these the proper drivers to install ?

You should start by figuring out which firmware release it has on it.
If it has PL1 (the newest security release, circa 2017/01/15), there will be no rooting for you... unless you manage to create a new exploit.
OB6 and OF1 - (one of) the yemen tool(s)**
NK1 - no root available ( and can't be rolled backwards w/ Odin, only NK1 or higher )
NJ6 - no root available? ( Try towelroot, or you can downgrade to NC4 using Odin )
MI9/MJ7/MJE/NC2(leak)/NC4 - Towelroot v3
For which bootloader unlock binary to use, see here.
Can't help you out with USB drivers, I don't remember what I used. afaik, they will either work 100% or not work at all, so you just need to get something working.
I've never used anything but Odin 3.0.9. Can't tell you if the version you mention is "better".
good luck
** i've never rooted OB6 or OF1, so can't give you any advice about which to use. Feel free to read the related threads. In my (casual) reading of those threads, it is nearly impossible to intuit out why some people have problems and others do not. Mostly because the reporting is not sufficiently detailed.

bftb0 said:
You should start by figuring out which firmware release it has on it.
Click to expand...
Click to collapse
Your right, after thinking about my post I realized there were 2 many variables that I need to know before I ask for help. So once I recieve the phone and if it's fully functional I will find out what firmware it has and what the cid it has and will post a follow up if I need help.
P.S thank you for the concise jist of what is and is not possible with the various firmware's.

Recieved my phone.
I got my note 3 and boy is it just a wonderful device. SM-900v running OF1 firmware, and My Cid is 15 so is all good.
procedurs completed.
I got root from useing the yemem tool.
and have tryed some debloating removed the NFL apk as a test with Tit.backup.
dissabled ota updates, I made a copy of the update.zip (that was downloaded with out me asking it too. I assume that this update.zip is the new PL4 firmware )and deleted it. renamed the fota.apk's with a .bak
not really sure if I should unlock the the bootloader I would love to have twerp.
Could anyone point me at a good debloating script ?
LOVE LOVE LOVE my note 3.
I also have a zero lemon battery/case combo on the way.

PL1 not PL4
See here. Might be dated - stuff tends to move around from release to release.
You should probably also freeze SDM.* and SysScope.* (in addition to LocalFOTA)**
There is a small permanent downside to unlocking - the blowing of the Knox Warranty Flag means that you will never be able to use Knox Secure containers, even if you did a full stock flash with Odin. Not sure how important this is to folks using the phone as a personal device (as opposed to a corporate device).
Operating with a rooted-stock device with a locked bootloader usually progresses through a customary arc - especially with new rooters, but also with experienced folks - where the user one day does some incremental mod that boot-loops the Android UI. At that point there is no means to reverse the small change. (You can't get in via "adb" as it's daemon isn't started yet, and even if it were, the fact that it is in secure mode means that you would have to have a stable UI in order to confirm the connection.) As there is no rooted secondary boot available (i.e., a custom recovery), there is no way to perform repairs, and a trip back to Odin is in store for the owner. Worse yet, a backup has never been made... so all customizations are all lost and must be re-created completely from scratch.
** this is a good idea if you unlock and install a custom recovery: (although TWRP may detect it and emasculate it automatically)
Code:
su
chmod 0000 /system/bin/install-recovery.sh

bftb0 said:
PL1 not PL4
Click to expand...
Click to collapse
Right PL1 ok.
Well I decided in for a penney in for a pound and have sucessfully unlocked my boot loader, had no issues.
my question now is how do I install twerp I have downloaded
twerp-3.0.2-0-hltevzw-4.4
and twerp 3.0.2-1-hlte.img.tar
I think I need to install the tar file.
but I don't know how. I have odin but not sure if that is the right program to use. I think I read where somone installed twerp with flashify or somthing like that.
What should I do ?

Truck'nfool said:
Right PL1 ok.
Well I decided in for a penney in for a pound and have sucessfully unlocked my boot loader, had no issues.
my question now is how do I install twerp I have downloaded
twerp-3.0.2-0-hltevzw-4.4
and twerp 3.0.2-1-hlte.img.tar
I think I need to install the tar file.
but I don't know how. I have odin but not sure if that is the right program to use. I think I read where somone installed twerp with flashify or somthing like that.
What should I do ?
Click to expand...
Click to collapse
man up and use a root prompt command line. It's a single command.
Code:
dd of=/dev/block/mmcblk0p15 if=/sdcard/twrp-3.0.2-0-hltevzw-4.4.img bs=2048
( assuming that you put the twrp .img file in the /sdcard folder. If it was in the download folder, then if=/sdcard/Download/twrp-3.0.2-0-hltevzw-4.4.img )
Note there are absolutely, positively no spaces anywhere in "mmcblk0p15". Critically important.
The above command writes a raw binary data (the .img file) to the 15th partition of the mmcblk0 device - the flash memory chip. You can do this with boot images (such as custom recoveries) or a few other binary images, but typically not with ext4 or other filesystems.
Note this command could be extremely dangerous if you made a mistake. If you were to write data someplace else it could be a permanent disaster. So cut-n-paste to be safest (without a new-line), and then double- and triple- check the command for typos before you hit the enter key.
FYI, you can see what the partition mapping is by doing a folder listing
Code:
ls -ld /dev/block/platform/*1/by-name/*
The partitioning scheme varies from android device to android device; but on the SM-N900V the recovery partition is the 15th partition. (On other devices it might be something different).

bftb0 said:
man up and use a root prompt command line. It's a single command.
dd of=/dev/block/mmcblk0p15 if=/sdcard/twrp-3.0.2-0-hltevzw-4.4.img bs=2048
Click to expand...
Click to collapse
are you talking about adb ?
So somthing like
adb shell
su
dd of=/dev/block/mmcblk0p15 if=/sdcard/twrp-3.0.2-0-hltevzw-4.4.img bs=2048
???

Truck'nfool said:
are you talking about adb ?
So somthing like
adb shell
su
dd of=/dev/block/mmcblk0p15 if=/sdcard/twrp-3.0.2-0-hltevzw-4.4.img bs=2048
???
Click to expand...
Click to collapse
That works.
Or a terminal emulator.
All you need is to put the file on your (internal, pseudo-) /sdcard, "su", and "dd".
For extra credit, make sure to compute a file checksum (e.g. "md5sum") every time you copy the original .img file to a new location and especially prior to flashing. That safeguards against a bad copy operation, crappy flash memory, etc.
Stock ROMs might not have a "md5sum" binary in /system/bin, but since you are rooted you could install a private busybox in someplace like /data/local/bin. I prefer to use a busybox which is SELinux-cognizant, e.g. v1.23.1 here as busybox_full_selinux_1.23.1.zip Note that I don't "install" this .zip so that stuff in /system/bin or /system/xbin get overwritten, but instead just keep it in a private area all on it's own.
Steps.
0) extract the "busybox" binary from the .zip file and get a copy to your SD card. Then
Code:
su
mkdir -p /data/local/bin
chmod 755 /data/local/bin
cp /sdcard/busybox /data/local/bin/
chmod 755 /data/local/bin/busybox
cd /data/local/bin
./busybox --install -s /data/local/bin
This allows it to be used as needed in a terminal/console shell.
e.g. using ls
1) Explicitly: /data/local/bin/ls -lZ *
2) Implicitly "as a last resort":
export PATH="${PATH}"':/data/local/bin'
ls -lZ *
3) Implicitly "as preferred":
export PATH='/data/local/bin:'"${PATH}"
ls -lZ *

I am now have root, unlocked bootloader and twrp Whoot!!
Well I now have twrp installed thank you vary much for all your help and direction I sincerly appreciate your assistance.
I installed termux and after updating the packages sucessfully used dd to install twrp.
1st thing I am going to do a full system backup.

No developer love for N900V not good

Root OP3T without unlocking bootloader - Automated App

ROOT w/o UNLOCKING BOOTLOADER:
Few of Qualcomm Devices have been found to have engineering mode software preinstalled on the device, which has root access. Using the same exploit root can be achieved in OP3, OP3T, OP5 and others, without unlocking the bootloader. Here is a full story: OnePlus Accidentally Pre-Installed an App that acts as a Backdoor to Root Access
The exploit was found by the user Elliot Alderson. An application has been promised by the author soon, to gain root access.
I have tested the method in OnePlus 3T and it works perfectly and passes SafetyNet check, furthermore you do not get DM-Verity error either.
Please follow the guide from here: OnePlus 3T Root w/o unlocking bootloader
Note: Do not modify system files though it won't let you, doing so will trigger Dm Verity.
Magisk Modules do not work, i,e you won't be able to use any modules.
Root and hide root works.
You will get system update but updating might kick you out of the root and you won't be able to gain access to root again.
It works on latest Oreo Beta, as you see in the screenshot.
Disclaimer: Follow the guide at your own risk, it is working fine for me, that in no way means it will work the same for you. Neither me nor the people envolved in this takes any responsibility. You and only you are responsible if anything goes wrong.
Note: I am not the developer or the person who found this exploit or root method. All credits go to them.
SCREENSHOTS ATTACHED
Update 1:
An app has been realsed by Oğuzhan Yiğit here is the link, the full credit goes to him for the same. Here is the link to the post:
Oneplus 3T Root Via App, further it installs SuperSU

This step is required every time you reboot:
adb shell
cd /data/magisk/
./magisk --mountimg xbin.img /system/xbin
magisk --post-fs
magisk --post-fs-data
magisk --service

I haven't tried doing the same, but theoretically, it shouldn't work.

[deleted]

casual_kikoo said:
...OnePlus 2...
Click to expand...
Click to collapse
That phone does not have dm-verity. That's why it works.
DOING THIS ON A ONEPLUS 3 OR NEWER WILL NOT WORK AND YOU WILL BRICK UNTIL YOU QUALCOMM UN-BRICK THE PHONE
Edit: I suggest deleting that and posting it in the OnePlus 2 section since someone will likely try it and brick.

SpasilliumNexus said:
That phone does not have dm-verity. That's why it works.
DOING THIS ON A ONEPLUS 3 OR NEWER WILL NOT WORK AND YOU WILL BRICK UNTIL YOU QUALCOMM UN-BRICK THE PHONE
Edit: I suggest deleting that and posting it in the OnePlus 2 section since someone will likely try it and brick.
Click to expand...
Click to collapse
Ok, as I thougth something else enter into account.
Thanks a lot !

As a newbie can u plz provide me the steps how to gain root access.?
Thanks in advance.

anuajayan said:
As a newbie can u plz provide me the steps how to gain root access.?
Thanks in advance.
Click to expand...
Click to collapse
Please do the necessary steps, I will assist you wherever you get stuck, you can also reach me at telegram on @apurvak

coolstoneapurva said:
Please do the necessary steps, I will assist you wherever you get stuck, you can also reach me at telegram on @apurvak
Click to expand...
Click to collapse
I don't know from where or how to start with? Please guide me accordingly..

replace hosts file
OK, so I decided to take advantage and replace my hosts file. I gain adb root, but then
Code:
@~/Downloads/oneplus[20:56:04]~: adb push hosts /system/etc/hosts
adb: error: failed to copy 'hosts' to '/system/etc/hosts': remote couldn't create file: Read-only file system
hosts: 0 files pushed. 73.3 MB/s (327680 bytes in 0.004s)
trying without success
Code:
@~/Downloads/oneplus[21:00:48]~: adb remount
remount failed
and from within
Code:
@~/Downloads/oneplus[21:00:51]~: adb shell
OnePlus3T:/ # 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),3009(readproc) context=u:r:su:s0
OnePlus3T:/ # mount -o rw,remount /system
'/dev/block/dm-0' is read-only
What am I doing wrong or need to do to replace my hosts file, please?

mitkko said:
OK, so I decided to take advantage and replace my hosts file. I gain adb root, but then
trying without success
and from within
What am I doing wrong or need to do to replace my hosts file, please?
Click to expand...
Click to collapse
It's a good thing something is stopping you, because you shouldn't be modifying any file on the partitions. Again, dm-verity is enabled. You modifying any file directly will result in getting a corrupt error after a reboot. Use Magisk for systemless modifications.

Please write in first post if OTA will still work on next update. And if possible specify if this woks also on oxygen os open beta with Android Oreo.
That said, anyone know if possible to unlock bootloader state, without trigger the factory reset??

SpasilliumNexus said:
It's a good thing something is stopping you, because you shouldn't be modifying any file on the partitions. Again, dm-verity is enabled. You modifying any file directly will result in getting a corrupt error after a reboot. Use Magisk for systemless modifications.
Click to expand...
Click to collapse
How do I do that? Assume I have already introduced magisk to my phone.

mitkko said:
How do I do that? Assume I have already introduce magisk to my phone.
Click to expand...
Click to collapse
Isn't there a systemless host option for adblock in Magisk's settings? If so, turn it on, install AdAway, turn on systemless hosts in that, apply the adblock.

SpasilliumNexus said:
Isn't there a systemless host option for adblock in Magisk's settings? If so, turn it on, install AdAway, turn on systemless hosts in that, apply the adblock.
Click to expand...
Click to collapse
Never used it before. Is that persistent? I mean after reboot and magisk root gone will it persist? I don't need persistent root, I just want to patch hosts one time only if possible.

mitkko said:
Never used it before. Is that persistent? I mean after reboot and magisk root gone will it persist? I don't need persistent root, I just want to patch hosts one time only if possible.
Click to expand...
Click to collapse
It's not persistent. The last steps for root access in that guide needs to be done after every reboot, which is also needed for AdAway to apply the block. Applying the adblock after root doesn't need a reboot.
You're better off just doing the traditional unlock and root instead.
Hope that makes sense.

Deodexed and Patched EngineeringMode.apk for restore default Privilege
I played a little with Angela`s Root and wanted to restore the previous level of privilege. In the application there is a special button rollback changes, but it is Invisible
Code:
this.mPrivilege = this.findViewById(2131493042);
this.mPrivilege.setOnClickListener(((View$OnClickListener)this));
this.mPrivilege.setVisibility(4); //this.mPrivilege.setVisibility(View.INVISIBLE);
So I did the application deodex and patched the application, changing it to
Code:
this.mPrivilege.setVisibility(0); //this.mPrivilege.setVisibility(View.VISIBLE);
After that I changed the original application to patched
Code:
adb remount
adb push EngineeringMode_SIGNED_ALIGNED.apk /system/app/EngineeringMode/EngineeringMode.apk
And start them
Code:
adb shell am start -n com.android.engineeringmode/.qualcomm.DiagEnabled --es "code" "angela"
Result Screenshort:
After click on the button, the phone restarts and all privileges are restored

mitkko said:
OK, so I decided to take advantage and replace my hosts file. I gain adb root, but then
Code:
@~/Downloads/oneplus[20:56:04]~: adb push hosts /system/etc/hosts
adb: error: failed to copy 'hosts' to '/system/etc/hosts': remote couldn't create file: Read-only file system
hosts: 0 files pushed. 73.3 MB/s (327680 bytes in 0.004s)
trying without success
Code:
@~/Downloads/oneplus[21:00:48]~: adb remount
remount failed
and from within
Code:
@~/Downloads/oneplus[21:00:51]~: adb shell
OnePlus3T:/ # 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),3009(readproc) context=u:r:su:s0
OnePlus3T:/ # mount -o rw,remount /system
'/dev/block/dm-0' is read-only
What am I doing wrong or need to do to replace my hosts file, please?
Click to expand...
Click to collapse
You shouldn't make any changes to system partion doing to will render you unable to boot, as dm verity is enabled.

andQlimax said:
Please write in first post if OTA will still work on next update. And if possible specify if this woks also on oxygen os open beta with Android Oreo.
That said, anyone know if possible to unlock bootloader state, without trigger the factory reset??
Click to expand...
Click to collapse
Yes it will work on next update as system files are intact, further it works on Beta Oreo as you can see the screenshot. I will further update the post with the same.

seems not working on Android 8 /OOS 5

(How I got) XZ premium Fingerprint Volte & WiFi calling WITHOUT bootloader unlock

*This would not be possible without j4nn & his amazing temp root https://forum.xda-developers.com/xperia-xz1-compact/development/devonly-exploits-temp-root-to-backup-t3795510 please thank & donate 2 him!*
This is not really a "how 2 guide" because I am not good at explaining things like this. But I will try & explain how I did it. Because I have seen a lot of other people also searching for working Volte without unlocking their bootloader.
First I used j4nn's temp root guide & flashed old firmware & ran his magic program. Then I backed up my DRM keys (incase I want to unlock my bootloader someday). Then I stopped. And instead of unlocking my bootloader & while still in temp root.. I thought, maybe I can write to the OEM folder? So I typed
'mount -o rw,remount /oem' and that worked!
So.. I used another command window without closing the first one and pushed a new OEM folder to /data/local/temp
(I got the new OEM folder from US XZ1c firmware. you can also get that folder by searching for TMo-VoLTE-fix-v3.zip & unziping it)
Then, I went back to the original temp root command window & used the 'cp' command to copy that new OEM file from data/local/temp over to my /OEM folder. I re-set the owner & file permissions rebooted.
After testing it, I was able 2 flash the latest (non US for working fp) Oreo by flashing like normal with Newflasher except I deleted the OEM.sin file, so it wouldn't write over my new one! Finally I disabled auto update.
Now my XZp is still bootloader locked, running 47.1.A.16.20 with Fingerprint, Volte & wifi calling all working on tmobile in the US.
I can actually receive calls at home now!! Before this, most of my calls went 2 vm, after a long pause.
I did also try it with pie & it didn't work for me. But, ymmv. I am sure it's possible tho. I was not impressed with pie anyways & I really hate that new volume popup window that covered my home & back keys in landscape mode.
One other note is because I have the dual sim XZp I changed my modem name in the modem.conf file from "tmobile_us_ims" to "dsds_tmobile_us_ims". I am not sure this is actually necessary tho because I have since looked in other ds Volte firmwares like Taiwan. And they don't use "dsds" in their modem.conf file

Robin Banks said:
*This would not be possible without j4nn & his amazing temp root https://forum.xda-developers.com/xperia-xz1-compact/development/devonly-exploits-temp-root-to-backup-t3795510 please thank & donate 2 him!*
This is not really a "how 2 guide" because I am not good at explaining things like this. But I will try & explain how I did it. Because I have seen a lot of other people also searching for working Volte without unlocking their bootloader.
First I used j4nn's temp root guide & flashed old firmware & ran his magic program. Then I backed up my DRM keys (incase I want to unlock my bootloader someday). Then I stopped. And instead of unlocking my bootloader & while still in temp root.. I thought, maybe I can write to the OEM folder? So I typed
'mount -o rw,remount /oem' and that worked!
So.. I used another command window without closing the first one and pushed a new OEM folder to /data/local/temp
(I got the new OEM folder from US XZ1c firmware. you can also get that folder by searching for TMo-VoLTE-fix-v3.zip & unziping it)
Then, I went back to the original temp root command window & used the 'cp' command to copy that new OEM file from data/local/temp over to my /OEM folder. I re-set the owner & file permissions rebooted.
After testing it, I was able 2 flash the latest (non US for working fp) Oreo by flashing like normal with Newflasher except I deleted the OEM.sin file, so it wouldn't write over my new one! Finally I disabled auto update.
Now my XZp is still bootloader locked, running 47.1.A.16.20 with Fingerprint, Volte & wifi calling all working on tmobile in the US.
I can actually receive calls at home now!! Before this, most of my calls went 2 vm, after a long pause.
I did also try it with pie & it didn't work for me. But, ymmv. I am sure it's possible tho. I was not impressed with pie anyways & I really hate that new volume popup window that covered my home & back keys in landscape mode.
One other note is because I have the dual sim XZp I changed my modem name in the modem.conf file from "tmobile_us_ims" to "dsds_tmobile_us_ims". I am not sure this is actually necessary tho because I have since looked in other ds Volte firmwares like Taiwan. And they don't use "dsds" in their modem.conf file
Click to expand...
Click to collapse
Do we lose drm key? Can I access the / system or use root explorer?

tronganhha29 said:
Do we lose drm key? Can I access the / system or use root explorer?
Click to expand...
Click to collapse
You won't lose any drm keys if you don't unlock the bootloader. I posted screen shots above that show all security keys intact, with locked bootloader. And if you look at the top, the wifi calling icon is there! The "rooting" part I used was only temporary & I only tried 2 modify files in the /OEM folder because that's all I needed for Volte & WiFi calling on tmobile. I had 2 downgrade firmware & run a temp root exploit from j4nn.
His exploit is explained here https://forum.xda-developers.com/xperia-xz1-compact/development/devonly-exploits-temp-root-to-backup-t3795510 BUT, instead of unlocking the bootloader I just copied US Xz1c /OEM files into my /OEM folder then set file permissions. That would be awesome if someone could make a script 2 automate this process for everyone!
Remember after your done, your gonna want 2 update to a newer more secure firmware. I didn't have luck with Pie, but it's got some minor bugs anyways (I am running Oreo 47.1.A.16.20 now & I love it). The trick is you MUST DELETE the OEM.sin folder from the new firmware folder before you flash it. Otherwise it will write over your progress.

Robin Banks said:
You won't lose any drm keys if you don't unlock the bootloader. I posted screen shots above that show all security keys intact, with locked bootloader. And if you look at the top, the wifi calling icon is there! The "rooting" part I used was only temporary & I only tried 2 modify files in the /OEM folder because that's all I needed for Volte & WiFi calling on tmobile. I had 2 downgrade firmware & run a temp root exploit from j4nn.
His exploit is explained here https://forum.xda-developers.com/xperia-xz1-compact/development/devonly-exploits-temp-root-to-backup-t3795510 BUT, instead of unlocking the bootloader I just copied US Xz1c /OEM files into my /OEM folder then set file permissions. That would be awesome if someone could make a script 2 automate this process for everyone!
Remember after your done, your gonna want 2 update to a newer more secure firmware. I didn't have luck with Pie, but it's got some minor bugs anyways (I am running Oreo 47.1.A.16.20 now & I love it). The trick is you MUST DELETE the OEM.sin folder from the new firmware folder before you flash it. Otherwise it will write over your progress.
Click to expand...
Click to collapse
Can you help me on activating VoLTE? I read in the above tutorial just talking about backup and restore TA partition. Sorry for my English not good. Thank you!

tronganhha29 said:
Can you help me on activating VoLTE? I read in the above tutorial just talking about backup and restore TA partition. Sorry for my English not good. Thank you!
Click to expand...
Click to collapse
Are you in the US, & want Volte on Tmobile?

Robin Banks said:
Are you in the US, & want Volte on Tmobile?
Click to expand...
Click to collapse
No, I'm in Vietnam, i'm using G8141 with custom CH firmware

tronganhha29 said:
No, I'm in Vietnam, i'm using G8141 with custom CH firmware
Click to expand...
Click to collapse
I am sorry, I am not familiar with any phone providers in Vietnam. I don't think there is an easy fix because I haven't seen Vietnamese Volte modem files in any XZp firmware. I could be wrong tho, so maybe someone will correct me & also help you out.
The only reason this works for tmobile is because Sony included built in support files for some providers, like tmobile in the US. But, it's only their XZ1c phone that will actually load the correct modem file & trigger Volte & WiFi calling features out of the box. Only a couple files need to be changed on the XZp.
Problem was, it always required a bootloader unlock to change those files.
This is not a problem anymore... Because it can now be done with temproot thanks to j4nn!

Robin Banks said:
I am sorry, I am not familiar with any phone providers in Vietnam. I don't think there is an easy fix because I haven't seen Vietnamese Volte modem files in any XZp firmware. I could be wrong tho, so maybe someone will correct me & also help you out.
The only reason this works for tmobile is because Sony included built in support files for some providers, like tmobile in the US. But, it's only their XZ1c phone that will actually load the correct modem file & trigger Volte & WiFi calling features out of the box. Only a couple files need to be changed on the XZp.
Problem was, it always required a bootloader unlock to change those files.
This is not a problem anymore... Because it can now be done with temproot thanks to j4nn!
Click to expand...
Click to collapse
I worry about losing drm key. I was on the xzc and I had a camera error.
Thank you !

tronganhha29 said:
I worry about losing drm key. I was on the xzc and I had a camera error.
Thank you !
Click to expand...
Click to collapse
The only way you can lose your DRM keys... Is unlocking your bootloader. I did not want to do that. But, I wanted Volte & WiFi calling. This thread is about how I got those features WITHOUT unlocking my bootloader. And yes, of course I still have my DRM keys.
You said, that you had a camera error on an XZ1c? Assuming, you unlocked the bootloader. Did you get Volte working in Vietnam after you unlocked it? If not, then none of this will help you with your XZp. because they are very similar & they use the same provider modem files.
From what I understand, the Pie update fixes the green picture camera error. Have you tried updating your XZ1c to Pie? That should atleast make your camera work again.

Good idea, i'm using others country rom because my country update speed suck ... (Due to the carrier) , so i lose feature like WIFI calling and VoLTE. Gonna try this.

vyis said:
Good idea, i'm using others country rom because my country update speed suck ... (Due to the carrier) , so i lose feature like WIFI calling and VoLTE. Gonna try this.
Click to expand...
Click to collapse
This is what people in the US with the XZ1c have been doing because they want to enable their Fingerprint sensor AND have the US Volte settings.
So if your provider already supports Volte.. Flash that firmware first so your volte works. Then before you flash the country you want to use. Just delete the new OEM.sin file out of the folder. That will make a perfect mix of the two.
It will only keep your volte provider settings from old firmware. You don't even need temp root.
But I doubt Volte setting would survive an OTA update. It also will work with two different build versions. I don't know if this is possible with oreo/pie mix tho.

Robin Banks said:
*This would not be possible without j4nn & his amazing temp root https://forum.xda-developers.com/xperia-xz1-compact/development/devonly-exploits-temp-root-to-backup-t3795510 please thank & donate 2 him!*
This is not really a "how 2 guide" because I am not good at explaining things like this. But I will try & explain how I did it. Because I have seen a lot of other people also searching for working Volte without unlocking their bootloader.
First I used j4nn's temp root guide & flashed old firmware & ran his magic program. Then I backed up my DRM keys (incase I want to unlock my bootloader someday). Then I stopped. And instead of unlocking my bootloader & while still in temp root.. I thought, maybe I can write to the OEM folder? So I typed
'mount -o rw,remount /oem' and that worked!
So.. I used another command window without closing the first one and pushed a new OEM folder to /data/local/temp
(I got the new OEM folder from US XZ1c firmware. you can also get that folder by searching for TMo-VoLTE-fix-v3.zip & unziping it)
Then, I went back to the original temp root command window & used the 'cp' command to copy that new OEM file from data/local/temp over to my /OEM folder. I re-set the owner & file permissions rebooted.
After testing it, I was able 2 flash the latest (non US for working fp) Oreo by flashing like normal with Newflasher except I deleted the OEM.sin file, so it wouldn't write over my new one! Finally I disabled auto update.
Now my XZp is still bootloader locked, running 47.1.A.16.20 with Fingerprint, Volte & wifi calling all working on tmobile in the US.
I can actually receive calls at home now!! Before this, most of my calls went 2 vm, after a long pause.
I did also try it with pie & it didn't work for me. But, ymmv. I am sure it's possible tho. I was not impressed with pie anyways & I really hate that new volume popup window that covered my home & back keys in landscape mode.
One other note is because I have the dual sim XZp I changed my modem name in the modem.conf file from "tmobile_us_ims" to "dsds_tmobile_us_ims". I am not sure this is actually necessary tho because I have since looked in other ds Volte firmwares like Taiwan. And they don't use "dsds" in their modem.conf file
Click to expand...
Click to collapse
You are awesome! Can you please write specific commands you used to
1) push a new OEM folder to /data/local/temp
2) 'cp' command to copy that new OEM file from data/local/temp over to my /OEM folder.
3) I re-set the owner & file permissions rebooted.
Thanks!

VBBoston said:
You are awesome! Can you please write specific commands you used to
1) push a new OEM folder to /data/local/temp
2) 'cp' command to copy that new OEM file from data/local/temp over to my /OEM folder.
3) I re-set the owner & file permissions rebooted.
Thanks!
Click to expand...
Click to collapse
I will try. But, like I said. I am not that great at step by step instructions. It would be awesome if someone made a better guide or a script 2 run after temp root.
So, AFTER you already have temp root. Open another command window (keep your temp root window open!) assuming you have the new OEM folder in your command line root dir.
Adb push OEM /data/local/tmp
Then using the temp root window from earlier exploit.
mount -o rw,remount /oem
chown root.root /data/local/tmp/OEM
cd /data/local/tmp/OEM
cp - R * /oem
chmod 755 /oem/modem-config
chmod 755 /oem/modem-config/408
chmod 644 /oem/modem-config/408/modem.conf
chmod 755 /oem/overlay-408
chmod 644 /oem/overlay-408/android-res-310-408.apk
chmod 644 /oem/overlay-408/com.android.carrierconfig-res-310-408.apk
chmod 644 /oem/overlay-408/com.android.phone-res-310-408.apk
chmod 644 /oem/overlay-408/com.android.settings-res-310-408.apk
chmod 644 /oem/overlay-408/com.android.systemui-res-310-408.apk
chmod 755 /oem/system-properties/408
chmod 644 /oem/system-properties/408/config.prop
Done. Reboot. You might half to take out your Sim card & reinsert it. Or factory reset. To get volte setting to take. You will know because it will say something like restarting to update carrier configuration.
Then of course you can update, but be shure to delete the OEM.sin file before flashing newer firmware! I tried this with pie once & it did not work for me. But ymmv. Right now I like oreo better anyways
I have included the zip file I found here on XDA & used it. It's meant for bootloader unlocked so just Unzip it & only use the OEM file.
Please let me know how it goes or if I forgot something!

Robin Banks said:
I will try. But, like I said. I am not that great at step by step instructions. It would be awesome if someone made a better guide or a script 2 run after temp root.
So, AFTER you already have temp root. Open another command window (keep your temp root window open!) assuming you have the new OEM folder in your command line root dir.
Adb push OEM /data/local/tmp
Then using the temp root window from earlier exploit.
mount -o rw,remount /oem
chown root.root /data/local/tmp/OEM
cd /data/local/tmp/OEM
cp - R * /oem
chmod 755 /oem/modem-config
chmod 755 /oem/modem-config/408
chmod 644 /oem/modem-config/408/modem.conf
chmod 755 /oem/overlay-408
chmod 644 /oem/overlay-408/android-res-310-408.apk
chmod 644 /oem/overlay-408/com.android.carrierconfig-res-310-408.apk
chmod 644 /oem/overlay-408/com.android.phone-res-310-408.apk
chmod 644 /oem/overlay-408/com.android.settings-res-310-408.apk
chmod 644 /oem/overlay-408/com.android.systemui-res-310-408.apk
chmod 755 /oem/system-properties/408
chmod 644 /oem/system-properties/408/config.prop
Done. Reboot. You might half to take out your Sim card & reinsert it. Or factory reset. To get volte setting to take. You will know because it will say something like restarting to update carrier configuration.
Then of course you can update, but be shure to delete the OEM.sin file before flashing newer firmware! I tried this with pie once & it did not work for me. But ymmv. Right now I like oreo better anyways
I have included the zip file I found here on XDA & used it. It's meant for bootloader unlocked so just Unzip it & only use the OEM file.
Please let me know how it goes or if I forgot something!
Click to expand...
Click to collapse
Thank you!!! just needed to edit command cp - R * /oem to cp -R * /oem

Robin Banks said:
[...] because I have the dual sim XZp I changed my modem name in the modem.conf file from "tmobile_us_ims" to "dsds_tmobile_us_ims".
Click to expand...
Click to collapse
Since my G8342 does not load the correct 'Current Modem Configuration' (see screenshot from G8341) I can force this by editing the 'modem.conf', right?

SGH-i200 said:
Since my G8342 does not load the correct 'Current Modem Configuration' (see screenshot from G8341) I can force this by editing the 'modem.conf', right?
Click to expand...
Click to collapse
I am just gonna guess that your running a single Sim firmware & you want 2 load a dual sim modem? I am pretty shure that won't work. You can use a single Sim firmware & modem file on a dual sim phone. But the other sim slot won't function. But it looks like you already know that. I am using a dual sim firmware (and phone g8142). But there is no official Volte tmobile firmware for the XZp. Even tho the correct tmobile modem is baked into all the XZp firmwares. It needs the OEM.sin to provision volte & WiFi. It sets "IMS" true or something like that. So I used an oem.sin config file from a single Sim Xz1c. But the rest of my firmware is still XZp dual sim. I originally changed the part where it loads the correct modem & added "dsds" to the beginning because that's what the tmobile modem in my firmware is named. That worked. But it turns out, I didnt even half 2 do that. It still loads my "dsds_tmobile_us_ims" modem. Even tho I just have "tmobile_us_ims" in my modem.conf file. If you were gonna try and load a diffent modem it would be under /oem/modem-config/310/modem.conf because 310 is the customization that your running (in your thumbnail). So, yes you can force it 2 load whatever modem you want.. But only try the modems that are included with your current firmware. I wouldnt copy an actual dual sim modem into your single sim firmware. It *might* work. More then likely would brick it. Lemme know if you have any other questions & I will help ya if I can

Robin Banks said:
I am using a dual sim firmware (and phone g8142). But there is no official Volte tmobile firmware for the XZp. Even tho the correct tmobile modem is baked into all the XZp firmwares. It needs the OEM.sin to provision volte & WiFi. It sets "IMS" true or something like that. So I used an oem.sin config file from a single Sim Xz1c. But the rest of my firmware is still XZp dual sim.
Click to expand...
Click to collapse
This is the way I did it, too!
Robin Banks said:
[...]still loads my "dsds_tmobile_us_ims" modem. Even tho I just have "tmobile_us_ims" in my modem.conf file.
Click to expand...
Click to collapse
Flashing the OEM.sin is not enough in my case (G8342) because the modem file is missing!?
Robin Banks said:
But only try the modems that are included with your current firmware.
Click to expand...
Click to collapse
Is it possible to "look" into a SIN file without flashing it, to see which modem files are included, without flashing the firmware?

SGH-i200 said:
This is the way I did it, too!
Flashing the OEM.sin is not enough in my case (G8342) because the modem file is missing!?
Is it possible to "look" into a SIN file without flashing it, to see which modem files are included, without flashing the firmware?
Click to expand...
Click to collapse
The actual modem files are in modem.sin and you could unpack them and take a look. But, if your using a single sim xz1 OEM.sin that supports your carriers volte settings.. I think you should be able 2 just flash the whole firmware. I have flashed a single Sim firmware on my XZp and back to dual sim. You will loose your second sim functionality. But you can always flash a dual sim firmware back & it will be good has new. Do you really use 2 sim cards? Check out the 7th post in this thread (user rafi.mv6) about Xz1 single Sim flashing. https://forum.xda-developers.com/xz-premium/how-to/xzp-volte-firmware-t3631276

I used j4nn bindershell version of the temp root and Your guide to activate VoLTE and VoWiFi for Vodafone CZ not for the temp root supported Oreo, but for the actually last available Pie firmware 47.2.A.10.107 Customized CE1 (1308-5321) for XZ Premium single SIM G8141
I am about to write down the detailed guide soon. It is based on info from j4nn post #9 in his bindershell version temp root thread.

XZ Premium Vodafone CZ Volte & WiFi calling in Pie WITHOUT bootloader unlock​
THE STORY BEHIND
As I have very poor telephone signal inside the building of our veteran garage due to combination of a garage-to-BTS distance and very thick walls of an old building and many calls to me ended up with "The number cannot be reached, try again later" and me receiving the SMS with info about missed call, I wanted to use last issued Android for my Xperia XZ Premium single SIM G8141 and to have available VoLTE and VoWiFi for my provider Vodafone CZ. Then I started to investigate, which version of the phone and which customization I have exactly. I found, that despite being located in Central Europe, my phone customization was to my surpise of South Africa (1308-5324 Customized ZA 47.2.A.10.107). To achieve activation of the VoLTE and VoWiFi I thought, it could be enough to flash the Central Europe customization (1308-5321 Customized CE1 47.2.A.10.107), as special Vodafone CZ customization was not showed by XperiCheck, and it will all work seamlessly then. I could not be wrong more. After quite weak search for the info, I downloaded and flashed that Pie CE1 customization, with skipping userdata, all TA files and persist.sin to keep all data and settings not erased, there was no VoLTE nor VoWiFi available anyway. Then I started to investigate the possibilities more intensively. What I found, there was no direct option to have VoLTE and VoWiFi activated somehow on Pie, as the temp root and modification guides was available just for Oreo. But there were some hints within those threads, that pointed me to the possibility to achieve to have that function on Pie as well. Despite there were infos, that the intended sequences did not worked for some members trying it for Pie, it was not detailed enough to be clear, how they proceed. So I started to think about that all the time and based on number of Xperia XZ1c/XZ1/XZp threads, I considered many ways how to achieve my goal. Finally, the resulted steps were none of my ideas, I just collected all the wisdome from those threads and I just put them into the right sequence, that worked for me. If being on temp root supported Oreo firmware when started, it could be a path without loosing any user data, but as I was on last Pie, I had to backup every possible data and settings and to proceed the downgrade from Pie to Oreo with factory reset. There is no known way to me to downgrade with user data being kept, as despite I was warned, I tried it and I got the "promised" bootloop of course.
THE BASIC INFO
- SONY Xperia XZ1 (G8341), SONY Xperia XZ1 Compact (G8441) and SONY Xperia XZ Premium (G8141) are very similar phones with almost identical hardware. Therefore their firmwares do not differ much, at least in the text config files content manner. Hinted by XDA users, there can be the config files adapted from one of those devices to another easily. Many of them tested that for the Oreo and it worked fine for them.
- There exists Vodafone CZ customized Pie firmware for both XZ Premium friendly phones and they differ to their CE1 customized Pie firmware version just in the config settings part of oem.sin file and all modem definitions present inside in the system.sin are the same, so to change active modem, there is just config files modification needed that can be achieved through the temp root
- Using UnSin and ext4 image mounting SW investigate the files content, location and presence and try to figure out, which files could work for Your phone
- when flashing firmware, all excluded *.sin files/partitions will be not overwritten by new data and kept in the phone in current status and content. This is used in described steps to transfer changes from firmware supported by temp root to target firmware.
THE DESCRIPTION
The VoLTE and VoWiFi config files are in the /oem folder's subfolders. The content of the /oem folder can be kept when upgrading from lower to higher version of the Android by excluding the oem*.sin file when flashing. I disliked the idea to have oem settings from Oreo in the Pie and I tried to modify Pie's /oem folder within the Oreo firmware. Based on the info from this forum and by comparing all the firmwares content, I prepared (copied from CZ customized Pie firmware version of friendly phone G8341 XZ1) few files, that I identified to be important to change the modem file choosing by the system in XZ Premium Pie. So I prepared my own custom Oreo temp root supported CE1 customized firmware, excluded the XZp Oreo oem.sin and included the XZp Pie oem*.sin. I prepared the files to be changed in XZp Pie's /oem folder and the XZp Pie firmware with oem.sin excluded as well. I flashed first the hybrid XZp Oreo-with-Pie-oem-folder firmware to my phone successfully, started the XZp with Android Oreo. I cancelled all automatic updates, activated developer menu item and set the USB debugging ON. With using ADB I ran temp root, injected modified files into the /oem folder and set their rights. Rebooted and with temp root again I checked the injected files presence in /oem folder. Then I flashed CE1 customized XZp Pie firmware with its oem.sin excluded and rebooted XZp to Pie. I cancelled all automatic updates again and checked the modem and VoLTE settings. There was VoLTE option switch inside the service menus in blue color and actitaved with the VoWiFi option greyed out but set to ON. There the Enable VoLTE menu item appeared in the Network settings and it could be switched ON. In the Call settings, the Wi-Fi calling menu item appeared there in Advanced settings and could be activated. The service itself appeared and started to function after activating the service inside the provider Self service web portal.
THE PRINCIPLE
- I wanted VoLTE and VoWiFi for Vodafone CZ on SONY Xperia XZ Premium single SIM G8141
- To let it work, I had to modify Pie's /oem folder
- it is posible to modify it only when rooted or temp rooted
- I do not want to root it
- the only temp root is for Oreo
- I prepared and flashed hybrid firmware, Pie /oem with the Oreo main system - this trick was my only invention to this and it fortunately worked !
- I modified Pie /oem folder inside Oreo firmware temp root to support Pie's VoLTE and VoWiFi for Vodafone CZ
- I flashed latest Pie excluding the oem.sin to keep modified /oem settings then
- I switched the device settings ON and I activated the provider support for Vodafone CZ VoLTE and VoWiFi in Self Service portal
- Now I can enjoy Vodafone CZ VoLTE and VoWiFi on SONY Xperia XZ Premium single SIM G8141
WHAT TO DOWNLOAD
- To investigate Your phone version settings (not needed to follow my steps)
Download UnSin (UnSIN 1.13 (Win x64).zip)
Download SW for mounting and explore ext4 partition (ext2explore-2.2.71.rar)
Download the firmware for the other phones to look for setting files. In my case, it was G8341 Vodafone CZ customized Pie firmware (XZ1 G8341_Vodafone CZ_47.2.A.11.228-R2C)
- To activate VoLTE and VoWiFi for Vodafone CZ on SOMY Xperia XZ Premium single SIM G8141 (enough to follow my steps)
Download ADB (platform-tools_r33.0.2-windows.zip)
Download newflasher (newflasher_v52.zip)
Download the j4nn temp root alternative solution for G8141 (bindershell)
Download the G8141 j4nn temp root supported Oreo firmware in the same customization, as the later Pie to minimize issues (XZ Premium G8141_47.1.A.16.20 Customization CE1)
Download the G8141 CE1 customized Pie firmware (1308-5321 Customized CE1 47.2.A.10.107)
Download the G8141 Vodafone CZ customized Pie /oem fodler files (attached here as G8141_Vodafone_CZ_Modded_Pie_OEM_folder.ZIP)
THE PREPARATION
- if You want to proceed for phone different to G8141 and Vodafone CZ, check with xpericheck all three phone versions firmwares, whether there is any that contains customized version for Your provider, if there is one for Your phone, just flash that customization and You go
- if there is customized version of the firmware for Your provider for any of the other two phones, investigate the content of those firmwares oem*.sin and system*.sin files and try to match the proper files to copy/modify for Your phone (use UnSin and ext4 explorer for this task), the content of modem.conf file in oem.sin file, modem-config folder holds the short name of the modem *.mbn file in system.sin file, etc/customization/modem folder. For example, if modem.conf file contains "vodafone_czech_volte_vowifi" text, it defines using the "amss_fsg_maple_vodafone_czech_volte_vowifi_tar.mbn" modem files, that allows function of VoLTE and VoWiFi for Vodafone CZ. If Your firmware in system.sin contains modem file with the same name, You can modify /oem part of the firmware to select this modem and activate VoLTE and VoWiFi for Your phone/provider combination as well. I was inspired by Robin Banks files copied and I identified and copied several relevant files from G8341 Vodafone CZ firmware's /overlay folder as well. Try to add similar files for Your phone version as well.
- Prepare the XZ Premium single SIM G8141 temp root supported Oreo firmware into folder "01 not full Oreo downgrade with Pie OEM"
- exclude the Oreo oem.sin to allow using Pie oem.sin
- exclude the following Oreo firmware files as well: see content of the folder "01b not used Oreo files" (for the list see attachement file G8141_Vodafone_CZ_mod_FoldersContent.TXT)
- do not exclude userdata.sin when downgrading or else You get the bootloop (tested by myself )
- copy inside the folder the Pie's oem*.sin (oem_X-FLASH-CUST-42E5.sin)
- copy inside the folder the newflasher.exe file (to ease the process)
- extract ADB files into its folder, c:\platform-tools\ in my case
- copy content of the "02 adb push files" folder into c:\platform-tools\, extract it from the attached G8141_Vodafone_CZ_Modded_Pie_OEM_folder.ZIP
- copy bindershell file from j4nn for Oreo temp root into c:\platform-tools\
- Prepare the XZ Premium single SIM G8141 last Pie firmware into folder "03 Pie flash without OEM"
- exclude the Pie oem.sin
- exclude the following Pie firmware files as well: see content of the folder "03b_not_used_Pie_files" (for the list see attachement file G8141_Vodafone_CZ_mod_FoldersContent.TXT)
- copy inside the folder the newflasher.exe file too
- check both firmware folders to have their boot_delivery.xml file in boot folder and partition_delivery.xml file in partition folder for the flash to end correctly
- check the G8141_Vodafone_CZ_mod_FoldersContent.TXT and compare the folders' content to match
THE STEPS (Windows PC)
#01 - have Your phone charged, all data and settings backed up (including trim areas) and all phone drivers installed, this is a good way to start
#02 - go to "01 not full Oreo downgrade with Pie OEM" folder and run newflasher.exe inside, it will open a command line window, stay in this window
#03 - switch off the phone, hold volume down key and connect it to PC, wait for green LED ilumination and release volume down button
#04 - type 'n' + ENTER to skip install of GordonGate flash driver (You have them already installed, see step #01)
#05 - type 'p' + ENTER for poweroff after flash
#06 - type 'n' + ENTER to skip of dump trim area backup and the Oreo with Pie oem.sin flash will start, wait several minutes for process to finish
#07 - when flash finished, disconnect phone, close command line window
#08 - switch ON the phone and start Oreo system fully, disable any automatic updates ASAP, to stay on temp root supported firmware version of the Oreo
#09 - become a Developer and in Developer menu switch USB debugging ON
#10 - connect the phone to PC and allow connection
#11 - go to c:\platform-tools\ in Explorer and using SHIFT+right click open e.g. first PowerShell window from this folder
#12 - in PowerShell window type 'adb push bindershell /data/local/tmp' and press ENTER to copy bindershell file to the phone
#13 - if You do not have ADB fully installed and You just have drivers copied into the c:\platform-tools\ folder, type the command like this './adb push bindershell /data/local/tmp', add the './' before ADB commands in future, if this error repeats
#14 - in PowerShell window type 'adb shell' (or add ./ in the front of the command again) and press ENTER to run shell in the phone, the command prompt will change from PC:/platform-tools> to the name of Your phone, e.g. G8141:/ $
#15 - get a simple temp root shell according j4nn HOWTO
G8141:/ $ cd /data/local/tmp
G8141:/data/local/tmp $ chmod 755 ./bindershell
G8141:/data/local/tmp $ ./bindershell
#16 - You will know to have a temp root, when the prompt character changes from $ to # (like G8441:/data/local/tmp #), keep this first PowerShell window open
#17 - open a second PowerShell window from the same folder as the first one (c:\platform-tools\) using SHIFT+right click
#18 - in the second PowerShell window type 'adb push OEM /data/local/tmp' and ENTER to copy your modified files from c:\platform-tools\OEM folder on the PC to /data/local/tmp/OEM folder in the phone (in case of error add the './' before the command), after finishing, You can close this second PowerShell window
#19 - activate the first PowerShell window with the temp root still active and type following commands (these are the Robin Banks commands he wrote in the post #13 modified for my XZ Premium single SIM Vodafone CZ version)
mount -o rw,remount /oem
chown root.root /data/local/tmp/OEM
cd /data/local/tmp/OEM
cp -R * /oem
chmod 755 /oem/modem-config
chmod 644 /oem/modem-config/modem.conf
chmod 755 /oem/overlay
chmod 644 /oem/overlay/android-res-305.apk
chmod 644 /oem/overlay/com.android.carrierconfig-res-305.apk
chmod 644 /oem/overlay/com.android.settings-res-305.apk
chmod 644 /oem/overlay/com.android.systemui-res-305.apk
chmod 755 /oem/system-properties/
chmod 644 /oem/system-properties/config.prop
#20 - for You own setup, remember to set rights 755 for any folder name and rights 644 for any file name copied from /data/local/tmp/OEM to /oem folder inside the phone
#21 - Done. Reboot the phone into the Oreo with now modified Pie /oem folder. Close PowerShell window.
#22 - You can repeat temp root now to check, If Your files are really present inside the phone /oem folder and You proceeded well.
#23 - do not panic, if You check the Service info/Software info menu item now by dialing *#*#7378423#*#* and there is still recent modem *.mbn file selected, do not care about it as it is prepared for Pie and You are still on Oreo firmware now
#24 - go to "03_Pie_flash_without_OEM" folder and run newflasher.exe inside, it will open a command line window, stay in this window
#25 - switch off the phone, hold volume down key and connect it to PC, wait for green LED ilumination and release volume down button
#26 - type 'n' + ENTER to skip install of GordonGate flash driver
#27 - type 'p' + ENTER for poweroff after flash
#28 - type 'n' + ENTER to skip of dump trim area backup and Pie without oem.sin flash will start, wait several minutes for process to finish
#29 - when flash finished, disconnect phone, close command line window, now there is complete Pie system with VoLTE and VoWiFi modified /oem folder installed on Your device and all should work from now on
#30 - switch ON the phone and start Pie system, disable any automatic updates ASAP to keep Your modification in tact and not overwritten by future possible updates, if You want, regularly check for the firmware updates manualy and if there is a newer firmware You want to run, be prepared to proceed the whole this procedure again with newer firmware and test if it works for it as well
THE CREDITS
- j4nn for the XZp temp root alternative
- Robin Banks for the original How To
- chris_j26 for information in his [GUIDE] Enable VoLTE for your non operator handset thread (this needs Unlocked BL)
- pbarrette for the info to flash the cust-reset.ta file to clear the device current carrier customization information
- and credits for the SW creators (UnSin 1.13 - IgorEisberg, newflasher v52 - munjeni, Ext2Explore - rcrajesh & regmi_manish)
- and all the others forgotten...
THE DOWNLOAD
Here You can find
files list with the folders structure for all steps described above and compressed modified OEM folder to push to G8141 XZp single SIM Vodafone CZ
- all files used by me listed with their folder structure in TXT file
- a zip file with XZ Premium single SIM OEM folder modified for Vodafone CZ VoLTE & VoWiFi
- pictures
01 original ZA customization info
02 target CE1 customization info before MOD
03 final CE1 modded to CZ customization info after MOD
04 *#*#4636#*#* telephone info after MOD
05 WiFi calling menu item after MOD