yashsingh1/xdaforums huggingface dataset:
[Android Q&A, Help & Troubleshooting] droidvoider:
I needed to finish another piece of code before I started on toolbox, and that code is finished and on github. I need to be able to replace a list of files and know they are exact byte for byte, that's the code that I made available, which is in itself cool. Now I'm testing how to control the toolbox loop but so far if I get input from the command line the child executes one task then dies. I don't really want to fork fork fork fork things.. I need better control logic. soon i will solve it then upload a great starting point

edit: I realized there is places I can post snippets of code.. Here's the code I'm playing with but please realize some things may not work, not belong or I may have started making variables I never used.. (this is the pile of code I am using for testing).

I test code in Ubuntu first otherwise there wouldn't be enough time in a day:

gcc -o fork_u fork_u.c

./fork_u

http://pastebin.com/7nFxGcnY

Update: It's not exiting after executing a command at all. I messed up that if statement that checks for x. I am not a C programmer by trade I took it in college 20 years ago. Now I'm relearning it, so be warned on that ;)
[Android Q&A, Help & Troubleshooting] droidvoider:
====>] We have changed directions back to replacing the bootloader see the next post [<====

I am exuberantly confident we can take the bootloader after the testing I've done today. This is the basics of the bootloader

https://www.xda-developers.com/galaxy-s7-bootloader-lock-explained-you-might-not-get-aosp-after-all/

===>] I need someone to copy their bootloader in both locked/unlocked status so I can find what to change. [<===

I am starting to suspect I can't simply copy an unlocked bootloader from another device. I am fairly certain that I need to pull the sboot from the device, patch it and then push it back. I need to actually look at the source code and perform any steps it does as well, such as deleting stuff.

I need someone who is vulnerable to dirtycow with an unlocked version of the Note 5 to pull their sboot in locked/unlocked status. This means they would run the hack I'm using on their device, overwrite toolbox, dumpstate and app_process temporarily to pull the partition.

====>] Plan B is downgrading then attacking an earlier version of the phone [<====

I believe I can write the original sboot.bin and system.img to the Note 5 now to do a forced downgrade. If that is true we could be dealing with trying to root an Android 5.0 device instead of Android 6.0 .. This opens the door on a million exploits!!

Plan B is all I have for now let me know if anyone can help with Plan A
[Android Q&A, Help & Troubleshooting] droidvoider:
edit: nevermind on this idea I want to stay focused on unlocking the bootloader or downgrading it to Android 5.01
[Android Q&A, Help & Troubleshooting] droidvoider:
Update on status:

I can hard code toolbox to replace a list of files that you create right now, I am confident this includes bootloader, system, and a ton more.. So if anyone wants to do the leg work and find out which partitions are which, gather up a file list to replace and deliver that to me (the text version not the real files) .. I will hard code that out for you.. (i think that's freedom for you, see later bye)... Everyone else please realize I am having fun.. I tried to write toolbox to read what to change from /data/local/tmp/ but as suspected it can't read from there.. Today I will try to use dumpstate to copy a file list to /data/cache so that I can read it as install_recovery.

--- When I read what to change from a file we just need one toolbox for everything.. (no more separate toolboxes)

--- When I can communicate with toolbox in this manner I can move on to the next tool which is controlling the loop

Update:

toolbox is very limited on what it can open for reading if anyone is working on another project following along here for ideas you need to use the farm-root bridge idea. and by that I do mean even patching arbitrary file tests have failed now also, so there will be no eliminating bridge/dumpstate process

Updated again: Haven't had a tremendous amount of time to play lately but I sat down and tested my way through my final idea for farm-root. Bridge reads what to pull/push from a text file and then also pushes a text file to cache/recovery for toolbox to read. The file will have the dd if/of statements. Instead of performing 1 operation bridge will loop it will either wait..pull...wait or push...wait..push.. toolbox dd pulls or dd writes, waits for bridge and they loop between one another doing the work.

(still uncertain about dealing with 4gb file size but I realized that I don't need a sig verification. So I can unpack system, make it quite small then repack. This should smash down the version problem then we will need to do a follow flash of OJ1 AP, CP, CSC files...)

....thanks for your help with things lately [MENTION=3254678]Delgoth[/MENTION] you've hurtled this project ahead and are likely the reason it's here at all. I'm not forgetting the other things you mentioned I'm just at a wait and see pattern on what we need to force this downgrade, then get root
[Android Q&A, Help & Troubleshooting] Delgoth:
If toolbox is becoming limited, Toybox is also a partner binary that is used on the system beside toolbox.

Also if you can shrink the system partition and keep it persistent. You can shrink it from 4gb to 3.5 safely and then possibly reclaim that 500mb for your own private partition. My installed stock system uses 3.4gb of 4. That hidden partition should then remain even after a factory reset. As long as the device was not repartioned by odin or otherwise. Or as long as a new PIT isn't flashed.

This is where you can store your hacks, and have access to on device when first booting to recovery from a fresh flash.
[Android Q&A, Help & Troubleshooting] droidvoider:
toybox, good idea

I forgot about toybox when I get this code working I will rerun some of the test code on it to see how powerful it is.

New logic for root-farmer

root-farm will now only have 1 bridge and maybe 2 toolboxes (depending on final binary size for toolbox)

Now the files to PUSH/PULL are in a text file. Bridge copies it to cache and then toolbox can read it also.

PULL example: <= everything before the '|' is one execv command used by toolbox. => | <=== following this character is bridge copy leftvalue => | right value

of=/cache/recovery/bota0_pull.img if=/dev/block/platform/15570000.ufs/by-name/BOTA0 bs=10m|cache/recovery/bota0_pull.img|/data/local/tmp/bota0_pull.img

So push will only push a files.txt, pull_files.txt/push_files.txt is copied to /data/local/tmp/ then bridge decides if this is a push or pull depending on the text file format. After that it's pretty much business as usually toolbox uses the dd command as root+install_recovery to over write or copy

anything

This code snippets are not complete. They are meant to show you what I did to test my theories.

toolbox_working example

bridge will copy files.txt to /cache, toolbox will pick it up and then spit the contents out into logcat -- success

unfinished_test_code

that's the parsing, it echos the commands it doesn't actually dd anything.. but you can see it echo what it should be copying, or dd'ing.

updated (adding sources per a users request):

brdg.c.tar.gz == linux proof of concept for bridge, i make copies, test stuff from blocks of code like this then port to android
[Android Q&A, Help & Troubleshooting] droidvoider:
This morning something dawned on me. If I can write to the first partitions known to the computer worlds as MBR1 512kb limit MBR2 extended mbr.. Then I already own this device. Now I need twrp with the correct addresses for my device, I simple write twrp on the device and wipe the rest.

While I think that is true 100% I have different passions then simply winning. If anyone is willing to try it I will port farm-root over to point at those partitions instead, and also to replace them in one go.

Those waiting for the finished tool I get to play today a little since I had to work Sunday! we should have a template at minimum this evening. I'm adding to sources one is the partitial conversion it will be called Android_Dirtycow_root_farmer from now on.. (because it isn't specific to any device any more it will work with any 64bit dirtycow vulnerable device)

the test zip?, man I forgot what I tested with that just type make test and watch logcat.. tests are always safe, reboot afterwards though.
[Android Q&A, Help & Troubleshooting] droidvoider:
Tool is working!!!

Android 64 bit universal dirtycow dd image write works for both push/pull.. I am tired so please see github readme, the Makefile and push_files.txt, pull_files.txt examples. I am going to get root, this is the first step.

https://github.com/droidvoider/Android_6.01__DD_Dcow

More info on it

I updated this thread with some info first/last posts only

https://xdaforums.com/note5/general...g-dirtycow-t3559637/post71102343#post71102343

What about root right now?

If I can get system_server + root, then switch to install_recovery + root I can fork both these processes away and send commands to them through a text file just like I sent the options for push/pull. This code wasn't only to eliminate the need for multiple toolbox / bridge binaries.. It was to create a command shell that I can issue any command. Remember my examples above?

.....Work study: take the examples I created and create a loop that doesn't close but instead waits for changes to a text file. Then execv those changes returning to wait again for more changes.

I have to be away for 1 to 4 weeks I just found out.. I might be able to check messages, I dunno. not away but same as.. have fun
[Android Q&A, Help & Troubleshooting] Delgoth:
Im going to go over all this, this weekend. Hopefully I can work out what data to write.

If we can patch /sbin/sverifysignature then we maybe able to disable the sig check. Right now my device is without a DT_Hash, I have busybox installed and linked to /system/xbin

I also have the su binary in xbin but its not linked so apps dont know it's there. But they both persist through reboots no problem. I am currently half way rooted, with zero hiccups so far.

Im close but im running 5.1.1 with an eng kernel and eng sboot. I dont currently have a CSC installed.

The problems im running into are that most apps have always done root the same way, the way that doesnt work on this device. Root is possible, but the age old standard root injection doesnt fly here, we have to do it manually this time because the standard root install scripts expect privs we dont have in certain places. That doesnt mean we can't root, it just means we have to edit the scripts and run them from some place other than TWRP. Which is still possible.
[Android Q&A, Help & Troubleshooting] Delgoth:
So here is what I have:

Dm Verity verification failed... Message when entering recovery. No effect on operation.

ADB root on boot, and when charging offline.

Busybox 1.22 fully linked from /system/xbin

Chainfire supersu 2.76 su binary placed in /system/xbin unlinked, I dont know how to link it like I did with busy box.

Even though dm verity fails, I can mount the entire filesystem read/write, and all my changes are still in place after normal reboot. I can modify my system and dm verity does NOT undo my changes. I can even pull my boot img from /dev/block/sda5

What do I have in my hands right now?
[Android Q&A, Help & Troubleshooting] droidvoider:
How did you get the binaries onto /system/xbin? I am almost finished now making an installer for Superuser.apk, and other things also if you wish.. I can install Superuser.apk as root but I am struggling to get the binary onto /system/xbin..

Unless??? Wait, are writing a boot.img and it adds the binaries while you are live/running?? I haven't tried that yet.. anyway I will update a powerful command executer soon which allows installing as system_server + root.. Also by the way I can disable packages with it such as at&t software updater, probably almost any package can be disabled now.
[Android Q&A, Help & Troubleshooting] Delgoth:
I used ADB to mount /system read write with

"Adb shell mount -o remount,rw /system"

Then used ADB push to get the binaries into the directory.

I would really love to get my hands on your full program. I believe it would get our tethered root into a full root. But I need to figure out how to have the shell user open apps from its root context.

With the eng kernel, the shell user is always root. So if we could launch things from the shell user context on my end, we would have the privs needed. I just dont know how to link the binaries correctly.

But most apps are programed to use a specific kind of su with all of the standard SuperSu ways. But the eng kernel already has root without the need for a su binary to grant it admin access.

If we could just get some su/root injection scripts modded and make it so all changes are done within /system we can get it on my device.
[Android Q&A, Help & Troubleshooting] droidvoider:
<see my edit update notes first>

Delgoth so then you have adb root this makes me very confused, I dunno what context rights you actually have. Can you cat /init??? If so then in fact you *can* use dirtycow to patch your /init!!! Can you do cat /selinux ?? <--- did it spit a bunch of binary out or say permission denied? (ok say you can patch all those things with dirtycow selinux, init, contexts, init.rc and etc.. ) --- use the tool I just uploaded to reload /init ---> -# |/init|

(if it fubars just reboot and try again, this is the benefit of a phone that rebuilds /system on boot)

Edit: If you need a rooted kernel I can make you one.. I have a PJ1 rooted boot.img/recovery.img but the file sizes are likely greater than yours.. (that doesn't work with dcow, never exceed file size)

Funny updated:

Our next goal is using dirtycow to patch files using root + system_server as well as root + install_recovery .. This is a major challenge due to binary size, while I can gain the necessary space by removing the LOG stuff I wouldn't be able to see what happened in the logs anymore.

But as I was considering Delgoth's words I realized I don't need to add dirtycow to toolbox. I can execute it if I patch a file under /system/bin to be dirtycow!! or maybe if just put it in /cache/recovery using the new tools copy feature but then on the next line execute it from cache?? going to hack my hacking tool, ill be back

Edit Updated

We can't execute /init which was one of my main goals. I am using system() to execute in my tool but perhaps we should use execv() like freddierice used original, and there's merit to if you google. But long story short I am making an updated version with the following features.. (almost done, but my eyes are blurry)

1. The tool will attempt the call with system(), but if we receive an error it will then attempt the call with execv()

2. execv() takes arguments piece by piece, I added the binary name + 5 more arguments.. "each space in your command constitutes an arguement"

example: cp -Rp /data/local/tmp/test1 /data/local/tmp/test2 <---- 3 arguments

3. The tool now executes consecutively line by line calling system_server or install_recovery context on a line by line basis.

(the current version executes all install_recovery commands then moves over to system_server)

night guys, tomorrow that tool will be released.. then i hammer even harder
[Android Q&A, Help & Troubleshooting] Delgoth:
I spent all night looking at it, I was running 5.1.1 Android with the rooted engineering kernel, but I kept hanging after running

./farm ./toolbox on the third exploit block. So I haven't actually gotten the root console to even issue an echo command from busybox under either context.

So I flashed back to PH4 and got then same error. Maybe it's because you are using the PJ1 kernel as your starting point instead of the PH4 kernel. That might be making a difference.

I really want to try to understand this tool at a lower level, this app could make it easy to write some code that exploits the Certifi-Gate vulnerability from older AP files.

This tool potentially offers the ability to convert TWRP recovery zips into a cmd_list.txt file compatible with this tool.

I'm still trying to figure out its usage, and actually understand what is happening when, in the source code. I have a long write up I'm mostly finished with I'm going to message you, about an updated Root Strategy. Also about a name for your tool I came up with I hope you might wanna go along with. As I plan to use your tool as a cornerstone for the Greyhat Root Project.

If we can run shell scripts out of whatever context we set, theoretically we could build this into a SuperSu replacement for our device to bypass our need for a 'su' binary. Because the app can act as if it were the su binary itself while at the time acting as its own super user access manager.

If an outside app needs to run a command as root, they could call to the console to run it, the console selects the correct context the command needs to run in, finally acting as a proxy and executing the root command itself for the outside user app.

Idk, some thoughts from the last 24 hours. I'm really looking into polishing up a nice front end to help automate the usage of your tools here.
[Android Q&A, Help & Troubleshooting] droidvoider:
I need to build a test for you all inside farm.c so you can see the errors that are taking place.. But before I do that I want to finish what I'm working on.. (i work saturday's but i will get this done).. name is something this tool needs.. I am not good at that type of thing, naming stuff.

This is how the tool works..

---- Hack applypatch with till(applypatch hack) ---- NOW WAIT UNTIL WE HAVE SYSTEM SERVER BEFORE EXECUTING!!

---- Hack toolbox.c and then WAIT for system_server + root to make a call that passes through toolbox.c (hijack it, make a copy and loop the copy into a process)

hijack system_server

---- (inside toolbox.c) "if curcon == system_server" <--- when we have system_server, also we rsf_set a const char * so we only do that once..

====>	if( !strcmp(SERVER_CONTEXT, currcon) && rsf_set(RSF_TOOLBOX) ) {

notice right here my tool does something new.. I fork a copy of system_server before allowing that process to morph into flash_recovery.. so I have both

forked < system_server, call flash_recovery --- we have two system_server process right now!! (but one we put in a while != sleep loop)

----	property_set("ctl.start", "flash_recovery"); -------> TILL morph to install_recovery then shoot install_recovery back through toolbox.c again

grab the root + install_recovery thread -- till issues ls command, this sends the flash_recovery through toolbox.c

}else if( !strcmp(INSTALL_CONTEXT, currcon) && rsf_set(RSF_DISK_TO_CACHE_WORKING) ) {

so now past that if statement you have root + install_recovery.. You can loop it, fork it.. whatever you want.

So now you know.. if you want another context we just hack it like till/applypatch to issue the toolbox command ---> ls

it's complicated to explain.. let me know if that got it done. you should be able to hardcode anything you want in the right areas.. remember to fork() before calling execv() or it will drive you insane, lol
[Android Q&A, Help & Troubleshooting] Delgoth:
Right, I still need to do more background reading on till I think.

Because I'm still a little fuzzy on the order of operations, or the program's flow of logic. I guess I need to do some more staring to see how this app truly does its work.

Thanks for that though. I'm writing up a modified root strategy, a README/User Manual for automating cmd_list.txt generation & how to use the app on Lollipop Builds that have extended system capabilities afforded by the Rooted Engineering Kernel from the PB2 build.

And I'm also writing you the message about Titles and Project Names.
[Android Q&A, Help & Troubleshooting] droidvoider:
Very cool thanks I will check it out when you're done..

HUGE BUG strtok should look for | on it's first call and not " " .... Please wait for updated version it will include a test section to test functionality so we can catch these little bugs.

note: make sure you have a space after the -$ or -# when using the old version and I think it still works.

Getting close to final

NO SPACE AFTER -$ AND -# NOW please notice I removed the space in cmd_list.txt I think it was causing issues.

This example mounts /system read write, or I get success on the attempt anyway. It has su binary and it attempts to copy, it fails but I'm confident the command executes correctly it's just denied. The smaller version doesn't include the example Superuser.apk install. The larger version includes Superuser.apk, which in fact does get installed but it's an untrusted app.

There is a huge chance we can patch a file to make Superuser.apk a trusted app though.. that's a different topic

toolbox and till binaries exist, you will have to make run to get the other binaries

Android_6.01_dcow_root_console-broken-su-install-example.zip

Android_6.01_dcow_root_console-Superuser-apk-example.7z

no local farm.c test yet.. limited testing, just finished... back soon
[Android Q&A, Help & Troubleshooting] droidvoider:
Ok here it is with a LOCALTEST feature. Download the github repo, delete Android.mk then rename LOCALTEST-Android.mk to be Android.mk

open 2 terminals, make log and make run

no rebooting needed for LOCALTEST, you can rerun all you want we aren't using any closed source stuff just bridge.c and farm.c

you can see the commands get executed right there in the window, permission denied like a mofo, but you see it happen lol

in addition to the localtest it also now executes in exact order as I mentioned I need it to do. As a measure of completeness it also retries failed commands using execv().

edited noted: April 09 2017 9:24am pst I realize bridge is completely unneeded in the test (thanks for the email to the person who emailed) ... the entire point of this tool is multi binary interaction and I needed that to work on some level so others can tinker with that side of things also.

Warning: I just remembered that something is off with allocate.. unfortunately I don't remember what it was.. hmm.. should be low level worries.. head is fog right now, back later need a rest.

https://github.com/droidvoider/Android_6.01_dcow_root_console <--- it's updated sorry about the 6mb Superuser.apk example

updated on malloc.. i am freeing the wrong address.. i'm not all the surprised that I can see the problem with my code, i learned C less than 4 months ago. it's not big on my list to fix and i will not push another update just to solve that problem it will be fixed in the next actual update

(playing with the tool today to see what I can get, let me know if you need anything added or fixed) --- ok temporal root done, now where is that twrp zip file I need to install?? hmmm?
[Android Q&A, Help & Troubleshooting] Delgoth:
Look at Philz MM Recovery for the G925F that arter97 uses in his arterKernel.

I had minor success with that on my VZW S6 Edge before you made these tools. It gave me a bunch of leads back then.

The N920 sources were built from the G925F sources. They should be VERY similar in many ways.