yashsingh1/xdaforums huggingface dataset:
[Magisk] uschipower:
Is this really a xiaomi-device?

Do you really run android 8?

Is this a device-specific custom rom, or a treble-custom-rom of LOS?

I have renamed addon.d in /system and twrp in /storage/emulated/0

But Momo still shows custom-rom, and many banking-apps do not work

I have 3 devices:

- SM-T550 running custom ROM: LOS 18 from user @retiredtab. This is a device-specific rom

- TB-X505F running Treble-GSI-ROM, LOS 20 from user @AndyYan

- TB-X605L running Treble-GSI-ROM, LOS 20 from user @AndyYan

Non of these Roms have

/vendor/bin/install-recovery.sh

Momo and banking-apps discover CustomROM

which version of shamiko do you use?

I am using 1.0 290 and it seems that it is not working with magisk kitsune (ex delta) --> message unsupported environment

shamiko Shamiko v0.7.5 seems to work with magisk kitsune, but it doesnt hide ""init.rc is modified"
[Magisk] simplepinoi177:
why don't you use PIF 15.1 or 14.6, or even Play Integrity Next? (because I think I read that you were using PIFork...)
[Magisk] sawdoctor:
Have you asked the ROM maintainer if they have changed anything
[Magisk] xcl1pse:
Try on /system/bin/install-recovery.sh? Also shamiko can't hide init.rc IIRC. This maybe due to /vendor/etc/init which are prebuilt in your rom
[Magisk] osm0sis:
Must be it! Can you post the whole script file? I'm curious what the other hex patches do.
[Magisk] xcl1pse:
bootloader_prop=/dev/__properties__/u:object_r:bootloader_prop:s0

/data/adb/magisk/magiskboot hexpatch $bootloader_prop 756E6C6F636B6564 6C6F636B65640000
/data/adb/magisk/magiskboot hexpatch $bootloader_prop 6F72616E6765 677265656e00
/data/adb/magisk/magiskboot hexpatch $bootloader_prop 013100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000726f2e626f6f742e77 013000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000726f2e626f6f742e77
/data/adb/magisk/magiskboot hexpatch $bootloader_prop 013000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000726f2e626f6f742e66 013100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000726f2e626f6f742e66
}&

Put this in the end of service.sh file. Honestly I never try this since resetprop problem already solve in my end
[Magisk] EuK_V:
The same shamiko behavior here and cannot hide "init.rc is modified", but in my case (redmi note 9 pro, official LOS20) renaming /system/addon.d did the work, no "custom rom" in momo.
[Magisk] DanGLES3:
Good to see my hexpatch script i shared on telegram is spreading, making these is annoying and tbh, current script doesn't patch every possible property i mainly patched the ones relevant to my device so there's very likely props in other devices that don't get patched by this script

this script only changes properties with the value unlocked to locked, orange to green and it also sets the warranty bit property of samsung devices to 0
[Magisk] DanGLES3:
Well, i've been the one responsible for making the hexpatched props (at least the one being spread on the modified play integrity modules), so you can ask me about it if you want
[Magisk] xcl1pse:
Never know your the first maker lol, but I never tested this so
[Magisk] DanGLES3:
Tbh i've gotten the inspiration from an example script sent to me by the Magisk Delta dev and i worked off of his example to create hexpatch for more properties and incorporated it into the module

Hexpatch is viable for most ro. props as long as the prop value/text you want to replace doesn't have more characters than the original value (less is fine tho)
[Magisk] pndwal:
If ROM 'fix' clashes with PIF but works, just don't use PIF!...

With root you only need to hide that from GMS, specially DroidGuard (attestation) and main processes... You know how don't you?... Just add Google Play Services processes com.google.android.gms.unstable and com.google.android.gms to denylist ... And don't forget to uninstall PIF! 👀 PW
[Magisk] pndwal:
Xiaomi Mi Pad 4

No. 🤔... LineageOS 18.1, Android 11...

Yes, the former.

Maybe your have /vendor/bin/install-recovery.sh as mentioned here:

or something else... I didn't... Renaming addon.d (to baddon.dog) in my case was enough to bypass custom ROM detection...

1.0 290

26404 Magisk is required... Are you using Delta/kitsune 26404 ('Canary')?

🤠 PW
[Magisk] wyt18:
Delta/kitsune 26404 (R56976974) doesn't seem to work with Shamiko 1.0 290 ... I get the same message of "unsupported environment"
[Magisk] dosbuddy:
Just for you information:

I am still on chit-PIF v14.0 with my first custom FP (end of Nov 2023). I have some more as backup.

Today I tested successfully @osm0sis migrate.sh with my FP in use.

I can confirm, that the script works perfect in an Windows-Cygwin-bash-environment.

So you don't rely on linux or termux here.

For those who are interested in Cygwin see here.
[Magisk] ipilcher:
Don't conflate rooting with unlocking the boot loader. Plenty of us would be (were) perfectly happy running non-rooted custom ROMS before a bunch of lazy app developers discovered SafetyNet/Play Integrity and decided to start using it with no actual understanding of security.

The only reason my phone is rooted is so that I can pass Play Integrity for apps like American Airlines, Now for Reddit, and SpotMe (none of which have any actual reason for requiring it). Ironically, this prevents me from running the Marriott Bonvoy app, which ran fine before I was forced to root.
[Magisk] V0latyle:
That's fair.

I'm not totally sure what a custom ROM would need to utilize these fixes. Is it as simple as replacing props with values from useable fingerprints? This has the obvious issue of putting more traffic on specific prints, increasing the liklihood they get banned
[Magisk] GabbyWC:
The release notes for Shamiko v1.0 mention that it hides Zygisk from that particular app. This requires a newer version of Magisk than the current stable release, however.
[Magisk] ipilcher:
I'm aware of Shamiko, but there's no way I'd ever install a Magisk/LSPosed module that isn't open source.
[Magisk] EuK_V:
Shamiko isn't open source?
[Magisk] Umgak:
It isn't. The repo just has a json file for magisk updater and a changelog. Fully-built binaries are directly uploaded to the releases. Idea being that it's a lot harder for people who want to detect Shamiko to reverse engineer it and see what it does.
[Magisk] ipilcher:
Nope. Look through the GitHub repo, and you'll only see a few configuration files. The "source" ZIPs have the same (minimal) content.
[Magisk] EuK_V:
@Umgak, @ipilcher as I see hiding root process goes differently on different phones/android versions/for different apps. In my case when I use official magisk I need shamiko for some banking/gov apps here in my country and whereas with magisk delta I don't need shamiko, magisk hide list does the work. But it's just here in my country and things change from version to version - I always need to test the new versions, that's why I update very rarely.
[Magisk] jeffyh:
"Google 2FA prompt devices" no longer seems to show on a device where pif was used. I also get some interesting info in the 2FA prompT devices page where there are devices such as "acer c01 added 600+ days ago". After the safety net deprecation day, I installed PIF the same day as some google apps updates. I'm still trying to figure out which aspect caused it. Would PIF cause 2FA prompts to no longer work?
[Magisk] Nergal di Cuthah:
It shouldn't cause that, i got my 2fa when i signed into google yesterday, osmosis fork, custom fingerprint i got from a rom dump on xda.
[Magisk] jeffyh:
Thanks, your comment might've narrowed it down.

i saw the note about the fingerprint, but not having any understanding of it, skipped it as the fix seemed to work fine. I'm starting to wonder it's the fingerprint i didn't do as the 2fa prompt devices dashboard seems to show "acer c01" which is the the default pif.json device. I guess that plays into how the google 2fa prompt devices system works.

For others' reference

🔧 [MODULE] Play Integrity Fix (SafetyNet fix)

PLAY INTEGRITY FIX This module tries to fix Play Integrity and SafetyNet verdicts to get a valid attestation. BEFORE YOU START: - Your ROM must be signed with a private key from maintainer, you can check with this command: unzip -l...

xdaforums.com
[Magisk] arda99:
This means the rom does the spoofing by default, or, you'll have an unlocked BL and can't pass device.
[Magisk] jeffyh:
okay, yup. the pif.json/custom-pif.json used for device spoofing does affect google 2fa prompt devices as well as find my device

2FA prompt devices dashboard in myaccount.google.com was showing "acer c01"; The value in the packaged `pif.json`. Using @osm0sis script (thank you btw) i generated a throwaway `custom.pif.json` using my current devices build.prop(s). The prompt devices dashboard immediately reflected the new `custom.pif.json` `MODEL`. This is somehow causing 2FA prompts not to show on devices with PIF.

Regarding find my device, the device id'd by IMEI will show up on the list, but trying to take action (eg - play sound) won't do anything.

Don't know if this is specific to my environment but this seems like a bigger thing with how google designed it's systems. I wonder what else in the google ecosystem doesn't work because of this.

I love that PIF works and the dev skill behind it, but I guess using a device that bypasses security to perform security related tasks doesn't really work. That tracks, haha.

LMK, if i'm completely off base or if these things are working for you.

- FOLLOW-UP -

I had a friend running stock pixel rom with PIF (packaged pif.json) try find my device play sound and it worked for him. Only difference between our phones is that i use lineage. ¯\_(ツ)_/¯
[Magisk] Nergal di Cuthah:
Could be. I'm also on pixel with stock os. There have been reports of strange devices showing up in google services (including a pixel i think running stock), but I've not experienced that.
[Magisk] ipilcher:
I'm using PlayIntegrityFork v3 on LineageOS 20, and Find My Device seems to work just fine. (Just tested the "play a sound" function.)
[Magisk] arda99:
I noticed the device identification issue a while back but it doesn't affect anything here.

anyway, the fix is easy: as I've several google accts in my phone and the first acct. shows correct info other shows spoofed model.

Turns out google remembers and uses the fingerprint at the time of login, and still consider the phone as same device after PIF fp changes. So just log out and re-login with PIF disabled...it should get correct device now. Enable/mess with PIF later wouldn't change it.
[Magisk] jeffyh:
Thanks, that worked for find my device. 2FA prompt devices is just broken though. It didn't work with logging in with PIF disabled either. Maybe it's something else.. Google support did tell me to give any device changes there 7 days. If that's true, considering the device model updates immediately, 7 days is a long time to propagate across their servers
[Magisk] WhoIsJohnGalt1979:
lol, finally!, for almost a couple of years I have been informing users not to setup their phone without logging into google and root and use USNF/PIF. What happens in effect is, in "Manage your google account - Security - Devices" the spoofed device name shows up. Many people who I worked with (took me a lot to convince them to try it out) were surprised when they saw that, and then started logging into their google account first and then root and use USNF/PIF. Additionally, if you are logging into two google accounts lets say in gmail, you end up seeing the spoofed device name show up under security-devices for the second account. Thank you for posting this. Most of my posts on this were ignored in the past lol. If I remember correctly there is a third way the spoofed device shows up in Security - Devices in google account is you add a google component except for wallet in the deny list (whis is not required). I think this is what @pndwal had written "I believe that would have been caused by MHPC module left enabled with Force BASIC key attestation (superseded by USNF) enabled. Default setting will set ro.product.model value to a pre-keymaster 3 (pre Android 8) device from the same OEM. 👀 PW"
[Magisk] Umgak:
Unable to repro any of the stated concerns over here. OnePlus 9 Pro on Lineage 20. Find my phone works (including sound alerts), Google 2FA works and shows "OnePlus 9 Pro 5G." The phone I'm spoofing also shows up in find my phone and in my account, but that's expected as I am actually signed into that phone - it's on my desk.

I did have this issue back in the day with MHPC, because that was global spoofing, but it hasn't personally been an issue since the USNF days.
[Magisk] jeffyh:
Thanks for checking. Happy to know that PIF works and will be putting it back after I reflash. Sorry for the noise OP
[Magisk] Rom:
@chiteroman I just test your last version on my OnePlus device (i did get the fingerprint unlock function issue with previous versions), apparently it's works successfull with last MagiskHide Props Config and last Shamiko modules. I get the certification message in the Play Store "About" section.

Thx for your work (y)
[Magisk] Umgak:
Shouldn't need MagiskHide Props Config - it's deprecated and its method of spoofing is considered inferior to USNF/PIF.
[Magisk] droidman1992:
Play integrity next no longer appears to work at all, the fingerprint is banned and using the gms.apk to pull a new one is not working.
[Magisk] Yellow571:
Not every fingerprint PIF-Next pulls will work AFAIK, it's trial and error until you get one that works.
[Magisk] Umgak:
PlayIntegrityNext just pulls the same one that Xiaomi.eu uses. You're thinking of the PIFS project by @TheFreeman193

May want to try again. Looks like PINext decided to null the entire JSON file for a couple hours... for... some reason.

EDIT: Someone forgot to add any error checks.

https://github.com/daboynb/autojson/actions/runs/7428838254/job/20216667443
[Magisk] RichyRicho:
Deleted
[Magisk] Yellow571:
Whoops, thanks for pointing that out for me!

On another note, I've fixed my issue from earlier by switching to Magisk Canary and adding the latest Shamiko as well as downgrading to an older version of Snapchat. Logs in fine now! Definitely going to backup the app's data in case it locks me out again.
[Magisk] pndwal:
You do know that this module went closed source for a while recently right?... The idea was similar to the one given here:

but I'm not sure that this is actually true of reasons for closed source Shamiko although I'm aware of the supposition... To clear/fair, @canyie's original reasons were all about abuses by other modders in fact, per comments here:

https://github.com/canyie/Riru-MomoHider#deprecation-notice

👀 PW
[Magisk] bleh815:
Same here. Find my device, 2FA notifications et.all. working fine. lineageOS 20-20231215-NIGHTLY-panther (Pixel 7), Magisk 26.4, PlayIntegrityFork v5
[Magisk] DanGLES3:
Revisiting this, the actual method used for resetprop detection has been made somewhat public by the Shamiko developers, with that information it should now be possible for Magisk forks like Kitsune to more properly fix it in the near future without the need of hexpatching
[Magisk] osm0sis:
Link?
[Magisk] DanGLES3:
Magisk alpha

You can view and join @magiskalpha right away.

t.me

It's on Alpha's Telegram page, it needs to be translated but it in short the issue is Resetprop increasing a counter that indicates how many times a property has been changed
[Magisk] WhoIsJohnGalt1979:
English translation of what was posted in Telegram

Expose two methods for detecting resetprop:

Operating property through setprop/getprop and other means actually operates files located under /dev/__property__. According to the respective SELinux Context storage of properties, the same context is grouped into a group and stored in a file. Each file size is fixed 128KB. Objects such as prop_bt prop_info that need to be used are implemented by a linear memory allocator. Each time memory is allocated, the address is simply bumped and memory release is not supported. More details can be found at https://blog.canyie.top/2022/04/09/property-implementation-and-isolation/

When Magisk's resetprop deletes a property, it will null the reference to prop_info in prop_bt, and then clear the entire prop_info memory. The problem occurs here. The memory of prop_info is cleared but not released, which results in a large empty area in the corresponding memory location. By detecting this, the application can detect that an attribute in the corresponding attribute area has been deleted, and then infer that the device has been rooted (because under normal circumstances, the property does not support deletion).

When does the deletion occur? When resetting ro through resetprop, which is a read-only property. The multiple properties that store the bootloader lock status, the ro.dalvik.vm.native.bridge that stores the native bridge, and the frequently modified device fingerprint are all read-only properties. In other words, unless you avoid modifying these attributes, they will be detected. Failure to modify the attributes of the bootloader status will cause "unlocked" to be stored directly in it, which can be read by the application.

After https://github.com/topjohnwu/Magisk/commit/f41994cb52ca08856216a8da0a28ed148c833f4e, as a side effect, the above problem has just been alleviated, but there is another problem:

There is a field on prop_info called serial. When this prop_info is updated, serial will increase by 2. That is, the number of times prop is updated = serial / 2. As for the ro attributes, they are read-only and cannot be updated at all under normal circumstances, so serial should always remain 0. In other words, if you find a read-only property where serial is not 0, it means that it has been resetpropped.

Our investigation found that there are already applications using these methods to detect root, and Shamiko 1.0+ has done its best to hide relevant traces. I know that many people are reluctant to use Shamiko, and the developers of other hidden solutions do not know these two detection points and have no way to deal with it, so I made it public.
[Magisk] osm0sis:
Love how we're all figuring this stuff out at the same time haha
[Magisk] fede2782:
I have some old phones (2015-2016) and they have stock rom, never rooted and locked bootloader. I was using on my device a fingerprint of these but now Google banned it and it seems that original devices have lost play certification too. Could these two things be related or maybe it is a temporary issue?
[Magisk] dmenezes:
A strong +1 to that.
[Magisk] droidman1992:
Well it looks like play integrity next does in fact work. For some reason it didn't pass immediately and when I rechecked in the morning all was passing.
[Magisk] dmenezes:
Today, it's been 35 days since @chiteroman's PlayIntegrityFix v14.0-resetprop + my first (and so far, only) self-mined fingerprint gave me back DEVICE, and it's still working:

View attachment 6052442

So, I don't think it's going to break anytime soon, and instead I'm thinking I can kinda relax and stop checking this thread so obsessively 😁

My plan is to come back when/if it breaks. If anyone here needs to talk to me, please send me a PM -- and if there's something you folks think I need to see, please @-MENTION me, and TIA for that; I get email notifications for both and will come if summoned.

Before leaving, I just want to say an emphatic "thank you" again to all the gents here, and to @chiteroman, @osm0sis, @badabing2003, @TheFreeman193 and all the other devs specially, for making it possible for me to get to this point.

You all rock! 👍
[Magisk] Umgak:
As mentioned here, the script that PINext uses errored out and ended up writing a file filled with nothing but null to the repo, which ended up staying for a few hours. When it came back (with the exact same print) and your phone retested for Wallet it started working again.

EDIT: It happened again.

Update pif.json · daboynb/autojson@92ed238

Contribute to daboynb/autojson development by creating an account on GitHub.

github.com
[Magisk] xSnowLeopardx:
Wholeheartedly agree with this entire comment.
[Magisk] Yusef Kifah:
2 weeks-ish since using a working fingerprint. Still passing Device on LOS20 for Oneplus Nord. All payments work. Great job devs and all involved!

Let's see how long this lasts. Any bets? 😜
[Magisk] EuK_V:
In my case (official LOS20) renaming/moving:

/system/addon.d - is hiding "custom rom",

/vendor/bin/install-recovery.sh - is hiding "init.rc is modified" in Momo:

If I use @chiteroman's Bootloader spoofer it's hiding unlocked bootloader from Momo, but since it's enabled for Momo it leaks that it's Lsposed module and Momo sees "Zygote is injected":

View attachment 6052493

EDIT: Magisk kitsune canary, no Shamiko.
[Magisk] niko26:
What's Momo?
[Magisk] EuK_V:
An app. Root-Magisk detector, one of the hardest to hide from.

EDIT: it's basically does the same thing that many banking apps do - detects root, so it can help figure out what some banking app might detect and give a starting point to find out how to hide it. So if you hide from Momo, you may also hide from banking apps, but there is no 100% guarantee.
[Magisk] niko26:
Do you have a link? Couldn't find it in any trustworthy source.
[Magisk] Umgak:
[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] osm0sis:
So, Dan, I made this today...

# resetprop_hexpatch [-f|--force] <prop name> <new value>
resetprop_hexpatch() {
case "$1" in
-f|--force) local FORCE=1; shift;;
esac
local NAME=$1
local NEWVALUE=$2
local CURVALUE=$(resetprop "$NAME")

local NEWLEN=${#NEWVALUE}
local CURLEN=${#CURVALUE}

[ "$NEWLEN" -gt "$CURLEN" -a ! "$FORCE" ] && return 1
[ "$NEWVALUE" = "$CURVALUE" ] && return 1

local PROPFILE=$(resetprop -Z "$NAME")
local HEXNAME=$(printf "$NAME" | od -A n -t x1 -v | tr -d ' \n')

#<hex length of prop value><prop value + nul padding to 92 bytes><prop name>
/data/adb/magisk/magiskboot hexpatch "/dev/__properties__/$PROPFILE" \
$(printf "%02x" "$CURLEN")$(printf "$CURVALUE" | od -A n -t x1 -v | tr -d ' \n')$(printf "%$((92-CURLEN))s" | sed 's/ /00/g')$HEXNAME \
$(printf "%02x" "$NEWLEN")$(printf "$NEWVALUE" | od -A n -t x1 -v | tr -d ' \n')$(printf "%$((92-NEWLEN))s" | sed 's/ /00/g')$HEXNAME
}

As you can see I left it only operating on values of equal or lesser lengths, but any reason you know of that it couldn't handle them, considering I'm patching the length byte and adjusting the padding as well? 🤔🤠

Edit: There, updated to guard longer values behind a -f (or --force) argument, so people can test it if they like. 👍🤞
[Magisk] DanGLES3:
Afaik increasing the value length could mess some padding in the property memory space, tho not sure if that could cause any issues or not, I was simply originally advised not to try that
[Magisk] GabbyWC:
https://apkcombo.com/momo/io.github.vvb2060.mahoshojo/

This is where I downloaded it from. The file hashes match those of the APK from XDA and Telegram so the file is safe.
[Magisk] osm0sis:
But I adjust the padding length as well, so... maybe fine?
[Magisk] DanGLES3:
If you want to risk it, never tried it but go ahead if you feel confident

By the way, nice work on that script
[Magisk] DanGLES3:
Tho, I'm wondering whether it's be feasible to make a boot script that does what Shamiko does

As in fixing Resetprop detection of all modules (as in clearing the counter for all resetproped props without modules needing to explicitly use the script themselves)
[Magisk] HippoMan:
I'm totally with you!