yashsingh1/xdaforums huggingface dataset:
[Magisk] xflowy:
Hey guys,

I wanna try Kitsune Magisk. Am I correct, that I need to flash the ZygiskNext Module to use Zygisk because the built in Zygisk in flawed in latest Kitsune?

What Kitsune would I download then? The R65976974-kitsune (26404) from 2 days ago or 26.4-kitsune-2 from 3 days ago?

The same for ZygiskNext: the debug or normal app version? And what is this Zygisk Symbols?

Also: Can/should I use zygisk next on offcial Magisk?

Thanks a lot!
[Magisk] zgfg:
1) Writing you this from the phone with Kitsune, Zygisk (and No Shamiko)

And no problem regarding Zygisk - LSPosed and PI F work flawlessly

2) Zygisk Next replaces Zygisk. Hence if you want to use Zygisk Next, you must switch off the built-in Zygisk

3) You may have problems with Shamiko on Kitsune.

IDK, I don't use Shamiko on Kitsune (I don't need it)

4) I don't know where this hype that 'Zygisk does not work with Kitsune' comes from

If it doesn't work, Kitsune developer would have simply removed it from gus Kitsune - but obviously he didn't remove I it

However, it seems that many users (specially on TG channels and so - but unfortunately then also even here on XDA) simply do not distinguish Shamiko from Zygisk

Shamiko helps to hide Zygisk. But Shamiko is not Zygisk and does not replace Zygisk

It's like bike and helmet. Helmet protects the head when riding a bike. But one cannot ride helmet instead of bike. And one can still ride a bike without helmet (although risking head injuries and troubles with police)

And quad (like Zygisk Next) can replace bike (Zygisk), and is probably more safe
[Magisk] pndwal:
Nb:

Zygisk-Next-v4-0.9.1.1-189-release Changelog:

...

3. Technical details: Zygisk Next is incompatable with kitsune Magisk's "sulist" feature. This is because Zygisk Next rely on ptrace init to inject into zygote, but it has already been traced by magiskd.

👀 PW
[Magisk] HippoMan:
I don't use sulist in Kitsune, and I simply have the Magisk-supplied Zygisk enabled.

I had no apparent problems with this in Kitsune 26400 and also no apparent problems now with Kitsune 26404, but is there any downside to using Magisk-supplied Zygisk instead of ZygiskNext in these Kitsune versions, as long as there is no use of sulist?
[Magisk] m0han:
+1. (Been away from this device for a while)
[Magisk] J.Michael:
@zgfg says no problem with Kitsune's Zygisk.

I say I can't tell the difference between the strings "Kitsune 26400" and "Kitsune 26400".
[Magisk] HippoMan:
OOPS ... second one should be 26404. Fixing in the original comment.

And thank you.
[Magisk] Compass Linux:
OK, my bank released an update that fixed the crash. I've immediately made a full Neo Backup of this new version just in case it happens again.

Nothing was required on my end to make it work. 🥵

Compass.
[Magisk] pndwal:
To be clear, the Delta/Kitsune inbuilt Zygisk is not TJW Magisk-supplied.

TJW Magisk has now moved to the new implementation of native bridge loading (developed in LSPosed Metagisk and related Magisk test forks).

@huskydg builds were using old Maru native bridge loading POC from 5ec1cff until recently but now uses ptrace+fuse loading from 5ec1cff and Dr-TSNG, which is the same loading mechanism used in ZygiskNext anyway but apparently modified for Delta compatibility...

In view of the above I'm doubtful there'd be any advantage swapping out Delta-supplied Zygisk for ZygiskNext even if it works...

🤠 PW
[Magisk] Candiety:
What's momo? Is that an app that tells you what's being revealed, for the people, or a banking app telling you where you messed up?

Link if the former pleased!
[Magisk] Nergal di Cuthah:
A checker for what's being detected for root (add it to your deny list to start seeing if hiding works).

[solved][question]Where to get momo root checker

I see a lot of people post Momo results, but I'm unable to find where they got it. Github has a lot of momoriru (forks reposts) i use zygisk so i don't believe it is those projects. Get a lot of search results that refer to a momobank app...

xdaforums.com
[Magisk] dipseeet:
R.I.P. Kitsune Mask (?)

Is this real?!

Iam using Kitsune since Magisk Delta but this sh#tstorm happened and now iam confused.

Is it still ok to use Kitsune Mask or should we switch to TJW Magisk?!
[Magisk] sawdoctor:
The GitHub is still up but last commit was 3 days ago. If it's still working then don't worry about it until it doesn't
[Magisk] LostInTheReality:
Did anyone manage to fully hide adb status without ever disabling debugging? After hours of searching I'm still unable. I've tried mods, like I Am not A Developer, DevOptsHide, HideUserDebug, etc. And the most rational solution so far is just to alter init.svc.adbd prop, without using excessive amounts of mods. When testing with Momo, I still do get caught.

Also, what does "partition mounted abnormally" in Momo mean?
[Magisk] J.Michael:
How is it a "rational solution" if it doesn't work?

The person who produces Momo does not explain anything. If he explained the clever way he was detecting, that clever technique could find its way into a bank app.

Security by obscurity cuts both ways.
[Magisk] samhhmobil:
Please excuse me,

this was discussed many months ago, but I can't find it.

S-Check detects root, even if everything is well configured, it detects the unlocked bootloader.

I remember, this could be avoided via resetprop, but I cannot remember the correct syntax for resetprop in this case.

Somebody here, who can help?

Thanks a lot,

samhhmobil
[Magisk] J.Michael:
I searched this thread for "resetprop" and found this post.
[Magisk] samhhmobil:
Thanks. (But this was not what I was searching for.)

I found it:

"resetprop -n sys.oem_unlock_allowed 0"

samhhmobil
[Magisk] Lira2604:
momo shows the notification “found code injection & zygote is injected” when hooked to the xposed module (HMA). How do I make the module still function but not be detected on Momo?

#nb: I use Momo for indicators, because the application I want to hook has the same detection.
[Magisk] zgfg:
Don't use LSPosed modules to hide something from Momo - what you described is a known/discussed issue

Eg, you enable Bootloader Spoofer to Momo, Momo will no more report that Bootloader is unlocked (in the best case) but will also cause Momo to report Zygote injection

Or with Im Not a Developer module (no more sure about the module's name) - it will not hide Debugging Mode from Momo but will also trigger Momo to report Zygote injection

Etc. Don't pay attention to Momo (there was a pretty nasty word for testing with Momo)

---

Besides, there is no point in hiding apps from Momo, hence no point in applying HMA to Momo

Scroll down through your Momo app and read "About the scan" - Momo clearly describes that it does not look for installed apps, hence why would you hide some apps from Momo
[Magisk] Lira2604:
The problem is, the application that I hooked on HMA/Android f4ker was also detected/couldn't be opened. while the application must be hooked for the module function to run, right?
[Magisk] zgfg:
Who says that that app requires HMA. You must experiment with HMA and without, in HMA you have various options - try with Blacklist or Whitelist, try with Vold App Data Isolation, combine, test

There is a thread with general instructions about HMA, please find, read, enjoy😁

Your best bet: will be to search how others solved the problem with that particular app because every app is developed by different developers, with different budgets, goals, etc, hence different apps use different detection methods.

No size fits all

Last but not the least - always start with DenyList, test with Shamiko and without, make sure you pass Play Integrity Basic and Device

Good luck
[Magisk] PH_Android:
Banking apps used to work in December 2023 on my LG VS986 setup using [TODAYS-SEC-PATCH-LEVEL][ROM][UNOFFICIAL][P][UsU/non-UsU] /e/ OS | BYE Google, HELLO Privacy! ROM with Magisk Canary + Shamiko + PlayIntegrityFix (by chiteroman) LSPosed + DevOptsHide. Now they refuse to load. Just getting a blank screen then the phone goes on standby. Phone passes both device and basic integrity using either chiteroman's module or osm0sis' fork and TheFreeman's PIFs. Replacing DevOptsHide with Hide My Applist causes banking apps to detect that phone has been rooted.
[Magisk] osm0sis:
That will change the toggle you see in Developer Options, so really shouldn't be tampered with in any way.
[Magisk] samhhmobil:
S-Check detects root again, it didn't earlier... sigh.

Nevertheless, all my apps are working, so I may ignore that. The system passes device integrity and basic integrity, Magisk (27) is hidden, shamiko is working well, GooglePlay says "Device is certified'.

So everything works as it should.

But why reports S-Check: "Root detection not passed"? And, if one clicks on the "i" it shows: "Error 107|204|250"...

Does somebody knows these error codes and can explain that?

Thanks a lot,

samhhmobil
[Magisk] Spartacus500:
@samhhmobil

In my case, on Android 9.0, Magisk 27.0 + the latest version of Shamiko hides. This is the information that it detects unlocked OEM developer version
[Magisk] zgfg:
You must be passing SafetyNet (test in YASNAC) and turn on NFC and you will have all green like on my screenshot

@samhhmobil

Make sure you have S-Check in DenyList

And I need additionally - you can execute in Terminal Emulator:

su -c resetprop -n sys.oem_unlock_allowed 0

If you eg use Systemless hosts, add

the attached service.sh script to:

/data/adb/modules/hosts

and restart

Actually, I asked long ago in the PIF thread that this resetprop for sys.oem_unlock_allowed would be nice to have among the others in the PIF module's service.sh

@osm0sis - we will be grateful👍
[Magisk] osm0sis:
No, I just explained above why that's a terrible idea...

If you look into it in the slightest you'll see lots of corroborating evidence going way back: https://github.com/kdrag0n/safetynet-fix/issues/160

Any app that looks for that is actually f*cking stupid, because stock *locked* Pixel phones would fail.
[Magisk] zgfg:
No, it does not toggle my setting in Developer Options
[Magisk] osm0sis:
Because you're already allowed and unlocked. What it does is hide that toggle or gray it out. It's still a stupid, bad idea to tamper with it, and any app that looks for it is stupid and bad. See my previous post.
[Magisk] zgfg:
If somebody did not allow OEM and did not unlock BL - then he would not run Magisk and your module, so how would you tamper then his OEM unlock?!

Please test on your phone, to see does it stay the same

And one thing, service sh waits for booting to complete, hence it gets changed afterwards - IMO, that's important here

And the change is Systemless - hence it's active only in System with Magisk - not in Bootloader

Btw, it's from Husky's Sensitive Props module - thank to him, he found that originally
[Magisk] samhhmobil:
Thanks!

Yes, of course, safetynet is passed.

Yes, of course, device integrity and basic integrity are passed.

Of course, S-Check is in denylist.

Of course, I made the "resetprop ..." manually before.

Thanks for your script.

Yes, I use "systemless hosts" (for AdAway).

Nevertheless, even with your script, the result is the same, "root detection not passed".

This is, since I upgraded my Xiaomi Mi10Tlite from Lineage19.1 (Android12) to Lineage20 (Android13). As long as it was on A12, all was green.

There must be another gimmick which is detected by S-Check now.

Thanks again, but maybe here is somebody, who knows the error codes of S-Check??

samhhmobil
[Magisk] osm0sis:
To repeat myself, again, on a stock *locked* Pixel phone `getprop sys.oem_unlock_allowed` will have a value of 1, because Pixel bootloaders are designed to be unlocked, so why in the world would we ever need to change it to 0? Any app that is looking at this value is fundamentally flawed, or more succinctly, stupid and bad.
[Magisk] LostInTheReality:
Apps checking for other installed apps is also said to be incorrect but if it happens then something needs to be done about that to hide traces. If not choose not to root whatsoever.

My banking apps also check for sys.oem_unlock_allowed. For a long time now I've had it set to be altered as a late prop. No issues, the toggle in Developer options is present and my apps stopped complaining. Fastboot allows flashing images. Had this been more talked about, I wouldn't have wasted my time searching online what gives away root.
[Magisk] osm0sis:
So your banking app only technically works on phones that don't even have the option to ever be unlocked? I'm sorry, but that's f*cking ridiculous...
[Magisk] pndwal:
This is strange... Bootloader on Xiaomi devices are also designed to be unlocked, but sys.oem_unlock_allowed value is 0 until Dev option OEM unlocking (allow the bootloader to be unlocked) is toggled on... I thought it was off for all devices until user decides to allow unlocking...

Google indicates that things are supposed to work this way too:

https://source.android.com/docs/core/architecture/bootloader/locking_unlocking

So are you sure that

?... Cos if Pixels do require user to toggle on OEM unlocking to allow unlocking like other devices (and sys.oem_unlock_allowed value is initially 0), rather than

, this would be expected behaviour from banks, and would logically be fairly common practice as seems to be the case... 😬

In relation to this:

Maybe you're thinking of this property?:

... But if that were set to 0 in the first place, we'd never have been able to set it to 1 I guess, so debating setting that back to 0 is... lets say an exercise in futility. 😉

Anyway, toggling OEM unlock off sets sys.oem_unlock_allowed back to 0 and that's enough to make some bank apps I've tested happy... If set to 0 via reset prop however, toggle in Dev settings is still set to 'allow' (on) which is misleading as altering the prop value doesn't affect/set the toggle... Toggling off then on sets sys.oem_unlock_allowed back to 1 however...

I don't think @Displax's request to have this merged in @kdrag0n USNF with his fairly comprehensive 'patch set' was knocked back (initially opposed by @huskydg) because it was really that bad of an idea... While @kdrag0n did mention Pixel in his response agreeing that it shouldn't be added, it seems his concern was regarding users being mislead about Allow unlock status by the toggle still being set to 'allow' (on) when deciding to re-lock device:

https://github.com/kdrag0n/safetynet-fix/pull/240#issuecomment-1368867689

I also think (just conjecture) that he may be muddling scenarios a bit in that comment however - eg all devices this could affect can necessarily be unrooted and re-locked, not just Pixels... I think he probably had re-locking Pixels with custom keys and modifications (although he didn't state that, this is a re-locking scenario that "may not hold significance on some devices") in the back of his mind since it's critical that sys.oem_unlock_allowed remains set to 1 in that circumstance, especially with root, to avoid hard brick as a number of factors could conspire to prevent both recovery and fastboot modes from working to recover device per:

https://github.com/chenxiaolong/avbroot#warnings-and-caveats

... Until a user goes to re-lock device I don't know of potential problems with sys.oem_unlock_allowed set to 0, but the misleading toggle is clearly a concern...

Personally, I don't know why users don't seem to consider simply toggling off OEM unlocking in Dev Options; this works fine (as I've indicated) for my Xiaomi devices anyway and prop will match toggle so not be misleading... I think this is the same solution @kdrag0n proposed too:

https://github.com/kdrag0n/safetynet-fix/pull/240#issuecomment-1368868394

🤠 PW
[Magisk] osm0sis:
If there's any chance it affects what's actually stored in the FRP partition (which is where the bootloader checks get_unlock_ability), then I don't want to be potentially responsible for any hard bricks. That's what it comes down to.

Setting it with the toggle definitely affects the FRP partition and therefore could lead to hard bricks if relocked, and from what you're saying there does seem to be more of a disconnect between the sys prop and FRP than I thought, but I'm still not sure it's worth the risk, same as those before me.
[Magisk] pndwal:
Well that's a better reason and it seems it may (likely) have been one of @kdrag0n's concerns too... And I indicated I'm certainly not advocating for such an addition either...

I simply clarified some apparent misconceptions you had (banks/apps may not actually be "fundamentally flawed, or more succinctly, stupid and bad" to detect the setting and the detection would not 'only technically work on phones that don't even have the option to ever be unlocked', stock *locked* Pixel phones not shipping with sys.oem_unlock_allowed set to 1 and banks not being 'f****** ridiculous'; they might actually be applying proper understanding of the props function)... Sorry, but it may be helpful.

Also I suggested the obvious solution for many (all?) users with apps detecting this setting:

Just toggle off OEM unlocking in Developer Options manually

... And turn off Dev Options again if that's also detected!

Hope the disambiguation between prop functions may be helpful to some here too... 🤷 PW
[Magisk] shoey63:
This is fraught with danger for users who flash self signed roms and re-lock their bootloader.

If you flash an unsigned image in user space (eg. by direct install of an incorrectly signed magisk patched image) and corrupt your device and lose recovery, you have a hard brick.

Can't enter recovery to sideload an ota.zip and can't unlock the bootloader to flash factory images.

Edge case scenario, but still . . .
[Magisk] pndwal:
Just saw this...

Not sure if either are better for FRP... Long time since I've looked at that anyway...

The issue is re-locking and users should check Allow unlock (OEM unlock) status in Dev Options before doing that so the real concern is adding such a change in module as toggle would be misleading when user checks... This is just the right reason not to do it...

Users can set the toggle themselves, and remember to check before re-locking, especially yellow...

I agree, Don't do it, not worth the risk... PW
[Magisk] pndwal:
Covered that above, and it's a principle reason to set by toggle (not misleading) rather than set in prop:

... Of course user needs to remember to check/re-set OEM Unlock toggle to allow unlocking before going yellow (most here are only concerned with orange state), but they'd be very remiss not to check that and toggle will be off, not on (user assumes it's really on but sys.oem_unlock_allowed is 0) but really off, which is really fraught.

🤠 PW
[Magisk] PH_Android:
Fixed it by reverting to Magisk Stable instead of Canary plus all other modules from December 2023 setup (no Hide My Applist), then removing the name "magisk" in files and folders in the /system/addon.d, /cache, and /data/magisk_backup_xxxxxx folders, before clearing storage of the banking apps and then patiently wait for them to start.
[Magisk] J.Michael:
Did you change the name of "data/magisk_backup_xxxxxx"?
[Magisk] PH_Android:
Yes, removed "magisk_".

Forgot to add in my last reply: I activated airplane mode before clearing storage of banking apps, booted to TWRP (recovery), wiped cache and dalvik_cache, restart system, then start the banking apps.
[Magisk] Cipcino81:
Hello guys,

I have installed new shamiko version 1.01 on Magisk 27 and this triggers safetynet / play integrity. I have tried various Magisk modules play integrity fixes but nothing works. Version 1.00 is the same, so I have reverted to shamiko v0.75 that works without any other module. Have you tried to install version 1 of shamiko on Lineage os 18.1 Tomoms unofficial rom for OnePlus one? Do you know any combination to make it work ? Thank you.
[Magisk] pedritopl:
Same here on OP3T with LineageOS 18.1 & Magisk 27.0.

Shamiko 1.0.0 & 1.0.1 -> no play Integrity.

Shamiko 0.7.5 or no Shamiko - basic & device integrity.

Maybe it's something OnePlus + LineageOS specific that newer Shamiko breaks?
[Magisk] Nergal di Cuthah:
There's also evidence of a mass banning, of fingerprints for play integrity, this week.
[Magisk] pedritopl:
I suppose You mean the banning based on kernel local version? That I had to overcome by modifying the kernel version string before testing different Shamiko versions.

BTW: this was also discussed here: https://xdaforums.com/posts/89324605/
[Magisk] Nergal di Cuthah:
Nope fingerprint banning yesterday and today
[Magisk] pedritopl:
OK, now I see people reporting it. Anyway, mine works on my devices for the moment. Including that OP3T with modified kernel version string and Shamiko 0.7.5. Only newer Shamiko versions cause problems.
[Magisk] Cipcino81:
I had not to modify my kernel by the way. That maybe is because I use the unofficial lineageOS with a different kernel than the original one I suppose.

I hope someone can shed some light into Shamiko 1.x versions incompatibility with our rom. Is that device specific or it is the same with every lineageos 18.1 based device?
[Magisk] osm0sis:
My OnePlus 9 Pro on Lineage 20 with Magisk 27001 and Shamiko 1.0.1 still works. You guys being on Lineage 18.1 does seem like a bit of a common denominator however. 🤔
[Magisk] Cipcino81:
Maybe it is worth to report it to shamiko developers, but I am not able/know how to do it
[Magisk] osm0sis:
Would need more evidence first. Not worth reporting anything to them until the conflicting setup is confirmed.
[Magisk] Cipcino81:
Yes , you are right. If anyone that is using lineage 18.1 would have some time to do some tests, please can you test if Shamiko 1.01 module broke play integrity for you too?
[Magisk] sawdoctor:
Shamiko and lsposed Devs have halted development due to a disagreement with another well known dev
[Magisk] HippoMan:
I read somewhere that the LSPosed folks *might* resume their support after the full lunar New Year celebration period is over.

I don't know how valid this information is, but I hope they do resume support.
[Magisk] sawdoctor:
I hope so too. There's an active fork of lsposed but it's still broken on the latest QPR3 beta
[Magisk] fillwithjoy1:
github
[Magisk] fillwithjoy1:
i'm not sure about that - they have been under fire when someone exposed them for harassing other projects and creating a unique method of detecting lsposed (thats currently unpatched).

but who knows
[Magisk] samhhmobil:
Does somebody knows, what happens with the german Payback app? Up to Version 23.11.1403 it did work without any root check. Now it refuses to work since end of January'24 (since version 24.xx.xxxx), even if my magisk-configuration is clean and other root-detecting apps are working flawlessly.

payback app deutschland - Android Apps on Google Play

Enjoy millions of the latest Android apps, games, music, movies, TV, books, magazines & more. Anytime, anywhere, across your devices.

play.google.com

Any help is appreciated.

Thanks a lot,

samhhmobil

Edit:

It seems to be fundamental... I tried it yet on my spare phone (Sony XA2(pioneer), factory reset, freshly installed LineageOS 21 A14, NOT rooted, no magisk, no other suspicious apps), and even Payback refuses to work, it says, system is modified. Sigh!
[Magisk] Spartacus500:
@samhhmobil

This is what I have after installing it 24.02.0100

Then in Magisk 27.0 stable I added the application to denylist and it works 🙂
[Magisk] samhhmobil:
Absolutely great.

So I need your assistance, about your magisk (and modules configuration).

I have:

- Xiaomi Mi10T lite (gauguin),

(- spare phone Sony Xperia XA2 (pioneer)),

- LineageOS 20 (A13),

(- sparephone XA2: LineageOS21 (A14)),

- Magisk 27.0 (hidden, of course),

- Shamiko 1.0.1,

- Busybox 1.36.1,

- PIF 15.7.1 (chiteroman),

- MHPC 6.1.2-v137 (for working fingerprint of this Xiaomi),

- /system/addon.d/99-magisk.sh renamed to rubbish,

- Payback is in denylist, of course.

It seems, it does not try to detect root by itself, but by basic modifications (open bootloader, custom rom, or something like that). What did I forget?

I'll try that on the spare XA2 at first.

Thanks,

samhhmobil