Develop Bugs

{ROOT} {100% Working} Vzw Desire 526 Perm Root {Unlocked Boot-Loader Required}

How To Get Permanent Root
This is a workaround until I can compile a Bootable Kernel
First of all say thanks to @Captain_Throwback !!
He was the original creator of the TWRP Recovery for the Desire 626s.
I have taken his TWRP recovery for the 626s, unpacked it and ported in some of the Desire 526 recovery image.
Kinda a cracked up way of doing this but hey ( It Works)
Step #1
Unlock Your Boot-Loader !!! (currently accomplished with a Java Card / HTC Service Tool)
Even with the card you could run into trouble with unlocking the boot-loader.
There is no switch to Enable OEM Unlock available in the Developer Options.
Here is a work-around for that.
Step #1-A
Open up terminal shell on a computer and pull the frp image from the device. (Temp Root Required)
Code:
dd if=/dev/block/bootdevice/by-name/frp of=/sdcard/frp.img
Terminal Output
[email protected]_a13wlpp:/ #dd if=/dev/block/bootdevice/by-name/frp of=/sdcard/frp.img <
1024+0 records in
1024+0 records out
524288 bytes transferred in 0.364 secs (1440351 bytes/sec)
[email protected]_a13wlpp:/ #
Pull the frp.img to the computer.
If you are still in adb shell.
Code:
exit
exit
Then from the normal command line
Code:
adb pull /sdcard/frp.img
Terminal Output
f=/dev/block/bootdevice/by-name/frp of=/sdcard/frp.img <
1024+0 records in
1024+0 records out
524288 bytes transferred in 0.364 secs (1440351 bytes/sec)
[email protected]_a13wlpp:/ # exit
[email protected]_a13wlpp:/ $ exit
[email protected]:~$ adb pull /sdcard/frp.img
2758 KB/s (524288 bytes in 0.185s)
[email protected]:~$
Now open the frp.img file in a hex editor. Like HXD in windows.
Go to the last line of the file.
Change the very last 00 to 01 and save the file.
Reference the screen shots below.
Factory FRP
{
"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"
}
Patched FRP
Flash the patched frp.img to the device.
Back to the terminal.
Code:
adb push frp.img /sdcard/frp.img
Code:
adb shell
su
dd if=/sdcard/frp.img of=/dev/block/bootdevice/by-name/frp
If you have completed this now your clip can unlock the boot-loader
In case your wondering this will also work on a boot loader locked device. It will get you as far as being able to get a unlock token from fastboot using Fastboot oem get_identifier_token WITH THE DEVICE IN DOWNLOAD MODE
Unfortunatly HTC-DEV still will not give you the UNLOCK TOKEN yet. The pg2fs partition needs an edit then htc dev will generate a good code. Problem is without clip you cannot modify the pg2fs image. Allthough I am working on it.
STEP #2 ( Get Perm Root !! )
Download the Patched TWRP and SuperSu
The 2 files are attached to the thread. Unzip the TWRP-No-Touch.img.zip Do not unzip the Super.zip.
Copy the super.zip to the device sdcard. Use file explorer or terminal.
Code:
adb push super.zip /sdcard/super.zip
Flash the TWRP Recovery to the device.
reboot to download mode
Code:
adb reboot download
Flash the recovery
Code:
fastboot flash recovery Twrp-526-NO-TOUCH.img
Boot into TWRP Recovery
Code:
fastboot boot recovery
DON'T PANIC !! Yes your right......The touch screen is not working!!!
I need to compile a custom kernel to get TWRP working Right.
I have compiled the kernel but it isn't booting right yet. That's why I figured out this work around for now.
So Now What ???
No worries....Even though we can't access the TWRP commands from the touch screen LETS NOT FORGET.........
We can use the command line :highfive:
Open up terminal on your computer.
If it's not already open.
Go into the shell.
Code:
adb shell
No need to type su cause in case you didn't notice we are already ROOT. "#"
So to install SuperSu (or any other zip package) we do this.
#1 Mount the system partition.
Code:
mount -o rw -t ext4 /dev/block/mmcblk0p62 /system
#2 Tell TWRP what we want it to do one stap at a time
Set device to boot into recovery upon reboot.
Code:
echo 'boot-recovery ' > /cache/recovery/command
Tell TWRP to install SuperSu when it boots.
Code:
echo '--update_package=/sdcard/super.zip' >> /cache/recovery/command
Reboot the recovery to install the SuperSu.
Code:
reboot recovery
Now you will see TWRP boot back up and when it boots up it will install the zip package.
Congratulations you are now one of the first peoples to have a fully rooted Verizon Desire 526. :laugh::silly:
Lets get busy boys !!!! We need to get this boot loader unlocked for the rest of the community.
It's all about the pg2fs partition. If we can find a way to write to it with s-on and boot loader locked then we can unlock all boot-loaders

Glad to see sum positive progress in the right direction....

BigCountry907 ,
Since the MarshaMallow update gives us the developer options OEM unlock switch, shouldn't we just update to it first, to get the bootloader unlock?

OEM Update
You won't find the option to turn on OEM in the device.
You can enable it! Here's how:
Go to the Google Play Store.
Search secret codes revealer.
Search codes
Look for 759
Click launch code
Confirm launch
Under oem click on.
Congrats. You've just enabled oem on your desire 526!
Happy hunting.
BigCountry907 said:
How To Get Permanent Root
This is a workaround until I can compile a Bootable Kernel
First of all say thanks to @Captain_Throwback !!
He was the original creator of the TWRP Recovery for the Desire 626s.
I have taken his TWRP recovery for the 626s, unpacked it and ported in some of the Desire 526 recovery image.
Kinda a cracked up way of doing this but hey ( It Works)
Step #1
Unlock Your Boot-Loader !!! (currently accomplished with a Java Card / HTC Service Tool)
Even with the card you could run into trouble with unlocking the boot-loader.
There is no switch to Enable OEM Unlock available in the Developer Options.
Here is a work-around for that.
Step #1-A
Open up terminal shell on a computer and pull the frp image from the device. (Temp Root Required)
Code:
dd if=/dev/block/bootdevice/by-name/frp of=/sdcard/frp.img
Terminal Output
[email protected]_a13wlpp:/ #dd if=/dev/block/bootdevice/by-name/frp of=/sdcard/frp.img <
1024+0 records in
1024+0 records out
524288 bytes transferred in 0.364 secs (1440351 bytes/sec)
[email protected]_a13wlpp:/ #
Pull the frp.img to the computer.
If you are still in adb shell.
Code:
exit
exit
Then from the normal command line
Code:
adb pull /sdcard/frp.img
Terminal Output
f=/dev/block/bootdevice/by-name/frp of=/sdcard/frp.img <
1024+0 records in
1024+0 records out
524288 bytes transferred in 0.364 secs (1440351 bytes/sec)
[email protected]_a13wlpp:/ # exit
[email protected]_a13wlpp:/ $ exit
[email protected]:~$ adb pull /sdcard/frp.img
2758 KB/s (524288 bytes in 0.185s)
[email protected]:~$
Now open the frp.img file in a hex editor. Like HXD in windows.
Go to the last line of the file.
Change the very last 00 to 01 and save the file.
Reference the screen shots below.
Factory FRP
Patched FRP
Flash the patched frp.img to the device.
Back to the terminal.
Code:
adb push frp.img /sdcard/frp.img
Code:
adb shell
su
dd if=/sdcard/frp.img of=/dev/block/bootdevice/by-name/frp
If you have completed this now your clip can unlock the boot-loader
In case your wondering this will also work on a boot loader locked device. It will get you as far as being able to get a unlock token from fastboot using Fastboot oem get_identifier_token WITH THE DEVICE IN DOWNLOAD MODE
Unfortunatly HTC-DEV still will not give you the UNLOCK TOKEN yet. The pg2fs partition needs an edit then htc dev will generate a good code. Problem is without clip you cannot modify the pg2fs image. Allthough I am working on it.
STEP #2 ( Get Perm Root !! )
Download the Patched TWRP and SuperSu
The 2 files are attached to the thread. Unzip the TWRP-No-Touch.img.zip Do not unzip the Super.zip.
Copy the super.zip to the device sdcard. Use file explorer or terminal.
Code:
adb push super.zip /sdcard/super.zip
Flash the TWRP Recovery to the device.
reboot to download mode
Code:
adb reboot download
Flash the recovery
Code:
fastboot flash recovery Twrp-526-NO-TOUCH.img
Boot into TWRP Recovery
Code:
fastboot boot recovery
DON'T PANIC !! Yes your right......The touch screen is not working!!!
I need to compile a custom kernel to get TWRP working Right.
I have compiled the kernel but it isn't booting right yet. That's why I figured out this work around for now.
So Now What ???
No worries....Even though we can't access the TWRP commands from the touch screen LETS NOT FORGET.........
We can use the command line :highfive:
Open up terminal on your computer.
If it's not already open.
Go into the shell.
Code:
adb shell
No need to type su cause in case you didn't notice we are already ROOT. "#"
So to install SuperSu (or any other zip package) we do this.
#1 Mount the system partition.
Code:
mount -o rw -t ext4 /dev/block/mmcblk0p62 /system
#2 Tell TWRP what we want it to do one stap at a time
Set device to boot into recovery upon reboot.
Code:
echo 'boot-recovery ' > /cache/recovery/command
Tell TWRP to install SuperSu when it boots.
Code:
echo '--update_package=/sdcard/super.zip' >> /cache/recovery/command
Reboot the recovery to install the SuperSu.
Code:
reboot recovery
Now you will see TWRP boot back up and when it boots up it will install the zip package.
Congratulations you are now one of the first peoples to have a fully rooted Verizon Desire 526. :laugh::silly:
Lets get busy boys !!!! We need to get this boot loader unlocked for the rest of the community.
It's all about the pg2fs partition. If we can find a way to write to it with s-on and boot loader locked then we can unlock all boot-loaders
Click to expand...
Click to collapse

Good to know about the 759 code webag.youtag.
But without buying the clip device we are still stuck.
So hopefully BigCountry907 can find a way to unlock the bootloader and root without the clip.
Sidenote: I tried changing my PRL but couldn't get the changes to stick. I tried DFS and QPST. Am I missing something?

@webag.youtag
I installed the mentioned app and used the code.
It shows in the app that the oem is turned on.
But It isn't setting the last byte of the FRP to 01 so ultimatly it will not work.
I tested and still get.
[email protected]:~$ fastboot oem get_identifier_token
...
(bootloader) [KillSwitch] : /dev/block/bootdevice/by-name/frp
(bootloader) [KillSwitch] Last Byte is 0X00, disable unlock
(bootloader) [KillSwitch] oem unlock Turn Off!
OKAY [ 0.082s]
finished. total time: 0.082s
[email protected]:~$
The app lacks permissions to write to the frp partition.
Anyone working on unlocking the boot-loader needs to use the method I posted previously.
And also note: If you reboot the phone then you need to flash the frp partition again.
During re-boot the bit gets set back to 00.
So in a nutshell.
Edit your frp. Make 00 = 01.
Then dd flash the frp.
Then adb reboot download.
Then fastboot oem get_identifier_token.
Problem is there still is a change required in the pg2fs partition / TO Avoid the CID Not Allowed Error
@supermaxkato
Not sure about the prl.
But I have noticed that the security system is tricky.
It will show you in adb shell that you have written the changes to the partition successfully.
But due to the read only protection the partition never really gets written.
Basically instead of giving an error it is writing to a NULL device successfully.

I was looking around and saw a post! (Rare I know)
Have you tried hboot instead of fastboot?also, I have no computer (sad). I am able to get temp root with "kingroot-4.8.2" I am able to use hex edit to change frp from 00 to 01. Is there a way to get identifier token without a PC? Maybe in configuration files or prop files?
BigCountry907 said:
@webag.youtag
I installed the mentioned app and used the code.
It shows in the app that the oem is turned on.
But It isn't setting the last byte of the FRP to 01 so ultimatly it will not work.
I tested and still get.
[email protected]:~$ fastboot oem get_identifier_token
...
(bootloader) [KillSwitch] : /dev/block/bootdevice/by-name/frp
(bootloader) [KillSwitch] Last Byte is 0X00, disable unlock
(bootloader) [KillSwitch] oem unlock Turn Off!
OKAY [ 0.082s]
finished. total time: 0.082s
[email protected]:~$
The app lacks permissions to write to the frp partition.
Anyone working on unlocking the boot-loader needs to use the method I posted previously.
And also note: If you reboot the phone then you need to flash the frp partition again.
During re-boot the bit gets set back to 00.
So in a nutshell.
Edit your frp. Make 00 = 01.
Then dd flash the frp.
Then adb reboot download.
Then fastboot oem get_identifier_token.
Problem is there still is a change required in the pg2fs partition / TO Avoid the CID Not Allowed Error
@supermaxkato
Not sure about the prl.
But I have noticed that the security system is tricky.
It will show you in adb shell that you have written the changes to the partition successfully.
But due to the read only protection the partition never really gets written.
Basically instead of giving an error it is writing to a NULL device successfully.
Click to expand...
Click to collapse

Can you please upload your unlocked boot loader bigcountry907?

Any more progress on this, gentlemen?

When I follow the OP and get to the step:
"fastboot flash recovery Twrp-526-NO-TOUCH.img"
I receive the following error:
FAILED (remote: 9: SD_SECURITY_FAIL recovery and bootloader isn't BL_UNLOCK)
finished. total time: 2.762s
Steps taken:
-frp.img (Pulled from the device, edited & reflashed back with dd command, adb shell reports successful)
-pushed super.zip to device
-rebooted using fastboot to download mode
-attempted to flash TWRP & get the fail with the same error multiple times
Any suggestions or clues? I've attempted this several times, following the OP step by step.
Thanks for the help

@rfunderburk39
You have to unlock the BOOTLOADER first.
Currently I can only unlock it with the xtc-2 clip.
But I'm working on it.
Surprisingly my desire 530 was able to be s-off using TWRP recovery.
If i can somehow capture the commands passed from the xtc-2 clip to the twrp recovery we can replicate it.
Other than that were looking at cooking a qfil / qpst flashable rom.
Not easy.
does anyone know how to log all commands sent to TWRP?

BigCountry907, is the desire 530 you were able to root with twrp the verizon version? If so, did you have to unlock the bootloader first? Because I don't see it on htcdev.

@BigCountry907 I misunderstood the OP, I thought the frp.img edit was a work around of the Java Card.
I will look into the logging of the the TWRP commands. Let me know if I can help out in other ways.

@rfunderburk39
It gets you one step closer but still at the end it fails.
Verizon implements some major security.
I could really use some help.
I got alot together. The entire qcom msm8909 source + manuals you name it.
I was amazed today when i unlocked a desire 530 with the xtc-2 clip and it used @Captain_Throwback twrp to s-off the device.
The beauty of this is it proves S-Off is possible through twrp recovery.
It was my belief that the recovery did not have high enough permissions to write to the radio and get s-off.
Apparently if you know the right commands in the TWRP #shell it's possible.
So how deep into linux / android do you go?
My next best attempt is to generate a service rom using QPST to flash in EDL mode.
Ever make a partition.xml file???
Thats aboot where im at.
oh yea and JTAG TOO.

BigCountry907 said:
@rfunderburk39
It gets you one step closer but still at the end it fails.
Verizon implements some major security.
I could really use some help.
I got alot together. The entire qcom msm8909 source + manuals you name it.
I was amazed today when i unlocked a desire 530 with the xtc-2 clip and it used @Captain_Throwback twrp to s-off the device.
The beauty of this is it proves S-Off is possible through twrp recovery.
It was my belief that the recovery did not have high enough permissions to write to the radio and get s-off.
Apparently if you know the right commands in the TWRP #shell it's possible.
So how deep into linux / android do you go?
My next best attempt is to generate a service rom using QPST to flash in EDL mode.
Ever make a partition.xml file???
Thats aboot where im at.
oh yea and JTAG TOO.
Click to expand...
Click to collapse
Tommorrow my time will be limited during the day, but I can look into "qcom msm8909 source + manuals" & the ability to log TWRP commands and see what I can find.
Interesting about the 530, I was not aware that was possible.
I've used linux for about 20 years, and would consider my knowledge to be good, with the ability to usually get to source of a problem and/or find a solution slash work around.
I've never created a partition.xml, but would be happy to look into it.
I do have quite a bit of past JTAG experience but that was using a serial port not USB, which I assume you are referencing.

@supermaxkato
No my Desire 530 is Metro-Pcs.
I took one of the verizon 526 and activated it then used the phone number to port to Metro Pcs.
With the port it cost $70 for the Desire 530 + 1 month of unlimited service. Essentially the Desire 530 was free.
Any Verizon HTC most likely will have the same security scheme.
@rfunderburk39
This is good news. I would be grateful to have help on this.
It is difficult to know what kind of experience people have some don't even know how to use adb.
I will start another thread with all the information I know so far.
And I have the MSM8909 source code. Not just the kernel but the "Qualcomm Chipcode" Board Support Package.
And many qcom manuals.
This should be very helpful to us.
I will name the new thread "{WIP} {ROM} MSM8909 Service Rom From Source / QPST Root + Unlock + Unbrick"
I will post all current information there.

Something potentially worth trying:
-Grab the Settings.apk (and .odex) from the 526+ or 626, just make sure its the same version of android.
-Push those to device
-adb shell
-su
-mount -o rw,remount,rw /system
-exit
-exit
-adb push Settings.apk /system/priv-app/Settings/
-adb push Settings.odex /system/priv-app/Settings/arm/
-Open >settings>developer options on the device
-check and see if the option “OEM Unlock” appears
-reboot into "download mode" and see if the settings stick.
-run fastboot oem get_identifier_token
Granted this holds the possibility of bricking the phone, but more than likely will not stick on a reboot & the Settings.apk will be replaced with the device original.

I will test on mine.
Give me an hour

Well I replaced the settings files with the settings files from the unlocked ruu for the 526.
It's a no-go the settings app crashes on boot.
This would only add the oem_unlocking option.
We can get the same result by changing the last byte 00 of the FRP.img to 01 and then in a root shell
to pull
dd if=dev/block/bootdevice/by-name/frp of=/sdcard/frp.img
to push
dd if=/sdcard/frp.img of=dev/block/bootdevice/by-name/frp
This will work to get a Unlock Token but the HTC-DEV site will reject it.
ERROR = CID Not Allowed.
If you can find a way to write the pg2fs partition I can make this work.

BigCountry907 said:
@rfunderburk39
It gets you one step closer but still at the end it fails.
Verizon implements some major security.
I could really use some help.
I got alot together. The entire qcom msm8909 source + manuals you name it.
I was amazed today when i unlocked a desire 530 with the xtc-2 clip and it used @Captain_Throwback twrp to s-off the device.
The beauty of this is it proves S-Off is possible through twrp recovery.
It was my belief that the recovery did not have high enough permissions to write to the radio and get s-off.
Apparently if you know the right commands in the TWRP #shell it's possible.
So how deep into linux / android do you go?
My next best attempt is to generate a service rom using QPST to flash in EDL mode.
Ever make a partition.xml file???
Thats aboot where im at.
oh yea and JTAG TOO.
Click to expand...
Click to collapse
BigCountry907 said:
Well I replaced the settings files with the settings files from the unlocked ruu for the 526.
It's a no-go the settings app crashes on boot.
This would only add the oem_unlocking option.
We can get the same result by changing the last byte 00 of the FRP.img to 01 and then in a root shell
to pull
dd if=dev/block/bootdevice/by-name/frp of=/sdcard/frp.img
to push
dd if=/sdcard/frp.img of=dev/block/bootdevice/by-name/frp
This will work to get a Unlock Token but the HTC-DEV site will reject it.
ERROR = CID Not Allowed.
If you can find a way to write the pg2fs partition I can make this work.
Click to expand...
Click to collapse
I didn't think it would work, just an outside chance. Hoped it may give a different token, that in turn would pass over at HTC-DEV.
Back when I had other HTC devices, I used a tool here on XDA [TOOL] HTC Easy Unlock Bootloader Tool. It doesn't appear to be maintained any longer, its based around Windows *.bat files (easy enough to edit)
https://forum.xda-developers.com/showthread.php?t=2133336
and SimpleGoldCard
https://forum.xda-developers.com/showthread.php?t=970157
SimpleGoldCard would access a site, after downloading that, you select it in the SimpleGoldCard application & it would create the image.
https://huygens.hoxnet.com/goldcard.html
I haven't had time to read through these post just yet, the method may no longer be valid. But worth a look, and I will be reading through these today to see.
Also I will see what I can find about a work-a-round of the the writing to pg2fs partition

Vernee Apollo Discoveries

I wanted to create a thread so as to report any unique findings from the internet realm and my own discoveries surrounding the Vernee Apollo Phone. The aim is to bring resources together to encourage development and to release utilities and roms.
Please post your own discoveries and updates!!!
This is NOT a "Vernee Apollo Lite" nor a "Vernee Apollo X" thread even though some information maybe relevant.
Device Name and Specs
Vernee Apollo.
Device Model =K15TA_A
Official Product Website
Official Product Forum
http://www.devicespecifications.com/
Vernee Apollo - Antutu Benchmark v6.2.7.
Score 92,235.
3D: 19159
UX: 38097
CPU: 27535
RAM: 7444
Helio X25 MT6797 Family System on a Chip (SoC) Comparison
Vernee Apollo deploys a X25 MT6797T.
https://en.wikipedia.org/wiki/MediaTek#Octa-_and_deca-core
https://www.mediatek.com/products/smartphones/mt6797-helio-x20
{
"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"
}
ADB and FASTBOOT Modes
The Vernee Apollo's bootloader supports Fastboot. The Recovery mode supports the Android Debugging Bridge (ADB) . To access, perform the button sequence below. A menu will appear allowing you to cycle through option to either boot into the recovery partitio,n or to start the Fastboot service.
ADB service is also available also within the Android desktop if you enable USB Debugging in the revealed developers settings menu. You will most likely need to accept a signed key issued from the managing computer for the service to communicate!
Accessing Bootloader Menu
Buttons: [Top-Volume] + [Power-Button] for 8 Seconds.
When the phone is shutdown, hold both buttons at same time from for 8 seconds. The Bootloader menu will appear and then release buttons.
Using Bootloader Menu
Button: [Top-Volume] = Cycle selection.
Button: [Bottom-Volume] = Choose selected item.
With the high screen resolution it maybe hard to see the text-options. There should be three;
1. Recovery, (Boot into Recovery partition with ADB.)
2. Fastboot, (Start Fastboot server.)
3. Normal. (Proceed to boot normally.)
Using Recovery Mode and Menu
When you boot the Recovery partition you will be meet with a failed Android icon on the stock Vernee release rom. ADB will be accessible from here. Note: The Recover menu will cause the ADB server to fail. If you want to display the recovery menu options then perform the following during the failed Android icon screen.
Buttons: [Top-Volume] + [Power-Button] pulsing till the menu appears.
Fastboot
If you plan to develop on your Apollo or to install future community roms then it's advisable to unlock your storage partitions. Unlocking will allow you to change partitions but doing so will void software warranty clauses, and in the process scrub all your personal data from the phone so it's best to do it before installing personal content.
To unlock the phone issue the following command through Fastboot. You will be asked to confirm.
Code:
fastboot oem unlock
Engineering Mode
Enter the following phone number in Android desktop
Code:
Dial *#*#3646633#*#*
Phone Test Options
Alternatively there is a phone test mode available at low level with less options. Whilst the phone is shutdown, press the following.
Buttons: [Bottom-Volume] + [Power-Button] for 8 Seconds.
A test menu will appear and is in simplified Chinese.
SIMS
If your phone is not receiving data over 4G or 3G, Google on another computer "apn" "YOURMOBILEPHONEPROVIDER" "YOURNATION". Example;
Code:
"apn" "vodafone" "uk"
You should find links to technical settings for your data provider's access. Then enter them in by navigating to;
Settings>More>Mobile network settings>Access point names>CLICK-YOUR-LOCKED-ON-PROVIDER>THEN-CONFIRM-SETTINGS
USB
Device USB Coding
Code:
System Mode:
ID 0e8d:201d MediaTek Inc.
ADB Mode:
ID 0e8d:2008 MediaTek Inc.
Fastboot Mode
ID 0bb4:0c01 HTC (High Tech Computer Corp.) Dream / ADP1 / G1 / Magic / Tattoo
Microsoft Windows VCOM Drivers
On Microsoft systems you will need to have drivers installed so as to communicate with the Mediatek phone.
MediaTek DA USB VCOM (Android) Driver 3.0.1504.0 for Windows 7/Windows 8.1
MediaTek DA USB VCOM (Android) Driver 3.0.1504.0 for Windows 10
UART Ability?
I haven't opened the phone yet but if anyone does please capture images of the circuit board. If there are UART pins on the board it may have a root shell piped to the interface. A UART (universal asynchronous receiver/transmitter) in this sense is a device that couples serial communications port to USB to run a terminal over.
Vernee Official Rom Images & "Over The Air" Updates
Official Product Downloads/Support
VerneeX25_Recovery_OriginalStock_v1p0 (Thx to Relief66)
Download (2016-12) ROM "full_k15ta_a-ota-1482441792.zip"
Download (2017-01) ROM "full_k15ta_a-ota-1484567521.zip" (Creating .img from .dat files works!)
Download (2017-07) ROM "full_k15ta_a-ota-1499861676.zip"
Download (2017-07) OTA Patch "20170712201130-OTA.rar"
Note: "20170712201130-OTA.rar" is only designed to update "full_k15ta_a-ota-1482441792.zip" image.
Flashing Partitions
There are three main ways to flash;
1. using "Smart Phone Flash Tool",
2. Fastboot flash command,
3. via internal software like a root bash shell or routine from recovery.
Partition Table
Code:
system logical drive = 2621.44MB [= 2684354560 bytes = 5242880 x 512blocks]
recovery logical drive = 16.384MB
Scatter file from OTA
----------------------------
preloader 0x0
pgpt 0x0
recovery 0x8000
para 0x1008000
custom 0x1088000
expdb 0x13c88000
frp 0x14688000
nvcfg 0x14788000
nvdata 0x14f88000
metadata 0x16f88000
protect1 0x18f88000
protect2 0x19788000
seccfg 0x1a000000
oemkeystore 0x1a800000
proinfo 0x1aa00000
md1img 0x1ad00000
md1dsp 0x1c500000
md1arm7 0x1c900000
md3img 0x1cc00000
scp1 0x1d100000
scp2 0x1d200000
nvram 0x1d300000
lk 0x1d800000
lk2 0x1d880000
boot 0x1d900000
logo 0x1e900000
tee1 0x1f100000
tee2 0x1f600000
keystore 0x1fb00000
system 0x20800000
cache 0xc0800000
userdata 0xdb000000
flashinfo 0xFFFF0080
sgpt 0xFFFF0000
recovery.fstab
------------------
# mount point fstype device [device2]
/boot emmc boot
/cache ext4 /dev/block/mmcblk0p4
/data ext4 /dev/block/mmcblk0p5
/misc emmc misc
/recovery emmc recovery
/sdcard vfat /dev/block/mmcblk0p6
/system ext4 /dev/block/mmcblk0p3
live fstab via "cat /fstab.mt6797"
------------------------------------------
# 1 "vendor/mediatek/proprietary/hardware/fstab/mt6797/fstab.in"
# 1 "<built-in>"
# 1 "<命令行>"
# 1 "vendor/mediatek/proprietary/hardware/fstab/mt6797/fstab.in"
# 20 "vendor/mediatek/proprietary/hardware/fstab/mt6797/fstab.in"
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/system /system ext4 ro wait
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/userdata /data ext4 noatime,nosuid,nodev,noauto_da_alloc,discard wait,check,resize,encryptable=/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/metadata,
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/cache /cache ext4 noatime,nosuid,nodev,noauto_da_alloc,discard wait,check
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/protect1 /protect_f ext4 noatime,nosuid,nodev,noauto_da_alloc,commit=1,nodelalloc wait,check,formattable
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/protect2 /protect_s ext4 noatime,nosuid,nodev,noauto_da_alloc,commit=1,nodelalloc wait,check,formattable
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/nvdata /nvdata ext4 noatime,nosuid,nodev,noauto_da_alloc,discard wait,check,formattable
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/nvcfg /nvcfg ext4 noatime,nosuid,nodev,noauto_da_alloc,commit=1,nodelalloc wait,check,formattable
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/custom /custom ext4 ro wait
/devices/mtk-msdc.0/11230000.msdc0* auto vfat defaults voldmanaged=sdcard0:auto
/devices/mtk-msdc.0/11240000.msdc1* auto auto defaults voldmanaged=sdcard1:auto,encryptable=userdata
/devices/soc/11270000.usb3_xhci* auto vfat defaults voldmanaged=usbotg:auto
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/frp /persistent emmc defaults defaults
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/nvram /nvram emmc defaults defaults
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/proinfo /proinfo emmc defaults defaults
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/lk /bootloader emmc defaults defaults
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/lk2 /bootloader2 emmc defaults defaults
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/para /misc emmc defaults defaults
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/boot /boot emmc defaults defaults
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/recovery /recovery emmc defaults defaults
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/logo /logo emmc defaults defaults
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/expdb /expdb emmc defaults defaults
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/seccfg /seccfg emmc defaults defaults
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/tee1 /tee1 emmc defaults defaults
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/tee2 /tee2 emmc defaults defaults
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/scp1 /scp1 emmc defaults defaults
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/scp2 /scp2 emmc defaults defaults
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/md1img /md1img emmc defaults defaults
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/md1dsp /md1dsp emmc defaults defaults
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/md1arm7 /md1arm7 emmc defaults defaults
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/md3img /md3img emmc defaults defaults
Raw block partition label and user/group
-----------------------------------------------------
/dev/block/platform/mtk-msdc\.0/[0-9]+\.msdc0/by-name/proinfo u:object_r:nvram_device:s0
/dev/block/platform/mtk-msdc\.0/[0-9]+\.msdc0/by-name/nvram u:object_r:nvram_device:s0
/dev/block/platform/mtk-msdc\.0/[0-9]+\.msdc0/by-name/nvdata u:object_r:nvdata_device:s0
/dev/block/platform/mtk-msdc\.0/[0-9]+\.msdc0/by-name/frp u:object_r:frp_block_device:s0
/dev/block/platform/mtk-msdc\.0/[0-9]+\.msdc0/by-name/expdb u:object_r:expdb_block_device:s0
/dev/block/platform/mtk-msdc\.0/[0-9]+\.msdc0/by-name/misc2 u:object_r:misc2_block_device:s0
/dev/block/platform/mtk-msdc\.0/[0-9]+\.msdc0/by-name/logo u:object_r:logo_block_device:s0
/dev/block/platform/mtk-msdc\.0/[0-9]+\.msdc0/by-name/para u:object_r:para_block_device:s0
/dev/block/platform/mtk-msdc\.0/[0-9]+\.msdc0/by-name/tee1 u:object_r:tee_block_device:s0
/dev/block/platform/mtk-msdc\.0/[0-9]+\.msdc0/by-name/tee2 u:object_r:tee_block_device:s0
/dev/block/platform/mtk-msdc\.0/[0-9]+\.msdc0/by-name/seccfg u:object_r:seccfg_block_device:s0
/dev/block/platform/mtk-msdc\.0/[0-9]+\.msdc0/by-name/userdata u:object_r:userdata_block_device:s0
/dev/block/platform/mtk-msdc\.0/[0-9]+\.msdc0/by-name/cache u:object_r:cache_block_device:s0
/dev/block/platform/mtk-msdc\.0/[0-9]+\.msdc0/by-name/recovery u:object_r:recovery_block_device:s0
/dev/block/platform/mtk-msdc\.0/[0-9]+\.msdc0/by-name/protect1 u:object_r:protect1_block_device:s0
/dev/block/platform/mtk-msdc\.0/[0-9]+\.msdc0/by-name/protect2 u:object_r:protect2_block_device:s0
/dev/block/platform/mtk-msdc\.0/[0-9]+\.msdc0/by-name/keystore u:object_r:keystore_block_device:s0
/dev/block/platform/mtk-msdc\.0/[0-9]+\.msdc0/by-name/oemkeystore u:object_r:oemkeystore_block_device:s0
/dev/block/platform/mtk-msdc\.0/[0-9]+\.msdc0/by-name/boot u:object_r:boot_block_device:s0
/dev/block/platform/mtk-msdc\.0/[0-9]+\.msdc0/by-name/persist u:object_r:persist_block_device:s0
/dev/block/platform/mtk-msdc\.0/[0-9]+\.msdc0/by-name/system u:object_r:system_block_device:s0
/dev/block/platform/mtk-msdc\.0/[0-9]+\.msdc0/by-name/nvcfg u:object_r:nvcfg_block_device:s0
/dev/block/platform/mtk-msdc\.0/[0-9]+\.msdc0/by-name/md1img u:object_r:md_block_device:s0
/dev/block/platform/mtk-msdc\.0/[0-9]+\.msdc0/by-name/md1dsp u:object_r:dsp_block_device:s0
/dev/block/platform/mtk-msdc\.0/[0-9]+\.msdc0/by-name/md1arm7 u:object_r:md_block_device:s0
/dev/block/platform/mtk-msdc\.0/[0-9]+\.msdc0/by-name/md3img u:object_r:md_block_device:s0
On my rooted phone I can check the UUID of the partitions. (You may need BusyBox installed to use blkid command!).
Code:
adb shell
su
blkid
displays;
Code:
/dev/block/loop0: LABEL="iAmCdRom" TYPE="iso9660"
/dev/block/loop1: UUID="57f8f4bc-abf4-655f-bf67-946fc0f9f25b" TYPE="ext4"
/dev/block/zram0: TYPE="swap"
/dev/block/mmcblk0p3: LABEL="custom" UUID="0f1095f4-0ece-e656-b6ac-e2ce104d5722" TYPE="ext4"
/dev/block/mmcblk0p6: UUID="57f8f4bc-abf4-655f-bf67-946fc0f9f25b" TYPE="ext4"
/dev/block/mmcblk0p7: UUID="57f8f4bc-abf4-655f-bf67-946fc0f9f25b" TYPE="ext4"
/dev/block/mmcblk0p9: UUID="57f8f4bc-abf4-655f-bf67-946fc0f9f25b" TYPE="ext4"
/dev/block/mmcblk0p10: UUID="57f8f4bc-abf4-655f-bf67-946fc0f9f25b" TYPE="ext4"
/dev/block/mmcblk0p28: LABEL="system" UUID="da594c53-9beb-f85c-85c5-cedf76546f7a" TYPE="ext4"
/dev/block/mmcblk0p29: UUID="57f8f4bc-abf4-655f-bf67-946fc0f9f25b" TYPE="ext4"
/dev/block/mmcblk0p30: UUID="57f8f4bc-abf4-655f-bf67-946fc0f9f25b" TYPE="ext4"
/dev/block/mmcblk1p1: UUID="0508-0E13" TYPE="vfat"
Modifying Partitions
Modify partitions often means Users hacking the commercial roms and that means extracting out the important files to work with. The most important blocks are the system-partition which holds the operating system, then the recovery-partition which pole vaults Users with low level tools and abilities, like startup phone root powers. Noting many modern phone root modes, deploy on the recovery-partition rather than modify the system-partition, so as to retain full compatibility and retention of abilities, when conducting "Over the Air" / OTA updates from the manufacturer.
There are two popular platforms to hack on. 1. on native Linux including the phone itself, and 2. on a Microsoft Windows platform with Linux style utilities.
To ready a partition, to then modify it, and to then save it for flashing has many steps. One should obtain the manufacturer's rom or OTA update, to seek out the latest images and files to utilise.
In this example of hacking an official rom, we will be using "full_k15ta_a-ota-1484567521.zip". Utility executables are readily available in repositories related to your Linux distribution, like AUR on Archlinux.
Linux - ACCESSING SYSTEM IMAGE TO MODIFY
1.) Extract the zip file to a new folder. The directory should be something like this structure.
Code:
.../tinysys-scp.bin
.../logo.bin
.../lk.bin
.../md1rom.img
.../system.patch.dat
.../type.txt
.../custom.new.dat
.../custom
.../custom/cip-build.prop
.../custom/app-res
.../custom/app-res/quicksearchbox-res
.../custom/app-res/quicksearchbox-res/quicksearchbox-res.apk
.../custom/app-res/android-res
.../custom/app-res/android-res/android-res.apk
.../custom/app-res/browser-res
.../custom/app-res/browser-res/browser-res.apk
.../custom/app-res/launcher3-res
.../custom/app-res/launcher3-res/launcher3-res.apk
.../custom/media
.../custom/media/audio
.../custom/media/audio/notifications
.../custom/media/audio/notifications/Leaf.ogg
.../custom/media/audio/notifications/Pure.ogg
.../custom/media/audio/notifications/Triumph.ogg
.../custom/media/audio/notifications/Vernee_n002.ogg
.../custom/media/audio/notifications/The_time_tunne.ogg
.../custom/media/audio/notifications/Jump.ogg
.../custom/media/audio/notifications/Whisper.ogg
.../custom/media/audio/notifications/Vernee_n001.ogg
.../custom/media/audio/notifications/Cuckoo.ogg
.../custom/media/audio/notifications/Cleverer.ogg
.../custom/media/audio/notifications/Meteor.ogg
.../custom/media/audio/notifications/Bongo.ogg
.../custom/media/audio/notifications/Ripples.ogg
.../custom/media/audio/notifications/Whistle.ogg
.../custom/media/audio/notifications/Gift.ogg
.../custom/media/audio/alarms
.../custom/media/audio/alarms/ClassicAlarm.ogg
.../custom/media/audio/alarms/Waltz.ogg
.../custom/media/audio/alarms/Vernee_a001.ogg
.../custom/media/audio/alarms/GoodLuck.ogg
.../custom/media/audio/alarms/Foredawn.ogg
.../custom/media/audio/alarms/Vernee_a002.ogg
.../custom/media/audio/alarms/MorningSunShine.ogg
.../custom/media/audio/alarms/Walking_in_the_rain.ogg
.../custom/media/audio/ringtones
.../custom/media/audio/ringtones/Call_of_love.ogg
.../custom/media/audio/ringtones/Spring.ogg
.../custom/media/audio/ringtones/New_life.ogg
.../custom/media/audio/ringtones/Menuet.ogg
.../custom/media/audio/ringtones/Vernee_r004.ogg
.../custom/media/audio/ringtones/Heartbeat.ogg
.../custom/media/audio/ringtones/Vernee_r005.ogg
.../custom/media/audio/ringtones/Technology.ogg
.../custom/media/audio/ringtones/Longing.ogg
.../custom/media/audio/ringtones/Vernee_r002.ogg
.../custom/media/audio/ringtones/Vernee_r003.ogg
.../custom/media/audio/ringtones/Westlake.ogg
.../custom/media/audio/ringtones/Vernee_r001.ogg
.../custom/media/audio/ringtones/Progress.ogg
.../custom/media/audio/ringtones/Journey.ogg
.../custom/media/audio/ringtones/GuitarPop.ogg
.../custom/media/audio/ringtones/Cloud.ogg
.../custom/media/audio/ringtones/Capriccioso.ogg
.../custom/media/audio/ringtones/IceWorldPiano.ogg
.../custom/plugin
.../custom/plugin/FwkPlugin
.../custom/plugin/FwkPlugin/FwkPlugin.mpinfo
.../custom/plugin/FwkPlugin/FwkPlugin.apk
.../custom/plugin/Signatures
.../custom/plugin/Signatures/mplugin_guard.xml
.../custom/etc
.../custom/etc/resources.xml
.../custom/bootani
.../custom/bootani/shutanimation.zip
.../custom/bootani/bootanimation.zip
.../custom/customprop
.../custom/customprop/custom.prop
.../system.new.dat
.../custom.patch.dat
.../md1arm7.img
.../md3rom.img
.../preloader_k15ta_a.bin
.../md1dsp.img
.../scatter.txt
.../custom.transfer.list
.../file_contexts
.../boot.img
.../META-INF
.../META-INF/CERT.SF
.../META-INF/MANIFEST.MF
.../META-INF/CERT.RSA
.../META-INF/com
.../META-INF/com/android
.../META-INF/com/android/metadata
.../META-INF/com/android/otacert
.../META-INF/com/google
.../META-INF/com/google/android
.../META-INF/com/google/android/update-binary
.../META-INF/com/google/android/updater-script
.../trustzone.bin
.../system.transfer.list
.../sdat2img.py
2.) the images we are looking for are either the system-partition or the recovery-partition to modify. In this case there is only the system and it's held in the file "system.new.dat", a 1.6 gigabyte file. We know from the partition tables above that the system-partition is 2.6GB wide, so this image is either compressed or short. Most partitions deployed on Android for updating are compressed in what's called a sparse format.
We need to uncompress any sparse file before we can work with it or mount it, but the issue in this case is the image is also in "dat" structure, which means we need to unsparse using structured data held in "system.transfer.list". Here we use "sdat2img" executable to create the file "system_fullsize.img";
Code:
sdat2img system.transfer.list system.new.dat system_fullsize.img
Alternatively if the file was not a dat format, we could simply unsparse using;
Code:
simg2img system.img system_fullsize.img
3.) Now that we have the full image we can mount it as a file-system to tinker with it. Example of making a mount point and mounting it;
Code:
sudo mkdir /system
sudo mount -t ext4 -o loop ./system_fullsize.img /system/
You can now modify the image simply by changing the files in the directory mounted on. After changes you can save out and attempting to flash it back to the phone for your custom system.
Linux - CAPTURING THE MOUNT BACK TO AN IMAGE FILE
1.) After we have modified the mounted system-partition we need to save it back out for flashing if you want to see your changes live on the phone.
Labelling (If desired). We can name the mount to enforce block-labels. In this case the loop device was "loop0" used to mount the image. (Check which loop-device was used when performing this. eg: lsblk) Here we are going to label it "system"..
Code:
e2label /dev/loop0 system
It maybe important to set the partition UUID the same as the manufacturer uses so the the mounting process finds the correct partition to mount at boot. We know the system partitions UUID from the above discovery details;
Code:
UUID="da594c53-9beb-f85c-85c5-cedf76546f7a"
We can set the mounted image's UUID to suit the original before creating a new;
Code:
sudo tune2fs /dev/loop0 -U da594c53-9beb-f85c-85c5-cedf76546f7a
Here we capture out the device to an "ext4" format file-system image. The length option, being 2684354560 bytes. Labelling option "-a" with name "system".
Code:
sudo make_ext4fs -s -l 2684354560 -a system system_modded.img /system/
2.) To flash your image, Android's recent "fastboot" utility will allow for unsparse and sparsed images to be flashed. I have broken down the fastboot process into each step.
CAUTION: fastboot writes over your phone's partition blocks. If you are not skilled in this area of computing them research "fastboot" before use.
Note: current I have not found out why this process is incompatible with Vernee Apollo. The images I write back are not operational even though they flash properly. My hunch is that I may need to enforce an ISO/image UUID the same as the manufacturers, but I haven't tested this yet.
Code:
fastboot -w
fastboot format system
fastboot flash system ./system_modded.img
If we want to sparse the file before flashing;
Code:
img2simg system_modded.img system_modded_sparse.img
If we want to create a sparse dat structured image;
Code:
img2sdat ./system_modded.img
Linux - ACCESSING RECOVER IMAGE TO MODIFY
An Android recovery image is really three items in one image. There is a compressed kernel (zImage) used to run a recovery system, a ramdisk (initrd.img), and configuration file. The ramdisk "initrd.img" holds the operating system files used by the recovery kernel. Note the bootimage partition/image is a similar structure to a recovery-image.
If you need a similar development community then the Xiaomi Redmi Pro is a similar phone due to its Mediatek Helio x25 but it uses a different cameras, screen and sensors. Modifying and tweaking settings in their recovery images can work on your Vernee Apollo X25.
To extract the sub held files (bootimg.cfg, zImage, initrd.img);
Code:
abootimg -x recovery.img
To unpack a ramdisk "initrd.img";
Code:
mkdir initrd
cd initrd
sudo zcat ../initrd.img | cpio -idmv
To pack files whilst in your ramdisk directory ''/initrd";
Code:
find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
To pack back up components into a recovery rom;
Code:
abootimg --create recovery_new.img -f bootimg.cfg -k zImage -r initrd.img
Alternatively;
Code:
mkbootimg --cmdline 'no_console_suspend=1 console=null' --kernel ./zImage --ramdisk ./newramdisk.cpio.gz -o recovery_new.img
Software
Chainfire SuperSU Release Announcement
F-Droid. Alternative App Store for public domain software.
.

Known Recovery Image Developers
Cleopatra Bianchi
https://forum.xda-developers.com/general/rooting-roms/vernee-apollo-helio-x25-twrp-root-t3554788
Known ROM Developers
Cleopatra Bianchi
https://forum.xda-developers.com/general/rooting-roms/vernee-apollo-helio-x25-roms-fix-t3561019
Vernee Apollo X25 General Resource Sites
http://www.needrom.com/ Vernee/ApolloX25
.

Hardware
Protective Covers
Silicone and more rigid covers are becoming available for the Vernee Apollo. Make sure you don't get a Lite version as it wont fit.
Those looking for more range and are willing to mod, the Lenovo K5 Note is very similar in dimensions to the Apollo X25, but the headphone jack, volume and power buttons are slightly off. Modding a K5 Note case will require cutting holes for the headphone jack, buttons, speaker holes, and possibly for the flash. Clear covers will allow the flash to work. Make sure the camera and finger scanner is a complete open section on any K5 cover!
https://www.aliexpress.com/item/Ver...-Shell-Back-Cover-For-Vernee/32799796884.html

TWRP Vernee Apollo Helio X25
Cleopatra Bianchi said:
Click to expand...
Click to collapse
http://bbs.vernee.cc/forum.php?mod=viewthread&tid=1721&extra=page%3D1

Cleopatra Bianchi said:
http://bbs.vernee.cc/forum.php?mod=viewthread&tid=1721&extra=page%3D1
Click to expand...
Click to collapse
I left it up to you to post. I hope people comment on what they think. I'm working on my own images so I can't install others at the moment to give an opinion. Readers please note I can't verify the security on this share. Do not take any compromising actions.
I'm super busy so not sure when I will have my own solutions.

How I wish I had more knowledge. This piece of Hw (Raw Hw?) has a lot of potential, but lacks interest of any developer adapt/adopt it....
The conditions are there (lets hope the owners free the code, as they have done with its small brother), and let's hope there are enough and good drivers for the chosen Hw.
Just to encourage your efforts.
Regards

I agree
lots of good hardware and poor software...I hope in this community

At the moment I found these "bad" things about this phone:
1) you can't choose to view the battery percentage in the upper bar
2) you have to set the APN manually or you can't use internet
3) you can't turn volume up or down if the screen is switched off

I've kind of hit a wall with modding the system image to root it. The system images I produce are just not compatible with flashing. They flash but no desktop runs on the phone. Tried both sparse and raws. and I've got the partition size correct. Mount point is set properly to "system" and they're ext4 images.
I'm building Chainfire's version of ext4_utils, specifically the make_ext4fs util. If that doesn't work then I'll build Google's version. Long process as you need SELinux headers which takes ages to install. There maybe a bug in older versions that's causing the trouble. Other thoughts, there maybe a different padding method or bit plane for storing file system nodes. I may need SELinux builds of executables just to get the job done as I did notice in a hex.diff that the original image has SELinux stamps in it. I need more investigation to know why that's so.
It would be nice if Cleopatra Bianchi chimed in if She knows the issue or has even been down this road before, so to speak.

Hi, E8
Do not know even if this could be valuable, but the sources of the lite version are there. I suppose they are taking the same engineering approaches with the big brother... or not...
but would check
Regards

jrotaetxe said:
Hi, E8
Do not know even if this could be valuable, but the sources of the lite version are there. I suppose they are taking the same engineering approaches with the big brother... or not...
but would check
Regards
Click to expand...
Click to collapse
I'll look into it as the scripts may indicate the process to image creation. Cheers.

TWRP and ROOT - successfully tested !
https://forum.xda-developers.com/general/rooting-roms/vernee-apollo-helio-x25-twrp-root-t3554788

Such a cool phone, but sending it back. Doesn't work with US carriers

Stock firmware in Flash Tool
Cleopatra Bianchi said:
TWRP and ROOT - successfully tested !
https://forum.xda-developers.com/general/rooting-roms/vernee-apollo-helio-x25-twrp-root-t3554788
Click to expand...
Click to collapse
I look forward to flash the stock firmware in Flash Tool. I foolishly made a phone of brick, all backups lost.

stock firmware
myextasy said:
I look forward to flash the stock firmware in Flash Tool. I foolishly made a phone of brick, all backups lost.
Click to expand...
Click to collapse
A working stock firmware will be here very soon.
Please be patient, I am working on that.

Cleopatra Bianchi said:
A working stock firmware will be here very soon.
Please be patient, I am working on that.
Click to expand...
Click to collapse
Anyway to unlock bands to get it working in US ???

myextasy said:
I look forward to flash the stock firmware in Flash Tool. I foolishly made a phone of brick, all backups lost.
Click to expand...
Click to collapse
You can easily restore the phone using the official zip rom. Place it on a micro sdcard and install via the Bootloader menu. Instructions are on the forst comment on how to get to the bootloader menu and then recovery. If you're destroyed your recovery partition but still have fastboot access then you can use the system image within the official rom to flash the system partition with a bit of modifications.
I've been super busy so I haven't had the time to work on my own version of the TWRP Recovery.

How can I find the drivers ? When I google search I only find the one for Apollo lite

Do not believe you can "unlock" US bands, as they differ from EU/ASIA system.
Anyway, trying is (almost) free. The worst thing can happen is a brick
Regards

LG G4 fails to complete LOS 14.1 boot after battery drained to zero [Fixed]

The battery of a rooted, UsUed LG G4 running LineageOS 14.1 was accidentally allowed to drain to zero. After re-charging above 50%, the device failed to boot. The LOS boot screen "bubble on a string" animation would continue indefinitely.
The phone still booted to TWRP, download mode, and fastboot mode.
Originally, it was suspected that this was ILAPO. However, this suspicion was incorrect.
After extensive work creating a boot sector that would allow logging and a ton of help from @steadfasterX, it was discovered that various files in /data/system had been corrupted and had sizes of zero. Android would try to read values from these files, fail, and repeat.
First, a full TWRP backup of the phone was made and copied off-device. Then, I made a second backup of /data/system. Next, I deleted the following zero-byte files from /data/system using TWRP (or ADB after launching TWRP).
packages.list
packages.xml
profiles.xml
netpolicy.xml
notification_policy.xml
If this doesn't work, I would have considered deleting other zero-byte files in /data/system. I used "ls -laS" to get a size-ordered list of files in my current directory.
After a reboot, android re-created the files and booted to the lockscreen.
All of the apps in /data/data had already been cleared. Otherwise, Android would probably have choked on the differences between the user IDs that it wanted to assign to apps and the ownership of the various app folders.
The following links suggest ways to restore some apps from previously created backups
GitHub - joshuabragge/twrp-manual-restore: Automate individual app restores from an android TWRP backup
Automate individual app restores from an android TWRP backup - GitHub - joshuabragge/twrp-manual-restore: Automate individual app restores from an android TWRP backup
github.com
https://www.semipol.de/posts/2016/07/android-manually-restoring-apps-from-a-twrp-backup/
(Permanent archive: https://web.archive.org/web/2019083.../android-restoring-apps-from-twrp-backup.html)
There is no warranty on this solution. It was a makeshift effort created by an amateur. If you choose to duplicate it, you do so at your own risk. You may permanently destroy your phone.
Old post below:
I'm trying to understand whether a particular G4 (H815) has ILAPO. Its been sneezing, has a sore throat, and now can't taste anything^H^H oops, I mean:
- Previously, the phone would get hot during use.
- The phone has been UsUed.
- The battery was accidentally allowed to discharge to zero.
- After the battery was recharged, the phone was unable to boot past the Lineageos "bubble on a string" animation. The animation simply continues forever.
- The phone can boot to TWRP, fasboot, download mode, etc.
Attempts to fix:
- Tried renaming /sdcard/Android to /sdcard/Android.old but this had no effect.
- Tried clearing cache and dalvik cache but this had no effect
- (NEW) Tried attaching to computer and launching "adb logcat" during animation. Device is never found. If I remember correctly, "USB debugging" was off when the device died. (ADB does work in TWRP.)
- (NEW) Tried creating a custom 4-core (2 core for boot) boot image using the instructions here https://forum.xda-developers.com/t/...tom-x-cores-boot-image-ilapo-tempfix.3718389/ and used "fastboot flash boot boot.img" to flash it. This doesn't seem to work.
-- If I reboot into TWRP after a long period of waiting for the lineageos splash screen, I get a CPU temperature of 46 C. I don't know what temperature was generated in the same situation the modified boot image was installed.
Most of the info on ILAPO suggests that phones with it can't get past the LG logo. That is not the case here. Is this ILAPO or something different? Does anyone have ideas as to what might be an appropriate fix?
Is it possible to retrieve boot logs using TWRP in order to figure out when/where/why the boot hangs?

electricfield said:
I'm trying to understand whether a particular G4 (H815) has ILAPO. Its been sneezing, has a sore throat, and now can't taste anything^H^H oops, I mean:
- Previously, the phone would get hot during use.
- The phone has been UsUed.
- The battery was accidentally allowed to discharge to zero.
- After the battery was recharged, the phone was unable to boot past the Lineageos "bubble on a string" animation. The animation simply continues forever.
- The phone can boot to TWRP, fasboot, download mode, etc.
Attempts to fix:
- Tried renaming /sdcard/Android to /sdcard/Android.old but this had no effect.
- Tried clearing cache and dalvik cache but this had no effect
- (NEW) Tried attaching to computer and launching "adb logcat" during animation. Device is never found. If I remember correctly, "USB debugging" was off when the device died. (ADB does work in TWRP.)
- (NEW) Tried creating a custom 4-core (2 core for boot) boot image using the instructions here https://forum.xda-developers.com/t/...tom-x-cores-boot-image-ilapo-tempfix.3718389/ and used "fastboot flash boot boot.img" to flash it. This doesn't seem to work.
-- If I reboot into TWRP after a long period of waiting for the lineageos splash screen, I get a CPU temperature of 46 C. I don't know what temperature was generated in the same situation the modified boot image was installed.
Most of the info on ILAPO suggests that phones with it can't get past the LG logo. That is not the case here. Is this ILAPO or something different? Does anyone have ideas as to what might be an appropriate fix?
Is it possible to retrieve boot logs using TWRP in order to figure out when/where/why the boot hangs?
Click to expand...
Click to collapse
Sounds like the ilapo. Is the battery charged now? I don't know which LOS version you have installed but if you use mine:
follow FAQ #7 of my LOS thread

steadfasterX said:
Sounds like the ilapo. Is the battery charged now? I don't know which LOS version you have installed but if you use mine:
follow FAQ #7 of my LOS thread
Click to expand...
Click to collapse
Thank you for your reply. You seem to know more about G4 issues than anyone. I really appreciate your help.
The battery is charged now.
Unfortunately, I am using the microg version of LOS 14.1, rather than your 16.0.
I tried following the instructions in your FAQ #7, but I can't do step 1 (boot android). The only way for me to exit the bootloop is by removing the battery. There is no "debug" in /cache after I mount cache in TWRP.
I also looked at FAQ #1. ADB never finishes waiting for the device. In fact "lsusb" doesn't show the phone during OS boot (ADB is fine when TWRP is loaded).
Any other ideas?

electricfield said:
Thank you for your reply. You seem to know more about G4 issues than anyone. I really appreciate your help.
The battery is charged now.
Unfortunately, I am using the microg version of LOS 14.1, rather than your 16.0.
I tried following the instructions in your FAQ #7, but I can't do step 1 (boot android). The only way for me to exit the bootloop is by removing the battery. There is no "debug" in /cache after I mount cache in TWRP.
I also looked at FAQ #1. ADB never finishes waiting for the device. In fact "lsusb" doesn't show the phone during OS boot (ADB is fine when TWRP is loaded).
Any other ideas?
Click to expand...
Click to collapse
As written in my mentioned FAQ taken battery out is needed in your case. Step 2 iirc.
If you dont use my LOS then no way. The cache/debug is something I've added and no one else has.
Option1:
You can just flash my LOS 16 or /e/ ROM (take a full backup before in TWRP) and use that for debugging your current issue. Why using microg btw? /e/ is great
Option2:
The other option would be pulling the boot img of your current LOS (in TWRP: adb pull /dev/block/bootdevice/by-name/boot ) and rebuilding it as insecure (i.e. usb debug on and adb root ) but if you never did that before it it will be hard i guess. AiK might work here or using mAid which includes bootimgtool.
Option3:
Also you can attach that boot img here and if i ever find the time i can do option2 for you but don't expext that this happens soon .

Thank you again for your help.
I'm a little afraid that installing a new & different ROM will increase the level of complexity. I'll do it if I must, though.
I started looking at option #2. Retrieving the boot image was fine, but unpacking presents a problem.
$ ./unpack-bootimg.sh boot.img.original
Found a secondary file after the ramdisk image. According to the spec (mkbootimg.h) this file can exist, but this script is not designed to deal with this scenario.
Is there a guide anywhere?

electricfield said:
Thank you again for your help.
I'm a little afraid that installing a new & different ROM will increase the level of complexity. I'll do it if I must, though.
I started looking at option #2. Retrieving the boot image was fine, but unpacking presents a problem.
$ ./unpack-bootimg.sh boot.img.original
Found a secondary file after the ramdisk image. According to the spec (mkbootimg.h) this file can exist, but this script is not designed to deal with this scenario.
Is there a guide anywhere?
Click to expand...
Click to collapse
thousands.. But the problem is that our device is sensitive when it comes to packaging the boot.img again. Bootimgtool is working in 9 of 10 times though.
Boot mAid . Open a terminal. Type bootimgtool --help .important is to use "-v qcom". Then extract the ramdisk with gzip and cpio, then modding the default.prop to make it insecure , then using gzip and cpio again to rebuild the ramdisk, finally using bootimgtool to construct the boot.img again. Sounds harder than it is but i have no access to my pc until monday so i cannot give all the needed cmds atm. There are plenty of guides out there and tools ofc which allow unpack,repack etc. That's why i mentioned AIK which does exactly the above but it fails sometimes to build a correct working boot.img.
So my suggestion is try your luck with one of the tools or wait until I've access to my pc. Consider joining my TG group then for easier support (see my sig)

steadfasterX said:
thousands.. But the problem is that our device is sensitive when it comes to packaging the boot.img again. Bootimgtool is working in 9 of 10 times though.
Boot mAid . Open a terminal. Type bootimgtool --help .important is to use "-v qcom". Then extract the ramdisk with gzip and cpio, then modding the default.prop to make it insecure , then using gzip and cpio again to rebuild the ramdisk, finally using bootimgtool to construct the boot.img again. Sounds harder than it is but i have no access to my pc until monday so i cannot give all the needed cmds atm. There are plenty of guides out there and tools ofc which allow unpack,repack etc. That's why i mentioned AIK which does exactly the above but it fails sometimes to build a correct working boot.img.
So my suggestion is try your luck with one of the tools or wait until I've access to my pc. Consider joining my TG group then for easier support (see my sig)
Click to expand...
Click to collapse
Thank you once again. I'm really impressed by how much help you have been able to give so far.
Unfortunately, I have no phone with which to join the Telegram group.
I made the modified boot image, but adb is still unable to speak to the phone during boot. I note that lsusb does not show the phone during boot -- maybe the system hangs before USB is activated. However, I could have made the boot image incorrectly.
Here is what I did:
[[email protected] extract]$ bootimgtool -i boot
Image size: 41943040
Page size: 4096
Kernel size: 22456976
Ramdisk size: 1672742
Second stage size: 0
Device tree size: 0
Kernel load address: 0x00008000
Ramdisk load address: 0x01000000
Second stage load address: 0x00f00000
Device tree load address: 0x00000000
Tags load address: 0x00000100
Product name:
Command line: maxcpus=4 boot_cpus=0-1 console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.hardware=qcom user_debug=31 ehci-hcd.park=3 lpm_levels.sleep_disabled=1 msm_rtb.filter=0x37 boot_cpus=0-1 buildvariant=userdebug
[[email protected] extract]$ bootimgtool -x boot -v qcom
[[email protected] extract]$ gunzip ramdisk
[[email protected] ex]$ cpio -i < ../ramdisk
In default.prop, I changed:
ro.adb.secure=0
ro.secure=0
security.perf_harden=0
ro.debuggable=0
persist.sys.usb.config=mtp,adb
In default.prop, I added:
persist.service.adb.enable=1
persist.service.debuggable=1
[[email protected] ex]$ find > /tmp/filelist
[[email protected] ex]$ cpio -o < /tmp/filelist > ../ramdisk.modified
This produces
-rw-r--r-- 1 android users 4166400 Jan 2 17:29 ramdisk.gunzip.original
-rw-r--r-- 1 android users 4162048 Jan 2 17:31 ramdisk.modified
-rw-r--r-- 1 android users 1672742 Jan 2 17:16 ramdisk.img.original
I don't understand why the "modified" gunzipped file is slightly smaller than the original.
[[email protected] extract]$ mv ramdisk.modified.gz ramdisk.img
[[email protected] extract]$ cp boot boot.original
[[email protected] extract]$ bootimgtool -v qcom -c boot
Overwrite 'boot'? [y/N] y
-rw-r--r-- 1 android users 25370624 Jan 2 17:38 boot
-rw-r--r-- 1 android users 41943040 Jan 2 17:37 boot.original
I am wary because I don't understand why the new file is so much smaller than the original. However, I decided to proceed. Uploaded modified boot to /sdcard/boot.modified
Inside adb:
/dev/block/platform/soc.0/f9824900.sdhci/by-name # ls -al boot
lrwxrwxrwx 1 root root 21 Jan 1 04:16 boot -> /dev/block/mmcblk0p38
/dev/block/platform/soc.0/f9824900.sdhci/by-name # cp /sdcard/boot.modified /dev/block/mmcblk0p38
Plugged in device. On computer "adb wait-for-device". Reboot device.
Unfortunately, no action from adb.

electricfield said:
Thank you once again. I'm really impressed by how much help you have been able to give so far.
Unfortunately, I have no phone with which to join the Telegram group.
I made the modified boot image, but adb is still unable to speak to the phone during boot. I note that lsusb does not show the phone during boot -- maybe the system hangs before USB is activated. However, I could have made the boot image incorrectly.
Here is what I did:
[[email protected] extract]$ bootimgtool -i boot
Image size: 41943040
Page size: 4096
Kernel size: 22456976
Ramdisk size: 1672742
Second stage size: 0
Device tree size: 0
Kernel load address: 0x00008000
Ramdisk load address: 0x01000000
Second stage load address: 0x00f00000
Device tree load address: 0x00000000
Tags load address: 0x00000100
Product name:
Command line: maxcpus=4 boot_cpus=0-1 console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.hardware=qcom user_debug=31 ehci-hcd.park=3 lpm_levels.sleep_disabled=1 msm_rtb.filter=0x37 boot_cpus=0-1 buildvariant=userdebug
[[email protected] extract]$ bootimgtool -x boot -v qcom
[[email protected] extract]$ gunzip ramdisk
[[email protected] ex]$ cpio -i < ../ramdisk
In default.prop, I changed:
ro.adb.secure=0
ro.secure=0
security.perf_harden=0
ro.debuggable=0
persist.sys.usb.config=mtp,adb
In default.prop, I added:
persist.service.adb.enable=1
persist.service.debuggable=1
[[email protected] ex]$ find > /tmp/filelist
[[email protected] ex]$ cpio -o < /tmp/filelist > ../ramdisk.modified
This produces
-rw-r--r-- 1 android users 4166400 Jan 2 17:29 ramdisk.gunzip.original
-rw-r--r-- 1 android users 4162048 Jan 2 17:31 ramdisk.modified
-rw-r--r-- 1 android users 1672742 Jan 2 17:16 ramdisk.img.original
I don't understand why the "modified" gunzipped file is slightly smaller than the original.
[[email protected] extract]$ mv ramdisk.modified.gz ramdisk.img
[[email protected] extract]$ cp boot boot.original
[[email protected] extract]$ bootimgtool -v qcom -c boot
Overwrite 'boot'? [y/N] y
-rw-r--r-- 1 android users 25370624 Jan 2 17:38 boot
-rw-r--r-- 1 android users 41943040 Jan 2 17:37 boot.original
I am wary because I don't understand why the new file is so much smaller than the original. However, I decided to proceed. Uploaded modified boot to /sdcard/boot.modified
Inside adb:
/dev/block/platform/soc.0/f9824900.sdhci/by-name # ls -al boot
lrwxrwxrwx 1 root root 21 Jan 1 04:16 boot -> /dev/block/mmcblk0p38
/dev/block/platform/soc.0/f9824900.sdhci/by-name # cp /sdcard/boot.modified /dev/block/mmcblk0p38
Plugged in device. On computer "adb wait-for-device". Reboot device.
Unfortunately, no action from adb.
Click to expand...
Click to collapse
Ok i haven't followed every step bc I'm in half sleep mode already but you did one step wrong : you cant use cp like you did to copy the boot img. Either use the IMG button within TWRP flash menu or use fastboot flash boot boot.img to actually flash the modded boot img

Thank you, once again.
I think that something must be wrong with the boot image.
After "fastboot flash boot boot.modified", I get a blue light. The screen is blank with a cursor in the upper-left hand corner.
"fastboot flash boot boot.original" restores it to its previous state. i.e., it gets to the first lineageos splash screen bubble.
I'm suspicious of the difference between the file sizes of the original and modified boot images.

electricfield said:
Thank you, once again.
I think that something must be wrong with the boot image.
After "fastboot flash boot boot.modified", I get a blue light. The screen is blank with a cursor in the upper-left hand corner.
"fastboot flash boot boot.original" restores it to its previous state. i.e., it gets to the first lineageos splash screen bubble.
I'm suspicious of the difference between the file sizes of the original and modified boot images.
Click to expand...
Click to collapse
Ignore the size diff. That's bc of diff compressing tools but does not matter. Your cpio cmd is unusual . Cpio has switches to create directories and that is not used in yours above . Thats likely the reason why it does not boot at all. Again sorry that i can't help better atm but without my pc..

Thanks.
I changed the ramdisk extraction command to:
gzip -dc ../ramdisk.img | cpio -imd
and the creation command to:
find . ! -name . | LC_ALL=C sort | cpio -o -H newc -R root:root | gzip > ../new-boot.img-ramdisk.gz
Bootimgtool then produced a boot image that booted. After fastboot flash, the device is in the same state as before (splash screen).
Unfortunately, "adb wait-for-device" produces nothing. "lsusb" does not show the phone.
Can you confirm the lines to change in default.prop?
In default.prop, I changed:
ro.adb.secure=0
ro.secure=0
security.perf_harden=0
ro.debuggable=0
persist.sys.usb.config=mtp,adb
I added:
persist.service.adb.enable=1
persist.service.debuggable=1

electricfield said:
Thanks.
I changed the ramdisk extraction command to:
gzip -dc ../ramdisk.img | cpio -imd
and the creation command to:
find . ! -name . | LC_ALL=C sort | cpio -o -H newc -R root:root | gzip > ../new-boot.img-ramdisk.gz
Bootimgtool then produced a boot image that booted. After fastboot flash, the device is in the same state as before (splash screen).
Unfortunately, "adb wait-for-device" produces nothing. "lsusb" does not show the phone.
Can you confirm the lines to change in default.prop?
In default.prop, I changed:
ro.adb.secure=0
ro.secure=0
security.perf_harden=0
ro.debuggable=0
persist.sys.usb.config=mtp,adb
I added:
persist.service.adb.enable=1
persist.service.debuggable=1
Click to expand...
Click to collapse
ro.debuggable=1 is better (allows adb root)
security.perf_harden shouldn't be added (or.changed if it was there)
Rest looks ok. At least as long as you really changed these values directly or added them at the top (ro. values can be set only once)
Otherwise you should wait until tomorrow then i can share a 100% working way

electricfield said:
Thanks.
I changed the ramdisk extraction command to:
gzip -dc ../ramdisk.img | cpio -imd
and the creation command to:
find . ! -name . | LC_ALL=C sort | cpio -o -H newc -R root:root | gzip > ../new-boot.img-ramdisk.gz
Bootimgtool then produced a boot image that booted. After fastboot flash, the device is in the same state as before (splash screen).
Unfortunately, "adb wait-for-device" produces nothing. "lsusb" does not show the phone.
Can you confirm the lines to change in default.prop?
In default.prop, I changed:
ro.adb.secure=0
ro.secure=0
security.perf_harden=0
ro.debuggable=0
persist.sys.usb.config=mtp,adb
I added:
persist.service.adb.enable=1
persist.service.debuggable=1
Click to expand...
Click to collapse
Oh wait! Pls share the bootimgtool command you are using to create the new boot.img

Thank you, again.
The bootimgtool command is the same one as I used before (no change). Before running it, I renamed the new ramdisk to ramdisk.img.
bootimgtool -v qcom -c boot.modified3
Followed by bringing the phone into fastboot mode and running
fastboot flash boot boot.modified3
The phone boots to the lineageos splash screen but no response to "adb wait-for-device".
I'll try ro.debuggable=1 and get rid of security.perf_harden in a few minutes, but I wonder if they are unlikely to change anything given that the device does not show up in (linux) lsusb.

electricfield said:
Thank you, again.
The bootimgtool command is the same one as I used before (no change). Before running it, I renamed the new ramdisk to ramdisk.img.
bootimgtool -v qcom -c boot.modified3
Followed by bringing the phone into fastboot mode and running
fastboot flash boot boot.modified3
The phone boots to the lineageos splash screen but no response to "adb wait-for-device".
I'll try ro.debuggable=1 and get rid of security.perf_harden in a few minutes, but I wonder if they are unlikely to change anything given that the device does not show up in (linux) lsusb.
Click to expand...
Click to collapse
That wont change anything if adb does not come up. Just for completeness.
Ok so if you renamed it to ramdisk.img then all.good that was the thing i had in mind (that you didn't and not.used the -r switch). Well ok then without my pc the only thing i can think of might be the USB cable but thats very unlikely

Thanks again for your help.
The boot image that was flashed is definitely the correct one. I extracted it to another folder and checked it before flashing.
I re-made the boot image, but the result is the same (no adb, no device in lsusb).
What "-r switch" are you referring to in your previous message?
The USB cable works fine for ADB in TWRP, so I doubt it is the problem.

electricfield said:
Thanks again for your help.
The boot image that was flashed is definitely the correct one. I extracted it to another folder and checked it before flashing.
I re-made the boot image, but the result is the same (no adb, no device in lsusb).
What "-r switch" are you referring to in your previous message?
The USB cable works fine for ADB in TWRP, so I doubt it is the problem.
Click to expand...
Click to collapse
The -r (iirc) switch was related to bootimgtool. That way you can choose your newly created ramdisk.img but when you renamed it to ramdisk.img it works without.

Thanks.
I would deeply appreciate if you were able to guide me in making the boot image correctly when you have your computer on Monday.
On the other hand, if this method won't work, its best if I know that so that I can try the next thing....

electricfield said:
Thanks.
I would deeply appreciate if you were able to guide me in making the boot image correctly when you have your computer on Monday.
On the other hand, if this method won't work, its best if I know that so that I can try the next thing....
Click to expand...
Click to collapse
ok here you go, this must be added /changed in default.prop:
Code:
ro.adb.secure=0
ro.secure=0
ro.debuggable=1
persist.service.adb.enable=1
persist.service.debuggable=1
persist.sys.usb.config=adb
thumbs pressed

Thank you.
I rebuilt the boot image with these entries, but "adb wait-for-device" still does not work during boot.
Any other ideas?

How To Guide How to backup your partitions with command line (requires root)

How to backup partition images with dd on the command line (root required)​
We don't currently have a working custom recovery for the Xperia 10 III, but if you have root there's a simple method to dump partition images.
This is a very good idea and you should do it at least once, especially if you like to mess around the device a lot.
You won't be able to do this before you root, so by the time you do some partitions will not be stock anymore. Use XperiFirm instead to get the clean stock images.
Special partitions:​
The userdata partition holds all your personal files and system settings. It's huge (about 105 GB) and obviously you can't dump it into itself. You can dump it on an SD card if it's 128+ GB.
The super partition is a physical partition that contains several logical partitions (including system and vendor) That's why you won't find those in the partition list. This is done on Android 10+ devices to allow those logical partitions to be resized or rearranged as needed. You don't need to split out the internal logical partitions, you can flash back the entire super partition. The stock firmware also comes with a super image, not individual logical partitions.
Using a helper script:​There's a Magisk module called Backup (by Draco) which gives you a command line shell script you can use if you prefer. It mostly does the same things I described above. The script is here if anybody wants to just grab it directly.
On the plus side, the script knows to dump only the active A/B image (which is the one that interests you most). On the flip side, it doesn't have a feature to skip userdata.
So here is a shell command that will use the backup script to dump all partitions, but only those matching your device's active A/B slot, and skips userdata:
Code:
backup $(ls /dev/block/bootdevice/by-name/ | grep -v userdata | sed 's/_[ab]$//')
And here's one that also skips super:
Code:
backup $(ls /dev/block/bootdevice/by-name/ | grep -v userdata | grep -v super | sed 's/_[ab]$//')
How to dump partitions manually:​If you can't/won't use the helper script you can do it by hand. All the following commands need root:
Find the names of all the partitions:
Code:
ls /dev/block/bootdevice/by-name/
Dump one specific partition identified by NAME:
Code:
dd if=/dev/block/bootdevice/by-name/NAME of=NAME.img
Dump all partitions except userdata:
Code:
ls /dev/block/bootdevice/by-name/ | grep -v userdata | while read NAME; do echo dd if=/dev/block/bootdevice/by-name/${NAME} of=${NAME}.img; done
Find the active slot:
Code:
getprop ro.boot.slot_suffix
Get checksums for all the images after the dump:
Code:
md5sum *.img
Confused about _a and _b partitions?​You should read about A/B Seamless Updates.
Long story short, some partitions have two copies eg. boot_a and boot_b. When you boot up the device you use the partitions in one slot (eg. the _a partitions). When an OTA update is being downloaded, it writes into the partitions for the other slot (eg. the _b partitions). Your phone can stay in use while this happens. If the OTA fails nothing is broken, you just keep using the good slot partitions. After the OTA is successful you switch to the other slot and also have the previous version in the other slot in case you need to switch back.
This means that some of the _a and _b images for the same partition can be different for you! So it's strongly recommended to do the checksums, and also to find out which is your active slot, so you know which partitions you're using right now.

I used a 128 GB card to take a backup of userdata. The backup script had some trouble with the backup location being on the storage card for some reason and I didn't have time to figure it out, but the dd command I gave above worked fine.
Code:
# time dd if=/dev/block/bootdevice/by-name/userdata of=userdata.img
112111374336 bytes (104 G) copied, 2342.274225 s, 46 M/s
39m02.31s real 1m11.78s user 14m44.72s system
Code:
# adb pull /storage/1234-ABCD/backup/userdata.img ./
/storage/1234-ABCD/backup/userdata.img: 1 file pulled, 0 skipped.
87.2 MB/s (112111374336 bytes in 1225.663s)
So that's 104 GB that took 39 minutes to be written to a new Samsung Evo U3/V30 microSDXC (46 MB/sec real write speed) and 20 minutes to be read to the PC (Samsung Evo M.2) with adb pull over USB (87 MB/sec read speed). Just so you know what you're in for.

I was looking into whether I could speed up the process of taking userdata snapshots by dumping the partition directly to the PC, but you need to be root to access the device block. The stock ROM doesn't allow the command adb root, but I found this blog post which made me realize you can run a su -c command that asks dd to write to stdout and just pipe the output to a file. The post author has also made this helpful Python script which lets you do pulls and pushes with root-only files.
If you want to run the command directly (I've only tested on Linux, no idea if it works on PowerShell but it might):
Code:
# adb shell "su -c" "dd if=/dev/block/bootdevice/by-name/userdata" > userdata.img
If you want to use the Python script:
Code:
# adb-root.py pull /dev/block/bootdevice/by-name/userdata userdata.img
Using the same fast SSD on the PC side as above, I now get:
Code:
218967528+0 records in
218967528+0 records out
112111374336 bytes (104 G) copied, 1077.681097 s, 99 M/s
real 17m57.910s
So that's roughly 15 minutes compared to 1 hour total with the previous method and you don't need to have a 128 GB SD card anymore.

Are you able to switch to a different backup location? Say a USB OTG if possible.

mikeshutte said:
Are you able to switch to a different backup location? Say a USB OTG if possible.
Click to expand...
Click to collapse
With dd yes, simply move to the directory you want before you call dd.
The backup script is bugged and seems to ignore the -d parameter for the backup location so it always uses /sdcard/backup. (I think it might be expecting a different version of getopts...) Normally I would say to try creating a symlink from /sdcard/backup to the OTG storage but the ln utility is also behaving strangely and I can't make any symlinks (even with root).

wirespot said:
With dd yes, simply move to the directory you want before you call dd.
The backup script is bugged and seems to ignore the -d parameter for the backup location so it always uses /sdcard/backup. (I think it might be expecting a different version of getopts...) Normally I would say to try creating a symlink from /sdcard/backup to the OTG storage but the ln utility is also behaving strangely and I can't make any symlinks (even with root).
Click to expand...
Click to collapse
Ok I'll give it a try and see what happens. Thanks for your help.

Hi, I'm used to TWRP backups, so I don't really understand this tool. I've backedup everything except the massive userdata partition. If needed, how would I restore this? Is the userdata partition required when I have all the others?
Thanks!

jakito said:
Hi, I'm used to TWRP backups, so I don't really understand this tool. I've backedup everything except the massive userdata partition. If needed, how would I restore this? Is the userdata partition required when I have all the others?
Thanks!
Click to expand...
Click to collapse
This is basically the same thing that TWRP does, dd is a command line Linux tool that makes a "raw" copy of a partition.
Restoration is a bit more tricky. In theory you can simply dump the raw backup copy over the partition. The problem is that it's not ok to do it while the system is running. Typically it's done by booting into recovery (TWRP) and overwriting the partition from there.
Another method for restore is to use fastboot, which is an alternative tool you can boot into that only does one thing, write partitions. But fastboot is typically locked by the vendor to only write signed images, so it can only be used to write official release ROMs.
There are some limited uses for fastboot, such as overwriting the boot partition, which is not checked for signature anymore once you've unlocked the bootloader. So if you want to experiment with unofficial kernels and mess something up you can always restore a good boot partition with fastboot.
TLDR: for the time being until we get a working TWRP recovery the most you can do is take backups, but not restore them.

wirespot said:
This is basically the same thing that TWRP does, dd is a command line Linux tool that makes a "raw" copy of a partition.
Restoration is a bit more tricky. In theory you can simply dump the raw backup copy over the partition. The problem is that it's not ok to do it while the system is running. Typically it's done by booting into recovery (TWRP) and overwriting the partition from there.
Another method for restore is to use fastboot, which is an alternative tool you can boot into that only does one thing, write partitions. But fastboot is typically locked by the vendor to only write signed images, so it can only be used to write official release ROMs.
There are some limited uses for fastboot, such as overwriting the boot partition, which is not checked for signature anymore once you've unlocked the bootloader. So if you want to experiment with unofficial kernels and mess something up you can always restore a good boot partition with fastboot.
TLDR: for the time being until we get a working TWRP recovery the most you can do is take backups, but not restore them.
Click to expand...
Click to collapse
I see. Thank you nonetheless!

wirespot said:
This is basically the same thing that TWRP does, dd is a command line Linux tool that makes a "raw" copy of a partition.
Restoration is a bit more tricky. In theory you can simply dump the raw backup copy over the partition. The problem is that it's not ok to do it while the system is running. Typically it's done by booting into recovery (TWRP) and overwriting the partition from there.
Another method for restore is to use fastboot, which is an alternative tool you can boot into that only does one thing, write partitions. But fastboot is typically locked by the vendor to only write signed images, so it can only be used to write official release ROMs.
There are some limited uses for fastboot, such as overwriting the boot partition, which is not checked for signature anymore once you've unlocked the bootloader. So if you want to experiment with unofficial kernels and mess something up you can always restore a good boot partition with fastboot.
TLDR: for the time being until we get a working TWRP recovery the most you can do is take backups, but not restore them.
Click to expand...
Click to collapse
I don't know how I ended up but making a backup you can't restore is completely pointless.

Techguy777 said:
I don't know how I ended up but making a backup you can't restore is completely pointless.
Click to expand...
Click to collapse
No, it's not. All your data is in there. You can mount your backup on a linux computer and pull out apks as well as app data. You can then restore these folder by folder with adb and a root shell on your phone.
That beeing said, does anyone know a proper backup software like Titanium Backup for Android 11 and above? Sometimes I read recommendations, but looking at the ratings it seems that no software manages to achieve the same level of comfort and control. Also they all seem to suffer from the same limitations.
Let's be honest: Google wants to make your life hard, so they can lock you in.

@xperinaut
I'm using Titanium on Android 11. Is it not working for you?

(Journal) A successful attempt at fixing a hard-hardbricked Redmi Note 9 (Global) on Fedora

A long time ago, I posted in a forum thread about my difficulty in trying to revive my M2003J15SG and after having my ethereal Windows install bricked. I switched to Fedora and tried my hand there, where surprisingly, things worked very well. I'm not calling this a guide because I'm basically piecing this together from my bash_history and recollection. I have used the word guide too many times to keep that sentence but yeah, it may be shaky in some places.
Disclaimer​
Code:
/*
* Your warranty is... still valid?
*
* 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.
*
* I have removed the part about laughing at you because I'm not a meanie :3
*
* But yeah, this text is as-is. We provide this work to you without
* warranty of any kind, express or implied and in no event shall the authors
* be liable for any claim, damages or other liability in any way, shape or form,
* arising from, out of, in connection with the work
*
*/
A few things to note​
This is an attempt to document my experience with BROM recovery of a phone that I bricked because I flashed an incorrect littlekernel image. If you're able to use other methods (using fastboot, recovery mode, hell, even preloader mode, you should probably go with that, this is a last resort).
This guide does involve opening your device, you will need a heat gun, a few picks and a screwdriver. No, this is not optional.
If you've read the excellent guide by VD171 on bypassing authentication and flashing, you may notice the important text that states
> Once you get "Protection disabled" at the end, without disconnecting phone and usb, run SP Flash Tool
That's because if you do disconnect and attempt to reconnect your device, it won't be recognized anymore. On Windows, this manifests as the infamous "USB device not recognized" error. This isn't you installing incorrect drivers, that's the device behaving erratically.
To have a second go at it, you have to press Vol Up + Power for about 60 seconds before you can retry.
To enter BROM mode, you need to press Vol Down and no other key, and then plug in your device.
This guide while being Fedora-specific, could be translated to other Linux distros assuming you have the necessary packages installed and have the appropriate permissions and udev rules set
This model of device doesn't need the kamakiri-specific kernel patch
On RHEL-like distros like Rocky Linux and... RHEL, you may need to disable SELinux. I have mine disabled at install so I'm not sure how this guide will behave with SELinux enforcement enabled.
Click to expand...
Click to collapse
Ingredients​
Stock MIUI ROM V11.0.5.0.QJOMIXM (the fastboot variant), which you can get from XiaomiFirmwareUpdater
SP Flash Tool v5.2020 for Linux, which you can get from SPFlashTools
VD171's readback_ui_bak.xml, which you can get from their XDA Forums thread
VD171's scatterfiles for V11.0.5.0.QJOMIXM, which you can get from their XDA forums thread
You'll specifically need MT6768_Android_scatter--V11.0.5.0.QJOMIXM--boundary_false.txt and MT6768_Android_scatter--V11.0.5.0.QJOMIXM--download_true--boundary_false.txt
mtkclient, an MTK device exploit kit, which you can find on their GitHub (you'll need their master branch, not their releases, so there'll be instructions on how to fetch it)
A box of chocolate chip cookies
Click to expand...
Click to collapse
a) Preparing the computer​
Step 0: Extract all ingredients and put them into one directory for ease of access
You can do this via the command line or through your file manager, it's just for convinence. This guide will assume that everything is done in one neat folder.
Click to expand...
Click to collapse
Step 1: Install all the dependencies you'll need
Bash:
sudo dnf install android-tools git libusb-devel python3 python3-pip systemd-udev
Step 2: Prevent Linux from interfering with MediaTek serial connections
Bash:
sudo touch /etc/udev/rules.d/20-mm-blacklist-mtk.rules
echo "ATTRS{idVendor}==\"0e8d\", ENV{ID_MM_DEVICE_IGNORE}=\"1\"" | sudo tee /etc/udev/rules.d/20-mm-blacklist-mtk.rules
echo "ATTRS{idVendor}==\"6000\", ENV{ID_MM_DEVICE_IGNORE}=\"1\"" | sudo tee -a /etc/udev/rules.d/20-mm-blacklist-mtk.rules
Step 3: Clone mtkclient and install its dependencies
Bash:
git clone https://github.com/bkerler/mtkclient
cd mtkclient
pip3 install -r requirements.txt
python3 setup.py build
sudo python3 setup.py install
Step 4: Install mtkclient's bundled udev rules
Bash:
sudo usermod -a -G dialout $USER
sudo cp Setup/Linux/*.rules /etc/udev/rules.d
Step 5: Reload udev rules
Bash:
sudo udevadm control --reload-rules
sudo udevadm trigger
Step 6: Return to previous directory
Bash:
cd ..
b) Preparing the device​
This is where you basically follow this iFixit guide for the purposes of just disconnecting the battery cable. So, just stop at Step 12, then put the back cover on just flush enough that you can now click the volume and power buttons and insert a cable into the USB-port but not too much so that you have to go through the effort of reopening it again (because, well, you'll have to).
Attempting to skip this will yield you STATUS_EXT_RAM_EXCEPTION.
Click to expand...
Click to collapse
c) Backing everything up​
Alongside ROM and userdata, your EMMC contains your IEMI, your bootloader lock state, MAC addresses, calibration data, the whole nine yards. It's always a good idea to back things up before we get started.
Step 1: Copy readback_ui_bak.xml to the SP Flash Tool directory
Bash:
cp ./readback_ui_bak.xml ./SP_Flash_Tool_v5.2020_Linux/readback_ui_bak.xml
Step 2: Connecting your device and applying the exploit
Start off by running the exploit.
Bash:
cd mtkclient
chown +x mtk
./mtk payload
Once it says Preloader - Status: Waiting for PreLoader VCOM, please connect mobile, hold down Vol Down and connect your phone to the computer. If everything goes according to plan, you'll get an output similar to this.
Code:
Port - Device detected :)
Preloader - CPU: MT6768/MT6769(Helio P65/G85 k68v1)
Preloader - HW version: 0x0
Preloader - WDT: 0x10007000
Preloader - Uart: 0x11002000
Preloader - Brom payload addr: 0x100a00
Preloader - DA payload addr: 0x201000
Preloader - CQ_DMA addr: 0x10212000
Preloader - Var1: 0x25
Preloader - Disabling Watchdog...
Preloader - HW code: 0x707
Preloader - Target config: 0xe7
Preloader - SBC enabled: True
Preloader - SLA enabled: True
Preloader - DAA enabled: True
Preloader - SWJTAG enabled: True
Preloader - EPP_PARAM at 0x600 after EMMC_BOOT/SDMMC_BOOT: False
Preloader - Root cert required: False
Preloader - Mem read auth: True
Preloader - Mem write auth: True
Preloader - Cmd 0xC8 blocked: True
Preloader - Get Target info
Preloader - BROM mode detected.
Preloader - HW subcode: 0x8a00
Preloader - HW Ver: 0xca00
Preloader - SW Ver: 0x0
Preloader - ME_ID: [redacted]
Preloader - SOC_ID: [redacted]
PLTools - Loading payload from mt6768_payload.bin, 0x264 bytes
PLTools - Kamakiri / DA Run
Kamakiri - Trying kamakiri2..
Kamakiri - Done sending payload...
PLTools - Successfully sent payload: [redacted]/mtkclient/mtkclient/payloads/mt6768_payload.bin
Click to expand...
Click to collapse
Step 3: Open SP Flash Tool
Bash:
cd ../SP_Flash_Tool_v5.2020_Linux
chmod +x flash_tool
sudo ./flash_tool
Yes, I'm aware, it's technically not advisable to grant superuser privileges to, a flashing tool but... I can't get it to work otherwise, if you know how to make it work on Fedora, drop a comment.
Click to expand...
Click to collapse
Step 4: Load the Download Agent (DA)
Click "Choose" and go to (common directory)/mtkclient/mtkclient/Loader/xiaomi_9_DA_6765_6785_6768_6873_6885_6853.bin
Click to expand...
Click to collapse
Step 5: Configure SP Flash Tool
Go to Options > Option
In General, uncheck "Storage Lifecycle Check"
In Connection, select "UART"
COM Port: /dev/ttyACM0 (it may not be the exact number, it'll just look something similar to this)
Baud rate: 921600
In Download
Uncheck "USB Checksum"
Uncheck "Storage Checksum"
Click to expand...
Click to collapse
Step 6: Backup device contents
Start by going to the "Readback" tab, it should already be populated with values that correspond to images from pgpt to otp. If you are presented with an empty table, you've need to go back and check if you've copied readback_ui_bak.xml to the correct directory.
If it shows up, then click "Read Back" and if all goes according to plan, you should see the green checkmark show up eventually.
Click to expand...
Click to collapse
d) Flashing stock firmware​Step 1: Copy scatterfiles to ROM directory
Bash:
cp ./MT6768_Android_scatter--V11.0.5.0.QJOMIXM--boundary_false.txt ./merlin_global_images_V11.0.5.0.QJOMIXM_20200609.0000.00_10.0_global/images/MT6768_Android_scatter--V11.0.5.0.QJOMIXM--boundary_false.txt
cp ./MT6768_Android_scatter--V11.0.5.0.QJOMIXM--download_true--boundary_false.txt ./merlin_global_images_V11.0.5.0.QJOMIXM_20200609.0000.00_10.0_global/images/MT6768_Android_scatter--V11.0.5.0.QJOMIXM--download_true--boundary_false.txt
Step 2: Flash the firmware
Return to the "Download" tab and select the MT6768_Android_scatter--V11.0.5.0.QJOMIXM--boundary_false.txt scatterfile we just copied in the ROM's images directory
Select "Firmware Upgrade" from the drop-down menu and then hit "Download". If all goes according to plan, you should see a green checkmark.
Click to expand...
Click to collapse
Step 3: Restore bootloader status (optional)
In case you had an unlocked bootloader before imploding your phone and don't want to bother with Xiaomi's rigmarole, then by restoring seccfg, you should get it back.
Step 3.1: Copy over seccfg from our backup
You're probably going to be using a new terminal window because SP Flash is still running, navigate to your common directory first. The backup we did earlier stored all the images within the SP Flash Tool directory. We need to use sudo because flash_tool was running with root privileges and so, was writing with root privileges as well.
Bash:
sudo cp ./SP_Flash_Tool_v5.2020_Linux/seccfg ./merlin_global_images_V11.0.5.0.QJOMIXM_20200609.0000.00_10.0_global/images/seccfg
Step 3.2: Change the scatterfile, select the image and flash it
Change the scatterfile to MT6768_Android_scatter--V11.0.5.0.QJOMIXM--download_true--boundary_false.txt and un-select everything except seccfg
Select "Download Only" from the drop-down menu and then hit "Download". Fingers crossed, green checkmark, you should get your unlock back.
Click to expand...
Click to collapse
Step 4: Reconnect your battery and first boot
If you've reached this point and everything has worked as expected, reconnect your battery, long press the Power button and you should be greeted with a boot animation and hopefully a functioning phone.
Click to expand...
Click to collapse
e) Packing it up​
Basically, just... follow the iFixit guide from Step b) in reverse and seal up your phone. I don't use this phone regularly so I never bothered sealing it, relying only on the plastic clips. You probably should but that's outside the scope of this journal.
Click to expand...
Click to collapse

f) Upgrading to Android 11 (optional)​
As of this writing, LineageOS supports this device under the codename merlinx (the x is because of a conflict with the Moto G3 Turbo, which shares the same codename) and according to their install documentation, they expect a base of Android 11 and this guide flashes Android 10.
I personally used the V12.5.4.0.RJOMIXM firmware (available from XiaomiFirmwareUpdater, again, use the fastboot version) but I did an ever-so-slight change. The entire song-and-dance of needing the bypass exploit is because of "upgrades" made to the payload. I modified flash_all.sh to omit flashing the payload and the modification looks something like this (the other comment-outs were already there in the file)
Bash:
(...)
#fastboot $* flash preloader `dirname $0`/images/preloader_merlin.bin
#if [ $? -ne 0 ] ; then echo "Flash preloader error"; exit 1; fi
#fastboot $* flash efuse `dirname $0`/images/efuse.img
#if [ $? -ne 0 ] ; then echo "Flash efuse error"; exit 1; fi
fastboot $* flash logo `dirname $0`/images/logo.bin
if [ $? -ne 0 ] ; then echo "Flash logo error"; exit 1; fi
fastboot $* flash tee1 `dirname $0`/images/tee.img
"Flash preloader error"; exit 1; fi
(...)
I also commented out the reboot command at the end so I could flash LineageOS's recovery and flash the OS that I wanted.
Bash:
(...)
#fastboot $* reboot
#if [ $? -ne 0 ] ; then echo "Reboot error"; exit 1; fi
(...)
Of course, you need to boot into fastboot mode (by taking a turned off device and pressing Power + Vol Down) before you execute the script
Code:
cd merlin_global_images_V12.5.4.0.RJOMIXM_20220325.0000.00_11.0_global
chmod +x flash_all.sh
./flash_all.sh
Click to expand...
Click to collapse
Sources​
https://github.com/bkerler/mtkclient
https://github.com/bkerler/mtkclient/issues/94
https://www.hovatek.com/blog/my-experience-unbricking-a-dead-boot-lg-stylo-6/
https://forum.xda-developers.com/t/...omi-redmi-10x-4g-xiaomi-redmi-note-9.4221065/
https://forum.xda-developers.com/t/...for-merlin-redmi-10x-4g-redmi-note-9.4238149/
https://forum.xda-developers.com/t/...omi-redmi-10x-4g-xiaomi-redmi-note-9.4223107/
https://forum.xda-developers.com/t/...omi-redmi-10x-4g-xiaomi-redmi-note-9.4223093/

Wow !
Really amazing guide !
Nice, nice
Thank you very much for contribution