yashsingh1/xdaforums huggingface dataset:
[Android Q&A, Help & Troubleshooting] droidvoider:
I have been very deep in code and I haven't really poked my head up to really understand the limitations. But now I understand locked bootloader and what that means completely. twrp doesn't address bootloaders if your device can launch that recovery it will load, otherwise it will not. The bootloader is checking for the existence of a signature and then it uses a backup signature. I believe that signature is the stuff at the bottom of the .pit file and the backup signature is something called md5.img.

I am hitting a wall now because I can't access PIT it is hidden beyond my ability to find it, inaccessible, or completely blocked. If I can't find PIT on the device I need to turn my logic around the other way. But I don't have to crack any encryption I just need to take the key from one and put it on the other.

edited, another thought: There is still an awesome chance I can ask someone with a Note 5 + twrp to just make me copies of their partitions though.. That is a valid idea still because if I write an unlocked bootloader from an LTE note 5 I am fairly certain it will boot up. this to me is fun, i like this

And then we come to the solution that is a lot more fun but a whole lot more complicated. Writing what we want to memory, the point of this thread when you started it.. Injecting selinux as they call it.

edit: i googled it's not hard.. sepolicy-inject was recommended by freddierice the same person I stole farm-root from. I need to figure out dirtycow memory writing the version with trident is the old version that hung up forever. So that's what I'm doing now unless you have another idea.. I need more umph to get things done with

another edit: dumpstate.c has this line of code, I know mmcblk0 by another name, the pit file.

static const char mmcblk0[] = "/sys/block/mmcblk0/";
[Android Q&A, Help & Troubleshooting] droidvoider:
A decent idea we didn't explore -- this could be it, we could be there​

install_recovery is really intended just to repair recovery, it can launch .sh scripts with limited other tasks. The idea is to edit the SuperSU scripts to point files that already exist on the phone now. Then patch those files with dirtycow to actually be daemonsu ..

Was this a bad idea or did we just have too many things to check out? If it is a file that is already in the context I think it may just happen

edited updated

installing su with it's install-recovery.sh isn't working because we over wrote /system/bin/applypatch with till, and till is only 1400 bytes so it's obviously not a functional but hacked applypatch. When I fire the install-recovery (kinda of amusingly) applypatch fires back through toolbox again, it's rejected by existing logic, but I can see the call because the hack shows commands through the toolbox.. You can't replace a running binary, the process dies. So the only option is to rewrite till into a functional applypatch but this seems to be very valid.

One note is that install_recovery can still execute .sh scripts and do very powerful things, not applypatch right now, but other powerful things! If you look in SuperSU common folder you will see some awesome examples of what you can do in a install-recovery.sh environment. I haven't tested it beyond attempting to get su installed.

1. Place your commands into script

2. use dirtycow to patch a script.. although 618 bytes /system/bin/install-recovery.sh has been tested to fire nicely

3. -#|/system/bin/sh /system/bin/install-recovery.sh|

p.s. I'm busy this week unfortunately, will try to get till reversed and put into a functional applypatch because I think with that we are home
[Android Q&A, Help & Troubleshooting] Delgoth:
You have a correct train of thought. The Stock Firmware mounts the Kernel (initramfs/boot.img) & Recovery as MMC and not ext4. So you would be correct thinking we would probably have to use mmcblk0 or another one similar.

Patching files already on device with dirty cow using Super Su data instead, is a great idea, albeit one we just haven't gotten to yet.

I've had success using a package of CLI disk partitioning apps like gdisk, that have been compiled for arm64. They've allowed me to read the entire GPT Partition Table of the devices internal storage.

I've used that to jump into trying to utilize the Real-time Kernel Protection CVE's that Project Zero disclosed in January & February.

If we can get access to EL0/EL1, which I have a sneaking suspicion is connected the Our Device's 'BOTA0 & BOTA' partitions, we would have access to full root permissions. So if we capitalize on dirtycow runtime patching, then we can get the kernel to execute any code we would like. Because dirtycow can make up the data for our injected kernel code.

If this is the case, then we might be able to load up the KEXEC modules I have in order to switch to a custom kernel. Also attaining access to those memory pages would boost the authority with which your tool can patch data.
[Android Q&A, Help & Troubleshooting] droidvoider:
we have applypatch​

Reboot is no longer necessary unless the exploit says so. (still a dangerous exploit use with caution of course) -- but i don't reboot

All code is included, this includes a new till exploit (both a small version and the precompiled working applypatch is included)

Warnings:

I haven't tested applypatch, it should work, i will test soon.

The Android 5.11 version is brand new! No one has tested it at all!!!

This is dangerously powerful code.. using it without understanding it, not a great idea

O

()() use with caution

* *

Code: (binaries applypatch and toolbox are included for Android 6.01 r1 and Android 5.11 r2)

https://github.com/droidvoider/CVE-2016-5195_GreyhatRootProject_Root_Console
[Android Q&A, Help & Troubleshooting] Delgoth:
Sweet! I will get to testing it with the 5.1.1 OJ1 Rom + Eng Kernel. I've already cloned the repo. Thanks.

I'm posting the files here, that I will be using to help test it all from my windows 10 OS first.
[Android Q&A, Help & Troubleshooting] droidvoider:
Updated the Rooting tool.

1. It patches screencap to be dirtycow so you can easily patch any file now.

2. If you add -#e for install_recovery, instead of -#, then install_recovery will wait the amount of minutes you set in the top of bridge.c before returning

(this needs to be done better, I need to check for status.. in logcat I see it begin the install, but there must be an error, i need to see the error)

3. I added Makefile and cmd_list.txt for attempting su install.. (it is the 2.79 SuperSU, change it accordingly)

p.s. that timing thing is mostly a hack I am not getting a ton of time to play.. 3am comes fast..

https://github.com/droidvoider/CVE-2016-5195_GreyhatRootProject_Root_Console
[Android Q&A, Help & Troubleshooting] Delgoth:
I worked on a SuperSu 2.79 script last night that got me halfway rooted through ADB shell.

I'll iron it out some more today and post it. I've been up since this time yesterday on my pc. These are exciting times.
[Android Q&A, Help & Troubleshooting] droidvoider:
Awesome! I have an idea to pipe the output from applypatch to stderr or a log file at worst. The variables are getting to be too many for me to simply work through it inside my head now. I have been blessed until Tuesday I am super busy. But any free time I have I always devote to Android now. (by the way I set that default wait to be 0 on the github repo, not needed in my testing the code is working)

<removed bootloader idea, it failed on write.. now that's behind us we can move on unless I figure a way past that>
[Android Q&A, Help & Troubleshooting] droidvoider:
you start an apk with am or monkey ... Let me know if I missed any other questions I'm excited about my find

I have awesome news.. As soon as I started playing with ls -la / using both contexts with root I seen that inside /cache/recovery/ is some log files. I am pressed for time hard, however

ls -la /cache/recovery/

/cache/recovery:
-rwxrwxrwx root root 1 2017-04-14 15:46 .bridge_run_once
-rwxrwxrwx root root 1 2017-04-14 15:46 .irec_done
-rwxrwxrwx root root 1 2017-04-14 15:46 .sent_file_list
-rwxrwxrwx root root 1 2017-04-14 15:46 .till_expolit_active
-rwxrwxrwx root root 1 2017-04-14 15:46 .toolbox
-rwxrwxrwx root root 1 2017-04-14 15:46 .toolbox_wait
-rwx---rwx root root 61 2017-04-14 15:46 cmd_list.txt
-rw------- root root 69632 2017-04-14 15:46 grp_rc.log
-rw-r--r-- system system 204367 2017-04-08 12:12 last_avc_msg_recovery
-rw-r--r-- system system 12168 2017-04-08 12:12 last_emmc_checksum
-rw-r--r-- root root 0 2017-04-08 12:12 last_install
-rw-r--r-- system system 428017 2017-04-08 12:11 last_kernel
-rw------- system system 414677 2017-04-08 12:12 last_kmsg
-rw------- system system 388927 2017-04-08 12:11 last_kmsg.1
-rw------- system system 401268 2017-04-08 12:11 last_kmsg.10
-rw------- system system 352600 2017-04-08 12:11 last_kmsg.2
-rw------- system system 410140 2017-04-08 12:11 last_kmsg.3
-rw------- system system 462013 2017-04-08 12:11 last_kmsg.4
-rw------- system system 402362 2017-04-08 12:11 last_kmsg.5
-rw------- system system 365127 2017-04-08 12:11 last_kmsg.6
-rw------- system system 391283 2017-04-08 12:11 last_kmsg.7
-rw------- system system 384879 2017-04-08 12:11 last_kmsg.8
-rw------- system system 387195 2017-04-08 12:11 last_kmsg.9
-rw-r--r-- system system 524288 2017-04-08 12:11 last_last_kernel
-rw------- root root 5 2017-04-08 12:12 last_locale
-rw-r----- root root 32634 2017-04-08 12:12 last_log
-rw-r----- root root 32762 2017-04-08 12:11 last_log.1
-rw-r----- root root 38454 2017-04-08 12:11 last_log.10
-rw-r----- root root 32349 2017-04-08 12:11 last_log.2
-rw-r----- root root 32789 2017-04-08 12:11 last_log.3
-rw-r----- root root 28005 2017-04-08 12:11 last_log.4
-rw-r----- root root 32569 2017-04-08 12:11 last_log.5
-rw-r----- root root 24835 2017-04-08 12:11 last_log.6
-rw-r----- root root 27938 2017-04-08 12:11 last_log.7
-rw-r----- root root 32646 2017-04-08 12:11 last_log.8
-rw-r----- root root 34493 2017-04-08 12:11 last_log.9
-rw-r--r-- system system 905265 2017-04-08 12:12 last_recovery

I can't copy those programmatically so I am going to attempt to read then write.. tired, it was a long day but i will try

Attached you can see the full output acquired from ls under both contexts
[Android Q&A, Help & Troubleshooting] Delgoth:
So as I said i uploaded three different build toolchains for arm64 linux devices. I have also uploaded all of the recent downloads from the thread in this mega folder.

Android-Dev ** N920A

https://mega.nz/#F!JqwiQRiI!DSNsThHo3EMR9Y6L5dq_3A
[Android Q&A, Help & Troubleshooting] killernos:
So I sideloaded 7.0 to my n920a would there be anyway to downgrade and be able to root, sorry if I'm posting in wrong place
[Android Q&A, Help & Troubleshooting] Delgoth:
I haven't gotten to Binary 4 firmware yet. Don't want to risk not being able to downgrade. The only option that might work, is flashing the binary 4 combination file for PL1, and hoping it's a Lollipop build like it's binary 3 PH1 counterpart. That would allow you to flash in the LP eng kernel.

Other than that, I don't know yet. I do really want to try the nougat update, but it's not time for me yet.
[Android Q&A, Help & Troubleshooting] killernos:
It is awesome way longer battery life, has a blue light filter as well this is amazing for when out in the sun, there is a lot to do as well but with these guys working is hard we may get the boot loader unlocked.
[Android Q&A, Help & Troubleshooting] killernos:
I can try this later just can't do it right now, but for sure in the next couple of days if not later tonight I will try, i want root so bad for this phone, exposed has somethings I would love to run
[Android Q&A, Help & Troubleshooting] droidvoider:
This is the log hijacker I started on. it has a simple problem. It copies the existing files to a new file beginning with the letter a so I could pick them apart. But the copying of even the file I created stopped working, never worked since that dirent, letter a thing was created.

Problem: I should be copying at least the files I put there and it's not.

Code may be a dead end but I likely it's just a matter of moving the process to a different binary

status:

code is being parked because it might not matter. The other idea regarding replacing files under /, /bin and /sbin while still blocked for the reasons listed is ringing in my head. Obviously if I replace those files we have root, remember a running binary dies if you replace it.. But there's something else I feel like I am missing. You ever get that feeling like you know something but it hasn't hit you yet?

I almost feel like I can give an eta now.. Given my past history on learning hard to learn things I will need to learn pthread/dirtycow I think we are approximately 1 to 2 months out unless an idea I have works.. (i have one, I will try it, then I will start pulling apart dirtycow to figure it out)
[Android Q&A, Help & Troubleshooting] Delgoth:
Good job dude. I'll be gone another day or two. I messed up the BCD for my laptop. I can't boot into Windows 10 since early this morning.

I was writing to [MENTION=7349237]JeSTeRH4CK3D[/MENTION], but I had to sleep, and now my windows bootloader is gone. So I've been reading about Boot Configurations all day and tomorrow. Android x86 is awesome because it's fully rooted and can connect to my phone. I haven't had a device that was root able in awhile. This might help.

I think it's because I installed androidx86 now as well as Ubuntu 16.10, that my EFI partition got jacked. The data is all safe. The UEFI Firmware just doesn't know where to find the windows install.

My device is back to PH4 now though. I'm gonna test them on MM unrooted, instead of Eng LP.

I need someone to help me deconstruct the stock and engineering sboot.bin so we can Diff them. I've never tried. And I don't have IDA Pro. So I'd have a long learning curve ahead of me, when there are already at least a handful of developers here, that are well versed in the matter.

I have some new results I'm writing up as well that came along as I wrote to jester. I haven't gotten that to him yet either. It's a lot. Like 12 pages right now.

Thanks to XDA, I can use the XDA Labs app, I can let you know.
[Android Q&A, Help & Troubleshooting] droidvoider:
edit, note

Anyone compiling for lower ABI level should edit the Makefile. If you don't know your ABI plug in your device, make sure adb connects and edit the Makefile build line as such

ndk-build NDK_PROJECT_PATH=. APP_BUILD_SCRIPT=./Android.mk APP_ABI=$(ARCH) APP_PLATFORM=android-$(SDK_VERSION)

[MENTION=3254678]Delgoth[/MENTION]

Keep me posted I do read your replies it helps me think and gives me a lot of my ideas :p

I have great success but not the whole enchilada yet. [MENTION=3254678]Delgoth[/MENTION] we can replace /sbin/adbd but I haven't explorer our idea on that yet.

Any file that is on the cmd_list.txt I can replace EXCEPT the dd command is failing, I don't think that will work anyway but I am trying to get at the last remaining files

This includes most /sbin files!!! I am considering hacking an sbin file and having our tool run from that.

there's a farm_dcow_list.txt now that farm and bridge both try to dcow -- not even sure it's working just assume yes because "i'm all that" and don't need to debug stuff

This is not worthy of time Del, it's posted here in case you are almost there if you could just replace an /sbin file.. Just showing you that indeed you can.

(wings clipped on this example, assayyed kitchen files and boot_push.img are not included, it can't exploit without adding files on cmd_list.txt)

unpack boot with assayed kitchen, modified to be root, keep those files and add them to phone.

---any missing files the exploit will say active but it shouldn't issue a command, that's by design.

off topic, lost connection can't hit my pc need to store this info

edit, storing a piece of code

I believe I need setexeccon when making execv type calls

working example but it must be in the aosp path. You could completely replace toolbox.c and compile using 'make toolbox' if you wanted.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>
#include <selinux/selinux.h>

#include <android/log.h>
#define LOGV(...) { __android_log_print(ANDROID_LOG_INFO, "execvp", __VA_ARGS__); printf(__VA_ARGS__); printf("\n"); fflush(stdout); }

int main(int argc, char *argv[])
{
//saves current context
char *currcon;

getcon(&currcon);
LOGV("[+] execvp running %s as uid: %d, gid: %d, context %s", argv[0], getuid(), getgid(), currcon);

int rc;
if (argc < 3) {
fprintf(stderr, "usage: %s context program args...\n", argv[0]);
exit(1);
}
rc = setexeccon(argv[1]);
if (rc < 0) {
fprintf(stderr, "Could not set context to %s: %s\n", argv[1], strerror(errno));
exit(2);
}
free(currcon);
getcon(&currcon);
LOGV("[+] toolbox running %s as uid: %d, gid: %d, context %s", argv[0], getuid(), getgid(), currcon);

argv += 2;
argc -= 2;
execvp(argv[0], argv);
fprintf(stderr, "Could not exec %s: %s\n", argv[0], strerror(errno));
exit(3);
}

no return value compiles as is ;)
[Android Q&A, Help & Troubleshooting] Delgoth:
Interesting indeed. I did manage to fix my laptop. I know so much about Windows boot manager now. I don't think I'll ever need Grub or Lilo again....My problem is I have a dual boot laptop, and my main pc is a tri-boot machine.

I can configure Linux to boot from Windows woop woop.

I got on to tell you, in PH4, the stock rom won't allow me to unchecked "verify apps over usb". It only turns on when I have USB debugging. And I can't change its setting, only the system can. It turns back on as well if both oem unlock and USB debugging are off.

That immutable toggle, might be killing us in ways we don't know yet. That's why I disable Google play store and all the Google Apps including play services as fast as I can. If you let Google update it apps, they will stop exploits that aren't patched in your build.

The play store watches what you do. And Google tells it to look for harmful behavior Samsung hasn't patched yet.
[Android Q&A, Help & Troubleshooting] Delgoth:
I know the post I just quoted is from almost a month ago but, if you look in the mega folder I posted above (https://mega.nz/#F!JqwiQRiI!DSNsThHo3EMR9Y6L5dq_3A), you will find the archive titled "aarch64-bin".

In that archive I have uploaded the command line applications for managing GPT Disks/Partitions, that are compiled for our devices.

They are SUPER informative about our NAND setup.
[Android Q&A, Help & Troubleshooting] droidvoider:
The info you uploaded again is spot on what I need to be able to overwrite /init. There is only a couple of files I am unable to replace with install_recovery. It will be a few days before I can test this but as soon as I compile a final version of the context code I pasted above I will compile for 5.11 also. It's a matter of patching the correct binary with dirtycow after finding a way to gain that context. If install_recovery normally calls another binary we jump in some where.

snippet from some of the info your uploaded

# Note that if SELinux is set to enforcing, the daemonsu binary expects
# to be run at startup (usually from install-recovery.sh, 99SuperSUDaemon,
# app_process, or init.supersu.rc) from u:r:supersu:s0 (7.0+), u:r:init:s0 or
# u:r:kernel:s0 contexts. Depending on the current policies, it can also
# deal with u:r:init_shell:s0 and u:r:toolbox:s0 contexts. Any other context
# will lead to issues eventually.

I over wrote adbd and it died, I did not try to reload it because to be honest I don't have time right now. so I know we will need kexec or another method of reloading the overwritten kernel.
[Android Q&A, Help & Troubleshooting] JeSTeRH4CK3D:
you guys are going to get me back into this damn DEV aren't you?
[Android Q&A, Help & Troubleshooting] Delgoth:
Please and Thank You!!! For real though.

I know we still have to jump most of the same roadblocks that got most other Dev's to leave this device originally.

But I honestly believe that between this thread we're in now,

plus this breakdown on the SM-N920A here: Current State of Root as of 1/31/2017

And my original thread on the SM-G925V here: Greyhat Root SM-G925V VRS4CPI2 MM 6.0.1

It shows we have indeed made some intriguing progress towards rooting the locked Exynos7420 devices, that does seem plausible in devices not fully up to date. And should be a reason for a serious second analysis of the current Exynos5 platform mobile phones.
[Android Q&A, Help & Troubleshooting] droidvoider:
That would be awesome! I have been away a few days I get back tomorrow and I am excited to get back into this.
[Android Q&A, Help & Troubleshooting] JeSTeRH4CK3D:
Then let me see what I can pull together for better file hosting. I may just put up a cloud server or something. Me and Delgoth talked about that in PM issue is size and space at the moment.
[Android Q&A, Help & Troubleshooting] Delgoth:
Good job on the April 16th update to the Root Console, Things seem cleaned up nicely too. I haven't had any problems running the Console like we talked about before, since you included the 5.1.1 branch. I do believe it's working when it says it successfully executes my command script. But I honestly don't know what it's doing exactly at each step reading the memory chunks. I have get the high concept perfect, but what is the C code doing in certain spots. I'm working on those questions still. Because I have an idea about how to automatically detect the best context suited to the file contents themselves for the console to execute under. This isn't terribly difficult to integrate, when you consider not every context is available to be used or switched to, at any given moment. The detection wouldn't be needed primarily, therefore it doesn't require perfect accuracy either at every node in the Algorithm's linked-list of steps.

Here is my Testing Agenda:

[MENTION=7945178]droidvoider[/MENTION] -- [MENTION=7349237]JeSTeRH4CK3D[/MENTION] -- [MENTION=5254272]TechNyne66[/MENTION]
[Android Q&A, Help & Troubleshooting] droidvoider:
By request I am uploading precompiled binaries for Android 6.01. See Makefile for how to use the binaries and I included a small cmd_list.txt without any copy ~ from ~ to ~ entries so that you can clearly see how to simply execute commands. I don't think Windows natively supports make. For Windows users rename Makefile to make.bat, edit it to be a batch file.. On linux I type 'make' in the same directory with a Makefile it's a scripting system. Then I can also type make run6 to run the exploit.

Updated binaries for our partially working tool. If you have great success please do list us in the credits!! This is a team effort and the credits are absent from this so please give credit to the folks I listed on github Greyhat Root Project Root Console, and please don't just give me alone credit. JeSTeRH4CK3D is has been a great consultant on this project also I need to list him in the credits as well.

https://mega.nz/#!EUV3jDrA!hU1uq6txRjneV6YlSIBvCXJyP8SzVaY25m-y3i0WeAk

things are starting to really click now stay tuned I am working on stuff again
[Android Q&A, Help & Troubleshooting] ibnbazooka:
[MENTION=7945178]droidvoider[/MENTION] thanks for the binaries

but can make you root exploit excute sh instead of cmd list pls
[Android Q&A, Help & Troubleshooting] droidvoider:
That's a great idea and I'm not sure why I haven't given you guys a tool that you can just type in commands. I will either make an entirely new tool or I will make the current tool offer both.

Task List:

completed ---> 1) eliminate system() in favor of execv so that I can test the exit codes.

2) add a command prompt to farm.c that will forward commands to 'toolbox' or whatever binary we exploited

updated

major update in the way we execute and much better error reporting. I didn't get a chance to test it much but that will come..

https://github.com/droidvoider/CVE-2016-5195_GreyhatRootProject_Root_Console