Related
The purpose of this thread is to provide a guide for users who have Proxyme preloaded in their device's firmware and want to find out how to use it effectively. Ideally, this will be a place to share experiences and ideas to further improve the tool and provide solutions to problems that people may have.
Introduction
Proxyme ( proc-zahym ) represents a system access solution comprised of the following components:
System service - provides access to privileged system environment
SSH daemon - provides secure shell (ssh) and file (scp) access (based on dropbear)
proxyme.apk - user interface module
This solution is offered as a preloaded option in firmware images and consequently cannot (should not) be installed as a regular app, either from the Play Store or being side loaded. The reason for pre-loading stems from the requirements of the system service component to be able to integrate at system level and not be bound by operating restrictions within the Android application and framework platform environment (Zygote and Dalvik sandbox). The Play Store has been enlisted as the primary and preferred source in providing updates to the user interface component; the actual app you will be interacting with.
Proxyme offers the following functionality through its user interface:
Installation/de-installation of the su binary to provide/remove root access
(useful only for other applications which require root level access)
The persistent behaviour of the su binary can be controlled by a one-shot switch
Register/de-register tag-along scripts for su enable and disable actions
(more details on this below)
Control availability and location of busybox toolbox
Start/Stop SSH daemon
Configure listening port for the SSH daemon
Configure user accounts for the SSH daemon
Submit and execute a shell script
SU Binary
The option to enable or disable the su binary switch (on/off) in the user interface is the equivalent of rooting and unrooting the device. When enabled, you are providing root access to apps which require it to perform correctly. Currently, Proxyme does not have built-in support for monitoring and 'policing' the actual access to root.
Auto Root @ Boot
This switch in the Proxyme app allows you to indicate whether the su binary should be installed or removed during a reboot or startup of the device. Setting it to the 'on' position will make the su binary persistent throughout reboot cycles and leave your phone permanently 'rooted'.
Registering Tag-along Scripts
Whenever you enable or disable the su binary with the on/off switch in the user interface, there exists an option to execute a user script just prior to and one unique to each action. This is possible by pre-registering a script for one of or both enable/disable actions. A script can virtually perform anything and is always executed within root context. Note that you must be very cautious about the scripts you are registering and be certain about their intentions, because a rogue script could cause irreparable damage to you device.
Each script has the option to override, and thus block, the intended action (enable or disable) by setting a system property named proxyme.override to anything but blank.
One purpose of having tag-along scripts would be to 'freeze' and 'unfreeze' specific root-shy apps, which do not 'like' rooted systems. This is one area where we can share the experience of pre-coded scripts for certain target apps and I do hope it will be put to good use.
To submit a script file, tap on one of the SU Enable Script or SU Disable Script text elements to start browsing for a file.
Busybox
Busybox is just that, busybox. Options are available to determine one of two hard-configured locations where it can be installed and to enable or disable it.
More to follow later...
SSH Daemon
The SSH daemon is based on dropbear. It has been modified to support logon accounts in Android, which are configured with the following parameters:
username
password
home directory
which shell to use
user ID
group ID
For whatever reasons, you can restrict access by specifying non-root user and group (0:0) IDs. The IDs you can choose from are derived from a system list which was used and known within Android at the moment of booting the device. If you have installed new apps in the meantime and would like to use their newly assigned IDs, then please reboot the phone to update this list.
Executing Shell Scripts
The ability to submit and execute a shell script from the user interface can be considered a convenient and quick way to get some tasks done. Take note however that your scripts are run in a privileged environment under the root account and that there are risks involved. A rogue or insufficiently tested script can cause major problems if/when it makes changes to key system partitions, which are normally mounted read only for obvious reasons.
Most rom images will include a sample de-bloating script,which removes ROM specific branding apps. The script. /sdcard/Proxyme/debloat.sh, shows how this is done and could serve as a base for more extensive clean-up of firmware components, if you so desire.
Operational Notes
Whenever a device boots from a factory reset condition (i.e. after wiping data), there will be no UID/GID list available in the user management screen. The reason for this is that the SuMeD setup process will complete before the app data store, the location where aforementioned list is stored. has been initialised. Restart the device in order to make this list available.
Behind The Scenes
For details regarding how Proxyme's system service components are integrated in a firmware image, please follow this trail...
Device Support
Before taking the next step to flash your phone/device, please be aware of the risks involved with performing such an operation. Prepare the device properly, i.e. sufficient battery charge, and be well informed of the correct flashing procedure(s) for your device's make and model. On Samsung devices, rooting will probably trigger 'custom' flag(s) and consequently render the warranty void. No matter how adventurous you may feel, it is always a bad idea to try to flash a firmware image which is not intended for your device. Having said all that, note that you will be flashing your phone at your own risk. You are solely responsible for anything you do to your phone/device, so make sure you are well informed and well prepared before deciding to flash or install anything on it.
The following list will be updated as soon as new firmware images are prepared for new and old devices.
Samsung Galaxy Note 10.1 2014
SM-P600 - (reference post)
Samsung Galaxy J
SC-02F (Docomo) - (reference thread)
SGH-N075T (Taiwan) - (reference thread)
Samsung Note 3
SM-N9005 - (reference post)
SM-N900A - (reference post - unconfirmed)
Samsung Galaxy S4
SHV-E330K - (reference thread)
SHV-E330L - (reference thread)
SHV-E330S - (reference thread)
SGH-I337 - (reference post - unconfirmed)
SC-04E - (reference post)
Samsung Galaxy Grand 2
SM-G710L - (reference post)
Samsung Galaxy S3
GT-I9300 - (reference post)
SC-03E - (reference thread)
SHV-E210K - (reference thread)
SHV-E210L - (reference thread)
SHV-E210S - (reference post)
SHW-M440S - (reference post)
Samsung Galaxy S2 LTE
SHV-E110S - (reference thread)
Samsung Galaxy S2
SHW-M250K - (reference post)
Planned Changes
built-in control of su access (much like what Superuser currently does)
choice of built-in simple file browser or use intents to initiate external app(s) for browsing and selecting files
...
Proxyme - Behind The Scenes
This section details how Proxyme's system service components are integrated in a firmware image.
If you are not up to speed with how a typical Android system is constructed, then I would like to suggest you at least make yourself familiar with this topic in order to fully understand what to do with the following text.
The system service components are integrated in the /system partition (mount point) in Android. In the case of changing a live system this will require mounting the appropriate partition read/write before applying the updates. If a static firmware image is to be updated, then extract the component which represents the /system partition from the package and apply the updates before re-packing the firmware image.
The following list describes the major system service components:
hijacker - this is a module you need to write, which has the role of initiating the system service in a privileged environment.
hjprepper - this module is started by the hijacker to prepare the environment prior to starting SuMeD
SuMeD - this one is what it's all about. The Proxyme app relies on this daemon to be up and running in order to perform any of its privileged functions
SSHD - the SSH daemon is represented by an updated implementation of dropbear on Android
Hijacker
The hijacker is a program you would normally have to write to replace an existing program in your rom, which is started during the boot process by for example initd. This part of the integration process requires your (creative) input, since you need to analyse the rom you are working on and figure out how and where to position the hijacker module. If you do find an existing module to hijack, make sure to always call that original module from your hijacker once it has managed to execute the hjprepper program. In some roms it suffices to start hjprepper from a shell script, which is run with root access... they exist, you just have to look for them.
This is what your hijacker could look like in C
Code:
#define PROP_HIJACK "proxyme.hijack.system"
#define HIJACKEE "/system/bin/original-program"
#define PREPPER "/system/xbin/hjprepper"
int main( int argc, char *argv[] )
{
char *lArgv[5];
char **lArgList;
int lArgCnt;
pid_t pid;
lArgList = (char **)malloc( sizeof(void *) * (argc + 1) );
for ( lArgCnt = 0; lArgCnt < argc; lArgCnt++ )
{
lArgList[ lArgCnt ] = argv[ lArgCnt ];
}
lArgList[ lArgCnt ] = NULL;
/* Fork parent process */
pid = fork();
if ( pid < 0 )
{
property_set( PROP_HIJACK, (char *)"Hijacker Startup... spawning failed, prep first before xfer" );
system( "/system/xbin/hjprepper" );
execv( HIJACKEE, lArgv );
exit( EXIT_SUCCESS );
}
else if ( pid > 0 )
{
property_set( PROP_HIJACK, (char *)"Hijacker startup... spawned, parent ascends phase 2" );
execv( HIJACKEE, lArgv );
exit( EXIT_SUCCESS );
}
if ( execl(PREPPER, PREPPER, (char *)NULL) < 0 )
{
property_set( PROP_HIJACK, (char *)"Hijacker startup... failed to call prepper" );
}
exit( EXIT_SUCCESS );
}
hjprepper
This program is responsible for setting up an operating environment for the SuMeD daemon. If you have full control over a rom's boot image, then include a call in your init process to start this module once during boot. If not, then use a hijacker program or look for existing and suitable scripts to initiate hjprepper.
hjprepper starts the SuMeD daemon once it completes the setup and configuration procedure.
SuMeD
This bad boy is responsible for the user requested actions through interaction with the Proxyme app.
Prebuilt Packages
To get you started, there are pre-built modules available,which you can download here. Currently, availability is limited to Android 4.3 and 4.4.2 only. The following zip archives are organized in a folder tree structure,which serves as a guide for where to place the modules within the /system path.
4.3 Prebuilts
4.4.2 Prebuilts
Filler 2
Filler 2
Filler 3
Filler 3
Please add support in latest SHV-E110S 4.1.2 rom(s)
Title says/asks it all...
Can You guide build pre-rooted rom by proxyme? Thank you very much.
linhbs said:
Can You guide build pre-rooted rom by proxyme? Thank you very much.
Click to expand...
Click to collapse
Behind The Scenes section has been added to the OP.
Can this method be used to prebuilts S3, S4, Note3 not Korea? Thanks so much.
linhbs said:
Can this method be used to prebuilts S3, S4, Note3 not Korea? Thanks so much.
Click to expand...
Click to collapse
Yes. You need to figure out how to get the SuMeD daemon started and that depends on the rom you want to integrate it in. The Behind The Scenes post highlights what areas to focus on when doing this.
Note that the first post includes 2 firmware images (both Android 4.3 and 4.4.2) for the international Note3 (SM-N9005). It's a no-brainer to copy the files from the appropriate directories to an equivalent and same level version firmware for another region of the same device.
Please add support N900A 4.4.2. Thank you very much.
linhbs said:
Please add support N900A 4.4.2. Thank you very much.
Click to expand...
Click to collapse
Has 4.4.2 been released on that device? If yes, a download link for the official stock firmware will help speed up the process. If not, then we wait or you could send a PM to davidcsv with the 10 or 11 digit s/n and he will monitor and download the latest release as soon as it becomes available...after that your new firmware image will be uploaded within a day.
Link: http://www.androidfilehost.com/?fid=23321874045862490. Thank you for your interest!
linhbs said:
Link: http://www.androidfilehost.com/?fid=23321874045862490. Thank you for your interest!
Click to expand...
Click to collapse
N900AUCECMLG (preloaded with Proxyme) (2014-01-04)
This rom implicitly performs a factory reset, so backup your data before flashing it. Unpack the zip archive and specify the resulting .tar.md5 filename in the PDA/AP section of the latest version of Odin.
Use Proxyme to execute the /sdcard/Proxyme/debloat.sh script to get rid of the k n o x messages.
mega.co.nz
torrent, mirror
Apparently, this firmware image is a pre-release/leaked image and not the final deal. It includes an updated bootloader and related components, meaning that it will not be straightforward to revert back to an older version of the firmware. If you encounter problems with this Proxyme preloaded image, then I'd suggest flashing the image from the original download link.
All feedback is welcome and will be appreciated. Enjoy!
Thank you very much. I ask you to add proxyme in I337 4.4.2 rom. Thank you very much.
Link: http://www.androidfilehost.com/?fid=23329332407566813
linhbs said:
Thank you very much. I ask you to add proxyme in I337 4.4.2 rom. Thank you very much.
Link: http://www.androidfilehost.com/?fid=23329332407566813
Click to expand...
Click to collapse
I337UCUFMLD (preloaded with Proxyme) (2014-01-02)
This rom implicitly performs a factory reset, so backup your data before flashing it. Unpack the zip archive and specify the resulting .tar.md5 filename in the PDA/AP section of the latest version of Odin.
Use Proxyme to execute the /sdcard/Proxyme/debloat.sh script to get rid of the k n o x messages.
mega.co.nz
torrent, mirror
Apparently, this firmware image is also a pre-release/leaked image and not the final deal. It too includes an updated bootloader and related components, meaning that it will not be straightforward to revert back to an older version of the firmware. If you encounter problems with this Proxyme preloaded image, then I'd suggest flashing the image from the original download link. A Google search shows that this image does have a few minor issues, so beware.
All feedback is welcome and will be appreciated. Enjoy!
Thank so much. I find the phone test. Will respond to you.
SC-04E Stock Firmware Proxyme Rooter images
Root Ready Stock Images
(Unfortunately, flashing these ROMs will trigger KNOX)
Kitkat 4.4
SC04EOMUFNI3 (Proxyme) (Build Date 2014-09-19)
This zip archive contains an Odin flashable file. It is not the complete stock image, so you MUST have OMUFNI3 already running on your phone or you will need to download it from the above reference sites, which carry complete stock firmware images, and flash it before continuing with this file. Instructions are included in the zip archive.
uploaded.net
mediafire
torrent, mirror2
I337:
- Before flash rom: I337UCUEMK2 version 4.3
- After flash rom I337UCUFMLD (preloaded with Proxyme) fail.
Good.
linhbs said:
I337:
- Before flash rom: I337UCUEMK2 version 4.3
- After flash rom I337UCUFMLD (preloaded with Proxyme) fail.
Click to expand...
Click to collapse
Please post the complete log from the message box in Odin. One more question, is your phone 16GB or 32GB model?
update: and also try again with newer version of Odin v3.09 instead of v3.07
Introduction
If you get your hands on a device with Cyanogen OS preinstalled and there is no factory image for it published by Cyanogen Inc. yet, then this script is for you. It constructs download links of factory image from a device running Cyanogen OS.
There are different files for a factory image: signed fastboot flashable zip, signed zip & boot-debuggable image.
Signed fastboot flashable zip: It contains the complete rom and can overwrite everything including your data partition. These cannot be flashed via recovery - extract their contents and flash via fastboot. An unlocked bootloader is required.
Signed zip: Normal recovery-flashable zip that contains just the system and kernel (they won't overwrite your data partition).
Boot-debuggable image: It is boot image/kernel that enables adb root and the developer menu options.
Requirements
1. Windows Vista or newer. 2000/XP should also work if choice.exe is present. Linux & OSX users should check the Python port.
2. Properly installed adb driver; see here.
3. Properly configured adb_usb.ini (optional); see here.
4. A device with regular Cyanogen OS (testing versions aren't supported) installed; list is here.
Download
https://github.com/Titokhan/cosfid
Usage
Download all of the files using "Download ZIP" option, extract somewhere (path with no space is recommended), connect the target device using USB cable & execute COSFID.cmd.
COSFID.py is intended for Linux & OSX users, though Windows users can run it too if Python for Windows is installed. The Python port is a quick-and-dirty one; it needs more refinement.
Don't confuse it by Cyanogen OS OTA trackers like the original one; read carefully to spot the difference.
Credit
1. qewlpal for inspirations in scripting
2. Jernej Simončič for providing Windows builds of GNU wget
3. Google for providing adb binaries under Apache license
4. Cyanogen for making Android more beautiful
Reserved for future.
Great job!
There is a way to get all ROM links for a specific model?
@bartito
Technically yes, but Cyanogen has made the tracking a little bit complicated now for 3rd parties. We also need to develop a database for historic data.
Titokhan said:
@bartito
Technically yes, but Cyanogen has made the tracking a little bit complicated now for 3rd parties. We also need to develop a database for historic data.
Click to expand...
Click to collapse
I'm refer to a way to locate new uploads.
Really not much interest on history but in the future
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.
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.
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?