This project is inspired by the thread here by Q9Nap
TWRP Flashable Stock Builds
In that thread, Q9Nap (and later me, although in an unofficial capacity) has created TWRP Flashable builds of the stock rom. These would have been based upon the full fastboot flashable stock images, and then OTA patches from those roms.
Although the tools used have been provided in that thread, there isn't a guide saying how to use them. (I originally posted parts of this guide in that thread, but this is to consolidate it all into one project.) So in the below posts, I'll go through the actual process of generating the TWRP flashable builds themselves.
This project is divided into the following posts:
Tools required
Creating a TWRP flashable build from an existing TWRP flashable build + OTA patch
Creating a TWRP flashable build from the fastboot iamges
Here is the link to the builds that I have created. Other older ones are in the thread mentioned at the top of this post.
https://www.androidfilehost.com/?w=files&flid=273039
Finally, this guide could also be used in principle for other devices, however there may be some device or vendor-specific differences.
XDA:DevDB Information
[GUIDE] Creating TWRP Flashbale Stock roms, ROM for the Moto G5 Plus
Contributors
NZedPred
ROM OS Version: 7.x Nougat
Version Information
Status: Stable
Created 2018-06-16
Last Updated 2018-06-16
Tools and other pre-requisites
Pre-requisites
This has been done entirely on Linux, Debian Stretch to be precise. Other 64 bit modern distros should work fine.
In all cases, it is assumed that you have extract or copy the relevant files into somewhere in your PATH.
1) IMG Patch Tools
The link to the IMG Patch Tools is here:
https://forum.xda-developers.com/an...ev-img-patch-tools-sdat2img-ota-zips-t3640308 - credits to @erfanoabdi
Repo is here:
https://github.com/erfanoabdi/imgpatchtools
The first post is a description of what the tool does. The second explains usage. The third contains download links.
Download the Release version from the first link in the third post. Note that the tools are only available for Linux_x64 and MacOS.
In my case I needed to compile them on my system. Follow the instructions as per the second post. I needed to install the development libraries for zlib and libbz2, and openssl:
sudo apt-get install libbz2-dev zlib1g-dev openssl
2) IMG Repack Tools
The link to the Android img Repack Tools is here:
https://forum.xda-developers.com/android/general/tool-android-rom-repack-tools-t3763986 - credits to @rkhat
Releases:
https://github.com/rkhat2/android-rom-repacker/releases
Source:
https://github.com/rkhat2/android-rom-repacker/tree/android-7
Download and extract the android-7 / nougat version
3) IMG to SDAT and SDAT to IMG tools
The link to the img2sdat and sdat2img tools is here:
https://forum.xda-developers.com/an.../how-to-conver-lollipop-dat-files-to-t2978952 - credits to @expirt
Repos are here:
https://github.com/xpirt/img2sdat
https://github.com/xpirt/sdat2img
4) Boot image tools
Get the mkbootimg tools available here:
https://github.com/xiaolu/mkbootimg_tools
Don't know of any XDA thread or developer for these.
5) SparseConverter
SparseConverter is needed to convert the Fastboot sparse chunks into an image file. This is only required for creating a TWRP flashable build from the Fastboot image files. It is not needed for an existing TWRP flashable build.
The link to SparseConverter, both the binary and source code, is here:
https://forum.xda-developers.com/showthread.php?t=2749797 - credits to @tal.aloni
In my case, I downloaded the source code and compiled it using MonoDevelop. You can open the Visual Studio Solution file (.sln) in MonoDevelop and compile. It may also be possible to download the binary and execute it using mono. If you choose this route, adjust commands below to suit. I haven't tried this myself, so if it doesn't work try compiling it from source.
6) TWRP Flashable Template zip
Another requirement for building a TWRP flashable zip from the Fastboot images is to have a suitable template zip. I have created one and placed it here:
https://www.androidfilehost.com/?fid=5862345805528045057
7) Brotli
Brotli is a loss-less compression format that is now being used in the Oreo OTAs. Its file extension is br. You can get the latest release/source code from here:
https://github.com/google/brotli/releases
8) lz4
In some cases, device tree images are compressed using lz4. This is a standard part of many linux distributions. Use the following on Debian/Ubuntu:
Code:
sudo apt install liblz4-tool
9) A hex editor
Editing the device tree binary/blob needs a hex editor. I have used dhex because it can be used over the command line. Use the following on Debian/Ubuntu:
Code:
sudo apt install dhex
Any other hex editor will suffice.
Change log of this post
2018-06-17 - add in SparseConverter details, TWRP template zip.
2018-07-10 - change link to TWRP Flashable template - new one is edited to NOT erase modemst1 and modemst2.
2018-08-19 - add in Brotli, required for new Oreo OTAs.
2018-09-09 - add in lz4 and hex editor requirements.
2018-10-14 - add in link to sdat2img repo. Properly tag the authors of the different tools that I use (where available).
Create TWRP Flashable from existing TWRP Flashable
Create TWRP Flashable zip from Existing TWRP Flashable
1) Get an existing TWRP flashable
You can download the latest TWRP Nougat flashables for Potter from here:
[Nougat][Stock][Rom] TWRP Flashable Stock Builds
The latest TWRP Oreo flashables for Potter are here:
[Oreo][Stock][Rom] TWRP Flashable Stock Builds
I also put together some TWRP flashables for other devices, such as Cedric (G5) and Sanders (G5S Plus). Have a search under my profile at Android File Host:
Downloads for Android Devices by nzedpred
Extract it to a folder, e.g. "next", that represents the next version that you will be creating. Enter the folder.
All commands are run from within this folder. If a folder is created as part of the instructions, I assume that the folder is not entered.
2) Convert sparse data images to img
With the sdat2img tool, convert the system, oem, and modem images to raw images:
Code:
sdat2img.py system.transfer.list system.new.dat system.img
sdat2img.py oem.transfer.list oem.new.dat oem.img
sdat2img.py modem.transfer.list modem.new.dat modem.img
3) Analyse the OTA and apply patching and updates
Unzip the ota upgrade files into a sub-folder ota.
Code:
unzip path/to/ota/Blur_Version.x.y.z.zip -d ota
In the OTA extract, open up the updater-script in a text editor
Code:
ota/META-INF/com/google/android/updater-script
The first parts of the script are to check for valid OEM, Recovery and System partitions from the previous version. The parts we're interested in start below the line:
Code:
# ---- start making changes here ----
New in Oreo
In Nougat, many of the files below are named e.g. system.new.dat. Oreo may have these files named e.g. system.new.dat.br. These "br" files are Brotli compressed files. Look for any files that are named as such, e.g.
Code:
ls ota/*.br
ota/dsp.new.dat.br ota/system.new.dat.br
In the example above, I get two files that are Brotli compressed. Decompress these using the following:
Code:
brotli --decompress --input ota/dsp.new.dat.br --output ota/dsp.new.dat
brotli --decompress --input ota/system.new.dat.br --output ota/system.new.dat
** System **
The first line that makes updates to the system image is this one for Nougat:
Code:
block_image_update("/dev/block/bootdevice/by-name/system", package_extract_file("system.transfer.list"), "system.new.dat", "system.patch.dat")
or Oreo:
Code:
block_image_update("/dev/block/bootdevice/by-name/system", package_extract_file("system.transfer.list"), "system.new.dat.br", "system.patch.dat")
The only difference between Nougat and Oreo is the "br" in system.new.dat.br. As we have decompressed the Brotli files in the previous steps, we only need to use sytem.new.dat.
The equivalent command to imitate this command is the following:
Code:
BlockImageUpdate system.img ota/system.transfer.list ota/system.new.dat ota/system.patch.dat
Check that the error code returned is 0.
** Boot **
The next line that makes updates to the boot image is this one:
Code:
apply_patch("EMMC:/dev/block/bootdevice/by-name/boot:16777216:f6ee50c0900378319080912820b5c20f4bb7051c:16777216:19b3ba799fd8f57588ff3736f1a1c0070417f4c2",
"-", 19b3ba799fd8f57588ff3736f1a1c0070417f4c2, 16777216,
f6ee50c0900378319080912820b5c20f4bb7051c,
package_extract_file("patch/boot.img.p"))
The equivalent command to imitate this is the following:
Code:
ApplyPatch boot.img - 19b3ba799fd8f57588ff3736f1a1c0070417f4c2 16777216 f6ee50c0900378319080912820b5c20f4bb7051c ota/patch/boot.img.p
NOTE: You will need to update the strings above to match what is in the OTA update script, which will differ from OTA to OTA.
NOTE: This will fail if we use the version straight from the previous flashable zip, as that version may have already been patched to disable dm-verity and disable forced encryption. We need to get a version from the stock image.
Also note, that as part of creating these zips, I leave the original unmodified boot.img file as a copy, boot-stock.img or similar. When patching, simply rename it to boot.img before doing the ApplyPatch command
Code:
mv boot-stock.img boot.img -fv
Check that the error code returned is 0.
** Bootloader **
The bootloader also gets updated quite often. Note that as part of making these zips safer, we don't update the bootloader, so skip right past them. These lines look something like this:
Code:
ui_print("updating sbl1 ...");
assert(package_extract_file("sbl1.mbn", "/tmp/sbl1.mbn"),
apply_raw_image("/tmp/sbl1.mbn", "sbl1"),
delete("/tmp/sbl1.mbn"));
Refer to post #13 to see details of how to work out which partitions are bootloader-related. In brief, the following are bootloader-related:
aboot
rpm
tz
devcfg
cmnlib
cmnlib64
keymaster
prov
sbl1
** MODEM **
When the modem is updated, it tends to be done using a few different techniques. Sometimes it uses one of the approaches above, other times it is untouched, and finally it can have a combination of deleting, patching and copying new files.
To apply changes that are done by deleting, patching and copying, first set up a mount point, mount the image, and make sure you have any of the tools in the path of the root user, as these need to be run as root.
Code:
mkdir modem
sudo su
mount modem.img modem
export PATH=$PATH:/path/to/tools
An example of deleting:
Code:
ui_print("Removing unneeded files from modem...");
delete("/modem/image/Ver_Info.txt", "/modem/image/cmnlib.b04",
"/modem/image/fpctzappfingerprint.b04",
"/modem/image/fpctzappfingerprint.b05", "/modem/image/modem.b17",
"/modem/image/qdsp6m.qdb", "/modem/image/dhsecapp.b00",
etc...
The equivalent of these are:
Code:
rm modem/image/Ver_Info.txt
rm modem/image/cmnlib.b04
rm modem/image/fpctzappfingerprint.b04
etc...
Take very special care to remove the leading slash before modem. You don't want to risk deleting files on your PC's filesystem.
An example of patching:
Code:
ui_print("Patching modem files...");
apply_patch("/modem/image/adsp.b00", "-",
42ae9e4a8a04b70938c6fda6bef2ad7063ccba15, 532,
6df377596db8273c268691fb87380c416128502c,
package_extract_file("patch/modem/image/adsp.b00.p")) ||
abort("E3008: Failed to apply patch to /modem/image/adsp.b00");
apply_patch("/modem/image/adsp.b01", "-",
13500067ce0564e2d45780d5511271f8d195a598, 6920,
3ee7f84d3e81a44725554ac24d001cff21a636ab,
package_extract_file("patch/modem/image/adsp.b01.p")) ||
abort("E3008: Failed to apply patch to /modem/image/adsp.b01");
etc...
The equivalent of these are:
Code:
ApplyPatch modem/image/adsp.b00 - 42ae9e4a8a04b70938c6fda6bef2ad7063ccba15 532 6df377596db8273c268691fb87380c416128502c ota/patch/modem/image/adsp.b00.p
ApplyPatch modem/image/adsp.b01 - 13500067ce0564e2d45780d5511271f8d195a598 6920 3ee7f84d3e81a44725554ac24d001cff21a636ab ota/patch/modem/image/adsp.b01.p
etc...
An example of copying:
Code:
ui_print("Unpacking new files in modem ...");
assert(package_extract_dir("modem", "/modem"));
The equivalent of this is:
Code:
cp -rv ota/modem/* modem/
You will probably also see something like:
Code:
ui_print("Symlinks and permissions in modem ...");
set_metadata_recursive("/modem/", "uid", 0, "gid", 0, "dmode", 0755, "fmode", 0644, "capabilities", 0x0);
That sets permissions of folders and files to 0755 and 0644 respectively. This can be achieved by:
Code:
find modem/ -type d -exec chmod 0755 {} \;
find modem/ -type f -exec chmod 0644 {} \;
When finished, unmount modem.img, exit the root shell, and remove the mount folder:
Code:
umount modem
exit
rmdir modem
** OEM **
The line that updates the oem image is this one:
Code:
block_image_update("/dev/block/bootdevice/by-name/oem", package_extract_file("oem.transfer.list"), "oem.new.dat", "oem.patch.dat")
The equivalent command to imitate this is the following:
Code:
BlockImageUpdate oem.img ota/oem.transfer.list ota/oem.new.dat ota/oem.patch.dat
Check that the error code returned is 0.
** DSP **
Occasionally the dsp partition is also updated. It will use one of the techniques above, e.g.
Code:
block_image_update("/dev/block/bootdevice/by-name/dsp", package_extract_file("dsp.transfer.list"), "dsp.new.dat.br", "dsp.patch.dat")
Has the equivalent command:
Code:
BlockImageUpdate adspso.bin ota/dsp.transfer.list ota/dsp.new.dat ota/dsp.patch.dat
Note that the equivalent of the dsp partition is the adspso.bin file.
** FSG **
If FSG is updated, you will often see something like this:
Code:
assert(package_extract_file("fsg.mbn", "/tmp/fsg.mbn"),
apply_raw_image("/tmp/fsg.mbn", "fsg"),
delete("/tmp/fsg.mbn"));
This doesn't represent a patch being applied. Instead the file would just be copied from the OTA folder into the base folder. This applies to any other file that hasn't been patched in one of the ways above (except the bootloader).
** Others **
At this point, check if there are other (non-bootloader) partitions in the updater-script. This should have covered off all, but a future device may have other partitions that follow this (or a new) technique.
One that is present that I haven't used here, is logo.bin being copied over the logo partition. I tend to leave this as-is, as I prefer/recommend that people flash the logo as a one-off, and preferably grab a "Hidden N/A" from the themes forum.
4) Disable dm-verity and forced encryption
There are two different techniques to disabling dm-verity and forced encryption, one for Nougat and one for Oreo. Refer to the appropriate section below.
4a) Nougat - Disable dm-verity and forced encryption in boot
Nougat has the flags for enabling/disabling dm-verity and forced encryption in the boot image. These instructions are based upon looking at the scripts in the files here:
https://build.nethunter.com/android-tools/no-verity-opt-encrypt/
Make a copy of the boot.img file, so that we have the original for the next ota. This is important, as without the original, the next time we try to apply the patch, it will fail.
Code:
cp boot.img boot-stock.img
Extract the boot image:
Code:
mkboot boot.img bootimg
Modify the fstab file in a text editor:
Code:
bootimg/ramdisk/fstab.qcom
Remove any instances of verify. For example, the below line:
Code:
/dev/block/bootdevice/by-name/system /system ext4 ro,barrier=1,discard wait[U],verify[/U]
Can be changed to:
Code:
/dev/block/bootdevice/by-name/system /system ext4 ro,barrier=1,discard wait
If the section "wait,verify" was in fact just "verify", we would need to replace it with "defaults"
Replace any instances of forceencrypt or forcefdeorfbe with encryptable
E.g. the below line:
Code:
/dev/block/bootdevice/by-name/userdata /data f2fs rw,discard,nosuid,nodev,noatime,nodiratime,nobarrier,inline_xattr,inline_data wait,check,formattable,[U]forceencrypt[/U]=/dev/block/bootdevice/by-name/metadata
Can be changed to:
Code:
/dev/block/bootdevice/by-name/userdata /data f2fs rw,discard,nosuid,nodev,noatime,nodiratime,nobarrier,inline_xattr,inline_data wait,check,formattable,[U]encryptable[/U]=/dev/block/bootdevice/by-name/metadata
Save and close the file.
Repack the boot image:
Code:
mkboot bootimg boot.img
Note the above line will replace your previous boot.img file, but that's OK because we made the copy to boot-stock.img.
4b) Oreo - Disable dm-verity and forced encryption
Oreo is different to Nougat with respect to these flags. Oreo uses a "device tree" in the boot image to mount the vendor partition. In the case of potter, and presumably the other recent Moto devices, vendor is actually a symlink to a folder in system. So, we need to make a change to the boot image, and the system partition.
4b) i) Oreo - Disable dm-verity
The process in broad terms is this:
Backup the boot image
Unpack the boot image
Decompress the dt.img file (if applicable), to get the underlying dtb file (device tree blob)
Hexedit the device tree blob, removing instances of verify
Compress the dtb file
Pack the boot image
To assist with the next OTA, make a copy of the boot image. Then use mkboot to extract the boot image to its component parts:
Code:
cp -v boot.img boot-stock.img
mkboot boot.img bootimg
Look at the extracted boot image:
Code:
ls -l bootimg/
-rw-r--r-- 1 user user 418560 Sep 9 09:12 dt.img
-rw-r--r-- 1 user user 466 Sep 9 09:12 img_info
-rw-r--r-- 1 user user 9211208 Sep 9 09:12 kernel
drwxr-xr-x 21 user user 4096 Sep 9 09:12 ramdisk
-rw-r--r-- 1 user user 1273390 Sep 9 09:12 ramdisk.packed
The dt.img is the device tree, which holds the mount information that we need to edit. Note that dt.img may be compressed - for Potter it is lz4 compressed, for Cedric for example, it is not compressed - it is raw data. To find out whether or not it is compressed, use the following command and check the output
Code:
file bootimg/dt.img
The output could be one of the following:
Code:
bootimg/dt.img: LZ4 compressed data (v1.4+)
bootimg/dt.img: data
If the output says that it is LZ4 compressed, use the following to decompress - we will call the decompressed file dtb.img:
Code:
lz4 -d bootimg/dt.img bootimg/dtb.img
Now we need to use a hex editor to view and manipulate the dtb.img (or dt.img if not compressed) file. Note that the dtc command (device tree compiler) should be able to convert these dtb files into source files. However I have had no success even with the latest versions. In future it may be possible (and preferable) to convert to source, and edit the source text and recompile to dtb.
Code:
dhex bootimg/dtb.img
or
Code:
dhex bootimg/dt.img
Now, search for instances of ",verify" (without the quotes). When they are found, you can also scroll up to see what the previous lines were, to make sure they are editing instances of "fstab", for example:
Code:
32E44 00 00 00 01 61 6e 64 72 6f 69 64 00 00 00 00 03 00 00 00 11 00 00 00 21 ....android............!
32E5C 61 6e 64 72 6f 69 64 2c 66 69 72 6d 77 61 72 65 00 00 00 00 00 00 00 01 android,firmware........
[COLOR="red"] 32E74 66 73 74 61 62 00 00 00 00 00 00 03 00 00 00 0e 00 00 00 21 61 6e 64 72 fstab..............!andr[/COLOR]
32E8C 6f 69 64 2c 66 73 74 61 62 00 00 00 00 00 00 01 73 79 73 74 65 6d 00 00 oid,fstab.......system..
32EA4 00 00 00 03 00 00 00 0f 00 00 00 21 61 6e 64 72 6f 69 64 2c 73 79 73 74 ...........!android,syst
32EBC 65 6d 00 00 00 00 00 03 00 00 00 35 00 00 03 72 2f 64 65 76 2f 62 6c 6f em.........5...r/dev/blo
32ED4 63 6b 2f 70 6c 61 74 66 6f 72 6d 2f 73 6f 63 2f 37 38 32 34 39 30 30 2e ck/platform/soc/7824900.
32EEC 73 64 68 63 69 2f 62 79 2d 6e 61 6d 65 2f 73 79 73 74 65 6d 00 00 00 00 sdhci/by-name/system....
32F04 00 00 00 03 00 00 00 05 00 00 00 71 65 78 74 34 00 00 00 00 00 00 00 03 ...........qext4........
32F1C 00 00 00 15 00 00 69 bc 72 6f 2c 62 61 72 72 69 65 72 3d 31 2c 64 69 73 ......i.ro,barrier=1,dis
32F34 63 61 72 64 00 00 00 00 00 00 00 03 00 00 00 0c 00 00 69 c6 77 61 69 74 card..............i.wait
[COLOR="Red"] 32F4C 2c 76 65 72 69 66 79 00 00 00 00 03 00 00 00 03 00 00 02 b4 6f 6b 00 00 ,verify.............ok..[/COLOR]
There will be several instances of this. In all cases, we want to overwrite the ",verify" with zeroes. So the last line above would become:
Code:
32F4C 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00 03 00 00 02 b4 6f 6b 00 00 ....................ok..
Make sure to repeat for all, then save and exit the hex editor.
Now complete the last few steps - the first set of commands if the dt.img file was compressed:
Code:
rm -v bootimg/dt.img
lz4 -9 bootimg/dtb.img bootimg/dt.img
rm -v bootimg/dtb.img
mkboot bootimg boot.img
Or the following if dt.img was not compressed:
Code:
mkboot bootimg boot.img
The boot image has now been recreated with dm-verity disabled.
4b) ii) Oreo - Disable forced encryption
The process here is similar to what is done in Nougat, just that we need to mount system.img first, and then apply to a file at system/vendor/etc/fstab.qcom.
It is important to know that merely mounting system.img will result in changes to the file. This could cause a future OTA to not work. The approach below will work, however it is now recommended that system.img is mounted read-only, the fstab.qcom file is copied and edited, and a script is used to replace the fstab.qcom file at install time. This way system.img is kept intact, there is no need to keep a > 1 GB file as a backup, and there will be no issues with future OTAs. This is the approach taken by the latest flashable zips with the Aroma installer.
In the below, I use vim to edit, but you can use any other text editor. I also create a backup of system.img, just in case I make a mistake. Note that it is a large file so you wouldn't want to keep it in the final zip.
Another thing to note is that this change appears to have no effect if dm-verity is not disabled.
Code:
cp -v system.img /path/to/keep/system.img.backup
mkdir system
sudo su
mount system.img system
vim system/vendor/etc/fstab.qcom
Here, apply the same approach as Nougat - replace "forceencrypt" with "encryptable". Close and save, then unmount system.img, and exit the root shell. Then remove the system folder.
Code:
umount system
exit
rmdir -v system
Installing Magisk immediately after flashing the rom, and before rebooting, will also disable dm-verity and forced encryption.
5) Convert images to sparse images, then to sparse data
Make a temporary folder for the spasre image files that we will create:
Code:
mkdir tmp
img2simg system.img tmp/system.img
img2simg oem.img tmp/oem.img
img2simg modem.img tmp/modem.img
Create the sparse data files from the sparse images:
Code:
img2sdat.py tmp/system.img -v 4 -p system
img2sdat.py tmp/oem.img -v 4 -p oem
img2sdat.py tmp/modem.img -v 4 -p modem
6) Update the actual updater-script
Use your text editor to update the updater-script file:
Code:
vim META-INF/com/google/android/updater-script
Update any lines that refer to the version being installed. It's good to have these lines in there, but are optional. They could be removed entirely if so desired...
Code:
ui_print("Target: motorola/potter/potter:7.0/NPNS25.137-93-8/10:user/release-keys");
As it is information only, it isn't necessary to get the values exactly right. You can get the correct values from the ota updater script here:
Code:
ota/META-INF/com/google/android/updater-script
Update - remove format of modemst1 and modemst2
The builds that I have provided to date erase the modemst1 and modemst2 partitions. Whilst that is fine for devices normally as they get recreated on boot, in cases where users have flashed a custom Oreo rom and then reverted to stock, there have been reports of losing IMEI and other capabilities. Whilst this is caused by Oreo roms changing ownership of the /persist/rfs folder, the fact that these partitions are erased can leave people without IMEI, relying upon a backup to get back. So, if the previous flashable zip has lines to format the modemst1/2 partitions, remove them. The lines look like the following, with the format commands being the ones that do the erase:
Code:
ui_print("Erasing modemst1 ...");
format("raw", "EMMC", "/dev/block/bootdevice/by-name/modemst1", "0", "/modemst1");
ui_print(" ");
ui_print("Erasing modemst2 ...");
format("raw", "EMMC", "/dev/block/bootdevice/by-name/modemst2", "0", "/modemst2");
ui_print(" ");
7) Remove working files and folders and zip
The folders we created in previous steps can now be removed:
Code:
rm -rf ota tmp bootimg
The temporary img files can now be removed:
Code:
rm system.img oem.img modem.img
Zip up the remaining files into the parent folder (I like to keep the update tree clean) - replace version_info with an appropriate string, e.g. NPNS25.137-93-14, OPS28.85-13:
Code:
zip ../twrp-flashable-potter-[i]version_info[/i].zip -r *
Note - this will also include the boot-stock.img file. Best to keep it there so we can use it for the next patch!
8) Prepare for flashing
Copy the newly created zip into your phone's SD card
BACKUP BACKUP BACKUP!!! Do a TWRP backup of course! NO EXCUSES!
Flash the zip file.
Voila!
Edit log
2018-07-07 - Added reference to post #10, as it details how to do a modem update for the NPNS25.137-93-14 OTA
2018-07-10 - Added recommendation to remove lines from OTA updater-script that erase modemst1 and modemst2
2018-08-19 - Updated for Oreo.
2018-09-09 - Tidied up the steps to disable dm-verity for Oreo, other tidying up. Catered for dt.img being either compressed (e.g. Potter) or not (e.g. Cedric).
Create TWRP from full fastboot image
Create TWRP Flashable from Fastboot Image
First off, make sure you have the SparseConverter and TWRP template zip from the second post. These weren't needed for building from an existing TWRP flashable zip, but are necessary for this.
1) Get an appropriate starting firmware
At the time of writing this, the April 2018 security patches are available for the Indian variant (NPNS25.137-92-10) and US variant (NPNS25.137-93-10). Note that these firmwares are used on other regions as well (e.g. the US firmware can be used on retapac). Refer to other threads in the forum if you aren't sure. Ideally you should stick with the firmware for your region, as e.g. there may be differences in the modems, etc.
Indian (NPNS25.137-92-10) https://mirrors.lolinet.com/firmware/moto/potter/official/RETAIL/POTTER_RETAIL_7.0_NPNS25.137-92-10_cid50_subsidy-DEFAULT_regulatory-DEFAULT_CFC.xml.zip
US (NPNS25.137-93-10) - refer to this thread https://forum.xda-developers.com/g5-plus/development/april-security-patch-xt1687-npns25-137-t3796797
Extract the zip file and enter the folder (rename it if you want for convenience).
2a) Convert the sparse chunk files into a (Motorola) image file
Use SparseConverter to convert the sparse chunks into an image file:
Code:
SparseConverter.exe /decompress system.img_sparsechunk.0 system.img.moto
The first parameter says that we are decompressing (obvious). The second is the name of the very first sparse chunk file - we only need to specify the first. The third and last parameter is the destination file to be created.
The reason for naming it system.img.moto (i.e. with moto on the end) is because Motorola have added a 128KB header and 4KB trailer. These will need to be removed later.
2b) Convert oem.img from sparse image to raw image
Confusingly, sparse image files and raw image files typically have the same extension - img. oem.img is a sparse image file, and must be converted to raw image. Similarly to the system image, it has a 128KB header and 4KB trailer.
Code:
mv oem.img oem.simg.moto
simg2img oem.simg.moto oem.img.moto
2c) Convert the modem (NON-HLOS.bin) to raw image
The modem file, although it has a .bin extension, is in sparse image format.
Code:
simg2img NON-HLOS.bin modem.img
This particular file does not have a header or trailer.
3) Remove header and trailer from image files
We will use dd and truncate to remove the header and trailer respectively from the system and oem image files:
Code:
dd if=system.img.moto of=system.img bs=131072 skip=1
truncate -s -4096 system.img
dd if=oem.img.moto of=oem.img bs=131072 skip=1
truncate -s -4096 oem.img
4) Extract template and copy files
In a separate folder, extract the TWRP Template zip file into a folder, and rename the folder to something more reasonable, e.g. twrp-flashable-NPNS.25.137-xx-xx.
Copy each of the following files into the template folder:
system.img
oem.img
modem.img
boot.img
fsg.mbn
adspso.bin
logo.bin
E.g. use a command like the following, adjusting the paths as necessary (the last parameter is the location of the template folder that I renamed in this case):
Code:
cp -fv adspso.bin boot.img fsg.mbn logo.bin modem.img oem.img system.img ../twrp-flashable-NPNS25.137-92-10/
Note that of those above, the first three were created in our previous steps, the others (boot.img etc) were already there with the other fastboot files.
The updater-script, located at META-INF/com/google/android/updater-script is already set up to take the steps that are done in the fastboot images, except it does not update the bootloader-related files.
At this stage, you could just go and zip up all of the files and flash. However, there are a few things you may want to do first. Ensure you are in the template folder before doing any of the following.
5) Disable dm-verity and forced encryption in boot
To do this, follow the same instructions as the previous post - step 4. Note the two different methods, one for Nougat, one for Oreo.
6) Change the logo image
Note that the logo.bin file is from stock, and therefore it will have the unlocked bootloader warning. You could replace it with the logo.bin from the other TWRP flashables, or you may want to grab one from the Themes forum, and (as I did) pick a nice one that hides the N/A.
7) Convert images to sparse images, then to sparse data
This step is the same as the previous post, step 5. It is repeated here for convenience.
Make a temporary folder for the sparse image files that we will create:
Code:
mkdir tmp
img2simg system.img tmp/system.img
img2simg oem.img tmp/oem.img
img2simg modem.img tmp/modem.img
Create the sparse data files from the sparse images:
Code:
img2sdat.py tmp/system.img -v 4 -p system
img2sdat.py tmp/oem.img -v 4 -p oem
img2sdat.py tmp/modem.img -v 4 -p modem
8) Remove working files and folders and zip
The folders we created in previous steps can now be removed:
Code:
rm -rf tmp bootimg
The temporary img files can now be removed:
Code:
rm -fv system.img oem.img modem.img
9) Create the zip file
Ensuring that you are in the template folder, execute the following command to create the zip:
Code:
zip twrp-flashable-NPNS25.137-92-10.zip -r *
Make sure to change the zip filename as appropriate.
10) Flash
Copy to your phone's SD Card
BACKUP BACKUP BACKUP Yes, the same warning as per usual!
Flash the zip file as usual.
Edit log
2018-06-29 - fixed references to logo.img, as they are actually logo.bin. Added -fv to remove temporary files.
Hi.... Will work with Oreo stock ROM too?
david.gs.gm said:
Hi.... Will work with Oreo stock ROM too?
Click to expand...
Click to collapse
We'll find out for sure once we get the OTA. I'd expect it will work, given that it is coming from a nougat base for the first one anyway.
Thanks for putting this together. It's a good resource.
Thank you OP keep up the great work I always keep latest on my ext so I can flash in case of custom rom issues
Hi all - the Fastboot to TWRP Flashable guide in post #4 is now complete.
I'd be really interested if anyone has tried following the guide and had success.
All the best.
Modem update via OTA
The update I did of NPNS25.137-93-14 (from NPNS25.137-93-10) had something I hadn't seen in previous updates. The modem was updated, but rather than the partition as a whole being patched, individual files within the partition were patched. The relevant parts of the updater-script from the OTA were as follows:
Code:
ui_print("Patching modem files...");
apply_patch("/modem/image/cmnlib.b01", "-",
6fa3c6b7659a838aba82f079794a9ac46b74651b, 6632,
720b36038ee0c7152dac051d7f4bb13dfdd3fb15,
package_extract_file("patch/modem/image/cmnlib.b01.p")) ||
abort("E3008: Failed to apply patch to /modem/image/cmnlib.b01");
apply_patch("/modem/image/cmnlib.b02", "-",
155983f129c89d1c8fb96df20e069e388a23c2c2, 178690,
6e0951d9fab22276dd772cb96ae91eff850b5bf1,
package_extract_file("patch/modem/image/cmnlib.b02.p")) ||
abort("E3008: Failed to apply patch to /modem/image/cmnlib.b02");
apply_patch("/modem/image/cmnlib.mdt", "-",
41fdff0863ac1215135802499433644f2b030b92, 6876,
1e7c7b75c2aec4cecfea538b93350975160ce0b5,
package_extract_file("patch/modem/image/cmnlib.mdt.p")) ||
abort("E3008: Failed to apply patch to /modem/image/cmnlib.mdt");
etc - there were a total of 51 patches applied
The other images have been patched directly, rather than individual files within the image. So the approach had to be slightly different:
Create a folder and mount the modem.img file into it
Use ApplyPatch on each of the folders
Unmount the image
Remove the folder
The resulting code to apply the changes looked like this:
Code:
# Make a folder to mount the image in
mkdir modem
# Change to a root shell
sudo su
# Mount the modem image to the modem sub-folder
mount modem.img modem
# ensure the ApplyPatch executable is in the path
export PATH=$PATH:"path to ApplyPatch"
ApplyPatch modem/image/cmnlib.b01 - 6fa3c6b7659a838aba82f079794a9ac46b74651b 6632 720b36038ee0c7152dac051d7f4bb13dfdd3fb15 ota/patch/modem/image/cmnlib.b01.p
ApplyPatch modem/image/cmnlib.b02 - 155983f129c89d1c8fb96df20e069e388a23c2c2 178690 6e0951d9fab22276dd772cb96ae91eff850b5bf1 ota/patch/modem/image/cmnlib.b02.p
ApplyPatch modem/image/cmnlib.mdt - 41fdff0863ac1215135802499433644f2b030b92 6876 1e7c7b75c2aec4cecfea538b93350975160ce0b5 ota/patch/modem/image/cmnlib.mdt.p
etc... for the remainder of the patches
# Unmount the modem image
umount modem
# Exit the root shell
exit
# Remove the modem folder
rmdir modem
Because the updater-script was consistently formatted, after doing the first 20 manually to make sure I was doing it right, I used a spreadsheet to extract the relevant hashes and filenames, and turned them into the commands above. This could have been done using a script or similar, but I'm a master of spreadsheets so chose to do it that way
@NZedPred is it possible to make a flashable zip to update only the firmware? I'm on custom rom and only would like the upgrade my firmware....would i only have to delete system boot and recovery from the zip?
Tech_Savvy said:
@NZedPred is it possible to make a flashable zip to update only the firmware? I'm on custom rom and only would like the upgrade my firmware....would i only have to delete system boot and recovery from the zip?
Click to expand...
Click to collapse
Hi - yes it's possible. Not 100% sure what you mean by "only the firmware" (modem/network related?), but you can alter the update the zip to only update the partitions that you want. These are the current steps in the updater-script (META-INF/com/google/android/updater-script):
modem
fsg
Erase modemst1 and modemst2
dsp
logo
boot
system
oem
Erase ddr
I've read that the modem and fsg are relating to the network. See the thread here for more information: Motorola Moto G Partitions Explained.
Not sure if custom roms would use oem. I know that Treble roms use oem in place of vendor, so if you're using a treble rom you wouldn't want to update that.
So all you need to do is remove the commands you don't want in the updater-script.
Hope this helps a bit.
Bootloader partitions
This is a quick guide on determining which partitions are related to the bootloader.
Using a full fastboot firmware, extract the bootloader.img file. Although it is a binary file, it has sections that are text, e.g. the following is using the less command
Code:
SINGLE_N_LONELY^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@index.xml^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@<82>^@^@^@^@^@^@^@<?xml version="1.0"?>
<index>
<package compatible="cpu.name:MSM8953 protocol:fastboot" filename="bootloader.pkg.xml"/>
</index>
Scrolling down a few pages, you'll find the following:
Code:
<?xml version="1.0" ?>
<recipe>
<flash partition="aboot" filename="emmc_appsboot.mbn"/>
<flash partition="rpm" filename="rpm.mbn"/>
<flash partition="tz" filename="tz.mbn"/>
<flash partition="devcfg" filename="devcfg.mbn"/>
<flash partition="cmnlib" filename="cmnlib.mbn"/>
<flash partition="cmnlib64" filename="cmnlib64.mbn"/>
<flash partition="keymaster" filename="keymaster.mbn"/>
<flash partition="prov" filename="prov.mbn"/>
<flash partition="sbl1" filename="sbl1.mbn"/>
</recipe>
So, that tells us exactly which partitions are updated when we update the bootloader. The filenames and partitions are the same as those that we would see in an OTA, e.g. when we see commands like this:
Code:
ui_print("updating rpm ...");
assert(package_extract_file("rpm.mbn", "/tmp/rpm.mbn"),
apply_raw_image("/tmp/rpm.mbn", "rpm"),
delete("/tmp/rpm.mbn"));
show_progress(0.100000,0);
assert(set_backup_flag());
ui_print("updating tz ...");
assert(package_extract_file("tz.mbn", "/tmp/tz.mbn"),
apply_raw_image("/tmp/tz.mbn", "tz"),
delete("/tmp/tz.mbn"));
show_progress(0.050000,0);
ui_print("updating devcfg ...");
assert(package_extract_file("devcfg.mbn", "/tmp/devcfg.mbn"),
apply_raw_image("/tmp/devcfg.mbn", "devcfg"),
delete("/tmp/devcfg.mbn"));
show_progress(0.050000,0);
etc...
Wow, great thread. Thank you so much for providing all of this info. I have been curious about how this works for quite some time. I can't wait to give it a try this coming weekend.
Thanks again mate!!
Related
Hi there,
I got my hands on a phone that appears to be a copycat of the HTC Diamond 2. It’s running WM6.5. There is no volume button on it so they have some other trick to get into the boot loader. In order to flash it, the vendor is using a simple process:
1. Put a Loader.bin and Flash.bin file on the SD Card.
2. Turn on the phone while holding the “hang-up” and “back” buttons.
3. The boot loader then kicks in and installs the new ROM.
What I’m trying to figure out is what is the file format for Flash.bin and how can to recreate it myself? Basically I’d like to be able to take an nbh from an official ROM file and convert it to that Flash.bin thing.
Using an HEX editor, I see that the first part of Flash.bin looks very similar to an OS partition that can be extracted from an nbh file (e.g. using NBHExtract) but one difference is that the header of Flash.bin starts with a few more bytes B0B0FF etc.:
B 0 B 0 F F …
42 30 42 30 46 46 0A 00 0C 0C 00 00 8A 90 06 00 0C 0C 00 00 02 02 00 2C 53 4E
I’ve uploaded both Loader.bin and Flash.bin here if you want to look further.
http://rapidshare.com/files/328271954/FLASH.zip
http://rapidshare.com/files/328259421/LOADER.BIN
Any tips greatly appreciated.
Thanks,
Bob
Hello,
I am trying to unlock my sgs, that I bought in Croatia. It is locked to VIP carrier, but none of the metods described in the forums work for me.
I have copied my nv_data. bin file to my computer and extracted the unlock code from it with SGUX utility for windows by rbnet.it and marcopon. But when I reboot the phone with my SIM and enter the unlock code it says unsucsessful unlocking...
I also installed Sgs_Unlock.apk to my phone, witch gave me the same unlock code that doesent work.
Than I tryed to edit nv_data.bin file with hex editor, but it doesent seem to include an address 0x181468.
Thank you wery much!!!
Luka
Try using super one click.
Sent from my GT-I9000 using XDA App
Done
I´ve managed to unlock it with editing nv_data.bin file, that was slightly diferent that the one in this threathttp://forum.xda-developers.com/showthread.php?t=761045 .
Ehtoeh the phone was allready rooted with Super One Click so i could retrive the nv_data.bin file, but that doesent unlock it to other carriers.
This is how i did it:
Follow step 1. from the mentioned thread (retrive the nv_data.bin file).
Open the file with 010 Editor (trial version), go to view, linefeeds and set it to 8 bytes.
Go to mentioned adress (ctrl+g) and see the slightly different line ( ff 01 00 00 00 00 33 35)
Edit it to ff 00 00 00 00 00 33 35 and save.
Follow step 3. from the mentioned (How to unlock/unfreeze all SGS Models) thread, reboot and the phone was unlocked.
Oh i forgot it was running the 2.1 update1 Eclair when i unlocked it.
Luka
I've hosted the file nv_data without've managed to find the line you need to change. whether we could to help;
Let`s think,
Maybe the lock is located at some other address, you just have to find it.
As mentioned in this thread http://forum.xda-developers.com/showthread.php?t=761045 there are 5 different types of locks in 5 different bytes:
network lock, subset lock, sp lock, cp lock and data lock (don`t know if that`s true because i can find only four locks in my phone:network, subset, sp and cp but no data). The locks are defined with byte 00 for lock off and 01 for lock on.
Now enter *#7465625# to phone. It will display the locks and weather they are on or off. (see attachment)
You can now put together a string from the values that you get from the phone 00 for lock off and 01 for lock on.
It should begin with ff followed by the bytes you got from your phone, for example if you have active network lock and all other locks inactive you should have:
ff 01 00 00 00 00 xy xy
As you can see there are two other bytes xy, but we can live without knowing their values as they seem to be differ from phone to phone but they should allways be digits.
Now open your nv_data file with hex editor and search for the string you`ve put together without the last two bytes. You can get more than one result, but the right place is the one where the last two bytes will de digits.
Edit it to ff 00 00 00 00 00 xy xy to turn all the locks off.
I hope you`ll unlock your phone this way and let us know how it goes.
Luka
because I can not find the line you say ,can you find if there is to please;
Can you post a screencapture like i did so i can find that string.
like this ...i quote and the file...I found this address that is similar to saying that
try editing that one to ff 00 00 00 00 00 00 05, but be careful and have your nv_data backed up first cause this can brick your phone.
Iment a screencapture from your phone.
Luka
ok I did the treatment. I just want to tell me exactly, step by step how to switch back to back in mobile
Did you edit your nv_data.bin file and now the phone doesent work?
If so you have to restore your backup like this:
1. Copy the file from the backup (nv_data.bin) to your sdcard.
2. In ADB type the following commands one by one:
su
cp /sdcard/nv_data.bin /efs/nv_data.bin
rm -rf /efs/nv_data.bin.md5 (OR)
busybox rm -rf /efs/nv_data.bin.md53. Reboot your phone.
4. Most probably, now your SIM will not work and you will not be able to login into your phone. Please don’t be panic. We are with you
5. Pop off the SIM.
6. Boot your smartphone.
7. Run the below commands through ADB:
su
busybox chown 1001:1001 /efs/nv_data.bin or
chown 1001:1001 /efs/nv_data.bin
8. Your phone should be OK now.
There is a whole thread on this topic on this forum http://forum.xda-developers.com/showthread.php?t=859914
thnaks for the reply, unfortunately i did not meant that.
i would like to explain me, how you can insert in the sd memory card the nv_data (edit) that i have already processed. In order to sumarize, i would like to know the orders.
Sorry, I didn´t understand you.
So you need to push nv_data.bin file that you have edited back to your phone.
you need to follow the instructions from this thread http://forum.xda-developers.com/showthread.php?t=761045
First copy your nv_data.bin file to root of your sdcard and then use "adb shell" or a terminal emulator to get a terminal prompt and run the following commands:
su
rm /efs/nv_data.bin
rm /efs/nv_data.bin.md5
cat /sdcard/nv_data.bin >> /efs/nv_data.bin
chmod 755 /efs/nv_data.bin
chown radio.radio /efs/nv_data.bin || chown 1001.1001 /efs/nv_data.bin
reboot
Post if it worked.
Luka
i can not, look the foto
This happened to me allso, try rooting your phone with superoneclick (ignore message device seem to be rooted) just before entering adb. If that still doesen`t work try with terminal emulator.
Well we made it and unlock it!
The procedure followed was about as I said it.
1. Follow step 1. from the mentioned thread (retrive the nv_data.bin file).
2.Open the file with 010 Editor (trial version), go to view, linefeeds and set it to 8 bytes.
3.Go to mentioned adress (ctrl+g) and see the slightly different line ( ff 01 00 00 00 00 33 35) may be different numbers from device to device
4.Edit it to ff 00 00 00 00 00 33 35 and save.
5.Follow step 3. from the mentioned (How to unlock/unfreeze all SGS Models) thread, reboot and the phone was unlocked.
When I did the procedure I had a mobile unroot!
Nice to hear you`ve managed to unlock it, I knew you`ll do it soon or later
If it`s unrooted now, you can just root it again, but i don`t know why this happened.
All i would like to know is at wich address the lock was located as your nv_data.bin file didn`t have the address mentioned in the first post. It could help other people to unlock their phones.
Luka
Well you do it again root, I changed my kernel and Rom are all ok!
The address for nv_data.bin is of the form FF 01 00 00 00 00 xx xx to me was
FF 01 00 00 00 00 00 05.
cm7 mac address fix
i rooted my kindle fire and my dads kindle fire and put cm7 on both
then when we both tried to get on wifi it didnt work after looking into it we found out that we both had the same ip address and also the same mac address
here is a quick quide for changing your mac address
original credit goes to jfb9301 over here
I AM NOT LIABLE IF YOU MESS SOMETHING UP
PROCEED AT YOUR OWN RISK
you need
root explorer
hexeditor
connect your fire
cmd.exe nav to your adb folder
> adb shell
> su
> wlan_cu -b
> / w p 1 l 2 f 2
> / t b v 21
> / t b t 1 0 0 0 0 0 0 0
> / q
now ctrl-C
exit cmd
now on kindle open root explorer
navigate to data/misc/wifi
copy nvs_map.bin
navigate to sdcard and paste
just for safety paste another copy and rename add .bak
" nvs_map.bin.bak "
now open the nvs_map.bin that is in the sdcard with hexeditor
edit the first line
for the mac address 08:00:28:12:34:56
0000: 01 6d 54 56 34 12 28 01 71 54 00 08 00 00
so for 11:22:33:44:55:66
0000: 01 6d 54 66 55 44 33 01 71 54 22 11 00 00
save the file
now in root explorer copy nvs_map.bin from the sdcard and paste it into data/misc/wifi
long press on the file and set permissions to RW- RW- RW-
now reboot
open up wifi settings> menu>advanced and double check your new mac address
credit to jfb9301
good luck!
saving for later
Already posted
SEE HERE
Also, someone in the thread posted an easier fix:
Download the attached .zip. Extract it. Copy the file to /system/bin/. Reboot.
tkalli said:
Already posted
SEE HERE
Click to expand...
Click to collapse
You mean already posted as in the OP pointed out it was posted there? He was just putting it in the dev section since that is where most people would search for it and where the original thread poster wanted to put it, but couldnt...
So i have redmi note 8 pro with chinese rom stable 12.5 .. the phone bootloader is locked , i tried to unlock the bootloader in normal way by bining an MI account but i am unable to bind mi account to device in developer settings BECAUSE ( the phone IMEI is changed) so its always gives an error of request timeout upon clicking bind account.. morever i tried evry vpn and other possible way to bind my account to unlock bootloader but unable to do it..
Can anyone help me out of this . Because i want to use global rom with google play which i cant do until unlocking bootloader.
I need any possible official or UNofficial way to unlock my redmi note 8 pro bootloader..
Your help would be appreciated. Thankyou
This error.. and it comes after 1-2 mins of clikcing "add device and account"
Hello
The seccfg partition unlocks the device.
You must initially unlock the bootloader through the MiUnlock application, then recover (save) the seccfg partition (which contains the bootloader unlock information). But, it is easier to get rid of the requirement of the MiUnlock app.
1) Recover your "seccfg" partition:
* the phone in normal mode =
- We launch the command prompt and we write
adb shell
ls -al /dev/block/by-name
or
adb shell
ls -al /dev/block/platform/bootdevice/by-name
- Output (looking for "seccfg") =
lrwxrwxrwx 1 root root 16 2021-03-06 23:25 seccfg -> /dev/block/sdc13
- We get "seccfg" on the internal memory =
dd if =/dev/block/sdc13 of =/sdcard/Partition_seccfg
(I named "Partition_seccfg", but you give the name you want)
- You save "Partition_seccfg" on your PC
* We can recover the "seccfg" partition by SPFlashTool
- Edit your "MT6785_Android_scatter.txt" from a stock ROM (with Notepad or other)
- We are looking for "seccfg" =
partition_index: SYS14
partition_name: seccfg
file_name: NONE
is_download: false
type: NORMAL_ROM
linear_start_addr: 0x13800000
physical_start_addr: 0x13800000
partition_size: 0x800000
- We turn off the phone
- we switch to EDL mode with the python script "bypass_utility-v.1.4.2" (see on the web for installation and other information, among other things to unbrick the phone)
- we do a "readback" of the "seccfg" partition with SPFlashTool using linear_start_addr: 0x13800000 and partition_size: 0x800000 (check the location on the PC, where the "seccfg" partition will be saved with the name you have chosen)
2) Modify your "seccfg" partition:
* We edit the "seccfg" partition with a hexadecimal editor (Notepad or other)
- Total size 000000000 to 007ffff0 (000000040 to 007ffff0 : zero bytes = 00)
- Address 000000000 to 00000003f, we find :
0000000 to 000000f
4d 4d 4d 4d 04 00 00 00 3c 00 00 00 02 00 00 00
0000010 to 000001f
00 00 00 00 00 00 00 00 45 45 45 45 3d aa 79 3b
0000020 to 000002f
eb b0 56 bd 53 48 d3 6e 7d 54 a0 41 0c 2d 1a 90
0000030 to 000003f
58 1a 9c 5f ab 90 cc 0f 5c 11 63 a2 00 00 00 00
(The bootloader is locked!)
- We modify with our hexadecimal editor (Address 000000000 to 000000030) :
0000000 to 000000f
4d 4d 4d 4d 04 00 00 00 3c 00 00 00 03 00 00 00
0000010 to 000001f
00 00 00 00 00 00 00 00 45 45 45 45 57 b3 59 5d
0000020 to 000002f
9e bc 3d 02 33 91 84 9a 42 59 54 8e 07 aa 0f 34
0000030 to 000003f
f1 bb 1e 47 ea 8e cf 76 fb de 79 7b 00 00 00 00
(The bootloader is unlocked!)
- We save our changes
3) Write your "seccfg" partition on the phone:
* We flash the "seccfg" partition
- fastboot flash seccfg "path on your PC"\"name of your saved seccfg partition" (E:\MyFolder\Partition_seccfg for example), in fastboot mode,
- SPFlashTool using EDL mode with the python script "bypass_utility-v.1.4.2 "and by flashing your rom by not checking that the partition "seccfg",
- in adb mode, with the opposite operation, after having copied your partion "seccfg" on the internal memory of the telephone (name "Partition_seccfg" that I gave and that you choose) :
adb shell dd if=/sdcard/Partition_seccfg of=/dev/block/sdc13
- We restart the phone and the bootloader is unlocked without intervention from Xiaomi or other!
4) Warning :
Once all this information is published, subsequent MIUI updates may destroy our efforts by scheduling the bootloader release in a more complicated way!
RahanCrau said:
Hello
The seccfg partition unlocks the device.
You must initially unlock the bootloader through the MiUnlock application, then recover (save) the seccfg partition (which contains the bootloader unlock information). But, it is easier to get rid of the requirement of the MiUnlock app.
1) Recover your "seccfg" partition:
* the phone in normal mode =
- We launch the command prompt and we write
adb shell
ls -al /dev/block/by-name
or
adb shell
ls -al /dev/block/platform/bootdevice/by-name
- Output (looking for "seccfg") =
lrwxrwxrwx 1 root root 16 2021-03-06 23:25 seccfg -> /dev/block/sdc13
- We get "seccfg" on the internal memory =
dd if =/dev/block/sdc13 of =/sdcard/Partition_seccfg
(I named "Partition_seccfg", but you give the name you want)
- You save "Partition_seccfg" on your PC
* We can recover the "seccfg" partition by SPFlashTool
- Edit your "MT6785_Android_scatter.txt" from a stock ROM (with Notepad or other)
- We are looking for "seccfg" =
partition_index: SYS14
partition_name: seccfg
file_name: NONE
is_download: false
type: NORMAL_ROM
linear_start_addr: 0x13800000
physical_start_addr: 0x13800000
partition_size: 0x800000
- We turn off the phone
- we switch to EDL mode with the python script "bypass_utility-v.1.4.2" (see on the web for installation and other information, among other things to unbrick the phone)
- we do a "readback" of the "seccfg" partition with SPFlashTool using linear_start_addr: 0x13800000 and partition_size: 0x800000 (check the location on the PC, where the "seccfg" partition will be saved with the name you have chosen)
2) Modify your "seccfg" partition:
* We edit the "seccfg" partition with a hexadecimal editor (Notepad or other)
- Total size 000000000 to 007ffff0 (000000040 to 007ffff0 : zero bytes = 00)
- Address 000000000 to 00000003f, we find :
0000000 to 000000f
4d 4d 4d 4d 04 00 00 00 3c 00 00 00 02 00 00 00
0000010 to 000001f
00 00 00 00 00 00 00 00 45 45 45 45 3d aa 79 3b
0000020 to 000002f
eb b0 56 bd 53 48 d3 6e 7d 54 a0 41 0c 2d 1a 90
0000030 to 000003f
58 1a 9c 5f ab 90 cc 0f 5c 11 63 a2 00 00 00 00
(The bootloader is locked!)
- We modify with our hexadecimal editor (Address 000000000 to 000000030) :
0000000 to 000000f
4d 4d 4d 4d 04 00 00 00 3c 00 00 00 03 00 00 00
0000010 to 000001f
00 00 00 00 00 00 00 00 45 45 45 45 57 b3 59 5d
0000020 to 000002f
9e bc 3d 02 33 91 84 9a 42 59 54 8e 07 aa 0f 34
0000030 to 000003f
f1 bb 1e 47 ea 8e cf 76 fb de 79 7b 00 00 00 00
(The bootloader is unlocked!)
- We save our changes
3) Write your "seccfg" partition on the phone:
* We flash the "seccfg" partition
- fastboot flash seccfg "path on your PC"\"name of your saved seccfg partition" (E:\MyFolder\Partition_seccfg for example), in fastboot mode,
- SPFlashTool using EDL mode with the python script "bypass_utility-v.1.4.2 "and by flashing your rom by not checking that the partition "seccfg",
- in adb mode, with the opposite operation, after having copied your partion "seccfg" on the internal memory of the telephone (name "Partition_seccfg" that I gave and that you choose) :
adb shell dd if=/sdcard/Partition_seccfg of=/dev/block/sdc13
- We restart the phone and the bootloader is unlocked without intervention from Xiaomi or other!
4) Warning :
Once all this information is published, subsequent MIUI updates may destroy our efforts by scheduling the bootloader release in a more complicated way!
Click to expand...
Click to collapse
can you please give me discord and guide me there. i am not so much pro in these.
i am waiting for help for soo many long time if you help me it will be really appreciated man please
RahanCrau said:
Hello
The seccfg partition unlocks the device.
You must initially unlock the bootloader through the MiUnlock application, then recover (save) the seccfg partition (which contains the bootloader unlock information). But, it is easier to get rid of the requirement of the MiUnlock app.
1) Recover your "seccfg" partition:
* the phone in normal mode =
- We launch the command prompt and we write
adb shell
ls -al /dev/block/by-name
or
adb shell
ls -al /dev/block/platform/bootdevice/by-name
- Output (looking for "seccfg") =
lrwxrwxrwx 1 root root 16 2021-03-06 23:25 seccfg -> /dev/block/sdc13
- We get "seccfg" on the internal memory =
dd if =/dev/block/sdc13 of =/sdcard/Partition_seccfg
(I named "Partition_seccfg", but you give the name you want)
- You save "Partition_seccfg" on your PC
* We can recover the "seccfg" partition by SPFlashTool
- Edit your "MT6785_Android_scatter.txt" from a stock ROM (with Notepad or other)
- We are looking for "seccfg" =
partition_index: SYS14
partition_name: seccfg
file_name: NONE
is_download: false
type: NORMAL_ROM
linear_start_addr: 0x13800000
physical_start_addr: 0x13800000
partition_size: 0x800000
- We turn off the phone
- we switch to EDL mode with the python script "bypass_utility-v.1.4.2" (see on the web for installation and other information, among other things to unbrick the phone)
- we do a "readback" of the "seccfg" partition with SPFlashTool using linear_start_addr: 0x13800000 and partition_size: 0x800000 (check the location on the PC, where the "seccfg" partition will be saved with the name you have chosen)
2) Modify your "seccfg" partition:
* We edit the "seccfg" partition with a hexadecimal editor (Notepad or other)
- Total size 000000000 to 007ffff0 (000000040 to 007ffff0 : zero bytes = 00)
- Address 000000000 to 00000003f, we find :
0000000 to 000000f
4d 4d 4d 4d 04 00 00 00 3c 00 00 00 02 00 00 00
0000010 to 000001f
00 00 00 00 00 00 00 00 45 45 45 45 3d aa 79 3b
0000020 to 000002f
eb b0 56 bd 53 48 d3 6e 7d 54 a0 41 0c 2d 1a 90
0000030 to 000003f
58 1a 9c 5f ab 90 cc 0f 5c 11 63 a2 00 00 00 00
(The bootloader is locked!)
- We modify with our hexadecimal editor (Address 000000000 to 000000030) :
0000000 to 000000f
4d 4d 4d 4d 04 00 00 00 3c 00 00 00 03 00 00 00
0000010 to 000001f
00 00 00 00 00 00 00 00 45 45 45 45 57 b3 59 5d
0000020 to 000002f
9e bc 3d 02 33 91 84 9a 42 59 54 8e 07 aa 0f 34
0000030 to 000003f
f1 bb 1e 47 ea 8e cf 76 fb de 79 7b 00 00 00 00
(The bootloader is unlocked!)
- We save our changes
3) Write your "seccfg" partition on the phone:
* We flash the "seccfg" partition
- fastboot flash seccfg "path on your PC"\"name of your saved seccfg partition" (E:\MyFolder\Partition_seccfg for example), in fastboot mode,
- SPFlashTool using EDL mode with the python script "bypass_utility-v.1.4.2 "and by flashing your rom by not checking that the partition "seccfg",
- in adb mode, with the opposite operation, after having copied your partion "seccfg" on the internal memory of the telephone (name "Partition_seccfg" that I gave and that you choose) :
adb shell dd if=/sdcard/Partition_seccfg of=/dev/block/sdc13
- We restart the phone and the bootloader is unlocked without intervention from Xiaomi or other!
4) Warning :
Once all this information is published, subsequent MIUI updates may destroy our efforts by scheduling the bootloader release in a more complicated way!
Click to expand...
Click to collapse
Bro, can you teach me on what basis did you give the hex values?
Is it that they are translated using tools such as HxD?
Are they device specific?
RahanCrau said:
Hello
The seccfg partition unlocks the device.
You must initially unlock the bootloader through the MiUnlock application, then recover (save) the seccfg partition (which contains the bootloader unlock information). But, it is easier to get rid of the requirement of the MiUnlock app.
1) Recover your "seccfg" partition:
* the phone in normal mode =
- We launch the command prompt and we write
adb shell
ls -al /dev/block/by-name
or
adb shell
ls -al /dev/block/platform/bootdevice/by-name
- Output (looking for "seccfg") =
lrwxrwxrwx 1 root root 16 2021-03-06 23:25 seccfg -> /dev/block/sdc13
- We get "seccfg" on the internal memory =
dd if =/dev/block/sdc13 of =/sdcard/Partition_seccfg
(I named "Partition_seccfg", but you give the name you want)
- You save "Partition_seccfg" on your PC
* We can recover the "seccfg" partition by SPFlashTool
- Edit your "MT6785_Android_scatter.txt" from a stock ROM (with Notepad or other)
- We are looking for "seccfg" =
partition_index: SYS14
partition_name: seccfg
file_name: NONE
is_download: false
type: NORMAL_ROM
linear_start_addr: 0x13800000
physical_start_addr: 0x13800000
partition_size: 0x800000
- We turn off the phone
- we switch to EDL mode with the python script "bypass_utility-v.1.4.2" (see on the web for installation and other information, among other things to unbrick the phone)
- we do a "readback" of the "seccfg" partition with SPFlashTool using linear_start_addr: 0x13800000 and partition_size: 0x800000 (check the location on the PC, where the "seccfg" partition will be saved with the name you have chosen)
2) Modify your "seccfg" partition:
* We edit the "seccfg" partition with a hexadecimal editor (Notepad or other)
- Total size 000000000 to 007ffff0 (000000040 to 007ffff0 : zero bytes = 00)
- Address 000000000 to 00000003f, we find :
0000000 to 000000f
4d 4d 4d 4d 04 00 00 00 3c 00 00 00 02 00 00 00
0000010 to 000001f
00 00 00 00 00 00 00 00 45 45 45 45 3d aa 79 3b
0000020 to 000002f
eb b0 56 bd 53 48 d3 6e 7d 54 a0 41 0c 2d 1a 90
0000030 to 000003f
58 1a 9c 5f ab 90 cc 0f 5c 11 63 a2 00 00 00 00
(The bootloader is locked!)
- We modify with our hexadecimal editor (Address 000000000 to 000000030) :
0000000 to 000000f
4d 4d 4d 4d 04 00 00 00 3c 00 00 00 03 00 00 00
0000010 to 000001f
00 00 00 00 00 00 00 00 45 45 45 45 57 b3 59 5d
0000020 to 000002f
9e bc 3d 02 33 91 84 9a 42 59 54 8e 07 aa 0f 34
0000030 to 000003f
f1 bb 1e 47 ea 8e cf 76 fb de 79 7b 00 00 00 00
(The bootloader is unlocked!)
- We save our changes
3) Write your "seccfg" partition on the phone:
* We flash the "seccfg" partition
- fastboot flash seccfg "path on your PC"\"name of your saved seccfg partition" (E:\MyFolder\Partition_seccfg for example), in fastboot mode,
- SPFlashTool using EDL mode with the python script "bypass_utility-v.1.4.2 "and by flashing your rom by not checking that the partition "seccfg",
- in adb mode, with the opposite operation, after having copied your partion "seccfg" on the internal memory of the telephone (name "Partition_seccfg" that I gave and that you choose) :
adb shell dd if=/sdcard/Partition_seccfg of=/dev/block/sdc13
- We restart the phone and the bootloader is unlocked without intervention from Xiaomi or other!
4) Warning :
Once all this information is published, subsequent MIUI updates may destroy our efforts by scheduling the bootloader release in a more complicated way!
Click to expand...
Click to collapse
seccfg is unreadable on MIUI 12.5.1 GLOBAL
RahanCrau said:
Hello
The seccfg partition unlocks the device.
You must initially unlock the bootloader through the MiUnlock application, then recover (save) the seccfg partition (which contains the bootloader unlock information). But, it is easier to get rid of the requirement of the MiUnlock app.
1) Recover your "seccfg" partition:
* the phone in normal mode =
- We launch the command prompt and we write
adb shell
ls -al /dev/block/by-name
or
adb shell
ls -al /dev/block/platform/bootdevice/by-name
- Output (looking for "seccfg") =
lrwxrwxrwx 1 root root 16 2021-03-06 23:25 seccfg -> /dev/block/sdc13
- We get "seccfg" on the internal memory =
dd if =/dev/block/sdc13 of =/sdcard/Partition_seccfg
(I named "Partition_seccfg", but you give the name you want)
- You save "Partition_seccfg" on your PC
* We can recover the "seccfg" partition by SPFlashTool
- Edit your "MT6785_Android_scatter.txt" from a stock ROM (with Notepad or other)
- We are looking for "seccfg" =
partition_index: SYS14
partition_name: seccfg
file_name: NONE
is_download: false
type: NORMAL_ROM
linear_start_addr: 0x13800000
physical_start_addr: 0x13800000
partition_size: 0x800000
- We turn off the phone
- we switch to EDL mode with the python script "bypass_utility-v.1.4.2" (see on the web for installation and other information, among other things to unbrick the phone)
- we do a "readback" of the "seccfg" partition with SPFlashTool using linear_start_addr: 0x13800000 and partition_size: 0x800000 (check the location on the PC, where the "seccfg" partition will be saved with the name you have chosen)
2) Modify your "seccfg" partition:
* We edit the "seccfg" partition with a hexadecimal editor (Notepad or other)
- Total size 000000000 to 007ffff0 (000000040 to 007ffff0 : zero bytes = 00)
- Address 000000000 to 00000003f, we find :
0000000 to 000000f
4d 4d 4d 4d 04 00 00 00 3c 00 00 00 02 00 00 00
0000010 to 000001f
00 00 00 00 00 00 00 00 45 45 45 45 3d aa 79 3b
0000020 to 000002f
eb b0 56 bd 53 48 d3 6e 7d 54 a0 41 0c 2d 1a 90
0000030 to 000003f
58 1a 9c 5f ab 90 cc 0f 5c 11 63 a2 00 00 00 00
(The bootloader is locked!)
- We modify with our hexadecimal editor (Address 000000000 to 000000030) :
0000000 to 000000f
4d 4d 4d 4d 04 00 00 00 3c 00 00 00 03 00 00 00
0000010 to 000001f
00 00 00 00 00 00 00 00 45 45 45 45 57 b3 59 5d
0000020 to 000002f
9e bc 3d 02 33 91 84 9a 42 59 54 8e 07 aa 0f 34
0000030 to 000003f
f1 bb 1e 47 ea 8e cf 76 fb de 79 7b 00 00 00 00
(The bootloader is unlocked!)
- We save our changes
3) Write your "seccfg" partition on the phone:
* We flash the "seccfg" partition
- fastboot flash seccfg "path on your PC"\"name of your saved seccfg partition" (E:\MyFolder\Partition_seccfg for example), in fastboot mode,
- SPFlashTool using EDL mode with the python script "bypass_utility-v.1.4.2 "and by flashing your rom by not checking that the partition "seccfg",
- in adb mode, with the opposite operation, after having copied your partion "seccfg" on the internal memory of the telephone (name "Partition_seccfg" that I gave and that you choose) :
adb shell dd if=/sdcard/Partition_seccfg of=/dev/block/sdc13
- We restart the phone and the bootloader is unlocked without intervention from Xiaomi or other!
4) Warning :
Once all this information is published, subsequent MIUI updates may destroy our efforts by scheduling the bootloader release in a more complicated way!
Click to expand...
Click to collapse
i am getting this error
josephmh said:
View attachment 5448767
i am getting this error
Click to expand...
Click to collapse
Use mtkclient. Google it, read and do.
Kirasu2080 said:
Use mtkclient. Google it, read and do.
Click to expand...
Click to collapse
Thnx dude.
Bootloader is unlocked but i can't access fastboot mode
I get this message :
The serial is not match fastboot_unlock_verify fail
josephmh said:
Thnx dude.
Bootloader is unlocked but i can't access fastboot mode
I get this message :
The serial is not match fastboot_unlock_verify fail
Click to expand...
Click to collapse
I didn't see anyone report that error until now (many tested).
Try again like this:
Join Telegram group and ask for help if not work.
josephmh said:
Thnx dude.
Bootloader is unlocked but i can't access fastboot mode
I get this message :
The serial is not match fastboot_unlock_verify fail
Click to expand...
Click to collapse
Almost EVERY smartphone manufacturer sets a Fastboot verification flag to verify if the Fastboot is really unlocked or not. As in the case of Redmi the bootloader unlock verification is done by the devinfo partition by verifying the flag. Since using the tool you just unlocked the bootloader, Fastboot can't be accessed. Just flash anything u want through SP Flash Tool. Or ask any kind human here for their devinfo and set the unlock flag yourself.
llxxVENOMxxll said:
Almost EVERY smartphone manufacturer sets a Fastboot verification flag to verify if the Fastboot is really unlocked or not. As in the case of Redmi the bootloader unlock verification is done by the devinfo partition by verifying the flag. Since using the tool you just unlocked the bootloader, Fastboot can't be accessed. Just flash anything u want through SP Flash Tool. Or ask any kind human here for their devinfo and set the unlock flag yourself.
Click to expand...
Click to collapse
Don't try this if your a noob and mess your phone.
llxxVENOMxxll said:
Don't try this if your a noob and mess your phone.
Click to expand...
Click to collapse
I was on android 11 i couldn't enter even recovery and i was having that dm-verity corruption, i downloaded the oldest firmware i can get which is android 10 nd flash it with sp flash tool now i can access recovery (colorOs recovery) nd i tried unofficial twrp recovery the phone can't boot to recovery until i reflashed the stock recovery by the way i have Oppo reno 3 cph2043 not redmi note 8
josephmh said:
I was on android 11 i couldn't enter even recovery and i was having that dm-verity corruption, i downloaded the oldest firmware i can get which is android 10 nd flash it with sp flash tool now i can access recovery (colorOs recovery) nd i tried unofficial twrp recovery the phone can't boot to recovery until i reflashed the stock recovery by the way i have Oppo reno 3 cph2043 not redmi note 8
Click to expand...
Click to collapse
The DM-Verity error is due to the unlock is not official. So it will happen. The device should normally boot after showing you the error for 5 seconds. If it doesn't then you're doomed.
llxxVENOMxxll said:
The DM-Verity error is due to the unlock is not official. So it will happen. The device should normally boot after showing you the error for 5 seconds. If it doesn't then you're doomed
Click to expand...
Click to collapse
As i said that error doesn't show on android 10 i downgraded the phone to colorOs7 which is android 10 not 11 but not i have fastboot_unlock_verify fail .. and when i go to developer options -> oem unlock it shows that bootloader is unlocked
Even my OPPO (A31 CPH2015) shows the same problem. We need to find a workaround or get rid of ColorOS forever.
Someone had that problem in Redmi note 8 pro also even official way. Some said press power 1 time whenever that dm-verity show (they just accept and live with it). Some used global one then clean flash China rom, patch vbmeta,... and it gone. Some flash random custom roms and it disappear. Hope these info can help you guys.
RahanCrau said:
Hello
The seccfg partition unlocks the device.
You must initially unlock the bootloader through the MiUnlock application, then recover (save) the seccfg partition (which contains the bootloader unlock information). But, it is easier to get rid of the requirement of the MiUnlock app.
1) Recover your "seccfg" partition:
* the phone in normal mode =
- We launch the command prompt and we write
adb shell
ls -al /dev/block/by-name
or
adb shell
ls -al /dev/block/platform/bootdevice/by-name
- Output (looking for "seccfg") =
lrwxrwxrwx 1 root root 16 2021-03-06 23:25 seccfg -> /dev/block/sdc13
- We get "seccfg" on the internal memory =
dd if =/dev/block/sdc13 of =/sdcard/Partition_seccfg
(I named "Partition_seccfg", but you give the name you want)
- You save "Partition_seccfg" on your PC
* We can recover the "seccfg" partition by SPFlashTool
- Edit your "MT6785_Android_scatter.txt" from a stock ROM (with Notepad or other)
- We are looking for "seccfg" =
partition_index: SYS14
partition_name: seccfg
file_name: NONE
is_download: false
type: NORMAL_ROM
linear_start_addr: 0x13800000
physical_start_addr: 0x13800000
partition_size: 0x800000
- We turn off the phone
- we switch to EDL mode with the python script "bypass_utility-v.1.4.2" (see on the web for installation and other information, among other things to unbrick the phone)
- we do a "readback" of the "seccfg" partition with SPFlashTool using linear_start_addr: 0x13800000 and partition_size: 0x800000 (check the location on the PC, where the "seccfg" partition will be saved with the name you have chosen)
2) Modify your "seccfg" partition:
* We edit the "seccfg" partition with a hexadecimal editor (Notepad or other)
- Total size 000000000 to 007ffff0 (000000040 to 007ffff0 : zero bytes = 00)
- Address 000000000 to 00000003f, we find :
0000000 to 000000f
4d 4d 4d 4d 04 00 00 00 3c 00 00 00 02 00 00 00
0000010 to 000001f
00 00 00 00 00 00 00 00 45 45 45 45 3d aa 79 3b
0000020 to 000002f
eb b0 56 bd 53 48 d3 6e 7d 54 a0 41 0c 2d 1a 90
0000030 to 000003f
58 1a 9c 5f ab 90 cc 0f 5c 11 63 a2 00 00 00 00
(The bootloader is locked!)
- We modify with our hexadecimal editor (Address 000000000 to 000000030) :
0000000 to 000000f
4d 4d 4d 4d 04 00 00 00 3c 00 00 00 03 00 00 00
0000010 to 000001f
00 00 00 00 00 00 00 00 45 45 45 45 57 b3 59 5d
0000020 to 000002f
9e bc 3d 02 33 91 84 9a 42 59 54 8e 07 aa 0f 34
0000030 to 000003f
f1 bb 1e 47 ea 8e cf 76 fb de 79 7b 00 00 00 00
(The bootloader is unlocked!)
- We save our changes
3) Write your "seccfg" partition on the phone:
* We flash the "seccfg" partition
- fastboot flash seccfg "path on your PC"\"name of your saved seccfg partition" (E:\MyFolder\Partition_seccfg for example), in fastboot mode,
- SPFlashTool using EDL mode with the python script "bypass_utility-v.1.4.2 "and by flashing your rom by not checking that the partition "seccfg",
- in adb mode, with the opposite operation, after having copied your partion "seccfg" on the internal memory of the telephone (name "Partition_seccfg" that I gave and that you choose) :
adb shell dd if=/sdcard/Partition_seccfg of=/dev/block/sdc13
- We restart the phone and the bootloader is unlocked without intervention from Xiaomi or other!
4) Warning :
Once all this information is published, subsequent MIUI updates may destroy our efforts by scheduling the bootloader release in a more complicated way!
Click to expand...
Click to collapse
Syed Abdul Sami said:
So i have redmi note 8 pro with chinese rom stable 12.5 .. the phone bootloader is locked , i tried to unlock the bootloader in normal way by bining an MI account but i am unable to bind mi account to device in developer settings BECAUSE ( the phone IMEI is changed) so its always gives an error of request timeout upon clicking bind account.. morever i tried evry vpn and other possible way to bind my account to unlock bootloader but unable to do it..
Can anyone help me out of this . Because i want to use global rom with google play which i cant do until unlocking bootloader.
I need any possible official or UNofficial way to unlock my redmi note 8 pro bootloader..
Your help would be appreciated. Thankyou
Click to expand...
Click to collapse
josephmh said:
Thnx dude.
Bootloader is unlocked but i can't access fastboot mode
I get this message :
The serial is not match fastboot_unlock_verify fail
Click to expand...
Click to collapse
josephmh: how you did it?? please help.
nijat1122 said:
josephmh: how you did it?? please help.
Click to expand...
Click to collapse
Use bypass-utility to enter BROM mode nd then unlock with mtkclient or mtkuniversal google it u'll find the how to use them
Hoping I can get some assistance. Seeing as TWRP isn't a viable option right now for the OnePlus 11, I'm curious if there is a good way to do a full system backup/restore (mimic what TWRP did) using ADB or some other native way or application. When I last played around with Titanium I didn't see a good way of performing this task. It's possible I wasn't doing it correctly, but I was playing around with the batch options and couldn't get it to do anything.
Anyway, my thought was to write a powershell script and backup all the partitions that way, but here is my question. On my oneplus 11 (I have the CPH2451 model) I can go to "/dev/block/by-name" and see all the partitions. I can use the adb shell dd if of command to copy it to my sd card and then pull it on to my computer for example, but is this the proper process to back up the system, data, settings?
I notice in TWRP when you go through the backup process, you have the option to backup boot, system, vendor/OEM, data, modem, efs partitions. That leads me to my next question when I traverse through the path I posted above, there are a ton of partitions there, not to mention many duplicate for exable boot_a and boot_b. So when I back it up would I need to back up everything or is there a fast & clean way to backup the minimum required data without missing anything important?
Root and try Swift for app, phone, sms backups.
Otherwise, since almost none of the other partitions are writable anymore, it's pretty pointless backing them up. But you could with DD (again, you would need to be rooted)... fastboot and fastbootd should be capable of writing the partitions back to the device.
All you need to backup is /data since all others are included in your firmware. Problem when do a backup of /data: You need to perform the backup while system is running. You can't access /data from outside the system without TWRP. If you perform a backup use Termux and the tar command for it. The built in tar command of Android is very limited. Termux offers you a full version of tar.
kevp75 said:
Root and try Swift for app, phone, sms backups.
Otherwise, since almost none of the other partitions are writable anymore, it's pretty pointless backing them up. But you could with DD (again, you would need to be rooted)... fastboot and fastbootd should be capable of writing the partitions back to the device.
Click to expand...
Click to collapse
Thanks for your reply. My device is rooted so that's not a problem. It's just a shame that TWRP doesn't seem to be a viable option. As far as SMS back goes, I'm not too concerned about that because I primarily use google voice, so basically all my contacts and SMS/MMS is saved in the cloud. My biggest concern is just getting a working backup of the system/configurations because I tend to do quite a bit of customizations on my phone and it would suck having to redo everything.
WoKoschekk said:
All you need to backup is /data since all others are included in your firmware. Problem when do a backup of /data: You need to perform the backup while system is running. You can't access /data from outside the system without TWRP. If you perform a backup use Termux and the tar command for it. The built in tar command of Android is very limited. Termux offers you a full version of tar.
Click to expand...
Click to collapse
Thank you as well for your reply. I'm assuming termux is a android based terminal? if termux can do it; would adb/adb shell be able to? The only reason I ask is because it's much easier to type commands from a computer than on the phone. Also what commands would I use? Is there a tut I can follow?
m0d hipp¥ said:
termux can do it; would adb/adb shell be able to?
Click to expand...
Click to collapse
Yes, Termux is an app. ADB could do, but with ADB you have only access to Android's built in commands in /system/bin. Termux offers an own environment with full versions of all the limited built in ones.
WoKoschekk said:
Yes, Termux is an app. ADB could do, but with ADB you have only access to Android's built in commands in /system/bin. Termux offers an own environment with full versions of all the limited built in ones.
Click to expand...
Click to collapse
That makes sense. I'll have to play around with it after work and see what I can figure out. Thanks
There are a few things to take care of. I'll post them later here.
For those who are not rooted:
OnePlus Clone Phone app allows to create full backs by copying apps and their data to a different OnePlus/Oppo phone.
adb backup/restore has long stopped working "thanks" to Google.
Sorry I haven't had a chance to test the methods above, but just to be more clear on my end, I'm not super concerned about backing up apps because there are several ways of doing that. Lucky patcher among other tools allows you to backup apps & app settings. I'm a bit more concerned about system settings/configurations. For example if I wanted to do a backup of my current state the system is in. I have over 100 apps disabled and having to redo that is a bit tedious. Not only that, but also all the configurations I have made within the system settings I'd like to save those as well. So this is really what I'm targeting.
EDIT:
For starters I wrote this simple script in Powershell that gets all the partitions on my device.
Code:
$Partition_Path = "/dev/block/bootdevice/by-name"
foreach($Partition in $(adb shell ls $Partition_Path))
{
$Partition
}
The output is the following:
Code:
ALIGN_TO_128K_1
ALIGN_TO_128K_2
DRIVER
abl_a
abl_b
aop_a
aop_b
aop_config_a
aop_config_b
apdp
apdp_full
apdpb
bluetooth_a
bluetooth_b
boot_a
boot_b
cdt
connsec
cpucp_a
cpucp_b
ddr
devcfg_a
devcfg_b
devinfo
dinfo
dip
dsp_a
dsp_b
dtbo_a
dtbo_b
engineering_cdt_a
engineering_cdt_b
featenabler_a
featenabler_b
frp
fsc
fsg
hyp_a
hyp_b
imagefv_a
imagefv_b
init_boot_a
init_boot_b
keymaster_a
keymaster_b
keystore
last_parti
limits
limits-cdsp
logdump
logfs
mdcompress
mdm1oemnvbktmp
mdtp_a
mdtp_b
mdtpsecapp_a
mdtpsecapp_b
metadata
misc
modem_a
modem_b
modemst1
modemst2
multiimgoem_a
multiimgoem_b
multiimgqti_a
multiimgqti_b
ocdt
oplus_sec_a
oplus_sec_b
oplusdycnvbk
oplusreserve1
oplusreserve2
oplusreserve3
oplusreserve4
oplusreserve5
oplusstanvbk_a
oplusstanvbk_b
param
persist
preisp_dt
preisp_dt_bk
preisp_otp
qmcs
qupfw_a
qupfw_b
qweslicstore_a
qweslicstore_b
rawdump
recovery_a
recovery_b
rtice
rticmpdata_a
rticmpdata_b
secdata
shrm_a
shrm_b
splash_a
splash_b
splash_odm
spunvm
ssd
storsec
super
toolsfv
tz_a
tz_b
tzsc
uefi_a
uefi_b
uefisecapp_a
uefisecapp_b
uefivarstore
userdata
vbmeta_a
vbmeta_b
vbmeta_system_a
vbmeta_system_b
vbmeta_vendor_a
vbmeta_vendor_b
vendor_boot_a
vendor_boot_b
vm-bootsys_a
vm-bootsys_b
vm-data
vm-persist
xbl_a
xbl_b
xbl_config_a
xbl_config_b
xbl_ramdump_a
xbl_ramdump_b
xbl_sc_logs
xbl_sc_test_mode
My question is if I went the termux route or the adb shell route to try and do a backup using the command:
Code:
adb exec-out "su -c dd if=$Partition_Path/$Partition of=/sdcard/Backup/$Partition.img"
which of these partitions would be the ones I should focus on backing up? By the way, there are 3 partitions that are HUGE so I don't think they're necessary, but let me know if they are. The 3 partitions are super, userdata, and logdump. By the way userdata is like over 100Gb, and that's unrealistic because my phone def doesn't have that much data on there.
m0d hipp¥ said:
Sorry I haven't had a chance to test the methods above, but just to be more clear on my end, I'm not super concerned about backing up apps because there are several ways of doing that. Lucky patcher among other tools allows you to backup apps & app settings. I'm a bit more concerned about system settings/configurations. For example if I wanted to do a backup of my current state the system is in. I have over 100 apps disabled and having to redo that is a bit tedious. Not only that, but also all the configurations I have made within the system settings I'd like to save those as well. So this is really what I'm targeting.
EDIT:
For starters I wrote this simple script in Powershell that gets all the partitions on my device.
Code:
$Partition_Path = "/dev/block/bootdevice/by-name"
foreach($Partition in $(adb shell ls $Partition_Path))
{
$Partition
}
The output is the following:
Code:
ALIGN_TO_128K_1
ALIGN_TO_128K_2
DRIVER
abl_a
abl_b
aop_a
aop_b
aop_config_a
aop_config_b
apdp
apdp_full
apdpb
bluetooth_a
bluetooth_b
boot_a
boot_b
cdt
connsec
cpucp_a
cpucp_b
ddr
devcfg_a
devcfg_b
devinfo
dinfo
dip
dsp_a
dsp_b
dtbo_a
dtbo_b
engineering_cdt_a
engineering_cdt_b
featenabler_a
featenabler_b
frp
fsc
fsg
hyp_a
hyp_b
imagefv_a
imagefv_b
init_boot_a
init_boot_b
keymaster_a
keymaster_b
keystore
last_parti
limits
limits-cdsp
logdump
logfs
mdcompress
mdm1oemnvbktmp
mdtp_a
mdtp_b
mdtpsecapp_a
mdtpsecapp_b
metadata
misc
modem_a
modem_b
modemst1
modemst2
multiimgoem_a
multiimgoem_b
multiimgqti_a
multiimgqti_b
ocdt
oplus_sec_a
oplus_sec_b
oplusdycnvbk
oplusreserve1
oplusreserve2
oplusreserve3
oplusreserve4
oplusreserve5
oplusstanvbk_a
oplusstanvbk_b
param
persist
preisp_dt
preisp_dt_bk
preisp_otp
qmcs
qupfw_a
qupfw_b
qweslicstore_a
qweslicstore_b
rawdump
recovery_a
recovery_b
rtice
rticmpdata_a
rticmpdata_b
secdata
shrm_a
shrm_b
splash_a
splash_b
splash_odm
spunvm
ssd
storsec
super
toolsfv
tz_a
tz_b
tzsc
uefi_a
uefi_b
uefisecapp_a
uefisecapp_b
uefivarstore
userdata
vbmeta_a
vbmeta_b
vbmeta_system_a
vbmeta_system_b
vbmeta_vendor_a
vbmeta_vendor_b
vendor_boot_a
vendor_boot_b
vm-bootsys_a
vm-bootsys_b
vm-data
vm-persist
xbl_a
xbl_b
xbl_config_a
xbl_config_b
xbl_ramdump_a
xbl_ramdump_b
xbl_sc_logs
xbl_sc_test_mode
My question is if I went the termux route or the adb shell route to try and do a backup using the command:
Code:
adb exec-out "su -c dd if=$Partition_Path/$Partition of=/sdcard/Backup/$Partition.img"
which of these partitions would be the ones I should focus on backing up? By the way, there are 3 partitions that are HUGE so I don't think they're necessary, but let me know if they are. The 3 partitions are super, userdata, and logdump. By the way userdata is like over 100Gb, and that's unrealistic because my phone def doesn't have that much data on there.
Click to expand...
Click to collapse
All settings and apps and app data is stored on /data. If you backup /data and save it on /sdcard (which is the path /data/media/0) your backup runs infinitely
TWRP does a backup either by dd or with tar. The command dd creates an image and tar an archive. It doesn't make sense to create an image of /data for two reasons: encryption will be corrupt and you don't have enough storage space on /data to save an image of /data.
What TWRP does: Create an archive of /data with tar, but exclude /data/media. It looks like this in Termux:
Code:
tar -cv --exclude='media/*' --file=/storage/$EXT/data.ext4.win000 /data
This saves the backup on an external sd. You can change it to
Code:
tar -cv --exclude='media/*' --file=/data/media/0/data.ext4.win000 /data
for saving the backup in your internal storage.
WoKoschekk said:
All settings and apps and app data is stored on /data. If you backup /data and save it on /sdcard (which is the path /data/media/0) your backup runs infinitely
Click to expand...
Click to collapse
So basically infinite loop? Is there any way to break out of it? Or what if I back it up to another partition that has RW and then when it's done move it to the sdcard?
Also I'm trying to understand how to use tar with exec-out. Would it be something like this:
Code:
adb exec-out "su -c dd if=/dev/block/bootdevice/by-name/userdata && tar -cz -p --exclude='media*' --exclude='*-cache' /sdcard/userdata.tar"
it's also possible to split the archive in several parts:
Code:
tar -cv --exclude='media/*' -ML 1572864 --file=/data/media/0/data.ext4.win000 --file=/data/media/0/data.ext4.win001 --file=/data/media/0/data.ext4.win002 /data
this way you get 3 parts with a size of 1,5GB for each of it.
please wait, it's a bit more complicated
do you have a TWRP backup of any phone?
Unfortunately I don't have a phone with TWRP. I do have a oneplus 9 Pro (LE2125) on hand, but it doesn't have TWRP either. As far as I am aware TWRP isn't available for the OP9 pro.
By the way, I really appreciate your help and your examples. Thank you!
m0d hipp¥ said:
Unfortunately I don't have a phone with TWRP. I do have a oneplus 9 Pro (LE2125) on hand, but it doesn't have TWRP either. As far as I am aware TWRP isn't available for the OP9 pro.
By the way, I really appreciate your help and your examples. Thank you!
Click to expand...
Click to collapse
The 9 pro has twrp and it works on oos13 too.
m0d hipp¥ said:
Unfortunately I don't have a phone with TWRP. I do have a oneplus 9 Pro (LE2125) on hand, but it doesn't have TWRP either. As far as I am aware TWRP isn't available for the OP9 pro.
By the way, I really appreciate your help and your examples. Thank you!
Click to expand...
Click to collapse
Ok, here is a part of the recovery.log by TWRP. It starts with the beginning of a backup of /data:
Code:
I:operation_start: 'Nandroid'
Updating partition details...
I:Data backup size is 5760MB, free: 43310MB.
I:Unable to mount '/usb-otg'
I:Actual block device: '', current file system: 'auto'
...done
I:Backup Name is: '2023-06-07--22-01-50'
I:Backup_Folder is: '/external_sd/TWRP/BACKUPS/ZY322V8K28/2023-06-07--22-01-50'
I:Calculating backup details...
* Total number of partitions to back up: 1
* Total size of all data: 5760MB
* Available space: 53009MB
[BACKUP STARTED]
* Backup Folder: /external_sd/TWRP/BACKUPS/ZY322V8K28/2023-06-07--22-01-50
Invalid encryption mode file /data/unencrypted/mode
Backing up Data (excl. storage)...
Backups of Data do not include any files in internal storage such as pictures or downloads.
Invalid encryption mode file /data/unencrypted/mode
Breaking backup file into multiple archives...
I:Creating backup...
I:Creating tar file '/external_sd/TWRP/BACKUPS/ZY322V8K28/2023-06-07--22-01-50/data.ext4.win000'
I:addFile '/data/ota' including root: 1
==> set selinux context: u:object_r:ota_data_file:s0
Click to expand...
Click to collapse
TWRP does exclude the "storage" which is /data/media. This directory gets always mounted as /storage/emulated/0 for security reasons on every Android phone.The path /storage/emulated/0 is the sdcardfs (virtual filesystem, see here for more info). Additionally it's always linked as /sdcard in the system.
So, /data/media = /storage/emulated/0 = /sdcard!
The log shows also that TWRP saves the files of /data as a tar archive. But tar ≠ tar if you compare Android's tar with the one of Termux.
Android's tar:
Code:
usage: tar -[cxtjzhmvO] [-X FILE] [-T FILE] [-f TARFILE] [-C DIR]
Create, extract, or list files from a tar file
Operation:
c Create
f Name of TARFILE ('-' for stdin/out)
h Follow symlinks
j (De)compress using bzip2
m Don't restore mtime
t List
v Verbose
x Extract
z (De)compress using gzip
C Change to DIR before operation
O Extract to stdout
exclude=FILE File to exclude
X File with names to exclude
T File with names to include
Termux:
Code:
Usage: tar [OPTION...] [FILE]...
GNU 'tar' saves many files together into a single tape or disk archive, and can
restore individual files from the archive.
Examples:
tar -cf archive.tar foo bar # Create archive.tar from files foo and bar.
tar -tvf archive.tar # List all files in archive.tar verbosely.
tar -xf archive.tar # Extract all files from archive.tar.
Main operation mode:
-A, --catenate, --concatenate append tar files to an archive
-c, --create create a new archive
--delete delete from the archive (not on mag tapes!)
-d, --diff, --compare find differences between archive and file system
-r, --append append files to the end of an archive
--test-label test the archive volume label and exit
-t, --list list the contents of an archive
-u, --update only append files newer than copy in archive
-x, --extract, --get extract files from an archive
Operation modifiers:
--check-device check device numbers when creating incremental
archives (default)
-g, --listed-incremental=FILE handle new GNU-format incremental backup
-G, --incremental handle old GNU-format incremental backup
--hole-detection=TYPE technique to detect holes
--ignore-failed-read do not exit with nonzero on unreadable files
--level=NUMBER dump level for created listed-incremental archive
--no-check-device do not check device numbers when creating
incremental archives
--no-seek archive is not seekable
-n, --seek archive is seekable
--occurrence[=NUMBER] process only the NUMBERth occurrence of each file
in the archive; this option is valid only in
conjunction with one of the subcommands --delete,
--diff, --extract or --list and when a list of
files is given either on the command line or via
the -T option; NUMBER defaults to 1
--sparse-version=MAJOR[.MINOR]
set version of the sparse format to use (implies
--sparse)
-S, --sparse handle sparse files efficiently
Local file name selection:
--add-file=FILE add given FILE to the archive (useful if its name
starts with a dash)
-C, --directory=DIR change to directory DIR
--exclude=PATTERN exclude files, given as a PATTERN
--exclude-backups exclude backup and lock files
--exclude-caches exclude contents of directories containing
CACHEDIR.TAG, except for the tag file itself
--exclude-caches-all exclude directories containing CACHEDIR.TAG
--exclude-caches-under exclude everything under directories containing
CACHEDIR.TAG
--exclude-ignore=FILE read exclude patterns for each directory from
FILE, if it exists
--exclude-ignore-recursive=FILE
read exclude patterns for each directory and its
subdirectories from FILE, if it exists
--exclude-tag=FILE exclude contents of directories containing FILE,
except for FILE itself
--exclude-tag-all=FILE exclude directories containing FILE
--exclude-tag-under=FILE exclude everything under directories
containing FILE
--exclude-vcs exclude version control system directories
--exclude-vcs-ignores read exclude patterns from the VCS ignore files
--no-null disable the effect of the previous --null option
--no-recursion avoid descending automatically in directories
--no-unquote do not unquote input file or member names
--no-verbatim-files-from -T treats file names starting with dash as
options (default)
--null -T reads null-terminated names; implies
--verbatim-files-from
--recursion recurse into directories (default)
-T, --files-from=FILE get names to extract or create from FILE
--unquote unquote input file or member names (default)
--verbatim-files-from -T reads file names verbatim (no escape or option
handling)
-X, --exclude-from=FILE exclude patterns listed in FILE
File name matching options (affect both exclude and include patterns):
--anchored patterns match file name start
--ignore-case ignore case
--no-anchored patterns match after any '/' (default for
exclusion)
--no-ignore-case case sensitive matching (default)
--no-wildcards verbatim string matching
--no-wildcards-match-slash wildcards do not match '/'
--wildcards use wildcards (default for exclusion)
--wildcards-match-slash wildcards match '/' (default for exclusion)
Overwrite control:
--keep-directory-symlink preserve existing symlinks to directories when
extracting
--keep-newer-files don't replace existing files that are newer than
their archive copies
-k, --keep-old-files don't replace existing files when extracting,
treat them as errors
--no-overwrite-dir preserve metadata of existing directories
--one-top-level[=DIR] create a subdirectory to avoid having loose files
extracted
--overwrite overwrite existing files when extracting
--overwrite-dir overwrite metadata of existing directories when
extracting (default)
--recursive-unlink empty hierarchies prior to extracting directory
--remove-files remove files after adding them to the archive
--skip-old-files don't replace existing files when extracting,
silently skip over them
-U, --unlink-first remove each file prior to extracting over it
-W, --verify attempt to verify the archive after writing it
Select output stream:
--ignore-command-error ignore exit codes of children
--no-ignore-command-error treat non-zero exit codes of children as
error
-O, --to-stdout extract files to standard output
--to-command=COMMAND pipe extracted files to another program
Handling of file attributes:
--atime-preserve[=METHOD] preserve access times on dumped files, either
by restoring the times after reading
(METHOD='replace'; default) or by not setting the
times in the first place (METHOD='system')
--clamp-mtime only set time when the file is more recent than
what was given with --mtime
--delay-directory-restore delay setting modification times and
permissions of extracted directories until the end
of extraction
--group=NAME force NAME as group for added files
--group-map=FILE use FILE to map file owner GIDs and names
--mode=CHANGES force (symbolic) mode CHANGES for added files
--mtime=DATE-OR-FILE set mtime for added files from DATE-OR-FILE
-m, --touch don't extract file modified time
--no-delay-directory-restore
cancel the effect of --delay-directory-restore
option
--no-same-owner extract files as yourself (default for ordinary
users)
--no-same-permissions apply the user's umask when extracting permissions
from the archive (default for ordinary users)
--numeric-owner always use numbers for user/group names
--owner=NAME force NAME as owner for added files
--owner-map=FILE use FILE to map file owner UIDs and names
-p, --preserve-permissions, --same-permissions
extract information about file permissions
(default for superuser)
--same-owner try extracting files with the same ownership as
exists in the archive (default for superuser)
--sort=ORDER directory sorting order: none (default), name or
inode
-s, --preserve-order, --same-order
member arguments are listed in the same order as
the files in the archive
Handling of extended file attributes:
--acls Enable the POSIX ACLs support
--no-acls Disable the POSIX ACLs support
--no-selinux Disable the SELinux context support
--no-xattrs Disable extended attributes support
--selinux Enable the SELinux context support
--xattrs Enable extended attributes support
--xattrs-exclude=MASK specify the exclude pattern for xattr keys
--xattrs-include=MASK specify the include pattern for xattr keys
Device selection and switching:
--force-local archive file is local even if it has a colon
-f, --file=ARCHIVE use archive file or device ARCHIVE
-F, --info-script=NAME, --new-volume-script=NAME
run script at end of each tape (implies -M)
-L, --tape-length=NUMBER change tape after writing NUMBER x 1024 bytes
-M, --multi-volume create/list/extract multi-volume archive
--rmt-command=COMMAND use given rmt COMMAND instead of rmt
--rsh-command=COMMAND use remote COMMAND instead of rsh
--volno-file=FILE use/update the volume number in FILE
Device blocking:
-b, --blocking-factor=BLOCKS BLOCKS x 512 bytes per record
-B, --read-full-records reblock as we read (for 4.2BSD pipes)
-i, --ignore-zeros ignore zeroed blocks in archive (means EOF)
--record-size=NUMBER NUMBER of bytes per record, multiple of 512
Archive format selection:
-H, --format=FORMAT create archive of the given format
FORMAT is one of the following:
gnu GNU tar 1.13.x format
oldgnu GNU format as per tar <= 1.12
pax POSIX 1003.1-2001 (pax) format
posix same as pax
ustar POSIX 1003.1-1988 (ustar) format
v7 old V7 tar format
--old-archive, --portability
same as --format=v7
--pax-option=keyword[[:]=value][,keyword[[:]=value]]...
control pax keywords
--posix same as --format=posix
-V, --label=TEXT create archive with volume name TEXT; at
list/extract time, use TEXT as a globbing pattern
for volume name
Compression options:
-a, --auto-compress use archive suffix to determine the compression
program
-I, --use-compress-program=PROG
filter through PROG (must accept -d)
-j, --bzip2 filter the archive through bzip2
-J, --xz filter the archive through xz
--lzip filter the archive through lzip
--lzma filter the archive through lzma
--lzop filter the archive through lzop
--no-auto-compress do not use archive suffix to determine the
compression program
--zstd filter the archive through zstd
-z, --gzip, --gunzip, --ungzip filter the archive through gzip
-Z, --compress, --uncompress filter the archive through compress
Local file selection:
--backup[=CONTROL] backup before removal, choose version CONTROL
--hard-dereference follow hard links; archive and dump the files they
refer to
-h, --dereference follow symlinks; archive and dump the files they
point to
-K, --starting-file=MEMBER-NAME
begin at member MEMBER-NAME when reading the
archive
--newer-mtime=DATE compare date and time when data changed only
-N, --newer=DATE-OR-FILE, --after-date=DATE-OR-FILE
only store files newer than DATE-OR-FILE
--one-file-system stay in local file system when creating archive
-P, --absolute-names don't strip leading '/'s from file names
--suffix=STRING backup before removal, override usual suffix ('~'
unless overridden by environment variable
SIMPLE_BACKUP_SUFFIX)
File name transformations:
--strip-components=NUMBER strip NUMBER leading components from file
names on extraction
--transform=EXPRESSION, --xform=EXPRESSION
use sed replace EXPRESSION to transform file
names
Informative output:
--checkpoint[=NUMBER] display progress messages every NUMBERth record
(default 10)
--checkpoint-action=ACTION execute ACTION on each checkpoint
--full-time print file time to its full resolution
--index-file=FILE send verbose output to FILE
-l, --check-links print a message if not all links are dumped
--no-quote-chars=STRING disable quoting for characters from STRING
--quote-chars=STRING additionally quote characters from STRING
--quoting-style=STYLE set name quoting style; see below for valid STYLE
values
-R, --block-number show block number within archive with each message
--show-defaults show tar defaults
--show-omitted-dirs when listing or extracting, list each directory
that does not match search criteria
--show-snapshot-field-ranges
show valid ranges for snapshot-file fields
--show-transformed-names, --show-stored-names
show file or archive names after transformation
--totals[=SIGNAL] print total bytes after processing the archive;
with an argument - print total bytes when this
SIGNAL is delivered; Allowed signals are: SIGHUP,
SIGQUIT, SIGINT, SIGUSR1 and SIGUSR2; the names
without SIG prefix are also accepted
--utc print file modification times in UTC
-v, --verbose verbosely list files processed
--warning=KEYWORD warning control
-w, --interactive, --confirmation
ask for confirmation for every action
Compatibility options:
-o when creating, same as --old-archive; when
extracting, same as --no-same-owner
Other options:
-?, --help give this help list
--restrict disable use of some potentially harmful options
--usage give a short usage message
--version print program version
Mandatory or optional arguments to long options are also mandatory or optional
for any corresponding short options.
The backup suffix is '~', unless set with --suffix or SIMPLE_BACKUP_SUFFIX.
The version control may be set with --backup or VERSION_CONTROL, values are:
none, off never make backups
t, numbered make numbered backups
nil, existing numbered if numbered backups exist, simple otherwise
never, simple always make simple backups
Valid arguments for the --quoting-style option are:
literal
shell
shell-always
shell-escape
shell-escape-always
c
c-maybe
escape
locale
clocale
*This* tar defaults to:
--format=gnu -f- -b20 --quoting-style=escape
--rmt-command=/data/data/com.termux/files/usr/libexec/rmt
You see the difference...
Download Termux here.
Open it and first of all run pkg update