topjohnwu / Magisk

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

Galaxy A8/A8+ incompatibility #426

Closed salvogiangri closed 6 years ago

salvogiangri commented 6 years ago

Hello everyone. Galaxy A8/A8+ users are reporting that flashing Magisk on their phone with Samsung Experience 9.0 (Android 8.0.0) up breaks their baseband, preventing them to use all its related features; after some tries we actually found it's related to the patched "init" file in ramdisk. Here there are the various logs to look closer this issue: https://drive.google.com/open?id=1F0kBmFjG45Zh1-yvDYHVCKip7XEZ8SGo Hope those will be helpful for the possible future fix of the issue, let me know if you need more infos/file to look at. Greetings!

DrKetan commented 6 years ago

Yes agree @BlackMesa123 @breakersvd please your PayPal ID

breakersvd commented 6 years ago

@DrKetan thanks for your appreciation but no need for that it is just my work that i love

DrKetan commented 6 years ago

@breakersvd Thank you very very much. highly appreciate your work and service to community!

@topjohnwu kidndly accept and oblige for first successful Note 9 root with magisk Confirmation number: 1JH41555BE2154130

topjohnwu commented 6 years ago

@breakersvd I've come up with my own hex pattern that might work even better For N9, the original hex pattern 603A46B91F0400710030005460C642F9 disassembles to

LDR W0, [X19, #0x638]
CMP W0, #0x1
B.EQ    #0x608
LDR X0, [X19, #0x588]

The 2 + 3 line is p->pid == 1, your patch changes it to p->pid != 1, which technically does not completely defeat the check. I come up with a better patch: 603A46B91F00006B0030005460C642F9, which disassembles to

LDR W0, [X19, #0x638]
CMP W0, W0
B.EQ    #0x608
LDR X0, [X19, #0x588]

The 2nd line can be seen as p->pid == p->pid, which means the 3rd line will always branch, which makes the operation simply if (true)

For the A8 variant, the only difference is that the branch offset is a bit different. Stock: 006044B91F040071802F005460DE41F9

LDR W0, [X0, #0x460]
CMP W0, #1
B.EQ    #0x5F8
LDR X0, [X19, #0x3B8]

Patch: 006044B91F00006B802F005460DE41F9

LDR W0, [X0, #0x460]
CMP W0, W0
B.EQ    #0x5F8
LDR X0, [X19, #0x3B8]

Dunno why the exact same code compile to different instructions, gonna hope this 2 variants are all we will get in the future.

breakersvd commented 6 years ago

@topjohnwu which technically does not completely defeat the check. Defex security will NEVER face a process that will pass p->pid != 1.

And the two hex patterns have the same result it is just bytes difference because of different edits

Anyway, the most important thing is the result and as you see the defex was FULLY defeated. Best regards.

topjohnwu commented 6 years ago

Oh I know what you mean, it just seems to be that init (PID=1) will always run in the whitelist so it technically won't be a problem. My patch is simply just an instruction before your's so it should do the same job. Also, I choose to patch the instruction that is general (the other instructions have non-general offsets), I'm still finding a way to do these patches generally.

breakersvd commented 6 years ago

@topjohnwu I think no need to do like this search because samsung always update it's codes and in N9 samsung added more codes to optimizing vmlinux (i.e. FIPS and SMU (system mount rw protection)) so all offsets will be changed than original gcc And if you try with chainfire RKP patch it will not work anymore but the good part is that samsung didn't enable RKP in N9 yet..

I think hexpatch binary is good in this way and no need to consume your time with it, for me i'm working now to add a patch to magiskinit.c to prevent RMM during boot (which disables oem unlock option and lock the bootloader and so losing root).

salvogiangri commented 6 years ago

@breakersvd I'm pretty much informed about it since me and my team did the fix (lel). RMM State is hardcoded in bootloader so I doubt you can disable it from there, the trigger instead is in system frameworks and the only way it triggers is:

Adding a script that does the job is enough to disable the protection. Regarding set it back to Normal without waiting the 168h uptime it's almost impossible since to unlock itself the phone contacts Samsung RMM Servers with a query and it then returns a token that is used by vaultkeeperd to write the flag (I doubt we can write the flag without a token and without root permissions)

breakersvd commented 6 years ago

@BlackMesa123 The RMM STATE is coded in the kernel ramdisk and the sboot and the system. on first boot the kernel runs /system/bin/vaultkeeperd and this elf file checks property ro.security.vaultkeeper.feature then if it was 1 it checks the service provider for the SIM if it match the CSC on device then it enable oem unlock and edit steady partition to unlock the bootloader.

Actually i did it with magiskinit.c to patch the init.rc to prevent it from create RMM /dev/socket and preventing from executing the vaultkeeperd binary also to edit the property and removing Rlc.apk and this success on [J600F, S8, S9, A8 7.1.1....] only waiting for 7 days to finish to test on my A8 8.0.0.

salvogiangri commented 6 years ago

@breakersvd Nothing new basically lol, we figured out those things months ago when Samsung started to push Rlc v2 on their firmwares, so when first case of RMM Locks went ahead. Here there's my post on XDA regarding RMM with attached a zip flashable file that does the magic, while here there's a thread by my collaborator @corsicanu full dedicated to the issue, with all the explanations and guides on how to get unlocked and how to not trigger anymore the lock (it's anyway enough to just remove Rlc.apk to not trigger the lock in frameworks, but in our custom kernels we anyway keep ro.security.vaultkeeper.feature to 0 and remove vaultkeeperd service aswell)

breakersvd commented 6 years ago

@BlackMesa123 that is what i make the magiskinit to do during the boot and this happened successfully with all samsung devices except A8 8.0.0 because the kernel executes vaultkeeperd service before running magisk on late_start stage (unlike all samsung RMM devices) so i moved the patch to magiskinit (i.e. before running the original init binary) and just wait my device to test if it success

FreshAvocado12 commented 6 years ago

Hello devs. J7 Pro J730G is also having this issue after Oreo 8.1.0 update. No baseband and imei when magisk is installed :/

salvogiangri commented 6 years ago

@FreshAvocado12

Hello devs. J7 Pro J730G is also having this issue after Oreo 8.1.0 update. No baseband and imei when magisk is installed :/

Seems like Defex hexpatches needs to be rewrote because each device's kernel needs different patch due to different offsets. In my opinion add 250 patches in boot_patch.sh is a bit dirty, we might need a way to identify where Defex hex code to patch is located via script and then patch it

breakersvd commented 6 years ago

The defex codes bytes offsets is changed on each new upgrade for whole series of Samsung not each device, for example the above file supports both (J730, J701)

salvogiangri commented 6 years ago

@breakersvd

The defex codes bytes offsets is changed on each new upgrade for whole series of Samsung not each device, for example the above file supports both (J730, J701)

So soc kernel sources related? Both J you mentioned have universal7870 soc so if the hexpatches are ok for both, they should be ok for all the 7870 phones with Defex. The problem still persists, different offsets so it needs more than 1 patch in boot_patch.sh, which is a bit dirty to see

breakersvd commented 6 years ago

That is true but detecting hexpatches that need to be changed is not easy without sources until now, maybe this will be easier in future by another marks in the same offset of defex code, but now i do not have a time to detect that, hope soon

salvogiangri commented 6 years ago

@breakersvd

That is true but detecting hexpatches that need to be changed is not easy without sources until now, maybe this will be easier in future by another marks in the same offset of defex code, but now i do not have a time to detect that, hope soon

7870 8.1 sources are already out actually, here an example (j7xelte ported sources)

breakersvd commented 6 years ago

@BlackMesa123 Yes i downloaded the source and compiled it and find the hexpatch and tested it and it is working (see the history of the zip file)

FreshAvocado12 commented 6 years ago

I feel so good being replied by devs :D

FreshAvocado12 commented 6 years ago

It works @breakersvd thank you!

Thanks a lot and to all of you here :) can i post this on XDA?

breakersvd commented 6 years ago

@FreshAvocado12 It is already exists on XDA

@BlackMesa123 I need an EFS dump from Oreo A530F, did you have it and could help me with sending it ?

FreshAvocado12 commented 6 years ago

Thanks @breakersvd

salvogiangri commented 6 years ago

@breakersvd

@BlackMesa123 I need an EFS dump from Oreo A530F, did you have it and could help me with sending it ?

What file do you need?

breakersvd commented 6 years ago

@BlackMesa123 EXT4 EFS dump [/dev/block/mmcblk0p3]

salvogiangri commented 6 years ago

@breakersvd

@BlackMesa123 EXT4 EFS dump [/dev/block/mmcblk0p3]

I know, but what specific file you need from efs?

breakersvd commented 6 years ago

@BlackMesa123 [nv_data.bin] I'm trying to bypass HWID between two devices

DrKetan commented 6 years ago

@@breakersvd It seems Note9 latest base RI* have break the hex patch :( will confirm after getting new boot.img as I haven't yet downloaded, but users report suggest it's same.

Edit : Checked it and it's broken

breakersvd commented 6 years ago

@DrKetan Samsung did not release the (RI*) base until now, anyway i will do some tries and compares.

Please let continue talking on XDA My account https://forum.xda-developers.com/member.php?u=9489654 I joined to XDA and i am planning to do some useful stuff and need your help 😉

breakersvd commented 6 years ago

@BlackMesa123 @DrKetan https://forum.xda-developers.com/android/software-hacking/test-disable-defex-security-samsung-t3851487

DrKetan commented 6 years ago

@breakersvd Sorry for late reply, actually I was checking opensource site and yet not released source so haven't visited here. I think something went wront there as account is disabled. Anyway I haven't yet download latest built, BTW RJ* also available, should I go with RI or RJ also fine? I will download it tonight and try to test earliest possible. Thank you.

Edit : Sorry I think file is removed. Anyway let me know if I can be a helpful to test anything.

breakersvd commented 6 years ago

@DrKetan I face an account problem on XDA. Anyway i found a ONE hex code that may remove defex security for all Samsung devices and also maybe support Note 9 on Samsung SEC U2 - Base RI*.

if you have the device flash the full stock RI base that the old defex patch does not solve it and upload the boot.img.lz4 from the rom for me

salvogiangri commented 6 years ago

@breakersvd

Anyway i found a ONE hex code that may remove defex security for all Samsung devices and also maybe support Note 9 on Samsung SEC U2 - Base RI*.

It is something in exec.c or another module which aren't directly Defex ones? (I doubt last one since an unique hexpatch is impossible due to diff offsets)

breakersvd commented 6 years ago

@BlackMesa123 Including libs will always generate random offsets so i searched deeper and i found it in fs/exec.c and the compiled codes for this file can not changed from device to another because it contents an unique code to defex that will never changed with all compilers and it is the main executing process during boot unlike the defex C files that may contents codes that defined in other lib.

The hex patch code that i detect is found in the all of models: J730 J530 J701 N960 A530 A730 So i expect to support all of them, i just waiting to confirm device from any tester.

DrKetan commented 6 years ago

@DrKetan I face an account problem on XDA. Anyway i found a ONE hex code that may remove defex security for all Samsung devices and also maybe support Note 9 on Samsung SEC U2 - Base RI*.

if you have the device flash the full stock RI base that the old defex patch does not solve it and upload the boot.img.lz4 from the rom for me

Here boot.img from bri firmware and failed with previous patch If you want me to test, let me know http://www.mediafire.com/file/vd2n68vqzy1n8g3/boot.zip/file

Thank you

breakersvd commented 6 years ago

@DrKetan Here is the Magisk patched boot image: https://mega.nz/#!uchlyCaT!7QjLSWPnP0UKtXcJkwLCf0DjyxFMVkt7SrLN_qtBLS8 could we continue on XDA thread please ? https://forum.xda-developers.com/android/software-hacking/test-disable-defex-security-samsung-t3851487

DrKetan commented 6 years ago

@DrKetan Here is the Magisk patched boot image: https://mega.nz/#!uchlyCaT!7QjLSWPnP0UKtXcJkwLCf0DjyxFMVkt7SrLN_qtBLS8 could we continue on XDA thread please ? https://forum.xda-developers.com/android/software-hacking/test-disable-defex-security-samsung-t3851487

Perfect! Worked like a charm!

ghost commented 4 years ago

Samsung tablets are also facing an on-slot of Defex rooting prevention the SM-T380 and SM-T385 are also not able to get root because of Defex...