Development Installing GSI by repacking super.img on SM-A127F and SM-A325F (Linux) - Samsung Galaxy A12

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?

Related

[TOOL] little tool support for flashing our moto v0.9.3

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.

[ROM] [Unofficial] [Stable] GrapheneOS 10 Pre-Rooted

**** 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.

[Android 12 / LineageOS 19.1] Manual patch to services.jar for signature spoofing

I haven't seen this shared anywhere but it's really quite straightforward if you know what you're doing. Maybe it helps someone to post it here. The next section is only for completeness, feel free to skip past it to get to the gist of it.
Background
Android by design depends for full functionality on Google services. These are normally provided by a proprietary application package com.google.android.gms. MicroG is an open-source replacement for Google services, allowing the user to take advantage of working notifications, location backends, installer, and other essential services, without compromising privacy and giving Google a backdoor to your device.
To operate properly, MicroG needs the ability to pretend it is the actual Google services application package, signed by Google. Hence the need for signature spoofing.
Official LineageOS builds do not include the ability to spoof signatures. Thus, using LineageOS with MicroG takes extra steps such as building patched LineageOS locally (a resource-consuming endeavor), or taking advantage of the LineageOS for MicroG builds helpfully provided in collaboration with the MicroG team (which however, due to resource constraints, are updated less often and lag behind the official builds).
A third solution is to patch an already-built system at installation time. This was initially implemented with Needle by souramoo, forked and improved upon as Tingle by @ale5000, which eventually inspired a wholly different approach with DexPatcher by @Lanchon, a tool allowing flexible patching of Dalvik executables, in particular services.jar, where signature spoofing is commonly implemented. Relevant patches for DexPatcher were authored by Lanchon himself up to Android 9. Later on, @oF2pks picked up the work to provide patches for Android 11.
Unfortunately, no such patch to be used with DexPatcher has existed from Android 12 onwards. One other option includes installing the FakeGApps Xposed module as forked and updated by whiz-inc. While it's great it exists, and the author's work should be appreciated, it's a complication and an unnecessary burden in many scenarios to depend on Xposed (and thus Magisk and LSPosed or the like) as a prerequisite for the patch to work. It's also worth it to be aware that the implementation makes it less secure than the traditional signature spoofing method.
The DexPatcher approach has several advantages. The patch can be more flexible and continues to apply as the underlying code changes. In comparison, the simple approach presented here is much more primitive and might require readjustment as new versions emerge over time. However it might still be good to know it works.
This way you can use the latest official LineageOS with MicroG, and update at will, as soon as new builds become available.
Patching
This is not a walkthrough, and I'm not going to explain everything step-by-step. Rather, the purpose is to give you the general idea what to do, which you can then adjust to your specific use case.
Obtain the file services.jar to patch. For example:
Pull it from your device: adb pull /system/framework/services.jar – or –
Extract it from a LineageOS image: payload-dumper-go -p system payload.bin and imgextractor system.img
Extract the file with APK Tool: apktool2 d -o services services.jar
Make the changes that allow signature spoofing. Either:
Apply the patch attached to this post: patch -i services.diff -p0 – or –
As of current LOS 19.1 builds (Nov 2022), you can just replace the single file: smali_classes2/com/android/server/pm/PackageManagerService$ComputerEngine.smali with the one attached to this post.
Note: this might not always hold in the future. You might even need to apply the patch manually if the source changes too much. Either approach works for now.
Recompile the modified framework: apktool2 b -c -f -o services.jar services
Note: This will overwrite the original services.jar. The -c flag to APK Tool is important as it keeps all the original META-INF inside it intact.
Copy services.jar over to the device: adb push services.jar /system/framework/ and you probably also have to adjust the permissions accordingly
This approach should work for any Android version in principle, although the exact patch might differ. However, since better options exist for Android 11 and below, you are probably interested in applying this to Android 12 or higher only.
One More Thing
For Android 12, an extra step is critical to ensure no bootloop on subsequent boot (2nd and then on), since oat_file_manager.cc now includes a check if OAT (.odex/.vdex) files are loaded from "trusted" locations only (effectively, the /system partition). You have to generate the optimization files and place them in the correct location, which is /system/framework/oat/arm64/:
dex2oat --dex-file=/system/framework/services.jar --instruction-set=arm64 --oat-file=/system/framework/oat/arm64/services.odex
The .vdex file will be created as well (these files already exist but should be overwritten, check the timestamps or you might want to delete them beforehand just to be sure). If you skip this step, the device will boot the 1st time but then the optimization files will be generated and saved in /data/dalvik-cache/. On any subsequent boot, an attempt to load these files from an "untrusted" location by the system will throw a fatal error and the Zygote process will die with the message: "Executing untrusted code from [...]". If you somehow find yourself in this predicament, delete the following files and reboot to temporarily make it work one more time:
/data/dalvik-cache/arm64/[email protected][email protected]@classes.dex
/data/dalvik-cache/arm64/[email protected][email protected]@classes.vdex
Further Steps
These are not all the required steps to install MicroG on an official LineageOS installation. You still want to, in particular:
Install at least the main MicroG app (GmsCore) and a dummy signature spoofing APK (also attached to this post) as priv-apps
Set up the priv-app permissions accordingly – otherwise you'll get a bootloop
Likely also install FakeStore, Aurora Store/F-Droid, and location backends of your choice, etc.
However: this is a simple solution to perhaps the most cumbersome aspect of signature spoofing. It's not necessary to resort to Xposed modules to get it working on Android 12, or to depend on a special build with the spoofing patched in at compilation time.
Credit: The patch .smali code has been reverse-engineered from the spoofing patch for LineageOS for MicroG builds.
Aqq123 said:
Patching
This is not a walkthrough, and I'm not going to explain everything step-by-step. Rather, the purpose is to give you the general idea what to do, which you can then adjust to your specific use case.
Obtain the file services.jarto patch. For example:
Pull it from your device: adb pull /system/framework/services.jar – or –
Extract it from a LineageOS image: payload-dumper-go -p system payload.bin and imgextractor system.img
Click to expand...
Click to collapse
can i do this method for android 12 one ui 4.1 s10e? it says extract lineage os from system image but how do i do that in one ui?
kullanici32 said:
can i do this method for android 12 one ui 4.1 s10e? it says extract lineage os from system image but how do i do that in one ui?
Click to expand...
Click to collapse
I don't know anything about Samsung but try here:
[TUTORIAL] How to Edit Unpack & Repack Samsung system.img or system.img.ext4
Follow https://stackoverflow.com/questions/58541074/how-to-unpack-modify-pack-and-flash-system-img-ext4-file-using-odin a) Modifying With simg2img system.img.ext4 system.img, you will get a raw image file named system.img With mkdir system...
forum.xda-developers.com
Alternatively you can just take services.jar from a live (running) system.
kullanici32 said:
can i do this method for android 12 one ui 4.1 s10e? it says extract lineage os from system image but how do i do that in one ui?
Click to expand...
Click to collapse
There are many good custom Rom for s10e. Why do you want to start with one UI ?
kurtn said:
There are many good custom Rom for s10e. Why do you want to start with one UI ?
Click to expand...
Click to collapse
due to some dysfunctions and design change, I will debloat one UI 4.1 and turn off google and samsung services in the back and make it like lineage os as much as possible, but the main services I use will be samsung applications. so i have a dream
kullanici32 said:
due to some dysfunctions and design change, I will debloat one UI 4.1 and turn off google and samsung services in the back and make it like lineage os as much as possible, but the main services I use will be samsung applications. so i have a dream
Click to expand...
Click to collapse
I've seen people doing similar things on android 12
Signature Spoofing on unsuported Android 11 (R) Roms
How to get Signature Spoofing working on Android 11 (R) Roms that have no support for Signature Spoofing? In my Case here I use a Samsung Galaxy S8 with an unofficial LineageOS 18.1 (Android 11) by stricted I use TWRP recovery but this should...
forum.xda-developers.com
kurtn said:
I've seen people doing similar things on android 12
Signature Spoofing on unsuported Android 11 (R) Roms
How to get Signature Spoofing working on Android 11 (R) Roms that have no support for Signature Spoofing? In my Case here I use a Samsung Galaxy S8 with an unofficial LineageOS 18.1 (Android 11) by stricted I use TWRP recovery but this should...
forum.xda-developers.com
Click to expand...
Click to collapse
because once you use samsung software, you can't quit. (of course debloated) I have used my phone without root until now, only by disabling system applications. now I'm trying to remove as much samsung/google as possible from the system or whatever services are unnecessary for me, I will do just like micro g for lineage os, the only difference is by using quality applications such as gallery phone application, because lineage os is very lousy.
Aqq123 said:
As of current LOS 19.1 builds (Nov 2022), you can just replace the single file: smali_classes2/com/android/server/pm/PackageManagerService$ComputerEngine.smali with the one attached to this post.
Note: this might not always hold in the future. You might even need to apply the patch manually if the source changes too much. Either approach works for now
Click to expand...
Click to collapse
How can I manually edit this file? because the attached file is 288kb and the one in samsung is 390kb.
so how do i open this file and where do i patch it?
kullanici32 said:
How can I manually edit this file? because the attached file is 288kb and the one in samsung is 390kb.
so how do i open this file and where do i patch it?
Click to expand...
Click to collapse
Of course. The patch is against current LOS 19.1, and this is the only situation where you can replace the whole .smali file instead of reapplying the patch. On other flavors of Android you'd have to redo the equivalent manually. In some cases it might even take a different patch altogether.
These are all text files. Just use any text editor, preferably with syntax highlighting, such as Notepad++. First look at services.diff. This is the code you want to add.
Now, in the APK you decompiled, look for where .method public final generatePackageInfo(Lcom/android/server/pm/PackageSetting;II)Landroid/content/pm/PackageInfo; is defined. The patch works by adding two private methods:
.method private static applyFakeSignature(Lcom/android/server/pm/parsing/pkg/AndroidPackage;Landroid/content/pm/PackageInfo;Ljava/util/SetLandroid/content/pm/PackageInfo;
.method private static getRequestedFakeSignature(Lcom/android/server/pm/parsing/pkg/AndroidPackageLjava/lang/String;
These can really be added anywhere but preferably within the same .smali file.
Finally, you change the code for generatePackageInfo(...) accordingly so that: (1) signature faking is added (OR-ed) to computed permissions for apps that have this permission granted, and the fake signature is returned where applicable instead of the actual one with applyFakeSignature(...).
Maybe it's easier to understand if you look at the original code, not the decompiled one: https://github.com/lineageos4microg..._patches/android_frameworks_base-S.patch#L128 This is why I linked to it in the top post.
Again, I don't know anything about Samsung One UI. The implementation might be different. So another approach would be to find a version of Samsung's services.jar patched for signature spoofing (possibly for an earlier version of Android) and decompile it to see how it's done there.
Aqq123 said:
Now, in the APK you decompiled, look for where .method public final generatePackageInfo(Lcom/android/server/pm/PackageSetting;II)Landroid/content/pm/PackageInfo; is defined.
Click to expand...
Click to collapse
{
"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"
}
.method private static applyFakeSignature(Lcom/android/server/pm/parsing/pkg/AndroidPackage;Landroid/content/pm/PackageInfo;Ljava/util/SetLandroid/content/pm/PackageInfo;
.method private static getRequestedFakeSignature(Lcom/android/server/pm/parsing/pkg/AndroidPackageLjava/lang/String;
I just write this code you say?
Or should I search for the code you provided in services.diff and copy the places marked in blue and copy the entire blue one into my original compiled file?
Aqq123 said:
Finally, you change the code for generatePackageInfo(...) accordingly so that: (1) signature faking is added (OR-ed) to computed permissions for apps that have this permission granted, and the fake signature is returned where applicable instead of the actual one with applyFakeSignature(...).
Click to expand...
Click to collapse
I hardly understand what you mean here.
i'm a bit of a novice
EDİT:
I added the blue parts after I found the red part, now I'll compile and test (I've probably missed something, but I'll have a look)
EDİT2:
generatePackageInfo
I searched for the code you said, but there were 3-4 (there was 1 that continued as L, and I deleted the one in this picture)
and i replaced it with this
I'll compile it now, probably won't, but...
This is the first time I've been in such a complicated business.
EDİT3: (FİXED EDİT 4 I went inside the extracted folder and solved this problem now it keeps compiling)
It gives such an error, why? (apktool2 command didn't work when extracting the file, it worked when I made apktool, ignore it) but now when recompiling it gives an error as in the picture.
EDİT5:
such an error???
EDİT6:
now that this did not happen, after extracting the jar file, I packed it again without making any changes, the original 30 mb file decreased to 20 mb and transferred to the device with mtp, then I copied it with root browser, the device system ui restarted and opened, the permissions were something like rw rw rw, maybe rw rw is Then I rebooted but the phone bootlooped. that is, if I decompile the original file and repackage it without doing anything else, it breaks down. :/
Aqq123 said:
I haven't seen this shared anywhere but it's really quite straightforward if you know what you're doing. Maybe it helps someone to post it here. The next section is only for completeness, feel free to skip past it to get to the gist of it.
Background
Android by design depends for full functionality on Google services. These are normally provided by a proprietary application package com.google.android.gms. MicroG is an open-source replacement for Google services, allowing the user to take advantage of working notifications, location backends, installer, and other essential services, without compromising privacy and giving Google a backdoor to your device.
To operate properly, MicroG needs the ability to pretend it is the actual Google services application package, signed by Google. Hence the need for signature spoofing.
Official LineageOS builds do not include the ability to spoof signatures. Thus, using LineageOS with MicroG takes extra steps such as building patched LineageOS locally (a resource-consuming endeavor), or taking advantage of the LineageOS for MicroG builds helpfully provided in collaboration with the MicroG team (which however, due to resource constraints, are updated less often and lag behind the official builds).
A third solution is to patch an already-built system at installation time. This was initially implemented with Needle by souramoo, forked and improved upon as Tingle by @ale5000, which eventually inspired a wholly different approach with DexPatcher by @Lanchon, a tool allowing flexible patching of Dalvik executables, in particular services.jar, where signature spoofing is commonly implemented. Relevant patches for DexPatcher were authored by Lanchon himself up to Android 9. Later on, @oF2pks picked up the work to provide patches for Android 11.
Unfortunately, no such patch to be used with DexPatcher has existed from Android 12 onwards. One other option includes installing the FakeGApps Xposed module as forked and updated by whiz-inc. While it's great it exists, and the author's work should be appreciated, it's a complication and an unnecessary burden in many scenarios to depend on Xposed (and thus Magisk and LSPosed or the like) as a prerequisite for the patch to work. It's also worth it to be aware that the implementation makes it less secure than the traditional signature spoofing method.
The DexPatcher approach has several advantages. The patch can be more flexible and continues to apply as the underlying code changes. In comparison, the simple approach presented here is much more primitive and might require readjustment as new versions emerge over time. However it might still be good to know it works.
This way you can use the latest official LineageOS with MicroG, and update at will, as soon as new builds become available.
Patching
This is not a walkthrough, and I'm not going to explain everything step-by-step. Rather, the purpose is to give you the general idea what to do, which you can then adjust to your specific use case.
Obtain the file services.jarto patch. For example:
Pull it from your device: adb pull /system/framework/services.jar – or –
Extract it from a LineageOS image: payload-dumper-go -p system payload.bin and imgextractor system.img
Extract the file with APK Tool: apktool2 d -o services services.jar
Make the changes that allow signature spoofing. Either:
Apply the patch attached to this post: patch -i services.diff -p0 – or –
As of current LOS 19.1 builds (Nov 2022), you can just replace the single file: smali_classes2/com/android/server/pm/PackageManagerService$ComputerEngine.smali with the one attached to this post.
Note: this might not always hold in the future. You might even need to apply the patch manually if the source changes too much. Either approach works for now.
Recompile the modified framework: apktool2 b -c -f -o services.jar services
Note: This will overwrite the original services.jar. The -c flag to APK Tool is important as it keeps all the original META-INF inside it intact.
Copy services.jar over to the device: adb push services.jar /system/framework/ and you probably also have to adjust the permissions accordingly
This approach should work for any Android version in principle, although the exact patch might differ. However, since better options exist for Android 11 and below, you are probably interested in applying this to Android 12 or higher only.
One More Thing
For Android 12, an extra step is critical to ensure no bootloop on subsequent boot (2nd and then on), since oat_file_manager.cc now includes a check if OAT (.odex/.vdex) files are loaded from "trusted" locations only (effectively, the /system partition). You have to generate the optimization files and place them in the correct location, which is /system/framework/oat/arm64/:
dex2oat --dex-file=/system/framework/services.jar --instruction-set=arm64 --oat-file=/system/framework/oat/arm64/services.odex
The .vdex file will be created as well (these files already exist but should be overwritten, check the timestamps or you might want to delete them beforehand just to be sure). If you skip this step, the device will boot the 1st time but then the optimization files will be generated and saved in /data/dalvik-cache/. On any subsequent boot, an attempt to load these files from an "untrusted" location by the system will throw a fatal error and the Zygote process will die with the message: "Executing untrusted code from [...]". If you somehow find yourself in this predicament, delete the following files and reboot to temporarily make it work one more time:
/data/dalvik-cache/arm64/s[email protected][email protected]@classes.dex
/data/dalvik-cache/arm64/[email protected][email protected]@classes.vdex
Further Steps
These are not all the required steps to install MicroG on an official LineageOS installation. You still want to, in particular:
Install at least the main MicroG app (GmsCore) and a dummy signature spoofing APK (also attached to this post) as priv-apps
Set up the priv-app permissions accordingly – otherwise you'll get a bootloop
Likely also install FakeStore, Aurora Store/F-Droid, and location backends of your choice, etc.
However: this is a simple solution to perhaps the most cumbersome aspect of signature spoofing. It's not necessary to resort to Xposed modules to get it working on Android 12, or to depend on a special build with the spoofing patched in at compilation time.
Credit: The patch .smali code has been reverse-engineered from the spoofing patch for LineageOS for MicroG builds.
Click to expand...
Click to collapse
I followed your steps for my OnePlus 8T on Lineage 19.1 and the signature spoofing app says disabled. When recompiling the system.jar with the new file copy and pasted in classes 2 the new system.jar is smaller than the original. Perhaps there is the issue with spoofing. Any information on this matter is much appreciated. Thank you for a great post btw.
Below is the attachment recompiled, perhaps some one else maybe interested in giving it a try or to just examine and find where the error may exist or to conclude it's my own error in recompiling.
JedidroidX said:
I followed your steps for my OnePlus 8T on Lineage 19.1 and the signature spoofing app says disabled. When recompiling the system.jar with the new file copy and pasted in classes 2 the new system.jar is smaller than the original. Perhaps there is the issue with spoofing. Any information on this matter is much appreciated. Thank you for a great post btw.
Below is the attachment recompiled, perhaps some one else maybe interested in giving it a try or to just examine and find where the error may exist or to conclude it's my own error in recompiling.
Click to expand...
Click to collapse
Don't use signature spoofing app. The only relevant measure of success is microG self-check. Use an installer to make microG a system app.
JedidroidX said:
I followed your steps for my OnePlus 8T on Lineage 19.1 and the signature spoofing app says disabled. When recompiling the system.jar with the new file copy and pasted in classes 2 the new system.jar is smaller than the original. Perhaps there is the issue with spoofing. Any information on this matter is much appreciated. Thank you for a great post btw.
Below is the attachment recompiled, perhaps some one else maybe interested in giving it a try or to just examine and find where the error may exist or to conclude it's my own error in recompiling.
Click to expand...
Click to collapse
I don't see any attachment (seems you edited your post) but I guess you recompiled it fine. If you didn't, the device would have ended up in a bootloop (Zygote process wouldn't start), so you'd definitely know. It should be services.jar though, not * system.jar, so maybe you didn't install it properly? Smaller file size is expected, since the repackaged version uses stronger compression as a ZIP file, so nothing to worry about. Again, if there's any problem with the modified services.jar, the device wouldn't get past the boot animation.
I'm not sure what you mean exactly by "signature spoofing app says disabled." It's not an actual app: it doesn't have any code, and won't show up in Launcher. Its only purpose is to add this permission. That being said, if you go into: Settings → Apps → See all ... apps → ⋮ → Show system → Signature Spoofing, there should be a button saying Disable (meaning it's enabled now), and not Enable (which would mean it were disabled at the time). Also, if you go further from that screen into Permissions → Additional permissions → Signature spoofing it should say Allow for this app, and when you click See all apps with this permission, it should show microG Services Core there as Allowed. If you set it up well this is all done automatically with the configuration files, you shouldn't have to go through the settings to change anything via the UI.
As I wrote in the original post, additional steps are required to fully set up MicroG, which is really outside the scope of this thread. These are, for the most part, the same steps as if you were using oF2pks's patch for Android 11 with Lanchon's DexPatcher except more recently you also have to add android.permission.MANAGE_USB to com.gooogle.android.gms (that is, MicroG Services Core) privapp-permissions, or you'll end up with a bootloop for a wholly different reason.
This topic is vast, and there are multiple ways to do it. Note that these should be installed as system apps, some of them as priv-apps, so there are many things that can go wrong. If you don't grant a priv-app all the required permissions through the configuration, now (as of Android 9 I think) you'll get a bootloop. For system apps, you also have to extract libraries (if any) from APKs and place them separately on the filesystem, and make sure you get the details right for the architecture: if you don't, you get... guess what (a bootloop). It's good to have a script automating all this: I have my own flashable ZIP specific to my needs but there are other more general solutions. Or, if you want to learn how to do this manually, one way would be to compare a vanilla LineageOS image with LineageOS for MicroG for the same device around the same build date and see what they are doing extra. On Windows you can use WinMerge to compare files and entire directory structures easily. But again, this is really outside the scope of this thread, which is about patching services.jar for signature spoofing support. No matter how you implement signature spoofing, you still have to figure out those other steps separately.
kurtn said:
Don't use signature spoofing app.
Click to expand...
Click to collapse
Actually, with this approach, Signature Spoofing app has to be used. This is to keep the patch as lean as possible (since it's easier to install a separate app rather than keep maintaining a more complicated patch).
It's not needed with LineageOS for MicroG, where it's already incorporated into the system (lines 1-82 in the patch): https://github.com/lineageos4microg...atches/android_frameworks_base-S.patch#L1-L82
Aqq123 said:
I don't see any attachment (seems you edited your post) but I guess you recompiled it fine. If you didn't, the device would have ended up in a bootloop (Zygote process wouldn't start), so you'd definitely know. It should be services.jar though, not * system.jar, so maybe you didn't install it properly? Smaller file size is expected, since the repackaged version uses stronger compression as a ZIP file, so nothing to worry about. Again, if there's any problem with the modified services.jar, the device wouldn't get past the boot animation.
I'm not sure what you mean exactly by "signature spoofing app says disabled." It's not an actual app: it doesn't have any code, and won't show up in Launcher. Its only purpose is to add this permission. That being said, if you go into: Settings → Apps → See all ... apps → ⋮ → Show system → Signature Spoofing, there should be a button saying Disable (meaning it's enabled now), and not Enable (which would mean it were disabled at the time). Also, if you go further from that screen into Permissions → Additional permissions → Signature spoofing it should say Allow for this app, and when you click See all apps with this permission, it should show microG Services Core there as Allowed. If you set it up well this is all done automatically with the configuration files, you shouldn't have to go through the settings to change anything via the UI.
As I wrote in the original post, additional steps are required to fully set up MicroG, which is really outside the scope of this thread. These are, for the most part, the same steps as if you were using oF2pks's patch for Android 11 with Lanchon's DexPatcher except more recently you also have to add android.permission.MANAGE_USB to com.gooogle.android.gms (that is, MicroG Services Core) privapp-permissions, or you'll end up with a bootloop for a wholly different reason.
This topic is vast, and there are multiple ways to do it. Note that these should be installed as system apps, some of them as priv-apps, so there are many things that can go wrong. If you don't grant a priv-app all the required permissions through the configuration, now (as of Android 9 I think) you'll get a bootloop. For system apps, you also have to extract libraries (if any) from APKs and place them separately on the filesystem, and make sure you get the details right for the architecture: if you don't, you get... guess what (a bootloop). It's good to have a script automating all this: I have my own flashable ZIP specific to my needs but there are other more general solutions. Or, if you want to learn how to do this manually, one way would be to compare a vanilla LineageOS image with LineageOS for MicroG for the same device around the same build date and see what they are doing extra. On Windows you can use WinMerge to compare files and entire directory structures easily. But again, this is really outside the scope of this thread, which is about patching services.jar for signature spoofing support. No matter how you implement signature spoofing, you still have to figure out those other steps separately.
Click to expand...
Click to collapse
Yes sir, I meant the services.jar, silly me I was writing in a rush. Sorry about that confusion.
I will try again and post the result. I guess I will use the same services.jar, however the issue with optimization. I did reboot several times after flashing a cache optimization module for magisk after I adb the services.jar because I'm not familiar on how to do the optimization manually.
The optimization module did lead to magisk not loading the modules and only booted successfully due to magisk bootloop protector module.
Also to adjust permissions to 644 I presume is already in the recompiled services.jar? As I could not view what permission with mixplorer that it had.
Btw, the signature spoofing app is an app I downloaded from f- droid that just displays the signature spoofing status, if disabled or enabled and it says disabled. Again sorry about the confusing and thank you again for your great feedback.
Hi,
would like to try on AOSP 12 GSI, installed over stock OOS10 On Nord (avicii).
@Aqq123 Do you think i can make it ? Any suggestion before starting ?
What about if i get service.jar from a GSI AOSP with google apps ? Maybe signature spoofing is altredy implemented there ?
kidronvalley said:
Hi,
would like to try on AOSP 12 GSI, installed over stock OOS10 On Nord (avicii).
@Aqq123 Do you think i can make it ? Any suggestion before starting ?
What about if i get service.jar from a GSI AOSP with google apps ? Maybe signature spoofing is altredy implemented there ?
Click to expand...
Click to collapse
Most gsi have signature spoofing feature.
Hi @kurtn
thanks,
heh, this AOSP 12 vanilla from PHH treble seems not, at least, microg is not detecting it, and one specific banking app is failing to work.
EDITED: I solved all installing PHH trebvle A12 "floss" that has signature spoofing up and running.
hi, @Aqq123 i applied the guide you wrote for lineage os 19.1 s10e (or so I think),
your attached:
I opened the PackageManagerService$ComputerEngine.smali file with notepad++,
.method private static applyFakeSignature(Lcom/android/server/pm/parsing/pkg/AndroidPackage;Landroid/content/pm/PackageInfo;Ljava/util/SetLandroid/content/pm/PackageInfo;
.method private static getRequestedFakeSignature(Lcom/android/server/pm/parsing/pkg/AndroidPackageLjava/lang/String;
I copied the code to where it says .end method and pasted it anywhere in my services.jar.
I deleted the next text where it says generatePackageInfo( and added the code that says applyFakeSignature( after it), and saved it and repackaged it as you said above.
I put it in the phone's memory and gave rw r r permissions in the system fremework with root explorer and restarted it. but the system went into bootloop.
I did a lineage os install from scratch after failing here.
I copied the PackageManagerService$ComputerEngine.smali file you provided,
I deleted the original PackageManagerService$ComputerEngine.sma in services.jar.
I pasted yours and repackaged it with the packaging code you wrote above (only apktool2 does not work for me, it works as apktool, does that cause the problem?) and I added the system to fremework and restarted the device once the device turned on but micro g and spoofing checker apk shows signature patch not applied .
and on the 2nd reboot, it naturally enters the bootloop as you said.
i didn't understand how to implement the following path, if i did that it wouldn't go into bootloop.
QUOTE: You have to generate the optimization files and place them in the correct location, which is /system/framework/oat/arm64/:
dex2oat --dex-file=/system/framework/services.jar --instruction-set=arm64 --oat-file=/system/framework/oat/arm64/services.odex
now i have 3 questions:
1. why did my patch to original smali fail (bootloop even on first boot)?
2. Why isn't the smali file you provided spoofing?
3. The file you gave does not bootloop the 1st time, but it does it for the 2nd time. What should I do to fully understand the above fix code?
ahmadmahmood2048 said:
hi, @Aqq123 i applied the guide you wrote for lineage os 19.1 s10e (or so I think),
your attached:
I opened the PackageManagerService$ComputerEngine.smali file with notepad++,
.method private static applyFakeSignature(Lcom/android/server/pm/parsing/pkg/AndroidPackage;Landroid/content/pm/PackageInfo;Ljava/util/SetLandroid/content/pm/PackageInfo;
.method private static getRequestedFakeSignature(Lcom/android/server/pm/parsing/pkg/AndroidPackageLjava/lang/String;
I copied the code to where it says .end method and pasted it anywhere in my services.jar.
I deleted the next text where it says generatePackageInfo( and added the code that says applyFakeSignature( after it), and saved it and repackaged it as you said above.
I put it in the phone's memory and gave rw r r permissions in the system fremework with root explorer and restarted it. but the system went into bootloop.
I did a lineage os install from scratch after failing here.
I copied the PackageManagerService$ComputerEngine.smali file you provided,
I deleted the original PackageManagerService$ComputerEngine.sma in services.jar.
I pasted yours and repackaged it with the packaging code you wrote above (only apktool2 does not work for me, it works as apktool, does that cause the problem?) and I added the system to fremework and restarted the device once the device turned on but micro g and spoofing checker apk shows signature patch not applied .
and on the 2nd reboot, it naturally enters the bootloop as you said.
i didn't understand how to implement the following path, if i did that it wouldn't go into bootloop.
QUOTE: You have to generate the optimization files and place them in the correct location, which is /system/framework/oat/arm64/:
dex2oat --dex-file=/system/framework/services.jar --instruction-set=arm64 --oat-file=/system/framework/oat/arm64/services.odex
now i have 3 questions:
1. why did my patch to original smali fail (bootloop even on first boot)?
2. Why isn't the smali file you provided spoofing?
3. The file you gave does not bootloop the 1st time, but it does it for the 2nd time. What should I do to fully understand the above fix code?
Click to expand...
Click to collapse
Use lineage.microg.org

[Firefly] [ROCKCHIP] 3.5-Month UPDATE: Firefly ITX-3588J (Rockchip RK3588) "Deskphone" WORKS! Almost.

After 3.5 months of trial and error, unresponsive communities, ups and down, spending $75 on a video card that may be proving unnecessary ... I finally present to you - an almost fully-working Firefly ITX-3588J Dual-Boot Android/Linux ARM Machine.
WHAT IS IT?
The Firefly ITX-3588J is a Mini-ITX - small PC form-factor - "single-board computer" that was released earlier this year by the Chinese manufacturer Firefly, aka. T-Chip Intelligent Technology Co. Ltd.. It features the Rockchip RK3588 (hence the name) ARM system-on-chip (SoC) in a package that adduces many different kinds of ports including a PCI Express x4 slot, multiple HDMI video outs that go to the on-chip Mali GPU, and an M.2 that can be used in theory to add a telephone network card, making it a mini-desktop and smartphone all in one.
I got one because I saw it as an opportunity to for once have an easily-transportable low-energy consumption system that would be both an alternative to x86 and also not the Mac while still offering reasonable performance even if far from top-of-the-line - and ideally, it'd be great if more such boards come later because other ARM SBC boards tend to be both more limited and also very awkward with their cables. This is the only one I'm aware of, besides certain Raspberry Pi breakout boards like the Turing Pi, that can use a standard PC case.
But getting it to work, on the other hand, proved to be MUCH more diifficult because while the vendors offered a choice between Android 12 and Ubuntu 20.04 operating systems, I realized I needed both: I wanted access to both software ecosystems on the same machine, and was determined to get that to happen. And I want to say that within the last few days I have finally come quite close to achieving this dream in full.
WHAT DOES IT DO NOW?
Right now, the machine dual-boots Android 12 and Ubuntu 20.04 using the vendor-provided patched 5.10.66 Linux kernel source tree, with the user-space data of both OSes stored on a SATA SSD hard disk instead of the embedded eMMC. Boot selection is possible on startup simply by hitting "Ctrl+C" and typing the appropriate command to select the Ubuntu OS; otherwise, Android 12 boots by default. All this happens by video console on U-Boot with no serial port requirement, making it function as a proper stand-alone dual-boot ARM PC.
WHAT IS STILL TO BE DONE?
Graphics support on Ubuntu 20.04. No idea why this isn't working even with the provided kernel and driver packages. Text console over monitor works fine, though.
WHAT DID IT TAKE TO MAKE IT GO?
In retrospect, it's not really all that difficult. The most difficult part was just figuring everything out because there was very little comprehensive documentation given beyond how to simply load the images, and I had before this point zero real experience actually piecing together an Android system on a mobile/embedded-style board and machine. One thing that's a casualty is the stock Ubuntu image; it turned out to be much more fruitful to simply install the system to the hard drive via a procedure analogous to, albeit having to be arranged manually, what a typical installer would do, i.e. setting up and using APT to load the whole Ubuntu system from the Internet over wi-fi with the only vendor-adulterated component being the kernel and Mali graphics drivers because Valhall, nor even the whole RK3588, is currently mainlined in the Linux kernel system.
WHAT DOES IT LOOK LIKE?
The machine:
{
"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"
}
Running Android:
Ubuntu (no graphics yet!):
@Shimmy99 Would you please offer the procedure you used to make the board boot from SATA SSD?
That would be greatly apprecaited. I have a similar board and I have been interested in installing Android on a SATA SSD but the vendors don't respond to messages and there is very little information on their forum.
Thank you
qwestmogul2012 said:
@Shimmy99 Would you please offer the procedure you used to make the board boot from SATA SSD?
That would be greatly apprecaited. I have a similar board and I have been interested in installing Android on a SATA SSD but the vendors don't respond to messages and there is very little information on their forum.
Thank you
Click to expand...
Click to collapse
Mmm. I don't have a direct boot from SSD possible yet. Getting it to this stage has required coding work on the provided U-Boot and I would share a source pack to my github but it will take more to get direct SATA boot because it crashes when the U-Boot is compiled with those config options enabled for some reason. My focus mostly was on getting graphical console on the U-Boot so that there is not need to use the serial debug simply to switch OSes ). The way it works currently is that the kernels for both Android and Ubuntu are loaded to the eMMC, then the userdata / rootfs are loaded to the SSD. That said, I could try to play with that for sure.
It would really be nice if there was an easy way to install OS on SSD drive,that would be a massive upgrade from the measly 128GB EMMC.
By the way I don't know if you have already figured this out but there is an easy way to install GAPPS without using the tedious method you used.
You simply patch boot.img with Magisk then use ADB to install it back to the unit. From there you can use Magisk to install Magisk GAPPS.
For the life of me I can't seem to figure out how to install GPS/GNSS drivers for Android. The stock firmwares provided by the vendor have GPS drivers but those stock firmware have 1920x1080 resolution whereas I want to use 3840x2160 screen.
One way of dealing with that is editing build.prop file in vendor folder which works but then the unit won't boot past boot screen when a patched boot.img is installed. so it is sort of catch 22.
qwestmogul2012 said:
It would really be nice if there was an easy way to install OS on SSD drive,that would be a massive upgrade from the measly 128GB EMMC.
By the way I don't know if you have already figured this out but there is an easy way to install GAPPS without using the tedious method you used.
You simply patch boot.img with Magisk then use ADB to install it back to the unit. From there you can use Magisk to install Magisk GAPPS.
For the life of me I can't seem to figure out how to install GPS/GNSS drivers for Android. The stock firmwares provided by the vendor have GPS drivers but those stock firmware have 1920x1080 resolution whereas I want to use 3840x2160 screen.
One way of dealing with that is editing build.prop file in vendor folder which works but then the unit won't boot past boot screen when a patched boot.img is installed. so it is sort of catch 22.
Click to expand...
Click to collapse
Thanks. Yes. I am currently working on trying to build up a software system that will enable proper booting from SSD "due to popular demand" from here (basically trying to modify the provided "RK U-Boot" and/or combine it with GRUB), however my progress has been set back after having lost the FIQ serial debug converter for my board and needing to get a new one. Also, I didn't know about that trick with Magisk, thanks! And when you say "won't boot past boot screen", what do you mean? Do you have any logs from the USB or from the FIQ serial stream for when that happens?
After the patched boot file is loaded back into the unit using ADB,the unit simply shows Firefly logo,the screen goes black then it shows the same logo,it never goes past that logo.
In other words I want a unit that has a patched boot file so that I can root it with Magisk and also have 4K resolution which only attainable by editing the build.prop file.
The root that is already in the stock firmware is inadequate because they lack SU binaries and therefore most apps that require root permission don't work effectively.
I have no way of generating logs,I don't have a serial debugger.
My goal is to have a simple Android system that I can install in my car with 4K portable screens and GPS.
I have tried the Android radios being sold out there and don't meet my needs for a system that can use 4K screens.They are still stuck in 1920x1080 or below resolution,not to mention that they can't play 4K video files without stuttering or freezing. They also lack storage that can store those large files.
qwestmogul2012 said:
After the patched boot file is loaded back into the unit using ADB,the unit simply shows Firefly logo,the screen goes black then it shows the same logo,it never goes past that logo.
In other words I want a unit that has a patched boot file so that I can root it with Magisk and also have 4K resolution which only attainable by editing the build.prop file.
The root that is already in the stock firmware is inadequate because they lack SU binaries and therefore most apps that require root permission don't work effectively.
I have no way of generating logs,I don't have a serial debugger.
My goal is to have a simple Android system that I can install in my car with 4K portable screens and GPS.
I have tried the Android radios being sold out there and don't meet my needs for a system that can use 4K screens.They are still stuck in 1920x1080 or below resolution,not to mention that they can't play 4K video files without stuttering or freezing. They also lack storage that can store those large files.
Click to expand...
Click to collapse
Wow, that is some really interesting use of this device. Are you able to capture anything via the debug serial interface? (TTL serial, port is called "DEBUG" on the board, it appears to be the preferred serial interface for this processor.) If you don't have a suitable TTL->USB converter, you might want to get one. It must be able to support 1500000 baud, though, so be careful to check. Firefly offers one, though I lost mine as I mentioned and I had to get another, though a different one so I can mount it permanently in the case and break out a back-of-the-case port.
If you can capture anything via the TTL serial line, that would be great. That should give you some idea of what it's choking on. Send me that just so I can think about it while I'm waiting on this.
I will definitely order one.I never thought I would hit such a roadblock.I have edited various kind of Android roms successfully.This one from Firefly though is something else.I suppose that is what happens when they make their work not open source.
By the way do you know how to unpack super.img? the unpack script provide does not recognize super.img even if I change the name to update.img
qwestmogul2012 said:
I will definitely order one.I never thought I would hit such a roadblock.I have edited various kind of Android roms successfully.This one from Firefly though is something else.I suppose that is what happens when they make their work not open source.
By the way do you know how to unpack super.img? the unpack script provide does not recognize super.img even if I change the name to update.img
Click to expand...
Click to collapse
Sorry for not responding sooner but I was diligently cracking away at this thing VERY much actually ... !!!
Ah yes, I think though I'm pretty close to getting it to work; most of the work so far has been in trying just to figure out how everything works given documentation is scant and I had never, ever worked with Android or anything else at this level before!
Very little of the material is not opensource - some of the tools required to generate the rockchip images does not appear to be and there are some binary-blob kernel drivers, but a LOT more than one thinks is; you just have to ask Firefly for the "board SDK" and they will provide on request. Other than what I mentioned, the code in there is pretty much all licensed under GPL (hence why they have to give you that code, given they've made kernel modifications to support the RK3588 - apparently mainstream support is coming along but is still not primetime yet).
Nonetheless, I see you've unpacked the Android image ROM, so perhaps you already have that - if so, great. Hence let's get to it (note maybe you know some of this already but I also want to make this post useful for as many people as possible): super.img - which I'm actually playing with right now - is not Firefly magic, but is generic Android and has been mentioned before on this forum if you search for "super.img" here. It's a "super partition" that contains partitions.
Editing system.img inside super.img and flashing our modifications
I'm trying to modify my system.img (/system/build.prop) to include support for multi users. After struggling a lot, I've succeeded following your guide (that's an awesome work btw) to unpack, mount, modify, umount and repack super.img. Then...
forum.xda-developers.com
To unpack it you need to grab OTA Tools:
[GUIDE] OTA Tools LPUnpack
Please see this URL https://android.googlesource.com/platform/build.git/+/eec4a7cba4face3370acb6293ab357879920b467 and this for more information. Hi everyone. I'm surprised I havent seen a thread about ota tools yet and lpunpack. This zip file...
forum.xda-developers.com
and the way to do this is you should first use the program simg2img, which actually ships with Ubuntu as a package of the same name I believe. Suppose you're in the Linux terminal and working in the directory containing super.img. Create (if you haven't already) a directory to unpack it, e.g.
Code:
mkdir super_unpack
Then use simg2img to get a "raw" version:
Code:
simg2img super.img super.img.raw
then finally use the OTATools (replace the string "/path/to/otatools" with whatever, or put them on your PATH, or ...)
Code:
/path/to/otatools/lpunpack super.img.raw super_unpack/
and now you should have it fully unrolled into smaller .img files which will ACTUALLY mount. In particular, I needed this because product.img specifically seems to be the best place to load GApps into - they will both come up on first Android boot and they will be retained if you do an Android system reset ("reset to factory defaults").
Now REPACKING super.img ... that's the fun part!
I had actually managed to find the instructions to unpack the super.img and also managed to mount vendor.img which is where I wanted to make changes in modifying the build.prop file.
After repacking the super.img and flashing it using fastboot the Android did not boot.
I also managed to incorporate the super.img to a ROM but the Android did not boot as well.
My thinking is that Android 12 being a Dynamic partitioned rom does not allow any modification in the root system and that is why I have not had success making the Android boot.
It used to be so easy to do that on Android 10 but Android 11 and 12 are not.
Well,if someone manages to do it,I hope to understand how they did it.
As of now I am pretty much stuck with a vanilla rom which is very disconcerting considering how expensive the ITX-3588J is.
By the way I already have SDK which I have been using to make roms.
Please let me know if you manage to boot the Android using a repacked super.img
As always I am very grateful for your assistance. Happy Ney Year!
qwestmogul2012 said:
I had actually managed to find the instructions to unpack the super.img and also managed to mount vendor.img which is where I wanted to make changes in modifying the build.prop file.
After repacking the super.img and flashing it using fastboot the Android did not boot.
I also managed to incorporate the super.img to a ROM but the Android did not boot as well.
My thinking is that Android 12 being a Dynamic partitioned rom does not allow any modification in the root system and that is why I have not had success making the Android boot.
It used to be so easy to do that on Android 10 but Android 11 and 12 are not.
Well,if someone manages to do it,I hope to understand how they did it.
As of now I am pretty much stuck with a vanilla rom which is very disconcerting considering how expensive the ITX-3588J is.
By the way I already have SDK which I have been using to make roms.
Please let me know if you manage to boot the Android using a repacked super.img
As always I am very grateful for your assistance. Happy Ney Year!
Click to expand...
Click to collapse
Thanks. I did not see any mention about build.prop, though maybe you dropped that on another thread that wasn't in my notifications anymore.
You say the "Android did not boot". Do you have a adb dump? Do you have a serial (UART) debug dump (i.e. through the FIQ port)? Also, how are you repacking super.img? It is a tricky process as I mentioned at the end.
I did mention build.prop editing on my second comment of this thread.I initially tried to use root explorer file manager,that did not work.Then attempted to pull file from the system using ADB,edited it on my computer then pushed the edited file back to the system.That did not work either.
That is when I resorted to trying to edit it by unpacking the super.img.
I am still waiting to receive USB SERIAL debugger.
As for how I unpacked and repacked the super.img I used the instructions on the thread on this link
Editing system.img inside super.img and flashing our modifications
I'm trying to modify my system.img (/system/build.prop) to include support for multi users. After struggling a lot, I've succeeded following your guide (that's an awesome work btw) to unpack, mount, modify, umount and repack super.img. Then...
forum.xda-developers.com
Maybe this helps: https://forum.xda-developers.com/t/linux-porting-native-linux-to-galaxy-note9.3936077/
Somebody ported Linux to the Galaxy Note 9.

[GUIDE] Assurance Wireless KonnectONE Moxee m2160 (MH-T6000) Rooting Guide

Assurance Wireless
KonnectONE Moxee m2160
4G-LTE Smartphone
Model No. MH-T6000
{
"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"
}
Rooting Guide​
OVERVIEW:
This guide outlines simplified instructions for rooting the Assurance Wireless Moxee MH-T6000 4G-LTE smartphone. To cater this guide to new and inexperienced members, I have provided a stock boot image pre-patched with the Magisk v26.1 systemless root solution.
PREREQUISITES:
First and foremost, you need an unlocked bootloader. If your bootloader is not yet unlocked, complete that task and then return here. XDA hosts a plethora of how-to guides on standard bootloader unlocking. You will also need a Windows PC or laptop running the Minimal ADB & Fastboot Tools (link provided below). It should be noted that this guide can be carried out on a Mac or Linux computer as well; however, for purposes of this guide, I am focusing solely on a Windows setup. It is highly recommended that your device be running firmware build number MH-T6000V1.0.OB010, with the March 5, 2023 security patch level. As OTA updates are rolled out for this device, I will try to keep this guide updated with a patched boot image that corresponds with the latest firmware build.
Finally, you will need the factory supplied, or a quality equivalent USB-A to USB-C charging/syncing cable.
DISCLAIMER:
By proceeding further, you are assuming sole responsibility for the integrity and operability of your smartphone. Rooting your device is a task that carries with it the inherent risk of bricking or otherwise rendering your phone inoperable. While this guide has been thoroughly tested on my own device, you have been warned. Proceed at your own risk.
INSTRUCTIONS:​
Download the ADB & Fastboot tools from the link below and install the program on your PC or laptop;​
Open your Windows File Explorer, navigate to your C: drive, Program Files x86, and locate the Minimal ADB & Fastboot folder. Copy this folder and paste it to your desktop. (This step is not required, but is recommended for easier access of the ADB & Fastboot path);​
Download the patched boot image from the below link and save the image in your ADB & Fastboot folder. Note: the filename for the patched boot image is patched_boot.img. The flashing commands assume that you leave the filename unchanged;​
Boot your phone into fastboot mode by first powering your device off, and then holding the power and volume down keys simultaneously until fastboot mode appears on your device display;​
Connect your smartphone to your Windows computer using the factory supplied or a quality equivalent USB-A to USB-C charging/syncing cable;​
Open your ADB & Fastboot folder and double click cmd-here.exe to open a command window. Execute this command to verify a proper fastboot connection:
Code:
fastboot devices
If properly connected, the command window will return an alphanumeric string consistent with your device serial number;​
Once a proper connection has been verified, execute this command:
Code:
fastboot flash boot patched_boot.img
Now execute:
Code:
fastboot reboot
Upon reboot, open your app drawer and tap on the Magisk app or its placeholder stub. Ensure you are connected to the internet, grant any permissions, and follow any prompts given by Magisk to update to the full version in order to complete the root environment setup. Magisk may reboot your device during this process.​
That's it. You're now rooted via the Magisk v26.1 systemless root solution.​
IMPORTANT NOTE:
In the unfortunate event that you get stuck in a boot loop or brick your device using this guide, my guide on unbricking this smartphone will get you back up and running fairly quickly. This guide can be used to restore both soft bricked and hard bricked devices. You can then return here and give rooting another go.
Moxee MH-T6000 Unbricking Guide​DOWNLOADS:
• Minimal ADB & Fastboot v1.4.3
• Magisk Patched Boot Image
THANKS & MENTIONS:
A huge thanks and shout-out to @omb714.1980 for donating the Moxee smartphone that made this rooting guide possible. You are a scholar and a gentleman, good sir. Thanks also to KonnectONE support specialist Faith Flores for releasing to me the factory firmware for this device.​
Viva La Android said:
Assurance Wireless
Moxee MH-T6000 4G-LTE
View attachment 5893661
Rooting Guide​
OVERVIEW:
This guide outlines simplified instructions for rooting the Assurance Wireless Moxee MH-T6000 4G-LTE smartphone. To cater this guide to new and inexperienced members, I have provided a stock boot image pre-patched with the Magisk v26.1 systemless root solution.
PREREQUISITES:
First and foremost, you need an unlocked bootloader. If your bootloader is not yet unlocked, complete that task and then return here. You will also need a Windows PC or laptop running the Minimal ADB & Fastboot Tools (link provided below). It should be noted that this guide can be carried out on a Mac or Linux computer as well; however, for purposes of this guide, I am focusing solely on a Windows setup. It is highly recommended that your device be running firmware build number MH-T6000V1.0.OB010, with the March 5, 2023 security patch level. Finally, you will need the factory supplied, or a quality equivalent USB-A to USB-C charging/syncing cable.
DISCLAIMER:
By proceeding further, you are assuming sole responsibility for the integrity and operability of your smartphone. Rooting your device is a task that carries the inherent risk of bricking or otherwise rendering your phone inoperable. While this guide has been thoroughly tested on my own device, you have been warned. Proceed at your own risk.
INSTRUCTIONS:​
Download the ADB & Fastboot tools from the link below and install the program on your PC or laptop;​
Open your Windows File Explorer, navigate to your C: drive, Program Files x86, and locate the Minimal ADB & Fastboot folder. Copy this folder and paste it to your desktop. (This step is not required, but is recommended for easier access of the ADB & Fastboot path);​
Download the patched boot image from the below link and save the image in your ADB & Fastboot folder;​
Boot your phone into fastboot mode by first powering your device off, and then holding the power and volume down keys simultaneously until fastboot mode appears on your device display;​
Connect your smartphone to your Windows computer using the factory supplied or a quality equivalent USB-A to USB-C charging/syncing cable;​
Open your ADB & Fastboot folder and double click cmd-here.exe to open a command window. Execute this command to verify a proper fastboot connection:
Code:
fastboot devices
If properly connected, the command window will return an alphanumeric string consistent with your device serial number;​
Once a proper connection has been verified, execute this command:
Code:
fastboot flash boot patched_boot.img
Now execute:
Code:
fastboot reboot
Upon reboot, open your app drawer and tap on the Magisk app or its placeholder stub. Ensure you are connected to the internet, grant any permissions, and follow any prompts given by Magisk to update to the full version in order to complete the root environment setup. Magisk may reboot your device during this process.​
That's it. You're now rooted via the Magisk v26.1 systemless root solution.​
DOWNLOADS:
• Minimal ADB & Fastboot v1.4.3
• Magisk Patched Boot Image
THANKS & MENTIONS:
A huge thanks and shout-out to @omb714.1980 for donating the Moxee smartphone that made this rooting guide possible. You are a scholar and a gentleman, good sir. Thanks also to the KonnectONE support team for releasing to me the factory firmware for this device.​
Click to expand...
Click to collapse
Lol. Now you post this. After unsuccessfully scouring the internet for the stock firmware. I finally did the same as you and simply reached out to konnectone and asked for it. I just came here to see if there was anyone here that is by far more knowledgeable than myself (not hard) interested to have the firmware and would post a guide like this one. Well done!
Would you happen to have a twrp recovery compiled for this device by chance? Or if not but planning on it would you let me know please. I would appreciate it!
scottfan81 said:
Lol. Now you post this. After unsuccessfully scouring the internet for the stock firmware. I finally did the same as you and simply reached out to konnectone and asked for it. I just came here to see if there was anyone here that is by far more knowledgeable than myself (not hard) interested to have the firmware and would post a guide like this one. Well done!
Would you happen to have a twrp recovery compiled for this device by chance? Or if not but planning on it would you let me know please. I would appreciate it!
Click to expand...
Click to collapse
I just got KonnectONE to agree to release firmware a couple of days before you mentioned having firmware. It's been a long wait indeed.
I don't have source code to compile TWRP; only the firmware. I will be attempting to port a TWRP build for this phone very soon. My legal battle with KonnectONE was in regards to source code under the General Public License 2.0. Because they were ultimately unable to provide kernel source, their legal team and support department finally acquiesced to provide firmware to device owners upon written request. I compromised for the firmware release, but was not able to get kernel source code for building TWRP. I am pretty confident that a ported TWRP can be ironed out as a stable build. I already have the base build selected.
Thank you so much! I have 3 of these devices and been waiting lol. I see the stock kernel has hot-plug . What's some good tuning profiles? I tried to debloat permanently with LP but it didn't work. I think it's read-only so I flashed the magisk overlay for rw and going to play. We definitely need TWRP! I see a port may be in the works. Awesome. Thanks again
Viva La Android said:
I just got KonnectONE to agree to release firmware a couple of days before you mentioned having firmware. It's been a long wait indeed.
I don't have source code to compile TWRP; only the firmware. I will be attempting to port a TWRP build for this phone very soon. My legal battle with KonnectONE was in regards to source code under the General Public License 2.0. Because they were ultimately unable to provide kernel source, their legal team and support department finally acquiesced to provide firmware to device owners upon written request. I compromised for the firmware release, but was not able to get kernel source code for building TWRP. I am pretty confident that a ported TWRP can be ironed out as a stable build. I already have the base build selected.
Click to expand...
Click to collapse
They never replied when I emailed them about it several months ago . This is so awesome. I got rid of most of the lag with kernel manager. Kudos
Argonon said:
They never replied when I emailed them about it several months ago . This is so awesome. I got rid of most of the lag with kernel manager. Kudos
Click to expand...
Click to collapse
Several months ago they weren't releasing firmware to the public. I got it released by battling with them over open source code and I ultimately compromised for factory firmware. It was only recently made public.
Yeah I've noticed a nice performance boost too with some debloating and sone kernel tweaks. I'm using EX Kernel Manager. Keep in mind this device uses dynamic partitioning (super.img). As such, even with root, it isn't always possible to mount /system r/w. I extracted the super.img on a PC and then mounted /system, /vendor and /product, debloated, and then repacked and reflashed super img.
Awesome. I don't have a good pc now unfortunately. I do have viper4android repackaged version with driver and effects pre-installed. I used smart pack kernel manager to tweak kernel. The device is very useable now! I have a Blu View 3 android 11 mtk device id love to root but can't even unlock bootloader. Maybe I should look into emailing them
Argonon said:
Awesome. I don't have a good pc now unfortunately. I do have viper4android repackaged version with driver and effects pre-installed. I used smart pack kernel manager to tweak kernel. The device is very useable now! I have a Blu View 3 android 11 mtk device id love to root but can't even unlock bootloader. Maybe I should look into emailing them
Click to expand...
Click to collapse
BLU won't unlock your bootloader. It is locked per contractual agreement with the branded carrier of the phone. However, if it's MediaTek, you may be able to use MTK Client to exploit the bootloader into an unlocked state.
Viva La Android said:
Several months ago they weren't releasing firmware to the public. I got it released by battling with them over open source code and I ultimately compromised for factory firmware. It was only recently made public.
Yeah I've noticed a nice performance boost too with some debloating and sone kernel tweaks. I'm using EX Kernel Manager. Keep in mind this device uses dynamic partitioning (super.img). As such, even with root, it isn't always possible to mount /system r/w. I extracted the super.img on a PC and then mounted /system, /vendor and /product, debloated, and then repacked and reflashed super img.
Click to expand...
Click to collapse
Would you plz share your super.img ? I'm on latest firmware and have attached screenshot of build etc.... I understand if you can't or don't want to. Can I pull mine since I'm rooted? Problem is I have a old Chromebook that I installed endeavor os on its arch based Linux but I don't have much hard drive space to do work
Viva La Android said:
Several months ago they weren't releasing firmware to the public. I got it released by battling with them over open source code and I ultimately compromised for factory firmware. It was only recently made public.
Yeah I've noticed a nice performance boost too with some debloating and sone kernel tweaks. I'm using EX Kernel Manager. Keep in mind this device uses dynamic partitioning (super.img). As such, even with root, it isn't always possible to mount /system r/w. I extracted the super.img on a PC and then mounted /system, /vendor and /product, debloated, and then repacked and reflashed super img.
Click to expand...
Click to collapse
Would you plz share your super.img ? I'm on latest firmware and have attached screenshot of build etc.... I understand if you can't or don't want to. Can I pull mine since I'm rooted? Problem is I have a old Chromebook that I installed endeavor os on its arch based Linux but I don't have much hard drive space to do work
Viva La Android said:
I just got KonnectONE to agree to release firmware a couple of days before you mentioned having firmware. It's been a long wait indeed.
I don't have source code to compile TWRP; only the firmware. I will be attempting to port a TWRP build for this phone very soon. My legal battle with KonnectONE was in regards to source code under the General Public License 2.0. Because they were ultimately unable to provide kernel source, their legal team and support department finally acquiesced to provide firmware to device owners upon written request. I compromised for the firmware release, but was not able to get kernel source code for building TWRP. I am pretty confident that a ported TWRP can be ironed out as a stable build. I already have the base build selected.
Click to expand...
Click to collapse
I have 3 of these devices. I surly can test TWRP port if needed
Argonon said:
Would you plz share your super.img ? I'm on latest firmware and have attached screenshot of build etc.... I understand if you can't or don't want to. Can I pull mine since I'm rooted? Problem is I have a old Chromebook that I installed endeavor os on its arch based Linux but I don't have much hard drive space to do work
I have 3 of these devices. I surly can test TWRP port if needed
Click to expand...
Click to collapse
Sure. I don't mind sharing my super.img. I'll need to upload it and then I'll message you a link. It's pretty much exactly 2.5 GB in file size, so I'll first compress it to a zip before uploading.
The edited one. Just clarifying so appreciated
Argonon said:
The edited one. Just clarifying so appreciated
Click to expand...
Click to collapse
I don't yet have all my mods made to the /super partition in that regard. Having encountered some force close issues with certain apps, I debloated from scratch and and have now begun my kernel tweaks and edits to the.varuous .prop files. So when finished, I'll share both my boot.img and super.img.
Just the stock super.img would be fine then. I think I can figure how to decompile, debloat and recompile then flash.
Argonon said:
Just the stock super.img would be fine then. I think I can figure how to decompile, debloat and recompile then flash.
Click to expand...
Click to collapse
MH-T6000 super.img unmodified
I was experimenting and flashed the super.img with dsu side loader apk as a gsi lol. The app description said can replace various partitions and I was just trying to get system rw on the dsu loader. I know that makes no sense. What windows 11 compatible software do you recommend to unpack, repack etc? I see a few magisk modules but not quite sure how to use. Like ro2rw magisk module
Viva La Android said:
MH-T6000 super.img unmodified
Click to expand...
Click to collapse
Thank you!
Argonon said:
Thank you!
Click to expand...
Click to collapse
When I have completed debloating, kernel tweaks and .prop files edits of the OS, I'll share my modified super.img and boot.img. I have a TWRP v3.6.0 port build that is currently booting properly on this phone. But, I have bugs to work out on logical partition mounting, as well as the backup & restore functionality.
Argonon said:
I was experimenting and flashed the super.img with dsu side loader apk as a gsi lol. The app description said can replace various partitions and I was just trying to get system rw on the dsu loader. I know that makes no sense. What windows 11 compatible software do you recommend to unpack, repack etc? I see a few magisk modules but not quite sure how to use. Like ro2rw magisk module
Click to expand...
Click to collapse
Check out CRB Android Kitchen here on XDA. Great for unpacking / repacking partition images, including super.img.
Viva La Android said:
When I have completed debloating, kernel tweaks and .prop files edits of the OS, I'll share my modified super.img and boot.img. I have a TWRP v3.6.0 port build that is currently booting properly on this phone. But, I have bugs to work out on logical partition mounting, as well as the backup & restore
Click to expand...
Click to collapse
Have you had anymore luck with this

Categories

Resources