yashsingh1/xdaforums huggingface dataset:
[Android Software/Hacking General [Developers Only]] Aqq123:
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.
[Android Software/Hacking General [Developers Only]] Aqq123:
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
[Android Software/Hacking General [Developers Only]] JedidroidX:
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.
[Android Software/Hacking General [Developers Only]] kidronvalley:
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 ?
[Android Software/Hacking General [Developers Only]] kurtn:
Most gsi have signature spoofing feature.
[Android Software/Hacking General [Developers Only]] kidronvalley:
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.
[Android Software/Hacking General [Developers Only]] ahmadmahmood2048:
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/Set;)Landroid/content/pm/PackageInfo;

.method private static getRequestedFakeSignature(Lcom/android/server/pm/parsing/pkg/AndroidPackage;)Ljava/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?
[Android Software/Hacking General [Developers Only]] kurtn:
Use lineage.microg.org
[Android Software/Hacking General [Developers Only]] ahmadmahmood2048:
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).
[Android Software/Hacking General [Developers Only]] Aqq123:
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
[Android Software/Hacking General [Developers Only]] kurtn:
My problem with xposed (LSPosed) is not resource usage but security doubt.

Anyways: you can build lineage4microg yourself.
[Android Software/Hacking General [Developers Only]] ahmadmahmood2048:
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 :)

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 :)
[Android Software/Hacking General [Developers Only]] 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
[Android Software/Hacking General [Developers Only]] Renate:
Nope, framework jars are not signed.

Your problem lies elsewhere.

Probably the patch massacred the smali file?
[Android Software/Hacking General [Developers Only]] Aqq123:
It's all in the OP:

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

On 2nd boot?
[Android Software/Hacking General [Developers Only]] Aqq123:
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:

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

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.
[Android Software/Hacking General [Developers Only]] 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?
[Android Software/Hacking General [Developers Only]] Aqq123:
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.
[Android Software/Hacking General [Developers Only]] kullanici32:
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...
[Android Software/Hacking General [Developers Only]] 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
[Android Software/Hacking General [Developers Only]] Aqq123:
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.
[Android Software/Hacking General [Developers Only]] 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.
[Android Software/Hacking General [Developers Only]] kurtn:
You are talking about app signatures and their verification when installing updates? That's far out of this topic.
[Android Software/Hacking General [Developers Only]] TheRealModder:
yea something like that, the dc rc stuff. sorry for that oot question, it just, i can't find a guide anywhere on xda.
[Android Software/Hacking General [Developers Only]] 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?
[Android Software/Hacking General [Developers Only]] Aqq123:
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.
[Android Software/Hacking General [Developers Only]] fbalder18:
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?
[Android Software/Hacking General [Developers Only]] 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.) `

EDIT

Thanks to this thread (and XDA for highlighting it), my first MicroG install is completed. How did I live without it? :oops:
[Android Software/Hacking General [Developers Only]] kurtn:
You are mis-interpreting lineageOS' core mission. Have a look at other rom pronects with other priorities. Maybe divestOS
[Android Software/Hacking General [Developers Only]] fbalder18:
There are different Signature Spoofing implementations. Some only allow for GMS Core and Play Store, some have a gui where one once confirms the permission for an app, and i think a few allow for all.
[Android Software/Hacking General [Developers Only]] Aqq123:
You will know once you generate the .diff. If there are other significant differences and/or it doesn't look too similar to the example I posted, then you probably need to look for other candidate builds. Or edit the .diff manually.

This patch does not allow spoofing "across the board," only to apps with permission, very much the same way MicroG handles it. What you're asking is what it does already.

The backstory is in the MicroG FAQ entry linked from the OP:
[Android Software/Hacking General [Developers Only]] fbalder18:
I tried to patch ComputerEngine.smali but it failed with

8 out of 13 hunks FAILED

Here is what I did. I downloaded on Windows 11 LineageOS 20 for star2lte (Samsung Galaxy S9+) dated 20230720 and Lineage4microG for same device dated 20230723. I extracted services.jar from system.new.dat.br using PeaZip and system.new.dat-extractor.

I decompiled with APKTool 2.8.1:

apktool d -b -o services services.jar

both the original and the sigspoofed variant. I added the -b switch to get rid of the .lines directive in smali files.

On Ubuntu 22.04 (Windows Subsystem for Linux WSL2) I created the diff:

diff -u ComputerEngine.orig.smali ComputerEngine.sigspoof.smali > Computer

Engine.orig.sigspoof.diff

Then I copied services.jar from WSA using a root file manager, also decompiled with APKTool and I applied the patch:

patch ComputerEngine.smali < ComputerEngine.orig.sigspoof.diff

but it failed with 8 out of 13 hunks FAILED. I attached the files to this post.

I also tried the same with LOS 20 for Pixel 5 (since WSA shows this device type in system settings). But there were even 11 failures.

What can I do to patch services.jar from WSA?