FORUMS

[help] ratel cell r1020 rooting

41 posts
Thanks Meter: 3
 
By arifincaesar, Member on 19th January 2020, 03:46 PM
Post Reply Email Thread
Hello,

I have a device called RATEL CELL R1020 with OS android 8.0 oreo.
I tried some applications for rooting this smartphone like kingroot, kingoroot, etc but failed. This device can't unlock bootloader, so I see rooting with exploit in youtube like thomasking. Please anyone here help me to rooting my smartphone?
4.4.78perf+ kernel

this attachment is screenshot of the system

Thankyou
29th January 2020, 04:52 AM |#2  
Recognized Developer
Thanks Meter: 2,026
 
Donate to Me
More
Quote:
Originally Posted by j4nn

@arifincaesar, do you have your phone's firmware in a downloadable form? Can you obtain linux kernel source code for your phone?
I could imagine adapting this (exploit source code here) for your phone, but the kernel binary that is running on the phone is a must pre-requisite. Obviously it would be only a temp root.

Quote:
Originally Posted by arifincaesar

there is no way to get firmware of this phone sir..
and there's no way to unlock bootloader..
i think the only way to backup firmware this device is exploit and getting root access without ubl..
there is just said 4.4.78-perf+

In my opinion, there is no exploit that would not need offsets within kernel image in advance.
Because of that you need a copy of kernel binary that is running on the phone.
Obviously it is not possible to back up kernel partition from the phone, so you would need the original fw (the same version that is running on the phone) and a way to extract the kernel from the fw package.
Without that you are out of luck, sorry...
Since there is linux kernel running on the phone (android uses linux kernel) you have legal options to request corresponding kernel source code, because linux kernel is distributed under gpl license.
But even if you obtained the kernel source, you would still need the binary, because most likely the new build from source would not be binary identical. The source code would just make it easy to decide which exploit could work, so it would make sense to adapt it for the kernel binary.
The Following User Says Thank You to j4nn For This Useful Post: [ View ]
30th January 2020, 05:33 AM |#3  
OP Member
Thanks Meter: 3
 
More
Quote:
Originally Posted by j4nn

In my opinion, there is no exploit that would not need offsets within kernel image in advance.
Because of that you need a copy of kernel binary that is running on the phone.
Obviously it is not possible to back up kernel partition from the phone, so you would need the original fw (the same version that is running on the phone) and a way to extract the kernel from the fw package.
Without that you are out of luck, sorry...
Since there is linux kernel running on the phone (android uses linux kernel) you have legal options to request corresponding kernel source code, because linux kernel is distributed under gpl license.
But even if you obtained the kernel source, you would still need the binary, because most likely the new build from source would not be binary identical. The source code would just make it easy to decide which exploit could work, so it would make sense to adapt it for the kernel binary.

is that bug when i had activated oem unlock in dev options but cannot unlock with fastboot mode?
22nd February 2020, 04:52 PM |#4  
OP Member
Thanks Meter: 3
 
More
Quote:
Originally Posted by j4nn

In my opinion, there is no exploit that would not need offsets within kernel image in advance.
Because of that you need a copy of kernel binary that is running on the phone.
Obviously it is not possible to back up kernel partition from the phone, so you would need the original fw (the same version that is running on the phone) and a way to extract the kernel from the fw package.
Without that you are out of luck, sorry...
Since there is linux kernel running on the phone (android uses linux kernel) you have legal options to request corresponding kernel source code, because linux kernel is distributed under gpl license.
But even if you obtained the kernel source, you would still need the binary, because most likely the new build from source would not be binary identical. The source code would just make it easy to decide which exploit could work, so it would make sense to adapt it for the kernel binary.

can you help me please?
Attached Thumbnails
Click image for larger version

Name:	Screenshot_78.png
Views:	110
Size:	41.7 KB
ID:	4956461  
23rd February 2020, 10:08 PM |#5  
Recognized Developer
Thanks Meter: 2,026
 
Donate to Me
More
Quote:
Originally Posted by arifincaesar

can you help me please?

Interesting. Getting kernel space R/W primitives is a nice first step.
But without kernel binary, that still may be difficult - with kernel 4.4.78 version, KASLR would be there for sure.
The Following User Says Thank You to j4nn For This Useful Post: [ View ]
24th February 2020, 01:23 AM |#6  
OP Member
Thanks Meter: 3
 
More
Quote:
Originally Posted by j4nn

Interesting. Getting kernel space R/W primitives is a nice first step.
But without kernel binary, that still may be difficult - with kernel 4.4.78 version, KASLR would be there for sure.

hehe i keep watching your work for exploit sir
if there something new exploit i'll try to my phone
thx before
24th February 2020, 05:38 AM |#7  
Recognized Developer
Thanks Meter: 2,026
 
Donate to Me
More
@arifincaesar, try this please:

Code:
cd /data/local/tmp
echo -e '#!/system/bin/sh\ncase "$1" in\n*model) echo G8441 ;;*) echo 47.1.A.8.49 ;;esac' > getprop
chmod 755 getprop

PATH=`pwd`:$PATH ./bindershell
That should try the offsets defined for xz1c. It's a blind try, but let's see.
Please post the log in a text form (copy it via clipboard from the terminal), using the CODE tags in the message (can be used with the # icon in advanced post).
The Following User Says Thank You to j4nn For This Useful Post: [ View ]
24th February 2020, 02:56 PM |#8  
OP Member
Thanks Meter: 3
 
More
Code:
cd /data/local/tmp
echo -e '#!/system/bin/sh\ncase "$1" in\n*model) echo G8441 ;;*) echo 47.1.A.8.49 ;;esac' > getprop
chmod 755 getprop

PATH=`pwd`:$PATH ./bindershell

i can't believe, it work bro i swear :v
is that my phone rooted?
Attached Thumbnails
Click image for larger version

Name:	Screenshot_79.png
Views:	106
Size:	85.4 KB
ID:	4957613  
24th February 2020, 03:07 PM |#9  
OP Member
Thanks Meter: 3
 
More
nope i think my phone is not rooted yet..
i check from root checker it say "sorry root access is not properly installed on this device."
24th February 2020, 03:18 PM |#10  
OP Member
Thanks Meter: 3
 
More
@j4nn heres the output
bindershell - temp root shell for xperia XZ1c/XZ1/XZp using CVE-2019-2215
https://github.com/j4nn/renoshell/tree/CVE-2019-2215

MAIN: starting exploit for devices with waitqueue at 0x98
PARENT: Reading leaked data
PARENT: leaking successful
MAIN: thread_info should be in stack
MAIN: parsing kernel stack to find thread_info
PARENT: Reading leaked data
PARENT: Reading extra leaked data
PARENT: leaking successful
MAIN: task_struct_ptr = ffffffcfe0d68000
MAIN: thread_info_ptr = ffffffd04aa3c000
MAIN: Clobbering addr_limit
MAIN: should have stable kernel R/W now
kernel slide invalid (0x4ffabc7b50)
kaslr slide 0x0
selinux set to permissive
current task credentials patched

got root, start shell...

Cell:/data/local/tmp # id
uid=0(root) gid=0(root) groups=0(root),1004(input),1007(log),1011(adb),101 5(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),300 2(net_bt),3003(inet),3006(net_bw_stats),3009(readp roc) context=u:r:shell:s0
Cell:/data/local/tmp # cd
Cell:/ # ls
ls: ./cache: Permission denied
ls: ./init: Permission denied
ls: ./init.environ.rc: Permission denied
ls: ./init.rc: Permission denied
ls: ./init.recovery.qcom.rc: Permission denied
ls: ./init.usb.configfs.rc: Permission denied
ls: ./init.usb.rc: Permission denied
ls: ./init.zygote32.rc: Permission denied
ls: ./init.zygote64_32.rc: Permission denied
ls: ./postinstall: Permission denied
ls: ./ueventd.rc: Permission denied
ls: ./verity_key: Permission denied
acct bt_firmware bugreports charger config d data default.prop dev dsp etc firmware lost+found mnt oem persist proc res root sbin sdcard storage sys system vendor
1|Cell:/ #
24th February 2020, 11:03 PM |#11  
Recognized Developer
Thanks Meter: 2,026
 
Donate to Me
More
@arifincaesar, well, as expected, detecting KASLR slide failed, therefore selinux could not be disabled and security context has not been patched either.
Without a kernel binary, it is difficult to implement a full temp root exploit.
I guess it could be doable, unfortunately I do not have the time for it.
The Following User Says Thank You to j4nn For This Useful Post: [ View ]
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes