[BUG - Magisk Canary 27008] Customize.sh doesn't working as expected

[diabl0w]

There is no config.txt target.txt not getting updated

[joeyoropesa-dev]

There is no config.txt target.txt not getting updated

Hello @diabl0w Could you tell me more about your bug.

I need these informations:

• Root manager:
• Root manager version:
• ROM:
• Device model and responses of these commands:

  :/ $ su
  :/ # cat /data/adb/tricky_store/tee_status 
  :/ # uname -a

• Screenshot of the getkb response (Look at README.md to know how to execute getkb)

[diabl0w]

There is no config.txt target.txt not getting updated

Hello @diabl0w Could you tell me more about your bug.

I need these informations:

• Root manager:
• Root manager version:
• ROM:
• Device model and responses of these commands:

:/ $ su
:/ # cat /data/adb/tricky_store/tee_status 
:/ # uname -a

• Screenshot of the getkb response (Look at README.md to know how to execute getkb)

RootManager: magisk canary 27008 Commands:

:/data/adb/tricky_store # uname -a
Linux localhost 5.4.233-qgki-27940246-abF926BXXS6GXBD #1 SMP PREEMPT Mon Mar 4 10:48:57 KST 2024 aarch64 Toybox
:/data/adb/tricky_store # ls -la
total 14
drwxr-xr-x  2 root root 3452 2024-09-26 04:27 .
drwx------ 11 root root 3452 2020-02-06 12:07 ..
-rw-r--r--  1 root root 7513 2024-09-26 04:22 keybox.xml
-rw-r--r--  1 root root  155 2024-09-26 04:24 target.txt
-rw-rw-rw-  1 root root   15 2024-09-26 04:39 tee_status
:/data/adb/tricky_store # cat tee_status
teeBroken=false

getkb isn't going to work as you don't have a "system/bin" folder in your module, you only have "bin"

[joeyoropesa-dev]

There is no config.txt target.txt not getting updated

Hello @diabl0w Could you tell me more about your bug.

I need these informations:

• Root manager:
• Root manager version:
• ROM:
• Device model and responses of these commands:

:/ $ su
:/ # cat /data/adb/tricky_store/tee_status 
:/ # uname -a

• Screenshot of the getkb response (Look at README.md to know how to execute getkb)

RootManager: magisk canary 27008 Commands:

:/data/adb/tricky_store # uname -a
Linux localhost 5.4.233-qgki-27940246-abF926BXXS6GXBD #1 SMP PREEMPT Mon Mar 4 10:48:57 KST 2024 aarch64 Toybox
:/data/adb/tricky_store # ls -la
total 14
drwxr-xr-x  2 root root 3452 2024-09-26 04:27 .
drwx------ 11 root root 3452 2020-02-06 12:07 ..
-rw-r--r--  1 root root 7513 2024-09-26 04:22 keybox.xml
-rw-r--r--  1 root root  155 2024-09-26 04:24 target.txt
-rw-rw-rw-  1 root root   15 2024-09-26 04:39 tee_status
:/data/adb/tricky_store # cat tee_status
teeBroken=false

getkb isn't going to work as you don't have a "system/bin" folder in your module, you only have "bin"

That's correct, /system/bin must be untouched but it still needs to work (like it worked for other people) since I'm adapting executables (including the ones that needs to be used during boot) in root manager's PATH since some root detection can detect if I use overlay to put executables somewhere in /system

Could you do getkb and ls for "/data/adb/magisk" and "/debug_ramdisk"? If this command didn't worked for you but these directories are used by official magisk canary build as PATH it could be that executable is not compatible. In that case, if PATH dir is not a problem, I will modify executables and push changes.

No one else had this issue before with executables in official magisk so this issue must be new if PATH are correct

[diabl0w]

There is no config.txt target.txt not getting updated

Hello @diabl0w Could you tell me more about your bug. I need these informations:

• Root manager:
• Root manager version:
• ROM:
• Device model and responses of these commands:

:/ $ su
:/ # cat /data/adb/tricky_store/tee_status 
:/ # uname -a

• Screenshot of the getkb response (Look at README.md to know how to execute getkb)

RootManager: magisk canary 27008 Commands:

:/data/adb/tricky_store # uname -a
Linux localhost 5.4.233-qgki-27940246-abF926BXXS6GXBD #1 SMP PREEMPT Mon Mar 4 10:48:57 KST 2024 aarch64 Toybox
:/data/adb/tricky_store # ls -la
total 14
drwxr-xr-x  2 root root 3452 2024-09-26 04:27 .
drwx------ 11 root root 3452 2020-02-06 12:07 ..
-rw-r--r--  1 root root 7513 2024-09-26 04:22 keybox.xml
-rw-r--r--  1 root root  155 2024-09-26 04:24 target.txt
-rw-rw-rw-  1 root root   15 2024-09-26 04:39 tee_status
:/data/adb/tricky_store # cat tee_status
teeBroken=false

getkb isn't going to work as you don't have a "system/bin" folder in your module, you only have "bin"

That's correct, /system/bin must be untouched but it still needs to work (like it worked for other people) since I'm adapting executables (including the ones that needs to be used during boot) in root manager's PATH since some root detection can detect if I use overlay to put executables somewhere in /system

Could you do getkb and ls for "/data/adb/magisk" and "/debug_ramdisk"? If this command didn't worked for you but these directories are used by official magisk canary build as PATH it could be that executable is not compatible. In that case, if PATH dir is not a problem, I will modify executables and push changes.

No one else had this issue before with executables in official magisk so this issue must be new if PATH are correct

:/ # ls /data/adb/magisk/
addon.d.sh     chromeos  magisk32    magiskpolicy
boot_patch.sh  init-ld   magiskboot  stub.apk
busybox        magisk    magiskinit  util_functions.sh
:/ # ls /debug_ramdisk/
magisk    magiskinit    resetprop  su
magisk32  magiskpolicy  shamiko    supolicy
:/ # getkb
: getkb: inaccessible or not found

[joeyoropesa-dev]

There is no config.txt target.txt not getting updated

Hello @diabl0w Could you tell me more about your bug. I need these informations:

• Root manager:
• Root manager version:
• ROM:
• Device model and responses of these commands:

:/ $ su
:/ # cat /data/adb/tricky_store/tee_status 
:/ # uname -a

• Screenshot of the getkb response (Look at README.md to know how to execute getkb)

RootManager: magisk canary 27008 Commands:

:/data/adb/tricky_store # uname -a
Linux localhost 5.4.233-qgki-27940246-abF926BXXS6GXBD #1 SMP PREEMPT Mon Mar 4 10:48:57 KST 2024 aarch64 Toybox
:/data/adb/tricky_store # ls -la
total 14
drwxr-xr-x  2 root root 3452 2024-09-26 04:27 .
drwx------ 11 root root 3452 2020-02-06 12:07 ..
-rw-r--r--  1 root root 7513 2024-09-26 04:22 keybox.xml
-rw-r--r--  1 root root  155 2024-09-26 04:24 target.txt
-rw-rw-rw-  1 root root   15 2024-09-26 04:39 tee_status
:/data/adb/tricky_store # cat tee_status
teeBroken=false

getkb isn't going to work as you don't have a "system/bin" folder in your module, you only have "bin"

That's correct, /system/bin must be untouched but it still needs to work (like it worked for other people) since I'm adapting executables (including the ones that needs to be used during boot) in root manager's PATH since some root detection can detect if I use overlay to put executables somewhere in /system Could you do getkb and ls for "/data/adb/magisk" and "/debug_ramdisk"? If this command didn't worked for you but these directories are used by official magisk canary build as PATH it could be that executable is not compatible. In that case, if PATH dir is not a problem, I will modify executables and push changes. No one else had this issue before with executables in official magisk so this issue must be new if PATH are correct

:/ # ls /data/adb/magisk/
addon.d.sh     chromeos  magisk32    magiskpolicy
boot_patch.sh  init-ld   magiskboot  stub.apk
busybox        magisk    magiskinit  util_functions.sh
:/ # ls /debug_ramdisk/
magisk    magiskinit    resetprop  su
magisk32  magiskpolicy  shamiko    supolicy
:/ # getkb
: getkb: inaccessible or not found

It's strange that none of executables was installed in "/debug_ramdisk"

Could you check using "touch" command is /debug_ramdisk writtable in your case

[diabl0w]

It's strange that none of executables was installed in "/debug_ramdisk"

Could you check using "touch" command is /debug_ramdisk writtable in your case

:/debug_ramdisk # ls
magisk    magiskinit    resetprop  su
magisk32  magiskpolicy  shamiko    supolicy
:/debug_ramdisk # touch test
:/debug_ramdisk # ls
magisk    magiskinit    resetprop  su        test
magisk32  magiskpolicy  shamiko    supolicy

[joeyoropesa-dev]

It's strange that none of executables was installed in "/debug_ramdisk" Could you check using "touch" command is /debug_ramdisk writtable in your case

:/debug_ramdisk # ls
magisk    magiskinit    resetprop  su
magisk32  magiskpolicy  shamiko    supolicy
:/debug_ramdisk # touch test
:/debug_ramdisk # ls
magisk    magiskinit    resetprop  su        test
magisk32  magiskpolicy  shamiko    supolicy

You could try to remove module, reboot device, re-download module from the same sources (since zip got updated for v1.0.8), re-install module, reboot and open terminal to check is "getkb" installed in "/debug_ramdisk" - if it's still not there, there could be issues with customize.sh that needs to complete executable installation to specific directories based on what root you're using.

[diabl0w]

I'm using official magisk canary but I'm guessing these release notes from the equivalent alpha version are related

[diabl0w]

It's strange that none of executables was installed in "/debug_ramdisk" Could you check using "touch" command is /debug_ramdisk writtable in your case

:/debug_ramdisk # ls
magisk    magiskinit    resetprop  su
magisk32  magiskpolicy  shamiko    supolicy
:/debug_ramdisk # touch test
:/debug_ramdisk # ls
magisk    magiskinit    resetprop  su        test
magisk32  magiskpolicy  shamiko    supolicy

You could try to remove module, reboot device, re-download module from the same sources (since zip got updated for v1.0.8), re-install module, reboot and open terminal to check is "getkb" installed in "/debug_ramdisk" - if it's still not there, there could be issues with customize.sh that needs to complete executable installation to specific directories based on what root you're using.

I'm already using 1.0.8 and already tried reinstalling so it would only get us to the same spot we are now

[joeyoropesa-dev]

I'm using official magisk canary but I'm guessing these release notes from the equivalent alpha version are related

customize.sh doesn't applying any mounts (to avoid overlay detections). The only thing that is doing is during installation, it installs (copying and setting correct permissions) executables required for the module to run (from module bin folder to root manager's PATH folder - in magisk it's /debug_ramdisk)

So if complete removal of the module, re-downloading updated zip from v1.0.8 and re-installing and rebooting worked for you, that means that customize.sh is not triggered correctly during updates for some reason and I will quickly figure out why.

That will also help me to instruct others who maybe also updated module but it didn't worked for them to re-download module so that changes may be applied to them too.

If after all module executables are still not installed, that means that customise.sh is the issue and maybe in that case I will move to install.sh method

[diabl0w]

I'm using official magisk canary but I'm guessing these release notes from the equivalent alpha version are related

customize.sh doesn't applying any mounts (to avoid overlay detections). The only thing that is doing is during installation, it installs (copying and setting correct permissions) executables required for the module to run (from module bin folder to root manager's PATH folder - in magisk it's /debug_ramdisk)

So if complete removal of the module, re-downloading updated zip from v1.0.8 and re-installing and rebooting worked for you, that means that customize.sh is not triggered during updates for some reason and I will quickly figure out why.

That will also help me to instruct others who maybe also updated module but it didn't worked for them to re-download module so that changes may be applied to them too.

If after all of this executables are still not installed, that means that customise.sh is the issue and maybe in that case I will move to install.sh method

Okay well I can confirm it doesn't work when trying from fresh install

[joeyoropesa-dev]

@topjohnwu We have a problem with Magisk compatibility about this module. Are you willing to collaborate?

[joeyoropesa-dev]

I'm using official magisk canary but I'm guessing these release notes from the equivalent alpha version are related

customize.sh doesn't applying any mounts (to avoid overlay detections). The only thing that is doing is during installation, it installs (copying and setting correct permissions) executables required for the module to run (from module bin folder to root manager's PATH folder - in magisk it's /debug_ramdisk) So if complete removal of the module, re-downloading updated zip from v1.0.8 and re-installing and rebooting worked for you, that means that customize.sh is not triggered during updates for some reason and I will quickly figure out why. That will also help me to instruct others who maybe also updated module but it didn't worked for them to re-download module so that changes may be applied to them too. If after all of this executables are still not installed, that means that customise.sh is the issue and maybe in that case I will move to install.sh method

Okay well I can confirm it doesn't work when trying from fresh install

I suggest temp fixes for this issue is that you manually install executables and set their permissions in specific directories:

:/ $ su
:/ # cp -f /data/adb/modules/trickystore-addon/bin/getkb /debug_ramdisk
:/ # cp -f /data/adb/modules/trickystore-addon/bin/busybox /debug_ramdisk
:/ # cp -f /debug_ramdisk/getkb /data/adb/magisk
:/ # cp -f /debug_ramdisk/busybox /data/adb/magisk
:/ # chmod 6777 /debug_ramdisk/busybox
:/ # chmod 6777 /debug_ramdisk/getkb
:/ # chmod 6777 /data/adb/magisk/getkb
:/ # chmod 6777 /data/adb/magisk/busybox
:/ # chmod 6777 /data/adb/modules/trickystore-addon/bin/getkb_boot
:/ # getkb

I will working on permanent fixes for this issue but also waiting on official magisk developer to respond since this compatibility issue has happened only to latest canary build from the first time. All older builds I didn't had any reports by users so I guess incompatibility started from Magisk Canary 27008 so I need to know what magisk developer changed to make customize.sh not functional anymore for future builds of magisk.

[diabl0w]

Also tested not working on 27007 magisk (specifically I tried using alpha but I assume official magisk 27007 canary as well)

All same symptoms that noted above (not being present in /debug_ramdisk, etc)

[diabl0w]

I'm using official magisk canary but I'm guessing these release notes from the equivalent alpha version are related

customize.sh doesn't applying any mounts (to avoid overlay detections). The only thing that is doing is during installation, it installs (copying and setting correct permissions) executables required for the module to run (from module bin folder to root manager's PATH folder - in magisk it's /debug_ramdisk) So if complete removal of the module, re-downloading updated zip from v1.0.8 and re-installing and rebooting worked for you, that means that customize.sh is not triggered during updates for some reason and I will quickly figure out why. That will also help me to instruct others who maybe also updated module but it didn't worked for them to re-download module so that changes may be applied to them too. If after all of this executables are still not installed, that means that customise.sh is the issue and maybe in that case I will move to install.sh method

Okay well I can confirm it doesn't work when trying from fresh install

I suggest temp fixes for this issue is that you manually install executables and set their permissions in specific directories:

:/ $ su
:/ # cp -f /data/adb/modules/trickystore-addon/bin/getkb /debug_ramdisk
:/ # cp -f /data/adb/modules/trickystore-addon/bin/busybox /debug_ramdisk
:/ # cp -f /debug_ramdisk/getkb /data/adb/magisk
:/ # cp -f /debug_ramdisk/busybox /data/adb/magisk
:/ # chmod 6777 /debug_ramdisk/busybox
:/ # chmod 6777 /debug_ramdisk/getkb
:/ # chmod 6777 /data/adb/magisk/getkb
:/ # chmod 6777 /data/adb/magisk/busybox
:/ # chmod 6777 /data/adb/modules/trickystore-addon/bin/getkb_boot
:/ # getkb

I will working on permanent fixes for this issue but also waiting on official magisk developer to respond since this compatibility issue has happened only to latest canary build from the first time. All older builds I didn't had any reports by users so I guess incompatibility started from Magisk Canary 27008 so I need to know what magisk developer changed to make customize.sh not functional anymore for future builds of magisk.

Who is testing this? I did your modifications:

• I had to remove the "-" in "trickystore-addon" because that is not how your module is named)
• I still dont have getkb in PATH after reboot
• keybox.xml only updates if I manually run getkb, it does not get updated on boot
• target.txt never gets updated at all

I dont see how this is a magisk developer's issue, seems like module issue

[diabl0w]

Where in your service.sh does helper.sh ever get called? It's hard to help you when hiding behind obfuscated code what is this trying to do?:

modules/trickystoreaddon/bin/getkb_boot                           
Keybox Updater: Executing
Keybox Updater: Successful!
touch: '': No such file or directory
touch: '': No such file or directory
touch: '': No such file or directory
touch: '': No such file or directory
touch: '': No such file or directory
touch: '': No such file or directory

[joeyoropesa-dev]

Where in your service.sh does helper.sh ever get called?

It's in compiled binary getkb_boot (for both keyboxs and target.txt updating)

The getkb_boot binary needs to be executed during boot by service.sh (if it's located correctly) and busybox and getkb binary needs to be accessible by PATH (that means that one of the directories used by your root manager to mount su and other root executables needs to be used for that - PATH that are not /system/bin since in /system/bin su command is only bind-mounted from another location that should be PATH for this root manager)

And it worked with every version of root managers before (until this report that I've got from you)

I'm currently setting up virtual machine with official Magisk Canary to manually test it and modify it on the go to fix it.

[diabl0w]

Where in your service.sh does helper.sh ever get called? It's hard to help you when hiding behind obfuscated code what is this trying to do?:

modules/trickystoreaddon/bin/getkb_boot                           
Keybox Updater: Executing
Keybox Updater: Successful!
touch: '': No such file or directory
touch: '': No such file or directory
touch: '': No such file or directory
touch: '': No such file or directory
touch: '': No such file or directory
touch: '': No such file or directory

This is your issue

[joeyoropesa-dev]

Where in your service.sh does helper.sh ever get called? It's hard to help you when hiding behind obfuscated code what is this trying to do?:

modules/trickystoreaddon/bin/getkb_boot                           
Keybox Updater: Executing
Keybox Updater: Successful!
touch: '': No such file or directory
touch: '': No such file or directory
touch: '': No such file or directory
touch: '': No such file or directory
touch: '': No such file or directory
touch: '': No such file or directory

Thank you, this response could help me find the issue (this response was never shown on my devices so this is new... it can also be due to specified compiling methods I've used - some methods could be incompatible with another devices so I'm going to debugging it)

[diabl0w]

Isn't debug_ramdisk just stored in ram memory? Putting any files there will just get lost on reboot correct?

[joeyoropesa-dev]

Isn't debug_ramdisk just stored in ram memory? Putting any files there will just get lost on reboot correct?

For other users, they didn't got any issues with that and they also used official Magisk - I'm using APatch so I know that APatch have different PATH and it always works from there and never got touch '': No such file or directory bug. Every file was found in it's location and all functions we're correctly loaded.

I'm also trying to adapt to other root managers but it seems that starting from the version you reported here, this is gonna be different.

Maybe I will move configurations back to service.sh for target.txt while working on an completely different version of this addon

New version should be able to instead of calling helper.sh every 5 seconds to actually be triggered by installing/uninstalling apps (it will be better for battery and device performance) and the file responsible for helper.sh will be service so service will handle it while executables will work only with keybox (service.sh will only have two jobs and that is to execute service.dex for target.txt and getkb_boot for keybox).

That should improve performance instead of refreshing target.txt every 5 seconds and compiling it into C executable. It will be the best if we put that in more-friendly languages for android like java+kotlin

(If starting from 27008 debug_ramdisk gets cleaned after each boot, I will need to include overlay for magisk in that case since /data/adb/magisk didn't worked as PATH)

[diabl0w]

Isn't debug_ramdisk just stored in ram memory? Putting any files there will just get lost on reboot correct?

For other users, they didn't got any issues with that and they also used official Magisk - I'm using APatch so I know that APatch have different PATH and it always works from there and never got touch '': No such file or directory bug. Every file was found in it's location and all functions we're correctly loaded.

I'm also trying to adapt to other root managers but it seems that starting from the version you reported here, this is gonna be different.

Maybe I will move configurations back to service.sh for target.txt while working on an completely different version of this addon

New version should be able to instead of calling helper.sh every 5 seconds to actually be triggered by installing/uninstalling apps (it will be better for battery and device performance) and the file responsible for helper.sh will be service so service will handle it while executables will work only with keybox (service.sh will only have two jobs and that is to execute service.dex for target.txt and getkb_boot for keybox).

That should improve performance instead of refreshing target.txt every 5 seconds and compiling it into C executable. It will be the best if we put that in more-friendly languages for android like java+kotlin

(If starting from 27008 debug_ramdisk gets cleaned after each boot, I will need to include overlay for magisk in that case since /data/adb/magisk didn't worked as PATH)

I agree, all of that sounds much better. As for getting included in PATH, what is the goal of doing so? So that user can call the executable manually? Or is module dependent on it for something? I am not sure how magisk handles it's PATH environment for modules vs userspace

[diabl0w]

It's strange that none of executables was installed in "/debug_ramdisk" Could you check using "touch" command is /debug_ramdisk writtable in your case

:/debug_ramdisk # ls
magisk    magiskinit    resetprop  su
magisk32  magiskpolicy  shamiko    supolicy
:/debug_ramdisk # touch test
:/debug_ramdisk # ls
magisk    magiskinit    resetprop  su        test
magisk32  magiskpolicy  shamiko    supolicy

You could try to remove module, reboot device, re-download module from the same sources (since zip got updated for v1.0.8), re-install module, reboot and open terminal to check is "getkb" installed in "/debug_ramdisk" - if it's still not there, there could be issues with customize.sh that needs to complete executable installation to specific directories based on what root you're using.

I'm already using 1.0.8 and already tried reinstalling so it would only get us to the same spot we are now

Shamiko is apparently able to make this persistent, so maybe it can be investigated how

[joeyoropesa-dev]

Isn't debug_ramdisk just stored in ram memory? Putting any files there will just get lost on reboot correct?

For other users, they didn't got any issues with that and they also used official Magisk - I'm using APatch so I know that APatch have different PATH and it always works from there and never got touch '': No such file or directory bug. Every file was found in it's location and all functions we're correctly loaded. I'm also trying to adapt to other root managers but it seems that starting from the version you reported here, this is gonna be different. Maybe I will move configurations back to service.sh for target.txt while working on an completely different version of this addon New version should be able to instead of calling helper.sh every 5 seconds to actually be triggered by installing/uninstalling apps (it will be better for battery and device performance) and the file responsible for helper.sh will be service so service will handle it while executables will work only with keybox (service.sh will only have two jobs and that is to execute service.dex for target.txt and getkb_boot for keybox). That should improve performance instead of refreshing target.txt every 5 seconds and compiling it into C executable. It will be the best if we put that in more-friendly languages for android like java+kotlin (If starting from 27008 debug_ramdisk gets cleaned after each boot, I will need to include overlay for magisk in that case since /data/adb/magisk didn't worked as PATH)

I agree, all of that sounds much better. As for getting included in PATH, what is the goal of doing so? So that user can call the executable manually? Or is module dependent on it for something? I am not sure how magisk handles it's PATH environment for modules vs userspace

A little bit of both. Easy accessible by user and APatch version of busybox for specific functions in getkb_boot and getkb executable - there is some commands available that are not usually available by default on non-APatch users that some functions depends on them.

It would be the easiest way just to use overlayfs for this but some ROMs with broken TEE can be detected for using overlayfs and integrity could be broken too for them. Anyway, as for now, I will temporary push some changes to the same v1.0.8 version that will register executables in PATH for magisk users using overlayfs (not recommended for TEE broken devices) until I complete a better solution for the future builds of this module.

Stay tuned for updates!

[joeyoropesa-dev]

It's strange that none of executables was installed in "/debug_ramdisk" Could you check using "touch" command is /debug_ramdisk writtable in your case

:/debug_ramdisk # ls
magisk    magiskinit    resetprop  su
magisk32  magiskpolicy  shamiko    supolicy
:/debug_ramdisk # touch test
:/debug_ramdisk # ls
magisk    magiskinit    resetprop  su        test
magisk32  magiskpolicy  shamiko    supolicy

You could try to remove module, reboot device, re-download module from the same sources (since zip got updated for v1.0.8), re-install module, reboot and open terminal to check is "getkb" installed in "/debug_ramdisk" - if it's still not there, there could be issues with customize.sh that needs to complete executable installation to specific directories based on what root you're using.

I'm already using 1.0.8 and already tried reinstalling so it would only get us to the same spot we are now

Shamiko is apparently able to make this persistent, so maybe it can be investigated how

Yeah, I will have a quick look into Shamiko module to see what method they are using for debug_ramdisk (it seems that Shamiko is using Zygisk to achieve this. I will decompile it and see it deeply to understand their method but I guess that Zygisk starts "as service" this module and from zygisk directory reads zygisk module code that copying required executable to PATH, set permissions and execute it and keep it working in background)