Related
Various Android devices support Android Verified Boot (AVB). A part of this is more commonly known as dm-verity, which verifies system (and vendor) partition integrity. AVB can however also verify boot images, and stock firmwares generally include signed boot images. Of course this does not mean that all signed boot images are using AVB, many OEMs have their own signature verification scheme.
Note: AOSP is moving towards the use of avbtool (taken from Brillo), the following is the old way for signing boot images.
Bootloaders might or might not accept unsigned boot images, and might or might not accept boot images signed with our own keys (rather than the OEM's keys). This depends on the device, bootloader version, and bootloader unlock state.
For example, with the bootloader unlocked, the Google Pixel (and XL) devices accepted unsigned boot images up to (but not including) the May 2017 release. From the May 2017 release onwards, the boot images must be signed if flashed (booted works without), but may be signed with your own key rather than the OEM's.
Note: The situation changes when you re-lock the bootloader. I have not tested this, but documentation implies that (one of) the keys used in the current boot image must be used for future flashes until it is unlocked again.
Generating custom signing keys
The following openssl commands generate all the keys we need. Execute them line-by-line rather than copying the whole block, as you will be asked for input.
Code:
# private key
openssl genrsa -f4 -out verifiedboot.pem 2048
openssl pkcs8 -in verifiedboot.pem -topk8 -outform DER -out verifiedboot.pk8 -nocrypt
# public key
openssl req -new -x509 -sha256 -key verifiedboot.pem -out verifiedboot.x509.pem
openssl x509 -outform DER -in verifiedboot.x509.pem -out verifiedboot.x509.der
For future signings, you do not need the .pem files, and they can safely be deleted once the .pk8 and .der files are generated. In AOSP's implementation, they were never even written to disk in the first place.
Security-wise, documentation states it is advisable to use a different set of keys for each device you support; though obviously this doesn't matter much if the device is running with the bootloader in unlocked state.
Signing the boot image
Download the attached BootSignature.jar file (built from AOSP sources), and sign the boot image using the keys generated above with the following commands:
Code:
java -jar BootSignature.jar /boot boot.img verifiedboot.pk8 verifiedboot.x509.der boot_signed.img
java -jar BootSignature.jar -verify boot_signed.img
Instead of /boot, /recovery and other values may be used. Their use should be obvious.
From Android
Attached is also BootSignature_Android.jar, which is a version ProGuard-reduced against SDK 21 and then dexed. Provided /system is mounted as is usual on Android (on the Pixel (XL), TWRP mounts this differently by default!), it can be used like this:
Code:
dalvikvm -cp BootSignature_Android.jar com.android.verity.BootSignature /boot boot.img verifiedboot.pk8 verifiedboot.x509.der boot_signed.img
dalvikvm -cp BootSignature_Android.jar com.android.verity.BootSignature -verify boot_signed.img
The base command can be extended as follows to make it able to run without any precompiled files present on the device:
Code:
/system/bin/dalvikvm -Xbootclasspath:/system/framework/core-oj.jar:/system/framework/core-libart.jar:/system/framework/conscrypt.jar:/system/framework/bouncycastle.jar -Xnodex2oat -Xnoimage-dex2oat -cp BootSignature_Android.jar com.android.verity.BootSignature ...
Flashable ZIP
Attached is also VerifiedBootSigner.zip, this is a flashable ZIP for FlashFire/TWRP/etc that signs the currently flashed boot image, if it isn't signed already. You can simply flash this after installing a SuperSU version or custom boot image or whatever that doesn't sign the boot image itself already.
I've tried to make it very portable (borrowing ample script from the SuperSU ZIP, as well as its signing keys), but I have only tested it on my Pixel XL.
Note that it does depend on Android files in the system partition, so if (aside from the unsigned boot image) your system isn't functional, the ZIP may not work either.
If the boot image is already signed when you flash the ZIP, it will offer to abort or force re-sign.
If you place custom.pk8 and custom.x509.der files inside the ZIP, these keys will be used for flashing instead of SuperSU's default keys. Additionally, /tmp/avb/custom.pk8 and /tmp/avb/custom.x509.der will override any keys from the ZIP.
There is some more documentation in the update-binary file inside the ZIP as well.
Note: If you're using TWRP's manual slot selection on the Pixel (XL), you must be using TWRP-v3.1.0-RC2 or newer, or it will not work as expected.
Todo
- test what happens when the bootloader is re-locked on multiple devices supporting AVB
- test what happens when dm-verity is kept enabled on a custom/modified boot image with a different image signature than dm-verity signature
-reserved-
*finally my dream come true, btw, nice job on doing this, keep it up man*
Super great
Great write up! So I take it we can no longer distribute kernel images without first integrating them into the boot image and then signing it? That negates the whole point of being able to flash the kernel individually with fastboot!
thank God Chanifire hasnt left us entirely!!!
This gives me hope my Pixel isn't dev dead. Thank you, CF!
@Chainfire you not going to reply but still, you are responsible i have faith in Android... Development is most of the times happens because of you ....It always revolves around you ... One man army i would say. Thank you for all your works. We all owe you a lot...
Is it possible to create the signature for boot bundle with openssl alone (i.e. without this BootSignature.jar ) ?
Wasn't self-signing boot images already kind of possible?
cr2 said:
Is it possible to create the signature for boot bundle with openssl alone (i.e. without this BootSignature.jar ) ?
Click to expand...
Click to collapse
Not just with openssl, no. How the boot signature works is not properly documented, but of course you could read the source in AOSP and make your own version.
mirhl said:
Wasn't self-signing boot images already kind of possible?
Click to expand...
Click to collapse
Apart from both of these things talking about signatures, they are unrelated. However, self-signing images has been supported for quite a while on several devices, it just wasn't required. CopperheadOS - as far as I know - is the only project that has actively been using it until now.
is it possible to sign the boot image in recovery?
Hi @Chainfire ! Thank you for this great find (and for everything else what you have done for us during the last years )!!
I would like to ask one question... Do you think it would be possible to sign the boot image on the fly in recovery? For example when changing the recovery image, before flashing the boot image back?
Your instructions use "dalvikvm" on android, and I ran the command successfully under a running android system. But what about recovery ?
I would be interested in your thoughts on this
Or am I completely wrong, and images "dumped" via dd can't be signed and flashed back?
I would really appreciate if you could point me in the right direction, how it could be possible to do this. (create an executable instead of the BootSignature.jar file? leave this, because it is not possible? start a java vm under recovery? ....)
Thanks in advance!
gubacsek said:
Hi @Chainfire ! Thank you for this great find (and for everything else what you have done for us during the last years )!!
I would like to ask one question... Do you think it would be possible to sign the boot image on the fly in recovery? For example when changing the recovery image, before flashing the boot image back?
Your instructions use "dalvikvm" on android, and I ran the command successfully under a running android system. But what about recovery ?
I would be interested in your thoughts on this
Or am I completely wrong, and images "dumped" via dd can't be signed and flashed back?
I would really appreciate if you could point me in the right direction, how it could be possible to do this. (create an executable instead of the BootSignature.jar file? leave this, because it is not possible? start a java vm under recovery? ....)
Thanks in advance!
Click to expand...
Click to collapse
Yes, this is possible - I have already tested this on my PIxel XL. SuperSU ZIP will do exactly this in a future update, and @Dees_Troy is also aware of all of this, so I assume TWRP will be updated to do this sooner or later as well.
If I can find the time I'll make a ZIP that does this.
Chainfire said:
Yes, this is possible - I have already tested this on my PIxel XL. SuperSU ZIP will do exactly this in a future update, and @Dees_Troy is also aware of all of this, so I assume TWRP will be updated to do this sooner or later as well.
If I can find the time I'll make a ZIP that does this.
Click to expand...
Click to collapse
Okay! I am very curious about how you solve it... Until then, I'll experiment a bit further
Can't wait to see your result!
Thanks! And have a very nice weekend!
I have attached a flashable ZIP to the opening post. Just flash it after SuperSU / custom boot image / whatever to fix the current boot image.
gubacsek said:
Okay! I am very curious about how you solve it... Until then, I'll experiment a bit further Can't wait to see your result!
Click to expand...
Click to collapse
Chainfire said:
I have attached a flashable ZIP to the opening post. Just flash it after SuperSU / custom boot image / whatever to fix the current boot image.
Click to expand...
Click to collapse
Thank you so much, it worked beautifully on my VZW Pixel with the May update.
:good: working fine on the May update with May bootloader, FK, TWRP and SuperSU
Outstanding as usual!
Chainfire said:
I have attached a flashable ZIP to the opening post. Just flash it after SuperSU / custom boot image / whatever to fix the current boot image.
Click to expand...
Click to collapse
I almost got it I could install TWRP and root but only by signing the boot images on my laptop...
I had a few errors (mounting /system did create a /system/system mount point, and I tried to copy the dalvikvm binary to the zip ), and I wouldn't ever have thought of clearing LD_LIBRARY_PATH
Thank you very much for this solution, and your time spent on this! I learnt a lot today
Nice job!
Chainfire said:
Various Android devices support Android Verified Boot (AVB). A part of this is more commonly known as dm-verity, which verifies system (and vendor) partition integrity. AVB can however also verify boot images, and stock firmwares generally include signed boot images. Of course this does not mean that all signed boot images are using AVB, many OEMs have their own signature verification scheme.
Note: AOSP is moving towards the use of avbtool (taken from Brillo), the following is the old way for signing boot images.
Bootloaders might or might not accept unsigned boot images, and might or might not accept boot images signed with our own keys (rather than the OEM's keys). This depends on the device, bootloader version, and bootloader unlock state.
For example, with the bootloader unlocked, the Google Pixel (and XL) devices accepted unsigned boot images up to (but not including) the May 2017 release. From the May 2017 release onwards, the boot images must be signed if flashed (booted works without), but may be signed with your own key rather than the OEM's.
Note: The situation changes when you re-lock the bootloader. I have not tested this, but documentation implies that (one of) the keys used in the current boot image must be used for future flashes until it is unlocked again.
Generating custom signing keys
The following openssl commands generate all the keys we need. Execute them line-by-line rather than copying the whole block, as you will be asked for input.
For future signings, you do not need the .pem files, and they can safely be deleted once the .pk8 and .der files are generated. In AOSP's implementation, they were never even written to disk in the first place.
Security-wise, documentation states it is advisable to use a different set of keys for each device you support; though obviously this doesn't matter much if the device is running with the bootloader in unlocked state.
Signing the boot image
Download the attached BootSignature.jar file (built from AOSP sources), and sign the boot image using the keys generated above with the following commands:
Instead of /boot, /recovery and other values may be used. Their use should be obvious.
From Android
Attached is also BootSignature_Android.jar, which is a version ProGuard-reduced against SDK 21 and then dexed. Provided /system is mounted as is usual on Android (on the Pixel (XL), TWRP mounts this differently by default!), it can be used like this:
Flashable ZIP
Attached is also VerifiedBootSigner.zip, this is a flashable ZIP for FlashFire/TWRP/etc that signs the currently flashed boot image, if it isn't signed already. You can simply flash this after installing a SuperSU version or custom boot image or whatever that doesn't sign the boot image itself already.
I've tried to make it very portable (borrowing ample script from the SuperSU ZIP, as well as its signing keys), but I have only tested it on my Pixel XL.
Note that it does depend on Android files in the system partition, so if (aside from the unsigned boot image) your system isn't functional, the ZIP may not work either.
Todo
- test what happens when the bootloader is re-locked on multiple devices supporting AVB
- test what happens when dm-verity is kept enabled on a custom/modified boot image with a different image signature than dm-verity signature
Click to expand...
Click to collapse
So are Samsungs latest devices now using this. Reason I ask is because in the S8 and Tab S3 stock firmware there is a META-DATA folder in the AP firmware tar. Inside is a fota.zip containing various folders with all sorts of utilities and files, one of which is BootSignature.jar.
It seems it is required to flash the META-DATA folder with the boot.img in ODIN or it will not boot. So I'm guessing the boot.img is being signed as part of the flashing process?
ashyx said:
So are Samsungs latest devices now using this. Reason I ask is because in the S8 and Tab S3 stock firmware there is a META-DATA folder in the AP firmware tar. Inside is a fota.zip containing various folders with all sorts of utilities and files, one of which is BootSignature.jar.
It seems it is required to flash the META-DATA folder with the boot.img in ODIN or it will not boot. So I'm guessing the boot.img is being signed as part of the flashing process?
Click to expand...
Click to collapse
Possibly. Which S8 are you talking about? I thought there was already working TWRP for S8 Exynos that didn't require anything special?
Chainfire said:
Possibly. Which S8 are you talking about? I thought there was already working TWRP for S8 Exynos that didn't require anything special?
Click to expand...
Click to collapse
New S8. Qualcomm Snapdragon 835 MSM8998 bootloader locked versions.
It's got an eng kernel available, but it's a no go with your s7 script due to no adb write access.
https://forum.xda-developers.com/galaxy-s8/how-to/rd-carrier-switch-root-snapdragon-t3597473/page54
Warning: SELinux – important security feature.
After disabling it you obliviously make Android less secure. Use it on your own risk.
Why it needed?
SELinux can prevent work some mods, like Viper. Or you can have own reasons.
Executing in Terminal "setenforce 0" or via scripts / apps turns SELinux off only after booting: this is not good.
This solution disables SELinux directly in kernel.
Compatible with any MIUI or custom ROM.
How it works
After flashing ZIP creates kernel dump, then it repacks with new command line androidboot.selinux=permissive and writes back.
Into /system/bin copied script.sh and two binaries: mkbootimg and unpackbootimg plus auto-restore script (addon.d)
Last required for keeping and launching that files at every ROM update. This works only on custom ROM's, on MIUI you need re-apply patch manually.
Note: on previous phone at some rare unknown conditions after updating ROM kernel repackaging ended with error and device can't boot.
In this case enter recovery and restore boot from backup or flash boot.img from ROM via fastboot / TWRP.
How to install
1. Once flash attached ZIP
2. Then flash required mods
How to delete
1. Delete file /system/addon.d/99-selinux.sh (and other, that belong to mods that not work with SELinux)
2. Flash current ROM
P.S. This patch probably will work on any device (at least with custom ROM because stock kernel can use different structure).
Rare, but may be required change path to boot partition in script.sh: /dev/block/bootdevice/by-name/boot, twice.
Hi does this method still work in Android 10 and newer?
Great job. This is exactly what I was searching for!
lebigmac said:
does this method still work in Android 10 and newer?
Click to expand...
Click to collapse
Very likely, don't know for sure because still on Pie. Try yourself and share result
When I run this command:
Code:
cat /proc/cmdline
I get this result:
Code:
BOOT_IMAGE=/boot/vmlinuz-5.0.0-13-generic root=UUID=XXXXX-XXXX-XXXX-XXXX-XXXXXXXXX ro quiet splash vt.handoff=1
Maybe in Android 10 and newer they moved the androidboot.selinux=permissive parameter to somewhere else kind of like how they moved the system partition into the super image?
lebigmac said:
Maybe in Android 10 and newer they moved parameter to somewhere else
Click to expand...
Click to collapse
Parameter not present by default.
It's not clear if you tried to flash ZIP. If yes and got no result: probably script can't handle changes in boot.img structure because it was created 4 years ago. Try some tool on PC to unpack boot and add line manually.
repacksuper
===========
Copyleft uluruman 2021-2022
(for LINUX/WSL only)
This is the minimalistic set of tools + a script for Linux for the automated
ground-up repacking and flashing of the Samsung Galaxy super.img, replacing
the stock Android system with something much less intrusive and obtrusive
(e.g. LineageOS). Or just some other GSI (Generic System Image).
Additional included scripts (since v1.1) simplify flashing of stock firmware or
separate image files under Linux using Heimdall.
Theoretically should work for any Samsung A-series phones, and may be even for
some others. Tested on SM-A127F/DSN made in India and Vietnam and SM-A325F/DS
made in India, on Debian Linux 11 x64. There are reports of successful flashing
of SM-A127M, SM-A032M and SM-A226B.
Why this method?
----------------
Repacking of super.img is the only method which allows changing of the phone's
operating system without screwing up the Verified Boot (VB) protection
mechanism. Keeping the VB allows you to be sure that everything besides the
platform was indeed compiled by Samsung and wasn't tampered with, no matter from
where you downloaded your stock firmware.
The other reason is that although there are alternative methods of changing the
OS, for phones with dynamic partitioning and no working version of TWRP
available they may be even more complicated than repacking of super.img
externally by this script.
Requirements
------------
Install the following tools from the official repositories of your Linux distro:
simg2img xz-utils lz4 unzip gzip jq file
Basic instructions
------------------
repacksuper.sh: main script for changing your phone's operating system
heimdall_flash_stock.sh: script for flashing stock firmware under Linux
heimdall_flash.sh: script for flashing any custom image file under Linux
Just run a script without any arguments to see help.
Extra tools used (x64 binaries and sources included)
----------------------------------------------------
GitHub - LonelyFool/lpunpack_and_lpmake: android super.img tools
android super.img tools. Contribute to LonelyFool/lpunpack_and_lpmake development by creating an account on GitHub.
github.com
GitHub - amo13/Heimdall: Heimdall is a cross-platform open-source tool suite used to flash firmware (aka ROMs) onto Samsung Galaxy devices. This is a fork of the original repository with a few crucial pull requests merged.
Heimdall is a cross-platform open-source tool suite used to flash firmware (aka ROMs) onto Samsung Galaxy devices. This is a fork of the original repository with a few crucial pull requests merged....
github.com
Additional notes
----------------
The included binaries for the lpunpack, lpmake and Heimdall were compiled for
the x86_64 architecture. If your PC architecture is different (e.g. x86 32-bit
or ARM) you have to compile these tools yourself. The full source code is
included (or otherwise available on GitHub).
Spoiler: Changelog
0.9: Initial release
0.91: Non-sparse new system is now correctly moved into the super dir
0.91a: Bug in the new system file format checking fixed
0.91b: Better support for spaces in paths
0.92: Added checking for system requirements and an optional parameter for
setting of the final tar archive name.
0.92a: Fixed file ownership issues inside the tar distribution archive
0.93: Added support for SM-A325F. Several minor improvements.
0.94: Added support for gzip-packed GSI images. Packing into .tar is now done
without question if the command line parameter is given. Tar parameter
now can include the full path. Without the full path the default tar
location is now the same as the GSI. Several other minor changes.
1.0: Finally added working native Linux flashing using Heimdall (HUGE thanks
to amo13 and Benjamin Dobell). Two new options: using empty product.img
and silent (non-interactive) mode. Colored text. Bugfixes and minor
changes.
1.01: Option to specify the SUPER partition name manually (needed for flashing
SM-A127F with Heimdall). Now it is possible to place output .img and .tar
files in any directory and give them any name. Text terminology a bit
clarified, help text expanded. Done many internal optimizations,
additional sanity checks and minor changes.
1.02: Support for SM-A032F/M and similar firmwares with non-packed super.img.
Support for firmwares with/without additional partitions. Support for
arbitrary partition group names. Very experimental option to use empty
system_ext.img for additional privacy (applicable to some phone models/
regions). Lots of minor fixes.
1.03: Multiple .img files are now supported in GSI archive files (one of them
should be system.img in that case), e.g. Android AOSP zip files are now
supported directly. The logic of flashing with Heimdall now includes more
complex cases, such as flashing in two steps with a reboot. Unnecessary
code in GZ unpacking removed. Some other small fixes and optimizations.
1.1: New scripts heimdall_flash_stock.sh and heimdall_flash.sh added.
Lots of refactoring in repacksuper.sh (because of that there may be some
bugs left), improved and clarified UI logic, changes in where the files are
now placed (see help for details), direct work with stock Zip firmware
files, lots of minor changes.
1.11: Colored text now should be correctly displayed in almost any shell that
supports it except if it's explicitly disabled with NO_COLOR.
1.11.1: heimdall_flash.sh now can flash Super partitions unconditionally in one
step when using both the -s parameter and manually specifying parition
name (e.g. SUPER for SM-A127F).
1.12: The heimdall_flash_stock.sh script was significantly upgraded with lots of
new features. Now it theoretically allows upgrading of stock firmware
without erasing user data, keeping the GSI and custom recovery, etc.
(although it's not that straightforward, read the help for details).
A couple of fixes in the other scripts.
1.12.1: changed unlz4 to lz4 -d, as some distros don't have the needed symlink
1.13: In repacksuper.sh support added for the Vendor DLKM and ODM DLKM
partitions, as well as the experimental -v option to add or replace Vendor
DLKM with a custom image. A couple of minor fixes.
1.14: Greatly improved logic of heimdall_flash.sh, now it's possible to specify
both or either custom partition name and custom file name, and acquiring
PIT from device is done only when it's needed. Versioning scheme of the
scripts was unified: the script that was updated receives the updated
version number of the whole pack, the rest retain the old numbers.
1.15: up_param_tool.sh script was added: it allows altering of the boot
sequence images (logo, "not official" warning, etc.), as well as the
Recovery and Download internal graphics. Happy hacking, but please pay
attention to the warning displayed after extracting the JPEG files.
A couple of minor fixes in the other scripts.
1.15.1: Bug with failing LZ4 uncompression fixed in repacksuper.sh and
heimdall_flash_stock.sh.
1.15.2: Added the Ctrl+C trap in heimdall_flash_stock.sh, so now the temporarily
renamed files are correctly renamed back in case of flashing being
aborted with Ctrl+C. Upgraded Heimdall with the git pull requests, but
it seems those still do not cure the relatively rare issue when flashing
specific files gets completely stuck at some point.
1.15.3: The "file" tool used to identify PIT files was replaced with direct
reading of the file header as the first method proved to be unreliable.
1.15.4: Fixed a bug in heimdall_flash.sh (missing g flag in sed)
1.15.5: Fixed the compatibility issue with the older LZ4 compressors
1.15.6: Fixed compatibility issues with systems where /bin/sh is Bash, such as
ArchLinux
1.15.7: repacksuper.sh: fixed using the existing "repacksuper" dir as source,
also in this mode you can now specify "-" as new system image to reuse
everything inside the "super" subdir. New experimental -w parameter.
All scripts: the Ctrl+C trap now switched on and off the correct way.
Several other fixes.
1.15.8: Fixed using the heimdall_flash_stock dirs as source for repacksuper.sh.
A couple of other fixes.
1.15.9: heimdall_flash_stock.sh: fixed skipping of duplicate partitions (e.g.
vbmeta) for some shells; fixed upgrade-flashing of Galaxy A32 (default
behavior).
Spoiler: Known issues
During the script run you can see several "Invalid sparse file format at header
magic" warnings, just ignore them.
For some firmware files Heimdall may not work at all (freeze indefinitely or
exit with an error), in that case you have to resort to Odin. In many cases
Heimdall freezes when uploading files for some time, but that does not mean it
is completely frozen, just be patient.
In LineageOS, Dot OS and some other GSIs I tried on SM-127F the touch screen
remains not responsive for about 6 seconds after waking up. The problem is not
present at least with SM-127F/DSN phones made in India, but present at least in
those made in Vietnam. Another problem in the most, if not all, GSIs is that the
MTP USB file transfer does not work (at least on Linux) because of the "wrong"
(Samsung's instead of Google's) default MPT driver used by the kernel.
Both of the aforementioned problems can be solved by installing the fixed and
recompiled kernel.
For the last problem alternative solutions include using apps such as
Warpinator, Syncthing or ftpd.
Spoiler: Food for thought
When choosing a GSI to install I really don't recommend using ones which include
GApps and therefore use any of the Google services. Don't let corporations
gather your data. You bought the phone and from now on it should be all yours,
with all of its data, like a PC in the good old days. You own your device, and
nobody has the right to stick their nose into how you use your phone, gather any
statistics and push you any ads. You always have a choice to turn down
privacy-unfriendly stuff, the price of that "inconvenience" is actually
ridiculous. From my point of view, there is simply no point in using non-stock
systems if they are still littered with the privacy-unfriendly bloatware.
For the step-by-step guide (slightly outdated) read this and this post. Also be sure to read this post concerning the importance of optics.img. Concerning the up_param_tool.sh be sure to read this post.
The included binaries for the lpunpack, lpmake and Heimdall were compiled for the x86_64 architecture. If your PC architecture is different (e.g. x86 32-bit or ARM) you have to compile these tools yourself. The full source code is included (or otherwise available on GitHub).
Latest stable combinations of stock firmware and LineageOS (updated February 5, 2023):
SM-A127F: A127FXXU7BVI4 + LineageOS 20.0-td 20230115 arm64 bvS
SM-A325F: A325FXXU2CVK3+ LineageOS 20.0-td 20230115 arm64 bvS
Some recommendations (updated February 5, 2023):
If you are a newbie and don't know how to do unlock the bootloader and other such stuff, here is a good guide by LAST_krypton (follow the "Unlocking the booloader" section) or a shorter guide by cldkrs.
First flash the phone with the whole set of stock firmware using the heimdall_flash_stock.sh (Linux only) script with the -d parameter: the latter forces flashing the unsafe partitions, which are needed for complete re-flashing.
If you're on Windows use Odin instead. Although there is a "leaked" Linux version of Odin, it's still closed-source (of course), so I don't recommend using it on your main Linux PC. For using the Windows version of Odin on Linux you have to either use Windows in QEMU (tested and works) or probably Wine (untested). When using QEMU remember to add the SUBSYSTEM=="usb", ATTRS{idVendor}=="04e8", ATTRS{idProduct}=="685d", MODE:="0666" line to the udev rules (e.g. /etc/udev/rules.d/30-qemu.rules) to enable the write access to the phone.
Sometimes Heimdall cannot flash the stock firmware and gets stuck at some particular file. Although you can successfully flash such a firmware using Odin, I recommend to better to find another firmware, may be one release older, because that may indicate some sort of incompatibility with your particular version of the phone.
The stock firmware comes in different revision numbers (also known as the baseband version), which are upgraded about once a year. Generally it should be beneficial to use the latest revision, but note that once you have upgraded it to a later revision there is no way back (at least known to me). In case you want to experiment with flashing of special kernels and other flavors provided by the XDA developers, if possible, you should probably stick to the very first revision.
If you already have the bootloader unlocked (OEM unlock) then after flashing the stock firmware there is no need to set up the Android, just go straight into the download mode again and flash the repacked super.img.
When downloading LineageOS or any other GSI select the normal arm64 bvS version, not vndklite version.
After flashing the OS go into the Recovery mode (hold volume up and power when rebooting) straight away and do the Factory reset. If you cannot get into the Recovery mode be sure to connect the USB cable before trying to.
If flashing with Heimdall completely freezes at some point make sure you've downloaded and repacked the correct arm64 b or a/b GSI and not arm and not a or a-only variant. If "sw rev check fail" message appears on the screen at some point just ignore it.
You can forcefully reboot your phone at any time, even if it seems bricked, by holding the volume down and power buttons for several seconds.
To upgrade your system to the recent version of the same OS just repackage it again using the same script and flash it normally. If the phone does not boot, get into the Recovery mode and try wiping the Cache partition (all your apps and settings should remain intact).
Most probably you don't need TWRP or any other 3rd party recovery tool at all, as the stock recovery tool works fine for just the factory reset after flashing the super file.
Try to avoid using Magisk if you just want to install another OS and nothing else. It is also not needed for LineageOS bvS version as it already has the su utility integrated, you just need to install the additional Superuser app by Pierre-Hugues HUSSON from the F-Droid store (although it's very old it works just fine).
It's possible that SM-127F/DSN internally is not A12 but actually M12, at least most of the tools and kernels made for M12 work on SM-127F/DSN while those made specifically for SM-125 and even other SM-127 versions do not. Therefore you can find more relevant info and tools in the corresponding XDA thread (my script is still remains relevant though).
I should test this for a127f
Bugs fixed: v0.91 & v0.91a
Bug fixed: v0.91b
Added the "file" utility to the list of requirements, updated readme.txt.
Thanks A LOT, this works! I am finally able to run LineageOS on my phone!
For Windows 10+ users: WSL runs this script just fine with a few additional steps.
1. Install WSL 2 and any Linux distribution from Microsoft Store
2. Run the distribution to finish setup
3. Install the required packages from the post (sudo apt install for Ubuntu/Debian)
4. Shift + Right Click in the folder where you have the script, the AP and the GSI packages
5. Open Linux shell there
6. Unpack & run script as stated in its help
Voila!
Wow ! Great job! I want to try it, but i'm getting many "Invalid sparse file format at header magic" while running the script, is it OK to flah the super.tar anyway?
jadfa said:
Wow ! Great job! I want to try it, but i'm getting many "Invalid sparse file format at header magic" while running the script, is it OK to flah the super.tar anyway?
Click to expand...
Click to collapse
It is totally OK
jadfa said:
Wow ! Great job! I want to try it, but i'm getting many "Invalid sparse file format at header magic" while running the script, is it OK to flah the super.tar anyway?
Click to expand...
Click to collapse
Yes, it is fine. These are just warnings produced by lpmake, they can not be suppressed. I could only suppress all the stdout/stderr from lpmake but it's no good in case of more serious warnings.
Updated to v0.92 with a couple of minor improvements.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
What should I do next with the raw file?
"Unknown super file format" is this how it should be?
ANDARXapi said:
View attachment 5490897What should I do next with the raw file?
"Unknown super file format" is this how it should be?
Click to expand...
Click to collapse
Of course not. The format of each file is checked using the "file" utility, it should return the string "Android super image". Try to run file /home/toor/APfilles/super.stock.raw . What is the response? And try doing it all without sudo. There is no need in root privileges.
uluruman said:
Of course not. The format of each file is checked using the "file" utility, it should return the string "Android super image". Try to run file /home/toor/APfilles/super.stock.raw . What is the response? And try doing it all without sudo. There is no need in root privileges.
Click to expand...
Click to collapse
The raw file opens as a picture
uluruman said:
Of course not. The format of each file is checked using the "file" utility, it should return the string "Android super image". Try to run file /home/toor/APfilles/super.stock.raw . What is the response? And try doing it all without sudo. There is no need in root privileges.
Click to expand...
Click to collapse
run without sudo: 168: ./lpunpack_and_lpmake/lpunpack: Permission denied Cannot correctly unpack the super file. Exiting ...
I managed to fix the script, you just need to give chmod +x rights to the files in the folder "lpunpack_and_lpmake": lpunpack, lpmake, lpflash, lpdump, lpadd
ANDARXapi said:
I managed to fix the script, you just need to give chmod +x rights to the files in the folder "lpunpack_and_lpmake": lpunpack, lpmake, lpflash, lpdump, lpadd
Click to expand...
Click to collapse
Hmmm. I have updated it, may be it'll help. Could you please test the latest version (v0.92a)? I want to work it out of the box for everyone, without sudo or any tweaks.
uluruman said:
Hmmm. I have updated it, may be it'll help. Could you please test the latest version (v0.92a)? I want to work it out of the box for everyone, without sudo or any tweaks.
Click to expand...
Click to collapse
Okay, I'll test it tomorrow, today I want to relax at the computer all day
uluruman said:
Hmmm. I have updated it, may be it'll help. Could you please test the latest version (v0.92a)? I want to work it out of the box for everyone, without sudo or any tweaks.
Click to expand...
Click to collapse
Checked, it works right away
Is there a way to install magisk and root?
I try to share my experience about this cheap phone (bought I think for 45€ : was the cheapest of the hypermarket, around 2019).
Here are some specs : https://www.gsmarena.com/wiko_sunny3-9733.php
First of all, this is a SPD (Spreadtrum) based device, not MTK (Mediatek). (Surely, it would have been easier on an MTK Wiko like the Jerry...)
My goal was to get root access and finally try to install a big-tech free system alternative.
I confess, I spent about one month on it. Here are my findings and the final result I could achieve.
Long story short : I could not get root (I'll explain it below). But I could "un-google" it as much as it is possible without breaking anything essential.
Here is the story and it's lessons learned, in a hopefully logical order.
1. Tried all (really all!) available "out of the box" rooting apps without any result.
2. However there is an "allow unlock bootloader" switch in the "developper settings" (once taped a couple of times on the "build" of the system menu...)
there was no way to really "unlock" it using any appliable fastboot command (tried really everything).
3. Magisk (latest or any other) could not patch the boot.img (or recovery.img).
As root access means the ability to get at some point a writable filesystem, and as this is mounted by boot/recovery.img, this is the key process here.
4. So I went to linux to modify them : tried again all dedicated tools to unpack, edit and repack the boot and recovery.img.
mkbootimg/unpacbootimg, abootimg, but it turns out, they don't repack the files in an acceptable way for this system.
Independently from change made or not (in some .rc file inside the ramdisk, initrd), those usual dedicated tools just cannot repack the file correctly, at least for this device.
Lastly, when I tried bootimg.exe (for windows) of "cofface" (https://github.com/cofface/android_bootimg/blob/master/bootimg.exe)
I could find out that it extracted an other file that abootimg and others was not even aware of : dt_image (binary having an SPRD header).
And this (avesome) tool is able to repack it with it.
But now, the new boot.img was 12Mo and not 36Mo as before. Turns out there is a huge empty (00 bytes) overlay, and a vbmeta (AVB) signature, somewhere at a precise place and at the end of the file.
So I completed and patched the file by a hex editor, to make it the same as the original one. (There were also some 2 "minor" diffs at the beginning of the file that I tried every combination with to make the device boot with it. No way.
I believe now, fdl2-sign.bin, one of the two mandatory required files to flash anything on the device (that gets allways flashed first), checks the signature of boot.img (and recovery.img), so a modification of these would need a brand new signature. (Tell me if I'm wrong: I'm not a pro) And I gave up at this point.
5. Before (understanding the above), I tried also by just changing system/vendor to make root tools available :
Mounted on Linux : strangely, when the filesystem was rebuilt by "make_ext4fs" the flashing crashed, but just unmounting it and then "img2simg" to get the android "spars" format, worked fine (despite for ex. the record of the mountpoint inside the file).
I tried to add all the necessary files (su, busybox, etc.) to "system "and "vendor"... retoutching everythig back to original time stamps, etc.etc.
but the loaded system denies access to all "new" files (and also to some others). Then I tried to change some "policies" files in /etc/selinux (like plat_sepolicy.cil), only trying to get how it works (I added some lines about my files taking as example a well authorized binary)... if ever the added binaries could be accessed even on a -ro filesystem. But nothing changed.
All file added or modified, such as a new bootanimation.zip, becomes "access denied" as well, despite adding them to policies files.
Same for some "new" sounds to media folder : they will be listed but not played (so you only get silenced wake-up instead .
6. After that I decided to un "big-tech"(BT) everything and replace as much (BT tracked) functions as possible by "clean" FOSS apps from F-Droid.
And this, at my surprise, I could get it through 100% (I believe).
The idea in short :
1 - make a clean firmware flush (perhaps with already reduced preinstalled apps)
2 - uninstall/deactivate on the device anything you want and can, replace needed default apps (by FOSS equivalent), especially the launcher(wiko app starter).
3 - edit system and vendor (on linux), delete unwanted apps (making according changes on some .xml control files doesn't change anything and only might cause problems: just deleting the packages seems enough here)
4 - then reflash only the modified system and vendor (reboot and see)
Now, for those who (I would like to say "hate" BT enough to accept loosing the shiny comfort they offer, but lets say) want to get rid of preinstalled privacy breaking BT apps, here is the howto : (with explanation for also the novice)
a) First, download the latest firmware update :
Wiko Mobile : Customer Area / Connection.
customer-world.wikomobile.com
b) Launch the app and push the start flushing button (play button). This will unpack the boundled .pac file into a temporary directory (into the app folder's "ImageFiles\_DownloadFilesE10_2C10D_0" : the suffix changes at each startup. Save this folder to somewhere else (because quiting the app will erase it).
c) Now you need to launch a linux OS, (that can of course access the saved rom files) mainly to mount and modify system.img and vendor.img.
I will detail this for the novice.
Basically, open any teminal, then install if its not yet done, the following needed tools :
sudo apt-get install e2fsprogs
sudo apt-get install android-tools-fsutils
to use Midnight Commander which will save you a lot of time, make also a
sudo apt-get install mc
Then "sudo mc".
Once in MC, do Ctrl+o to switch (back and forth) to command line
d) Uncompress the system+vendor image files, mount, modify, then umount and recompress them :
Uncompress by : "simg2img vendor.img vendor-whatever.img" (same with system.img)
Then (create some "sys", "ven" folders) and : "mount system-whateweryoucalledit.img sys -rw" (thats all, same for vendor).
It turns out, you can just easyly erase some apps (but not anything!) and they just won't be installed, or will "disappear" if they were...
You can delete already from system: in "app" and "priv-app" folders any Facebook related app or service, plus Youtube, Chrome, Gmail... Duo, Messages, TTS, Calendar, Maps. From vendor: Photos, Music, Contact (and also Chrome vendor overlays). Normally you could only deactivate them from the device, but that way they won't be present at all.
You can also edit /etc/prop.default, as follows, but honestly, I did not recognized anything really working, except the sys.usb config and mock.location (allowing fake gps position app).
ro.secure=0 ---> these 2 doesn't seem to do anything without a patched boot.img
security.perf_harden=0
ro.adb.secure=1 ---> needed, otherwise you won't get adb access dialog
ro.allow.mock.location=1 ---> allows fake gps app
ro.debuggable=0 ---> if 1: will just crash "developper settings" because of its defaults
persist.sys.usb.config=none ---> you will be free to set it
Do not try to "ro.adb.secure=0" because you just won't get confirmation box for trusted adb connection attempts and they just won't work!
Same, don't be tempted by "ro.debuggable=1" bacause you will not even be able to access "developper options" any more as its defaults will conflict with this setting an it will just crash over and over. I did it, I payed the price to start it over again...
Now, it seems, ro.secure=0 and security.perf_harden=0 does just nothing as well, without being able to modify boot.img first.
Changing eventually "ro.build.type=user" (in system/build.prop or anywhere else) to "eng" or to "userdebug" makes just the flashing operation to crash. (same by patching boot/recovery.img in hex mode (which looked attractive at first sight) but led to flush crash as well, mainly for the vbmeta thing I tried to describe above.
When finished, just "umount sys" and "umount ven"
Then recompress the files by "img2simg vendor-whatever.img vendor.img" (same with system).
(This first amputation and further, could be done perhaps later all at once, but thats how I did. Of course its about to avoid first installations but without breaking the setup process.)
e) Flash the new firmware to the device, replacing system and vendor.img by the modified files :
The modified files shouldn't be bigger than the original ones, at least not bigger than their size stated (in Mb) in the k120.xml (system:1400,vendor:300) but there is no reason anyway as after my experience all added files will become "access denied". (Should they become bigger than that you will have to change these values in k120.xml and re-pac them (using spd research tool, that will update k120.xml) before using them again, otherwise the flashing will fail.)
So now, get ready for the flashing:
Un mount the back cover of your Wiko Sunny 3, remove for a few seconds the battery, then replace it.
Now, here is something I had to figure out myself because there isn't anywhere a clear description of it, and this is foundamental to be able to flash :
First thing to do is to launch your flashing software, choose the pac file if necessary and push the action button to get ready for the device's connection.
You can wait some time, while the app unpacks the included .pac file. (spd factory/research tools lets you choose your pac file, the one downloaded refers to it only through its .ini file).
So pushing the "start flashing" still nothing happens, the flashing app (unpacks the pac file and) just waits for the devive to connect... This can last forever, don't worry.
Now, to be able to connect de device in service/flashing mode, it should NOT go into charging mode when you connect it.
Thats why, you have to connect the (computer) USB slot by pressing continuosly volume up on the device (after havig removed and reinserted the battery) AND wait until the app detects it and starts the transfer. Do not release the volume-up until it gets at least 3-4%. (Many guides speak about 3 sec or so, the only thing accurate is that the app starts effectively the transfer.) If you release it too quick, the phone goes into charging mode and the COM port used to flash closes, and you will need to repeat the operation.
(And of course you need all required drivers loaded previously. The driver for flashing is called SPRD or SPD Driver R4.20.4201: seems the latest)
If successful, the device gets rebooted.
---------
Here I'd like to ask some pros of XDA : what signal boots the device after flashing? Can it be reproduced without flashing? In other words, can we start/boot an extincted device by USB signal? If yes, how ?
---------
As the first-time setup launches, just decline/skip ewerything, most of all the final wiko/vendor offer (this keeps you safe from vendor commercial services). Just get to the home screen.
See what you have got.
f) Now, setup your anti big-tech privacy free environment. For example, deactivate google play including its service. (Yes, "big-tech haters" don't rely on this ;-)
To know where are the spies, I installed TrackerControl (version 2022.02.10 from F-droid) which gives enough info on that even without root. You will be surprised. There are "feedbacks" to google, to the vendor, and also to Microsoft, even without launching anything, just the wifi on. Even the caller app has trackers...
The best thing is that this (GPL) app lets you know what package causes the leak. You can just write them down, for later deletion.
It turns out, I could delete all of them (mainly from system.img, monted again on Linux) without that anything breaks.
I replaced the caller/dialer, calender, contact, everything, by new default apps. Replaced the Wiko launcher by the Fairphone launcher (from F-Droid).
I installed ungoogled chromium from https://github.com/wchen342/ungoogled-chromium-android/releases (chrome public). (Strangely could not install other browsers!). I replaced Google TTS by "eSpeak NG" (the final config is a little bit tough : have to download "espeak-ng-data" (voices) and push it to the "sdcard" then, slowly, it finds it and it works. (Well, ok, its not the fine google tts thats far the best actually, but its still a tts...) And yes, there is still the keyboard to tap keywords to look for. ;-)
g) When done, take and mount again the system.img file (you flashed) and take out what (following the list of tracker apps found by "TrackerControl", which are mainly (for me) : (for howto, see d) above)
/system/priv-app/phonesky // playstore : com.android.vending
/system/priv-app/GoogleDialerGo // contains trackers!
/system/priv-app/GmsCore // googleplayservices (yes it works without it)
/system/priv-app/WIKOSetupWizard
/system/priv-app/WIKOLauncher // easyly replaced (by Fairphone's 1/2/3)
/system/priv-app/WIKOInstaller
/system/priv-app/AppCloud // wiko appstarter (77 trackers)
/system/priv-app/SearchSpeachService // (google) tracker by definition
/system/priv-app/AntitheftPlugin
can be removed as well (and still some others, but its more wise to stop here, till it still works ;-)
NB : The 3 "Vital-app", probably commercial boudles, must be really present but they can be uninstalled cleanly (weather, smart-assistance, gaming).
Finally, enjoy your non-rooted, but privacy tuned Wiko Sunny 3, and install clean FOSS apps from F-Droid (or from elswhere).
One more thing: Its not because an app is "free and open source" that it won't track you : choose your apps carefully, observing all permissions they ask for.
For example, there isn't much acceptable explanation for a calculator to claim "full network access" or a game to be "launched at startup" or get "system configuration" rights.
And sadly, as we still do not have root access on this device, there isn't much control available on apps, permissions, network or system. But it is possible now to free it from big-tech trackers, as much as possible.
Of course, as usually in these cases, I cannot guarantie anything. It just worked for me like that (reproduced several times), and I think there is no reason that for anybody else it would produce a differet outcome.
Your comments are allways welcome.
This is the Android 10 recovery image by HCT (version 10.3.1) patched to skip signature checking on .zip files
Tested on MTCE_LM (Eunavi). Use at your own risk
It can be flashed from a root shell (either adb or via terminal emulator) by performing the following steps
1. upload recovery via adb
Code:
adb push hct_recovery_patched.img /sdcard/
2. flash recovery
Code:
# backup current recovery
dd if=/dev/block/by-name/recovery of=/sdcard/recovery_backup.img
# write new recovery
dd if=/sdcard/hct_recovery_patched.img of=/dev/block/by-name/recovery
NOTE: If you do not disable the "flash_recovery" service in /init.rc, AND you have a stock kernel, recovery will be restored to the original version after rebooting.
There are 3 ways to avoid this:
- Flash magisk (or a modified kernel) while in recovery. The patch will then fail to apply and recovery won't be overwritten
- Disable "flash_recovery" by doing "adb remount" and editing /init.rc (comment out the following)
Code:
service flash_recovery /system/bin/install-recovery.sh
class main
oneshot
- Neuter the service by either:
- removing /system/bin/install-recovery.sh- replacing /system/bin/install-recovery.sh with a dummy script- removing /system/recovery-from-boot.p
Woo-hoo, after hundreds of rubbish posts in the MTCD forums, we have a real development post!
Great work and thanks for sharing this, these forums need more like you.
Thanks for the kind comment!
I have to admit that it was frustrating to see the lack of information sharing on this forum, and the pervasive pay-per-use model.
I spent a lot of time just getting Android 10 installed (starting from Android 9), and i had to bring the head unit to my desk as working in the car was rather hard and all i achieved was a brick.
I unfortunately had to bring it back in the car now (can't sit on my desk forever) but, now that i figured out how to make bootable recoveries, i was wondering how hard it could be to have TWRP or at least a hassle-free recovery to install Android 10 from Android 9.
As a first step, this recovery makes it possible to install Magisk or other zip files without doing it manually within adb.
Cheers!
Your work is really good!
Thanks a lot for it.
Now you can also modify ROM's without signatur errors when installing.
Wouldn't it be good if we had an app like the ModInstaller ?
So a one click installation of the recovery without shell or adb.
I have now built an app.
And now need help.
Namely, in the app is the recovery and the script.
Unfortunately, the flash process is not started.
It always comes only the first message from the script.
The app is open source and the script and the recovery are in res/raw.
In the attach you will find the finished app and pictures.
If someone has a solution, he can write me or make a pull request on Github.
Source code:
GitHub - jamal2362/RK33XX-Custom-Recovery-Installer: Application for flashing custom recovery on Rockchip Android Head-Units.
Application for flashing custom recovery on Rockchip Android Head-Units. - GitHub - jamal2362/RK33XX-Custom-Recovery-Installer: Application for flashing custom recovery on Rockchip Android Head-Units.
github.com
The script:
RK33XX-Custom-Recovery-Installer/script at master · jamal2362/RK33XX-Custom-Recovery-Installer
Application for flashing custom recovery on Rockchip Android Head-Units. - RK33XX-Custom-Recovery-Installer/script at master · jamal2362/RK33XX-Custom-Recovery-Installer
github.com
First of all, congrats for the work!
DISCLAIMER:
I don't own ModInstaller, i have never bought a copy of it and i don't intend to do so.
Analysis is purely done from Youtube videos, open source code analysis and existing and openly available binary images.
I was working to figure out how to make a FLOSS alternative to ModInstaller.
The issues i found in all my attempts are the following:
- A6 recovery is the only one that can boot from SD Card (which can then be used to flash A9 -> A10 with the 2SD trick)
- (it took me a long time to pull these information together and unbrick my unit)- The A6 recovery is unable to directly flash A10 RKAF/RKFW images (sdupdate.img) due to the code being too old
- a failure will be observed while writing super.img. This happens because the device needs to be repartitioned, and the A6 recovery is not doing it correctly- A9 recovery is buggy. Booting it with no system installed will result in a black screen.
- it will only boot succesfully after being written by the A6 flash tool, which writes the "misc" partition with the recovery commands to run (the "hint" i get from this is that the misc partition is important)- A10 recovery can't be loaded by the A6 recovery. I always got a black screen after flash. Is it a flash issue? is it an issue with the recovery itself? hard to know
Theory: maybe the recovery could be written over the kernel partition? ("boot")
This way, the recovery will always run after being flashed instead of requiring an explicit "enter recovery" trigger (buttons, misc partition, etc.)
Besides these experiments, in parallel, i did some bug fixing to this repository: https://github.com/liftoff-sr/rockchip-tool/commits/master (i'm "smx-smx")
That allows me to unpack nad repack "sdupdate.img" , "reduced recovery images" and "full IMG files".
With those tools. i tried to swap "recovery.img" in the A6 image, but i always got the black screen upon booting from SD.
Either A9/A10 breaks sdboot or the bootloader crashes before it gets there.
Since this also happens when being flashed, this could either be a bug in the flashing program or a bug in the boot stack (which fails to run recovery perhaps due to a dirty state of the internal flash). It's hard to know for sure without having a UART connection with the board.
BUT, we have an alternative, in the form of the recovery built-in ISP flash tool.
This is the code that reads "sdupdate.img" from the SD Card and flashes it
After reading the recovery source code, i realised that this code can only be triggered correctly when booting from the SD card.
It detects this state by reading /proc/cmdline and probing for specific values (https://github.com/rockchip-android...6f72b7d3123dab27135ac41d55029/sdboot.cpp#L206)
This means the bootloader can (and will) pass those arguments under specific conditions (https://github.com/rockchip-linux/u...c873f178c/arch/arm/mach-rockchip/board.c#L358)
If you check here https://github.com/rockchip-linux/u...3f178c/arch/arm/mach-rockchip/boot_mode.c#L47 you can see the magic word that needs to be written to the "misc" partition in order to trigger that code.
Note that, besides the well known "sdboot", "usbboot" is also possible.
I'm not sure if the ROM can physically boot from USB, but the bootloader and recovery do support (according to code) passing the flag to enable flashing from USB.
So, recapping, there are these ways we can try:
a - try to overwrite "boot" with "recovery" (but it might not work due to the partitioning layout, e.g. jumping from A6 -> A10)
- note: uboot might also need to be written when doing this.
b - making a modified "sdupdate.img" that flashes recovery on top of boot, and all the other core partitions like "misc", "uboot", "trust", "vbmeta"
c - writing "misc" from android in order to triggers the "rkfwupdate" mode
d - taking a dump of the first portion of the flash in various states (A6, A8, A9, A10), and having a "dd" that writes it back to the beginning of the flash (i suspect this is how ModInstaller does it)
Considering cases "b" and "c" depend on a recovery that can write them correctly (and the A6 one is buggy), this leaves us with "a" and "d"
Considering that ModInstaller does it in one shot, and doesn't seem to matter about the partitioning layout, i believe "d" might be the most viable option...
Using the "rockchip-tool" repository i linked from github, the partition table can be dumped from any .img file
You can observe "Image/parameter.txt" from the extracted firmware
This is the partition table from A6's recovery:
[email protected](uboot)
[email protected](trust)
[email protected](misc)
[email protected](resource)
[email protected](kernel)
[email protected](dtb)
[email protected](dtbo)
[email protected](vbmeta)
[email protected](boot)
[email protected](recovery)
[email protected](backup)
[email protected](security)
[email protected](cache)
[email protected](system)
[email protected](metadata)
[email protected](vendor)
[email protected](oem)
[email protected](frp)
[email protected](userdata)
And this is the partition table from A9's recovery
[email protected](uboot)
[email protected](trust)
[email protected](misc)
[email protected](resource)
[email protected](kernel)
[email protected](dtb)
[email protected](dtbo)
[email protected](vbmeta)
[email protected](boot)
[email protected](recovery)
[email protected](backup)
[email protected](security)
[email protected](cache)
[email protected](system)
[email protected](metadata)
[email protected](vendor)
[email protected](oem)
[email protected](frp)
[email protected](userdata)
Notice how uboot, trust, misc, resource, kernel, dtb, and others live in the same space. (2000, 4000, 6000, 8000, 10000, ...)
What we could do is create a raw blob that spans that address range, and "dd" it directly to /dev/mmcblk0 at the right offset.
So i would focus on converting recovery images to raw blobs, with recovery-as-kernel so it boots straight away on the first try.
Bump a real thread.
Is it possible to convert it to a file installed by SDDiskTool?
marchnz said:
Bump a real thread.
Click to expand...
Click to collapse
I created a flashing tool to flash recovery within Android, using Rockchip's own code: https://forum.xda-developers.com/t/...chip-firmware-flash-tool-for-android.4458299/
blala said:
I created a flashing tool to flash recovery within Android, using Rockchip's own code: https://forum.xda-developers.com/t/...chip-firmware-flash-tool-for-android.4458299/
Click to expand...
Click to collapse
This file hct_recovery.patched.img does not appear to be installed via rkupdate
sadaghiani said:
Is it possible to convert it to a file installed by SDDiskTool?
Click to expand...
Click to collapse
It needs to be converted, yes
I'll take a look this afternoon
blala said:
It needs to be converted, yes
I'll take a look this afternoon
Click to expand...
Click to collapse
Is it possible to create a boot image that includes moded recovery & magisk and moded kernel ?
If by image you mean firmware image then yes, it can be done with https://github.com/liftoff-sr/rockchip-tool
But what i would recommend is the modded recovery only, with the magisk .zip to use in Recovery
Otherwise you risk flashing a kernel that doesn't match with kernel modules or is otherwise not fully compatible with the installed system
blala said:
If by image you mean firmware image then yes, it can be done with https://github.com/liftoff-sr/rockchip-tool
But what i would recommend is the modded recovery only, with the magisk .zip to use in Recovery
Otherwise you risk flashing a kernel that doesn't match with kernel modules or is otherwise not fully compatible with the installed system
Click to expand...
Click to collapse
boot.img file included recovery+magisk+kernel
Flashing a boot.img (Kernel, for example) in an Android mobile phone via adb shell
Flashing a boot.img (Kernel, for example) in an Android mobile phone via adb shell - script.sh
gist.github.com
MTCD has separate boot and recovery partitions.
Perhaps you can adapt both recovery/kernel to be in the same image but the bootloader won't know about that (and will always boot from "recovery" partition)