osm0sis
Senior Recognized Developer / Contributor
No haven't seen that one yet, but you could experiment by adding one with Magisk and see if anything respects it. 

I did test on my two Xiaomi phones, MIUI 12.5/A11 and MIUI 13/A12No haven't seen that one yet, but you could experiment by adding one with Magisk and see if anything respects it.![]()
Thanks again for your whole advice.It's ok not to be a dev or know Python, you can use the program as a user,
it would extract the boot from the image, transfer it to the phone, create the script based on the chosen file, create the patch and pull it back to your PC, and it is cross platform.
You can inspect the generated script which is bash, and understand what it is doing without necessarily knowing one bit of python.
The program is very verbose so that people can follow what is going on.
Generate a patch using the program, and let's assume this patch is not exactly what is needed and functional, let's call it abad patch
Also generate a patch the manual way that you know works, and let's call this agood patch
Next you would compare the two, the patched boot files can be unpacked and compared.
This can be done on the phone or if you are more comfortable doing it on the PC, you can use the excellent toolkit Android Image Kitchen by @osm0sis
Even a binary diff would give you an idea of the difference.
See further below.
I don't agree with the above generalization, there's always outliers, but in general the community is very helpful, and amazingly patient even with newcomers, what is typically not tolerated is people not putting in the effort to research or even read few posts and expect all the answers to be delivered on a platter.
When a senior member who is well seasoned and knows what he/she is talking about, asks a specific question to be able to offer advise, and it is evaded, it naturally irks the person.
Almost always there is a lot of context in the questioner's mind that is not totally relayed in the post, hence why specific questions are asked and answers expected.
You're not supposed to know, but you find out with exploratory observation, testing, trial and error and of course differential analysis.
For example I didn't know about the KEEPVERITY and KEEPENFORCEENCRYPT flags when I first called boot_patch.sh, and just like you the generated patch was not good and different from a good patch.
I did a binary diff of the two (at the time I didn't even know I could unpack) and noticed those two keywords existing in the good patch, but not mine.
Read up about it, inspected the script, and asked questions to eventually figure out the right options to use to generate an identical patch.
Same with the Magisk32,
Did you get any answer? Absher, Nafath & SNB (Bank) all not working nowIs there anyway to tell if an app is checking for strong integrity? I have 2 apps that stopped working after having to update them and it's because they detect root, but I would like to know if it's strong integrity so I can just give up. The apps names are Absher and Nafath.
Yeah same for meDid you get any answer? Absher, Nafath & SNB (Bank) all not working now
Did you get any answer? Absher, Nafath & SNB (Bank) all not working now
Fastboot temp booting images doesn't work on all devices... Did you try flashing? PWFinally installed Magisk on an ocean (Moto) device with LOS 20.0. With Zygisk active, universal safetynet module, and adding the infamous banking app to deny list, app finally let run instead of complaining "device cannot be trusted, exit".
But there were big problems, which I describe in 2 separate posts.
First, trying "fastboot boot magisk_patched.img" did not work at all.
Fastboot output:
fastboot FAILED (remote: '') # yes, [B]nothing[/B] inside the simple quotes...
Bootloader logs:
incomplete boot image downloaded
I tried with su in PC console, "--set-active=b" just to be sure (albeit it's always slot b, and it already was), different platform-tools versions... NOTHING.
Why is this?
My answer has not changedHowever, still nothing of this would explain my first problem back here:
![]()
Magisk General Support / Discussion
This is the place for general support and discussion regarding "Public Releases", which includes both stable and beta releases. All information, including troubleshoot guides and notes, are in the Announcement Threadforum.xda-developers.com
incomplete boot image downloaded
Is there anyway to tell if an app is checking for strong integrity? I have 2 apps that stopped working after having to update them and it's because they detect root, but I would like to know if it's strong integrity so I can just give up. The apps names are Absher and Nafath.
Check app prerequisites and see if it can run with Android 7 or earlier... If it can they're not enforcing strongIntegrity...Did you get any answer? Absher, Nafath & SNB (Bank) all not working now
Moto edge 30 ultraThat was from a while ago (many magisk canaries). So lets start with basics.
What device
What android version
What other mods do you have
What version of magisk (canary stable beta and number)
What version of usnf are you running
What's in your deny list
All of that will make finding what is being seen by the apps easier . It is HIGHLY UNLIKLY that it is belching on strong integrity nobody to date uses that one, and if, by slight chance they are -which they're not - then the only remedy is to unroot and relock your bootloader and turn off oem debug.
Magisk 25210 is flawed, no mods are enabled or can run. Switch to 25209 or stable. Don't forget to roll back your boot.img too.Moto edge 30 ultra
Android 12
I have magisk alpha 25210 + latest lsposed
I have shamiko and all apps that don't require root added to denylist + google services and store
I use unsf 2.4.0 mod 1.1
I also have hide my applist
snb used to work but stopped after a recent update
He mentioned Magisk Alpha 25210..Not sure do we have active Alpha users who know the up-to-date situation there, bugs and fixes in the recent Alpha releases, etcMagisk 25210 is flawed, no mods are enabled or can run. Switch to 25209 or stable. Don't forget to roll back your boot.img too.
Usnf mod 1.1 was flawed did not kick in soon enough switch to 2.4.0 mod 1.2
Then try and see if apps still are blocked
Oops i read alpha as canary and forgot that there are forks (poorly named imho) alpha and delta. Figured since this is the general thread they were using the general magisk, at my likely mistake.He mentioned Magisk Alpha 25210..Not sure do we have active Alpha users who know the up-to-date situation there, bugs and fixes in the recent Alpha releases, etc
Probably you forgot that I did mention that I tried with ALL the imgs: the bad patch, the good one, and even the original unpatched one. All of them gave that result.My answer has not changed
Inspect the boot file you generated and see how it differs from the expected patched boot file.
incomplete boot image downloaded
This should be a clue.
Yes, I didn't realize that, so basically what you're saying you have a flashing issue, no matter what you try to flash, it does not work, even stock?Probably you forgot that I did mention that I tried with ALL the imgs: the bad patch, the good one, and even the original unpatched one. All of them gave that result.
-Device: OnePlus 8 ProThat was from a while ago (many magisk canaries). So lets start with basics.
What device
What android version
What other mods do you have
What version of magisk (canary stable beta and number)
What version of usnf are you running
What's in your deny list
All of that will make finding what is being seen by the apps easier . It is HIGHLY UNLIKLY that it is belching on strong integrity nobody to date uses that one, and if, by slight chance they are -which they're not - then the only remedy is to unroot and relock your bootloader and turn off oem debug.
From play store info "absher" supports (android 5.0 and up), while "SNB" & "Nafath" supports 8.0 and upCheck app prerequisites and see if it can run with Android 7 or earlier... If it can they're not enforcing strongIntegrity...
Test if app can run on any unmodded (stock, locked) device launched with Android 7 or earlier (can be running later stock Android) or any later device known to have broken keymaster implementation (eg. many OnePlus devices)... If it can they're not enforcing strongIntegrity...
Nb. It is conceivable that an app requiring strongIntegrity might not check for this on certain (whitelisted) devices. However if this behaviour did exist the App would really be compromising the strongIntegrity attestation itself since there should be no way to bypass a failing verdict... Implementing such behaviour would allow any device to bypass the verdict simply by spoofing the device properties of any whitelisted device, rendering strongIntegrity really no better than deviceIntegrity...
PW
Praps not a flashing issue... Not sure if flashing was actually tried... I said:
Fastboot temp booting images doesn't work on all devices... Did you try flashing? PW
... Sorry, I only saw the reference to temp booting magisk-patched image also, per:Probably you forgot that I did mention that I tried with ALL the imgs: the bad patch, the good one, and even the original unpatched one. All of them gave that result.
... If by "I tried with ALL the imgs: the bad patch, the good one, and even the original unpatched one. All of them gave that result" you mean withFinally installed Magisk on an ocean (Moto) device with LOS 20.0. With Zygisk active, universal safetynet module, and adding the infamous banking app to deny list, app finally let run instead of complaining "device cannot be trusted, exit".
But there were big problems, which I describe in 2 separate posts.
First, trying "fastboot boot magisk_patched.img" did not work at all.
Fastboot output:
fastboot FAILED (remote: '') # yes, [B]nothing[/B] inside the simple quotes...
Bootloader logs:
incomplete boot image downloaded
I tried with su in PC console, "--set-active=b" just to be sure (albeit it's always slot b, and it already was), different platform-tools versions... NOTHING.
Why is this?
fastboot boot xxx.img
then you should try flashing... He's talking about OTA, you can't modify OTA, it will fail AVB.What you describe has a good chance of working. When it doesn't work, you will have a good chance of recovering by flashing the unmodified "new" ROM, and continuing as you used to.
J Michael,He said "no OTA updates for me. So I download them from the Google site", which I took to mean he downloaded a full ROM.
I don't understand your reference to "AVB". If he can flash a patched boot image after the system is updated, and if he does indeed have a full ROM corresponding to an updated system, why couldn't the first flash of the updated system be with the boot image patched? (Unless this is one of those systems where Magisk cannot do a complete job of patching unless it is currently running on the target system.)
Before this spins out of control.The angry sir answered with something I already had learned (again, my fault as always...)
And worse, as mentioned in the link, that's NOT it at all. Even other users such as zgfg pointed out this very fact.
...I'll take it as direct consequence of my very being. Devs are clearly unwilling to help.
Thanks everyone else for all your advises. At least the other flags were able to be figured out.
Magisk/manager.sh at master · topjohnwu/Magisk
The Magic Mask for Android. Contribute to...github.com
The angry sir answered with something I already had learned (again, my fault as always...)
And worse, as mentioned in the link, that's NOT it at all. Even other users such as zgfg pointed out this very fact.
...I'll take it as direct consequence of my very being. Devs are clearly unwilling to help.
Thanks everyone else for all your advises. At least the other flags were able to be figured out.
If the "issue" is that you have not yet been able to reproduce the Magisk manager app's "Ramdisk: Yes/No":
Did you try a "wrapper" for the shell script function you found? At the time you reported several script fragments, there was talk of needing to call other functions first to set up environment variables.
Look up the "echo" command. There is a form that causes the shell to echo all lines as they are executed. Do this, redirect output to a log file, and you can crawl through and maybe spot where it first disappoints you.
I'm running into an interesting problem that I can't put my fingers on, and am open to ideas / suggestions.
As you may already know, Magisk embeds the SHA1 of the stock boot image used to create the patch into the patched image, this is great because one can easily determine the source image that was used and validate if it is what it is supposed to be.
And this is exactly what PF does, it extracts the SHA1 from the patched image.
Here's the function code
Python:def extract_sha1(binfile, length = 8): with open(binfile, 'rb') as f: s = f.read() # Find SHA1= pos = s.find(b'\x53\x48\x41\x31\x3D') # Move to that location if pos != -1: # move to 5 characters from the found position f.seek(pos + 5, 0) # read length bytes res = f.read(length) return res.decode("utf-8")
Unlike magiskboot and Android Kitchen Tools by @osm0sis which extracts the ramdisk.cpio and performs magiskboot cpio <ramdisk.cpio> sha1 on it, PF (to keep it lightweight) it just looks for the stringSHA1=
directly on the patched file and then reads the next 8 hex characters and converts them to ascii.
And this has worked flawlessly so far, until this.
Basically what is happening is:
The expected embedded SHA1 is: 40100d6b9512f6dffbb6f6b67c1b878f3bd82d18
With the exception of the red part of the SHA1, everything matches.
In one case 0100 part which is expected to be 30 31 30 30 hex it is instead 89 00 FB 33, and in the other case it is 72 00 FC 15
View attachment 5902493View attachment 5902495
I don't understand why this is happening, my first guess would be some kind of encoding, but then why now and only with this image, my other guess / fear is that perhaps the writing is not clean which would be a bug in Magisk.
Obviously I can skip over the first few bytes and do the validation with the remaining bytes, but I'd hate to take a path like that without understanding why this is happening, who's to say that this thing can't happen on the other portions of the SHA1 string.
If you have any ideas, I'm all ears.
As I expected in advance, problems with Magisk occurred after the OTA update of LineageOS (Pixel 6a).
Updated from a 20.0 build to lineage-20.0-20230429-nightly-bluejay
After the update it was necessary to flash the new boot image again. I have done that. But Magisk simply does not root. Magisk patched the downloaded LineageOS boot-image, saved it in the download folder and that was it.
Magisk was hidden before I did OTA update.
Simply very beautiful. All this after setting up LineageOS to my liking.
And what can I do now except re-flash ROM?