Related
hello there,
this tool is windows based. You need the .net 4.5 framework. There is no installer. Simply extract the executable onto your computer.
@xQrzy shared some insight about the flashfile.xml. So i made this tool for reading an image archive and creating proper flash statements. Its very rudimentary but its working.
So, whats to do? Use an image file (zip) or unzip it first. Then execute the program and select the image or the folder. And thats it. There is one tab with some information and on the second tab there is a list of flash operations this image provides. Under options you'll find one checkbox. Uncheck it will generate the full file paths for your image files. The third tab is for the output executing a real flash would return on the command line.
Choose your operations wisely, because eg. erase user data will make a factory reset.
version info
Code:
current version: 0.9.3
- (untested) added experimental flashing. There will be a warning before the actual flashing.
- little rework of the gui.
features:
Code:
- checking MD5 hashes of all files
- (untested) selectable flash commands and running them (thats why i called it installer)
for interested devs:
- its a sharpdevelop project (built with sharpdevelop 5.1 rc1). This project was hacked whithin 5 hours so its not that filled with comments and stuff. Its not on git because of this. You can of course download my sourcecode and compile your own binary if you don't trust me. Which would be clever and cautious.
I'm really happy to be the spark of this idea. ^^
And hope you will make the tool better and better.
aVe2000 said:
hello there,
this tool is windows based. You need the .net 4.5 framework. There is no installer. Simply extract the executable onto your computer.
@xQrzy shared some insight about the flashfile.xml. So i made this tool for reading an image archive and creating proper flash statements. Its very rudimentary but its working. I made this tool capable of executing the generated flash statements but i deactivated this because of the potential problems beeing caused by using this feature. Maybe i will continue on this in future.
So, whats to do? Use an image file (zip) or unzip first. Then execute the program and select the image or the folder. And thats it. There is one tab with some information and on the second tab there is a list of flash operations this image provides. Under options you'll find one checkbox. Uncheck it will generate the full file paths for your image files. The third tab is for the output a real flash would provide in the command line.
Choose wisely your operations, because eg. erase user data will make a factory reset.
Additional features:
- checking MD5 hashes of all files
current version: 0.9.2
Click to expand...
Click to collapse
so it will generate a txt file with the statements to type, it doesn't flash anything by itself, right?
bilbo75 said:
so it will generate a txt file with the statements to type, it doesn't flash anything by itself, right?
Click to expand...
Click to collapse
with version 0.9.3 it tries to flash.
Version 0.9.3 added.
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
Zip Builder is a stand-alone Windows exe (ZipBuild.exe) that can be used to build and sign Android zip-based installers from Windows folders. All required components to build and sign a zip installer are included - no additional files or software are required. The only requirement is that you have a current version of Java installed on your system. Zip Builder can be used on both shell-script and edify-script based installers and performs the proper build and signing methods, accordingly.
Although it's highly recommended to install the software using the Windows Installer (see below), the stand-alone exe is all that's required to use the program. The program command line options are as follows:
ZipBuild.exe <option1> <option2...> <*Folder Name>
Valid options are as follows:
'm' or '-manual': Manually select folder to be processed
's' or '-signed': Append '-signed' to the output file name
'5' or '-md5': Generate corresponding MD5 checksum file
'c' or '-confirm': Confirm options before building
'g' or '-gitinclude': include .git folders and related files
* Ignored when using manual selection mode
OPTIONS EXPLAINED
'm' or '-manual': In Manual mode you will be presented with a dialog box where you can manually select the folder containing the files to be processed. *When using Manual mode, the folder name will be ignored if it was provided in the command line
's' or '-signed': This option will append '-signed' to the output file name. For example: Folder name 'UPDATE-adb.Installer.v1.0.36' would produce a signed zip file named 'UPDATE-adb.Installer.v1.0.36-signed.zip'.
'5' or '-md5': This option will create a separate, corresponding MD5 checksum file that can be used to verify file integrity in TWRP or with other Windows checksum utilities.
'c' or '-confirm': When this option is used, you will be presented with a dialog box where you can confirm (or change) the 2 options above. If either (or both) options above have been specified on the command line, the checkboxes will be pre-selected accordingly. Once you're satisfied with your selections, click the 'Build Zip File' button to begin the zip building and signing process.
'g' or '-gitinclude': This option will include any .git folders and related files (.git, .gitignore, and .gitattributes) that are excluded from the zip file by default. [Should rarely be needed, if ever]
ZIP BUILDER SETTINGS MANAGER
Zip Builder Settings Manager (ZipBuildSettings.exe) is an optional companion app that can be used to manage the settings and options (shown below) for Zip Builder:
You can choose to create Windows Context (Right-Click) menus that will allow you to build a signed zip installer simply by right-clicking on a folder name. Folder names that end in '20YYMMDD' or '20YYxxxx' as well as folder names that begin with 'UPDATE' are supported in Windows 7 and above. You can also enable the option to build from any folder by holding the SHIFT key while selecting the folder.
You can choose when to display the confirmation dialog
You can choose when to append '-signed' to output file names
You can choose when to create md5 checksum files
You can choose to include all .git folders and related files (see above)
DATE CODE FEATURE
If you're building from a Windows folder name that ends in '20YYMMDD' or '20YYxxxx', Zip Builder will give you the option to change or update the date code portion of the file name before building the zip (it will also suggest the current date's date code - YYYYMMDD). And, if you're building a zip installer that includes a g.prop file (found in many GApps packages), the installer will read the date code from the 'ro.addon.*_version=' property and automatically use it in place of the date code from the Windows folder name.
WINDOWS INSTALLER
As mentioned above, you'll have the best user experience if you install Zip Builder using the Windows installer. It runs in standard user mode (no Admin access required or requested) and installs the Zip Builder and Zip Builder Settings exe's in: 'C:Users<user>AppDataRoamingZip Builder'. The installer will create a program group and shortcuts in the Windows start menu (and optionally on the desktop) that can be used to launch Zip Builder in 'manual selection mode', where the user can manually select the folder they wish to build. The installer will automatically run Zip Builder Settings Manager at the conclusion of the install where you can configure the settings and options to your personal preference.
Uninstalling Zip Builder from the Windows Uninstall menu will remove all traces of the software from your system. And, since Zip Builder, Zip Builder Settings Manager, or its installer will NEVER prompt for UAC access, you can be confident that it's not touching the Windows operating system. Of course, all source code is available if you want to check for yourself - you can even build it for yourself, if you want!
TECHNICAL NOTES
Version 4.3+ of Zip Builder includes the new ZipSigner 2.1 Java executable that was rewritten from the ground up by @topjohnwu for use in his Magisk root management software. This change will allow you to build the largest zip installer on even the smallest 32-bit machine. I was able to build a 1.0+GB shell-script based installed on a 32-bit Windows XP machine with only 1GB of RAM.
If you have had java heap size issues building zip installers in the past, version 4.3+ of Zip Builder should completely eliminate these problems.
XDA:DevDB Information
Zip Builder, Tool/Utility for all devices (see above for details)
Contributors
TKruzze
Version Information
Status: Stable
Current Stable Version: 4.5.2
Stable Release Date: 2020-09-06
Created 2018-01-23
Last Updated 2020-09-06
Anti-Virus False-Positives
ANTI-VIRUS FALSE-POSITIVES
There have been reports of false-positive flaggings of Zip Builder and/or the Windows installer. While I can, personally, assure you that there's no malware included in Zip Builder or its installer, I also understand that there may be some concern with using software that's been flagged on your machine.
To allay your concerns as best as possible, I have included 100% of the original source code for you to inspect and/or build the software yourself. Again, there is no possibility of malware as I do all of my compiling on a clean machine that is not connected to the internet. I have also submitted all 4 Windows executables to the major AV inspection service on the net. Below are the results of these inspections:
VirusTotal.com
ZipBuild.exe (32 bit) 7/68
ZipBuild.exe (64 bit) 2/68
ZipBuildSettings.exe 4/67
Zip Builder_4.5.2_Setup.exe 1/69
Sources & Acknowledgements / Recent Changes
SOURCES AND ACKNOWLEDGEMENTS
Zip Builder has existed for me since way back in 2013 when I started developing GApps packages. I've added features here and there and finally decided to share it. After privately sharing with @osm0sis, I received a lot of very constructive feedback and based on this, I polished the interface and added some new features. A big thank you to @osm0sis for this feedback. Without his input, it would look a lot clunkier than it does today.
All source code is provided, however, it's only appropriate for me to publicly acknowledge that this work includes code and binaries from several third party sources. Below is a complete list of these sources. You will also find this list as well as the actual code and binaries in the Source Code Zip file available for download.
Zip Builder
------------
Zip Builder is Copyright (c) 2013-2020 by @TKruzze
Original source code and compiled executables can be found on
XDA Developers. Zip Builder also includes code and compiled
executables from the sources listed below:
ZipSigner
---------------
ZipSigner is Copyright (c) 2016-2020, John Wu @topjohnwu)
Original source code and license can be found at:
https://github.com/topjohnwu/Magisk
The version of ZipSigner used in Zip Builder was built by @topjohnwu using the source code above and optimized using ProGuard optimizations
Info-ZIP
----------
Info-ZIP is Copyright (c) 1990-2007 Info-ZIP
Original License can be found at:
http://www.info-zip.org/license.html
Downloads can be found at:
ftp://ftp.info-zip.org/pub/infozip/win32/
Original source code can be found at:
https://sourceforge.net/projects/infozip/
Hashutils
----------
The MD5 Checksum code and executable are from code.kliu.org
Original source code and compiled executables can be found at:
http://code.kliu.org/misc/hashutils/
SUMMARY OF RECENT CHANGES
SEPTEMBER 6, 2020 - v4.5.2
Fixed RegEx bug (oversight) that only supported automatic folder renaming through the year 2019. Now we're good through the year 2029.
As always, the best and easiest way to update is to simply install the new version using the Windows installer without uninstalling the previous version. All of your settings and options will be retained
NOVEMBER 1, 2018 - v4.5.1
Updated the cleanup function to also include removal of the SignAPK*.tmp files that are created in the %TEMP% folder during the signing process.
- Thanks to @osm0sis for reporting
MARCH 26, 2018 - v4.4.0
Updated the ZipSigner java executable to v2.1-min. This version is significantly smaller than v2.1 (458K vs 4.0MB) and was built by @topjohnwu, himself, using using ProGuard optimizations
Recompiled Zip Builder Settings Manager (ZipBuildSettings.exe) without UPX compression to try and further minimize AV false-positives
Windows installer now built using lzma2/max compression and no longer uses solid compression. This was done to optimize installation speed and further minimize AV false-positives
MARCH 25, 2018 - v4.3.0
Updated signing code with the new ZipSigner 2.1 Java executable that was rewritten from the ground up by @topjohnwu for use in his Magisk root management software. This change will allow you to build the largest zip installer on even the smallest 32-bit machine. I was able to build a 1.0+GB shell-script based installer on a 32-bit Windows XP machine with only 1GB of RAM.
- Thanks, of course, to @topjohnwu, but also to @osm0sis for the heads up on its existence
- Thanks to @jenslody for building it for inclusion here.
Since memory and java heap size issues are now resolved with the above change, I have removed all memory and java heap size checks from Zip Builder. The above change also allowed me to remove the separate test key files (testkey.pk8 and testkey.x509.pem), signapk.jar, zipadjust, and minsignapk.jar executables as their functions are all now contained in the new ZipSigner 2.1 Java executable mentioned above.
Installer will now clean up its 'temp folder' files before displaying the 'COMPLETED' message. On slower systems this should reduce the delay when selecting the 'Close' button after Zip Builder completes the signing process.
- Thanks to @osm0sis for reporting and helping track down the issue
Zip Builder is now built without UPX compression on the Windows exe's. This was done to try and reduce false-positives that may be reported by your AV software. If you're still having AV hits, please read the ANTI-VIRUS FALSE-POSITIVES section on the OP.
Fixed bug in installer that would corrupt the context (right-click) menu settings on an update (not initial) installation.
- Thanks to @osm0sis for reporting and helping track down the issue
Excellent! Glad to see a public release! I was using Zip Builder all day to prepare my latest round of updates for my Odds and Ends thread, and it couldn't be easier!
It's been great working with you again @TKruzze, I knew you couldn't stay away from contributing awesome things to the community for too long.
Looks very cool! You're inspiring me to clean up and release a tool that I built which has no current equivalent.
Seeing as this uses Java, what would it take to make it work under linux? As a staunch Linux/osx user who only runs a windows VM for flashing his Samsung with odin, I would love to integrate this into my workflow, but without linux or Mac support for me personally that will be difficult ?
This is an incredible contribution. Thank you for making this public and for your hard work!
partcyborg said:
Seeing as this uses Java, what would it take to make it work under linux?
Click to expand...
Click to collapse
The only thing I'm actually using Java for is the signing portion of the process. There's no real way I can think of to easily port the rest of it to Linux. Thanks for the feedback!
wow thanks @TKruzze :good:
this will be really helpful for my future firmware updates ✌
Ok im very very new to all this but does this make zips that are flashable in twrp? Im wanting to learn how to do that if you guys could point me in the right direction id be thankful.
papasmurf879 said:
Ok im very very new to all this but does this make zips that are flashable in twrp? Im wanting to learn how to do that if you guys could point me in the right direction id be thankful.
Click to expand...
Click to collapse
yes
you need update-script and update-binary along other files
TKruzze said:
The only thing I'm actually using Java for is the signing portion of the process. There's no real way I can think of to easily port the rest of it to Linux. Thanks for the feedback!
Click to expand...
Click to collapse
My mistake. Thanks for the explanation! I'm sure then that this will run in wine however, I may give it a shot at some point. If I do I will let you know.
kamilmirza said:
yes
you need update-script and update-binary along other files
Click to expand...
Click to collapse
Thank you for replying im doing searches right now trying to figure it out.
papasmurf879 said:
Thank you for replying im doing searches right now trying to figure it out.
Click to expand...
Click to collapse
Advanced, but check out my thread here and the linked resources: [DEV][TEMPLATE] Complete Shell Script Flashable Zip Replacement + Signing [SCRIPT]
The EDIFY references/resources are the place to start. :good:
Can i create flashable zips of my apks. I Flash custom roms very often and some apps are needed as my daily driver so can i make a flashable zip of those apk file and flash via this tool
Ash225 said:
Can i create flashable zips of my apks. I Flash custom roms very often and some apps are needed as my daily driver so can i make a flashable zip of those apk file and flash via this tool
Click to expand...
Click to collapse
Have you tried this?
This tool in this thread is for making a zip if you already have the components (updater script and binary).
madbat99 said:
Have you tried this?
This tool in this thread is for making a zip if you already have the components (updater script and binary).
Click to expand...
Click to collapse
Thanks but i knew about this app i want to creat zips from my computer and not from my phone thats why i asked the question thanks for your prompt reply
This looks like this tool that will, hopefully, be helpful for one of my other little projects that I had to put aside till I finish catching up with some other projects/developments that's already on my plate.
I already have a working set of script commands for safely disabling the Google Play Protect but, i will need a medium/delivery system before I can release it and this looks promising to help with this.
~~~~~~~~~~~~~~~
I DO NOT provide support via PM unless asked/requested by myself. PLEASE keep it in the threads where everyone can share.
Did you just give me a Trojan? Because Defender says so and even VirusTotal was positive about this. Beware about using this software!
Djentist said:
Did you just give me a Trojan? Because Defender says so and even VirusTotal was positive about this. Beware about using this software!
Click to expand...
Click to collapse
Yeah, I'm sure one of the most respected developers on XDA would do that. I'd be more worried about those antivirus softwares you're using than anything.
Djentist said:
Did you just give me a Trojan? Because Defender says so and even VirusTotal was positive about this. Beware about using this software!
Click to expand...
Click to collapse
Definitely not a very responsible post to make. There's nothing wrong about reporting your findings, but to make an accusation like this is a bit irresponsible. I also seriously doubt that Microsoft Defender identified this as a virus (as you claim).
Anyways, here are the facts: There is no virus or malicious behavior. Below are the actual results of scans by VirusTotal and VirScan
Zip Builder_4.2.1_Setup.exe
VirusTotal.com (0/65)
VirScan.org (1/39)
ZipBuildSettings.exe
VirusTotal.com (2/66)
VirScan.org (2/39)
ZipBuild.exe (32 bit)
VirusTotal.com (2/66)
VirScan.org (2/39)
ZipBuild.exe (64 bit)
VirusTotal.com (1/65)
VirScan.org (1/39)
Based on personal experience, ANY file that is not signed with a Microsoft Root Certificate and/or uses UPX compression is going to produce false positives with the heuristics deployed by some of these 'so called' anti-virus software products in the marketplace. I'm actually surprised the numbers are as low as they are.
All that said, if you are not comfortable using the software, fine. But please exercise responsible reporting if you have questions or concerns. A big part of the reason for me releasing all the source code is to avoid having to defend myself from people making exactly this type of assertion.
**** Disclaimer: I'm not responsible if you destroy your device. Use at your own risk!!! ****
GrapheneOS is an open source privacy and security focused mobile OS with Android app compatibility. It's focused on the research and development of privacy and security technology including substantial improvements to sandboxing, exploit mitigations and the permission model. Currently it is based on AOSP.
Link: (Mod Edit: Link removed)
Important information:
1. This ROM does NOT include Gapps or Google Play Service and hasn't Signature Spoofing Support. If you rely on the mentioned things this Rom isn't for you.
2. I take the official releases, modify the install script and include a pre-patched Magisk boot image. I'm not in contact with the GrapheneOS dev which is the reason why i mark this ROM as Unofficial.
3. Due of point two: Please don't ask questions on the official channels as reddit. Leave comments etc here on this thread.
4. You need a unlocked bootloader to flash this rom and must have adb+fastboot installed on your computer. If this is not the case download it from here: https://developer.android.com/studio/releases/platform-tools
I plan to make unofficial releases when new official builds are available.
Features:
AOSP 10
Built-in Firewall
Built-in local backup function (it's not working on all Apps; some doesn't support it)
Improved MAC Randomization
Hardened Kernel
Expanded Permissions (sensors)
Force calls to 4G only
Bugs
- Receiving text over verizon sim doesn't work reliable. Thx @wolfu11 for reporting.
Download: (Mod Edit: Link removed)
Installation:
Notice 1: The First-time installation will wipe your data. Backup first (i recommend this too when you follow the update instructions to be safe)
Notice 2: I recommend to have the newest stock firmware before the First-time installation
First-time installation:
1. Download the zip from the linked download page and unzip it on your computer
2. Copy the following files into the plattform-tools folder:
-> coral zip
-> bootloader img
-> radio img
-> flash-all_first_install.bat for Windows or flash-all_first_install.sh for Linux
3. Boot your phone into fastboot mode and verify that the phone is recognized from your computer
4. In Terminal (Linux) or Powershell (Windows): Run the appropriate script
5. Install the Magisk Manager App
10. Be happy with a rooted GrapheneOS
Update:
Notice: I assume that fastboot+adb is still installed on your computer.
1. Download the newest zip from the linked download page and unzip it on your computer
2. Copy the following files into the plattform-tools folder:
-> coral zip
-> bootloader img
-> radio img
-> flash-all.bat for Windows or flash-all.sh for Linux
If your computer asks you to overwrite the current files in the plattform-tools folder, confirm it.
3. Boot your phone into fastboot mode and verify that the phone is recognized from your computer
4. In Terminal (Linux) or Powershell (Windows): Run the appropriate script
5. Start the system once. This need a few more time than the first installation cause the data partition remains. Be patient.
6. Install the Magisk Manager App
7. Be happy with a rooted GrapheneOS
Sources:
https://github.com/GrapheneOS
https://grapheneos.org/releases
https://github.com/GrapheneOS/kernel_google_coral
https://github.com/GrapheneOS/device_google_coral-kernel
All Credits go to:
- The GrapheneOS team
- wolfu11 for reporting the verizon bug and testing the windows scripts
- and topjohnwu for his amazing Magisk
Created: 09.08.2020
Based on: Android 10
Updated: 21.08.2020
Current Version: 2020.08.07.01
Changelog from 09.08.2020
New Release: 2020.08.03.22
SHA3-512 Hash for Complete zip:
Code:
773c67b8571927c6f884a98ee67a10f96c3a759e34f925f7a8aaab7c19a4ca6b1ff53bb6dc500b4fe7c306b73853189a1c559889df6d9b4f2e8a90258d3d26c9
SHA3-512 Hash for Unpatched boot.img:
Code:
9b584f6941d37f60a7ed17ec4108b7bf484c3cbf1b63f2be6af1e59f452ed1d06e1b64704785d6ca3b38a3c09c8f29657f88c757bda993df509ef001d9842f00
Changes:
full 2020-08-01 security patch level
full 2020-08-05 security patch level
rebased onto QQ3A.200805.001 release
fix secondary stack hardening when a non-page-size multiple stack size is specified
fix picking up previous build date when doing incremental builds
Vanadium: update Chromium base to 84.0.4147.89
Vanadium: update Chromium base to 84.0.4147.105
Vanadium: update Chromium base to 84.0.4147.111
Vanadium: remove Chromium logo in chrome://version
kernel (Pixel 4, Pixel 4 XL): read-only data expansion
Changelog from 11.08.2020:
Updated the OP with some more informations
Rewrite the instruction cause i believe that they were not fully correct.
Reupload the 2020.08.03.22 unofficial release with new structure. I patched the boot.img which come with GrapheneOS in the zip with Magisk and then replaced the original GrapheneOS boot.img in the zip with the patched version.
Hi good evening to all,
Can somebody try to install this Rom with the updated instructions? I think they should work now (at least on Linux) but i would appreciate a confirmation to be safe.
dhacke said:
Changelog from 11.08.2020:
Updated the OP with some more informations
Rewrite the instruction cause i believe that they were not fully correct.
Reupload the 2020.08.03.22 unofficial release with new structure. It isn't needed anymore to flash Magisk separately from the zip. I replaced the stock boot.img in the zip with the pre-patched one.
Click to expand...
Click to collapse
Just a heads up - you really aren't meant to pre-patch a boot image for Coral/Flame, as you are only meant to patch the boot image from your own individual device, as per the man topjohnwu himself
See: https://twitter.com/topjohnwu/status/1272136975022084097?s=19
Can you supply the unpatched boot img?
Thank you
wolfu11 said:
Can you supply the unpatched boot img?
Thank you
Click to expand...
Click to collapse
Done. Look here: (Mod Edit: Link removed)
I added an SHA3-512 Hash for file checking,too (see changelog from 11.08.2020).
Changelog from 15.08.2020
New Release: 2020.08.07.01
SHA3-512 Hash for Complete zip:
Code:
f3a2b088e0ec503296d5a2527a3766951cb2a3ccd1955ced14d304222e76ed3f341dd9d84b6e186a534eddac335065b756c1fdc89d0f1db3985314424e7f9eea
SHA3-512 Hash for unpatched boot image:
Code:
11abb901511ce8e39911bc951be4b1a349158c5d8389e74766942159c0f83aa9730ed39d8c8ae6c3cc66be559e3c165b5d4f35e0962d20a7be0b1532673a0287
Changes:
SELinux policy: fix executing apk libraries as executables for third party applications
Installation Notices:
From 2020.08.03.22 => No wipe needed. Just take the update scripts and let the right one running (see OP).
From Stock Rom => Use the install_first scripts. Be aware: This will wipe your data
Apart from that i recommend to make a backup first always (to be safe).
Wireguard Kernel integration
dhacke said:
Hi good evening to all,
Can somebody try to install this Rom with the updated instructions? I think they should work now (at least on Linux) but i would appreciate a confirmation to be safe.
Click to expand...
Click to collapse
Hi, great work!! It was exactly what I was looking for, GrapheneOS with root. Are you able to integrate wireguard into the kernel?
[email protected] said:
Hi, great work!! It was exactly what I was looking for, GrapheneOS with root. Are you able to integrate wireguard into the kernel?
Click to expand...
Click to collapse
Hi Cryptt33,
first thx for your praise.
Regarding wireguard integration:
You should be able to use Wireguard independently from the kernel if i understand the description from the wireguard f-droid app right (https://f-droid.org/en/packages/com.wireguard.android/).
Then Wireguard runs in a userspace version. Apart from that i have found a xda thread already regarding wireguard integration. I guess i will at least try it and mayby i will be successful with the help of the thread. But i can't give a eta. I built roms from sources in the past but i until now i didn't try to modify them before the compiling step.
Best regards
dhacke
dhacke said:
Hi Cryptt33,
first thx for your praise.
Regarding wireguard integration:
You should be able to use Wireguard independently from the kernel if i understand the description from the wireguard f-droid app right (https://f-droid.org/en/packages/com.wireguard.android/).
Then Wireguard runs in a userspace version. Apart from that i have found a xda thread already regarding wireguard integration. I guess i will at least try it and mayby i will be successful with the help of the thread. But i can't give a eta. I built roms from sources in the past but i until now i didn't try to modify them before the compiling step.
Best regards
dhacke
Click to expand...
Click to collapse
Just need to add this to local_manifest for WG support
If unfamiliar with local_manifest, it's located in /.repo/local_manifests/ - it'll be the only file in that dir, often it's called room service.xml but it could be something like graphene_manifest.xml. Either way, it'll be the only file there and it'll be an XML - add those lines above to it and sync and you should have WireGuard support.
<remote name="zx2c4" fetch=https://git.zx2c4.com/>
<project remote="zx2c4" name="android_kernel_wireguard" path="kernel/wireguard" revision="master" sync-s="true" />
dhacke said:
Hi good evening to all,
Can somebody try to install this Rom with the updated instructions? I think they should work now (at least on Linux) but i would appreciate a confirmation to be safe.
Click to expand...
Click to collapse
I've tried this several time with a windows computer with no luck the shell opens briefly with red writing on the top and closes.
i must be doing something wrong but can't put my finger on it..... i run windows ltsb but i don't have any issues up and downgrading my p4 xl on it i am running the latest platform tools but get this message:
C:\Users\Wolf's laptop\Desktop\platform-tools_r30.0.4-windows\platform-tools>flash-all_first_install
fastboot : The term 'fastboot' is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:10
+ $version=fastboot --version; try { $verNum = $version[0].substring(17 ...
+ ~~~~~~~~
+ CategoryInfo : ObjectNotFound: (fastboot:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
fastboot too old; please download the latest version at https............
wolfu11 said:
I've tried this several time with a windows computer with no luck the shell opens briefly with red writing on the top and closes.
i must be doing something wrong but can't put my finger on it..... i run windows ltsb but i don't have any issues up and downgrading my p4 xl on it i am running the latest platform tools but get this message:
C:\Users\Wolf's laptop\Desktop\platform-tools_r30.0.4-windows\platform-tools>flash-all_first_install
fastboot : The term 'fastboot' is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:10
+ $version=fastboot --version; try { $verNum = $version[0].substring(17 ...
+ ~~~~~~~~
+ CategoryInfo : ObjectNotFound: (fastboot:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
fastboot too old; please download the latest version at https............
Click to expand...
Click to collapse
Hi wolfu11,
i know this message in similar way on Linux. To fix it on linux i need to run all fastboot commands and scripts with './' before.
So for example:
./fastboot devices instead of fastboot devices or ./flash-all.sh instead of flash-all.sh.
I done this in the scripts for linux already cause i know it is needed there but didn't thought that it is needed on windows, too.
So please go into the script and make this before all fastboot commands:
./
Save it and execute it in the plattform-tools folder with ./ again in the shell. Hopefully it runs then.
If this fixes your issue, i will update the windows scripts.
dhacke said:
Hi wolfu11,
i know this message in similar way on Linux. To fix it on linux i need to run all fastboot commands and scripts with './' before.
So for example:
./fastboot devices instead of fastboot devices or ./flash-all.sh instead of flash-all.sh.
I done this in the scripts for linux already cause i know it is needed there but didn't thought that it is needed on windows, too.
So please go into the script and make this before all fastboot commands:
./
Save it and execute it in the plattform-tools folder with ./ again in the shell. Hopefully it runs then.
If this fixes your issue, i will update the windows scripts.
Click to expand...
Click to collapse
I will try it when I get home today thank you
wolfu11 said:
I will try it when I get home today thank you
Click to expand...
Click to collapse
that didn't work either i downloaded the latest platform tools so im at a loss about the fastboot issue.
I'm going keep trying
Update: I was able to get the official Graphene to work via putting the image into a working stock update platform tools folder and renaming it to the stock image. it wouldn't work per instruction on the website very strange.
wolfu11 said:
that didn't work either i downloaded the latest platform tools so im at a loss about the fastboot issue.
I'm going keep trying
Update: I was able to get the official Graphene to work via putting the image into a working stock update platform tools folder and renaming it to the stock image. it wouldn't work per instruction on the website very strange.
Click to expand...
Click to collapse
Well it was worth a shot texts don't work on verizon so i guess i'll just give up.
thank you
wolfu11 said:
Well it was worth a shot texts don't work on verizon so i guess i'll just give up.
thank you
Click to expand...
Click to collapse
Hi wolfu11,
i tested the bat script (more precisely flash-all.bat) with './' on my dedicated gaming machine with win 10 2004 education, too. First i got the same problem as you: It didn't run whether i made './' before all fastboot commands in the scripts.
Then i removed all the './' before all fastboot command except at this line:
Code:
$version= fastboot --version; ^
So the line looks now:
Code:
$version=./fastboot --version; ^
And hurray the script worked without problems on my machine (see attached screenshots).
Only as reminder: The bat scripts are from the 2020.08.07.01 unofficial release so you need the radio, bootloader and image files from that release.
i attached the new scripts with my mentioned modification, too. Xda doesn't allow bat files so i made them into a zip file. Please test once more. Thx in advance.
dhacke said:
Hi wolfu11,
i tested the bat script (more precisely flash-all.bat) with './' on my dedicated gaming machine with win 10 2004 education, too. First i got the same problem as you: It didn't run whether i made './' before all fastboot commands in the scripts.
Then i removed all the './' before all fastboot command except at this line:
Code:
$version= fastboot --version; ^
So the line looks now:
Code:
$version=./fastboot --version; ^
And hurray the script worked without problems on my machine (see attached screenshots).
Only as reminder: The bat scripts are from the 2020.08.07.01 unofficial release so you need the radio, bootloader and image files from that release.
i attached the new scripts with my mentioned modification, too. Xda doesn't allow bat files so i made them into a zip file. Please test once more. Thx in advance.
Click to expand...
Click to collapse
That script worked thanks
wolfu11 said:
That script worked thanks
Click to expand...
Click to collapse
Yeah finally. I'm happy to read that. Then i will update the OP & scripts in the next days and take you on the credit section. Thx very much for your windows testing.
Now the next on the to-do list is the building of this rom from source and adding Wireguard support into the kernel
dhacke said:
Yeah finally. I'm happy to read that. Then i will update the OP & scripts in the next days and take you on the credit section. Thx very much for your windows testing.
Now the next on the to-do list is the building of this rom from source and adding Wireguard support into the kernel
Click to expand...
Click to collapse
No problem i'm happy to test. unfortunately the still is an issue with texting on verizon which is what i use this phone on. the texts send but receiving them is not reliable. I tested on an att sim and it didn't have an issue so it's something on verizon's end.
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?