FORUMS
Remove All Ads from XDA

Root tool DirtyCow Apk && adb

109 posts
Thanks Meter: 126
 
By kryz, Senior Member on 24th December 2016, 03:21 PM
Post Reply Email Thread
14th January 2017, 12:44 PM |#161  
OP Senior Member
Thanks Meter: 126
 
More
Quote:
Originally Posted by Curtis1973

@kryz

Ok here are two zips. One with a dmesg.txt before attempting the ./exploit.sh with 1 and after with 1. of note i could not post the onscreen results of the exploit running with the 1 added. the device went black screen and lost connection to it from shell had to reboot. but do have the dumps and the dmesg.txt maybe they will be helpful.

Thank you for the logs are helping a lot

I see in your dmesg (without 1 param), that the exploit is loading the new sepolicy, these lines in dmesg confirms that:

Code:
<7>[  420.215067] SELinux: 2048 avtab hash slots, 12560 rules.
<7>[  420.227142] SELinux: 2048 avtab hash slots, 12560 rules.
<7>[  420.227199] SELinux:  1 users, 2 roles, 743 types, 0 bools, 1 sens, 1024 cats
<7>[  420.227212] SELinux:  86 classes, 12560 rules
The first load sepolicy of the device is this:

Code:
<7>[    2.747565] SELinux: 2048 avtab hash slots, 9071 rules.
<7>[    2.753025] SELinux: 2048 avtab hash slots, 9071 rules.
<7>[    2.753067] SELinux:  1 users, 2 roles, 743 types, 0 bools, 1 sens, 1024 cats
<7>[    2.753080] SELinux:  86 classes, 9071 rules
<7>[    2.755379] SELinux:  Completing initialization.
Also If you got this prompt is because the new selinux policy was loaded:
Code:
# Type run-as -s1 to get a shell
# Type run-as -s2 to execute su daemon
Well, now we know that we have injected code in init process and the shellcode was executed, but in your device the run-as binary has some restricted rule, maybe can't change to permissive, even when i added some rules that's the purpose of the shellcode.

We are close, just we need to adjust the selinux rules to give more permissions to run-as domain, i've updated the exploit ADB.

The exploit is basically the same, just ive added some more permissive rules to run-as and now install su in enforced mode that's not bad at all.

If you can do the same test, clean the /data/local/tmp/ foder and extract/execute the new exploit without 1 param.

After the exploit is finished and if you get this prompt:
Code:
# Type run-as -s1 to get a shell
# Type run-as -s2 to execute su daemon
Execute these commands:
Code:
run-as -s1
id
run-as -s2
Wait 5 seconds and turn on/off bluetooth and do a dump of dmesg:
Code:
dmesg > /data/local/tmp/dmesg.txt
And finally again attach the result files please.

I attach the new version here:
Attached Files
File Type: rar EXPLOIT_ADB.rar - [Click for QR Code] (1.26 MB, 192 views)
The Following User Says Thank You to kryz For This Useful Post: [ View ] Gift kryz Ad-Free
14th January 2017, 01:10 PM |#162  
Curtis1973's Avatar
Senior Member
Flag Greenville, S.C. USA
Thanks Meter: 645
 
More
Quote:
Originally Posted by kryz

Thank you for the logs are helping a lot

I see in your dmesg (without 1 param), that the exploit is loading the new sepolicy, these lines in dmesg confirms that:

Code:
<7>[  420.215067] SELinux: 2048 avtab hash slots, 12560 rules.
<7>[  420.227142] SELinux: 2048 avtab hash slots, 12560 rules.
<7>[  420.227199] SELinux:  1 users, 2 roles, 743 types, 0 bools, 1 sens, 1024 cats
<7>[  420.227212] SELinux:  86 classes, 12560 rules
The first load sepolicy of the device is this:

Code:
<7>[    2.747565] SELinux: 2048 avtab hash slots, 9071 rules.
<7>[    2.753025] SELinux: 2048 avtab hash slots, 9071 rules.
<7>[    2.753067] SELinux:  1 users, 2 roles, 743 types, 0 bools, 1 sens, 1024 cats
<7>[    2.753080] SELinux:  86 classes, 9071 rules
<7>[    2.755379] SELinux:  Completing initialization.
Also If you got this prompt is because the new selinux policy was loaded:
Code:
# Type run-as -s1 to get a shell
# Type run-as -s2 to execute su daemon
Well, now we know that we have injected code in init process and the shellcode was executed, but in your device the run-as binary has some restricted rule, maybe can't change to permissive, even when i added some rules that's the purpose of the shellcode.

We are close, just we need to adjust the selinux rules to give more permissions to run-as domain, i've updated the exploit ADB.

The exploit is basically the same, just ive added some more permissive rules to run-as and now install su in enforced mode that's not bad at all.

If you can do the same test, clean the /data/local/tmp/ foder and extract the new exploit.

After the exploit is finished and if you get this prompt:
Code:
# Type run-as -s1 to get a shell
# Type run-as -s2 to execute su daemon
Execute these commands:
Code:
run-as -s1
id
run-as -s2
Wait 5 seconds and turn on/off bluetooth and do a dump of dmesg:
Code:
dmesg > /data/local/tmp/dmesg.txt
And finally again attach the result files please.

I attach the new version here:

Going to give it a try now and will report back. Would have posted sooner but was helping another user find firmware for an obscure device he owns.
14th January 2017, 01:57 PM |#163  
Curtis1973's Avatar
Senior Member
Flag Greenville, S.C. USA
Thanks Meter: 645
 
More
@kryz

ok heres the dump. of note i did get a permission denied even though i had the pound symbol for root after running the -s1 and -s2 commands
Attached Files
File Type: zip Dump_A621BL.zip - [Click for QR Code] (487.2 KB, 20 views)
14th January 2017, 02:40 PM |#164  
OP Senior Member
Thanks Meter: 126
 
More
Quote:
Originally Posted by Curtis1973

@kryz

ok heres the dump. of note i did get a permission denied even though i had the pound symbol for root after running the -s1 and -s2 commands

The permission denied in the root prompt is because is a shell root with a init context, this context is very high but anyways have some restrictions, is normal to get "permission denied" listing files in /data/local/tmp/.

But with this shell you can do many things, anyways the non-restricted shell is su, that is given by run-as -s2

I see that all was all ok now, first you got a root shell with init context, can you confirm this executing this:

Code:
run-as -s1
id
And also i see in dmesg logs that the su.img was mounted correctly:

Code:
<6>[  306.342382] EXT4-fs (loop200): mounted filesystem with ordered data mode. Opts: 
<7>[  306.342416] SELinux: initialized (dev loop200, type ext4), uses xattr
So i guess the su binary is in:

Code:
/system/xbin/su
Have you tried to execute su after run-as -s2?
Code:
run-as -s2
Turn on/off bluettoth
wait 5 seconds
Code:
su
I think the exploit worked this time, at least all the logs show the su was installed, can you confirm that please?

I have to say that the su installation is temporal when you reboot the device the su binary in /system/xbin/su will disappear.

Now i don't need the files just the output of the commands, will be good if su is not working that you attach a dmesg dump after.

Best regards
The Following User Says Thank You to kryz For This Useful Post: [ View ] Gift kryz Ad-Free
14th January 2017, 02:51 PM |#165  
Curtis1973's Avatar
Senior Member
Flag Greenville, S.C. USA
Thanks Meter: 645
 
More
Will check and report back on the id check and wherher or not su is in fact in xbin. if all is well I intend to get familiar with everything I can do with this as I am not to familiar with performing root functions from shell
14th January 2017, 03:05 PM |#166  
OP Senior Member
Thanks Meter: 126
 
More
Quote:
Originally Posted by Curtis1973

Will check and report back on the id check and wherher or not su is in fact in xbin. if all is well I intend to get familiar with everything I can do with this as I am not to familiar with performing root functions from shell

I understand all this is a little bit confuse, because the exploit has 2 root methods:

run-as -s1
run-as -s2

The shell that you get with run-as -s1 is a root shell, with almost the most privileged context init, for normal users this root shell is useless.
But if you are researching how to break some kind of security in the Android is very useful even you can load new policies with this context, so this means bye bye Selinux->game over.

The second option run-as -s2 will execute a sudaemon, this means that you will have a normal rooted device, the only difference is that you don't have installed supersu.apk, and always you get su permission allowed.

If you install supersu.apk after the root, the device will have the same behavior that a permanent rooted device, asking you for su authorization when one apk or shell script requires it.

I think one of the next steps to do if you get root, is try if you can mount your system partition in write mode:
Code:
su
mount -o remount,rw /system
You can get a reboot at this time, because some phones have a protection, but if you don't get reboot probably you can make your root permanent.
14th January 2017, 03:17 PM |#167  
Curtis1973's Avatar
Senior Member
Flag Greenville, S.C. USA
Thanks Meter: 645
 
More
@kryz

ok heres my onscreen results although i will do a dmesg before exiting and upload it for review. su is in xbin. i can see it in root explorer as well. although it does appear that all of the bins that originally came with my device in xbin are no longer there. not sure of their use but i suspect a reboot will restore them. the result of running id should be in the command prompt. still getting a denied when running su.
Attached Thumbnails
Click image for larger version

Name:	Untitled-1.png
Views:	178
Size:	33.1 KB
ID:	4003164  
14th January 2017, 03:26 PM |#168  
Curtis1973's Avatar
Senior Member
Flag Greenville, S.C. USA
Thanks Meter: 645
 
More
@kryz

heres the dump from above comment
Attached Files
File Type: zip A621BL-Dump2.zip - [Click for QR Code] (476.4 KB, 28 views)
The Following User Says Thank You to Curtis1973 For This Useful Post: [ View ] Gift Curtis1973 Ad-Free
14th January 2017, 03:47 PM |#169  
OP Senior Member
Thanks Meter: 126
 
More
Quote:
Originally Posted by Curtis1973

@kryz

heres the dump from above comment

Well su is installed, can you try to execute su from the normal shell user?

I mean when you executed su you were in the shell obtained by run-as -s1 you have to exit of this shell:
Code:
exit
And the user to execute su have to be this:
Code:
id
uid=2000(shell) gid=2000(shell) groups=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) context=u:r:shell:s0
su
[email protected]:/ #
After to check if the daemon su is running can you search the process with this:

Code:
ps | grep -i su
Also see the permissions of the /system

Code:
ls -laZ /system
And see the permissions of /system/xbin/su

Code:
ls -laZ /system/xbin/su
Another check more to set to permissive:

Code:
run-as -s1
setenforce 0
Well to resume, your device is rooted, all was executed in kernel context that is the max high privileged context.

If you get still "Permission denied" executing su in a normal shell user, please just after execute su, make a dmesg please and post it.
The Following User Says Thank You to kryz For This Useful Post: [ View ] Gift kryz Ad-Free
14th January 2017, 03:52 PM |#170  
Curtis1973's Avatar
Senior Member
Flag Greenville, S.C. USA
Thanks Meter: 645
 
More
did not exit then start new shell and try su. Will do that. let you know shortly.
14th January 2017, 04:05 PM |#171  
OP Senior Member
Thanks Meter: 126
 
More
Quote:
Originally Posted by Curtis1973

did not exit then start new shell and try su. Will do that. let you know shortly.

I think im giving to you many checks, im coding a new exploit.sh that will do all those checks for you and also will write a log with all that i need.

Maybe I'm making you dizzy with all this commands
The Following 2 Users Say Thank You to kryz For This Useful Post: [ View ] Gift kryz Ad-Free
Post Reply Subscribe to Thread

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

Advanced Search
Display Modes