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

[ahmadmahmood2048]

Use lineage.microg.org

This rom is slow to update, and I can't trust that site. i just want to use micro g with official linegage os without xposed (it uses a lot of resources).

 

[Aqq123]

i applied the guide you wrote for lineage os 19.1 s10e (or so I think) [...] 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. [...]

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?

Always use the latest APK Tool, which is currently the 2.x.x series. I named it apktool2 since I also keep the last apktool from the 1.x.x series for legacy systems.

If the patch doesn't work for you, you can create your own by running a diff between the decompiled services.jar from the official LineageOS and the one from LineageOS for MicroG (preferably around the same date to minimize other differences). That's how I got this patch, which still worked for me on lemonadep as of 2022-12-27 (last build before the device was switched to LOS 20). Mind you, there will be other differences like resource IDs, which you shouldn't change, so the scope of the patch has to be adjusted manually. But from the rest of your post, it seems like it works in the end?

Once you have the recompiled services.jar, copy it to your device and run dex2oat on it to generate the two files: services.odex and services.vdex. Place them in the correct location on the /system partition. Make sure the permissions match the other files in the same location. Delete any equivalent system.jar cache files from /data/dalvik-cache/ since they'll prevent your device from booting.

I think this is all covered in the OP step-by-step already, not sure what else can be said. Maybe if you already booted the device the 1st time, you can skip running dex2oat and directly move and rename the OAT cache files from /data/ to /system/.

Not sure what went wrong but note that even when there is an issue and the screen is black, it's just the Android Runtime crashing, so you can still ADB into the system (if you had it set up beforehand) and run adb root, adb shell stop, apply any fixes, and adb shell start to immediately check if they work. You can also run adb logcat during boot to see what exactly is failing.

To make signature spoofing work, you also have to install the SignatureSpoofing.apk "app" (it's not really an app since it doesn't have any code, just a declaration of this permission). It's attached to the OP. Have you installed it?

This just gives you signature spoofing support, installing MicroG takes a couple of extra steps as well (installing APKs and granting them permissions). If you install system priv-apps but don't grant them the required permissions, the device will also bootloop. It can be tricky to get it all right the first time. You really need to be able to get such information from adb logcat yourself if you want to set it all up it on your own. Once you get it partly running though, the MicroG app has an excellent self-check feature to see what's missing.

Setting this all up is another thing altogether, and not covered here. For starters, if you want to learn it, I suggest comparing the system, system_ext and product partitions of LOS and LOS for MicroG. You can then use the same files they're using (plus the SignatureSpoofing.apk which is not required in LOS for MicroG). In particular take a look at the configuration files that go into etc/default-permissions, etc/permissions and etc/sysconfig on the respective partitions.

Or maybe you can try the NanoDroid installer: https://github.com/Nanolx/NanoDroid

 

[kurtn]

This rom is slow to update, and I can't trust that site. i just want to use micro g with official linegage os without xposed (it uses a lot of resources).

My problem with xposed (LSPosed) is not resource usage but security doubt.

Anyways: you can build lineage4microg yourself.

 

[ahmadmahmood2048]

Always use the latest APK Tool, which is currently the 2.x.x series. I named it apktool2 since I also keep the last apktool from the 1.x.x series for legacy systems.

If the patch doesn't work for you, you can create your own by running a diff between the decompiled services.jar from the official LineageOS and the one from LineageOS for MicroG (preferably around the same date to minimize other differences). That's how I got this patch, which still worked for me on lemonadep as of 2022-12-27 (last build before the device was switched to LOS 20). Mind you, there will be other differences like resource IDs, which you shouldn't change, so the scope of the patch has to be adjusted manually. But from the rest of your post, it seems like it works in the end?

Once you have the recompiled services.jar, copy it to your device and run dex2oat on it to generate the two files: services.odex and services.vdex. Place them in the correct location on the /system partition. Make sure the permissions match the other files in the same location. Delete any equivalent system.jar cache files from /data/dalvik-cache/ since they'll prevent your device from booting.

I think this is all covered in the OP step-by-step already, not sure what else can be said. Maybe if you already booted the device the 1st time, you can skip running dex2oat and directly move and rename the OAT cache files from /data/ to /system/.

Not sure what went wrong but note that even when there is an issue and the screen is black, it's just the Android Runtime crashing, so you can still ADB into the system (if you had it set up beforehand) and run adb root, adb shell stop, apply any fixes, and adb shell start to immediately check if they work. You can also run adb logcat during boot to see what exactly is failing.

To make signature spoofing work, you also have to install the SignatureSpoofing.apk "app" (it's not really an app since it doesn't have any code, just a declaration of this permission). It's attached to the OP. Have you installed it?

This just gives you signature spoofing support, installing MicroG takes a couple of extra steps as well (installing APKs and granting them permissions). If you install system priv-apps but don't grant them the required permissions, the device will also bootloop. It can be tricky to get it all right the first time. You really need to be able to get such information from adb logcat yourself if you want to set it all up it on your own. Once you get it partly running though, the MicroG app has an excellent self-check feature to see what's missing.

Setting this all up is another thing altogether, and not covered here. For starters, if you want to learn it, I suggest comparing the system, system_ext and product partitions of LOS and LOS for MicroG. You can then use the same files they're using (plus the SignatureSpoofing.apk which is not required in LOS for MicroG). In particular take a look at the configuration files that go into etc/default-permissions, etc/permissions and etc/sysconfig on the respective partitions.

Or maybe you can try the NanoDroid installer: https://github.com/Nanolx/NanoDroid

Thank you very much. very descriptive information indeed. but i'm a bit unfamiliar with this stuff, anyway now i will try to compare LOS4MicroG with the official version, then i will learn how dex2oat works and update my apktool,
i hope i can do something on this way by myself, anyway thank you very much for your help

My problem with xposed (LSPosed) is not resource usage but security doubt.

Anyways: you can build lineage4microg yourself.

actually i mean it is a security problem for me too, many settings need to be opened root, zygisk and lsposed. without opening them and i am looking for a safe way and i hope i succeed

 

[idGEN]

hi, need to ask something

follow ur tutorial with samsung n xiaomi official rom for bypassmock.
working and can use for spooflocation after edit some method at service.jar original
but the problem is like ur post, after 2nd boot stuck and bootloop.
any advice? should service.jar signed or something? how to do that

thanks

 

[Renate]

Should service.jar signed or something?

Nope, framework jars are not signed.
Your problem lies elsewhere.
Probably the patch massacred the smali file?

 

[Aqq123]

but the problem is like ur post, after 2nd boot stuck and bootloop.
any advice? should service.jar signed or something?

It's all in the OP:

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/system@[email protected]@classes.dex
/data/dalvik-cache/arm64/system@[email protected]@classes.vdex

Have you done any of this? What does the log say?

Probably the patch massacred the smali file?

On 2nd boot?

 

[Aqq123]

For Android 12, an extra step is critical to ensure no bootloop on subsequent boot (2nd and then on)

Since a couple of people have had issues with this, I'll try to explain what's going on here in more detail. Maybe the following helps:

The background

• Android runtime (ART) uses cache to execute the virtual machine (Dalvik/"Java") code faster.
• This is called ahead-of-time optimization (OAT).
• The cache for system apps and the system itself is generated at build time. It is preinstalled on the system partition.
• Any remaining cache (such as for user apps) is generated when needed. It is saved on the (user) data partition.
• This is transparent to the user except you might notice a newly-installed app takes longer to run the 1st time (and a lot of messages about it if you check the logs).

What happens when you modify the system

• When you modify a system APK or JAR, any prebuilt cache for it stored on the system partition (that came as part of the installation image) is no longer valid.
• Any missing cache files for a system component are then generated and saved on the data partition to be reused.

Why this is an issue

• The "cache" is actually precompiled code, which comes with all the caveats. For system components, it runs with system privileges.
• If you have write access to where the cache is stored, you could craft a special file to execute completely different code with the privileges of any installed app, and make it do whatever you want.
• If the cache for a system app is read from the data partition (which the user can modify), it means one could execute arbitrary code with the privileges of any system app, thus bypassing the Android security model.
• So with Android 12 there is now a boot-time check that makes the Android runtime fail to start if any cache for system components is read from an "untrusted" location, such as the data partition.

What this means for anyone who wants to modify code on the system partition

Two things:

1. First, you need to delete any cache for system components from the data partition. This guarantees the system will boot one more time (and generate these cache files again while doing so).
2. Second, you need to place all the required cache files on the system partition, so that they are never generated automatically and placed on the data partition. This solves the problem completely and ensures the system will boot every time from then on (or if it doesn't, it's not for this reason anymore).

Hope this is useful to understand what has to be done. As for how to do it, see the One More Thing section of the OP.

 

[kullanici32]

finally... i've been trying to figure out how to do it occasionally since this post was posted, and i've finally figured out how to do it by repeatedly reading the posts here. now i can use micro g signature spoofing with official lineage os 19.1.

very very thanks @Aqq123

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

i just don't understand how to run this dex2oat
I can only boot once for now.
Then I can delete the part you said from the data cache and restart it.
how do i run dex2oat for this services.jar? termux? adb shell? Or is it another way?

 

[Aqq123]

i just don't understand how to run this dex2oat
I can only boot once for now.
Then I can delete the part you said from the data cache and restart it.
how do i run dex2oat for this services.jar? termux? adb shell? Or is it another way?

It's an executable on the device. So adb shell is fine. Terminal should also work if you don't mind the typing.

If you already have these files though (booted once), it should be enough to rename and move them to the right location.

Either way, when you're done make sure the permissions allow them to be read by anyone (chmod 644 /system/framework/oat/arm64/services.*) and that the owner and group are correct (chown 0.0 /system/framework/oat/arm64/services.*). And you're good to go.

 

[kullanici32]

It's an executable on the device. So adb shell is fine. Terminal should also work if you don't mind the typing.

If you already have these files though (booted once), it should be enough to rename and move them to the right location.

Either way, when you're done make sure the permissions allow them to be read by anyone (chmod 644 /system/framework/oat/arm64/services.*) and that the owner and group are correct (chown 0.0 /system/framework/oat/arm64/services.*). And you're good to go.

It had occurred to me to replace the optimization files created in the 1st boot with the ones in the system. but the file sizes were quite different, the odex file was 40 mb the newly formed file was 160 kb, the vdex 281 kb the newly formed file was 19 mb. I gave up on changing them. but now I said you can replace the files in this system with newly created files, I tried and it worked, now I can forge signature without any problem, I will try to do it in one ui in the future. And finally, I would like to thank you once again for this topic. see you later...

 

[kullanici32]

@Aqq123 i bother you again... sorry...

Now I'm trying for one UI, but how can I add the codes in the services.diff file from the place shown in the picture? I added the top 2 big patch codes and the device shows signature spoof permission. do you have any solution? If I can add all the code in services.diff to the right place, I think it will work in one ui 4.1

 

[Aqq123]

Now I'm trying for one UI, but how can I add the codes in the services.diff file from the place shown in the picture? I added the top 2 big patch codes and the device shows signature spoof permission. do you have any solution?

This patch is for LOS. I think for Samsung's One UI you might need something different altogether unfortunately.

Coming up with an edit like this from scratch as a .smali file is non-trivial.

What I'd do is find an older patched version of Samsung's services.jar. Then find an unpatched clean version matching the same build. Or maybe find a DexPatcher patch for Samsung and patch a version of services.jar on which it still worked (Android 11?). Either way, decompile and compare the two. This should get you started where the patch should go.

As far as I recall, Samsung changes the Package Manager code too much from vanilla.

 

[TheRealModder]

Hello, i have a question that somehow relates to this Signature Spoofing thread but it's not about Signature Spoofing, it's about Signature Verification.

You guys have a guide for disabling signature verification on Android 12 and up? SmaliPatcher is no no way since it didn't get updated for months, and the forbidden lucky tool didn't work. Tried to do the Android 10 way of disabling signature verification but, it does not work and after a second boot, i got a bootloop. and i guess now i know why the phone got bootloop the second time i rebooted the phone because of this thread.

And no, i didn't want to use corepatch since i need the signature verification patch baked into the rom.

Sorry for the out-of-topic question but, i've been searching for signature verification patch for android 12 and up on xda, and the only thing shows up is corepatch, corepatch and corepatch.

 

[kurtn]

Hello, i have a question that somehow relates to this Signature Spoofing thread but it's not about Signature Spoofing, it's about Signature Verification.

You guys have a guide for disabling signature verification on Android 12 and up? SmaliPatcher is no no way since it didn't get updated for months, and the forbidden lucky tool didn't work. Tried to do the Android 10 way of disabling signature verification but, it does not work and after a second boot, i got a bootloop. and i guess now i know why the phone got bootloop the second time i rebooted the phone because of this thread.

And no, i didn't want to use corepatch since i need the signature verification patch baked into the rom.

Sorry for the out-of-topic question but, i've been searching for signature verification patch for android 12 and up on xda, and the only thing shows up is corepatch, corepatch and corepatch.

You are talking about app signatures and their verification when installing updates? That's far out of this topic.

 

[TheRealModder]

You are talking about app signatures and their verification when installing updates? That's far out of this topic.

yea something like that, the dc rc stuff. sorry for that oot question, it just, i can't find a guide anywhere on xda.

 

[fbalder18]

@Aqq123 , do you think that your approach can still work for Android 13? I have Windows Subsystem for Android 2307.40000.3.0 and want to integrate microG. How to get services.diff and services_replace.zip for A13?

 

[Aqq123]

@Aqq123 , do you think that your approach can still work for Android 13? I have Windows Subsystem for Android 2307.40000.3.0 and want to integrate microG. How to get services.diff and services_replace.zip for A13?

It should work but you need to make your own .diff. The easiest way to do so is by comparing the decompiled services.jar from both the regular LineageOS and LineageOS for MicroG. You can then apply the said .diff directly.

In this scenario, you do not use services_replace.zip at all.

 

[fbalder18]

It should work but you need to make your own .diff.
[...]

My WSA is TQ3A.230705.001. Do I need to find a device available on both lineageos and lineage.microg with the exact same version? Or is A13 sufficient? How to find the exact version without device to be able to install on?

 

[q2n]

Rather than allowing signature spoofing across the board, is it possible to allow only the necessary MicroG file(s)?

Given that MicroG fits with Lineage's core mission so much better than the Google-provided files, how has MicroG not been worked in as the default? (...which would make all the extra work here obsolete, though thank you for doing it.)