Closed salvogiangri closed 6 years ago
Yes agree @BlackMesa123 @breakersvd please your PayPal ID
@DrKetan thanks for your appreciation but no need for that it is just my work that i love
@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
@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.
@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.
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.
@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).
@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)
@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.
@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)
@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
Hello devs. J7 Pro J730G is also having this issue after Oreo 8.1.0 update. No baseband and imei when magisk is installed :/
@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
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)
@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
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
@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)
@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)
I feel so good being replied by devs :D
It works @breakersvd thank you!
Thanks a lot and to all of you here :) can i post this on XDA?
@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 ?
Thanks @breakersvd
@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?
@BlackMesa123 EXT4 EFS dump [/dev/block/mmcblk0p3]
@breakersvd
@BlackMesa123 EXT4 EFS dump [/dev/block/mmcblk0p3]
I know, but what specific file you need from efs?
@BlackMesa123 [nv_data.bin] I'm trying to bypass HWID between two devices
@@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
@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 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.
@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
@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)
@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 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
@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 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!
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...
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!