search

topjohnwu / Magisk

The Magic Mask for Android
GNU General Public License v3.0
47.6k stars 12.08k forks source link

Wrong busybox binary on x86 #1600

Closed xymopen closed 5 years ago

xymopen commented 5 years ago

Hi,

I have a Xiaomi Mi Pad 2 which runs on Intel Atom X5-Z8500 and Magisk installs busybox for ARM architect. I find out that update_binary.sh uses /dev/null to decide architect is arbitrary, because the tablet has such device. I also notice that during patching boot.img the console said the platform is arm64-v8a, although it installed the right binary. The misleading message is from MagiskInstaller.java#L122.

osm0sis commented 5 years ago

No, it just attempts to run busybox and if it fails to run, it then uses x86. It's likely getting confused by Intel's libhoudini arm emulation.

xymopen commented 5 years ago

Yes, the binary can run after system started. However it fails during boot and modules cannot be loaded. /cache/magisk.log says:

--------- beginning of main
I/Magisk  ( 2291): Magisk v19.3(19300) daemon started
I/Magisk  ( 2291): * Device API level: 22
I/Magisk  ( 2291): ** post-fs-data mode running
I/Magisk  ( 2291): * Initializing Magisk environment
I/Magisk  ( 2291): * Mounting mirrors
I/Magisk  ( 2291): mount: /sbin/.magisk/mirror/system
I/Magisk  ( 2291): mount: /sbin/.magisk/mirror/data
I/Magisk  ( 2291): link: /sbin/.magisk/mirror/vendor
I/Magisk  ( 2291): * Setting up internal busybox
E/Magisk  ( 2311): execve /sbin/.magisk/busybox/busybox failed with 8: Exec format error
I/Magisk  ( 2291): * Running post-fs-data.d scripts
I/Magisk  ( 2291): * Running module post-fs-data scripts
I/Magisk  ( 2291): * Loading modules
I/Magisk  ( 2291): * Starting MagiskHide
I/Magisk  ( 2291): hide_policy: Hiding sensitive props
I/Magisk  ( 2291): hide_list init: [com.google.android.gms/com.google.android.gms.unstable]
I/Magisk  ( 2291): hide_list init: [org.microg.gms.droidguard/com.google.android.gms.unstable]
--------- beginning of system
I/Magisk  ( 2291): ** late_start service mode running
I/Magisk  ( 2291): * Running service.d scripts
I/Magisk  ( 2291): * Running module service scripts
I/Magisk  ( 2291): ** boot_complete triggered
osm0sis commented 5 years ago

Sounds like maybe it would be better to try to run the x86 first, then do arm as the fallback, @topjohnwu.

xymopen commented 5 years ago

May be we can use api_level_arch_detect in util_functions.sh#L325?

osm0sis commented 5 years ago

The goal is to have a zip that automatically creates its own flashing environment, so no. I think my idea of reversing the order would work well though.

Once the environment is setup for flash though there must be some other reason its not getting the right architecture for the installed files. Have you checked to make sure the x86 busybox included works by manually copying it from the zip to /data/adb/magisk?

Edit: Actually rereading your log it seems more like the exec command is failing on a syntax error, not the binary itself.

xymopen commented 5 years ago

I tried replace busybox binary at /sbin/.magisk/busybox but after reboot it reverted to ARM version(makes no sense to me). I don't understand how this happened. I made a flashable zip without architect detection and used fiddler to inject it.

xymopen commented 5 years ago

I pull the binary from /sbin/.magisk/busybox/busybox to PC and probe it with file in wsl .

osm0sis commented 5 years ago

I told you where to replace busybox and it wasn't in sbin. Please read more carefully.

xymopen commented 5 years ago

I just try to get the same result in a different approach. I install Magisk several times and check which binary it installed. When x86 binary get the right place the issue did resolve.

xymopen commented 5 years ago

Maybe I didn't express myself clearly. I made a magisk.zip that would always emit x86 busybox, hijack Magisk Manager with fiddler so it would always get my altered zip, follow the normal patch boot procedure, and now I have a working Magisk.

xymopen commented 5 years ago

The working Magisk's log is a copy of the non-working ones, just without the only error line.

osm0sis commented 5 years ago

Okay good, thanks, my idea could fix it then, it'll just need changes to the update-binary.sh and the build system (so ideally from @topjohnwu) to try x86 first as a more definitive detection, then maybe another fix to the arch detection in the installer if that doesn't fix it on its own.