Database Info

New Root Security Model?

I saw in the SDK this permission for apps to request:
public static final String FACTORY_TEST
Run as a manufacturer test application, running as the root user. Only available when the device is running in manufacturer test mode.
Constant Value: "android.permission.FACTORY_TEST"
Click to expand...
Click to collapse
Our current model with superuser whitelist is not very secure because a malicious person could bundle their own su binary and circumvent the restrictions. It would seem that having our custom roms run in test mode would provide a great solution: using Android's own permission/security model for apps to run as root. This should force all apps to visibly request root permissions at install time.

I am in favor of anything that will improve the security of my phone. It concerns me that anyone who knows what they are doing can so easily boot into recovery mode on my phone, wipe and flash any ROM they want. Granted, they would not have access to my information if the wipe and flash. But, it makes it trivially simple to hijack my phone. I would like to have some password protection for Recovery and Fastboot.

i am by no means a dev, but it seems to me that this probably just has to do with the adp devices

what's a adp device? and explain how they could possibly do this again?

android developer phone.

jaaronmoody said:
i am by no means a dev, but it seems to me that this probably just has to do with the adp devices
Click to expand...
Click to collapse
well, technically, if we have root, dont have an "ADP" device?
when I do a fresh install, it says welcome to Android Developer Phone 1 (in most ROMs)

the adp device was a specific phone release for developers to be used with the sdk.

jaaronmoody said:
the adp device was a specific phone release for developers to be used with the sdk.
Click to expand...
Click to collapse
I know that, but the hardware is the same as ours (they just get the awesome battery cover)

jaaronmoody said:
the adp device was a specific phone release for developers to be used with the sdk.
Click to expand...
Click to collapse
Most roms especially cyanogen Roms are based on SDK/ADP1 directly and thus making our devices recognizable as ADP Devices.

Simple solution could be to restore the original su binary at boot.
1) keep a copy in the boot image ramdisk
2) scan the path at boot for su
3) compare md5sum with the original
4) delete if md5sum is different
5) restore original trusted su
and also just for paranoia:
6) scan system for setuid binaries and report to the user

This has NOTHING to do with ADP1. Test mode is just that... TEST MODE, i.e. diagnostics and repair. Probably needs to be plugged into a test station that authenticates using some manufacturer diagnostic keys. I really doubt that it would be a simple matter of requesting root permissions as this would be too easy to abuse.
And to the OP: No, you can't just bundle an 'su' binary and run it. The binary has to be owned and setuid as root in order for it to actually get root permissions. There is nothing magical about the su binary -- it is just 'sh' renamed as 'su', chown'd as root, and chmod 4755. A regular user can NOT chown root. Only root can chown root. Note that the su binary that works with the root app is modified such that it will terminate if the root app doesn't grant root permission. For all these reasons, su+rootapp is fairly secure. Not against someone unauthorized getting their hands on the device, but against some malevolent app taking root and running amok.

lbcoder said:
This has NOTHING to do with ADP1. Test mode is just that... TEST MODE, i.e. diagnostics and repair. Probably needs to be plugged into a test station that authenticates using some manufacturer diagnostic keys. I really doubt that it would be a simple matter of requesting root permissions as this would be too easy to abuse.
And to the OP: No, you can't just bundle an 'su' binary and run it. The binary has to be owned and setuid as root in order for it to actually get root permissions. There is nothing magical about the su binary -- it is just 'sh' renamed as 'su', chown'd as root, and chmod 4755. A regular user can NOT chown root. Only root can chown root. Note that the su binary that works with the root app is modified such that it will terminate if the root app doesn't grant root permission. For all these reasons, su+rootapp is fairly secure. Not against someone unauthorized getting their hands on the device, but against some malevolent app taking root and running amok.
Click to expand...
Click to collapse
Thanks for clearing that up.
The idea posted earlier about recovery menu password should be lofted at Cyanogen (or anyone willing to take that on). Should we make a thread for it?

Keep in mind that it is physically impossible to secure your phone against somebody who gets their hands on the actual device. You can only make it harder to get at it. If somebody wanted to they could just read the flash chip directly or use JTAG to get at it. However, I agree that adb could be made a bit more secure.

And to the OP: No, you can't just bundle an 'su' binary and run it. The binary has to be owned and setuid as root in order for it to actually get root permissions. There is nothing magical about the su binary -- it is just 'sh' renamed as 'su', chown'd as root, and chmod 4755. A regular user can NOT chown root. Only root can chown root. Note that the su binary that works with the root app is modified such that it will terminate if the root app doesn't grant root permission. For all these reasons, su+rootapp is fairly secure. Not against someone unauthorized getting their hands on the device, but against some malevolent app taking root and running amok.
Click to expand...
Click to collapse
@lbcoder,
That's nonsense. Check any linux system, /bin/sh is always owned by root and is always executable. Running an executable owned by user X does NOT run said program as X. Copying a binary onto the phone preserves permissions, so if i chowned an sh binary as root on my computer and copied it over, the binary will stay owned by root. The su binary is just that, a binary. It is not simply a shell owned by root.

nobodyimportant said:
@lbcoder,
That's nonsense. Check any linux system, /bin/sh is always owned by root and is always executable. Running an executable owned by user X does NOT run said program as X. Copying a binary onto the phone preserves permissions, so if i chowned an sh binary as root on my computer and copied it over, the binary will stay owned by root. The su binary is just that, a binary. It is not simply a shell owned by root.
Click to expand...
Click to collapse
you're missing the bit (pun intended) about su being setuid root. when a normal user runs su, it does, indeed run as root, but it uses the security subsystem behind the scenes to prevent unauthorized activity:
http://en.wikipedia.org/wiki/Setuid
the 'unzip' executable will, indeed, preserve ownership, but to my knowledge, there's no way to copy a setuid binary to the phone as a normal user -- there may be a way it could be pulled off, but I don't know how

nobodyimportant said:
@lbcoder,
That's nonsense. Check any linux system, /bin/sh is always owned by root and is always executable. Running an executable owned by user X does NOT run said program as X. Copying a binary onto the phone preserves permissions, so if i chowned an sh binary as root on my computer and copied it over, the binary will stay owned by root. The su binary is just that, a binary. It is not simply a shell owned by root.
Click to expand...
Click to collapse
I have one thing to say to you:
http://en.wikipedia.org/wiki/Setuid
Now that you've made a complete and utter fool of yourself, how do you feel?
FYI: your regular user can NOT chown root. Go ahead and try it.

alapapa said:
you're missing the bit (pun intended) about su being setuid root. when a normal user runs su, it does, indeed run as root, but it uses the security subsystem behind the scenes to prevent unauthorized activity:
http://en.wikipedia.org/wiki/Setuid
the 'unzip' executable will, indeed, preserve ownership, but to my knowledge, there's no way to copy a setuid binary to the phone as a normal user -- there may be a way it could be pulled off, but I don't know how
Click to expand...
Click to collapse
It is a moot point whether the setuid bit can be restored since a regular user doesn't have the ability to change the owner to anything but self, which means that the best they could do is create an su binary that will give other users THEIR OWN permissions.
A regular user can change ownership *only* to self -- i.e. if they have group or other write permission, then they can chown the file. They can also change the group, but only to groups to which they are members -- and this requires that they already have some form of write permission on the file.
Note that extracting a file is no different than actually *creating* the file, which means that if the user couldn't simply MAKE the file, then they can't *extract* the file either.
If any of this was untrue, there would be nothing to stop any user from doing something like this to take over any Linux computer (except from within a chroot jail, but that doesn't apply here);
cp `which sh` ~/su; chown root:root ~/su; chmod 4755 ~/su
** but that most definitely won't work.

Root any device just using ADB Shell.

In this post, I'm not telling any tricks or methods. I am just providing my thoughts and possibilities. Recently I was trying to root my phone and I did a little bit of research on it. By the way, note one thing here that my phone is part of the Android One project and made by Xiaomi, so it's much harder to root than any other phone. If you have also tried to root your phone, then you might have also heard these words... (Magisk manager, Superuser, Busybox, SU Binary, TWRP Custom recovery, root file, System file, Custom Rom), etc. In this thread, if I am right you can root your phone just by using ADB Shell. Rooting your phone means...
Rooting (Android)
From Wikipedia, the free encyclopedia
Rooting is the process of allowing users of smartphones, tablets, and other devices running the Android mobile operating system to attain privileged control (known as root access) over various Android subsystems. As Android uses the Linux kernel, rooting an Android device gives similar access to administrative (superuser) permissions as on Linux or any other Unix-like operating system such as FreeBSD or macOS.
Rooting is often performed with the goal of overcoming limitations that carriers and hardware manufacturers put on some devices. Thus, rooting gives the ability (or permission) to alter or replace system applications and settings, run specialized applications ("apps") that require administrator-level permissions, or perform other operations that are otherwise inaccessible to a normal Android user. On Android, rooting can also facilitate the complete removal and replacement of the device's operating system, usually with a more recent release of its current operating system.
Root access is sometimes compared to jailbreaking devices running the Apple iOS operating system. However, these are different concepts: Jailbreaking is the bypass of several types of Apple prohibitions for the end-user, including modifying the operating system (enforced by a "locked bootloader"), installing non-officially approved (not available on the App Store) applications via sideloading, and granting the user elevated administration-level privileges (rooting). Many vendors such as HTC, Sony, LG, Asus, and Google explicitly provide the ability to unlock devices and even replace the operating system entirely. Similarly, the ability to sideload applications is typically permissible on Android devices without root permissions. Thus, it is primarily the third aspect of iOS jailbreaking (giving users administrative privileges) that most directly correlates to Android rooting.
Rooting is distinct from SIM unlocking and bootloader unlocking. The former allows removing the SIM lock on a phone, while the latter allows rewriting the phone's boot partition (for example, to install or replace the operating system).
Source: Wikipedia
So, as much as I've noticed (I could be wrong) mainly all rooting processes does one of those two things,
1. Edits your boot.img
or
2. Adds a SU binary file to your system & more specifically to your system/bin file.
So if that's true and every Android phone or at least the same brands or same models or at least same Android versions or maybe all of them requires the exact same SU binary file(Superuser binary file). Now, if you don't want to change your boot.img there is only one is remaining and that is adding the SU binary file. Now you might ask how to do that...
Just use your ADB shell to give writing system files permission to your file manager. And then put the SU file to your system.
So, that's all I was just trying to say. Now if I am right please let me know and thanks for reading until now. And also if I am right, please someone provide me the SU binary file of Xiaomi MI A3, code name: laurel_sprout . Thank you once again, All developers, take care of your health. For further inquiries and helping me out, message me on XDA personally.
Writer: Samiullah Ridoy.

Samiullah Ridoy said:
...
Just use your ADB shell to give writing system files permission to your file manager. And then put the SU file to your system.
...
Click to expand...
Click to collapse
Absolutely errleading ( i.e. wrong ) statement:
1. To mount Android's partition /system as RW - so you can copy SU-binary onto it - you need superuser ( SU ) rights.
2. Modern Android versions have SELinux enabled, and most also DM-verity and/or AVB. These safety-features lock the /system partition to get tampered, what at least with regards to SELinux and/or DM-verity only can be disabled by superuser ( SU ).
3. With regards to AVB one has to unlock device's bootloader, too, in order to disable this lock.

@Samiullah Ridoy
As above post said,
-You can't simply give writing system files permission.
-Only emulators have that ability(since they are not production builds)
Here is your device specific guide at Mi A3 forum https://forum.xda-developers.com/t/...-root-mi-a3-with-magisk-without-twrp.3958509/
Rooting your device is same as any other device if we use Magisk rooting method. It does not take additional steps to root your specific device.
Thanks

You need to disable DM-verity.
You can do it from ADB. You need to modify Stock boot image file. Patch it and disable DM-Verity.

HemanthJabalpuri said:
@Samiullah Ridoy
As above post said,
-You can't simply give writing system files permission.
-Only emulators have that ability(since they are not production builds)
Here is your device specific guide at Mi A3 forum https://forum.xda-developers.com/t/...-root-mi-a3-with-magisk-without-twrp.3958509/
Rooting your device is same as any other device if we use Magisk rooting method. It does not take additional steps to root your specific device.
Thanks
Click to expand...
Click to collapse
I have already seen that post & I don't want to do it that way. You said, " You can't simply give writing system files permission. ", I've already mentioned but saying it once again that I could be wrong but we can give writing system files permission by using these code...
Code:
adb shell pm grant [package name] android.permission.WRITE_SETTINGS
adb shell pm grant [package name] android.permission.ACCESS_MEDIA_LOCATION
adb shell pm grant [package name] android.permission.WRITE_INTERNAL_STORAGE
Tell me if I am wrong & thanks for your compliment.

Samiullah Ridoy said:
I have already seen that post & I don't want to do it that way. You said, " You can't simply give writing system files permission. ", I've already mentioned but saying it once again that I could be wrong but we can give writing system files permission by using these code...
Code:
adb shell pm grant [package name] android.permission.WRITE_SETTINGS
adb shell pm grant [package name] android.permission.ACCESS_MEDIA_LOCATION
adb shell pm grant [package name] android.permission.WRITE_INTERNAL_STORAGE
Tell me if I am wrong & thanks for your compliment.
Click to expand...
Click to collapse
I didn't tried those but I am sure those are NOT for writing read-only partitions.
Those are for accessing internal storage and changing settings like brightness I think.

jwoegerbauer said:
Absolutely errleading ( i.e. wrong ) statement:
1. To mount Android's partition /system as RW - so you can copy SU-binary onto it - you need superuser ( SU ) rights.
2. Modern Android versions have SELinux enabled, and most also DM-verity and/or AVB. These safety-features lock the /system partition to get tampered, what at least with regards to SELinux and/or DM-verity only can be disabled by superuser ( SU ).
3. With regards to AVB one has to unlock device's bootloader, too, in order to disable this lock.
Click to expand...
Click to collapse
Absolutely correct.
It seems to me OP has never tried this, simply has copied from other sources. That is why the nonsense.

Questions about rooting without unlocking bootloader?

Phone is Samsung A50 (A505F), Android 11,
1) As title.. how do you do that? I will keep stock ROM.
Only want to root to debloat, and add other apps that require root.
2) Also if you use kingroot, does it unlock the bootloader?
3) If you relock a bootloader does it remove root?
Will relocking erase user data?
Thank you

Generally speaking - with regards to this thread's title:
Rooting phone's Android works without unlocking it's bootloader. Rooting Android simply is adding an user called "superuser ( AKA root )" to Android.
Reason why people unlock bootloader is to be able to flash custom ROMS.

rossrosh007 said:
1) As title.. how do you do that?
2) Also if you use kingroot, does it unlock the bootloader?
Is the kingroot app required to be installed at all times to keep root?
3) If you relock a bootloader does it remove root?
Will relocking erase user data?
Phone is Samsung A50 (A505F)
Thank you
Click to expand...
Click to collapse
Rooting without unlocking bootloader only works on
4.2 jellybean
4.4 KitKat
5.0 lollipop
5.1.1. lollipop
All of the other version of android will not work because in android 6 marshmallow google patched root without unlocking bootloader so this means if u are on Android 6 marshmallow it will not work also if u are on Android 6 marshmallow and higher don't brother with kingroot or all of that one click root because that will not work I would recommend magisk to root your phone

@rossrosh007
Hint: Add Samsung A50 (A505F) to this thread's title thus mainly owners of such a device get addressed.

Austinredstoner said:
Rooting without unlocking bootloader only works on
4.2 jellybean
4.4 KitKat
5.0 lollipop
5.1.1. lollipop
All of the other version of android will not work because in android 6 marshmallow google patched root without unlocking bootloader so this means if u are on Android 6 marshmallow it will not work also if u are on Android 6 marshmallow and higher don't brother with kingroot or all of that one click root because that will not work I would recommend magisk to root your phone
Click to expand...
Click to collapse
I'm on Android 11.
Ok, so I have to patch boot.img with magisk or magisk manager (I don't know the difference)? On GitHub the latest version is just magisk v22.
So to use magisk unlocking bootloader is required... I'll be keeping stock ROM. So will I be able to relock bootloader after patching and rooting?

jwoegerbauer said:
Generally speaking - with regards to this thread's title:
Rooting phone's Android works without unlocking it's bootloader. Rooting Android simply is adding an user called "superuser ( AKA root )" to Android.
Reason why people unlock bootloader is to be able to flash custom ROMS.
Click to expand...
Click to collapse
I'm on Android 11, and I'll keep stock Rom.
How can I flash SuperSU without custom recovery or unlocking bootloader?
If I have to unlock bootloader, can I relock it after flashing SuperSU?

rossrosh007 said:
I'm on Android 11, and I'll keep stock Rom.
How can I flash SuperSU without custom recovery or unlocking bootloader?
If I have to unlock bootloader, can I relock it after flashing SuperSU?
Click to expand...
Click to collapse
Don't confuse SuperSU ( what is an application which lets you manage root permissions for apps which require root access) and SU ( AKA superuser and/or root ): Totally different things.
SuperSU app relies on presence of SU applet.
Installing SU applet doesn't require phone's bootloader gets unlocked, but it's required Android's DM-VERITY feature permanently gets disabled before, this because content of /system partition gets altered.
Look also inside here:
SuperSU: Installation Guide (Rooted and Unrooted Devices)
There are two ways to install SuperSU. If you have a Rooted Device then you can simply download this APK file and install it on your device. For unrooted de
www.squto.com

jwoegerbauer said:
Don't confuse SuperSU ( what is an application which lets you manage root permissions for apps which require root access) and SU ( AKA superuser and/or root ): Totally different things.
SuperSU app relies on presence of SU applet.
Installing SU applet doesn't require phone's bootloader gets unlocked, but it's required Android's DM-VERITY feature permanently gets disabled before, this because content of /system partition gets altered.
Look also inside here:
SuperSU: Installation Guide (Rooted and Unrooted Devices)
There are two ways to install SuperSU. If you have a Rooted Device then you can simply download this APK file and install it on your device. For unrooted de
www.squto.com
Click to expand...
Click to collapse
Ok. SuperSU app is the permission manager.
How do I go about implementing superuser without unlocking bootloader on Android 11?
Unlocking BL is required when using magisk. I'll be keeping stock ROM, so will I be able to relock BL after patching boot.img with magisk? Will root/superuser stay if I relock BL?
Some threads say the magisk patched boot.img is considered tampered and the DM-verity will cause issues when relocking BL. Unless you sign it... Is that true? (Different users saying true and false, so I don't know what is what)

1. You install matching SU applet by means of ADB. The SU applet can get fetched from here
LineageOS Downloads
download.lineageos.org
2. Can't tell you what is right or wrong: never made use of Magisk or TWRP.

jwoegerbauer said:
1. You install matching SU applet by means of ADB. The SU applet can get fetched from here
LineageOS Downloads
download.lineageos.org
2. Can't tell you what is right or wrong: never made use of Magisk or TWRP.
Click to expand...
Click to collapse
Fair enough on point 2
The SU from LineageOS not a problem to use on Samsung stock Rom? I mean that SU applet not developed to be compatible with LineageOS only or something?
Any instruction on how to apply this SU applet will be useful. (I'm searching through the forum as well)

Only to clarify things:
SU is a Linux command, Android is based on Linux kernel, hence SU applet compiled for mobile's CPU architecture always works, regardless of mobile's brand / model / Android release.
As I already mentioned here, you can install SU by means of a ADB command-sequence which typically looks like this
Code:
adb disable-verity
adb reboot
adb shell "mount -t auto -o rw,remount /system"
adb push <SU-BINARY-LOCATION-ON-PC-HERE> /system/bin
adb shell "chown root:root /system/bin/su"
adb shell "chmod 06755 /system/bin/su"
adb shell "chcon '/system/bin/su' u:object_r:su_exec:s0"

jwoegerbauer said:
Only to clarify things:
SU is a Linux command, Android is based on Linux kernel, hence SU applet compiled for mobile's CPU architecture always works, regardless of mobile's brand / model / Android release.
As I already mentioned here, you can install SU by means of a ADB command-sequence which typically looks like this
Code:
adb disable-verity
adb reboot
adb shell "mount -t auto -o rw,remount /system"
adb push <SU-BINARY-LOCATION-ON-PC-HERE> /system/bin
adb shell "chown root:root /system/bin/su"
adb shell "chmod 06755 /system/bin/su"
adb shell "chcon '/system/bin/su' u:object_r:su_exec:s0"
Click to expand...
Click to collapse
True, it's all Linux based, but thought the directories might be different manufacturer to manufacturer. With the verify functions and all... Didn't want to modify a wrong directory and get bricked.
Nice, thanks for the help and ADB commands. Also just came across LADB (on-phone ADB shell), will give it a go on that.
Will update back.

Austinredstoner said:
Rooting without unlocking bootloader only works on
4.2 jellybean
4.4 KitKat
5.0 lollipop
5.1.1. lollipop
All of the other version of android will not work because in android 6 marshmallow google patched root without unlocking bootloader so this means if u are on Android 6 marshmallow it will not work also if u are on Android 6 marshmallow and higher don't brother with kingroot or all of that one click root because that will not work I would recommend magisk to root your phone
Click to expand...
Click to collapse
rossrosh007 said:
I'm on Android 11.
Ok, so I have to patch boot.img with magisk or magisk manager (I don't know the difference)? On GitHub the latest version is just magisk v22.
So to use magisk unlocking bootloader is required... I'll be keeping stock ROM. So will I be able to relock bootloader after patching and rooting?
Click to expand...
Click to collapse
Hope you can give me some insight on this. Would be good to learn.

jwoegerbauer said:
Only to clarify things:
SU is a Linux command, Android is based on Linux kernel, hence SU applet compiled for mobile's CPU architecture always works, regardless of mobile's brand / model / Android release.
As I already mentioned here, you can install SU by means of a ADB command-sequence which typically looks like this
Code:
adb disable-verity
adb reboot
adb shell "mount -t auto -o rw,remount /system"
adb push <SU-BINARY-LOCATION-ON-PC-HERE> /system/bin
adb shell "chown root:root /system/bin/su"
adb shell "chmod 06755 /system/bin/su"
adb shell "chcon '/system/bin/su' u:object_r:su_exec:s0"
Click to expand...
Click to collapse
Can I install supersu.apk (root access manager) after this?
If I need to revert things back to how they were (unroot, enable dm-verity) ... How do I do that?

rossrosh007 said:
Can I install supersu.apk (root access manager) after this?
Click to expand...
Click to collapse
SuperSU APK is just like any other Android application. It only will properly work if SU is runing as Android service, means gets started at Android's boot up
Code:
# su daemon
service su_daemon /system/bin/su --daemon
seclabel u:r:sudaemon:s0
oneshot
on property:persist.sys.root_access=1
start su_daemon
what requires Android's boot file init.rc must got patched accordingly.

frequently conversing - with thoughts to this thread's headline:
I am rooting the phone's Android products externally, unfastening its bootloader. Rooting Android only is combining a user-designated "superuser ( AKA motive )" toward Android.
Special purpose how? Somebody unlock bootloaders is to be capable of flashing system ROMS.

jwoegerbauer said:
Only to clarify things:
SU is a Linux command, Android is based on Linux kernel, hence SU applet compiled for mobile's CPU architecture always works, regardless of mobile's brand / model / Android release.
As I already mentioned here, you can install SU by means of a ADB command-sequence which typically looks like this
Code:
adb disable-verity
adb reboot
adb shell "mount -t auto -o rw,remount /system"
adb push <SU-BINARY-LOCATION-ON-PC-HERE> /system/bin
adb shell "chown root:root /system/bin/su"
adb shell "chmod 06755 /system/bin/su"
adb shell "chcon '/system/bin/su' u:object_r:su_exec:s0"
Click to expand...
Click to collapse
I've just found this thread and wanted to understand something. Does adb disable-verity work without unlocking bootloader?
Do you mean that if you install su on the system via adb on the above sequence then the system is essentially rooted no matter whether you unlock the bootloader or not?
Earlier it was mentioned that you need to run a service in order for the superuser apps to work and this requires the boot.img to be modified and this needs the bootloader to be unlocked. Will superuser apps like superuser apk work just with su on the system?
I mean can I just soft start the daemon with a terminal app without adding it as a startup service?

Again: Rooting Android is adding an user named SUPERUSER to Android OS - not to get confused with Android's default user named root - an user who has elevated rights ( comparable to Administrator in Windows OS ).
The SuperSU app what you're referring to is a manager app that runs a database where apps which request superuser right are stored.
The SuperSu service ( read: sudaemond ) is a complete other thing, it serves another purpose: it's needed to have SuperSU app working.

It's not possible to add any binary or user or rooting app without unlocking your bootloader. All partitions except /data are not writable.

More nonsense is hardly possible.

I want a complete guide on how to install android 10 on TB-X304L. OEM unlocking is greyed out and it shows an error if I try a method given by @hk96

The problem I have is that the 'enable OEM unlocking' option is greyed out on my tablet. I've tried this method but I keep getting this error. I didn't find anything helpful on the internet. Please help me if you can.

Look inside system file build.prop for entry
Code:
ro.oem_unlock_supported
If it's value is 0 then unlocking bootloader isnt supported.
If Android is rooted then you can try to change this entry to
Code:
ro.oem_unlock_supported=1
More info here:
Locking/Unlocking the Bootloader | Android Open Source Project
source.android.com

jwoegerbauer said:
Look inside system file build.prop for entry
Code:
ro.oem_unlock_supported
If it's value is 0 then unlocking bootloader isnt supported.
If Android is rooted then you can try to change this entry to
Code:
ro.oem_unlock_supported=1
More info here:
Locking/Unlocking the Bootloader | Android Open Source Project
source.android.com
Click to expand...
Click to collapse
Well I am unable to root with those 1 click rooting apps. Is there any other way to root it? The PC way is not gonna work because it needs twrp and twrp requires me to unlock OEM

To root a device's Android TWRP isn't needed at all: Rooting is the act of unlocking the Android OS to gain complete control over the device through which you can access hidden files, change the ROM or install certain special apps. Rooting Android OS simply means to add Superuser functionality to it.
Here is what you have to do to root your device's Android: Replace Android's Toybox binary - what is a restricted version by default - by unrestricted Toybox v0.8.5. This can get achieved by means of ADB.

jwoegerbauer said:
To root a device's Android TWRP isn't needed at all: Rooting is the act of unlocking the Android OS to gain complete control over the device through which you can access hidden files, change the ROM or install certain special apps. Rooting Android OS simply means to add Superuser functionality to it.
Here is what you have to do to root your device's Android: Replace Android's Toybox binary - what is a restricted version by default - by unrestricted Toybox v0.8.5. This can get achieved by means of ADB.
Click to expand...
Click to collapse
I am not a developer and new to all these things. I would appreciate if you could provide any video or article on how to do it. Thanks in advance!!

Shutupboomer said:
I am not a developer and new to all these things. I would appreciate if you could provide any video or article on how to do it. Thanks in advance!!
Click to expand...
Click to collapse
I was able to find this method of rooting through adb:https://forum.xda-developers.com/t/universal-guide-root-any-android-device-manually.2684210/
try it out and please reply if this method worked for you as i also want to try.

update: the rooting manually method didnt work. however, i found another way to get temporary root access on the lenovo tab 4 10. the lenovo tab 4 10 uses kernel version 3.18.71 which can be exploited by cve-2019-2215. download the zip i have attached and then copy the su98-memory-kallsyms file without the extention to /data/local/tmp if you want to do it through adb or to the /data/data/_________ folder where _______ is the terminal emulator you want to use with it and chmod it. then you can just do ./su98-memory-kallsyms and it will give you a root shell.
there is even an app included that does this and provides root access to all the apps. you can however whitelist some apps by puting them in the /data/local/tmp/su98-whitelist.txt. and the apps which werent allowed root access will be automatically put in the su98-denied.txt from where you can put them in the whitelist.
WARNING: this version of su98 was not specifically compiled for lenovo tab 4 10 and is a bit unstable. sometimes when performing a root task, it will freeze your tablet and you will need to restart. this is particularly annoying for me as my powr button is broken and i need to remove and reconnect the battery every time.

Vivo y33a

Hi everyone, I got a vivo y33s and wanted to ask if you can root it and if there are any custom roms

Every phone's Android can get rooted.
All you have to do is either to replace the pre-installed suite of Android shell commands ( AKA Toybox ) by a version what contains the su command or adding a suitable su binary to Android's filesystem, preferably to /data/local/tmp.
Whether a Custom ROM like LOS etc.pp. exists for this phone or not, IDK. GIYF ...

xXx yYy said:
Every phone's Android can get rooted.
All you have to do is either to replace the pre-installed suite of Android shell commands ( AKA Toybox ) by a version what contains the su command or adding a suitable su binary to Android's filesystem, preferably to /data/local/tmp.
Whether a Custom ROM like LOS etc.pp. exists for this phone or not, IDK. GIYF ...
Click to expand...
Click to collapse
Exist tutorial or guide for this?

I would also like to root my Y33s....
Can anyone please suggest a good (up to date) Tutorial for the ADB stuff.....or any other method for rooting?
greets

Yeah !
I also want to root Vivo y33t.
It is such a headache to watch all the adds, with root access I want to disable all the adds with energized protection. But, could not root this phone.
Expect some helps from XDA specialists here.
Thanks in advance.