yashsingh1/xdaforums huggingface dataset:
[Android Q&A, Help & Troubleshooting] droidvoider:
Major update!

1. I have debugged the tool heavily and it appears to me that I can replace any file on the system. Testing files you can't normally read is done via code so it's slow going, let me know if you find any blocks now.

2. If you have any file that gives an error but then replaces, that's because it tried other contexts.. PUT THIS ACTION AS THE LAST ENTRY, it might not be changing back to install_recovery from some contexts

3) the su install thing is designed to give an error I didn't even try to get root with this, literally focused on getting the tool done only.

4) next is a console of sorts, with exec dcow patching.. muahahaha

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

update on progress

I have been working and when I work I can't really create new tools. I have been reading, small tweaks to current tools only today

.. learning selinux, anyone wanting to see how it works check this area of aosp

AOSP_Sources/Android_6.01_r1/external/selinux/libselinux/src

AOSP_Sources/Android_6.01_r1/external/sepolicy
[Android Q&A, Help & Troubleshooting] droidvoider:
I can reset adbd but if I try to allow root it won't restart.. selinux, of course.. I am focusing 100% on selinux now because i tested and I can change the test in adbd, restart it and it is patched. I am doing that with c code by the way and I do have a version compiled for 5.11 as well already that restarts adbd after the cmd_list is run..

it's getting pretty fun now. I'm holding making the shell until I see if I am going to succeed we will have root. thanks Delgoth for the idea of hidden commands in adb_main

[MENTION=6336105]ibnbazooka[/MENTION]

The problem with making the psuedo shell is that the basic things are blocked with selinux where only certain things are allowed. install_recovery context is extremely powerful, but mostly when executing install-recovery.sh script. In many cases to execute a command I need to decide if I will execute it directly or if I will patch a bash shell script then call that script.

because if you try to do it by hand you have to patch .sh file. call .sh file. now you have no log file so you can't see what passed through toolbox. then next is handling piping, and so on.

not as easy as I thought, if you tell me what you're trying to do I can tell you how with the current tool (or I can just make a simply little exploit)
[Android Q&A, Help & Troubleshooting] Delgoth:
That last bit is what I'm still struggling to get the front end to recognize before communicating with the backend CLI.

I need to learn the sepolicy inject tool more specifically. But you are right.

The tool has those two contexts to choose from, and then you can only transition to other contexts that are allowed in the policy. Install_recovery can't just switch to any old context. It has to go through a Daisy chain of switches.

***

Can we fix the code,

so that instead of specifically waiting for "system_server" or "install_recovery" to encapsulate our context loop,

We can specify a context to wait for, either in cmd_list.txt or an accompanying file, so that way we can be sure the commands we are trying to execute will run in the context expected?

***

I have my S7 edge rooted now, and finally fixed up as of this morning on a September build. So now I can really see what has been going on.

And using the rooted device to test, I can get results from the console that we haven't been able to get yet. The full root will allow to act as if the console is already finished, giving us examples on where to take the code possibly to finish it.

Farm root was originally intended for S7 devices. So maybe there will be many insights to be had. I'm downloading the newest source now. And I plan on spending the day pretty much on my computer.
[Android Q&A, Help & Troubleshooting] verg0:
Wow! This is great news! Did you try this on a combination firmware as i need root on this device to repair my dmverity faild S7 Edge?
[Android Q&A, Help & Troubleshooting] JeSTeRH4CK3D:
interesting questions when running hashcat against the extracted bootloader.img file looking like "NO BS" there is a master code to unlock bootloader functions. Showed interesting USSD to [MENTION=3254678]Delgoth[/MENTION] was it interesting [MENTION=3254678]Delgoth[/MENTION] or am i just looking to deep into the rabbit hole?
[Android Q&A, Help & Troubleshooting] droidvoider:
Code is updated back to have two loops again because really setting context does nothing for us, I will update the repo soon it isn't yet. But, all the same, I am able to keep the context setting stuff still. I believe I want to add back system() but this time only if execve() failed, I think system() has rare successes that execv does not. (long story short, it will process each command per context and wait again with the new setexeccon() logic)

Almost done now.. I am also adding new toolbox binary for 5.11 and 6.01 which restarts adbd because I have a feeling our very talented Delgoth might have a lot of fun with that. I am consulting on a problem for work but I know the problem, just remotely instructing.. so i think i will be done in a couple hours (I want to make the restart adbd dynamic and allow multiple restarting services)

back soon, also I was given a tip by [MENTION=6336105]ibnbazooka[/MENTION] regarding swapping in recovery in a way to boot root which I need to try. ibnbazooka you didn't say not to pass the knowledge I will give you a couple hours to stop me but please realize if I have positive results, as you say reboot without rebuilding system every time, I will be publishing open source solutions. (im all about open source)
[Android Q&A, Help & Troubleshooting] ibnbazooka:
[MENTION=4811885]DroidVoid[/MENTION] publishing open source solutions

if you make it publishe open sorce they will fix it in the next update and all you work will be vanished

the biggest challenge is to make root work open source doesn't matter

---------- Post added at 09:01 PM ---------- Previous post was at 09:01 PM ----------

[/COLOR [MENTION=4811885]DroidVoid[/MENTION] publishing open source solutions

if you make it publishe open sorce they will fix it in the next update and all you work will be vanished

the biggest challenge is to make root work open source doesn't matter
[Android Q&A, Help & Troubleshooting] Delgoth:
I was extremely surprised to see how many of the Factory IME codes worked when I was on the full factory binary firmware.

Many possibllities. I just don't know how to use all of those yet.
[Android Q&A, Help & Troubleshooting] JeSTeRH4CK3D:
[MENTION=4811885]DroidVoid[/MENTION] technically speaking [MENTION=6336105]ibnbazooka[/MENTION] is correct however the fact that the findings are for an open source community kind of makes risk verse reward come into play. If you root it and they fix it we still have the option to disable all further OTA options

[MENTION=3254678]Delgoth[/MENTION] I'm wondering if the device master code in question has to do with imei because I narrowed the needed code to 8 char. And the imei unlock is also 8 char. yet so it the sim unlock for most att and Verizon.
[Android Q&A, Help & Troubleshooting] droidvoider:
ibn good point I will not publicly disclose your secret.

little delays, I never know when work will suddenly get busy. I have to do a lot of testing before I release the updated version. I have to add a new idea which is to have farm.c just handle shell context related commands also, sounds trivial but actually shell has some umph when paired with dirtycow.
[Android Q&A, Help & Troubleshooting] droidvoider:
ok i updated github, i need to do a lot more testing but the basics of what was tested to work is there.

1. Tons of LOGV messages especially with setcon, setexeccon and etc.. remove to reduce binary size

2. Services restart doesn't seem effective without hacking selinux, recompile without the flag if you need it smaller

3. but all the same `adbd will do stop/start on it.

I am getting pretty good and I have a few ideas to allow the disallowed selinux actions. as I test my ideas you can expect I will find bugs and update the github.. let me know if you find them first.
[Android Q&A, Help & Troubleshooting] ibnbazooka:
[MENTION=7945178]droidvoider[/MENTION] i think its the time to surprise us
[Android Q&A, Help & Troubleshooting] akiraO1:
Off subject but useful all the same

Hey guys ive been following thus thread for awhile and i first and foremost would like to say thank you for all your hard work, it has literally inspired me to learn to read and write C code. Ive been testing everything you have been releasing on my note 7. Yup i still have it and always will. It is also an extremely rare phone that is immune to updates so nothing will ever be "fixed" on it haha but tht also means if i brick it, its gone forever and since i am trying to decrypt the signature on the bootloader, its been a little scary. That is until i realized you can flash a bootloader to your recovery partion. I actually even got a modified bootloader to stick there and flash with it but i dont remember which img it was and i hadnt realized the ppotential of putting a bootloader in your recovery partion at tthat time. So basically what im saying is that if you ever need to test a bootloader and not permanently destroy your device, flash it to your recovery partition with either farm-root or odin. With odin just name the bootloader recovery.img, then tar it. Now im not sure if this is necessary with odin because i havent tryed to flash the bootloader to the recovery partition with it but i always use the PIT file and click repartition, it just made sense to me to do that considering what a PIT file does and what the word "repartition" means ;) I hope this information helps you all out and is useful in some way, also if you need a tester, im your man. Im fearless when it comes to testing and know exactly how to not brick a device. Also ive never not been able to bring one back to life :) thanks again for everything thus far.
[Android Q&A, Help & Troubleshooting] droidvoider:
akira thank you so much for posting. I think it is incredible you have the Note 7, if you haven't already solved the battery issue yourself you definitely should do that first.

I am very happy to hear that you are learning c that was really our point when Delgoth and I started this. In my opinion it is very hard for those outside of the Android developers to understand how to use the AOSP source to compile your own versions of Android binaries, not just toolbox. There are a lot of examples how to change almost every part of the kernel, compile them and make easy little drop file zip flash files. The information is absolutely easy to find now that I know the keywords, and have an understanding of the entire make system. A great tip is if you want to understand how something works for example, setcon() search: site:android.googlesource.com setcon(

I can't reparation at all so you have a lot more power than I do. I love that you are trying to figure out the sig verification, pretty sure it's md5 the cert file is included with boot.img and recovery.img, system.img has one.. I have to check my notes if you need this info. (might add more to this, had to stop, back soon)
[Android Q&A, Help & Troubleshooting] Delgoth:
Let me read over this tonight. And I'll be back.

But even with all 4 files from the G935U flashed to my g935v SmartSwitch still reads the device as a g935v.
[Android Q&A, Help & Troubleshooting] akiraO1:
What does the build.prop say your model number is? If its still g935v it doesnt mean it really is just needs to be changed maybe? Just a thought :)
[Android Q&A, Help & Troubleshooting] Delgoth:
But I have been using the sprint version of the U firmware on my verizon device.

You are right, that the build.prop would/could make that difference. But it's weird still that the sprint firmware would still read as verizon.

I've been really kind of busy the last week and haven't been able to get online much
[Android Q&A, Help & Troubleshooting] droidzer1:
I've got a SM-920V - Verizon which is not an activated phone and don't have any intentions to activate it with VZ. Do you know if it would be possible to flash a whole Sprint ROM to this phone or does the VZ locked bootloader make this impossible? I don't need it to be on Verizon ... ever. I don't even need it to work on Sprint - just to be usable as a Wifi handheld computer ;)
[Android Q&A, Help & Troubleshooting] JeSTeRH4CK3D:
The bootloader has nothing to do with carrier protocols IE. just because you buy a imei unlock code online does that unlock your devices firmware? no it does not even remove old carrier bloat.
[Android Q&A, Help & Troubleshooting] akiraO1:
Well i ask because it seemes with things like model number and imei number when edited in the build.prop only actually changes the respective number in the settings, like a spoof. For example you can change your imei number and it won't actually change in settings until you edit your build.prop but will still be changed internally.
[Android Q&A, Help & Troubleshooting] JeSTeRH4CK3D:
Choose your next comment VERY carefully spoofing, changing, or modifying a IMEI number and a HOW TO DO SO are very touchy subjects and will get this site shut down if it is discussed.

NEW SUBJECT PLEASE!
[Android Q&A, Help & Troubleshooting] droidvoider:
I have to rush to a client and I am dropping my work here.. I think it is possible I can come home tonight and find that someone got root with these pointers.

Working with sepolicy in the aosp sources is actually really easy. I want to throw out some steps for other c programmers.

sepolicy files located in: (files ending in .te)

Android_6.01_r1/external/sepolicy/

First thing you should understand is to remove the never allow policies in conflict with the policy you wish to allow.

so modifiying adbd.te with this line will give a never allow compiler error

allow shell kernel:security setenforce;

so grep on sepolicy/ directory to see what is never allow

grep 'neverallow' external/sepolicy/*

Pieces of the code engine such as but not limited to libsepol.so

Android_6.01_r1/external/selinux

libselinux.so

Android_6.01_r1/external/libselinux

audit2allow <---- super awesome tool.. Takes dmesg disallows and makes policies to allow (right from dmesg)

1. The current Root Kit tool doesn't use shell context to replace files.. This may be a limitation to get this to work.. So just make a bash script to replace files using /data/local/tmp/dcow or something..

2. I think that's my big secrets for now.. go forth and produce fROOT, short for f**king root. (laugh, gotta go, bye)

earlier posts...

The entire time I was testing my code I was using the wrong sepolicy, I was just putting back the locked down sepolicy distributed with the phone! I am busy today but I got far in my testing last night.. There is one piece of run-once code that may get in the way of the following idea:

there's a run once section of code, if it dies with libselinux.so you just got root.. if not i will hack the run once sequencer

<removed, steps that can't possibly work>

update: 11:11 am

The SuperSU policy patching tool adds 100kb to the size of the sepolicy, that is fail for dirtycow.. but that's ok because we can build our own with the source code

make sepolicy

busy, but I feel like I am soooo close now! I just need to make a new policy that is less than 580kb
[Android Q&A, Help & Troubleshooting] Delgoth:
Good call. I was about to start writing before I saw your comment. That is a touchy subject, but I then refer back to this thread and the other in the N920A forum.

Lucky for me though, I don't currently have phone service and all my devices are WiFi only.

In all my endeavors over the last few months, having working Telephony/LTE services, has not been on my list of concerns. I own my devices outright and don't have service with any carrier.

Dude, I was able to get a root check to show partial root. It was when I messed with the SuperSU Install script I posted awhile back. I need to update the OP and include your links. PM with the next step of this idea here, and I will show you what I've been doing with SuperSu 2.76.

You can probably see what I've been missing. Probably doing the wrong patches at the wrong time.
[Android Q&A, Help & Troubleshooting] akiraO1:
Only an example, not in any way, shape, or form, talking about, or attempting the aforementioned subject. The example wasnt even based on actual events, it's all only theory.....go Ducks!
[Android Q&A, Help & Troubleshooting] JeSTeRH4CK3D:
Just warning you sometimes the "ADMINS" get touchy once the word change and IMEI are in the same thread. i been warned so im just passing on the war. not saying you did say you could......even though "YOU COULD" change them just saying not to say you could ;)
[Android Q&A, Help & Troubleshooting] droidzer1:
Yes I know the bootloader has nothing to do with carrier protocols. And Verizon is already carrier unlocked just by flipping a toggle in the unrooted settings. But my question is whether the locked bootloader would prevent flashing an entire Sprint Rom for the Galaxy Note 5 on a Verizon based Galaxy Note 5. Maybe the answer is to obvious but it's one I don't currently have with any certainty.
[Android Q&A, Help & Troubleshooting] JeSTeRH4CK3D:
And the answer is yes it would. The md5 hashes in the bootloader are different from carrier to carrier and result is failed Odin

The bootloader you can changes is only 1 of 2 bootloaders in the device, there is a BL and a SBL at&t has been setting locked SBL's for years the main BL is only for upgrading newer options and stuff like that, however the SBL is locked tight as hell so you can not change the hash keys to change the carriers codes. Now Samsung is locking the SBL for the carrier 2 carrier. even if you get the IMEI unlock codes for your phone the SBL will still always be the purchasing carrier. That's why a lot of people that switch carriers don't get the OTA updates and a lot have to do them manually
[Android Q&A, Help & Troubleshooting] droidzer1:
Thanks for clarifying that. It's what I had assumed was true but wasn't sure about it.
[Android Q&A, Help & Troubleshooting] JeSTeRH4CK3D:
your welcome..... i do like ppl to click thanks :P HAHAHA but anyways ya thats what is being the issue for most of us
[Android Q&A, Help & Troubleshooting] droidzer1:
Oh thanks was clicked also :good: cheers
[Android Q&A, Help & Troubleshooting] verg0:
Is it possible to install supersu to unrooted phone currantly with this method yet or is there still allot more to be done?
[Android Q&A, Help & Troubleshooting] JeSTeRH4CK3D:
superuser will only work with rooted phones so the binary SU will not work
[Android Q&A, Help & Troubleshooting] droidvoider:
Anything that we're doing is going to require patching the kernel and we are at the stage right now of just trying to trick something into allowing us to reload. I would simply 'inject' it into memory but even subtle testing with this leads to an instant reboot for me. This may not be true of devices running lesser than October 2016 security but to design such a tool I need a testing platform. If I patch running memory I believe the phone goes into 'fall back policy'. In this state even /system/bin/ binaries are 'untrusted_app'.. I get about 15 seconds then a reboot. But even if I have root it doesn't matter in this stage with things closing nothing is allowed, the system is broken. But we don't need to put it into this state after patching, we can patch everything in place but now we need to correctly reload.. (complicated, yes)

Which incidentally is pretty much what I believe dirtycow poc run-as experiences for users which it partially works. (Note 5 Oct 2016 security run-as doesn't work) But for those for which whom it does work those people seem to report root for about 15 seconds then reboot. For me I can see what's happening I watch the LOGV / logcat as it kicks /system/bin exec binaries and all apps to untrusted including privileged apps ending with systemui (so if running toolbox exploit LOGV context switches from root to untrusted_app)

It's not possible to describe the things I am working on right now other than to say I am playing with policies, selinux run once stuff, magic numbers and a ton of replumbing ideas.. sepolicy is patchable by anyone at the shell prompt, you can make sepolicy if you download the aosp source code then use dirtycow from /data/local/tmp/ to patch sepolicy .. no root needed, libselinux.so are both accessible also and if you replace an running proc image that image dies. I have instructions how to download aosp to compile these things yourself but I think you have to read a book or a tutorial on c programming not just try to learn on the fly.. (i am shopping more books)

https://xdaforums.com/android/software-hacking/guide-compile-bin-binaries-device-aosp-t3573623

make sepolicy

to see a list of modules you can make such as make toolbox, or make libselinux, or make sepolicy, please type the following from the root Android Aosp directory.

make modules
[Android Q&A, Help & Troubleshooting] droidvoider:
root

freddierice's trident actually does give a root shell!! dirtycow is the old version in that example and it doesn't always work, but if you try a few times in row it eventually works and we have root!! It not only is giving root IT IS INJECTING THE SEPOLICY. So trident uses a customized dirtycow_memcpy function, it's really not hard from what I see and I am attempting to move that function to the new dirtycow structure. I am not having a hard time reading dirtycow.c like when this all started so hopefully today we will get trident updated, root shell happening, sepolicy injection workng!!

excited yet? i am vibrating, I just got a root shell!! couldn't do anything yet, we need an sepolicy to inject...

Moving toward custom rom

I have some ideas mixed with several suggestions. Someone recently told me a solution to avoid having the system rebuild at boot and it is closed source. It is powerful, he had something mixed up a little but when I try I get all kinds of stuff, android setting up again, and etc.. (promising, this is a ways off) --- this is the end game
[Android Q&A, Help & Troubleshooting] akiraO1:
really?! ive tryed trident so many times and nothing....im on sept sec patch.
[Android Q&A, Help & Troubleshooting] droidvoider:
I'm using an incredibly large hammer..

ROOT!!!

https://github.com/droidvoider/trident

1. Download it., unzip it, open two terminals one for log.

2. type make log in one of the terminals

3. pull your current sepolicy to the current directory in the other terminal: adb pull /sepolicy

4. open settings on your phone, go to connections, mobile hotspots and get ready to follow instructions in the make log window

5. make run (follow instructions)

6. when it says so, make reverse

7. when it says so, make connect

Notes:

There is no prompt after 'make connect' --- you are connected try typing ls

You didn't update your sepolicy so you are very limited what you can do.. try cd /sbin and then try cat watchdogd <----- see, we are rooted

If you do ctrl-c to terminate something, you need to type 'make connect' again

Further notes:

freddierice warns us that the INIT_OFFSET may be incorrect, if that's true it isn't reloading the sepolicy.. have fun with root for now while I check this out further.
[Android Q&A, Help & Troubleshooting] akiraO1:
I can't wait to try thank you so much for all your hard work, I had a feeling this whole time that trident was the one, very exciting!

---------- Post added at 01:26 PM ---------- Previous post was at 01:22 PM ----------

Dude I can't beleive that!! All I had to do this whole time is type ls......wow haha
[Android Q&A, Help & Troubleshooting] Delgoth:
I knew you could do it. I knew it was possible. Im gonna play with these using the numbers we get from jcadduono's bootimg tool.
[Android Q&A, Help & Troubleshooting] ibnbazooka:
[MENTION=7945178]droidvoider[/MENTION] can you upload the binaries just for testing place the so much
[Android Q&A, Help & Troubleshooting] verg0:
Could 1 click root be developed from this exploit now?