Related
The folks over at Sony Ericsson have released something a bit useful if you’ve been wondering lately how to build Linux Kernels for your phone. Sony Ericsson’s Developers has laid out a detailed process on how to build a new Linux kernel and flash it to your Android device. We’ve pasted the info below for you so you don’t have to hop around. Below you’ll find Sony Ericsson’s how-to in its entirety for your convenience with respective links and all. If you’ve been wanting to tinker and dive into the world of Linux and flashing kernels on mobile devices, we’d say now is the time. Follow the expert step by step process and toss us a note or two in the comments below if this works out for you. However, keep in mind, even though the article is written by experienced Sony Ericsson developers, nothing is guaranteed to work the way it’s supposed to. So be very diligent while following and performing these tasks. In other words, do your research first.
How to build a Linux kernel and flash it to the phone.
Since the launch of the unlock boot loader site, Sony Ericsson have received a lot of really great feedback. The Sony Ericsson Developer Program wants to continue to build on this open dialogue with external developers.
Developers and advanced users can now unlock the boot loader, which is the first step to be able to flash your own image. Where developers run into problems when building their own image, and and trying to flash the image using Fastboot.
Before moving on, I like to remind you again that there is no turning back when unlocking the boot loader. You may void the warranty of the phone, and you will not be able to revert the phone to a locked or original state if you unlock it.
What is the Linux kernel?
The Xperia™ line of smartphones run on the Android™, the mobile operating system based on the Linux kernel. Though it is only a small part of the operating system, the kernel ensures that all other processes in the system are synchronized to work together properly.
Why rebuild the kernel?
Rebuilding the kernel enables end users to make modifications to their devices that are normally not intended by the device manufacturer, such as theming the device by changing system icons and removing/modifying system components. Please note that Sony Ericsson is not recommending this.
Considerations before building your own kernel and reflashing your device
As mentioned in the beginning of this article, the first step is to unlock the boot loader. When the boot loader is unlocked, the sensitive data is removed, such as DRM certificates, and the user partition of the file system is wiped out. But all other functionality, such as the camera and other drivers, is left intact. Please note that content, like music files, that require the DRM certificate will not be accessible any more. But most importantly, you may void the warranty of your phone if you decide to unlock it. Aside from the considerations mentioned above, the functionality is there, just waiting for you to take advantage of it. So, if you’re ready, here’s how to get started.
Building the kernel
It takes a few main steps to build the kernel. Below we’ll show you how to build a Linux kernel and flash it onto the device.
Step A – Download the necessary software
Download the following software to get started:
The kernel source code can be downloaded from the copyleft archives on Sony Ericsson Developer World. You can use the file called ex. 3.0.A.2.181_182.tar.bz2 for our Android™ Gingerbread devices. This is the source code for the Linux kernel as used in the Xperia™ PLAY.
The Fastboot client which is part of the Android SDK. This is the standard Android flashing utility. This allows you to flash the image you are about to create onto the device.
The Init RAM disk. The initial RAM disk (also known as the initrd) is the initial filesystem that the kernel will mount and start running processes off. You can configure the Init RAM disk to grant root access. How you create or download your own Init RAM disk is beyond the scope of this article.
The ARM cross-compiler. A cross-compiler is used to build ARM binaries on a different architecture, such as x86. This allows you to compile software (such as the kernel) into a format that the device can run. We recommend getting the CodeSourcery Lite compiler, especially the GNU/Linux variant, as you’ll need that if you want to build binaries for a full-blown Linux system on the device later. However, any EABI ARM compiler capable of compiling the Linux kernel should be enough for this step.
Step B – Building the kernel
To build the kernel, you first need to unpack the kernel. Once you’ve unpacked the kernel, you need to configure it, and then build it. The example below is based on you using the file called 3.0.A.2.181_182.tar.bz2.
1. Go into the kernel directory:
cd kernel
2. Configure the kernel:
ARCH=arm CROSS_COMPILE=/opt/arm-2010q1/bin/arm-none-eabi- make semc_zeus_defconfig
Note: Replace /opt/arm-2010q1 with where you installed your cross-compiler. Also, this example is for Xperia™ PLAY. Replace defconfig with the following values depending on what device you want to configure it for:
Xperia™ PLAY semc_zeus_defconfig
Xperia™ arc semc_anzu_defconfig
Xperia™ neo semc_hallon_defconfig
3. Build the kernel:
ARCH=arm CROSS_COMPILE=/opt/arm-2010q1/bin/arm-none-eabi- make
Replace /opt/arm-2010q1 with where you installed your cross-compiler. Once done, you should have a compressed kernel-image in arch/arm/boot/zImage.
Step C – Getting a RAM disk
The RAM disk is the initial filesystem the kernel will mount before transferring control to userspace. How you create your own root filesystem is beyond the scope of this article, but you can use the following instructions to pack/unpack the file.
Unpacking (you have to ramdisk.img, and weant to create a directory of files out of it):
gzip -d – < ramdisk.img > cpio -idm
Packing (You have directory of files, and want to create ramdisk.img from it):
find . | cpio –quiet -H newc -o | gzip > ramdisk.img
Step D – Assembling the boot.img
Now that we have all the parts we need to create a flashable file. The next stop is to package the parts. To do this, you’ll need the program mkbootimg, which is part of the standard Android tree. If you don’t feel like compiling all of Android to get this tool, it is available to download from various trusted sites on the Internet.
Once you have the tool, this is the command to combine your kernel and RAM disk into a flashable file:
mkbootimg –base 0×00200000 –kernel kernel/arch/arm/boot/zImage –ramdisk ramdisk.img -o boot.img
Step E – Flashing the file
You should flash the file using Fastboot. If you’ve unlocked the boot loader on your device, you already have Fastboot.
1. To flash the boot.img file, use the following the command
fastboot –i 0x0fce flash boot boot.img
2. Now, it will prompt you to connect your device. To do so, follow these simple steps:
Make sure your device is powered down.
Hold down the Search button (Xperia™ PLAY only) or the Back button (all other Xperia™ devices). The device’s notification light should shine blue to confirm it’s inFastboot mode.
Connect the USB cable.
Flashing should now start and complete.
3. As a last step in the process, you need to reboot the device. You can either remove the USB cable and battery to power the device down. If you prefer, you can instead issue the following command (either method will work):
fastboot –i 0x0fce reboot
Important information!
Additional information for experienced Linux kernel experts
The kernel is pretty standard, all the regular things you’re used to is there, and available to use. Things that are different are the memory config and the kernel commandline. The memory config is hardcoded (i.e., ATAGs aren’t used for this). It’s set in the board-file for your target, such as kernel/arch/arm/mach-msm/board-semc_zeus.c in the function msm7x30_fixup. The kernel commandline is also not fetched from the boot.img file, but compiled into the kernel (CONFIG_CMDLINE). Some arguments are also added from the boot loader.
Additional information if porting non-Linux format files to the device. The boot loader will accept any reasonably formatted boot.img file.
For example, at the Android Kernel Git, you will see the format of the boot.img file. This allows you to create a boot.img file containing two loadable files (kernel+ramdisk), which will get loaded into RAM. Once the boot loader is loaded, it passes the control to the first instruction of the loaded kernel image. After control is passed, the kernel can rely on the data contained in the RAM disk already being loaded.
Guide by Karl-Johan Dahlström
Hashy said:
The folks over at Sony Ericsson have released something a bit useful if you’ve been wondering lately how to build Linux Kernels for your phone. Sony Ericsson’s Developers has laid out a detailed process on how to build a new Linux kernel and flash it to your Android device. We’ve pasted the info below for you so you don’t have to hop around. Below you’ll find Sony Ericsson’s how-to in its entirety for your convenience with respective links and all. If you’ve been wanting to tinker and dive into the world of Linux and flashing kernels on mobile devices, we’d say now is the time. Follow the expert step by step process and toss us a note or two in the comments below if this works out for you. However, keep in mind, even though the article is written by experienced Sony Ericsson developers, nothing is guaranteed to work the way it’s supposed to. So be very diligent while following and performing these tasks. In other words, do your research first.
How to build a Linux kernel and flash it to the phone.
Since the launch of the unlock boot loader site, Sony Ericsson have received a lot of really great feedback. The Sony Ericsson Developer Program wants to continue to build on this open dialogue with external developers.
Developers and advanced users can now unlock the boot loader, which is the first step to be able to flash your own image. Where developers run into problems when building their own image, and and trying to flash the image using Fastboot.
Before moving on, I like to remind you again that there is no turning back when unlocking the boot loader. You may void the warranty of the phone, and you will not be able to revert the phone to a locked or original state if you unlock it.
What is the Linux kernel?
The Xperia™ line of smartphones run on the Android™, the mobile operating system based on the Linux kernel. Though it is only a small part of the operating system, the kernel ensures that all other processes in the system are synchronized to work together properly.
Why rebuild the kernel?
Rebuilding the kernel enables end users to make modifications to their devices that are normally not intended by the device manufacturer, such as theming the device by changing system icons and removing/modifying system components. Please note that Sony Ericsson is not recommending this.
Considerations before building your own kernel and reflashing your device
As mentioned in the beginning of this article, the first step is to unlock the boot loader. When the boot loader is unlocked, the sensitive data is removed, such as DRM certificates, and the user partition of the file system is wiped out. But all other functionality, such as the camera and other drivers, is left intact. Please note that content, like music files, that require the DRM certificate will not be accessible any more. But most importantly, you may void the warranty of your phone if you decide to unlock it. Aside from the considerations mentioned above, the functionality is there, just waiting for you to take advantage of it. So, if you’re ready, here’s how to get started.
Building the kernel
It takes a few main steps to build the kernel. Below we’ll show you how to build a Linux kernel and flash it onto the device.
Step A – Download the necessary software
Download the following software to get started:
The kernel source code can be downloaded from the copyleft archives on Sony Ericsson Developer World. You can use the file called ex. 3.0.A.2.181_182.tar.bz2 for our Android™ Gingerbread devices. This is the source code for the Linux kernel as used in the Xperia™ PLAY.
The Fastboot client which is part of the Android SDK. This is the standard Android flashing utility. This allows you to flash the image you are about to create onto the device.
The Init RAM disk. The initial RAM disk (also known as the initrd) is the initial filesystem that the kernel will mount and start running processes off. You can configure the Init RAM disk to grant root access. How you create or download your own Init RAM disk is beyond the scope of this article.
The ARM cross-compiler. A cross-compiler is used to build ARM binaries on a different architecture, such as x86. This allows you to compile software (such as the kernel) into a format that the device can run. We recommend getting the CodeSourcery Lite compiler, especially the GNU/Linux variant, as you’ll need that if you want to build binaries for a full-blown Linux system on the device later. However, any EABI ARM compiler capable of compiling the Linux kernel should be enough for this step.
Step B – Building the kernel
To build the kernel, you first need to unpack the kernel. Once you’ve unpacked the kernel, you need to configure it, and then build it. The example below is based on you using the file called 3.0.A.2.181_182.tar.bz2.
1. Go into the kernel directory:
cd kernel
2. Configure the kernel:
ARCH=arm CROSS_COMPILE=/opt/arm-2010q1/bin/arm-none-eabi- make semc_zeus_defconfig
Note: Replace /opt/arm-2010q1 with where you installed your cross-compiler. Also, this example is for Xperia™ PLAY. Replace defconfig with the following values depending on what device you want to configure it for:
Xperia™ PLAY semc_zeus_defconfig
Xperia™ arc semc_anzu_defconfig
Xperia™ neo semc_hallon_defconfig
3. Build the kernel:
ARCH=arm CROSS_COMPILE=/opt/arm-2010q1/bin/arm-none-eabi- make
Replace /opt/arm-2010q1 with where you installed your cross-compiler. Once done, you should have a compressed kernel-image in arch/arm/boot/zImage.
Step C – Getting a RAM disk
The RAM disk is the initial filesystem the kernel will mount before transferring control to userspace. How you create your own root filesystem is beyond the scope of this article, but you can use the following instructions to pack/unpack the file.
Unpacking (you have to ramdisk.img, and weant to create a directory of files out of it):
gzip -d – < ramdisk.img > cpio -idm
Packing (You have directory of files, and want to create ramdisk.img from it):
find . | cpio –quiet -H newc -o | gzip > ramdisk.img
Step D – Assembling the boot.img
Now that we have all the parts we need to create a flashable file. The next stop is to package the parts. To do this, you’ll need the program mkbootimg, which is part of the standard Android tree. If you don’t feel like compiling all of Android to get this tool, it is available to download from various trusted sites on the Internet.
Once you have the tool, this is the command to combine your kernel and RAM disk into a flashable file:
mkbootimg –base 0×00200000 –kernel kernel/arch/arm/boot/zImage –ramdisk ramdisk.img -o boot.img
Step E – Flashing the file
You should flash the file using Fastboot. If you’ve unlocked the boot loader on your device, you already have Fastboot.
1. To flash the boot.img file, use the following the command
fastboot –i 0x0fce flash boot boot.img
2. Now, it will prompt you to connect your device. To do so, follow these simple steps:
Make sure your device is powered down.
Hold down the Search button (Xperia™ PLAY only) or the Back button (all other Xperia™ devices). The device’s notification light should shine blue to confirm it’s inFastboot mode.
Connect the USB cable.
Flashing should now start and complete.
3. As a last step in the process, you need to reboot the device. You can either remove the USB cable and battery to power the device down. If you prefer, you can instead issue the following command (either method will work):
fastboot –i 0x0fce reboot
Important information!
Additional information for experienced Linux kernel experts
The kernel is pretty standard, all the regular things you’re used to is there, and available to use. Things that are different are the memory config and the kernel commandline. The memory config is hardcoded (i.e., ATAGs aren’t used for this). It’s set in the board-file for your target, such as kernel/arch/arm/mach-msm/board-semc_zeus.c in the function msm7x30_fixup. The kernel commandline is also not fetched from the boot.img file, but compiled into the kernel (CONFIG_CMDLINE). Some arguments are also added from the boot loader.
Additional information if porting non-Linux format files to the device. The boot loader will accept any reasonably formatted boot.img file.
For example, at the Android Kernel Git, you will see the format of the boot.img file. This allows you to create a boot.img file containing two loadable files (kernel+ramdisk), which will get loaded into RAM. Once the boot loader is loaded, it passes the control to the first instruction of the loaded kernel image. After control is passed, the kernel can rely on the data contained in the RAM disk already being loaded.
Guide by Karl-Johan Dahlström
Click to expand...
Click to collapse
Thanks, this helped immensely! My phone is running much better now.
Hi,
I'm currently waiting for buy the Xperia XZ. I check some of XDA's thread and with Sony's smartphone I'm still afraid. So I want to know if there is a thread gathering all the detailled step to root, install TWRP, flash latest firmware, install custom ROM etc... ?
Thanks a lot
[Guide] Here is the DHGE guide for rooting SONY devices 2019-04
Changelog at the bottom of this post.
nathan30 said:
if there is a thread gathering all the detailed step to root, install TWRP, flash latest firmware, install custom ROM etc... ?
Click to expand...
Click to collapse
No - but you can find all you need to know here in this forum or in the devices-fora later than Z3+ or SONY-cross-device.
https://forum.xda-developers.com/crossdevice-dev/sony
Good introductory (written for devices before Z3+):
https://forum.xda-developers.com/crossdevice-dev/sony/noob-guide-to-sony-ericsson-xperia-t3209012
It is still valid but the 2015 and newer devices are not rootable anymore as described thanks to DM-Verity.
For rooting the current device you have to open the bootloader.
Any claims to the contrary found "on the web" are only tricks to have you install "interesting" software on a Windows PC.
Do you want root?
A classic post to help you decide
No:
wait for the OTA-updates from SONY (over the air - prosaic?)
don't like waiting or want to downgrade: get Flashtool http://www.flashtool.net
it comes with Xperifirm that finds you the latest ROM
https://forum.xda-developers.com/cr...xperifirm-xperia-firmware-downloader-t2834142
Unfortunately Xperifirm only finds the latest ROM (the only available on SONYs servers) so you better keep your downloads (>2 GBytes each) or find an older ROM in case you need it (xda has a search function). Here you'll find some ROM-versions: https://xpericheck.com
since my Xperia XZ/XZ1 I occasionally have problems with Flashtool that it requires a FSC-script which does not come with it or can not easily be copied from a similar device.
Now I use Newflasher https://forum.xda-developers.com/cr...gress-newflasher-xperia-command-line-t3619426 by @munjeni. This is a command line tool that for me unfortunately only works under Windows (have JDK issues under Debian).
You unpack the ROM (ftf-file) and place the newflasher.exe in the directory where you unpacked to. Then you start the device in flash mode (power on while holding the volume down key) and run the tool from the command line as administrator/root.
If you do not delete userdata.sin you will initiate the equivalent of a factory reset (aka loose all your data and settings!). For an upgrade within the same Andoid version I always delete userdata.sin before newflashing.
Yes:
As stated above, you need to unlock the bootloader to modify the system software on your device. Fortunately SONY gives (for non-carrier-locked) devices the option to unlock the bootloader.
Check if unlocking is allowed: in the service menu (dial *#*#7378423#*#* or *#*#SERVICE#*#* ) check under "Service Info"->"Configuration" the line "Bootloader unlock allowed:"
If you read anything other than "Yes" Stop here!
No: flashing another SONY Rom ("Customized CountryX") does not help you.
Hint: there is an app "SONY service menu" in the app-repository (F-Droid or Google).
OK - you can Now it is your last chance to save your device keys or "backup the trim area partition"
You should do this if you ever want to return to a SONY "blessed" state. e.g claiming service in countries where warranty is not for devices with unlocked bootloader or you want to sell it.
There are some device specific kernels out there whose authors state that they mitigate all DRM issues once the TA is restored. I guess you need these kernels otherwise restoring the TA locks up your device ...
Otherwise do not bother with restoring the TA-partition. Doing so after the next steps will soft brick your device.
Now you have to prepare your PC with some drivers in order to start the backup process:
Go to SONY's developver world http://developer.sonymobile.com
Under "Downloads" you will find the drivers for the XZ or any other device http://developer.sonymobile.com/downloads/drivers/xperia-xz/
These drivers are for Windows, do not bother if you are running a free operating system.
To get fastboot running you might additionally have to find the "fastboot_driver" in the download area. Put the content of the ZIP-file into the directory where you you unzipped the device driver and install it via right-clicking on the file android_winusb.inf.
Install these drivers if you are a Windows user. Under Windows 8 and newer there could be problems with installing "non signed" drivers.
Do a web/xda search to circumvent this security measure of Microsoft or do click on reboot while holding the shift-key and figure it out yourself.
http://www.flashtool.net/win8drivers.php
When you are installing: You also need to install the programs adb and fastboot.
https://forum.xda-developers.com/showthread.php?t=2317790
If you are running a free operating system: search for adb/fastboot or Android SDK in your repository and install these.
Running Linux it helps to insert the udev-rule mentioned in http://www.flashtool.net/lininstall.php otherwise you have to run esp. fastboot with root-privileges (not recommended, although the udev rule saves no punches ...)
On Android on your SONY device you have to be root to save a partition - catch 22 :crying: ...
https://en.wikipedia.org/wiki/Catch-22
Don't fear the ... / catch: For Android Marshmallow ROMs, e.g. up to version 39.0.A.3.30 of the Xperia XZ ROM, exists an exploit of the copy on write function in the Linux kernel that gets you root privileges temporarily.
On newer devices where there is no Marshmallow ROM with a vulnerable kernel available you are out of luck until another exploit is found.
Follow https://forum.xda-developers.com/crossdevice-dev/sony/universal-dirtycow-based-ta-backup-t3514236
Hint: In post #21 is described how to restore the TA (read the last sentence! -> you have to flash a stock ROM after restore).
If it does not work the first time let the tarnished bovine do its stride several times more.
Or: Repeat the process until success.
If you are already on Nougat you must downgrade the system ROM (see above) to use the exploit and backup the TA-partition.
The latest exploit that is available for devices that came out with Oreo uses a different exploit.
Search for this exploit in the specific forum or on "Sony Cross Device". If you are already on Pie you have to download an Oreo ROM for your device.
This is similar to the procedure described above that has the Xperia XZ in mind.
TA-partiton backed up?
Now the non-reversible part:
Under http://developer.sonymobile.com/unlockbootloader/ you request an unlock code.
READ, READ what SONY have written there!
- You will lose some DRM functionality: https://forum.xda-developers.com/z3-compact/general/loss-drm-keys-t2890936
- Your device will factory reset. You have a backup?
You can get the IMEI-number from the original package of your phone (if you have good eye sight and nobody swapped the boxes) or pull a tab from the side of the phone (you do not want to do that) or print a screen shot of the relevant page of your service menu or head into settings->about device->status->IMEI-Info.
You follow SONY's instructions to unlock the bootloader and hold your breath as after a long reboot everything on your device is wiped. On the newer devices you get an ugly warning "the device can't be trusted anymore".
NEVER EVER enable the MyXperia software from now on!
On some devices this in combination with an unlocked bootloader will hard brick your device.
Here was a link to fxpblog where they destroyed two devices.
Hey, you have been warned. With the TA-backup you always can return to the chicken den.
Become a "developer"
- Tap seven times on the build number of your device. (settings->device info)
- then enable "OEM unlocking" (new for the 2016 and later devices like XZ) and "USB-debugging"
You have read the SONY advice?
Next decision: Root stock ROM or go Custom Rom?
I am VERY happy with LineageOS on a Tablet Z and other devices in my household. I liked the Resurrection Remix ROM on my SAMSUNG phone.
Your mileage may vary: Testing a ROM and reversing will cost you with a proper backup minimum 4-5 hours.
If you choose a custom ROM:
- read the thread to get a hunch if you really want to install it (get over the off topic noob questions and annoying full quotes)
- Follow the instructions of the first page of the ROM-thread to install it. If you can not do this: stop or be prepared for searching and learning.
From February 2017 until May 2017 I had eXistenZ N on my Xperia XZ and like the UI tuning modifications. This "ROM" does not come pre-rooted it is a patch for the stock ROM (match the versions exactly!) that enhances the settings/look.
On SONY devices I recommend rooting stock ROMs.
Shortcut: Pie users can proceed to step 7 here
Having a custom kernel might still be advantageous for you.
You need a custom (or modified stock) kernel (aka boot image) with DM-Verity and SONY-RIC OFF.
This kernel has to be in sync with your ROM. Flashing an unsuitable kernel (e.g. MM-kernel on N-Roms) will result in a boot loop aka "soft brick".
You even can bake one yourself (no easy task) if you find/adapt the sources for your device. -> first stop SONY developer world
This is might be easy! THANKS to the efforts of @AndroPlus, @janjan and others.
You have to look into the device specific fora to find a proper kernel for your ROM-version.
They have also included many patches to improve battery life, mitigate some (e.g. camera) issues from the loss of the device keys ...
Download the kernel and recovery for your device and ROM-version and follow the kernel makers' instructions.
On devices where there is no custom kernel, you can try patching the stock kernel to switch off RIC and DM-verity. In reality behind the scenes it is a bit more than just patching (=modifying) the kernel. You also get some updated init-scripts and as a end result a new boot.img
Very useful is [PoC][Work in progress] Trim Area Proof Of Concept developed by @munjeni
These scripts not only prepare a stock kernel for rooting but also put your TA backup from above to such a use that you regain the DRM-features lost by opening the bootloader! So you do not need a custom kernel with partial DRM-fixes!
For Oreo it is more complicated (it might be easier to search for a suitable boot.img aka kernel and I have not tested it on Pie but see next step):
@serajr enhanced a script specifically for Xperia X Performance, XZ and XZs
https://forum.xda-developers.com/showpost.php?p=74724162&postcount=2793
Under Linux I had to set the executable attributes on the shell scripts and binaries (chmod +x).
You get the required kernel.elf via the tools menu in Flashtool. Dump "kernel.sin".
I started applying the scripts to the Stock ROM in May 2017 since eXistenZ ROM lagged a bit behind in security patches and Android version:
- flashed stock ROM via Flashtool or Newflasher
- prepared a patched boot image with PoC and my kernel...sin and TA.img and answered all questions with "yes" (hit return each time)
Code:
./ta_poc kernel.sin TA.img ramdisk
I am on Debian as operating system.
On Windows you just run the provided batch files and follow the instructions here and in the thread for the scripts.
- flashed the resulting boot image with fastboot flash boot boot.img and test it works. Service menu/Security: keys provided YEAH
- flash recovery and from there root with SuperSU and flash Titanium Backup
- restored my apps with their data via Titanium Backup
==============
Some hints:
==============
Most of these commands emit useful info on the command line - read it, post their error messages if you are stuck.
Version numbers of the software used speeds diagnosis of problems. Often a good advice: "Use latest version."
adb reboot bootloader or switching OFF the device and then pressing the "volume up" button while plugging the USB cable gets you into fastboot mode. You see a black screen and the blue LED light.
I normally do not flash the kernel-ZIP-file via recovery but unpack it and flash this: fastboot flash boot boot.img
To get into recovery mode:
Switch OFF your device. Press the "power" button shortly to switch ON and hold "volume down" button more than 5 seconds (or when you see the yellow LED light on some devices).
Or: adb reboot recovery
If you can not get into recovery (e.g. AndroPlus has no kernel for your latest SONY ROM):
fastboot boot TWRP_latest_version.img
I use an SD card (content there survives factory resets) and there a directory "for_recovery" well stocked with the zip-files I intend to flash. In TWRP you can tell the file manager on what storage (internal, SD-card, USB ...) it will find the flashable ZIP-files. The default is "internal".
Pressing the Power button and "volume up" for about five seconds gives you a hard reset.
Good if you are totally struck - just flash a SONY ROM for your device with Flashtool and all the wipe boxes checked or use Newflasher (overwrites most partitions including your data).
If you like to read about the haarrrdddd way:
https://forum.xda-developers.com/z4-tablet/help/enybody-root-t3154926
The first rooting of a DM-Verity secured device in 2015. Thanks to SONY for releasing source code and binaries.
Rooting - aaahh, finally
Flash the latest Magisk (up to late 2017 I used SuperSU which still works) from recovery.
https://forum.xda-developers.com/apps/magisk/official-magisk-v7-universal-systemless-t3473445
https://www.chainfire.eu/ Find the latest SuperSU from there. You will not find it there any more since Chainfire has sold the rights to the utility. I endorse Magisk since that is open sourced on GitHub.
No: flashing a custom kernel and recovery does not root your device.
For Android Pie users: On my Xperia XZ1 I can skip step 6 completely!
Just install/upgrade to the latest Pie ROM and flash Magisk and install the Magisk app.
Bonus: Debloat the device
https://forum.xda-developers.com/search/forum/2522?query=debloat
Nowadays I use a debloat script written by @serajr for my devices https://forum.xda-developers.com/xperia-xz2/development/oreo-debloat-script-v1-0-t3798979,.
I edit (comment out) the debloat_list.sh in order to keep "com.google.android.apps.maps" and "com.sonymobile.email" which I both use.
mine (you screened my script?):
flash the attached ZIP-file
View attachment xtrm_debloat.flashable_ew_2016-12.zip
found in https://forum.xda-developers.com/xperia-z5/general/discussion-bloat-sony-xperia-z5-t3518860 probably original work by @ganeshbiyer
=============================================================
With opened bootloader you will not get OTA updates any more!
You have to check with the Xperifirm program if there are newer ROMs for your device.
I have not had any problems with installing e.g. a Swiss ROM over a Central Europe. There could be some worries when switching continents.
Download the desired ROM via Xperifirm and follow the instructions of Flashtool to flash the device (over USB update = OUU :laugh.
Accept the use of the FSC script.
Repeat the steps 5 to 6(7) for any other/newer SONY ROMs you flash followed by step 4 (if necessary).
If a wipe is needed I prefer the full wipe in TWRP compared to checking the boxes in Flashtool.
Or use Newflasher without flashing userdata.sin (just delete the file) in case of an upgrade.
=============================================================
CHANGES to this Guide
2019-04-23 updated for Pie, endorsed Newflasher, added link to serjars debloat script, link ckecks
2018-02-28 clarified getting kernel.elf for self patching, some typos, link ckecks
2018-01-31 link for better suited ta_poc added, toned down AndroPlus endorsement, added Magisk
2017-06-25 added link to xpericheck (find older ROMs), added hint for restoring TA for those TLDR-guys
2017-06-02 added procedure for patching stock kernel as alternative to custom kernels
2017-02-05 added recommendation for eXistenZ N ROM
2017-01-25 new URL for SuperSU, typos
2017-01-18 corrected the advice for booting into TWRP
2017-01-17 added info on fastboot driver for Windows users
DHGE said:
No - but you can find anything here or in the devices-fora later than Z3+ or SONY-cross-device.
https://forum.xda-developers.com/crossdevice-dev/sony
Good introductory (written for devices before Z3+):
https://forum.xda-developers.com/crossdevice-dev/sony/noob-guide-to-sony-ericsson-xperia-t3209012
It is still valid but the 2015 and newer devices are not rootable anymore (as described) thanks to DM-Verity.
For rooting the current device you have to open the bootloader.
Any claims to the contrary found "on the web" are only tricks to have you install "interesting" software on a Windows PC.
Do you want root?
No:
wait for the OTA-updates from SONY
don't like waiting or want to downgrade: get flashtool http://www.flashtool.net
it comes with Xperifirm (at least for my linux machines) that finds you the latest ROM
https://forum.xda-developers.com/cr...xperifirm-xperia-firmware-downloader-t2834142
Unfortunately it does not find many older ROMs anymore so you better keep your downloads (>2 GBytes each) or find an older ROM in case you need it (xda has a search function).
Yes:
As stated above, you need to unlock the bootloader to modify the system software on your device. Fortunately SONY gives (for non-carrier-locked) devices the option to unlock the bootloader.
Check if unlocking is allowed: in the service menu (dial *#*#7378423#*#* or *#*#SERVICE#*#* ) check under "Service Info"->"Configuration" the line "Bootloader unlock allowed:"
If you read anything other than "Yes" Stop here!
No: flashing another SONY Rom ("Customized CountryX") does not help you.
Hint: there is an app "SONY service menu" in the app-repository (F-Droid or Google).
OK - you can Now it is your last chance to save your device keys or "backup the trim area partition"
You should do this if you ever want to return to a SONY "blessed" state. e.g claiming service in countries where warranty is not for devices with unlocked bootloader or you want to sell it.
Otherwise do not bother with restoring the TA-partition. Doing so after the next steps will soft brick your device.
Go to SONY's developver world http://developer.sonymobile.com
Under drivers you find the drivers for the XZ under "Downloads" http://developer.sonymobile.com/downloads/drivers/xperia-xz/
These drivers are for Windows (which version?), do not bother if you are running a free operating system.
Install these drivers if you are a Windows user. Under Windows 8+ there could be problems with installing "non signed" drivers. Do a web/xda search to circumvent this security measure of Microsoft. http://www.flashtool.net/win8drivers.php
When you are installing: You also need to install the programs adb and fastboot.
https://forum.xda-developers.com/showthread.php?t=2317790
If you are running a free operating system: search for adb/fastboot or Android SDK in your repository and install these.
Running Linux it helps to insert the udev-rule mentioned in http://www.flashtool.net/lininstall.php otherwise you have to run esp. fastboot with root-privileges (not recommended, although the udev rule saves no punches ...)
You have to be root to save a partition - catch 22 :crying: ...
For Android Marshmallow ROMs, precisely up to version 39.0.A.3.30, exists an exploit of the copy on write function in the Linux kernel that gets you root privileges temporarily.
Follow https://forum.xda-developers.com/crossdevice-dev/sony/universal-dirtycow-based-ta-backup-t3514236
If you are already on Nougat you must downgrade the system ROM (see above) to use the exploit and backup the TA-partition.
TA-partiton backed up?
Now the non-reversible part:
Under http://developer.sonymobile.com/unlockbootloader/ you request an unlock code.
READ, READ what SONY have written there!
- You will lose some DRM functionality: https://forum.xda-developers.com/z3-compact/general/loss-drm-keys-t2890936
- Your device will factory reset. You have a backup?
You can get the IMEI-number from the original package of your phone (if you have good eye sight and nobody swapped the boxes) or pull a tab from the side of the phone (you do not want to do that) or print a screen shot of the relevant page of your service menu or head into settings->about device->status->IMEI-Info.
You follow SONY's instructions to unlock the bootloader and hold your breath as after a long reboot everything on your device is wiped. On the newer devices you get an ugly warning "the device can't be trusted anymore".
Hey, you have been warned. With the TA-backup you always can return to the chicken den.
Become a "developer"
- Tap seven times on the build number of your device. (settings->device info)
- then enable "OEM unlocking" (new for the 2016 devices like XZ) and "USB-debugging"
You have read the SONY advice?
Next decision: Root stock ROM or go Custom Rom?
Well - my opinion - for the newer SONY devices I have not found a recommendable custom ROM yet. I am VERY happy with a generic CyanogenMod on a tablet Z in my household. Do not ask me about the sad story of CyanogenMod as of late 2016...
Your mileage may vary: testing a ROM and reversing will cost you with a proper backup minimum 4-5 hours.
If you choose a custom ROM:
- read the thread to get a hunch if you really want to install it (get over the off topic newbie questions)
- Follow the instructions of the first page of the ROM-thread to install it. If you can not do this stop or be prepared for searching and learning.
On SONY devices I recommend rooting stock ROMs.
You need a custom kernel (aka boot image) with DM-Verity and SONY-RIC OFF.
This kernel has to be in sync with your ROM. Flashing an unsuitable kernel (e.g. MM-kernel on N-Roms) will result in a boot loop aka "soft brck".
You even can bake one yourself (no easy task) if you find/adapt the sources for your device. -> first stop SONY developer world
This is easy! THANKS to @AndroPlus
AndroPlus has also included many patches to improve battery life, mitigate some (e.g. camera) issues from the loss of the device keys ...
https://forum.xda-developers.com/xperia-xz/development/kernel-andropluskernel-v01-t3475240
AndroPlus has kernels for other devices too. Look into the specific device forum for a custom kernel,
Download the kernel and recovery for your device and ROM-version and follow AndroPlus' instructions.
Some hints: (most of these commands emit useful info on the command line - read it, post it if you are stuck)
adb reboot bootloader or switching OFF the device and then pressing the "volume up" button while plugging the USB cable (hooked to your PC! we need DC power for all this) gets you into fastboot mode. You see a black screen and the blue LED light.
I normally unpack the kernel-ZIP-file and flash this: fastboot flash boot boot.img
You get into recovery mode on booting by pressing the "volume up" button when you see the yellow LED light.
If you can not get into recovery (e.g. AndroPlus has no kernel for your latest SONY ROM):
fastboot boot TWRP_latest_version
I use an SD card (content there survives factory resets) and there a directory "for_recovery" well stocked with the zip-files I intend to flash.
Pressing the Power button and "volume up" for about five seconds gives you a hard reset.
If you like to read about the hard way:
https://forum.xda-developers.com/z4-tablet/help/enybody-root-t3154926
The first rooting of a DM-Verity secured device in 2015. Thanks to SONY for releasing source code and binaries.
Rooting - aaahh, finally
Flash the latest SuperSU from recovery.
https://download.chainfire.eu/1019/SuperSU
No: flashing AndroPlus or TWRP does not root your device. You'll have to flash Chainfire's ZIP-file!
Bonus: Debloat the device
https://forum.xda-developers.com/search/forum/2522?query=debloat
mine (you screened my script?):
flash the attached ZIP-file
View attachment 4000189
With opened bootloader you will not get OTA (over the air - prosaic?) updates any more!
You have to check with Xperifirm if there are newer ROMs for your device.
I have not had any problems with installing e.g. a Swiss ROM over a Central Europe. There could be some worries when switching continents.
Download the desired ROM via Xperifirm and follow the instructions of flashtool to flash the device. Accept the use of the FSC script.
Repeat the steps 5 to 6(7) for SONY ROMs followed by step 4 (if necessary).
If a wipe is needed I prefer the full wipe in TWRP compared to checking the boxes in FlashTool.
Click to expand...
Click to collapse
Woaw, thanks a lot for your awesome answer !
I receive my phone today, I'll follow your instructions
@DHGE your guide is well put, and I've not had any problems so far (I used a slightly different version of the Xperia ROM since the version you specified didn't show up, but it worked just fine, is sitting on Android 6.0, and I have the TA backed up).
I've obtained the unlock code from Sony's developer site, but I've still yet to get their email with the instructions on where to shove the code. Its been about two or three hours now, and it was sent to a Gmail address (which has received other mail since). I tried generating a new code to make sure the email was right (it was), and it spat out the same unlock code, so I'm guessing its just based off of the IMEI.
Question is: what does one do with the unlock code? I can't imagine the instructions would be different for each person and am not sure how long it may take Sony to email the Gmail account...
k2trf said:
What does one do with the unlock code?
Click to expand...
Click to collapse
Follow the steps on SONY's website where you obtained the unlock code.
Look at the big link at the right bottom after all the warnings...
Somehow I missed that completely, and just latched onto it saying to wait for the instructions via email. Honestly, I don't even know why they think it necessary. Anyone playing with unlock codes damn sure better be familiar with ADB and fastboot already, or be learning as they go. >_>
Hi,
there something I can do to roll back if I didn't backed up my TA partition?
thanks
bigkekko said:
Hi,
there something I can do to roll back if I didn't backed up my TA partition?
thanks
Click to expand...
Click to collapse
Roll back to recover TA? Unfortunately not.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Code:
#include <std_disclaimer.h>
/*
* Your warranty is now void.
*
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this ROM
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at me for messing up your device, I will laugh at you.
*/
Bootimage ADB Unsecure Patcher
Android Bootimage ADB Unsecure Patcher is made to ease the development of ROMs.
Its purpose is to modify the ramdisk to set ADB into an unsecure mode,
in order to debug Android ROMs on clean / bringup boots without doing an 'eng' build.
It means adb can be used without any permissions to run logcat or other commands.
The project implements the logic from the MultiROM injection (originally by Tasssadar),
finds the bootimage of your device (boot naming similar to Chainfire's boot detection),
and applies the needed modifications to the ramdisk's default.prop configurations.
The objective of Bootimage ADB Unsecure Patcher is therefore to simply enable unsecure adb
on a regular ROM's bootimage for developers and users who would require it.
Developers no longer need to recompile a bootimage or full ROM with 'eng' pressets,
nor do users need to edit their bootimages with unsecure adb settings if they really need it.
The patcher needs to be flashed again after a ROM / bootimage update.
This is originally based on my bootimagedebuggable function from android_development_shell_tools.
The project also uses my version of libbootimg to support Sony ELF bootimages.
Bootimage Debug Addition Patcher
Another part was added to this project: Bootimage Debug Addition allows developers
to debug unbootable Android builds by providing the following items:
Complete logcat service to /data/debug.logcat.txt
Kernel messages exported to /data/debug.kernel.txt
Runtime properties to /data/debug.properties.txt
Detailed tree of / to /data/debug.roottree.txt
Rebooting to recovery and reading the file contents can help resolving issues rather than guessing.
The patcher is called "bootimage_debug_addition", while the revert is called "bootimage_debug_removal".
For builds running with enforced sepolicies, you might need to flash Universal Kernel Permissive Patcher too.
Downloads (Unlocked Bootloader only)
bootimage_adb_secure.zip : https://github.com/AdrianDC/bootimage_adb_patcher/blob/master/release/bootimage_adb_secure.zip
bootimage_adb_unsecure.zip : https://github.com/AdrianDC/bootimage_adb_patcher/blob/master/release/bootimage_adb_unsecure.zip
bootimage_debug_addition.zip : https://github.com/AdrianDC/bootimage_adb_patcher/blob/master/release/bootimage_debug_addition.zip
bootimage_debug_removal.zip : https://github.com/AdrianDC/bootimage_adb_patcher/blob/master/release/bootimage_debug_removal.zip
Other related useful projects
Universal Kernel Permissive Patcher - http://forum.xda-developers.com/-/-t3506338
Source code
Project sources - https://github.com/AdrianDC/bootimage_adb_patcher (branch master)
libbootimg sources - https://github.com/multirom-dev/libbootimg (branch master)
Bootimage ADB Unsecure Patcher created also thanks to :
- Tasssadar for the original MultiROM sources
- The MultiROM-Dev team for our evolution of MultiROM
- Chainfire for the boot detection
- Everyone involved in testing it
XDA:DevDB Information
Bootimage ADB Unsecure Patcher, Tool/Utility for the Android General
Contributors
AdrianDC
Version Information
Status: No Longer Updated
Created 2017-06-07
Last Updated 2019-08-06
Reserved
Changelog
Code:
Bootimage Debug Addition Patcher - 12/06/2017
===========================================
* Complete logcat service to /data/debug.logcat.txt
* Kernel messages exported to /data/debug.kernel.txt
* Runtime properties to /data/debug.properties.txt
* Detailed tree of / to /data/debug.roottree.txt
Bootimage Debug Addition Patcher - 11/06/2017
===========================================
* Initial public release on XDA
Bootimage ADB Unsecure Patcher - 11/06/2017
===========================================
* Update release to support Oreo system default properties
Bootimage ADB Unsecure Patcher - 05/06/2017
===========================================
* Initial public release on XDA
Nice work, any chance adding support for MTK devices with /dev/bootimg path? The boot detection by chainfire doesn't detect it. Any other information you need I can provide.
kirito9 said:
Nice work, any chance adding support for MTK devices with /dev/bootimg path? The boot detection by chainfire doesn't detect it. Any other information you need I can provide.
Click to expand...
Click to collapse
I never had to work on MTK devices for now.
Is it only a question of different path, with a regular !ANDROID bootimage structure, or something else specifically to handle ?
If only the path, can easily be added. Please try the versions I pushed on a separate "staging" branch and let me know.
If valid, I can do the same for Kernel Permissive Patcher too.
AdrianDC said:
I never had to work on MTK devices for now.
Is it only a question of different path, with a regular !ANDROID bootimage structure, or something else specifically to handle ?
If only the path, can easily be added. Please try the versions I pushed on a separate "staging" branch and let me know.
If valid, I can do the same for Kernel Permissive Patcher too.
Click to expand...
Click to collapse
It's the path and also requires an mtk header appended to the boot.img or it won't boot. I'll try the separate versions.
AdrianDC said:
I never had to work on MTK devices for now.
Is it only a question of different path, with a regular !ANDROID bootimage structure, or something else specifically to handle ?
If only the path, can easily be added. Please try the versions I pushed on a separate "staging" branch and let me know.
If valid, I can do the same for Kernel Permissive Patcher too.
Click to expand...
Click to collapse
The path you added helped me figure out how to allow Chainfire's boot detection can be used to detect the dev/bootimg. I had to modify it like bootimg BOOTIMG as I saw the others like that.
So boot image detection is working but I don't think your binary file can unpack the MTK bootimage or it could be another error. There's not enough logging to say at which point the script fails.
Magisk also uses Chainfire's boot detection so I was also able to add the dev/bootimg path to the Magisk script and it got to the point of the unpacking as well. It also doesn't support this MTK boot.img.
@osm0sis was able to use his mkmtkhdr binary to support the unpacking/repacking of this particular boot.img. Maybe implementing in some way can add support for my device :fingers-crossed:.
I was expecting this.
It means (without much surprise) that our MultiROM libbootimg was never ported for and used on an MTK device.
A year ago I added full support for Sony ELF bootimages structures.
You might want to look into it and see if you can identify what's needed for MTK.
However if it's a lot to do / change, as we never needed it and none of us owning an MTK,
I'm not sure it'd be done, especially only for a Dev helper tool rather than MultiROM itself.
At least you can check what I do in my scripts and apply the same thing to a decompiled mtk bootimage.
AdrianDC said:
I was expecting this.
It means (without much surprise) that our MultiROM libbootimg was never ported for and used on an MTK device.
A year ago I added full support for Sony ELF bootimages structures.
You might want to look into it and see if you can identify what's needed for MTK.
However if it's a lot to do / change, as we never needed it and none of us owning an MTK,
I'm not sure it'd be done, especially only for a Dev helper tool rather than MultiROM itself.
At least you can check what I do in my scripts and apply the same thing to a decompiled mtk bootimage.
Click to expand...
Click to collapse
MTK-support would be great..
AdrianDC said:
I was expecting this.
It means (without much surprise) that our MultiROM libbootimg was never ported for and used on an MTK device.
A year ago I added full support for Sony ELF bootimages structures.
You might want to look into it and see if you can identify what's needed for MTK.
However if it's a lot to do / change, as we never needed it and none of us owning an MTK,
I'm not sure it'd be done, especially only for a Dev helper tool rather than MultiROM itself.
At least you can check what I do in my scripts and apply the same thing to a decompiled mtk bootimage.
Click to expand...
Click to collapse
If it isn't a challenge then it isn't fun . I'll try to see if I can follow what was done for the libbootimg and see if I can get what is needed for MTK.
Also the libbootimg sources in the first post link needs changing to this libbootimg.
this is great its making life easier
kirito9 said:
The path you added helped me figure out how to allow Chainfire's boot detection can be used to detect the dev/bootimg. I had to modify it like bootimg BOOTIMG as I saw the others like that.
So boot image detection is working but I don't think your binary file can unpack the MTK bootimage or it could be another error. There's not enough logging to say at which point the script fails.
Magisk also uses Chainfire's boot detection so I was also able to add the dev/bootimg path to the Magisk script and it got to the point of the unpacking as well. It also doesn't support this MTK boot.img.
@osm0sis was able to use his mkmtkhdr binary to support the unpacking/repacking of this particular boot.img. Maybe implementing in some way can add support for my device :fingers-crossed:.
Click to expand...
Click to collapse
MTK boot.img headers are only for old mt65xx, that's not needed on newer mtk platforms I think you should consider making a mt65xx specific version of this tool (great tool btw, was looking for something similar ) because it's only (no offense) useful for a couple people still working on mt65xx (and mt65xx with 3.4 will probably never see Ng/Oc due to the egl/mali blobs crashing asap as devices enter suspend).
AdrianDC said:
I was expecting this.
It means (without much surprise) that our MultiROM libbootimg was never ported for and used on an MTK device.
A year ago I added full support for Sony ELF bootimages structures.
You might want to look into it and see if you can identify what's needed for MTK.
However if it's a lot to do / change, as we never needed it and none of us owning an MTK,
I'm not sure it'd be done, especially only for a Dev helper tool rather than MultiROM itself.
At least you can check what I do in my scripts and apply the same thing to a decompiled mtk bootimage.
Click to expand...
Click to collapse
Mtk got a lot better, kirito has a mt65xx device as far as I know, most if not all platforms after mt6592 (meizu mx4 period) have vanilla boot.img, I'm pretty sure I saw some mtk devices (mt67xx) use MultiROM, so there shouldn't be any need for modifications (except for old undev'ed mt65xx SoCs)
AdrianDC said:
I was expecting this.
It means (without much surprise) that our MultiROM libbootimg was never ported for and used on an MTK device.
A year ago I added full support for Sony ELF bootimages structures.
You might want to look into it and see if you can identify what's needed for MTK.
However if it's a lot to do / change, as we never needed it and none of us owning an MTK,
I'm not sure it'd be done, especially only for a Dev helper tool rather than MultiROM itself.
At least you can check what I do in my scripts and apply the same thing to a decompiled mtk bootimage.
Click to expand...
Click to collapse
Can you explain in simple language
What is this for.
Someone suggest me to flash this as my phone (codename merlin) was not booting after flashing somefeak kernel
Moyster said:
Mtk got a lot better, kirito has a mt65xx device as far as I know, most if not all platforms after mt6592 (meizu mx4 period) have vanilla boot.img, I'm pretty sure I saw some mtk devices (mt67xx) use MultiROM, so there shouldn't be any need for modifications (except for old undev'ed mt65xx SoCs)
Click to expand...
Click to collapse
Yes your correct 98% of MTK devices now use the standard format boot.img.
There are exceptions like the Lenovo TAB 2 A10-70 but it's a pretty easy process convert the old format .img to the newer one and they still work just fine on device. Converting my Sony C4 from a 64bit .ELF to a standard format boot.img was a little more challenging but I got there in the end.
If you need any help @kirito9 converting your boot.img to the standard format drop me a PM :good:
bigrammy said:
Yes your correct 98% of MTK devices now use the standard format boot.img.
There are exceptions like the Lenovo TAB 2 A10-70 but it's a pretty easy process convert the old format .img to the newer one and they still work just fine on device. Converting my Sony C4 from a 64bit .ELF to a standard format boot.img was a little more challenging but I got there in the end.
If you need any help @kirito9 converting your boot.img to the standard format drop me a PM :good:
Click to expand...
Click to collapse
Ha, sorry I didn't mention mtk tablets because I'm so lost with their mt81xx / mt76xx mt89xx, tho a10-70 ran with a mt8165 which is the 2014 generation (around mt6752 release, then they later refreshed their socs and release the mt6753/35 in 2015).
Most if not all mtk SoCs released after 2015/mt67xx work fine on vanilla boot.img, mt65xx and mt81xx (which are =<2014), still needs it
Since OP tool works fine, the only "really needed" thing is a small software to convert vanilla boot.img <-> mediatek headers boot.img, this way if you want to use OP tool with an old mediatek kernel, all it takes is to pre-convert / reconvert (actually, using any kitchen supporting mtk headers to unpack / repack old mtk kernels works just fine, not sure if there's a need for a dedicated tool )
Moyster said:
Ha, sorry I didn't mention mtk tablets because I'm so lost with their mt81xx / mt76xx mt89xx, tho a10-70 ran with a mt8165 which is the 2014 generation (around mt6752 release, then they later refreshed their socs and release the mt6753/35 in 2015).
Most if not all mtk SoCs released after 2015/mt67xx work fine on vanilla boot.img, mt65xx and mt81xx (which are =<2014), still needs it
Since OP tool works fine, the only "really needed" thing is a small software to convert vanilla boot.img <-> mediatek headers boot.img, this way if you want to use OP tool with an old mediatek kernel, all it takes is to pre-convert / reconvert (actually, using any kitchen supporting mtk headers to unpack / repack old mtk kernels works just fine, not sure if there's a need for a dedicated tool )
Click to expand...
Click to collapse
You sure do your homework Moyster 100% correct :laugh:
I agree the OP should not have to alter their code to support the <2014 boot.img when it's so easy to convert it to a standard/vanilla format. :good:
:highfive:
Necro post!
Is anybody still using this for modern devices (Oreo) and it still works for adb on boot for initial bring up? Would save me reinventing the wheel if so, I have some porting work ahead of me.
CosmicDan said:
Necro post!
Is anybody still using this for modern devices (Oreo) and it still works for adb on boot for initial bring up? Would save me reinventing the wheel if so, I have some porting work ahead of me.
Click to expand...
Click to collapse
I always am while doing debugging & testings.
I released an update today on something I'm currently working upon, it adds Oreo support for most of the "recent" devices,
feel free to go along and test it, and to participate in the sources if you need something additional.
I also added a new part to the project, meant to ease unbooting builds debugging by automatically logging to /data/logcat.txt as a service.
We often do it manually for development purposes but let's do it automatically for anyone who would need it.
AdrianDC said:
I always am while doing debugging & testings.
I released an update today on something I'm currently working upon, it adds Oreo support for most of the "recent" devices,
feel free to go along and test it, and to participate in the sources if you need something additional.
I also added a new part to the project, meant to ease unbooting builds debugging by automatically logging to /data/logcat.txt as a service.
We often do it manually for development purposes but let's do it automatically for anyone who would need it.
Click to expand...
Click to collapse
Cool stuff. I also compiled a "god mode" adbd binary that I can inject to initramfs, the idea being that it runs as root even on user builds, but for some reason it doesn't work on Oreo anymore. Might just need to update my sources for 8.1 or something, or I missed a compiler flag somewhere, but I'm thinking the init might not be actually running adbd in the right permissions. Tried anything like that?
Moto g5 plus, stock rom 7.0 + magisk 16.6. When connecting I get error:
error: device unauthorized.
This adb server's $ADB_VENDOR_KEYS is not set
Try 'adb kill-server' if that seems wrong.
Otherwise check for a confirmation dialog on your device.
@CosmicDan: Would you mind uploading a patched standalone adbd god mode binary? I Googled your name like "adbd god cosmicdan", only found some references on XDA and GitHub, but they appear to be device-specific. Would such a binary be universal (work on all commonly used CPU architectures/Android versions)? I think your patch is for ARM64, and I do own 2 ARM64 devices, but also a handful of older phones that are armv7a/32 bit.
Thanks!
Sony "MediaTek SoC" Cross-Device Development: C4 C5 XA XA1 L1 E5 M5 and others
Hi Sony MediaTek SoC Device owners This is a WIP and I stand to be corrected by any dev regarding my grasp or explanation of things.
In this OP I will share all what I know or think I know about the Sony Device line that use MediaTek SoC's (System on Chip).
In my opinion most users will fall into one of two camps
Camp 1. Those who have always used Sony Devices and purchased one of these MediaTek based phones probably due to the price point.
Camp 2. Those who are well use to MediaTek based phones typically having used or owned previous cheaper Chinese branded devices. (I am in this camp mainly )
Camp 1. users will be well use to all the terms used in association with Sony device development.
Camp 2. users will be baffled and left scratching their heads saying "what" "what's that" "how do you mean" "I don't get it"
So for the benifit of Camp 2. users and noobs I present a list of the most often used Sony Terms and tools along with a very brief explanation and links where applicable.
1 FlashTool (meaning a Sony Specific tool to flash firmware packages using Sony's S1 Protocols in our case (http://www.flashtool.net/index.php Note: the Warning to C4/C5 users in the Downloads section. To use that version you need a custom FSC if one exists if not then there is a older version which is safe to use but it does have some limitation but more on this later)
2 TA (meaning Trim Area This is a impotant /partition and contains info specific to the device like IMEi, Serial Number, DRM keys, also Keys for Sony specific stuff which are called "Proprietary's" (more on this later)
3 FOTAKERNEL (meaning a For Over The Air Kernel a /partition basically this is the /recovery partition
4 .sin (meaning a Sony Specific archive tool kinda like .zip When you get stock sony firmware it comes packaged in .sin archives eg: system.sin boot.sin fotakernel.sin these .sin's all contain Sony Signatures i believe
5 .elf (meaning Sony's Preferred Format for the boot and recovery instead of the standard .img the .elf's are contained within the .sin's as explained above.
6 XperiFirm (meaning a firmware downloader and extraction Tool which allows you to choose your device and any Stock Firmware package for it. It will then download the firmware and automatically extract the file's contained within the .sin's. Stand Alone XperiFirm Thread Here This Tool is also integrated in to FlashTool which is at the top of this list XperiFirm is denoted within FlashTool by the XF tab/button at the top.
The following Info and Tools below are Mainly For Dev's. Some of the Tool's are beta and untested so ONLY experienced dev's should consider using them. When you brick a Sony it's usually just that a brick Unlike other MediaTek devices which are pretty unbrickable :good:
7 UnSIN (meaning a Tool by the dev of XperiFirm and is a stand alone tool for unsining .sins and would be most useful to dev's. (Note: for dev's it works using "mono" on Linux systems although I have to do a tune2fs on the system.ext4 before it can be extracted this could be just a glitch in my setup on yours it may well work just fine. ) UnSIN Thread Here
8 AIK (meaning Android Image Kitchen by @osm0sis this tool will unpack the .elf's and repack them as AOSP .img's by default :good: I did notice the default pagesize seems to be 4096 but most if not all the MediaTek .img's I come across seem to use 2048 so I usually change this from the default 4096. Main Thread HERE
9 Trim Area Proof Of Concept (meaning a tool by @munjeni to replace DRM fix likley this tool needs to be tested/adapted to MediaTek devices. Main thread HERE
10 Xflasher (meaning a tool again by @munjeni This tool is a cmdline tool and can flash devices using the S1 protocol in download mode. I tested this on the L1 Flashing only the system, boot, recovery etc but not the "boot delivery" preloader lk etc and it worked well but further testing is needed regarding the "boot delivery" Main Thread HERE
11 Unpack any Sony firmware (meaning a tool again by @munjeni Main Thread Here
To be continued..............
This is a draft OP so may change thing around depending on comments and certain dev's etc etc
Maybe a meeting point for Sony MediaTek SoC Device to meet share and get help from across the different device threads.
There is 98% + commonality between all our devices so It make sense to share and swap info in one common thread.
I am pretty sure what works for one device will most likely work for another.
Comments welcome.
@DerTeufel1980
Road to full Root
Since I am asked many times here is a super quick bullet listed workflow.1. is needed as there is no workaround for this at the moment!!
1. Unlock Bootloader (Get a backup of /ta partition first if possible just search xda for mtk-su )
2. Extract the stock sony boot/kernel.sin to .elf format. (Tools listed in OP)
3. Convert the boot/kernel.elf to .img (Tools listed in OP)
4. Patch the .img with Magisk (Search xda)
5. Flash to the device. (Fastboot, TWRP if you have one or use dd method with tmp root)
Hey mate! Great thread!
I need some help with my Xperia L3..
I backed up the TA partition with dd and I want to restore it now. How I can do it?
Thanks!
Rortiz2 said:
Hey mate! Great thread!
I need some help with my Xperia L3..
I backed up the TA partition with dd and I want to restore it now. How I can do it?
Thanks!
Click to expand...
Click to collapse
Sorry for the mega late reply but I did not get any notification
I guess you probably sorted it already but just incase see this post here https://forum.xda-developers.com/showpost.php?p=69971015&postcount=16 as that pretty much covers it.
Note you must reflash 100% Stock ROM when using the restored TA.
Also check this thread HERE if you want to run none stock.
Note I have not tested any of these myself so please ask any specific questions in the relative threads.
:highfive: :highfive:
Assurance Wireless
KonnectONE Moxee m2160
4G-LTE Smartphone
Model No. MH-T6000
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Rooting Guide
OVERVIEW:
This guide outlines simplified instructions for rooting the Assurance Wireless Moxee MH-T6000 4G-LTE smartphone. To cater this guide to new and inexperienced members, I have provided a stock boot image pre-patched with the Magisk v26.1 systemless root solution.
PREREQUISITES:
First and foremost, you need an unlocked bootloader. If your bootloader is not yet unlocked, complete that task and then return here. XDA hosts a plethora of how-to guides on standard bootloader unlocking. You will also need a Windows PC or laptop running the Minimal ADB & Fastboot Tools (link provided below). It should be noted that this guide can be carried out on a Mac or Linux computer as well; however, for purposes of this guide, I am focusing solely on a Windows setup. It is highly recommended that your device be running firmware build number MH-T6000V1.0.OB010, with the March 5, 2023 security patch level. As OTA updates are rolled out for this device, I will try to keep this guide updated with a patched boot image that corresponds with the latest firmware build.
Finally, you will need the factory supplied, or a quality equivalent USB-A to USB-C charging/syncing cable.
DISCLAIMER:
By proceeding further, you are assuming sole responsibility for the integrity and operability of your smartphone. Rooting your device is a task that carries with it the inherent risk of bricking or otherwise rendering your phone inoperable. While this guide has been thoroughly tested on my own device, you have been warned. Proceed at your own risk.
INSTRUCTIONS:
Download the ADB & Fastboot tools from the link below and install the program on your PC or laptop;
Open your Windows File Explorer, navigate to your C: drive, Program Files x86, and locate the Minimal ADB & Fastboot folder. Copy this folder and paste it to your desktop. (This step is not required, but is recommended for easier access of the ADB & Fastboot path);
Download the patched boot image from the below link and save the image in your ADB & Fastboot folder. Note: the filename for the patched boot image is patched_boot.img. The flashing commands assume that you leave the filename unchanged;
Boot your phone into fastboot mode by first powering your device off, and then holding the power and volume down keys simultaneously until fastboot mode appears on your device display;
Connect your smartphone to your Windows computer using the factory supplied or a quality equivalent USB-A to USB-C charging/syncing cable;
Open your ADB & Fastboot folder and double click cmd-here.exe to open a command window. Execute this command to verify a proper fastboot connection:
Code:
fastboot devices
If properly connected, the command window will return an alphanumeric string consistent with your device serial number;
Once a proper connection has been verified, execute this command:
Code:
fastboot flash boot patched_boot.img
Now execute:
Code:
fastboot reboot
Upon reboot, open your app drawer and tap on the Magisk app or its placeholder stub. Ensure you are connected to the internet, grant any permissions, and follow any prompts given by Magisk to update to the full version in order to complete the root environment setup. Magisk may reboot your device during this process.
That's it. You're now rooted via the Magisk v26.1 systemless root solution.
IMPORTANT NOTE:
In the unfortunate event that you get stuck in a boot loop or brick your device using this guide, my guide on unbricking this smartphone will get you back up and running fairly quickly. This guide can be used to restore both soft bricked and hard bricked devices. You can then return here and give rooting another go.
Moxee MH-T6000 Unbricking GuideDOWNLOADS:
• Minimal ADB & Fastboot v1.4.3
• Magisk Patched Boot Image
THANKS & MENTIONS:
A huge thanks and shout-out to @omb714.1980 for donating the Moxee smartphone that made this rooting guide possible. You are a scholar and a gentleman, good sir. Thanks also to KonnectONE support specialist Faith Flores for releasing to me the factory firmware for this device.
Viva La Android said:
Assurance Wireless
Moxee MH-T6000 4G-LTE
View attachment 5893661
Rooting Guide
OVERVIEW:
This guide outlines simplified instructions for rooting the Assurance Wireless Moxee MH-T6000 4G-LTE smartphone. To cater this guide to new and inexperienced members, I have provided a stock boot image pre-patched with the Magisk v26.1 systemless root solution.
PREREQUISITES:
First and foremost, you need an unlocked bootloader. If your bootloader is not yet unlocked, complete that task and then return here. You will also need a Windows PC or laptop running the Minimal ADB & Fastboot Tools (link provided below). It should be noted that this guide can be carried out on a Mac or Linux computer as well; however, for purposes of this guide, I am focusing solely on a Windows setup. It is highly recommended that your device be running firmware build number MH-T6000V1.0.OB010, with the March 5, 2023 security patch level. Finally, you will need the factory supplied, or a quality equivalent USB-A to USB-C charging/syncing cable.
DISCLAIMER:
By proceeding further, you are assuming sole responsibility for the integrity and operability of your smartphone. Rooting your device is a task that carries the inherent risk of bricking or otherwise rendering your phone inoperable. While this guide has been thoroughly tested on my own device, you have been warned. Proceed at your own risk.
INSTRUCTIONS:
Download the ADB & Fastboot tools from the link below and install the program on your PC or laptop;
Open your Windows File Explorer, navigate to your C: drive, Program Files x86, and locate the Minimal ADB & Fastboot folder. Copy this folder and paste it to your desktop. (This step is not required, but is recommended for easier access of the ADB & Fastboot path);
Download the patched boot image from the below link and save the image in your ADB & Fastboot folder;
Boot your phone into fastboot mode by first powering your device off, and then holding the power and volume down keys simultaneously until fastboot mode appears on your device display;
Connect your smartphone to your Windows computer using the factory supplied or a quality equivalent USB-A to USB-C charging/syncing cable;
Open your ADB & Fastboot folder and double click cmd-here.exe to open a command window. Execute this command to verify a proper fastboot connection:
Code:
fastboot devices
If properly connected, the command window will return an alphanumeric string consistent with your device serial number;
Once a proper connection has been verified, execute this command:
Code:
fastboot flash boot patched_boot.img
Now execute:
Code:
fastboot reboot
Upon reboot, open your app drawer and tap on the Magisk app or its placeholder stub. Ensure you are connected to the internet, grant any permissions, and follow any prompts given by Magisk to update to the full version in order to complete the root environment setup. Magisk may reboot your device during this process.
That's it. You're now rooted via the Magisk v26.1 systemless root solution.
DOWNLOADS:
• Minimal ADB & Fastboot v1.4.3
• Magisk Patched Boot Image
THANKS & MENTIONS:
A huge thanks and shout-out to @omb714.1980 for donating the Moxee smartphone that made this rooting guide possible. You are a scholar and a gentleman, good sir. Thanks also to the KonnectONE support team for releasing to me the factory firmware for this device.
Click to expand...
Click to collapse
Lol. Now you post this. After unsuccessfully scouring the internet for the stock firmware. I finally did the same as you and simply reached out to konnectone and asked for it. I just came here to see if there was anyone here that is by far more knowledgeable than myself (not hard) interested to have the firmware and would post a guide like this one. Well done!
Would you happen to have a twrp recovery compiled for this device by chance? Or if not but planning on it would you let me know please. I would appreciate it!
scottfan81 said:
Lol. Now you post this. After unsuccessfully scouring the internet for the stock firmware. I finally did the same as you and simply reached out to konnectone and asked for it. I just came here to see if there was anyone here that is by far more knowledgeable than myself (not hard) interested to have the firmware and would post a guide like this one. Well done!
Would you happen to have a twrp recovery compiled for this device by chance? Or if not but planning on it would you let me know please. I would appreciate it!
Click to expand...
Click to collapse
I just got KonnectONE to agree to release firmware a couple of days before you mentioned having firmware. It's been a long wait indeed.
I don't have source code to compile TWRP; only the firmware. I will be attempting to port a TWRP build for this phone very soon. My legal battle with KonnectONE was in regards to source code under the General Public License 2.0. Because they were ultimately unable to provide kernel source, their legal team and support department finally acquiesced to provide firmware to device owners upon written request. I compromised for the firmware release, but was not able to get kernel source code for building TWRP. I am pretty confident that a ported TWRP can be ironed out as a stable build. I already have the base build selected.
Thank you so much! I have 3 of these devices and been waiting lol. I see the stock kernel has hot-plug . What's some good tuning profiles? I tried to debloat permanently with LP but it didn't work. I think it's read-only so I flashed the magisk overlay for rw and going to play. We definitely need TWRP! I see a port may be in the works. Awesome. Thanks again
Viva La Android said:
I just got KonnectONE to agree to release firmware a couple of days before you mentioned having firmware. It's been a long wait indeed.
I don't have source code to compile TWRP; only the firmware. I will be attempting to port a TWRP build for this phone very soon. My legal battle with KonnectONE was in regards to source code under the General Public License 2.0. Because they were ultimately unable to provide kernel source, their legal team and support department finally acquiesced to provide firmware to device owners upon written request. I compromised for the firmware release, but was not able to get kernel source code for building TWRP. I am pretty confident that a ported TWRP can be ironed out as a stable build. I already have the base build selected.
Click to expand...
Click to collapse
They never replied when I emailed them about it several months ago . This is so awesome. I got rid of most of the lag with kernel manager. Kudos
Argonon said:
They never replied when I emailed them about it several months ago . This is so awesome. I got rid of most of the lag with kernel manager. Kudos
Click to expand...
Click to collapse
Several months ago they weren't releasing firmware to the public. I got it released by battling with them over open source code and I ultimately compromised for factory firmware. It was only recently made public.
Yeah I've noticed a nice performance boost too with some debloating and sone kernel tweaks. I'm using EX Kernel Manager. Keep in mind this device uses dynamic partitioning (super.img). As such, even with root, it isn't always possible to mount /system r/w. I extracted the super.img on a PC and then mounted /system, /vendor and /product, debloated, and then repacked and reflashed super img.
Awesome. I don't have a good pc now unfortunately. I do have viper4android repackaged version with driver and effects pre-installed. I used smart pack kernel manager to tweak kernel. The device is very useable now! I have a Blu View 3 android 11 mtk device id love to root but can't even unlock bootloader. Maybe I should look into emailing them
Argonon said:
Awesome. I don't have a good pc now unfortunately. I do have viper4android repackaged version with driver and effects pre-installed. I used smart pack kernel manager to tweak kernel. The device is very useable now! I have a Blu View 3 android 11 mtk device id love to root but can't even unlock bootloader. Maybe I should look into emailing them
Click to expand...
Click to collapse
BLU won't unlock your bootloader. It is locked per contractual agreement with the branded carrier of the phone. However, if it's MediaTek, you may be able to use MTK Client to exploit the bootloader into an unlocked state.
Viva La Android said:
Several months ago they weren't releasing firmware to the public. I got it released by battling with them over open source code and I ultimately compromised for factory firmware. It was only recently made public.
Yeah I've noticed a nice performance boost too with some debloating and sone kernel tweaks. I'm using EX Kernel Manager. Keep in mind this device uses dynamic partitioning (super.img). As such, even with root, it isn't always possible to mount /system r/w. I extracted the super.img on a PC and then mounted /system, /vendor and /product, debloated, and then repacked and reflashed super img.
Click to expand...
Click to collapse
Would you plz share your super.img ? I'm on latest firmware and have attached screenshot of build etc.... I understand if you can't or don't want to. Can I pull mine since I'm rooted? Problem is I have a old Chromebook that I installed endeavor os on its arch based Linux but I don't have much hard drive space to do work
Viva La Android said:
Several months ago they weren't releasing firmware to the public. I got it released by battling with them over open source code and I ultimately compromised for factory firmware. It was only recently made public.
Yeah I've noticed a nice performance boost too with some debloating and sone kernel tweaks. I'm using EX Kernel Manager. Keep in mind this device uses dynamic partitioning (super.img). As such, even with root, it isn't always possible to mount /system r/w. I extracted the super.img on a PC and then mounted /system, /vendor and /product, debloated, and then repacked and reflashed super img.
Click to expand...
Click to collapse
Would you plz share your super.img ? I'm on latest firmware and have attached screenshot of build etc.... I understand if you can't or don't want to. Can I pull mine since I'm rooted? Problem is I have a old Chromebook that I installed endeavor os on its arch based Linux but I don't have much hard drive space to do work
Viva La Android said:
I just got KonnectONE to agree to release firmware a couple of days before you mentioned having firmware. It's been a long wait indeed.
I don't have source code to compile TWRP; only the firmware. I will be attempting to port a TWRP build for this phone very soon. My legal battle with KonnectONE was in regards to source code under the General Public License 2.0. Because they were ultimately unable to provide kernel source, their legal team and support department finally acquiesced to provide firmware to device owners upon written request. I compromised for the firmware release, but was not able to get kernel source code for building TWRP. I am pretty confident that a ported TWRP can be ironed out as a stable build. I already have the base build selected.
Click to expand...
Click to collapse
I have 3 of these devices. I surly can test TWRP port if needed
Argonon said:
Would you plz share your super.img ? I'm on latest firmware and have attached screenshot of build etc.... I understand if you can't or don't want to. Can I pull mine since I'm rooted? Problem is I have a old Chromebook that I installed endeavor os on its arch based Linux but I don't have much hard drive space to do work
I have 3 of these devices. I surly can test TWRP port if needed
Click to expand...
Click to collapse
Sure. I don't mind sharing my super.img. I'll need to upload it and then I'll message you a link. It's pretty much exactly 2.5 GB in file size, so I'll first compress it to a zip before uploading.
The edited one. Just clarifying so appreciated
Argonon said:
The edited one. Just clarifying so appreciated
Click to expand...
Click to collapse
I don't yet have all my mods made to the /super partition in that regard. Having encountered some force close issues with certain apps, I debloated from scratch and and have now begun my kernel tweaks and edits to the.varuous .prop files. So when finished, I'll share both my boot.img and super.img.
Just the stock super.img would be fine then. I think I can figure how to decompile, debloat and recompile then flash.
Argonon said:
Just the stock super.img would be fine then. I think I can figure how to decompile, debloat and recompile then flash.
Click to expand...
Click to collapse
MH-T6000 super.img unmodified
I was experimenting and flashed the super.img with dsu side loader apk as a gsi lol. The app description said can replace various partitions and I was just trying to get system rw on the dsu loader. I know that makes no sense. What windows 11 compatible software do you recommend to unpack, repack etc? I see a few magisk modules but not quite sure how to use. Like ro2rw magisk module
Viva La Android said:
MH-T6000 super.img unmodified
Click to expand...
Click to collapse
Thank you!
Argonon said:
Thank you!
Click to expand...
Click to collapse
When I have completed debloating, kernel tweaks and .prop files edits of the OS, I'll share my modified super.img and boot.img. I have a TWRP v3.6.0 port build that is currently booting properly on this phone. But, I have bugs to work out on logical partition mounting, as well as the backup & restore functionality.
Argonon said:
I was experimenting and flashed the super.img with dsu side loader apk as a gsi lol. The app description said can replace various partitions and I was just trying to get system rw on the dsu loader. I know that makes no sense. What windows 11 compatible software do you recommend to unpack, repack etc? I see a few magisk modules but not quite sure how to use. Like ro2rw magisk module
Click to expand...
Click to collapse
Check out CRB Android Kitchen here on XDA. Great for unpacking / repacking partition images, including super.img.
Viva La Android said:
When I have completed debloating, kernel tweaks and .prop files edits of the OS, I'll share my modified super.img and boot.img. I have a TWRP v3.6.0 port build that is currently booting properly on this phone. But, I have bugs to work out on logical partition mounting, as well as the backup & restore
Click to expand...
Click to collapse
Have you had anymore luck with this