Can You Get Root With A MITM Attack? - General Questions and Answers

I have a Samsung A535w which doesn't have OEM unlock enabled so I can't unlock the bootloader and thus I can't get Root.
Is it possible to use a man in the middle attack to hijack an update to enable the option?
Alternatively, can I install a rootkit to do a similar thing?
Are either of these even theoretically possible?
I read about rootkits coming from apps in the PlayStore all the time.
Does the bootloader need to be unlocked to do this?
Ignore the implicit dangers of this and assume that I am going to craft the attack updates myself.

opticyclic said:
I have a Samsung A535w which doesn't have OEM unlock enabled so I can't unlock the bootloader and thus I can't get Root.
Is it possible to use a man in the middle attack to hijack an update to enable the option?
Alternatively, can I install a rootkit to do a similar thing?
Are either of these even theoretically possible?
I read about rootkits coming from apps in the PlayStore all the time.
Does the bootloader need to be unlocked to do this?
Ignore the implicit dangers of this and assume that I am going to craft the attack updates myself.
Click to expand...
Click to collapse
hello, i cannot find any info on this device, is the processor mtk, qcom, or exynos

To root a phone's Android it's never needed to unlock phone's bootloader: this is a fairy tale which is told hundreds of times here and elsewhere.

opticyclic said:
I have a Samsung A535w which doesn't have OEM unlock enabled so I can't unlock the bootloader and thus I can't get Root.
Is it possible to use a man in the middle attack to hijack an update to enable the option?
Alternatively, can I install a rootkit to do a similar thing?
Are either of these even theoretically possible?
I read about rootkits coming from apps in the PlayStore all the time.
Does the bootloader need to be unlocked to do this?
Ignore the implicit dangers of this and assume that I am going to craft the attack updates myself.
Click to expand...
Click to collapse
Assuming the OEM uses the AOSP model (which Samsung doesn't), no.
Hardware backed Keystore
SELinux
Trusty
Android Verified Boot
All of these work together.
When the bootloader is locked, the boot image is verified (using a cryptographic hash signed by the hardware keystore, which is itself verified) to determine its integrity. This prevents persistent rootkits.
During run time, SELinux enforces access control over all processes, even those with root privileges.
Trusty is a completely separate and isolated secure environment that runs alongside the Android kernel and is used as a "trusted verifier"
And this isn't even getting into the security features implemented in the update process.
For this attack vector you're describing to work, you would have to have the OEM's private and proprietary key used to sign everything in the update package, otherwise an unsigned or incorrectly signed package will be rejected. And even if you did manage to sign the update package, you'd have to essentially reprogram the hardware keys to match, because even if the update flashed to the device, all the images would fail verification because of the hardware keystore authentication.
xXx yYy said:
To root a phone's Android it's never needed to unlock phone's bootloader: this is a fairy tale which is told hundreds of times here and elsewhere.
Click to expand...
Click to collapse
Source?
How do you get elevated permissions in a protected environment without compromising the boot image, which would make the device fail to boot?

V0latyle said:
Source?
How do you get elevated permissions in a protected environment without compromising the boot image, which would make the device fail to boot?
Click to expand...
Click to collapse
You probably don't know how rooting Android is accomplished: no elevated permissions are needed to run SU binary.

xXx yYy said:
You probably don't know how rooting Android is accomplished: no elevated permissions are needed to run SU binary.
Click to expand...
Click to collapse
Explain?

$cronos_ said:
hello, i cannot find any info on this device, is the processor mtk, qcom, or exynos
Click to expand...
Click to collapse
Samsung Galaxy A53 5G - Full phone specifications
www.gsmarena.com
Although it says exynos on that page, I believe this is a Snapdragon as it has the W suffix on the model and as I am in Canada it looks to be the US version.
PSA: There is No OEM Unlock on US Galaxy A53's
Whether you get a carrier version or the factory unlocked U1 model, OEM unlock does not exist on this phone. So those in the US that were thinking of doing custom roms with this cheap new Android device, look elsewhere.
forum.xda-developers.com
V0latyle said:
Assuming the OEM uses the AOSP model (which Samsung doesn't), no.
Hardware backed Keystore
SELinux
Trusty
Android Verified Boot
All of these work together.
When the bootloader is locked, the boot image is verified (using a cryptographic hash signed by the hardware keystore, which is itself verified) to determine its integrity. This prevents persistent rootkits.
During run time, SELinux enforces access control over all processes, even those with root privileges.
Trusty is a completely separate and isolated secure environment that runs alongside the Android kernel and is used as a "trusted verifier"
And this isn't even getting into the security features implemented in the update process.
For this attack vector you're describing to work, you would have to have the OEM's private and proprietary key used to sign everything in the update package, otherwise an unsigned or incorrectly signed package will be rejected. And even if you did manage to sign the update package, you'd have to essentially reprogram the hardware keys to match, because even if the update flashed to the device, all the images would fail verification because of the hardware keystore authentication.
Click to expand...
Click to collapse
Thanks for the info.

@pndwal since you're much more knowledgeable on this topic than I, care to jump in here?

V0latyle said:
@pndwal since you're much more knowledgeable on this topic than I, care to jump in here?
Click to expand...
Click to collapse
Topic of temp root etc using vulns / exploits?; All I know is from reading...
This 'Deployment' developer doc was removed in January but mentioned Magisk deployment via exploits:
https://github.com/topjohnwu/Magisk...62964e41201b9f157923b/docs/deploy.md#exploits
I believe this temp MagiskSU from such a root shell can then often be used to flash/obtain full-fleged Magisk root...
Exploit / vulnerability based root certainly has benefits, one of which is ease of properly (and fully) bypassing device integrity attestations since kernel can be modified while bootloader remains locked... John commented here (and on future potential):
www.twitter.com/topjohnwu/status/1299903496028790785
... Doubt he'll be elaborating on this any more somehow...
There may not be many useful exploits for root due to security research, pen testing, patching, anti rollback etc... Here's a recent one that can be leveraged for Pixel 6; POC here:
https://github.com/polygraphene/DirtyPipe-Android
... This is already patched from 2022-04-05...
Could be used for Realme GT2 Pro, some Galaxy S22 models, others(?)... The process notes may be enlightening: https://github.com/polygraphene/DirtyPipe-Android/blob/master/TECHNICAL-DETAILS.md#exploit-process
XDA article re. 'infamous "Dirty Pipe" vulnerability can be exploited on the Samsung Galaxy S22 and the Google Pixel 6 Pro to gain root shell access':
https://www.xda-developers.com/tag/root-exploit/
This vuln caused a minor furore over Google anti-rollback w/ A13 update etc... Ex XDA editor Mishael commented:
www.twitter.com/MishaalRahman/status/1511036735433715719
Johns here:
www.twitter.com/topjohnwu/status/1511107456566390785
... I want "MagiPipe" One-Click Root app w/ the rainbow Magikarp icon!
Further:
www.twitter.com/topjohnwu/status/1559786740050644992
And Shawn Willden on patching, anti-rollback counters etc here:
www.twitter.com/shawnwillden/status/1559893884120928256
Older 'Linux Kernel bug dubbed 'Dirty Cow' can Root every version of Android' article by Mishael:
https://www.xda-developers.com/9-ye...-dirty-cow-can-root-every-version-of-android/
PW

V0latyle said:
Assuming the OEM uses the AOSP model (which Samsung doesn't), no.
Click to expand...
Click to collapse
...
Please can you explain what you mean here?... I understood '(AOSP) is the bedrock of modern Android skins like One UI and MIUI'...
https://www.androidauthority.com/aosp-explained-1093505/
Is this wrong?...
Can't see how even heavy OEM Android OS skins would make a difference to OEM unlock (or even using a root kit hypothetically)... Aren't unlock options etc determined by OEMs and re-sellers?...
And user does have Samsung device anyway... PW

pndwal said:
...
Please can you explain what you mean here?... I understood '(AOSP) is the bedrock of modern Android skins like One UI and MIUI'...
https://www.androidauthority.com/aosp-explained-1093505/
Is this wrong?...
Can't see how even heavy OEM Android OS skins would make a difference to OEM unlock (or even using a root kit hypothetically)... Aren't unlock options etc determined by OEMs and re-sellers?...
And user does have Samsung device anyway... PW
Click to expand...
Click to collapse
What I mean is whether Samsung follows the same Android security model, with verified boot, dm-verity, and so on. They do have security features implemented to prevent unsigned binaries (even if the bootloader is unlocked) but they also add a lot of their own stuff like Knox and Vaultkeeper. Either way, it would be difficult for a rootkit to persist after reboot because of these security features.
My understanding of OneUI is that it's not just a reskin/overlay but it also changes a lot of the core components as well. I could be wrong.

V0latyle said:
What I mean is whether Samsung follows the same Android security model, with verified boot, dm-verity, and so on.
Click to expand...
Click to collapse
Of course they do... AVB (ie Verified Boot 2.0) is mandated for any Android 8+ certified implementation...
An AOSP-compatible device must conform to the list of requirements in the Compatibility Definition Document (CDD). An Android-compatible device must conform to the list of requirements in the CDD and Vendor Software Requirements (VSR) and tests such as those in the Vendor Test Suite (VTS) and Compatability Test Suite (CTS).
Click to expand...
Click to collapse
https://source.android.com/docs/core/architecture#hidl
Eg. CCD:
https://source.android.com/docs/compatibility/cdd
see 9.9.2. File Based Encryption:
[C-1-4] MUST support Verified Boot and ensure that DE keys are cryptographically bound to the device's hardware root of trust. etc...
https://source.android.com/docs/compatibility/8.0/android-8.0-cdd
device-mapper-verity (dm-verity) is simply a kernel feature used since A 4.4 to implement Verified Boot...
V0latyle said:
They do have security features implemented to prevent unsigned binaries (even if the bootloader is unlocked) but they also add a lot of their own stuff like Knox and Vaultkeeper.
Click to expand...
Click to collapse
Sure; and MIUI adds Xiaomi Security Centre...
OEMs can add what they like as long as they comply with the CDD and VSR incl VTS and CTS...
V0latyle said:
Either way, it would be difficult for a rootkit to persist after reboot because of these security features.
Click to expand...
Click to collapse
Well maybe...
I'm unaware of any special safeguards against root whether userspace based or exploit based personally...
V0latyle said:
My understanding of OneUI is that it's not just a reskin/overlay but it also changes a lot of the core components as well. I could be wrong.
Click to expand...
Click to collapse
Well Android skins are necessarily software tweaks that live on top of stock Android; "They often look very different and offer features that other skins don't. In other words, underneath all the additional design and functionality tweaks, the core version of Android is on all Android devices." More on this here:
https://www.androidauthority.com/android-skins-945375/
Also these can't change security requirements for API/SDK level compliance... There is lattitude for OEMs to use their own components, but this is of course costly; Eg OEMs are free to implement their own TEE OS instead of Google's Trusty TEE, but most use Trusty as it's free and works fine!... PW

All very interesting. Thanks.
I remember using Dirty Cow to root a previous device.
My first phone was the Samsung Galaxy Nexus and after that I used several Chinese brands and got root on everything.
Because of the popularity of Samsung I assumed that root would be available.

Related

[Q] CF Auto Root - Will it wipe encrypted lollipop phones?

Hi all,
I'm planning to root my encrypted Nexus 5 with Lollipop by the latest CF Auto Root. Is it still the case that encrypted phones will be wiped by CF Auto Root? Chainfire said that would no longer be the case on 11 October 2014 (head to his Google+ page for the post). I'm wondering if the latest CF Auto Root for Nexus 5 Lollipop will wipe my encrypted storage.
It would be great if Chainfire could answer my question.
Thanks!
yes, it will no longer touch the data.
See his October 10, 2014 post.
CF-Auto-Root
There have been a few changes to the CF-Auto-Root installer as well. One noteworthy one is that in preparation for L having encryption enabled by default, it no longer touches /data. This is both good and bad.
The good is that it doesn't need to know your decryption key, the process remains automatic, and encrypted phones are no longer wiped on usage of CF-Auto-Root.
The bad is that this means some /data cleanup code is run on first boot after rooting, which may trigger a (one) reboot in the process. I do not expect bootloops because of this, it works fine on all the devices I have tested it on, but you never know.
Additionally, because CF-Auto-Root cannot distinguish between a garbage and an encrypted partition, it no longer fixes OEM unlock issues. On several fastboot based devices, the OEM unlock command, instead of formatting /data and /cache, wipes them. Android will not automatically re-format them anymore (used to in 2.x days), which means that your device will forever bootloop until you manually format /data and /cache (which CF-Auto-Root did for you automatically in the past).
Last but not least, some changes have been made to allow the progress to be visible on some new Qualcomm based devices. While I would normally not waste words on something as trivial as this, I would like to point out that these devices no longer support fbdev to put content on screen, but instead use something called Qualcomm overlay. Nothing basically wrong with that either, aside from the absolutely horrid fact that the interface to this changes between different kernels in a completely incompatible way, pretty much requiring a userspace program to use the exact right version of kernel headers to do something as basic as putting anything onscreen. Making a non-kernel specific binary that support a wide range of devices is thus now nigh impossible unless some very ugly code and errorprone methods are employed. As such, I expect that ultimately there will be no visual progress for CF-Auto-Root anymore on Qualcomm based devices, as I certainly can't be bothered keeping track of these shenanigans.
Click to expand...
Click to collapse
Thanks. This is the post that I was referring to.
Has anyone with encrypted Nexus 5 tried it out yet?
matthew01202 said:
Thanks. This is the post that I was referring to.
Has anyone with encrypted Nexus 5 tried it out yet?
Click to expand...
Click to collapse
Encrypted Nexus 6 works fine. Didn't wipe anything. I'm sure it's the same for the N5.

[DEV] Bootloader Signature Bypass

Hello @rbox,
I have implemented a bootloader signature bypass and was wondering if you could help me verify my method.
Because we know this works for the firetv, my plan is:
1. You could send me one of your unsigned custom recoveries for firetv.
2. I would then sign it and send it back to you to check it works.
Hope you don't mind me contacting you this way.
ggow
Woah! Props! I still don't plan on picking up an HDX, but at least it'll get some development now! Now just to get root on KitKat for you guys.
@rbox,
I should add some information which I forgot to include earlier:
I tried the recovery image on the device but failed to boot which is why I need some help to verify my method to find out whether our bootloader is susceptible to this approach, mathematically it looks good (I think). See what you think. I have PM'ed you a link to the modified recovery image as we discussed.
Conclusions
@rbox
In short I found our bootloader is NOT susceptible to the signature bypass method.
I tried first on stock 13.3.2.4 and then on stock 13.3.1.0.
Thanks for your help rbox. I really appreciate you taking the time.
I had some implementation issues in my work which led to to the differences between our output files.
I believe I have fixed those now.
Bootloader question
How much has been done with anyone looking into the unlock code functionality for the bootloader? I have spent a ton of time (mostly wasted time it has turned out), trying to make any kind of sense of the bootloader using IDA Pro with hex-rays decompilation. It seems easy enough to write an unlock code for the device using idme, but not knowing what the code is, and not knowing where in the bootloader decompilation the unlock checking is done has just lead to dead ends. I assume from some posts in much older development threads that some very smart people already spent some time attempting to decompile the bootloader and didn't have much luck. Does anyone think anything can be gained from further muddling around with the decompilation?
gbgadgets said:
How much has been done with anyone looking into the unlock code functionality for the bootloader? I have spent a ton of time (mostly wasted time it has turned out), trying to make any kind of sense of the bootloader using IDA Pro with hex-rays decompilation. It seems easy enough to write an unlock code for the device using idme, but not knowing what the code is, and not knowing where in the bootloader decompilation the unlock checking is done has just lead to dead ends. I assume from some posts in much older development threads that some very smart people already spent some time attempting to decompile the bootloader and didn't have much luck. Does anyone think anything can be gained from further muddling around with the decompilation?
Click to expand...
Click to collapse
I did the same as you and found "unlock_code" can be read from idme, but not without unlocking the bootloader. I can't seem to find it in any partition either.
ggow said:
@rbox
In short I found our bootloader is NOT susceptible to the signature bypass method.
I tried first on stock 13.3.2.4 and then on stock 13.3.1.0.
Thanks for your help rbox. I really appreciate you taking the time.
I had some implementation issues in my work which led to to the differences between our output files.
I believe I have fixed those now.
Click to expand...
Click to collapse
Have you taken a look at the 2nd_init hack? Safestrap uses it to load a recovery, but it can also be used to load new kernels.
r3pwn said:
I did the same as you and found "unlock_code" can be read from idme, but not without unlocking the bootloader. I can't seem to find it in any partition either.
Have you taken a look at the 2nd_init hack? Safestrap uses it to load a recovery, but it can also be used to load new kernels.
Click to expand...
Click to collapse
Hi r3pwn, I looked at 2nd init. I can use it to load a new ramdisk which is great. But I don't think you can load a different kernel. Also correct me I'm wrong, I don't think we can boot kitkat on the jelly bean kernel with a modified ramdisk.
Sent from my Nexus HDX 7 using Tapatalk
ggow said:
Hi r3pwn, I looked at 2nd init. I can use it to load a new ramdisk which is great. But I don't think you can load a different kernel. Also correct me I'm wrong, I don't think we can boot kitkat on the jelly bean kernel with a modified ramdisk.
Sent from my Nexus HDX 7 using Tapatalk
Click to expand...
Click to collapse
Oh. My bad. Meant ramdisk. Not sure why kernel came out. The devs over with the Sony Xperia SP (I think, lemme double check) managed to run Lollipop on their JB 4.3 device using the 2nd init. Let me look some more and report back with (hopefully) useful info.
Edit: Yep, it is the SP. Their rd hijack process: https://bitbucket.org/bagyusz/hijack-ramdisk-huashan/src/20a66537e120?at=cm-10.2_LBL. They list the rest of their sources at the bottom of the post here (Device tree, vendor tree, how to make the ramdisk alone, etc...): http://forum.xda-developers.com/xperia-sp/development/xperiasp-locked-bootloader-lbl-t2947194
Cool, will take a look
Sent from my Nexus HDX 7 using Tapatalk
r3pwn said:
Oh. My bad. Meant ramdisk. Not sure why kernel came out. The devs over with the Sony Xperia SP (I think, lemme double check) managed to run Lollipop on their JB 4.3 device using the 2nd init. Let me look some more and report back with (hopefully) useful info.
Edit: Yep, it is the SP. Their rd hijack process: https://bitbucket.org/bagyusz/hijack-ramdisk-huashan/src/20a66537e120?at=cm-10.2_LBL. They list the rest of their sources at the bottom of the post here (Device tree, vendor tree, how to make the ramdisk alone, etc...): http://forum.xda-developers.com/xperia-sp/development/xperiasp-locked-bootloader-lbl-t2947194
Click to expand...
Click to collapse
@r3pwn,
Thanks for the pointing me in that direction... With the 13.3.2.4 stock kernel I have a build of aosp lollipop 5.0.1 which now boots to some degree. Very early days yet but some progress. I now have adb access. I can see that in logcat services are starting up and then dying.
I can't see the boot animation yet because the video driver / surfaceflinger is not starting. First goal is to get that and full hw graphical support working.
Definitely a way forward
ggow said:
@r3pwn,
Thanks for the pointing me in that direction... With the 13.3.2.4 stock kernel I have a build of aosp lollipop 5.0.1 which now boots to some degree. Very early days yet but some progress. I now have adb access. I can see that in logcat services are starting up and then dying.
I can't see the boot animation yet because the video driver / surfaceflinger is not starting. First goal is to get that and full hw graphical support working.
Definitely a way forward
Click to expand...
Click to collapse
Thanks! Glad I could help! If there's anything you need help with, let me know and I could try to get in contact with the Xperia SP devs and maybe even get a Hangout set up.
I have examined aboot for some time now and I can think of 3 methods to unlock the bootloader:
Provide the unlock code. The code seems to be a 512 byte image, that is flashed by "fastboot flash unlock code.img". The code is somehow verified using a X509 certificate. Writing an arbitrary code to unlock_code won't work, because the code will be verified the same way the code.img is verified.
Overwrite the certificate a custom one and create a custom code. For this approach we have to understand the verification process and we obliviously need to know the location of the certificate and write access.
There is some variable called "production" we would have to change. The variable is obtained by
Code:
MOV R3, 0xFD511004
LDR R0, [R3,R0,LSL#4]
AND R0, R0, #1
R0 has the value 0x5C.
In C pseudocode:
Code:
int production = *(0xFD511004 + 92*2^4) & 1;
The default value of that variable is 1.
Anyone with ideas here?
vortox said:
I have examined aboot for some time now and I can think of 3 methods to unlock the bootloader:
Provide the unlock code. The code seems to be a 512 byte image, that is flashed by "fastboot flash unlock code.img". The code is somehow verified using a X509 certificate. Writing an arbitrary code to unlock_code won't work, because the code will be verified the same way the code.img is verified.
Overwrite the certificate a custom one and create a custom code. For this approach we have to understand the verification process and we obliviously need to know the location of the certificate and write access.
There is some variable called "production" we would have to change. The variable is obtained by
Code:
MOV R3, 0xFD511004
LDR R0, [R3,R0,LSL#4]
AND R0, R0, #1
R0 has the value 0x5C.
In C pseudocode:
Code:
int production = *(0xFD511004 + 92*2^4) & 1;
The default value of that variable is 1.
Anyone with ideas here?
Click to expand...
Click to collapse
I can't answer that, but @Cpasjuste may be revealing something soon according to this thread: http://forum.xda-developers.com/kindle-fire-hdx/development/cm-11-t2971457
I was using some information from this source aboot reverse engineering to try and figure more out about the structure of aboot. The fact that the strings are obfuscated and don't appear through the decompiled functions was the biggest hurdle I was running into starting with this. I tried to use the open source little kernel code to see if a few of these functions could be put into better pseudocode and perhaps crack the string obfuscation to be able to xref more strings throughout the decompilation of the hundreds of functions. Just kept getting stuck.
I've been using this loader for IDA. I see a lot of strings and they have been very useful .
Further I've found the certificate in the aboot partition. This means my 2. suggestion probably wouldn't work.
This leaves me with 2 two possible options:
Brute force the image (unlikely)
Looking at the production variable to see if it can be safely overwriten without a side effect
vortox said:
I've been using this loader for IDA. I see a lot of strings and they have been very useful. [/LIST]
Click to expand...
Click to collapse
Off-topic,
you can use this loader to load sbl1.mbn, sbl2,mbn, sbl3.mbn, aboot.mbn tz.mbn and rpm.mbn?
maybe a debricking solution...
aaronkatrini said:
Off-topic,
you can use this loader to load sbl1.mbn, sbl2,mbn, sbl3.mbn, aboot.mbn tz.mbn and rpm.mbn?
maybe a debricking solution...
Click to expand...
Click to collapse
Nope. It's just to load those files into IDA PRO and helps reverse engineering them.
vortox said:
I've been using this loader for IDA. I see a lot of strings and they have been very useful .
Further I've found the certificate in the aboot partition. This means my 2. suggestion probably wouldn't work.
This leaves me with 2 two possible options:
Brute force the image (unlikely)
Looking at the production variable to see if it can be safely overwriten without a side effect
Click to expand...
Click to collapse
Could you share the certificate? I think there should be no legal problem with that.
@vortox
This article may refer to the production variable your talking about.
http://blog.azimuthsecurity.com/2013/05/exploiting-samsung-galaxy-s4-secure-boot.html
Seems to be following CVE: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0974
Besides of that, has somebody tried to insert the kexec module into the kernel? http://forum.xda-developers.com/galaxy-note-3/devs-only/kernel-kernel-execution-loading-custom-t2812650
D0ubl3_X said:
Could you share the certificate? I think there should be no legal problem with that.
Click to expand...
Click to collapse
I will try my best to obtain the cerificate.
@vortox
This article may refer to the production variable your talking about. http://blog.azimuthsecurity.com/2013/05/exploiting-samsung-galaxy-s4-secure-boot.html
Click to expand...
Click to collapse
Thanks for the link.
Seems to be following CVE: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0974
Click to expand...
Click to collapse
I will take a look at that.
Edit:
@D0ubl3_X
Here the certificate used for checking the unlock code. http://www45.zippyshare.com/v/82885181/file.html
Edit2 :
The post in the blog does not match the CVE. This is the right one. This exploit hat been patched.
But the CVE you posted seems unpatched. Atleast on my device with .3.2.4. The newer version are probably patched.
Edit3:
Another possible exploit: https://www.codeaurora.org/projects...tion-leads-to-signature-forgery-cve-2014-0973
September 4th - @jcase said : "If you can port it yourself, feel free, more than one of these works on the HDX https://www.codeaurora.org/projects/security-advisories ..."
There are 18 exploits, but at least one of them works!

Nugat rom with no need for ROOT? Plausible?

Hi,
I'm fond of my non-root software, just because there is a number of apps that I use on regular basis that do not allow root.
Is it going to be at all possible to build a "custom rom" that will be able to run those applications that typically just FAIL when root is detected, by simply not forcing root on the device?
Look forward to hearing from you.
mikber18 said:
Hi,
I'm fond of my non-root software, just because there is a number of apps that I use on regular basis that do not allow root.
Is it going to be at all possible to build a "custom rom" that will be able to run those applications that typically just FAIL when root is detected, by simply not forcing root on the device?
Look forward to hearing from you.
Click to expand...
Click to collapse
Well, it depends on a couple things:
First, there are different ways that apps can detect root. Some apps simply try to gain access to root. But more advanced apps, a notable one being Android Pay, also check if the firmware running on the device has passed Google's CTS tests, which only original 100% stock firmware can pass.
So is your device 100% stock non-modified, or is it a custom ROM with no root access? This will help determine if the apps you use are of the more simple kind, or of the advanced kind.
At this present moment I'm running the Sony Concept software and realistically I would love to continue to be running the latest OS, but unless something like Sony Concept continue to exist the only way to run 7.0 in the future will be a custom Rom. Almost all custom Roms require Root, is there hope that one gets developed that will run similarly to the Concept Software project, I.e. No need for root or nada and thereby allowing me to use my apps (banking etc) that do a scan against root + custom software

SM-J337A: Need to Access Certain Permissions and/or Root

Hello. I have been an Android user since 2012, and am new to the XDA-Developers forum.
I am technically inclined to a point, but I am by no means in the Developer category. I have successfully rooted one phone, but that was running Android 5.0 and the process seemed to be A LOT simpler than that which is required for today's more sophisticated operating systems.
I come here tonight seeking assistance with an unlocked Samsung SM-J337A running Android 8.0. I purchased this phone online and not from a carrier. Specifically, I am seeking to gain write permission access to the SD card for all third-party apps. None of the automatic call recording apps available in the Play Store function properly without this permission, and in my work I require a phone running Android 7.0 at minimum. Additionally, I am seeking to install a system-wide ad blocker which doesn't necessitate using a battery-draining VPN.
Here are the stats from this phone:
Baseband: J337AUCU3ARJ1
Kernel: 3.18.14-13465503-QB20325568
Build: R16NW.J337AUCU3ARJ1
Knox: 3.1, API level 25, TIMA 4.0.0
Security: ASKS v1.4 Release 180123; FIPS BoringSSL v1.2; SMR Sep-2018 Release 1
I need to know if what I am seeking to do with this phone is possible. Otherwise, I will have to obtain an Android 7.0 or 8.0 phone with which I can successfully gain these permissions or outright root to accomplish same.
So far, all I have been able to do is access Developer Options. From there, I cannot even determine if this device has an unlocked bootloader as there is no "OEM Unlock" option or anything remotely similar under that menu option.
Please assist me with suggestions on how best to proceed. Thank you.
IPaidIOwn said:
Hello. I have been an Android user since 2012, and am new to the XDA-Developers forum.
I am technically inclined to a point, but I am by no means in the Developer category. I have successfully rooted one phone, but that was running Android 5.0 and the process seemed to be A LOT simpler than that which is required for today's more sophisticated operating systems.
I come here tonight seeking assistance with an unlocked Samsung SM-J337A running Android 8.0. I purchased this phone online and not from a carrier. Specifically, I am seeking to gain write permission access to the SD card for all third-party apps. None of the automatic call recording apps available in the Play Store function properly without this permission, and in my work I require a phone running Android 7.0 at minimum. Additionally, I am seeking to install a system-wide ad blocker which doesn't necessitate using a battery-draining VPN.
Here are the stats from this phone:
Baseband: J337AUCU3ARJ1
Kernel: 3.18.14-13465503-QB20325568
Build: R16NW.J337AUCU3ARJ1
Knox: 3.1, API level 25, TIMA 4.0.0
Security: ASKS v1.4 Release 180123; FIPS BoringSSL v1.2; SMR Sep-2018 Release 1
I need to know if what I am seeking to do with this phone is possible. Otherwise, I will have to obtain an Android 7.0 or 8.0 phone with which I can successfully gain these permissions or outright root to accomplish same.
So far, all I have been able to do is access Developer Options. From there, I cannot even determine if this device has an unlocked bootloader as there is no "OEM Unlock" option or anything remotely similar under that menu option.
Please assist me with suggestions on how best to proceed. Thank you.
Click to expand...
Click to collapse
I assume you are looking for a way to root, so I'd like to share some things with you. I have looked at this phone too, and found it has some very odd booting. There is no fastboot. Instead you have to make due with Download Mode. Power + Home + Volume up (or down) on boot will bring you to download mode. If it brings you to recovery, try the other volume button. Choosing download mode from recovery is only for recovering the current installation. (I think) Once in download mode, you will see some info in the top left corner. In order to unlock the flashing of ROMS (This is required for rooting with Magisk) you need to disable FRP. AKA, sign out of your google account on your phone. You should thus be able to install custom ROMs. In order for Magisk to work, you need a copy of your current firmware. I found some sights with downloads, but they were either untrustworthy, paid for, or the ROM was nonexistent. After searching online, I found another, official, and free way that you can get the official firmware for Samsung devices through Samsung's Smart Switch application. The only problem is that the program will only download the ROM if you have an available update on your sm-j337a. I'm up to date with the first android pie update on my sm-j337a. If you've held off patching, I would:
Install smart switch both mobile and PC.
Set preferences to preload ROMs in PC version (download first, then choose install)
Copy the ROM from user 》 documents》 Samsung
If this works, please share the ROM. My phone is too updated to test it.
You can then use the Magisk guide for rooting.

General (OPEN DEV) BruteRoot - A collection of Root Tactics (Possibly Force Bootloader unlock on NA Samsung S22?)

Devices & Linux Versions I or other Testers have Successfully Gained Root on:
(Likely All) MTK CPU Based Android devices UP TO 11 (Maybe 12? I haven't tested) (I.e LG, Sony, Select Samsung devices)
Android Devices with LINUX KERNEL VERSIONS - 5.8 - 4.14 - Maybe More? (Needs Testing)
-THIS GUIDE IS NOT BEGINNER FRIENDLY - BASIC UNDERSTANDING OF PYTHON, UNIX/LINUX ETC WILL BE REQUIRED!-​
If you have been holding off updating your device, well here's some good news, your device may still be vulnerable to a method to gain root access (and subsequently, possibly the ability to edit Build.prop and therefore allow the ability for OEM unlocking on USA based devices.) <- correct me if I'm wrong, but this should be possible, and once done, should persist across updates, correct?
As of the time of writing this, there is not currently a simplified APK method, but, still this process is relatively straight forward.
Alot of the methods used HAVE been patched from what I understand, but there have got to be plenty of devices out there still which are not updated. This project aims to compile all current, former and future Root methods into an APK that will do all the leg-work. If its able to find a working method, the GUI will pop a root shell for the end user. This SHOULD work, regardless of the setting of the "OEM UNLOCK" option in the dev options. A bypass, essentially.
Regardless, The project linked below uses a myriad of known exploits & vulnerabilities and looks to find one that will work.
Methods used are:
Nearly all of GTFOBins
Writeable docker.sock
CVE-2022-0847 (Dirty pipe)
CVE-2021-4034 (pwnkit)
CVE-2021-3560
It'll exploit most sudo privileges listed in GTFOBins to pop a root shell, as well as exploiting issues like a writable docker.sock, or the recent dirty pipe (CVE-2022-0847). More methods to root will be added over time too.
There is also an alternative (Dirty Pipe) injection method the uses @topjohnwu 's Magisk , this should be implemented into the apk. See this Github repo, Here.
I would imagine this could be implented in a way to target devices that have stopped being supported for updates, aswell, that do not have TWRP, such as the SM-T307U.
One big note - I am betting there are still ALOT of devices that are in inventory at retailers that remain on the vulnerable OS. So keeping that in mind, I'd say this is worth building.
What needs to be done:
TESTING!
Build APK - HELP NEEDED WITH THIS!
Deploy
Main Goals:
Get bootloader unlock ability for devices normally not unlockable (I.e North American Samsung Galaxy S22, Etc)
Above can be achieved by getting temp root via methods detailed here or otherwise, then editing build.prop, altering the below settings (The settings may be worded differently or simply not present at all, depending on device and Firmware version):
sys.oem_unlocking_allowed to 1
ro.oem_unlock_supported to 1 (most devices are set to 1 by default.)
ro.boot.flash.locked to 0
ro.secure to 0
ro.debuggable to 1
I think there may be one or two more that pretaint to Flash.locked. I.e flash.locked.other--or something very close.
Locally, gain temp root (System preferred, but any root will do.) on as many device types as possible.
Give device control back to end user.
Stay up-to-date on new exploits for root access & update apk accordingly.
STAY ETHICAL!!!! This is, in the end, a research project. Meaning all work preformed in the context of this project could result in a damaged or bricked device. By participating in this project you acknoledge these risks and accept them, and agree to not hold me, XDA, or anyone else responsible if you do some dumb ****. - k0mraid3
Github Project link: HERE for my fork & HERE for the original project.
My fork will incorporate the original project, as well as other found root access methods, such as the magisk injection method mentioned above - my repo is mainly used as a hub for the APK's dev - i don't have enough time to work on it at the moment but all are welcome to help.
July 15th 2022 (UPDATE) (SAMSUNG DEVICES ONLY): A new Escalation method has been found via the Galaxy app store (Versions BEFORE Galaxy Store 4.5.41.8). No details known yet, but it is said to be very easy. See CVE-2022-33708 (July132022). Unknown if downgrading the app to 4.5.0.0 will enable the method again or not.
Cred: liamg
One method to run Traitor on device - Thanks @DevinDking for sharing this.
Steps to get script on phone.
//
#!/bin/sh
set -e
dir=/data/local/tmp
adb=${adb:-"adb"}
$adb push traitor ${dir} //This puts file on phone make sure to run the terminal where its located
$adb shell chmod 755 ${dir}/traitor"
//
Now to run script start a new terminal
//
adb shell
#!/bin/sh
set -e
dir=/data/local/tmp
adb=${adb:-"adb"}
${dir}/traitor //script opens
//
But I assume this wouldn't work right, and isn't right.
Idk trying my best here xD
Click to expand...
Click to collapse
Tools & References:
Linux (and Android, FTMP) Privilege Escalation Techniques
Dirty Pipe - Magisk Injection
Traitor - Main Repo
GTFOBins
CVE Database (Public Database for exploits, vulnerabilities, etc.)
Windows Subsystem For Linux (Great for Dev)
ADB App Control - Cred @Cyber.Cat
Leaked Samsung Source Code ***Mod Edit: Link Removed***
Crontab Root Template script (File Attached - you still must edit crontab with "crontab -e" and point it to this file, see comments for guide, I will add one to post later)
Android Image Kitchen Used to create custom image's etc.
MTK Client
MTK Meta Utility (Source-???)
Will add more as time goes on and more found.
Interesting Attack vectors -
GFX Componets of a system.
Issues with Linux itself (i.e Dirty Pipe)
Privilage escalation via any means (I.e GTFOBins)
unprotected system process - Hijack them if possible (i.e RILService Mode, and a wide range of other OEM apps left on devices after ship)
7/24/22 - Samsung, LG & Other OEM's obfuscating (Intentionally Hiding) Fastboot and ADB Bootloader interfaces on PC
So over the last week or so i dived head first into USB Dev - ill save you the time and sum it up.
Vendors and OEM's are actively obfuscating the USB connection between your smartphone and the PC to keep you from Rooting. As far as im aware, there is no Universal way to fix this as each OEM screws with the USB drivers differently. THIS needs to be a point of focus for the rooting community. However, i have found a few tools for Dev if you wish to screw with this. (I'll upload them tonight)
7/24/22 - MTK (MediaTek) based Exploits
I Will try to compile a few methods for FORCING Bootloader Unlock on MTK based Devices as well as a way for manipulating said devices. I will attach two tools to this thread, these tools are EXTREMELY POWERFUL and can completely **** up your device. When i say REALLY F*CK UP your device, I mean to the point you cant even access recovery, Download OR bootloader mode. I'm Talking a blank DEAD device. So use with caution.
With that said, lets talk about the tools. You will need a basic understanding of Python to make use of MTK Client
First up, we have MTK Meta Utility (Currently Version 44) (Download Below)
Next we have MTK Client (Github Link)
So what can you do? Well, you can crash the Preloader to Brom with MTK Meta Utility while at the same time using MTK Client to send any payload you like to the device via Fastboot.
I know, vague right now, but ill add detail over the coming days.
I will continue to update the below list as new methods are discovered.
If you find Guides, tutorials or new exploits, please link them in the comments so I can include them in future development!
Telegram Channel: Here.
Information on Vulnerabilities, exploits & methods - CVE-2022-0847 (Jfrog) - The Story Of "Dirty Pipe" - XDA - Dirty Pipe - PWNKIT (CVE--2021-4034) - CVE-2021-3560 - Docker Breakout / Privilege Escalation - CVE-2022-33708 (July132022) - CVE-2022-33701 (July122022) - CVE-2022-22268 (Unlock Knox Guard with DEX) (JAN2022) - MTK Client -
Dev Team & credit to -
@topjohnwu - LiamG - @wr3cckl3ss1 - bkerler -
UPDATED - 7/29/22
There is also a new vulnerability exploit by Zhenpeng Lin that allows for privilege escalation on Pixel 6 and and Galaxy S22 devices running 5.10 kernel.
Don't update... destroyer of worlds
I feel like I'm missing something because wouldn't their normally be a million responses of hype, hope and nay-saying going on here? Has this been shot down already?
olivehue512 said:
I feel like I'm missing something because wouldn't their normally be a million responses of hype, hope and nay-saying going on here? Has this been shot down already?
Click to expand...
Click to collapse
Lol, everybody already updated the patch
blackhawk said:
Lol, everybody already updated the patch
Click to expand...
Click to collapse
This is just sad panda. I'm gonna skip next update anyways unless it comes with an actual other phone that is BL unlocked. I feel like everyone wants this so bad it can't be that far out before it happens.
Does the Magisk injection method work after July patch? I was reading through the work they did to get it done. Props to those guys.
sierratango88 said:
There is also a new vulnerability exploit by Zhenpeng Lin that allows for privilege escalation on Pixel 6 and and Galaxy S22 devices running 5.10 kernel.
Click to expand...
Click to collapse
Has it got a fancy number yet?! Eager to try this!!!! Maybe it can be put in with the others.
olivehue512 said:
I feel like I'm missing something because wouldn't their normally be a million responses of hype, hope and nay-saying going on here? Has this been shot down already?
Click to expand...
Click to collapse
Well, because they are known and accepted vulnerabilities and exploits. A very few have even been marked as "WONTFIX" such as the TTY method.
olivehue512 said:
This is just sad panda. I'm gonna skip next update anyways unless it comes with an actual other phone that is BL unlocked. I feel like everyone wants this so bad it can't be that far out before it happens.
Does the Magisk injection method work after July patch? I was reading through the work they did to get it done. Props to those guys.
Click to expand...
Click to collapse
Honestly, it's worth a shot but I doubt it.
One of the goals behind building the APK compilation of all these different tactics is to enable the end user to "give it a shot" easily on different devices, without having to know how to run all of this manually. Basically imagine an apk that just tries all the above methods and if ones successful the gui will pop a root shell open. From there, the possibilities are endless. Edit Build.prop, SELinux, Verity, Etc.
FYI even you applied the July update, seems like the Kernel version is still from June 21st, is still 5.10xxxx so we could still benefit from this exploit. Very interested in how we can get root here in the US.
K0mraid3 said:
Has it got a fancy number yet?! Eager to try this!!!! Maybe it can be put in with the others.
Click to expand...
Click to collapse
There hasn't been a CVE assigned to it yet that I am aware of.
xgerryx said:
FYI even you applied the July update, seems like the Kernel version is still from June 21st, is still 5.10xxxx so we could still benefit from this exploit. Very interested in how we can get root here in the US.
Click to expand...
Click to collapse
Go to the Github linked and try the different methods, see if you can pop a root and nano build.prop to allow OEM unlocking?
sierratango88 said:
There hasn't been a CVE assigned to it yet that I am aware of.
Click to expand...
Click to collapse
GREAT news for us! LEts get this temp root! lol
Looks like another new one! CVE-2022-33708
Another Samsung Exclusive - CVE-2022-33701
So, ive just spent my entire friday and friday night MANUALLY testing all the GTFOBins & reproducing some of the newer CVE's on Samsung Galaxy S7 Edge (Android 9) -Galaxy tab A 8.4, (Android 11), Galaxy S21 & S22 (Android 12) --- A little bit of progress made. Again, ill need someone with better working knowledge on APKs & Java to really move forward. All i can say so far, is this all must be awk for sammie, because cronie is looking promising
"crontab -e"
interesting find. not "New" but still new-ish enough some may be able to use. CVE-2022-22268 (Unlock Knox Guard with DEX)
New to this all but not rooting. Anyone recommend a way tutorial on how to try these methods on Win 11?
I don't have a deep understanding of Linux, I have tried, debian and unbuntu. I get traitor to run but it's detecting the Linux kernel and not my phones. How can I get the program to search for vulnerability on my phone not my Linux. I would love a more in depth guide and I'd love to give feedback on methods.
DevinDking said:
I don't have a deep understanding of Linux, I have tried, debian and unbuntu. I get traitor to run but it's detecting the Linux kernel and not my phones. How can I get the program to search for vulnerability on my phone not my Linux. I would love a more in depth guide and I'd love to give feedback on methods.
Click to expand...
Click to collapse
i had the same issue but cant remember how i worked that out. let me see if i can find out what i did on win11

Categories

Resources