- Sep 18, 2017
Please help me understand Magisk Alpha. Is this a Magisk Alpha - Public build?Agree... This is an abusive member who thinks I'm a toxic know-it-all anyway...
I've run Alpha since this was just the base for mtk fix and other branches... Not going down the "it's not legit" route either... Already cited @huskydg's view, but nothing has changed in last couple of weeks ... Source and GitHub builds have been unavailable publicly for months now... PW
Yes, checksum for app-release.apk is the same as when 25210 downloaded from the TG channelPlease help me understand Magisk Alpha. Is this a Magisk Alpha - Public build?
I mentioned that, so did @zgfg... Who cares who said it first?...The guy you are replying quoted husky first. See told you, you are toxic. Blaming me for something someone else did too. Lol. Literally the guy you are responding saying I am bad for linking that linked it before me.
Last Alpha with published source was July last year AFAIK... Source began to be linked from inaccessible (to public) LSPosed GitHub since Feb this year... That's inaccessible for month's in my book...That is toxic. Ok for him before me but not me. LMFAO. Literally are proving my point on the daily.
Ok.Yes, checksum for app-release.apk is the same as when 25210 downloaded from the TG channel
But only the Readme, JSON for auto-updating and latest apk for download, no sources
You originally said:Post in thread '[Discussion] Magisk Alpha (Public Released) fork - @vvb2060' https://forum.xda-developers.com/t/...c-released-fork-vvb2060.4424845/post-88296465
So what I originally said is still true. The GitHub Alpha repos all point to official Magisk now. They didn't a week ago before being wiped...
This is still NOT true... At best, JSON in vv's Alpha GitHub repo points to official Canary notes, and Alpha does build Canary commits but it adds her experimental ones... always has... And lack of public source doesn't change that; ie. Alpha builds are a very different animal...... The Alpha Canary is the same as the Canary Official, FYI.
That's only the original (Chinese) Alpha Discussion thread, now name has changed but a number of members here are in that discussion... Builds aren't shared there however, only in the official Alpha channel...View attachment 5868873
It's all shared from a private channel you can't even see. And the owner isn't listed.
For those who might be confused is that the official Magisk Alpha GitHub source (wrong, it is not) and why its Readme Download links to the official Canary (yielding somebody to wrongly think that Alpha is nothing else but Magisk Canary)This is the Magsik Alpha. The links on this page link to Magisk Debug latest version. The code hasn't been updated but the links and where they are the same as canary/debug official build.
GitHub - CoderTyn/Magisk-AlphaContribute to CoderTyn/Magisk-Alpha development by creating an account on GitHub.github.com
Thank you, though that link is, of course, in the information thread and peppered all through this discussion thread so nothing newI have been using this link for current code changes.
GitHub - topjohnwu/Magisk: The Magic Mask for AndroidThe Magic Mask for Android. Contribute to topjohnwu/Magisk development by creating an account on GitHub.github.com
Users should be aware that official @kdrag0n fix is busted ATM however.... Use this fork:Also current changes for safetynet Fix
kdrag0n - OverviewGeneralist dev exploring new things. kdrag0n has 120 repositories available. Follow their code on GitHub.github.com
Who is this talking toI am using Magisk Delta, what's your question?
Who is spreading the lies?John was not part of that group. Quit spreading lies.
What I said was once you root something's will never work again which is CORRECT. Of course you can relock bootloader but it won't fix the apps that will never work again and that was my point ffsStill, you said
which is just not true. You can both re-lock B/L and use stock ROM again and you will have Android like other devices. Samsung just disable their proprietary special knox-based features after device is tampered...
Old Sammy devices did work that way, but now soc makers include e-fuses that utilise physical burn-in on the substrate... I put info on use of q-fuses (Qualcomm) here:
I put a number of links here (incl. ref. above):
Yup... It's a choice... Much like Google's device integrity APIs and key attestation models really... They're doing that because they must compete in the secure Mobile OS arena in today's climate, and are loosing to IOS in the enterprise/corporate marketplace because of the (justified) perception that Android is largely insecure...
Samsung want to position themselves as a credible alternative to IOS/iPhone and as the leading manufacturer of property secure Android devices in this market too as the (somewhat outdated) links above show...
The difference in these approaches (ie. Google doesn't penalise modders by making the restoration of some device features impossible while Samsung does) may indicate that Google is more supportive of the modding community than is Samsung... I don't know if Sammy encourage custom modders in any way other than allowing B/L unlock... But it's still far more generous that what IOS will offer you!
Ah... Sorry.What I said was once you root something's will never work again which is CORRECT. Of course you can relock bootloader but it won't fix the apps that will never work again and that was my point ffs
to mean you 'can't relock bootloader and go back to stock on Sammy once you trip Knox, and that's something that will never ever work again' rather than 'If you relock bootloader and go to back stock on Sammy, once you trip Knox some things will never ever work again'!...At least you can relock bootloader and go back stock I guess. On Sammy once you trip Knox that's it something's will never ever work again...
Unfortunately I use everyones of the apps you listed which is why i never rooted my zfold 3. The one think Knox gives you is adhell 3 and other similar apps. You can use the Knox firewall as a pretty effective adblocker and to disable system apps/remove permissions and receivers.
At least you can relock bootloader and go back stock I guess. On Sammy once you trip Knox that's it something's will never ever work again...
Old Sammy devices did work that way, but now soc makers include e-fuses that utilise physical burn-in on the substrate... I put info on use of q-fuses (Qualcomm) here:I must say that I totaly hate that warranty bit. No idea why, when relocking the device and wiping the device completely that bit is not reverted to 0x0 to allow the full experience.
If a non-Knox boot loader or kernel has been installed on the device, Knox can no longer guarantee the security of the Knox container. As a result, the Warranty Bit is tripped to 0X1, indicating that this device can no longer use the Knox Workspace (container.)
Yup... It's a choice... Much like Google's device integrity APIs and key attestation models really... They're doing that because they must compete in the secure Mobile OS arena in today's climate, and are loosing to IOS in the enterprise/corporate marketplace because of the (justified) perception that Android is largely insecure...It's one of the biggest things that I dislike about Samsung devices as I like to root my devices and make roms for them .
How do you know?
You must be an expert or something
As I expected in advance, problems with Magisk occurred after the OTA update of LineageOS (Pixel 6a).
Updated from a 20.0 build to lineage-20.0-20230429-nightly-bluejay
After the update it was necessary to flash the new boot image again. I have done that. But Magisk simply does not root. Magisk patched the downloaded LineageOS boot-image, saved it in the download folder and that was it.
Magisk was hidden before I did OTA update.
Simply very beautiful. All this after setting up LineageOS to my liking.
And what can I do now except re-flash ROM?
Thanks, I realize it is only needed for custom Kernel cases.Yeah, if I want to run a custom kernel (Pixel 7) then I need to wipe. Should have sideloaded (not booted up), then gone into bootloader and run
fastboot flash vbmeta --disable-verity --disable-verification vbmeta.imgto that slot. Once booted after sideload/flashing the firmware it's too late as it's enabled after booting. Don't think it matters if you do it before or after flashing the patched image, just as long as you do it before you boot up. Oh well, lol...
Nothing to do with what we were testing, just custom kernel related. Seems to also help to avoid getting the red
eiocorrupt message when things may not go as expected.
Others have already addressed your question, but for me, the biggest benefit here is to have a safety valve in place where your inactive slot is bootable (without first having to flash the firmware) in case you get into a hairy situation where your active slot becomes unbootable for whatever reason. May be useful in some situations.So as well as making it easier to keep root with an ota we can have the same firmware on the device one rooted and one not? So if magisk hide/safetynet/etc aren't working we can boot to the non rooted firmware to use wallet/banking apps etc and then boot back to rooted. Or is it a bit more complicated than that? Never had a pixel device before
If the "issue" is that you have not yet been able to reproduce the Magisk manager app's "Ramdisk: Yes/No":
Did you try a "wrapper" for the shell script function you found? At the time you reported several script fragments, there was talk of needing to call other functions first to set up environment variables.
Look up the "echo" command. There is a form that causes the shell to echo all lines as they are executed. Do this, redirect output to a log file, and you can crawl through and maybe spot where it first disappoints you.
I'm running into an interesting problem that I can't put my fingers on, and am open to ideas / suggestions.
As you may already know, Magisk embeds the SHA1 of the stock boot image used to create the patch into the patched image, this is great because one can easily determine the source image that was used and validate if it is what it is supposed to be.
And this is exactly what PF does, it extracts the SHA1 from the patched image.
Here's the function code
def extract_sha1(binfile, length = 8): with open(binfile, 'rb') as f: s = f.read() # Find SHA1= pos = s.find(b'\x53\x48\x41\x31\x3D') # Move to that location if pos != -1: # move to 5 characters from the found position f.seek(pos + 5, 0) # read length bytes res = f.read(length) return res.decode("utf-8")
Unlike magiskboot and Android Kitchen Tools by @osm0sis which extracts the ramdisk.cpio and performs magiskboot cpio <ramdisk.cpio> sha1 on it, PF (to keep it lightweight) it just looks for the string
SHA1=directly on the patched file and then reads the next 8 hex characters and converts them to ascii.
And this has worked flawlessly so far, until this.
Basically what is happening is:
The expected embedded SHA1 is: 40100d6b9512f6dffbb6f6b67c1b878f3bd82d18
With the exception of the red part of the SHA1, everything matches.
In one case 0100 part which is expected to be 30 31 30 30 hex it is instead 89 00 FB 33, and in the other case it is 72 00 FC 15
View attachment 5902493View attachment 5902495
I don't understand why this is happening, my first guess would be some kind of encoding, but then why now and only with this image, my other guess / fear is that perhaps the writing is not clean which would be a bug in Magisk.
Obviously I can skip over the first few bytes and do the validation with the remaining bytes, but I'd hate to take a path like that without understanding why this is happening, who's to say that this thing can't happen on the other portions of the SHA1 string.
If you have any ideas, I'm all ears.