yashsingh1/xdaforums huggingface dataset:
[Magisk] HippoMan:
This repetitious and rambling message of yours here seems to show that you have difficulities in focusing your mind (one example: you repeated your overly verbose complaint about TWRP 3.6.0 three times in your message here that I have quoted above).

And the fact that you missed clear and simple instructions given to you here in this thread about how to root your phone via a patched boot.img file seems to indicate that you also might have reading-comprehension problems.

Another reading-comprehension issue of yours: the text about 64MB was not trying to give you any kind of lesson in hexadecimal arithmetic. The numbers posted were simply there to illustrate and clarify that the size of the module being loaded is larger than the maximum allowed size. I'm sure that everyone else here who has read that text about 64MB could easily understand that you were not being given any kind of arithmetic lesson.

Also keep in mind that you are not the only person reading these publicly posted and publicly readable messages. Some people are greatly helped by the kind of extra clarification given here, but which just seemed to confuse you.

Please don't blame your own mental-focus difficulties and reading-comprehension difficulties on others who have been going out of their ways to try to help you.
[Magisk] Nickwilde7755:
Is there a method to root a Z Fold 3 without losing data or formatting?
[Magisk] Nergal di Cuthah:
I believe that you first must unlock bootloader which always results in data wipe, so in general no. However maybe there is a way on your particular device, best to ask in that device's subforum.
[Magisk] MrDubsstep:
Do you know what is the last version of Magisk? Mine says 4.3.3, but in the home says v11.6
[Magisk] pndwal:
Version 26103... Latest public stable build is 26.1... 😬 PW
[Magisk] MrDubsstep:
Ok, i found that 4.3.3 is the version of MagiskManager is 4.3.3.

So i will unistall everything and reinstall it with latest versions. Thanks!
[Magisk] pndwal:
Magisk Manager has been dead since 22.0!:

https://topjohnwu.github.io/Magisk/releases/22000.html

... Single package app archive now!... 🙃 PW
[Magisk] MrDubsstep:
Thanks, i installed v26.1
[Magisk] flesheatingbeatles:
Greetings awesome magisk devs and contributors to this thread!

Pixel 7 Pro with unlocked bootloader here, with a cautious, even paranoid owner.

I installed magisk *.apk from proper place, patched init_boot.img, ran sha256sum on the output and got:

3ad33cb1fee75be7253edecf59f276e0b9dc383f36232cf0e4aafaae464a04c0

I built magisk from source using the output of build.py ndk for the ndk, ran sha256sum on the output and got:

b4327ff116842ece9a149404d11d9a236baaeecbc67be64bc8007fbfd767a473

Got stuck on built ndk from source, or I'd have presented the sum for it's output, but time for that later. Chokes on something about several versions of crate. Father time is telling me I need to get this phone working.

Why is there a diff? Which patched image should I choose? Have I stumbled on something malicious?

Something sure is going right as they are all 8 MiB long.

Anyone want to post a sha256sum from their patched boot_init?

Build is tq3a.230605.012.a1

Is there anything other than "make root happen" in the patch? If there isn't then there wouldn't be much change over time because it just works. If there is... isn't the kernel in init_boot?
[Magisk] J.Michael:
Go read @badabing2003's PixelFlasher thread. I think he mentioned Magisk suddenly starting to inject a random string while patching.

Instead of comparing hashes, why not compare the actual patched images? You say they are the same length.

I don't think the kernel is in init_boot, I think the kernel is in "boot.img"; at some point the ramdisk was split out into another partition -- that's why on some devices you need to patch some partition other than "boot.img".
[Magisk] Lughnasadh:
For devices launching with Android 13, the generic ramdisk is now in the init_boot image, leaving the boot image with only the GKI kernel.

Generic boot partition | Android Open Source Project

source.android.com
[Magisk] pndwal:
Further to the above, these changes to seperate vendor ramdisks etc to /vendor_boot, later seperation of generic ramdisk (used by init files for booting incl. w/ magiskinit) to /init_boot etc. are all part of project Treble & project Mainline initiatives to facilitate easier updates for vendors, give incentive to support devices much longer, better support GSI ROMs (https://developer.android.com/topic/generic-system-image) etc.

So Magisk is of course always changing to accommodate Google's 'Android Booting Shenanigans' etc...

-------​

On the question of your differing sha256sum results:

1) /dev/<random_string> has been used as TMP directory only in devices where there's no (Magisk accessible) /sbin (from Android 11?), so I think sha256sum will have differed with every fresh patch for some time... This has now changed w/ latest Canary as mentioned below.

2) Random code also results from Use stable random seed which was merged from vv's 'seed' branch on April 4 and built from 25211... it combined Use stable random seed, Get random separately & Make base as template argument for optimization... An associated change, Make build reproducible, may still be a WIP (or draft has simply been forgotten/neglected).

It seems that random code generation in 1) above is removed with the recent change New magisk tmp dir: /debug_ramdisk committed on May 6, built from Canary 26102, which replaced /dev/<random_string> with /debug_ramdisk...

It seems that random code generation in 2) above is removed with Remove randomness from Magisk, committed on June 15 and built from 26103 also.

I'm guessing you may have been using Magisk older than 26103, but seems that if you check after seperate patching attempts using same unpatched boot image and device w/ 26103, you may now get consistent sha256sum, assuming "Remove randomness..." does indeed revert all random code generation... Guess it's still possible there's another function doing this that hasn't been addressed yet...

Nb. Recently (v26.0+) Magisk also began requiring booted system when patching to fully root, ie to set selinux/module rules directory on a per-device/OS basis. (.zip installer installation from custom recovery now only achieves partial root, enough to take in-app Direct install later to fully root after booting to system however)... I'm guessing the directory should be set consistently on any one device, but I'm not sure...

👀 PW
[Magisk] flesheatingbeatles:
I have had reason to alter the contents of ramdisks for desktop Linux kernels (long ago) and I was able to use "mount -o loop ..." to mount the file courtesy of a /dev/loop* device but pounded on that for about an hour with this with no success. There is info to be had about the sectors, etc. using other utilities, and it is reported as a dos or msdos partition from those. If that's what you mean? Or load them into something like ghex and compare visually... Several other options with which I'm unfamiliar must be available given the nature of the community at large.

Presumably they are precisely the same size as the partition they are destined for.

Of course (slaps forehead) init_boot.img is the contents of the ramdisk, initrd*** on desktop! Where the kernel expects directions and enablements to / to be. This is not much different from desktop Linux except for names.

I was unable to find this mention using search.

Anyway I should expect to have to dig in to the code to find exactly what is in the end product. As long as there are reasons other than maliciousness that could cause the diff I can proceed. Thank you.
[Magisk] badabing2003:
https://xdaforums.com/search/65127829/?q=randomseed&c[users]=badabing2003&o=relevance
[Magisk] J.Michael:
You tried two sequences of operations, producing two patched images. You said their hashes were different. I assumed you wanted some assurance that they represented equivalent patched images.

I was imagining using "cmp" to compare the two patched images. I don't remember how big the random string is, but I thought you might find it reassuring if the only difference between any two patched images was a short string at a fixed address.

As you say, you could mount the two patched images and then compare pairs of files within the two ramdisks. I don't know whether the random string appears within the ramdisk, or was appended to the filesystem image. If the latter, you would find that you had identical ramdisks, with different random strings appended.
[Magisk] pndwal:
I answered with the commits (took pains to supply dates and versions too) responsible for random code generation in post above, and where/when reverted...

... The commits I gave you are not malicious, and that's your starting point for code-digging...

Also, you haven't said which Magisk you used but I'm still interested in whether it was pre-26103 (because if latest stable 26.1 was used for example, varying sha256sum would be expected), and if seperate patching attempts using same unpatched boot image and device w/ 26103 do indeed result in a consistent sha256sum (or if there is more 'randomness' unaccounted for)... I could test, but you may as well too... (Maybe you were already on 26103. 🤔 ) PW
[Magisk] badabing2003:
I've tested this and creating multiple patches with 26103 (obviously from the same boot/init_boot) results in consistent identical binaries with matching SHA1.
[Magisk] flesheatingbeatles:
Comparing sha256 hashes is just plain lazy and I couldn't resist following that proverbial path. Now there's only to uncover the meaning and functionality of the value stored in the RANDOMSEED variable, which is not found in init_boot.img, is found in the pre-build magisk of the first hash (26100) but is not found in the magisk source build of the second hash (26103). badabing2003 suggested a link to a proper search result from the string RANDOMSEED, much obliged, which yields usage of the var but the question remains precisely what is the purpose of it, which reminds me of a random hex string unique identifier.

I got the Magisk version which produced the first hash from the github files site, 26100. The one I compiled is 26103 with which sha256sum produced the second hash.

I removed magisk, reinstalled the pre-built 26.1 and ran install on init_boot.img with the following results:

a1b084c20f9dd4d2ba18b3170697f8faa316eb52a48be654156073ffdda4c7b0 magisk_patched-26100_yyyyy.img

which differs with my original from 26.1 as such:

3ad33cb1fee75be7253edecf59f276e0b9dc383f36232cf0e4aafaae464a04c0 magisk_patched-26100_xxxxx.img

Then I removed the pre-built and reinstalled the canary 26103 build and got:

b4327ff116842ece9a149404d11d9a236baaeecbc67be64bc8007fbfd767a473 magisk_patched-26103_yyyyy.img

which is identical to the original from canary 26103 build:

b4327ff116842ece9a149404d11d9a236baaeecbc67be64bc8007fbfd767a473 magisk_patched-26103_xxxxx.img

which suggests random string creation has been removed.

Extreme appreciation for extreme guidance and information!

1) Clearly there are reasons other than maliciousness for diffs in output of different versions.

2) I'll have to look into the rest of this later

So as for a comparison of three ramdisk images; one original init_boot.img from cheetah-tq3a.230605.012.a1-factory-170d1863.zip, one as patched by the pre-built magisk from the github files site 26100, and one as patched by the canary 26103 build which I performed with the ndk from

build.py ndk

First 21 bytes are consistent, beginning with "ANDROID!" and ending in 0x30 0x06, except for 3 bytes at the same position:

1. init_boot.img

0xDA 0x8E 0x1F

2. magisk_patched-26100_xxxxx.img

0x8A 0x93 0x26

3. magisk_patched-26103_xxxxx.img

0x99 0x5E 0x27

Then there are zeros between byte 20 and 0x02 0x21 0x4C which begins at 0x1000 on all three counts.

That's all I have time for. I will proceed to contemplate the reason those 3 bytes differ between the original and the magisk_patched.
[Magisk] badabing2003:
The purpose was unknown as I didn't see any official documentation or note mentioning it.

I speculated (probably wrongly) it was inserted to identify the source of shared patched images.

Seeing that it got removed in 26103, I guess it could have been an unexpected outcome.

Better way to compare them is to unpack and then compare.

I use the excellent Android Image Kitchen by @osm0sis.
[Magisk] flesheatingbeatles:
I see a fresh release factory image for my fresh Pixel 7 Pro is available!

cheetah-tq3a.230705.001.a1-factory-4031418c.zip

Will magisk devs indicate the readiness of their program to handle this new build, or is this where fresh guinea pigs are summoned to sacrifice themselves at the alter of the Android Magic Mask?
[Magisk] pndwal:
The Devs are always ready to implement any needed changes to support emerging stock Android architecture changes... They do rely on proper debug build logs etc and proper GitHub issue reporting however, but they often preempt the big changes as their own testing usually accommodates new Android booting shenanigans etc in pre-release developer preview, beta etc. builds...

There will always be issues/regressions associated with Google changes as well at changes to improve Magisk compatibility and functionality however. 🙃 PW
[Magisk] Lughnasadh:
Magisk Stable 26.1 or Canary 26102 should work fine with the July build. No guinea pigs necessary.
[Magisk] pndwal:
So both @badabing2003 and you have confirmed that from 26203 'randomness' has been removed from magiskboot tool, and should render consistent patching going forward... PW
[Magisk] pndwal:
... Are there issues w/ 26103 on P7P? PW
[Magisk] Lughnasadh:
Saw one or two reports that there was trouble patching with 26103, but have mostly seen success stories so mentioned Canary 26102 as an over abundance of caution. Probably a one off and definitely not related to the problems with the Pixel 6/Pro and 26103.
[Magisk] pndwal:
The Use stable random seed change didn't introduce the 'randomness' for most devices as we already had dev/<random_string> as TMP directory in devices with no (Magisk accessible) /sbin for a long while, but both these sources of random code are now gone...

I understand that RANDOMSEED is associated with new sepolicy rule (/module rule) and PREINITDEVICE implementation in Magisk 26.0, but not sure how RANDOMSEED or PREINITDEVICE keys were/are used...

This change was to improve Magisk compatibility for modules providing custom SELinux patches by including the file sepolicy.rule... Due to the complicated nature of SELinux patching, the compatibility of this functionality has been pretty spotty with many devices not supported. In this release, a brand new pre-init partition detection mechanism has been designed to support even more devices. (Ripped off from John's release notes)

I agree better documentation could go far to reduce confusion surrounding this major change... Clarification has been needed re. PREINITDEVICE implementation even since RANDOMSEED use was reverted, eg in Please consider making PREINITDEVICE optional... Apparently it is optional and can be predefined...

Anyway, hope this gives you some clues... @osm0sis (supplied a fix for preinit device retention with addon.d etc, Retain PREINITDEVICE in recovery flash if previously found during booted patching) and possibly others here may be able to explain (old) RANDOMSEED and PREINITDEVICE variable use further. 😜 PW
[Magisk] osm0sis:
If I recall/understood correctly RANDOMSEED was for magiskinit to create a reproducibly named /dev/*/ directory, since I guess that helped with a few things. That's gone now that /debug_ramdisk is being used to house the `magisk --path` files.

PREINITDEVICE is the decrypted storage where sepolicy module files are now housed, since sepolicy patching can only occur preinit on many devices. It's intentionally named preinit (not serules) to include future expansion to other files. The devs found the recovery reporting of device checks to be inconsistent/inaccurate, so PREINITDEVICE can only be determined while booted to Android, hence the new prompt to reflash when this variable isn't in init_/boot's ramdisk .magisk config file.
[Magisk] pndwal:
Oh... I thought these were unrelated as /dev/<random_string> was introduced as TMP directory (where there's no Magisk accessible /sbin) some time ago (from Android 11?) whereas Use stable random seed which was merged (from vv's 'seed' branch) recently on April 4, first built in 25211...

Further, New magisk tmp dir: /debug_ramdisk committed on May 6 (built from Canary 26102) whereas random seed use appears to be removed with Remove randomness from Magisk, committed on June 15 (built from 26103)...

Anyway, related or not both are gone now... 🤪 PW
[Magisk] osm0sis:
I think the keyword was *stable* random seed, because with RANDOMSEED in the config the /dev directory would always be named the same thing on every boot, but before it was random each time.

And yes the removal of the now unused randomness didn't happen at the same time as the new Magisk tmp dir being added, but they seem to have been connected. Reference:

Clean up unrooted boot patching log errors by osm0sis · Pull Request #7047 · topjohnwu/Magisk

Clean up unrooted boot patching cp errors in log remove call since cp_readlink shouldn't be necessary with installDir getting cleaned up regularly cp: can't preserve ownership of 'busybox': Opera...

github.com
[Magisk] Lindex:
hello pls help

oneplus 9

lineage-20.0-20230709-nightly-lemonade-signed.zip

sideload magisk.apk - no root

sideload magisk.zip - no root

patch boot and flash via fastboot - no root
[Magisk] pndwal:
Many thanks for these clarifications... I see I missed a lot (partly due to wrong assumptions using search in GitHub to find code)...

It's certainly clearer for me now although hard for a novice like me to get my head around... Hope it's useful for @badabing2003 and other coders...

Anyway, now seems that if random seed generation was actually unused in 26102 (w/ TMP dir: /debug_ramdisk) despite the code remaining until 26103, a consistent sha256sum should actually be produced from Magisk 26102...

👍 PW
[Magisk] osm0sis:
sha256sum of.. the entire boot.img? Until RANDOMSEED was removed from the config in 26103 it would still create a difference in the ramdisk doing multiple patched images.
[Magisk] pndwal:
Looks like this pinned 'wontfix' issue:

Custom kernel erroneously hides magisk su file #6914

- Please see Dev Edit comment in first post and linked comment...

- If this, will need to wait for fixed LineageOS builds to use w/ 26.0+...

Possibly this open issue w/ ongoing investigation also (known regression):

Magisk with libsu version after 4.0 show version as N/A APP #7021

👀 PW
[Magisk] osm0sis:
I'm on latest lemonadep Lineage and all is working fine on 26103, so I'd find it difficult to believe there's that big a difference. 🤔

Sideload the 26103 apk in Lineage Recovery or TWRP and post a log.
[Magisk] Lindex:
thank you!

do you think is it safe to test this fork? https://github.com/programminghoch10/Lygisk
[Magisk] pndwal:
No reason to think there may be any bad intent with that... Dev(s) does good work with Viper4Afx etc...

Seems to be a fork based currently on 26.1 so same issues I mentioned above may well be present unless you use a pre-26.0 build... Fork structure seems a little unorthodox too at first glance...

Also I don't know that you really need that fix for addon.d with FBE, especially with an A/B device where addon.d should work fine as I understand it... Further, I think @osm0sis' approach (fixing addon.d in official Magisk within the constraints of other dev decisions, Magisk functions and limitations) is more beneficial and advantageous generally...

Please consider @osm0sis' comment above for you re. 'lemonade' also... PW
[Magisk] Lindex:
I have flashed (via adb sideload) 26103 version. still no root

may be manual boot from patched boot will help?

I would like to share more logs.. please help me how to do it
[Magisk] Lindex:
thanks for the help, just tried it
[Magisk] J.Michael:
And?
[Magisk] Lindex:
same result, not rooted. https://xdaforums.com/t/magisk-general-support-discussion.3432382/page-2829#post-88736389
[Magisk] pndwal:
... I really should have asked if you had taken Hide the Magisk app option previously... If so it's likely that you simply have dual apps competing and conflicting...

Check in device settings, Apps for Magisk stub app(s) named either Settings (default) or whatever name you choose and uninstall these.

Apps like Applist Detector will show random package names for any hidden Magisk stub instances installed (if applist hiding is not activated for it in HideMyApplist module etc)...

Typing Magisk -v and magisk -V in a terminal emulator app will show version of Magisk (daemon) if it's actually running despite "Installed - N/A" showing...

🤠 PW
[Magisk] flesheatingbeatles:
I went ahead and performed update to tq3a.230705.001.a1 with the factory image with partial? success. I used 26103, the issue of my build from source with the ndk from "build.py ndk" but I have some issues.

1. The "Package" as reported in the App field of the magisk home screen changed from com.topjohnwu.magisk to <randomstring>.<randomstring>. I'm hoping that is an element of the Hding of the App for which I opted but I didn't catch when it occurred.

2. Under DenyList, "Android Auto" and "Contacts Storage" refuse to stay checked. I can check them then go back a screen and return and they are unchecked.

3. I am unable to remount / rw on the command line or with Root Explorer in the / or /system dirs. I believe Magisk is having the same difficulty because it fails installing terminal_systemizer which is half of the reason I've embarked on this journey. I did some research but I found no solution. It seems the brilliant @Chainfire took part in the original rooting of one of this line of devices and noted there are peculiarities in the mounting of the partitions but I was unable to remount either in / or /system in Root Explorer as he suggests. Any news on this front?

Or am I missing something? I thought I had accomplished the second task when I installed Magisk after the flashing and it required a reboot which I performed. There is plenty of evidence that Magisk is in the system: it has its own mount points and processes, etc.

It's not clear where the / partition is mounted, or where under /dev /or /dev/block the / partition device listed.

I take that back, the error from

mount -o rw,remount /

is

'/dev/block/dm-7' is read-only

so we know the device is /dev/block/dm-7.

So the error from:

mount -o rw,remount /dev/block/dm-7 /

is the same.
[Magisk] J.Michael:
You are not supposed to "remount,rw".

One of Magisk's claims to fame is its provision of a means to make it *look* like you modified "/system" *without* actually modifying "/system".

If "terminal_systemizer" is a Magisk module, some log file might say exactly how the installation is failing. Are you sure that the version you are trying to install is compatible with the version of Magisk you have installed?
[Magisk] Lughnasadh:
If that's the same mod I am thinking of, it hasn't been updated in nearly 4 years so that may be your problem.