Related
AnyKernel3 -- Flashable Zip Template for Kernel Releases with Ramdisk Modifications
"AnyKernel is a template for an update.zip that can apply any kernel to any ROM, regardless of ramdisk." - Koush
The concept of AnyKernel has been around for awhile, (originally by Koushik Dutta/ClockworkMod,) which allowed a device-specific kernel zImage to be flashed over device-specific ROM and use the ramdisk that came with the ROM to reduce the chance of any issues arising from the custom kernel pairing.
The drawback to this was that some kernels require modifications to the ramdisk to enable/set up kernel features, and in the old AnyKernel format there was no way to do this. Enter AnyKernel2.
AnyKernel2 pushed the format even further by allowing kernel developers to modify the underlying ramdisk for kernel feature support easily using a number of included command methods along with properties and variables to customize the installation experience to their kernel. AnyKernel3 adds the power of topjohnwu's magiskboot for wider format support by default.
A script based on Galaxy Nexus (tuna) is included for reference. An example of ramdisk-only changes can be seen in my GN Synapse Injector repo. For an example that also modifies ROM and properly injects init.d support using busybox run-parts and sepolicy-inject see CosmicDan's CosmicTweaks project. For a multi-partition example and an example of how to handle a device which only has a ramdisk when rooted see my N5X/6P BLOD Workaround Injector. Other working AK2/3 examples for more recent devices may be found on eng.stk's blu_spark device repos under Releases.
Please see the linked posts here for instructions on enabling full AVBv1 (Pixel), AVBv1, A/B slot and/or system-as-root (SAR) or 2-stage init (2SI) device support, and further guidelines for system-as-root/2-stage init (/system/system in recovery) modifications in general.
Please also see the post here for important notes about the current state of AOSP vendor_boot v4 support and AVBv2 flag options.
Magisk root is automatically detected and retained by patching the new Image.*-dtb as Magisk would!
My development work on my many projects comes out of my free time, so if you enjoy this project or anything else I've done on xda, please consider sponsoring my ongoing work using my GitHub Sponsors profile. For a one-time donation you can hit the donate link from my profile. Thank you for your support!
Source: https://github.com/osm0sis/AnyKernel3/
Download: https://github.com/osm0sis/AnyKernel3/archive/master.zip
Instructions
1) Place final kernel build product, e.g. Image.gz-dtb or zImage to name a couple, in the zip root (any separate dt, dtb, recovery_dtbo, dtbo and/or vendor_dlkm should also go here for devices that require custom ones, each will fallback to the original if not included)
2) Place any required ramdisk files in /ramdisk (/vendor_ramdisk for simple multi-partition vendor_boot v3 support) and module files in /modules (with the full path like /modules/system/lib/modules)
3) Place any required patch files (generally partial files which go with AK3 file editing commands) in /patch (/vendor_patch for simple multi-partition vendor_boot v3 support)
4) Modify the anykernel.sh to add your kernel's name, boot partition location, permissions for any added ramdisk files, and use methods for any required ramdisk modifications (optionally, also place banner and/or version files in the root to have these displayed during flash)
5) `zip -r9 UPDATE-AnyKernel3.zip * -x .git -x .github README.md *placeholder`
The LICENSE file must remain in the final zip to comply with licenses for binary redistribution and the license of the AK3 scripts.
If supporting a recovery that forces zip signature verification (like Cyanogen Recovery) then you will need to also sign your zip using the method I describe here:
[DEV][TEMPLATE] Complete Shell Script Flashable Zip Replacement + Signing [SCRIPT]
Not required, but any tweaks you can't hardcode into the source (best practice) should be added with an additional init.tweaks.rc or bootscript.sh to minimize the necessary ramdisk changes. On newer devices Magisk allows these within /overlay.d - see examples.
It is also extremely important to note that for the broadest AK3 compatibility it is always better to modify a ramdisk file rather than replace it.
If running into trouble when flashing an AK3 zip, the suffix -debugging may be added to the zip's filename to enable creation of a debug .tgz of /tmp for later examination while booted or on desktop.
Staying Up-To-Date
Now that you've got a ready zip for your device, you might be wondering how to keep it up-to-date with the latest AnyKernel commits. AnyKernel2 and AnyKernel3 have been painstakingly developed to allow you to just drop in the latest update-binary and tools directory and have everything "just work" for beginners not overly git or script savvy, but the best practice way is as follows:
1) Fork my AnyKernel3 repo on GitHub
2) `git clone https://github.com/<yourname>/AnyKernel3`
3) `git remote add upstream https://github.com/osm0sis/AnyKernel3`
4) `git checkout -b <devicename>`
5) Set it up like your <devicename> zip (i.e. remove any folders you don't use like ramdisk or patch, delete README.md, and add your anykernel.sh and optionally your Image.*-dtb if you want it up there) then commit all those changes
6) `git push --set-upstream origin <devicename>`
7) `git checkout master` then repeat steps 4-6 for any other devices you support
Then you should be able to `git pull upstream master` from your master branch and either merge or cherry-pick the new AK3 commits into your device branches as needed.
Enjoy!
Questions, comments and feedback welcome.
Credits & Thanks: All authors of the included binaries and the tools I used to port them over for their amazing work. koush for the original AnyKernel concept.
Disclaimer: Naturally, you take all the responsibility for what happens to your device when you start messing around with things.
Script Commands Reference
Everything to edit is self-contained in anykernel.sh. A quick-reference for the commands and properties included are as follows.
Properties / Variables
These are some values that will be read during the install process, allowing you to customize your installation, e.g. block= is a shell variable to specify the kernel/boot block partition that the dump_boot command method will copy and unpack.
Code:
kernel.string=KernelName by YourName @ xda-developers
do.devicecheck=1
do.modules=1
do.systemless=1
do.cleanup=1
do.cleanuponabort=0
device.name1=maguro
device.name2=toro
device.name3=toroplus
device.name4=tuna
supported.versions=6.0 - 7.1.2
supported.patchlevels=2019-07 -
block=/dev/block/platform/omap/omap_hsmmc.0/by-name/boot;
is_slot_device=0;
ramdisk_compression=auto;
patch_vbmeta_flag=auto;
do.devicecheck=1 specified requires at least device.name1 to be present. This should match ro.product.device, ro.build.product, ro.product.vendor.device or ro.vendor.product.device from the build.prop files for your device. There is support for as many device.name# properties as needed. You may remove any empty ones that aren't being used.
do.modules=1 will push the .ko contents of the modules directory to the same location relative to root (/) and apply correct permissions. On A/B devices this can only be done to the active slot.
do.systemless=1 (with do.modules=1) will instead push the full contents of the modules directory to create a simple "ak3-helper" Magisk module, allowing developers to effectively replace system files, including .ko files. If the current kernel is changed then the kernel helper module automatically removes itself to prevent conflicts.
do.cleanup=0 will keep the zip from removing its working directory in /tmp/anykernel (by default) - this can be useful if trying to debug in adb shell whether the patches worked correctly.
do.cleanuponabort=0 will keep the zip from removing its working directory in /tmp/anykernel (by default) in case of installation abort.
supported.versions= will match against ro.build.version.release from the current ROM's build.prop. It can be set to a list or range. As a list of one or more entries, e.g. 7.1.2 or 8.1.0, 9 it will look for exact matches, as a range, e.g. 7.1.2 - 9 it will check to make sure the current version falls within those limits. Whitespace optional, and supplied version values should be in the same number format they are in the build.prop value for that Android version.
supported.patchlevels= will match against ro.build.version.security_patch from the current ROM's build.prop. It can be set as a closed or open-ended range of dates in the format YYYY-MM, whitespace optional, e.g. 2019-04 - 2019-06, 2019-04 - or - 2019-06 where the last two examples show setting a minimum and maximum, respectively.
block=auto instead of a direct block filepath enables detection of the device boot partition for use with broad, device non-specific zips. Also accepts any partition filename (from by-name), e.g. boot, recovery, or vendor_boot.
is_slot_device=1 enables detection of the suffix for the active boot partition on slot-based devices and will add this to the end of the supplied block= path. Also accepts auto for use with broad, device non-specific zips.
ramdisk_compression=auto allows automatically repacking the ramdisk with the format detected during unpack. Changing auto to gz, lzo, lzma, xz, bz2, lz4, or lz4-l (for lz4 legacy) instead forces the repack as that format, and using cpio or none will (attempt to) force the repack as uncompressed.
patch_vbmeta_flag=auto allows automatically using the default AVBv2 vbmeta flag on repack, and use the Magisk configuration (Canary 23016+). Set to 0 forces keeping whatever is in the original AVBv2 flags, and set to 1 forces patching the flag (only necessary on few devices).
customdd="<arguments>" may be added to allow specifying additional dd parameters for devices that need to hack their kernel directly into a large partition like mmcblk0, or force use of dd for flashing.
slot_select=active|inactive may be added to allow specifying the target slot. If omitted the default remains active.
no_block_display=1 may be added to disable output of the detected final used partition+slot path for zips which choose to include their own custom output instead.
Command Methods
Code:
ui_print "<text>" [...]
abort ["<text>" [...]]
contains <string> <substring>
file_getprop <file> <property>
set_perm <owner> <group> <mode> <file> [<file2> ...]
set_perm_recursive <owner> <group> <dir_mode> <file_mode> <dir> [<dir2> ...]
dump_boot
split_boot
unpack_ramdisk
backup_file <file>
restore_file <file>
replace_string <file> <if search string> <original string> <replacement string> <scope>
replace_section <file> <begin search string> <end search string> <replacement string>
remove_section <file> <begin search string> <end search string>
insert_line <file> <if search string> before|after <line match string> <inserted line>
replace_line <file> <line replace string> <replacement line> <scope>
remove_line <file> <line match string> <scope>
prepend_file <file> <if search string> <patch file>
insert_file <file> <if search string> before|after <line match string> <patch file>
append_file <file> <if search string> <patch file>
replace_file <file> <permissions> <patch file>
patch_fstab <fstab file> <mount match name> <fs match type> block|mount|fstype|options|flags <original string> <replacement string>
patch_cmdline <cmdline entry name> <replacement string>
patch_prop <prop file> <prop name> <new prop value>
patch_ueventd <ueventd file> <device node> <permissions> <chown> <chgrp>
repack_ramdisk
flash_boot
flash_generic <partition name>
write_boot
reset_ak [keep]
setup_ak
"if search string" is the string it looks for to decide whether it needs to add the tweak or not, so generally something to indicate the tweak already exists. "cmdline entry name" behaves somewhat like this as a match check for the name of the cmdline entry to be changed/added by the patch_cmdline function, followed by the full entry to replace it. "prop name" also serves as a match check in patch_prop for a property in the given prop file, but is only the prop name as the prop value is specified separately.
Similarly, "line match string" and "line replace string" are the search strings that locate where the modification needs to be made for those commands, "begin search string" and "end search string" are both required to select the first and last lines of the script block to be replaced for replace_section, and "mount match name" and "fs match type" are both required to narrow the patch_fstab command down to the correct entry.
"scope" may be specified as "global" to force all instances of the string/line targeted by replace_string, replace_line or remove_line to be replaced/removed accordingly. Omitted or set to anything else and it will perform the default first-match action.
"before|after" requires you simply specify "before" or "after" for the placement of the inserted line, in relation to "line match string".
"block|mount|fstype|options|flags" requires you specify which part (listed in order) of the fstab entry you want to check and alter.
dump_boot and write_boot are the default method of unpacking/repacking, but for more granular control, or omitting ramdisk changes entirely ("OG AK" mode), these can be separated into split_boot; unpack_ramdisk and repack_ramdisk; flash_boot respectively. flash_generic can be used to flash an image to the corresponding partition. It is automatically included for dtbo and vendor_dlkm in write_boot but can be called separately if using "OG AK" mode or creating a simple partition flashing only zip.
Multi-partition zips can be created by removing the ramdisk and patch folders from the zip and including instead "-files" folders named for the partition (without slot suffix), e.g. boot-files + recovery-files, or kernel-files + ramdisk-files (on some Treble devices). These then contain Image.gz, and ramdisk, patch, etc. subfolders for each partition. To setup for the next partition, simply set block= (without slot suffix) and ramdisk_compression= for the new target partition and use the reset_ak command.
Similarly, multi-slot zips can be created with the normal zip layout for the active (current) slot, then resetting for the inactive slot by setting block= to the partition (without slot suffix) again, slot_select=inactive and ramdisk_compression= to the desired options for the target slot and using the reset_ak keep command, which will retain the patch and any added ramdisk files for the next slot.
backup_file may be used for testing to ensure ramdisk changes are made correctly, transparency for the end-user, or in a ramdisk-only "mod" zip. In the latter case restore_file could also be used to create a "restore" zip to undo the changes, but should be used with caution since the underlying patched files could be changed with ROM/kernel updates.
You may also use ui_print "<text>" to write messages back to the recovery during the modification process, abort "<text>" to abort with optional message, and file_getprop "<file>" "<property>" and contains "<string>" "<substring>" to simplify string testing logic you might want in your script.
Binary Inclusion
The AK3 repo includes current ARM builds of magiskboot, magiskpolicy, lptools_static and busybox by default to keep the basic package small. Builds for other architectures and optional binaries (see below) are available from the latest Magisk zip, or my latest AIK-mobile and Flashlt packages, respectively, here:
https://forum.xda-developers.com/t/...kernel-ramdisk-win-android-linux-mac.2073775/ (Android Image Kitchen thread)
https://forum.xda-developers.com/t/...-and-ends-multiple-devices-platforms.2239421/ (Odds and Ends thread)
Optional supported binaries which may be placed in /tools to enable built-in expanded functionality are as follows:
mkbootfs - for broken recoveries, or, booted flash support for a script/app via bind mount to /tmp (deprecated/use with caution)
flash_erase, nanddump, nandwrite - MTD block device support for devices where the dd command is not sufficient
dumpimage, mkimage - DENX U-Boot uImage format support
mboot - Intel OSIP Android image format support
unpackelf, mkbootimg - Sony ELF kernel.elf format support, repacking as AOSP standard boot.img for unlocked bootloaders
elftool (with unpackelf) - Sony ELF kernel.elf format support, repacking as ELF for older Sony devices
mkmtkhdr (with unpackelf) - MTK device boot image section headers support for Sony devices
futility + chromeos test keys directory - Google ChromeOS signature support
boot_signer-dexed.jar + avb keys directory - Google Android Verified Boot 1.0 (AVBv1) signature support
rkcrc - Rockchip KRNL ramdisk image support
Optionally moving ARM builds to tools/arm and putting x86 builds in tools/x86 will enable architecture detection for use with broad, device non-specific zips.
Boom . dibs on first :good:
You get 2 thank button presses fro me lol
Awesome work man as always
Good thing that this amazing work has it's own thread. Congrats buddy.
Sent from my Galaxy Nexus using XDA Premium 4 mobile app
Thanks guys!
I figured it would be nice to get it out there and also have it as a "Help Desk" thread for kernel devs who have questions about implementation, etc. too. Some devices might require switching it from dd to MTD-Utils, so I can help with that. So on and so forth.
Once we get a few devs who know how to use it, it should be pretty easy to help others. I'm looking at you Smitty. No pressure.
I finished my thanks ... but as always a great job.
ak said:
I finished my thanks ... but as always a great job.
Click to expand...
Click to collapse
So wait im confused. ?.. so 1) those that mean I can flash ak kerenl 4.2 with ur any kernel to my 4.4 .
2) those it have to be same kerenl for same phone manufacturer. Meaning can I be stupid enought to flash a nexus 4 kernel in my gnexus?
I understand any kernel cause I have been using smitty so thanks
milojoseph said:
So wait im confused. ?.. so 1) those that mean I can flash ak kerenl 4.2 with ur any kernel to my 4.4 .
2) those it have to be same kerenl for same phone manufacturer. Meaning can I be stupid enought to flash a nexus 4 kernel in my gnexus?
I understand any kernel cause I have been using smitty so thanks
Click to expand...
Click to collapse
Haha I wrote "device-specific" in the OP to try and avoid this very confusion.
Since I answered this same question earlier tonight in my Odds and Ends thread I'll just paste it here:
caspboy said:
so now devs can use kernels from other devices with their roms?
Click to expand...
Click to collapse
osm0sis said:
No. That's crazy talk. :laugh:
The concept of AnyKernel has been around for awhile, (originally by Koushik Dutta/ClockworkMod,) which allows device-specific kernels to be flashed over device-specific ROMs and use the ramdisk that came with the ROM to reduce the chance of any issues arising from the custom kernel pairing.
The drawback to this is that some kernels require modifications to the ramdisk to enable/set up kernel features, but in the old AnyKernel format there was no way to do this. Until now.
AnyKernel 2.0 makes it easy for kernel devs to use a number of simple command methods to automate the process of adding tweaks into a ROM's underlying ramdisk during the flashing process. :good:
Click to expand...
Click to collapse
Hopefully that helps. Basically exactly what's in the OP since that's where I edited it in from.
The only way I can explain it any further is with the very basics: that kernel boot.img files contain a zImage and a ramdisk. "AnyKernel Classic" just slaps the custom kernel zImage on top of the ROM's untouched default kernel boot.img ramdisk. AnyKernel 2.0 allows kernel devs to also modify the ramdisk to add anything required for kernel features in addition to the usual repacking it with the custom zImage and flashing it.
Great thread!! Best of lucky bro!!!
Sent from my Galaxy Nexus using xda app-developers app
AnyKernel will work on my phone now ? Thanks for enhancing awesome @osm0sis but DrRamdisk to the rest of you guys ?
wow,thats very cool,great work.
Github updated with my own forked native compiles of mkbootimg+unpackbootimg.
This should expand AnyKernel 2.0 device support a lot by using all the available offsets in mkbootimg, as exported by my drastically updated unpackbootimg. :good:
osm0sis said:
Github updated with my own forked native compiles of mkbootimg+unpackbootimg.
This should expand AnyKernel 2.0 device support a lot by using all the available offsets in mkbootimg, as exported by my drastically updated unpackbootimg. :good:
Click to expand...
Click to collapse
Hi osm0sis,
Have You update anykernel 2.0 to work with cyanogen11 roms ? Thanks for Your hard work !
Should already?
It uses the ROM kernel ramdisk like AnyKernel always has. Your custom kernel dev just needs to use it. Spread the word. :good:
osm0sis said:
Should already?
It uses the ROM kernel ramdisk like AnyKernel always has. Your custom kernel dev just needs to use it. Spread the word. :good:
Click to expand...
Click to collapse
Recently I had used Your method on Cyano11 but boot stopped on "Google".. new Cyano11 (that required ramdisk changes) had just come out and maybe anykernel 2.0 was not ready yet (I had just discovered your brillant work on It ! : Dita incrociate.
I'll try again ... if I have trouble going to ask you for help ...
I am already spreading the word : Cool:
Thanks man : Good:
What custom kernel were you trying to adapt to AnyKernel so you could flash it on CM?
osm0sis said:
What custom kernel were you trying to adapt to AnyKernel so you could flash it on CM?
Click to expand...
Click to collapse
Two kernels... My custom kernel (from cyanogenmod sources) and recently Fancy kernel (dirty-fancy)... now I want to try Fancy Kernel .. I need of a hibryd ramdisk for best final results and Your project is perfect for It !!! You're a genius !!!
Please, Can You link me Your dirty-V kernel re-pack by Anykernel 2.0 ? So I can follow It as an example. Thanks a lot...
So if I understand you, you're trying to make an AnyKernel 2.0 of Fancy Kernel so that you can flash it on any ROM for your device?
Should be doable. The DirtyV AnyKernel 2.0 is the example posted to the GitHub repo in the OP. Just follow the instructions to make your own anykernel script so that it will add the /sbin/ scripts and other ramdisk modifications (init.d, etc.) that @boype uses, instead of the DirtyV ones.
Good luck!
osm0sis said:
So if I understand you, you're trying to make an AnyKernel 2.0 of Fancy Kernel so that you can flash it on any ROM for your device?
Should be doable. The DirtyV AnyKernel 2.0 is the example posted to the GitHub repo in the OP. Just follow the instructions to make your own anykernel script so that it will add the /sbin/ scripts and other ramdisk modifications (init.d, etc.) that @boype uses, instead of the DirtyV ones.
Good luck!
Click to expand...
Click to collapse
Yes !
osm0sis ? If I want include init.rc original file by "real" ramdisk can I copy It as is into patch folder ?
It would go against the idea of AnyKernel to include the file like that. Remember, everything automatically comes from the original ramdisk, I just give you the ability to alter those files to add tweaks. :good:
Hi everybody,
Right after upgrading my Moto G Pro to Android 11 (SOFIAP_AO_EEA_RPR31.Q4U_20_26_2), I wanted to install the February security patch and received the following message:
Package verification failed
The update package being download is not compatible with the current software version on the device.
Click to expand...
Click to collapse
I wanted to apply the same procedure for OTA updates on my rooted phone that was working under Android 10 (cf. this posting).
Anyone has an idea how to solve this?
Thanks in advance for your help!
today i receive february security patch (RPRS31.Q4U-20-28 (chanell: reteu)), install & root via this method without problem, also before upgrade from A10 to A11 work with same method...
sure you restore stock boot image via magisk manager (step 3) ? your error message look exactly as without restored stock boot...
k3dar7 said:
today i receive february security patch (RPRS31.Q4U-20-28 (chanell: reteu)), install & root via this method without problem, also before upgrade from A10 to A11 work with same method...
sure you restore stock boot image via magisk manager (step 3) ? your error message look exactly as without restored stock boot...
Click to expand...
Click to collapse
Thank you for your reply! Yes, I did uninstall Magisk with "restore images" ("Restoration done!" toast appears on the screen) - but still the problem persists and I receive the error message when I try to update...
Any other idea what could block my OTA update?
You have disabled SmartUpdates? (step 2)
Try:
1. Install Magisk again to CurrentSlot
MagiskManager/Magisk-Install/DirectInstall
2. Disable Wifi and MobileData
3. Reboot
4. MagiskManager/UnstallMagisk/RestoreImages
5. Enable Wifi and/or MobileData
6 . initialize manualy OTA search:
(Android)Settings/System/SystemUpdate
This steps maybe to not have Magisk installed when OTA is inicialized. Not know if help
k3dar7 said:
You have disabled SmartUpdates? (step 2)
Try:
1. Install Magisk again to CurrentSlot
MagiskManager/Magisk-Install/DirectInstall
2. Disable Wifi and MobileData
3. Reboot
4. MagiskManager/UnstallMagisk/RestoreImages
5. Enable Wifi and/or MobileData
6 . initialize manualy OTA search:
(Android)Settings/System/SystemUpdate
This steps maybe to not have Magisk installed when OTA is inicialized. Not know if help
Click to expand...
Click to collapse
Thank you so much!
Yes, "Smart Updates" are disabled.
I tried what you suggested - unfortunately, same error message on step 6...
I still don't understand what blocks the OTA update on my device:
My current Android 11 was flashed with the Rescue and Smart Assistant (LMSA) after a full wipe.
I re-flashed the original boot.img (to completely unroot).
I re-flashed the original recovery.img on both partitions.
I deleted the cache of "Motorola Update Services".
...Now I'm running out of ideas how to get rid of the "Package verification failed" message...
This should be the relevant extract from logcat:
Code:
02-28 19:38:45.512 1580 1580 E update_engine: [ERROR:delta_performer.cc(1205)] The hash of the source data on disk for this operation doesn't match the expected value. This could mean that the delta update payload was targeted for another version, or that the source partition was modified after it was installed, for example, by mounting a filesystem.
02-28 19:38:45.515 1580 1580 E update_engine: [ERROR:delta_performer.cc(1210)] Expected: sha256|hex = 63B6A76F2009E796A2A1F3F6A70957DB12E2146A6929A659505F9EC5BCA16A53
02-28 19:38:45.518 1580 1580 E update_engine: [ERROR:delta_performer.cc(1213)] Calculated: sha256|hex = 6FE9E5AF9EC26F47B555E7088A8BED085C49BE551AAB5C584D140232F02D6C68
02-28 19:38:45.525 1580 1580 E update_engine: [ERROR:delta_performer.cc(1224)] Operation source (offset:size) in blocks: 0:2,4:1,43:2,161:56
02-28 19:38:45.527 1080 1218 E qdmetadata: paramType 2048 not supported
02-28 19:38:45.534 1580 1580 W update_engine: [WARNING:mount_history.cc(66)] Device was remounted R/W 46 times. Last remount happened on 1970-10-12 05:15:10.000 UTC.
02-28 19:38:45.544 8783 9015 D OtaApp : UpdaterEngHelper:verifyPayloadMetadata:isVerifySuccessful=false
I still have android 10. The Feb security patch worked on my phone fine. You may be trying to install a 10 patch onto an 11 system.
How can an Android application detect that it is running on a rooted device that is running the Universal SafetyNet Fix with MagiskHide configured to hide from that application, props configured to a known good fingerprint, and magisk renamed to something else?
I have read that the Universal SafetyNet Fix module works by causing hardware attestation to fall back to basic when key attestation fails with the "not implemented" error. How can an app developer detect when this happens and require that true hardware attestation is used?
It's easy for any app to detect whether Android got tampered or not: No Magisk module can prevent this.
Only as example:
The Universal Safetynet Fix changes in system file named build.prop these properties
Code:
ro.boot.flash.locked
ro.boot.verifiedbootstate
ro.boot.veritymode
ro.boot.vbmeta.device_state
what in turn changes LastModifiedTime property of build.prop.
Hence it should be obvious - to see whether Android OS got tampered or not - the most easy method is comparing this timestamp with timestamp when Android OS was built.
IMO it's a misconception to believe that app developers are dumber than the developer of Magisk.
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
{
"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"
}
This is the support thread of PixelFlasher
(PixelFlasher is an open-source self contained GUI tool to facilitate Pixel phone device flashing/rooting/updating with extra features).
Note: This thread is meant for issues and problems faced in Google Pixel 7a devices, generic issues that are device agnostic should be discussed in the main thread.
For full details on where to download / usage and feature set of the tool, visit the main thread at XDA or the project's Github page.
Troubleshooting:
If you need support or assistance, the best way to get is by generating a support file from within PixelFlasher.
You can hit that big Support button on the main screen, or select it from the Help menu.
The generated support.zip file is sanitized (redacted) to keep your sensitive information (username device id ...) private.
New Release:
May 19, 2023 v5.0.0.1 release
#75 Bug fix, when device is in bootloader, type error.
#74 Added Support for Pixel 7a (lynx)
Configuration option to define the file manager to use on Linux (default: Nautilus)
Configuration option to define the terminal emulator to use on Linux (default: gnome-terminal).
Support for additional types of Factory / ROM files.
Checksum validation of firmware / ROM files (if part of the checksum is in the name, otherwise just display)
New advanced option, ability to choose the patching method (with recommendations).
Added Recovery Image patching option.
Advanced option to enable the use of busybox shell (default off).
Auto detect firmware / rom with init_boot and use init_boot for creating patches, this way future firmware don't have to be manually added to PixelFlasher.
Auto detect devices with init_boot and use init_boot for flashing, this way future devices don't have to be manually added to PixelFlasher.
Auto-popup the detected devices dropdown after a scan, to make it obvious to select that next. (Thanks @pndwal for the idea)
Show SHA-256 of adb and fastboot binaries, as Google keeps on messing up Android Platform-tools, it's necessary to whitelist / blacklist specific binaries.
#66, when checking the patched files internal SHA1, provide a confidence rating.
Check, valdiate and warn if necessary when flashing an image patched with Magisk Zygote64_32, as there are wipe implications, provide links to documentation.
Added fastbootd testing to Dry Run.
Added Github actions to build all the targets on Github.
Code refactoring, bug fixes and improvements
New Release:
May 25, 2023 v5.1.0.0 release
Support for Android platform tools version 34.0.3, and automatic setting of ANDROID_PRODUCT_OUT environment to workaround a regression introduced in version 34.0.3
Temp workaround to avoid selecting root method patching when Magisk Delta is detected.
Nicer looking / clearer manual patching dialog.
When a Pixel device is selected, PixelFlasher now displays additional information about the device's support.
Things like: Device name, version end date, security update end date, Android version, name, codename, release date, end date.
Boot image list box now displays the applied PixelFlasher patch method.
Auto-resize boot image list box columns for better readability.
Precautionary cleanup up of leftover files on the phone in case root detection software keys on presence of such files.
#77 added attrict3 to requirements.txt in case it helps with certain builds (it shouldn't be needed).
Bug fixes and improvements.
Update:
Patch Release:
v5.1.0.1 release
Exception handling when device is not in the listed Pixel devices.
v5.1.0.2 release
Skip testing fastbootd in dry run mode if Android platform tools version is > 34, is it no longer supports fastbootd (at least 34.0.3 does not)
Thank you so much for this awesome software! When trying to trying to patch the int.boot from the factory image I run into the following error "Detected Unsupported firmware, with payload.bin". Is this truly unsupported or am I doing something wrong?
I also tried extracting the payload.bin to manually pull out int.boot and patch it, which I think worked, but in the console field said something about a low confidence match and aborted the flash.
Any help would be greatly appreciated.
I downloaded the following build from google: lynx-ota-tq2b.230505.005.a1-766dbd16
Using: platform-tools_r34.0.3-windows
Pixel Flasher: v5.1.0.2 release
Gp3322 said:
Thank you so much for this awesome software! When trying to trying to patch the int.boot from the factory image I run into the following error "Detected Unsupported firmware, with payload.bin". Is this truly unsupported or am I doing something wrong?
I also tried extracting the payload.bin to manually pull out int.boot and patch it, which I think worked, but in the console field said something about a low confidence match and aborted the flash.
Any help would be greatly appreciated.
I downloaded the following build from google: lynx-ota-tq2b.230505.005.a1-766dbd16
Using: platform-tools_r34.0.3-windows
Pixel Flasher: v5.1.0.2 release
Click to expand...
Click to collapse
You are selecting an OTA image instead of firmware image.
If you click on that green button on the left of firmware selection, it should open a download link for your device, download that and process that.
Manually extracting init_boot from payload.bin is ok for patching, which you did the first time around, and it create a proper patch.
But then you proceeded to trying to patch the patched file, why would you do that?
That's when PF aborted with low confidence level.
You are 100% correct! I was using the OTA instead of the full image. Once I found the correct file, everything fell into place.
New Release:
June 01, 2023 v5.2.0.0 release
Update build workflows
Add payload_dumper functionality to PixelFlasher to handle OTA files, thanks to vm03 for sharing source code.
Added rules engine code to better / easier management of the UI widgets enabling / disabling.
Auto detect Pixel OTA image and extract boot / init_boot / vbmeta for patching and flashing.
Add Full OTA mode, which flashes full OTA image, while optionally retaining root, and best of all, for A/B devices, both slots are bootable, you can even have one rooted and one not.
Bug Fix Release:
June 01, 2023 v5.2.0.1 release
Bug fix #78 Error when opening a shell console on Linux / Mac
Update:
June 03, 2003 v5.2.0.2 release
#76 Get a better build with Github action to support more Linux based platforms (no functionality changes).
New Release:
June 06, 2003 v5.3.0.0 release
Added Github Action build on Windows 2019 with Python 3.8 to support Windows 7.
PixelFlasher now supports loading and processing Samsung Firmware (at least my Samsung's ), it would extract AP, BL, CSC, Home_CSC ... and then extract boot.img.lz4 from AP and unpack the lz4.
When creating a patch from the set boot.img, PixelFlasher will also create boot.tar to be flashed as AP to retain root.
If there was a way to pre-load odin with the extracted files, flashing could also be automated.
I know, what does PixelFlasher have anything to do with Samsung firmware? I added it for my own use.
New Release:
June 16, 2003 v5.3.1.2 release
Set Active slot now automatically reboots to system after setting the slot, unless "No Reboot" option is selected.
Update Ubuntu 20.04 build to be aligned to the same methods that Ubuntu 22.04 build uses.
Improve confidence value calculation when comparing compressed sha1 against normal sha1 to account for shift.
Do not abort when the sha1 comparison confidence value is low, leave the choice to the user.
Update Windows builds (both) as wxPython wheel path changed, rely on a more persistent URL instead.
Thank you. Work like a champ.
tim1aust said:
2 questions in re. PixelFlasher and P7a.. a) is P7a supported yet? (seems like yes) b) is PixelFlasher from AUR for Manjaro *at the same build level* (it has 5.3.1.2 in lower left)as the one from Github, et.al?
I figured it would be easier to just have a supported AUR package, so I installed that. But when I tried to use it for P7a with latest Full image, it couldn't patch the file (said it couldn't find boot.img). Of course, for P7 & P7a, it should firstly be looking for init_boot.img. Could it be due to the fact that this was a new phone which didn't yet have Magisk installed? (I guess that's 3 questions Anyway, I wound up gettng Magisk installed from scratch, so my P7a now has it installed. I'm hoping to use PixelFlasher from AUR next time.
TIA,
Tim
Click to expand...
Click to collapse
Original Post:
@tim1aust
I'm answering you in here to keep the Magisk thread clean of PF specific discussions.
Yes, PF supports Pixel 7a (lynx)
If you provide a support file, I could check what might have happened.
Thanks for answering, and pointing me to correct thread.
Unfortunately, I don't have a support file, unless the tool automatically saved one and I wasn't paying attention.
tim1aust said:
Thanks for answering, and pointing me to correct thread.
Unfortunately, I don't have a support file, unless the tool automatically saved one and I wasn't paying attention.
Click to expand...
Click to collapse
Yes, the tool creates logs, and when you click on the support button, it processes them and redacts sensitive information and creates a zip file for upload.
All you have to do is launch PF, and hit the button and share the file.
Great, attaching it here. Thanks for your help!
tim1aust said:
Great, attaching it here. Thanks for your help!
Click to expand...
Click to collapse
Thanks
Sorry I'm confused, you reported an issue with Pixel 7a (Lynx), but all I see is logs regarding Pixel 7 (Panther).
You mentioned about failed patching.
But I see nothing wrong with patching.
Code:
Creating a patch ...
Cleaning up...
- Unpacking boot image
Parsing boot image: [/sdcard/Download/init_boot_bea42eca.img]
HEADER_VER [4]
KERNEL_SZ [0]
RAMDISK_SZ [2068178]
PAGESIZE [4096]
CMDLINE []
RAMDISK_FMT [lz4_legacy]
VBMETA
- Checking ramdisk status
Loading cpio: [ramdisk.cpio]
- Stock boot image detected
- Patching ramdisk
- Pre-init storage partition device ID: REDACTED
Loading cpio: [ramdisk.cpio]
Add entry [init] (0750)
Create directory [overlay.d] (0750)
Create directory [overlay.d/sbin] (0750)
Add entry [overlay.d/sbin/magisk64.xz] (0644)
Add entry [overlay.d/sbin/stub.xz] (0644)
Patch with flag KEEPVERITY=[true] KEEPFORCEENCRYPT=[true]
Loading cpio: [ramdisk.cpio.orig]
Backup mismatch entry: [init] -> [.backup/init]
Record new entry: [overlay.d] -> [.backup/.rmlist]
Record new entry: [overlay.d/sbin] -> [.backup/.rmlist]
Record new entry: [overlay.d/sbin/magisk64.xz] -> [.backup/.rmlist]
Record new entry: [overlay.d/sbin/stub.xz] -> [.backup/.rmlist]
Create directory [.backup] (0000)
Add entry [.backup/.magisk] (0000)
Dump cpio: [ramdisk.cpio]
- Repacking boot image
Parsing boot image: [/sdcard/Download/init_boot_bea42eca.img]
HEADER_VER [4]
KERNEL_SZ [0]
RAMDISK_SZ [2068178]
PAGESIZE [4096]
CMDLINE []
RAMDISK_FMT [lz4_legacy]
VBMETA
Repack to boot image: [new-boot.img]
HEADER_VER [4]
KERNEL_SZ [0]
RAMDISK_SZ [2528130]
PAGESIZE [4096]
CMDLINE []
PATCH_SHA1: 081f1391
PATCH_FILENAME: magisk_patched_26100_bea42eca_081f1391.img
Cleaning up ...
Checking patch log: /data/local/tmp/pf_patch.log ...
Getting file content of /data/local/tmp/pf_patch.log on the device ...
Return Code: 0
Deleting /data/local/tmp/pf_patch.log from the device ...
Return Code: 0
Looking for magisk_patched_26100_bea42eca_081f1391.img in /storage/emulated/0/Download ...
Checking for /storage/emulated/0/Download/magisk_patched_26100_bea42eca_081f1391.img on the device ...
File: /storage/emulated/0/Download/magisk_patched_26100_bea42eca_081f1391.img is found on the device.
Pulling /storage/emulated/0/Download/magisk_patched_26100_bea42eca_081f1391.img from the phone to: magisk_patched_26100_bea42eca_081f1391.img ...
Pulling remote file: /storage/emulated/0/Download/magisk_patched_26100_bea42eca_081f1391.img from the device to: "/home/REDACTED/.local/share/PixelFlasher/tmp/magisk_patched_26100_bea42eca_081f1391.img" ...
Return Code: 0
Getting SHA1 of /home/REDACTED/.local/share/PixelFlasher/tmp/magisk_patched_26100_bea42eca_081f1391.img ...
SHA1 of magisk_patched_26100_bea42eca_081f1391.img file: 081f1391b700afb8ef5b28b4dce6db0bdb6d5d38
Getting SHA1 of source init_boot.img ...
Source init_boot.img's SHA1 is: bea42eca0a4e06eac0e876c2e7b9f518ade87874
Extracting SHA1 from magisk_patched_26100_bea42eca_081f1391.img ...
SHA1 embedded in /home/REDACTED/.local/share/PixelFlasher/tmp/magisk_patched_26100_bea42eca_081f1391.img is: bea42eca0a4e06eac0e876c2e7b9f518ade87874
Comparing source init_boot.img SHA1 with SHA1 embedded in bea42eca0a4e06eac0e876c2e7b9f518ade87874 (they should match) ...
Good: Both SHA1s: bea42eca0a4e06eac0e876c2e7b9f518ade87874 match.
Magisk Version: 26.1:26100
Patch time: 5 seconds
The attempt was made yesterday.. 6-20. Is there a log from that date? The ones for panther were when I was using PF for my P7.
--tim
tim1aust said:
The attempt was made yesterday.. 6-20. Is there a log from that date? The ones for panther were when I was using PF for my P7.
--tim
Click to expand...
Click to collapse
OK I see it now.
What is this file? where did it come from?
lynx-factory-23410002.zip
Code:
Selected Firmware lynx-factory-23410002.zip SHA-256: 033c2d0381aec8e4538a393baa9fdd86bfc7f24578fa8e4db9f7d9ea49756948
I have a bookmark in my browser for getting OTA updates ( which I've been doing forever, before PF).. Anyway, there is a link at the top left of the page for Factory images, that's what I downloaded. URL is https://developers.google.com/android/images