Permission denied though uid=root - Security Discussion

I'm trying to understand why I still get such "Permission denied" errors though I'm UID root.
I will describe my setup and particular error, but I think a proper explanation of what's happening may interest others.
I just need occasional root shell for reverse engineering sessions, and from what I know, a simple way to achieve this is to boot a modified initial ramdisk that contains a properly modified /default.prop, and/or a setuid shell, and/or some kind of su command.
I managed to successfully boot the device (Moto G) with my custom modified image using "fastboot boot custom_boot.img".
First I can verify it's actually "my initrd.img" that's in use:
Code:
[email protected]_umts:/ $ cat /default.prop
#
# ADDITIONAL_DEFAULT_PROPERTIES
#
[I]ro.secure=0[/I]
ro.allow.mock.location=0
[I]ro.debuggable=1[/I]
This does _not_ allow me to get root shell (with "adb shell"):
Code:
[email protected]_umts:/ $ id
[I]uid=2000(shell)[/I] gid=2000(shell) groups=1003(graphics),1004(input),1007(log),1009(mount),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
So, I added a setuid copy of /system/bin/sh to the initial ramdisk, at "/sbin/shell0".
Code:
[email protected]_umts:/ $ ls /sbin/shell0 -l
[I]-rwsr-xr-- root shell[/I] 157424 2014-07-14 16:08 shell0
[email protected]_umts:/ $ /sbin/shell0
# id
[I]uid=2000(shell)[/I] gid=2000(shell) groups=1003(graphics),1004(input),1007(log),1009(mount),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
# exit
[email protected]_umts:/ $ /sbin/shell0 +p
[email protected]_umts:/ # id
[I]uid=0(root)[/I] gid=2000(shell) groups=2000(shell) context=u:r:shell:s0
[email protected]_umts:/ # ls /data/
[I]opendir failed, Permission denied[/I]
Here, it appears that I have to use the "+p" flag to prevent the shell to immediately get back to the real user id (2000), despite the suid bit is set on /sbin/shell0.
But I don't understand I don't have the permission neither to open simple directories as /data, nor to read the interesting stuff in the /proc subsystem, though I'm uid=0 (root).
I've also tried adding to the initial ramdisk a simple su command, at /sbin/test_su, that does the setuid(0)/setgid(0)/execve(...) thing (snippets available at android.googlesource.com).
But though this properly keep the supplementary groups I had lost within the previous try above, I still can't read into /data:
Code:
[email protected]_umts:/ $ ls -l /sbin/test_su
[I]-rwsr-xr-- root shell[/I] 6316 2014-07-14 17:12 test_su
[email protected]_umts:/ $ test_su
[email protected]_umts:/ # id
[I]uid=0(root) gid=0(root)[/I] groups=1003(graphics),1004(input),1007(log),1009(mount),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
[email protected]_umts:/ # ls /data/
[I]opendir failed, Permission denied[/I]
From a un*x point of view, it seems weird to me that the shell still answers "opendir failed, Permission denied" while I'm uid/gid 0 (root).
I will continue to investigate, notably regarding SELinux which may enforce rules I'm not aware of, but would also greatly appreciate anyone who could put some light on this issue. At least for me it's an issue, as I don't understand what's happening.
Thanks.

t0kt0ckus said:
So, I added a setuid copy of /system/bin/sh to the initial ramdisk, at "/sbin/shell0".
Click to expand...
Click to collapse
Note that making a setuid shell executable might not be 100% reliable. When I've tried this with bash, it quickly realizes that getuid() != geteuid(), and drops the root permission.
I don't see this happening in your logs, but it's something to watch out for. Typically I've just used simple wrapper programs like the attached file to guarantee that the real/effective/saved UIDs are 0/0/0.
From a un*x point of view, it seems weird to me that the shell still answers "opendir failed, Permission denied" while I'm uid/gid 0 (root).
I will continue to investigate, notably regarding SELinux which may enforce rules I'm not aware of, but would also greatly appreciate anyone who could put some light on this issue. At least for me it's an issue, as I don't understand what's happening.
Click to expand...
Click to collapse
Chainfire is probably the best person to comment on Android SELinux matters. If you look through his old G+ posts you may be able to determine which restrictions apply to your security context.
Do you see any denials logged in dmesg? (Or is that inaccessible too?)
If there is a /selinux/enforce file, does it read back '0' or '1'?

Thank you for your answer.
cernekee said:
Note that making a setuid shell executable might not be 100% reliable. When I've tried this with bash, it quickly realizes that getuid() != geteuid(), and drops the root permission.
I don't see this happening in your logs, but it's something to watch out for. Typically I've just used simple wrapper programs like the attached file to guarantee that the real/effective/saved UIDs are 0/0/0.
Click to expand...
Click to collapse
I've looked at your attached source, the main difference with my own wrapper is that you fork the process, I've tried also, behavior is the same. But, after reading your comment, I've modified my setuid/execve code, to make it more verbose about the real/effective/saved UIDs (using getresuid()).
Code:
[email protected]_umts:/ $ test_su
Initial UIDs
ruid: 2000
[B]euid: 0[/B]
suid: 0
Setting UIDs ...
New UIDs
[B]ruid: 0
[/B]euid: 0
suid: 0
[email protected]_umts:/ # ls /data/
[I]opendir failed, Permission denied[/I]
1|[email protected]_umts:/ #
It clearly appears that, POSIX speaking, all go fine until the "Permission denied" error:
the effective uid is already 0 (just after the "adb shell" command), which is expected and documented, as the content of my /default.prop prevents the shell to revert its effective uid to its real one, which would then be 2000 (shell)
after the setuid(0) call, the real uid is successfully set to 0, as expected, because the suid bit is set AND we were already privileged (if not privileged, setuid() should only change the effective uid, as for "man 2 setuid")
after execve(..), the whole prompt, "[email protected]_umts:/ #", again confirms the real uid is 0 (root)
Chainfire is probably the best person to comment on Android SELinux matters. If you look through his old G+ posts you may be able to determine which restrictions apply to your security context.
Click to expand...
Click to collapse
Yes, I definitely need to dig into the SELinux/Android stuff (see bellow), and will try to find the Chainfire posts you propose.
Do you see any denials logged in dmesg? (Or is that inaccessible too?)
If there is a /selinux/enforce file, does it read back '0' or '1'?
Click to expand...
Click to collapse
Neither dmseg (which is accessible) nor logcat shows any related error or warning.
I haven't any /selinux/enforce file, but it clearly appears from information bellow that SELinux is activated and enforced:
Code:
[email protected]_umts:/ $ getenforce
[B]Enforcing[/B]
[email protected]_umts:/ # setenforce 0
setenforce: Could not set enforcing status: Permission denied
[email protected]_umts:/ $ cat seapp_contexts
isSystemServer=true domain=system
user=system domain=system_app type=system_data_file
user=bluetooth domain=bluetooth type=bluetooth_data_file
user=nfc domain=nfc type=nfc_data_file
user=radio domain=radio type=radio_data_file
user=_app domain=untrusted_app type=app_data_file levelFrom=none
user=_app seinfo=platform domain=platform_app type=platform_app_data_file
user=_app seinfo=shared domain=shared_app type=platform_app_data_file
user=_app seinfo=media domain=media_app type=platform_app_data_file
user=_app seinfo=release domain=release_app type=platform_app_data_file
user=_isolated domain=isolated_app
user=shell domain=shell type=shell_data_file
user=log domain=log_app type=system_data_file
user=sprint_extension domain=carrier_ext type=platform_app_data_file
user=smartcard domain=smartcard type=smartcard_data_file
I'm a noob at SELinux, and I may be wrong, but I think a rule policy could prevent a user, being it root, to achieve certain actions. I need to read stuff about this.
The initial boot image that I modify (just add my suid shell /sbin/test_su) is the 4.4.2 one from sbf, and I expand/repack it using standard un*x tools (gunzip,cpio,...) and abootimg. Anything wrong with that ?
I build the C files using:
Code:
$ echo $CC
<android-ndk>/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc --sysroot=<android-ndk>/platforms/android-19/arch-arm
$ $CC -o test_su test_su.c
Should I use particular flags for gcc, to make it produce SELinux aware object files ?
[EDIT: stupid question, answer is no]
Again, thanks for your help and ideas.

Just for information (for thus who are as dumb as I am): acquiring uid=(euid=suid=)0 is of little or no help within a user application, you're (obviously) still constrained by capabilities you can't acquire unless involving some kind of exploit.
To get a shell that's not restricted by the SE policies (on the 4.4 branch), the main way seems to have somewhat a system daemon capable to spawn /system/bin/sh with appropriate privileges/capabilities upon su client requests: so you again need an exploit.
So, for my understanding, starting with KitKat you can't anymore get a useful adb root shell through the uid=0 thing (traditional su), you have either to flash a custom rom or involve an exploit.

Related

[Q] Write, Execute Permissions

I have been googling far too long for an explanation of how to change the Read, Write, Execute options on individual system and data apps, when I remembed how fast someone usually answers my n00b questions here. It is not even clear to me what the differences are between the Write and Execute options. Can someone give me a link to a tutorial regarding this?
I did read the suggested threads, not helpful, and one I didn't understand about remounting the "entire /system partion to read-write".
thanks. d
To be more specific, I want to change the permission on certain system apps so I can uninstall them.
If your phone is rooted then you need a file manager that will remount the system partition as RW ( read write). Or you can use adb with your first command being adb remount.
Sent from my HTC Vision using XDA App
As ESKIMOn00b started to explain, the process of removing apps from the /system partition isn't a matter of individual file or folder permissions. Android secures the /system partition by preventing it from being written to under normal circumstances. If you have rooted your device then you have the ability to become the root user and run most if not all commands.
ADB provides a nice convenience command, 'adb remount', that will allow you to modify the /system partition. This command will only work if you have root user privileges but will unlock all of the apps for you to remove. Be careful though, you shouldn't just delete APK's directly out of /system/app as the package manager in Android might not keep up with your deletions. The best way to go about it (after remounting /system read/write) is to use the 'pm uninstall' command:
# pm uninstall com.myapp
To figure out the package names you can use 'pm list packages' and it will dump a huge list of all installed apps on the device. You'll need to hunt through and find the right ones. Most developers use obvious naming schemes such as Amazon's MP3 Store: com.amazon.mp3.
Hope this helps!
-ObsidianX
I have root and some recent experience w/the AndroidSDK. Using the SDK on my SonyEricsson phone:
c:\Users\dSpr> cd c:\AndroidSDK\tools
c:\AndroidSDK\tools>dir
{list}
c:\AndroidSDK\tools>adb devices
{0123456789ABCDEF device}
c:\AndroidSDK\tools>adb ls /system/app
{list}
c:\AndroidSDK\tools>adb shell
$ pm list packages
{list}
Note the shell command produces a $ instead of a #, but it still gives me a list.
But w/the $ and the command adb remount this:
$adb remount
adb remount
adb: permission denied.
If: tools>adb remount
This: remount failed; Operation not permitted
Same operation w/my QT7 and tools>adb shell produces a #. In fact, I don't even have to I don't have to use the adb remount command on my first uninstall, just
#rm /system/app/{app}.apk
#pm uninstall {package name}
I don't recall that I used the remount command between uninstalls-don't think I did or I would have noted it because I was keeping careful track of what I was doing. I can't test it because I have no apps on that device to uninstall.
Get the same result when using the terminal with the su command on the phone itself.
This is why I thought I had to change the Read/Write permissions.
What are you telling me that's not getting thru.
Thank you both very much.
d
to remount your system, you can try this
Code:
adb shell
Code:
su
Code:
mount -o remount,rw -t yaffs2 /dev/block/mtdblock4 /system
hesperides said:
to remount your system, you can try this
Code:
adb shell
Code:
su
Code:
mount -o remount,rw -t yaffs2 /dev/block/mtdblock4 /system
Click to expand...
Click to collapse
Nope. adb shell results in a $. su results in a su w/out the $ and after some (close to a minute) hesitation: Permission denied $
Debugging is on, as is mock locations. I am also having the exact same problem with my new enTourage Pocket eDGe, but it isn't that bothersome because it doesn't have a lot of garbage like the cell phone.
d

[HOWTO] Use pattern lock and device encryption

Normally, a pattern/gesture lock is not available when device encryption is activated.
But the lockscreen can be reactivated by changing the corresponding settings in /data/data/com.android.providers.settings/databases/settings.db to the values used for the pattern lock before enabling device encryption, namely resetting lockscreen.password_type to PASSWORD_QUALITY_SOMETHING.
If you don't run Android 4.0.4, you may verify that android.app.admin.DevicePolicyManager.PASSWORD_QUALITY_SOMETHING still corresponds to 0x10000.
Enter a root shell and execute:
Code:
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "UPDATE secure SET value='65536' WHERE name = 'lockscreen.password_type'"
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "UPDATE secure SET value='1' WHERE name = 'lockscreen.patterneverchosen'"
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "UPDATE secure SET value='1' WHERE name = 'lock_pattern_autolock'"
Generate a new gesture.key with the attached perl script (call it without arguments for help) and transfer it to the device:
Code:
mv gen-gesture.key.pl.txt gen-gesture.key.pl && chmod +x gen-gesture.key.pl
./gen-gesture.key.pl 01258 > gesture.key
adb push gesture.key /mnt/sdcard/Download/
adb shell
su -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
^C
Reboot the device.
This was tested on my Samsung Galaxy S3 with Android 4.0.4.
Thanks to robberknight who initiated a thread about PIN locks and encryption.
Thanks for the post!
I tried this today with my Samsung Galaxy Note 2 but it didn't work (Android 4.1)
The only thing I couldn't do (regarding to your how-to) was using the sqlite3 command from the shell, because there is no sqlite3 on my device (installing it with "SQLite Installer for root" didn't work either, I'm getting a "CANNOT LINK EXECUTABLE" error). So I just pulled the settings.db to my computer, editied it with an sqlite-manager and pushed it back. But I guess this shouldn't make any difference ...
I simply can't get rid of the password unlock screen, no matter what I enter in the sqlite database.
And I would be happy if I could even use a PIN instead of an alphanumeric password (which is the only option for encryption now)
By the way, what did you mean with "If you don't run Android 4.0.4, you may verify that android.app.admin.DevicePolicyManager.PASSWORD_QUA LITY_SOMETHING still corresponds to 0x10000."?
On my phone this constant is 65536
Right now this would be my lock-settings from the settings.db:
"103","lock_after_timeout_rollback","60000"
"35","lock_motion_tilt_to_unlock","0"
"107","lock_pattern_autolock","1"
"108","lock_pattern_visible_pattern","0"
"104","lock_screen_lock_after_timeout","60000"
"94","lock_screen_owner_info","..."
"95","lock_screen_owner_info_enabled","1"
"59","lock_screen_quick_note","1"
"36","lock_signature_visible_pattern","1"
"29","lockscreen.disabled","0"
"109","lockscreen.lockexchange.enable","0"
"34","lockscreen.options","enable_facelock"
"105","lockscreen.password_type","65536"
"106","lockscreen.patterneverchosen","1"
Found the solution on my own: Just delete the /data/system/locksettings.db (this one was empty on my device anyway)
After a restart the lock-keys of settings.db now finally work. I guess there is some caching in place and removing the locksettings.db forces Android to update the settings of the lock-screen.
Hello!
This sounds very interesting.
How to define the unlock pattern:
Does the perl-script create a pattern/gesture that corresponds to the digits you entered. In your example:
gen-gesture.key.pl 01258 > gesture.key - This makes your pattern 01258? (Since there is no dot inte 3x3 pattern matrix to represent a "0" then this cannot be correct.)
How do I define the pattern I want to use then? Is this done separately by going in to the settings later when the phone is booted? I don't dare to do this in fear of "locking" the device with a pattern/gesture that I don't know.
I hope to get your help here...
Thank you!
Thank you very much mod23! My phone is finally usable again
Works as described on Galaxy R with leaked ICS.
-Android Freak- said:
This makes your pattern 01258? (Since there is no dot inte 3x3 pattern matrix to represent a "0" then this cannot be correct.)
Click to expand...
Click to collapse
Was confused at first as well, but running the perl script without arguments tells us:
0 1 2
3 4 5
6 7 8
Afterwards, you won't be able to change it in the settings. I think you have to newly generate the gesture.key
Warning
I do not want to give lessons to anybody, but just to highlight how the unlock pattern protection is low, thwarting almost certainly the extra layer of protection that is supposed to be brought by Android full-phone encryption. Just consider the following remarks:
1) Contrary to a PIN code, pattern lock equivalent digits will be linked to each other (except if you are really really cunning). For example, if you start at digit 0, the following digits are to be 1,4 or 3. Thus decreasing dramatically the entropy of the underlying number.
2) You can't use the same digit two times. As an example, try the greek PHI symbol. The equivalent PIN code can't be 03452147, because 4 can't be used two times. The equivalent code must be simpler: 034521 7. You will agree that this greatly reduces the number of possible equivalent PIN codes you can achieve with pattern lock.
3) The protection mechanism offered by Android is way too weak in my opinion for such lock mechanism. After 3 failed attempts, your phone just ask you to wait for 30 sec. It does not shutdown.
4) But the killing argument is: you have grease under your fingers. Except if you systematically think to wipe the screen of your phone after unlocking your phone, the gesture will let a fingerprint corresponding to the gesture you will repeat several times per day. Try by yourself, and see how easy it is to see the lock pattern used with an oblique light source.
So, if I was to steal your phone to have access to your personal data you think secured by encryption, I would
1) Steal your phone when it is on
2) Realize that it is "protected" by lock pattern
2) Use an oblique light with the almost certainty that I will see the fingerprint of the pattern lock (except if you wipe systematically your screen, or you wash your hands always before unlocking your phone).
3) Try to draw the pattern in one direction.
4) Try it in the other direction if it fails. Almost sure to unlock the phone at this point (except if the pattern is really really intricate).
5) Once your phone is unlocked, I could do whatever I would want to with it. So no need to be the king of crackers.
I hope, after reading this, you will reconsider using pattern lock in parallel to encryption. In my opinion, it is a total nonsense. But it is my only personal opinion. Just judge by yourself.
Edit:
------
For me, the only way, both secure and practical, to secure your phone is by using a PIN code of at least 4 numbers (6 is better). PIN codes let fingerprints much harder to "interpret" than unlock pattern. Then use a handy tool like EncPassChanger to have a true complex password for decryption at boot time. And, if you are clearly paranoid, follow this great tip: http://forum.xda-developers.com/showpost.php?p=26730989&postcount=2.
And, something that people may forget, always double check that USB debugging is disabled.
lolo250612 said:
For me, the only way, both secure and practical, to secure your phone is by using a PIN code of at least 4 numbers (6 is better). PIN codes let fingerprints much harder to "interpret" that unlock pattern. Then use a handy tool like EncPassChanger to have a true complex password for decryption only at boot time. And, if you are clearly paranoid, follow this great tip: http://forum.xda-developers.com/showpost.php?p=26730989&postcount=2.
Click to expand...
Click to collapse
There is one big problem with your solution: The SD card. The SD card is encrypted with your PIN Code as well, which is stored in the same file as your screen-unlock-PIN code. I have no idea why the Google developers choose to use the same file for everything, but they did. So your solution is a good idea as long as you don't care about the security of your SD card.
On my phone (Lenvo A789, with ICS 4.0.4), the sdcards (both internal and external) are not encrypted at all. Only /data and other "system" partitions. You can view them with Terminal Emulator, by typing the mount command. The encrypted partitions correspond to /dev/block/dm-x (x is a number). Just to be clear, I mean "sdcards", the partition /mnt/sdcard or /mnt/sdcard2 as reported by Android and mounted as such.
Anyway. I am certainly not an expert in security. I am just trying to document myself to have an overview of the security mechanisms I use. But, if I am right, your encrypted partitions are not encrypted directly with your password or your PIN code. They are encrypted by a random key generated by Android when you start the encryption process. This master key is then encrypted itself at first by your PIN code (if you choose this option) before being saved in a file. That's what allows the user to change his password without having to re-encrypt everything. And I agree with you, this is a major security flaw, as a password with only digits can be cracked in a few µsec by a casual PC, if somebody has access physically to the content of your phone memory and this key file.
This is where EncPassChanger acts. It reencrypts your master key (not the data itself) with a password that can be complex as you don't type it everytime you unlock your phone.
So you have your PIN code to unlock your phone when it is on ( and only when it is on); it does not decrypt anything, decryption only occurs at boot time; it just gives you access to the UI and allows you to interact with your phone. And you have a strong password for the encryption of the data that lay physically on the memory (even when the phone is off), that allows Android to decrypt your master encryption key at boot, and therefore your data. And the PIN code cannot be used to decrypt your encryption master key any longer.
"Online" protection (phone lock) and "offline" protection (encryption of data lying "physically" on the memory) are really two different things. They become completely disconnected from each other once you use EncPassChanger to make the encryption/decryption password different from the initial PIN code. The only thing you have to be careful about, is that if you change your PIN code for whatever reasons, Android reencrypts the master encryption key with this new PIN code, droping the job done previously by EncPassChanger. So you have to use it again.
And the fact that, for a reason I don't see clearly, your sdcard would be encrypted as well as /data, does not change anything to that.
But I may be wrong, don't I ?
For more extensive details, see: http://nelenkov.blogspot.fr/2012/08/changing-androids-disk-encryption.html and http://source.android.com/tech/encryption/android_crypto_implementation.html
And even more details (Android encryption is in fact more or less Linux LUKS): http://www.markus-gattol.name/ws/dm-crypt_luks.html
Confirmed working on Nexus 10 and Nexus 4 with 4.2.2
Check for records in settings.db first!
If they don't exist, use this method.
On newer devices, the fields above do not exist in the settings.db file once encryption has been activated. The proper way to do this for a device is to confirm the settings are there, and if not, go through the below process (note the INSERTs instead of UPDATEs).
Create gesture.key using the Perl script and copy to SDCARD
Ensure device is unlocked and keep screen active while running the below code. If the device locks, you can get stuck on a black screen after removing /data/system/locksettings.db.
Run the below code.
Code:
su -
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "INSERT INTO secure (name, value) values ('lockscreen.password_type', '65536')"
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "INSERT INTO secure (name, value) values ('lockscreen.patterneverchosen', '1')"
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "INSERT INTO secure (name, value) values ('lock_pattern_autolock', '1')"
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "INSERT INTO secure (name, value) values ('lock_pattern_visible_pattern', '1')"
cat /mnt/sdcard/gesture.key > /data/system/gesture.key
rm /data/system/locksettings.*
Reboot
Lastly, combine with EncPassChanger to use a 20+ character encryption password at boot to ease your mind about brute force attempts.
Thanks,
Ben
Fmstrat said:
Confirmed working on Nexus 10 and Nexus 4 with 4.2.2
Check for records in settings.db first!
If they don't exist, use this method.
On newer devices, the fields above do not exist in the settings.db file once encryption has been activated. The proper way to do this for a device is to confirm the settings are there, and if not, go through the below process (note the INSERTs instead of UPDATEs).
Create gesture.key using the Perl script and copy to SDCARD
Ensure device is unlocked and keep screen active while running the below code. If the device locks, you can get stuck on a black screen after removing /data/system/locksettings.db.
Run the below code.
Code:
su -
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "INSERT INTO secure (name, value) values ('lockscreen.password_type', '65536')"
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "INSERT INTO secure (name, value) values ('lockscreen.patterneverchosen', '1')"
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "INSERT INTO secure (name, value) values ('lock_pattern_autolock', '1')"
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "INSERT INTO secure (name, value) values ('lock_pattern_visible_pattern', '1')"
cat /mnt/sdcard/gesture.key > /data/system/gesture.key
rm /data/system/locksettings.*
Reboot
Lastly, combine with EncPassChanger to use a 20+ character encryption password at boot to ease your mind about brute force attempts.
Thanks,
Ben
Click to expand...
Click to collapse
Thanks for the update. I want to give this a try on my Razr Maxx HD running 4.1.1, any idea if this will work? Also, in your info here, your code says:
Code:
('lockscreen.password_type', '65536')"
But isn't it impossible to use the same number twice? Not sure I understand this correctly if that is a true pattern lock sequence.
gadsden said:
Thanks for the update. I want to give this a try on my Razr Maxx HD running 4.1.1, any idea if this will work? Also, in your info here, your code says:
Code:
('lockscreen.password_type', '65536')"
But isn't it impossible to use the same number twice? Not sure I understand this correctly if that is a true pattern lock sequence.
Click to expand...
Click to collapse
I don't see any reason why it wouldn't work, but of course, no guarantees. As for the password_type, 65536 is a code saying "use the pattern lock", it is not the same as the string of numbers used with the python file to create your gesture.key file.
Thanks,
Ben
Fmstrat said:
Confirmed working on Nexus 10 and Nexus 4 with 4.2.2
Check for records in settings.db first!
If they don't exist, use this method.
On newer devices, the fields above do not exist in the settings.db file once encryption has been activated. The proper way to do this for a device is to confirm the settings are there, and if not, go through the below process (note the INSERTs instead of UPDATEs).
Create gesture.key using the Perl script and copy to SDCARD
Ensure device is unlocked and keep screen active while running the below code. If the device locks, you can get stuck on a black screen after removing /data/system/locksettings.db.
Run the below code.
Code:
su -
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "INSERT INTO secure (name, value) values ('lockscreen.password_type', '65536')"
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "INSERT INTO secure (name, value) values ('lockscreen.patterneverchosen', '1')"
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "INSERT INTO secure (name, value) values ('lock_pattern_autolock', '1')"
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "INSERT INTO secure (name, value) values ('lock_pattern_visible_pattern', '1')"
cat /mnt/sdcard/gesture.key > /data/system/gesture.key
rm /data/system/locksettings.*
Reboot
Lastly, combine with EncPassChanger to use a 20+ character encryption password at boot to ease your mind about brute force attempts.
Thanks,
Ben
Click to expand...
Click to collapse
Ok, I'm ready to do this, but I am afraid I have no idea what I'm doing! I couldn't find the settings.db like you said might happen. I tried running the perl script, but got permission denied when it tried to create /data/system/gesture.key. It did create the key and push it to the device, but then it stopped there.
After I verified it did push the gesture.key, I tried running the sqlite3 code in root shell. Some of the commands said adb does not recognize this command as an internal or external command. I have never ran commands like the ones shown here for sqlite3. My adb experience is pretty limited to following directions to root. I have done manual roots in adb, so I understand some basic commands, but this is out of my league! Can you help me a little bit to do this with some steps that are more beginner-ish? If you can help me out (PM is fine), I'll be glad to type out the instructions in an organized way for others to follow in the future. I really want to be able to set this up, any help would be greatly appreciated.
Ok, I think I need to stop messing with this now, been working on it all day! I ran all the sqlite3 commands you said, and got stuck at the cat command. It says no such file or directory. I think I did the perl script wrong and never got the gesture key done right. It pushed a file called gesture.key, but I don't know if it's right. I am not sure how to run the perl script, really. I have to get back to my job that I haven't done anything at today, yikes! Any help is appreciated.
Ok, I didn't quite understand the concept of how this worked yesterday, so I spent some more time on it today. I thought the perl script was to be ran from the PC. I didn't understand that I was supposed to be loosely following the steps in the other thread referenced here. Having no experience whatsoever with python, I didn't know what to do. Now, I understand the process, I am just having a little trouble. So far I have followed these instructions.
Fmstrat said:
Check for records in settings.db first!
If they don't exist, use this method.
Click to expand...
Click to collapse
I looked and could not find this, so I proceeded as described.
azoom1 said:
1) Load SLA4
2) Menu-View-Interpreters
3) Menu-Add
4) Select Python 2.6.2 - the SLA4 app will go get Python and intall it with the correct linking
5) Exit SLA4, then start Python and select Install, and when finished, exit Python
6) Put the pin_change.py file in the SLA4 "scripts" directory
7) Start SLA4
After that, when SLA4 is run you should see the script in the pick list. Upon selection SLA4 will pop-up an icon select-list. Pick the gear, which will run the script.
Click to expand...
Click to collapse
(I pasted this from the other thread, I did not use the script name here, I did use gen-gesture.key.py)
I installed SLA4 as described here and went to run the script with the gear icon. When I run it, all I get is a notification that gen-gesture.key.py was exited. Reading that I am supposed to generate the key, then copy it to the SD card, I thought maybe it did generate the gesture.key and I just have to find it, but I looked everywhere through files and couldn't find the file anywhere. I did locate a log file, gen-gesture.key.py.log, but it was blank, nothing to see.
Thinking there might have been a problem with the script, I tried to use the QR code here, but python said "Invalid QR code content". I double checked my script and I don't appear to have missed anything when I copied it, so I am lead to believe there is something else I am missing about how to use python. Only other thing I can think of that's wrong is the script extension, I used .py to run it in python, but wonder if it's supposed to be .pl since it's perl, or if I need .py to run it in python and the script runs as a perl script like that.
So, I am trying really hard to do this, I'm trying to learn on my own, but a little help would be really nice if anyone is able.
Bumped for help!
gadsden said:
Bumped for help!
Click to expand...
Click to collapse
You should not need to follow any directions in another thread. The Perl script is intended to be run on a PC, not on the phone, so there is no need for Perl to be installed. Running the script with out any arguments prints out the pattern of the android lock screen but instead of dots it has numbers. Run the script with the numbers after it as provided in the example in post number 1 to create the gesture.key file on your PC. Then copy that file over to the phone as described.
I'm also a little confused by your comment about not finding settings.db. I can think of no reason why the file would not exist, unless you mean that the records were not in the database file.
Thanks,
Ben
Fmstrat said:
You should not need to follow any directions in another thread. The Perl script is intended to be run on a PC, not on the phone, so there is no need for Perl to be installed. Running the script with out any arguments prints out the pattern of the android lock screen but instead of dots it has numbers. Run the script with the numbers after it as provided in the example in post number 1 to create the gesture.key file on your PC. Then copy that file over to the phone as described.
I'm also a little confused by your comment about not finding settings.db. I can think of no reason why the file would not exist, unless you mean that the records were not in the database file.
Thanks,
Ben
Click to expand...
Click to collapse
You said to check for records in settings.db first. When I search through my files, I can locate the directory data/data/com.android.providers.settings, but there is nothing inside of it. So, I did run the sqlite codes. I ran each line separately, and it said Error:too many options. So, I ran them all together and no errors came back. However, I still can't find anything in the directory.
Then to run the script, there is an attached file here called gen-gesture.key.pl.txt. Am I supposed to put that file into my platform tools folder and use the mv gen-gesture.key code to call the script? Or do I paste the text in the txt file into adb? I have tried running everything explained here in root shell in adb, I thought that was how I am supposed to do it, but I seem to be missing something. Sorry for the basic questions, but I'm still learning here.
Fmstrat said:
You should not need to follow any directions in another thread. The Perl script is intended to be run on a PC, not on the phone, so there is no need for Perl to be installed. Running the script with out any arguments prints out the pattern of the android lock screen but instead of dots it has numbers. Run the script with the numbers after it as provided in the example in post number 1 to create the gesture.key file on your PC. Then copy that file over to the phone as described.
I'm also a little confused by your comment about not finding settings.db. I can think of no reason why the file would not exist, unless you mean that the records were not in the database file.
Thanks,
Ben
Click to expand...
Click to collapse
Here's what I did so far.
1) Installed perl because it wasn't on my computer
2) changed permissions on /data/data/com.android.providers.settings/databases/settings.db to 777 so I could view the files in DDMS. Checked the settings.db and when I outputted it as a text file, all I got was a blank document
3) installed sqlite3 on my phone with sqlite installer
4) Entered root shell and entered
Code:
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "UPDATE secure SET value='65536' WHERE name = 'lockscreen.password_type'"
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "UPDATE secure SET value='1' WHERE name = 'lockscreen.patterneverchosen'"
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "UPDATE secure SET value='1' WHERE name = 'lock_pattern_autolock'"
I didn't know if I was supposed to run each line individually, or all at once, so I did it both ways. neither one had an error
5) Saved the gen-gesture.key.pl.txt file to my platform tools folder. Ran
Code:
perl gen.gesture.key.pl.txt
It came back with this
Code:
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>perl C:\Android\ad
t-bundle-windows-x86-20130219\sdk\platform-tools\gen-gesture.key.pl.txt
Usage: gen-gesture.key.pl <sequence>
With sequence as number sequence drawn on this keypad:
0 1 2
3 4 5
6 7 8
The generated binary output has to be put into: /data/system/gesture.key
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>
6) then entered this all at once
Code:
mv gen-gesture.key.pl.txt gen-gesture.key.pl && chmod +x gen-gesture.key.pl
./gen-gesture.key.pl 01258 > gesture.key
adb push gesture.key /mnt/sdcard/Download/
adb shell
su -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
^C
it came back with a bunch of errors and left me at root shell. I figured maybe I was supposed to run it from root shell anyway, so I entered it again. The very first command came back as "mv" is not a recognized internal or external command. I tried it a couple more times, but I'm not following what's supposed to happen here. I did do a reboot of the phone and when I did so, the lock settings were disabled. So, something is happening, but not everything that needs to. I I've probably spent over 12 hours on this over the past week and I am sure I'm doing it wrong. The OP doesn't describe in detail how a beginner needs to do this. I've learned as much as I can, but seeing as how I even got stuck on not knowing I needed to install perl, I'm positive that I'm missing more. The post just isn't beginner friendly. I'm trying hard to understand this but I'm becoming really discouraged here. Can someone provide a little more info here.
Here's the whole session if it helps
Code:
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>perl C:\Android\ad
t-bundle-windows-x86-20130219\sdk\platform-tools\gen-gesture.key.pl.txt
Usage: gen-gesture.key.pl <sequence>
With sequence as number sequence drawn on this keypad:
0 1 2
3 4 5
6 7 8
The generated binary output has to be put into: /data/system/gesture.key
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>mv gen-gesture.key
.pl.txt gen-gesture.key.pl && chmod +x gen-gesture.key.pl
'mv' is not recognized as an internal or external command,
operable program or batch file.
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>./gen-gesture.key.
pl 01258 > gesture.key
'.' is not recognized as an internal or external command,
operable program or batch file.
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>adb push gesture.k
ey /mnt/sdcard/Download/
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>adb shell
su -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
^Csu -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
[email protected]:/ $ su -
re.key > /data/system/gesture.key <
[email protected]:/ # mv gen-gesture.key.pl.txt gen-gesture.key.pl && chmod +x gen-g
esture.key.pl
./gen-gesture.key.pl 01258 > gesture.key
adb push gesture.key /mnt/sdcard/Download/
adb shell
su -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
n-gesture.key.pl && chmod +x gen-gesture.key.pl <
sh: ^Cmv: not found
adb push gesture.key /mnt/sdcard/Download/
adb shell
su -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
127|[email protected]:/ # ./gen-gesture.key.pl 01258 > gesture.key
sh: can't create gesture.key: Read-only file system
1|[email protected]:/ # adb push gesture.key /mnt/sdcard/Download/
* daemon not running. starting it now on port 5038 *
* daemon started successfully *
error: device not found
1|[email protected]:/ # adb shell
error: device not found
1|[email protected]:/ # su -
re.key > /data/system/gesture.key <
[email protected]:/ #
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>mv gen-gesture.key
.pl.txt gen-gesture.key.pl && chmod +x gen-gesture.key.pl
'mv' is not recognized as an internal or external command,
operable program or batch file.
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>./gen-gesture.key.
pl 01258 > gesture.key
'.' is not recognized as an internal or external command,
operable program or batch file.
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>adb push gesture.k
ey /mnt/sdcard/Download/
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>adb shell
su -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
^Csu -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
[email protected]:/ $ su -
re.key > /data/system/gesture.key <
[email protected]:/ # exit
^Cexit
sh: ^Cexit: not found
127|[email protected]:/ # exit
exit
127|[email protected]:/ $ exit
exit
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>mv gen-gesture.key
.pl.txt gen-gesture.key.pl && chmod +x gen-gesture.key.pl
'mv' is not recognized as an internal or external command,
operable program or batch file.
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>./gen-gesture.key.
pl 01258 > gesture.key
'.' is not recognized as an internal or external command,
operable program or batch file.
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>adb push gesture.k
ey /mnt/sdcard/Download/
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>adb shell
su -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
^Csu -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
[email protected]:/ $ su -
re.key > /data/system/gesture.key <
[email protected]:/ #
Been working on this for a whole week now, just wondering if I'm even on the right track here?
gadsden said:
Here's what I did so far.
1) Installed perl because it wasn't on my computer
2) changed permissions on /data/data/com.android.providers.settings/databases/settings.db to 777 so I could view the files in DDMS. Checked the settings.db and when I outputted it as a text file, all I got was a blank document
3) installed sqlite3 on my phone with sqlite installer
4) Entered root shell and entered
Code:
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "UPDATE secure SET value='65536' WHERE name = 'lockscreen.password_type'"
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "UPDATE secure SET value='1' WHERE name = 'lockscreen.patterneverchosen'"
sqlite3 -batch /data/data/com.android.providers.settings/databases/settings.db "UPDATE secure SET value='1' WHERE name = 'lock_pattern_autolock'"
I didn't know if I was supposed to run each line individually, or all at once, so I did it both ways. neither one had an error
5) Saved the gen-gesture.key.pl.txt file to my platform tools folder. Ran
Code:
perl gen.gesture.key.pl.txt
It came back with this
Code:
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>perl C:\Android\ad
t-bundle-windows-x86-20130219\sdk\platform-tools\gen-gesture.key.pl.txt
Usage: gen-gesture.key.pl <sequence>
With sequence as number sequence drawn on this keypad:
0 1 2
3 4 5
6 7 8
The generated binary output has to be put into: /data/system/gesture.key
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>
6) then entered this all at once
Code:
mv gen-gesture.key.pl.txt gen-gesture.key.pl && chmod +x gen-gesture.key.pl
./gen-gesture.key.pl 01258 > gesture.key
adb push gesture.key /mnt/sdcard/Download/
adb shell
su -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
^C
it came back with a bunch of errors and left me at root shell. I figured maybe I was supposed to run it from root shell anyway, so I entered it again. The very first command came back as "mv" is not a recognized internal or external command. I tried it a couple more times, but I'm not following what's supposed to happen here. I did do a reboot of the phone and when I did so, the lock settings were disabled. So, something is happening, but not everything that needs to. I I've probably spent over 12 hours on this over the past week and I am sure I'm doing it wrong. The OP doesn't describe in detail how a beginner needs to do this. I've learned as much as I can, but seeing as how I even got stuck on not knowing I needed to install perl, I'm positive that I'm missing more. The post just isn't beginner friendly. I'm trying hard to understand this but I'm becoming really discouraged here. Can someone provide a little more info here.
Here's the whole session if it helps
Code:
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>perl C:\Android\ad
t-bundle-windows-x86-20130219\sdk\platform-tools\gen-gesture.key.pl.txt
Usage: gen-gesture.key.pl <sequence>
With sequence as number sequence drawn on this keypad:
0 1 2
3 4 5
6 7 8
The generated binary output has to be put into: /data/system/gesture.key
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>mv gen-gesture.key
.pl.txt gen-gesture.key.pl && chmod +x gen-gesture.key.pl
'mv' is not recognized as an internal or external command,
operable program or batch file.
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>./gen-gesture.key.
pl 01258 > gesture.key
'.' is not recognized as an internal or external command,
operable program or batch file.
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>adb push gesture.k
ey /mnt/sdcard/Download/
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>adb shell
su -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
^Csu -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
[email protected]:/ $ su -
re.key > /data/system/gesture.key <
[email protected]:/ # mv gen-gesture.key.pl.txt gen-gesture.key.pl && chmod +x gen-g
esture.key.pl
./gen-gesture.key.pl 01258 > gesture.key
adb push gesture.key /mnt/sdcard/Download/
adb shell
su -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
n-gesture.key.pl && chmod +x gen-gesture.key.pl <
sh: ^Cmv: not found
adb push gesture.key /mnt/sdcard/Download/
adb shell
su -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
127|[email protected]:/ # ./gen-gesture.key.pl 01258 > gesture.key
sh: can't create gesture.key: Read-only file system
1|[email protected]:/ # adb push gesture.key /mnt/sdcard/Download/
* daemon not running. starting it now on port 5038 *
* daemon started successfully *
error: device not found
1|[email protected]:/ # adb shell
error: device not found
1|[email protected]:/ # su -
re.key > /data/system/gesture.key <
[email protected]:/ #
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>mv gen-gesture.key
.pl.txt gen-gesture.key.pl && chmod +x gen-gesture.key.pl
'mv' is not recognized as an internal or external command,
operable program or batch file.
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>./gen-gesture.key.
pl 01258 > gesture.key
'.' is not recognized as an internal or external command,
operable program or batch file.
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>adb push gesture.k
ey /mnt/sdcard/Download/
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>adb shell
su -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
^Csu -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
[email protected]:/ $ su -
re.key > /data/system/gesture.key <
[email protected]:/ # exit
^Cexit
sh: ^Cexit: not found
127|[email protected]:/ # exit
exit
127|[email protected]:/ $ exit
exit
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>mv gen-gesture.key
.pl.txt gen-gesture.key.pl && chmod +x gen-gesture.key.pl
'mv' is not recognized as an internal or external command,
operable program or batch file.
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>./gen-gesture.key.
pl 01258 > gesture.key
'.' is not recognized as an internal or external command,
operable program or batch file.
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>adb push gesture.k
ey /mnt/sdcard/Download/
C:\Android\adt-bundle-windows-x86-20130219\sdk\platform-tools>adb shell
su -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
^Csu -
cat /mnt/sdcard/Download/gesture.key > /data/system/gesture.key
[email protected]:/ $ su -
re.key > /data/system/gesture.key <
[email protected]:/ #
Click to expand...
Click to collapse
thx

Terminal emulator size after upgrade Android 4.3

Hi,
I'm having an issue with all terminal emulators (Android Terminal Emulator, ConnectBot, ...) after upgrading my Nexus 10 from Android 4.2.2 to 4.3.
The terminal is not recognizing the actual size of the screen and it is fixed to 80 columns and 20 rows. I can temporarily fix it typing "stty cols 180 rows 35", but those values depend on the screen rotation, font size, etc.
This is really weird, and I wasn't having this issue before the upgrade.
Anyone else has this problem or know how to solve it?
Thanks!
Ok, i've been doing some tests.
It seems to be a 'su' bug, it is not receiving the SIGWINCH signal.
If I type without su:
trap 'echo sigwinch' SIGWINCH
It is executed every time I rotate the tablet or popup the keyboard.
But, under su, the same command is not working.
It may be a permission issue.
Any ideas?
I can confirm having the same issue with my Nexus 10 and android 4.3. As soon as I run su - from the terminal (Android Terminal Emulator) the lines start wrapping at 80 characters.
Hi,
i've been working on this trying to find a solution.
Here is what I saw:
Every time I enter su or enter chroot (i have a chrooted debian), the tty number is changed to another one. That isn't the usual tty behavior!
So, if the normal user is in /dev/pts/0 , root could be in /dev/pts/1 and chroot in /dev/pts/2.
If I rotate the screen /dev/pts/0 cols and rows are changed even if I am as root, I can verify that by typing:
stty -F /dev/pts/0 -a
But, if I am at /dev/pts/1 i'm not receiving that SIGWINCH signal. In common linux distributions, that is not happening as pts number doesn't change.
Here is my (not so perfect) solution for the chrooted debian:
Write a fix_stty.sh script as root:
#!/bin/bash
sttypath=/bin
tty0=$(ls --sort time /dev/pts/ | head -n 1 | awk '{print $1}')
stty0=$($sttypath/stty -F /dev/pts/$tty0 -a | head -n1)
rows=$(echo $stty0 | sed -e 's:.*rows\ \([0-9]\+\).*:\1:g')
cols=$(echo $stty0 | sed -e 's:.*columns\ \([0-9]\+\).*:\1:g')
$sttypath/stty rows $rows cols $cols
Save it in /usr/local/bin
Make it executable:
chmod +rx /usr/local/bin/fix_stty.sh
Add to ~/.bashrc this line:
trap '/usr/local/bin/fix_stty.sh' DEBUG
Or if you use non-root users:
trap 'sudo /usr/local/bin/fix_stty.sh' DEBUG
And add to sudoers file:
%sudo ALL = (ALL) NOPASSWD: /usr/local/bin/fix_stty.sh
Logout and login again, and it will fix the rows and columns before each command.
----
For su, outside the chrooted linux write a script fix_stty.sh:
sttypath=/system/xbin
tty0=$(/system/xbin/busybox ls -t /dev/pts | head -n1)
stty0=$($sttypath/stty -F /dev/pts/$tty0 -a | head -n1)
rows=$(echo $stty0 | sed -e 's:.*rows\ \([0-9]\+\).*:\1:g')
cols=$(echo $stty0 | sed -e 's:.*columns\ \([0-9]\+\).*:\1:g')
$sttypath/stty rows $rows cols $cols
Save it to /system/xbin
(You should remount /system as rw: mount --remount -orw /system)
Then, make it exec:
chmod 755 /system/xbin/fix_stty.sh
And, finally you should type at each su login:
trap '/system/xbin/fin_stty.sh' SIGINT
(i don't know why DEBUG isn't here)
So you have to press Ctrl+C to fix it.
----
Alternatively, you can write an infinite loop or a simple daemon to fix it, but i don't like daemons on my tablet.
If anyone has a better solutions, please post it.
Hi all. I've been mulling over this problem as well. I believe the issue is because in 4.3, SuperSU now uses a "proxy", where commands are sent form the process which called su to daemonsu, which is launched at system startup. Chainfire explains a bit more in his G+ posts the reasons for doing this, but I think the key here is that root processes are now launched on a different tty, because they are launched by a different process (namely, daemonsu). Starting a root shell (whether system shell or ubuntu/debian chroot) now results in the creation of three pts devices, as opposed to the usual one. However, other shells not launched locally are fine. For example, starting the SSH server in my chroot and logging in via SSH is always fine.
I'm still trying to figure out a permanent solution to this problem. I still don't have a full understanding of the problem as I'm still trying to wrap my head around how Linux handles terminals and TTYs. I do have a few ideas floating around my head, though:
Change daemonsu and su to support full termios/line-discipline/whatever-we-need through the "pts bridge" that he is using
Create TTY(pts) pairs on demand, and have a modified Terminal Emulator connect to those directly when we want a shell
Have a background-ed process in the original terminal catch SIGWINCH and pass it to the root terminal
Still quite a bit a figure out though. I may just go through Terminal Emulator's source code to see how it work to get a better picture too. But that's gonna take time. I've also created a little native utility which creates two pts pseudo-TTYs and shuffles data between them. I'm still experimenting. Will post more as I learn more.
Just to let you all know that I've got a system working for myself: http://blog.tan-ce.com/android-root-shell/
The way I'm doing it uses a daemon, much like the su daemons ChainFire and Koush are using. The benefit of doing it this way is that I'm not confined by the application container, which is good for security when used by applications, but is annoying when you are using the terminal itself. I remember having to do hacks with adb servers to get around those.
But if you don't want a daemon, you can still set one up manually, just look at the last section of the README on how to use pts-wrap and pts-exec.
I gave this a try.
First, I've noticed that pts-wrap and pts-exec symbolic links were missing.
And I don't think the line '/system/etc/install-recovery-2.sh' in pts-daemon-start file is needed at all.
I'm using ChainFire SuperSU and pts-shell is not working as expected or catching SIGWINCH signals. I just don't see any difference with the standard shell. Maybe I misunderstood how it works.
alf_tux said:
I gave this a try.
First, I've noticed that pts-wrap and pts-exec symbolic links were missing.
And I don't think the line '/system/etc/install-recovery-2.sh' in pts-daemon-start file is needed at all.
Click to expand...
Click to collapse
My mistake, I forgot to create the symlinks for those two.
install-recovery-2.sh is an idea I took from CharinFire's SuperSU. Basically, it seems as if people are using install-recovery.sh to install startup scripts, and having the script try to call install-recovery-2.sh allows you to chain recovery scripts. For example, if you install this on a system with SuperSU, it will be installed as install-recovery-2.sh. If the system doesn't already have an install-recovery.sh, it'll install itself as install-recovery.sh.
Anyway, I've fixed and uploaded a new zip.
alf_tux said:
I'm using ChainFire SuperSU and pts-shell is not working as expected or catching SIGWINCH signals. I just don't see any difference with the standard shell. Maybe I misunderstood how it works.
Click to expand...
Click to collapse
Are you running pts-shell from a regular (non-root) shell, or from a root shell? It should be run from a non-root shell. (It will give you a root shell once it runs.) Only pts-passwd and pts-daemon is meant to be run as root.
tan-ce said:
Are you running pts-shell from a regular (non-root) shell, or from a root shell? It should be run from a non-root shell. (It will give you a root shell once it runs.) Only pts-passwd and pts-daemon is meant to be run as root.
Click to expand...
Click to collapse
Yes, here is my the terminal output:
[email protected]:/ $ ps | grep pts
root 136 1 760 180 ffffffff 00000000 S /system/xbin/pts-daemon
[email protected]:/ $ pts-shell /system/bin/sh
(pts-shell) /system/bin/sh
Could not connect to socket: Permission denied
255|[email protected]:/ $ su pts-shell /system/bin/sh
[email protected]:/ #
As you see, I can only run pts-shell as root.
alf_tux said:
Yes, here is my the terminal output:
[email protected]:/ $ ps | grep pts
root 136 1 760 180 ffffffff 00000000 S /system/xbin/pts-daemon
[email protected]:/ $ pts-shell /system/bin/sh
(pts-shell) /system/bin/sh
Could not connect to socket: Permission denied
255|[email protected]:/ $ su pts-shell /system/bin/sh
[email protected]:/ #
As you see, I can only run pts-shell as root.
Click to expand...
Click to collapse
Sorry, I realized that the correct command should be:
[email protected]:/ $ su -c pts-shell /system/bin/sh
(pts-shell) /system/bin/sh
(pts-shell) Enter your password:
[email protected]:/ #
Anyway I can only run this as root.
Oh yeah, I found the bug. Sorry, my bad. I've fixed it and uploaded a new copy of the update ZIP, but you don't have to upgrade if you don't want to. Running
Code:
# chmod 0701 /data/pts
should be sufficient to fix the problem. Then you should be able to run pts-shell from a regular (non-root) shell.
tan-ce said:
Oh yeah, I found the bug. Sorry, my bad. I've fixed it and uploaded a new copy of the update ZIP, but you don't have to upgrade if you don't want to. Running
Code:
# chmod 0701 /data/pts
should be sufficient to fix the problem. Then you should be able to run pts-shell from a regular (non-root) shell.
Click to expand...
Click to collapse
I don't think that was the the bug:
[email protected]:/ $ su
[email protected]:/ # ls -l /data/pts
-rw------- root root 61 2013-08-28 19:09 passwd
srw-rw-rw- root root 2013-08-28 18:59 pts
[email protected]:/ # chmod 0701 /data/pts
[email protected]:/ # ls -l /data/pts
-rw------- root root 61 2013-08-28 19:09 passwd
srw-rw-rw- root root 2013-08-28 18:59 pts
[email protected]:/ # ^D
[email protected]:/ $ pts-shell /system/bin/sh
(pts-shell) /system/bin/sh
Could not connect to socket: Connection refused
255|[email protected]:/ $
I have also tried:
chmod 0701 /data/pts/pts
And
chmod 0701 /data/pts/*
I'm getting the same connection refused. Maybe you can send me a debug version, I can run it just to find what is going on.
alf_tux said:
I'm getting the same connection refused. Maybe you can send me a debug version, I can run it just to find what is going on.
Click to expand...
Click to collapse
That's strange. Could you show me the output of ls -la? (The "a" is needed to see the permissions for /data and /data/pts itself)
After that, perhaps you could try "chmod 0711 /data/pts"
There isn't a debug version. The error message comes from the part of the code which tries to open a unix socket located at /data/pts/pts. For this to work, /data and /data/pts must have the execute bit set, and /data/pts/pts needs to have the readable and writable bit set for you. Otherwise you'll get a "permission denied".
Perhaps it might be easier for me to just move the socket to /dev like what koush does for Superuser... it's possible the permissions on my /data is non-standard.
On a side note, I'm also currently trying to contribute to koush's Superuser project to fix terminal handling. With any luck, I (or someone else?) will succeed and we won't really need my pts-multi tools anymore.
tan-ce said:
That's strange. Could you show me the output of ls -la? (The "a" is needed to see the permissions for /data and /data/pts itself)
After that, perhaps you could try "chmod 0711 /data/pts"
There isn't a debug version. The error message comes from the part of the code which tries to open a unix socket located at /data/pts/pts. For this to work, /data and /data/pts must have the execute bit set, and /data/pts/pts needs to have the readable and writable bit set for you. Otherwise you'll get a "permission denied".
Perhaps it might be easier for me to just move the socket to /dev like what koush does for Superuser... it's possible the permissions on my /data is non-standard.
On a side note, I'm also currently trying to contribute to koush's Superuser project to fix terminal handling. With any luck, I (or someone else?) will succeed and we won't really need my pts-multi tools anymore.
Click to expand...
Click to collapse
Yes, I agree that fixing su would be better.
I don't have my tablet right know, i don't remember well /data /data/pts and /data/pts/pts read and exec bits. I will see better whan I have my tablet with me.
Here is the output:
/data:
drwxrwx--x system system 2013-08-28 18:59 data
/data/pts:
drwxr-xr-x root root 2013-08-28 19:06 pts
[email protected]:/ $ ls -la /data/pts
-rwxrwxrwx root root 61 2013-08-28 19:09 passwd
srwxrwxrwx root root 2013-08-28 18:59 pts
[email protected]:/ $ pts-shell /system/bin/sh
(pts-shell) /system/bin/sh
Could not connect to socket: Connection refused
255|[email protected]:/ $
I suppose it isn't a permission problem.
alf_tux said:
I suppose it isn't a permission problem.
Click to expand...
Click to collapse
You're probably right, my Nexus 10 could be a bit different because of the semi-botched update I went through. Well, good news on two fronts: First, I updated pts-multi (latest update zip here) to use /dev/pts-daemon as the socket instead of /data... It works on mine, and I think it should work on yours, because Superuser puts its socket there too.
Second, I finished some modifications to the su binary in Superuser (source code here), and I've submitted a pull request to Koush. He says he'll do a code review of my changes, and we'll see how it goes.
tan-ce said:
You're probably right, my Nexus 10 could be a bit different because of the semi-botched update I went through. Well, good news on two fronts: First, I updated pts-multi (latest update zip here) to use /dev/pts-daemon as the socket instead of /data... It works on mine, and I think it should work on yours, because Superuser puts its socket there too.
Second, I finished some modifications to the su binary in Superuser (source code here), and I've submitted a pull request to Koush. He says he'll do a code review of my changes, and we'll see how it goes.
Click to expand...
Click to collapse
T/hanks! I tried your new update and I think it's working!
Can you add a passwordless option? Or if password is blank just don't ask for it
alf_tux said:
T/hanks! I tried your new update and I think it's working!
Can you add a passwordless option? Or if password is blank just don't ask for it
Click to expand...
Click to collapse
Ok, but I took the easiest way out... If you set the environment variable PTS_AUTH, pts-shell will read the password from there instead of prompting you for it. So, if you're writing a script to spawn a root shell, do:
Code:
#!/system/bin/sh
export PTS_AUTH="your password here"
pts-shell /system/bin/sh
The latest update zip is here.
Thanks a lot tan-ce!!
It's working just as I expected!
Glad to hear it.

[SOLVED] sm-t330 LP 5.1.1 working out supersu

This NOT a Q&A thread. Only people working out the problem are welcome.
okay , so as of flashing even supersu beta version BETA-SuperSU-v2.49 this is the issue i'm guessing for our device
for reference the firmware release api in question is Android 5.1 , API Level 22
Code:
[email protected]:/# adb logcat -d | grep F/
F/appproc ( 305): Error changing dalvik-cache ownership : Permission denied
F/libc ( 305): Fatal signal 6 (SIGABRT), code -6 in tid 305 (app_process32_o)
F/appproc ( 1026): Error changing dalvik-cache ownership : Permission denied
F/libc ( 1026): Fatal signal 6 (SIGABRT), code -6 in tid 1026 (app_process32_o)
F/appproc ( 1389): Error changing dalvik-cache ownership : Permission denied
F/libc ( 1389): Fatal signal 6 (SIGABRT), code -6 in tid 1389 (app_process32_o)
F/appproc ( 1758): Error changing dalvik-cache ownership : Permission denied
F/libc ( 1758): Fatal signal 6 (SIGABRT), code -6 in tid 1758 (app_process32_o)
F/appproc ( 2123): Error changing dalvik-cache ownership : Permission denied
F/libc ( 2123): Fatal signal 6 (SIGABRT), code -6 in tid 2123 (app_process32_o)
F/appproc ( 2482): Error changing dalvik-cache ownership : Permission denied
F/libc ( 2482): Fatal signal 6 (SIGABRT), code -6 in tid 2482 (app_process32_o)
[email protected]:/#
after looking at the script i ran and got this
Code:
[email protected]:/# adb shell ls -al /system/bin/app*
[COLOR="Red"]lrwxrwxrwx root root 2014-03-07 10:19 app_process -> /system/xbin/daemonsu
lrwxrwxrwx root root 2014-03-07 10:19 app_process32 -> /system/xbin/daemonsu
-rwxr-xr-x root shell 13588 2015-07-02 14:29 app_process32_original[/COLOR]
-rwxr-xr-x root shell 13588 2014-03-07 10:19 app_process_init
-rwxr-xr-x root shell 57688 2015-07-02 14:29 applypatch
-rwxr-xr-x root shell 213 2015-07-02 14:29 appops
-rwxr-xr-x root shell 215 2015-07-02 14:29 appwidget
undoing that with this
Code:
rm -f app_process app_process32
ln -sf /system/bin/app_process32_original /system/bin/app_process
"resolved" the "error" so if you flashed supersu thinking YAY ROOT ! and ended up with what you got you need to run what i did to
regain what you had.
SO, linking daemonsu in a different way is probably the thing but, how?
so far selinux is still alive i am trying out a patch @RunasSudo suggested here
http://forum.xda-developers.com/goo...orrect-to-compile-permissive-selinux-t3074761
also i am trying to figure out how app_process works
@thisisapoorusernamechoice
sorry for hijacking your thread. m
Okay, so with a modified adbd in /sbin i achieve a root prompt through adb
Note - at this point i do have full control over the system. yay!
but at the cost of blank display and no functions of hardware input [no touch hard buttons] awww (frowny face)
interesting note, the stock adbd has root access/privelege when executing adb reboot recovery.
does anyone have a lead on how to bind a block device to a tcp port ?
something like this, but that works, and as a service maybe?
cat /dev/whatever | nc -l 2345
okay if i'm seeing this right...,
Code:
F/appproc ( 305): Error changing dalvik-cache ownership : [COLOR="Red"]Permission denied[/COLOR]
F/libc ( 305): Fatal signal 6 (SIGABRT), code -6 in [COLOR="Red"]tid[/COLOR] 305 (app_process32_o)
my gues would be selinux denial based on wrong/incorrect type id
from file contexts
Code:
/system/bin/app_process32 u:object_r:[COLOR="Red"]zygote_exec[/COLOR]:s0
from zygote.te
Code:
# zygote
[COLOR="Red"]type[/COLOR] zygote, domain;
type [COLOR="Red"]zygote_exec[/COLOR], exec_type, file_type;
soooooo when the shuffling around of app_process* happens and /system/xbin/daemonsu is linked to /system/bin/app_process
should daemonsu instead of being [from supersu installer script]
Code:
/system/xbin/daemonsu 0755 u:object_r:system_file:s0
be
Code:
/system/xbin/daemonsu 0755 u:object_r:zygote_exec:s0
?
i don't think it sepolicy version 26, same as sm-t530nu, i'm also using the sm-t53nu's LL kernel source release for my sm-t330nu LP kernel build, so it's not the knox ****ery in the kernel source. so it's the actual policy itself ?
I'm going to do an experiment by flashing/writing the system.img.ext4 from the sm-t530nu LP release with a modified boot.img
to the sm-t330nu [post LP release flash]
If it works it would effectively be a downgrade to 5.0.X
This has worked with @sub77 's LP builds for sm-t530nu to "port" them to sm-t330nu soooo
more to come ?
okay, sooooo
now that my sm-t330nu has the official LP release installed, i CAN flash the system.img from the official sm-t530nu to it and boot successfully,
so i was right about the tied to firmware thing.
Now after a few different tests i am unable to "downgrade" my boot.img to match the sm-t530nu release version wise, policy and all
and remain at android 5.1.1 NNNYYYAAAAAHHHHHHHHH ! [WHEW okay , glad to get that out.. ]
SO, i flashed supersu to see what would happen and got the same result as before BUT, totally sepolicy contexts
Without restoring system or doing the meatball surgery from the previous post, i instead manually changed the policy context
of /system/xbin/daemonsu through adb in recovery
[note- you must enbale dev-options--->debugging
Code:
adb reboot recovery
adb shell mount /system
adb shell
chcon u:object_r:zygote_exec:s0 /system/xbin/daemonsu
chattr +i /system/xbin/daemonsu
reboot
SHINY ! no root. but boots
Code:
[email protected]:/system/bin/.ext $ ls -Z /system/xbin/daemonsu
-rwxr-xr-x root root u:object_r:zygote_exec:s0 daemonsu
Okay so now we need to know proper context for
/system/xbin/su
/system/bin/.ext/.su
hmmmm... i am going outside to play.
Nature sucks, the resolution is terrible ! xD
okay android 5.1.1 samsung policy context for system libraries is
Code:
u:object_r:system_library_file:s0
okay so far nutz..,
i found this for setool utility [setools-android-sepolicy-inject] project by @Mikos
http://forum.xda-developers.com/android/software/setools-android-sepolicy-inject-t2977563
i've forked his sources https://github.com/xmikos/setools-android
adjusted for api, and will try this method.
Android NDK
wget https://dl.google.com/android/ndk/android-ndk-r10e-linux-x86.bin
m
okay,
got Miko's toolkit compiled, this is the output of seinfo
Code:
\[email protected]:/ $ seinfo
Statistics for policy file: /sepolicy
Policy Version & Type: v.26 (binary, mls)
Classes: 86 Permissions: 271
Common classes: 5
Sensitivities: 1 Categories: 1024
Types: 1169 Attributes: 162
Users: 1 Roles: 2
Booleans: 0 Cond. Expr.: 0
Allow: 14802 Neverallow: 0
Auditallow: 0 Dontaudit: 401
Type_trans: 458 Type_change: 0
Type_member: 0 Role allow: 0
Role_trans: 0 Range_trans: 0
Constraints: 59 Validatetrans: 0
Initial SIDs: 27 Fs_use: 19
Genfscon: 43 Portcon: 0
Netifcon: 0 Nodecon: 0
Permissives: 0 Polcap: 2
[email protected]:/ $
i'm looking for someone who can run me through how sepolicy injection works specifically.
I don't know enough to interpret a generic example.
what i can understand right now is daemonsu disguised as app_process cannot access/change what it needs to in dalvik-cache due to incorrect/wrong -tid if that's the right way to say it.
this again
Code:
F/appproc ( 305): Error changing dalvik-cache ownership : Permission denied
F/libc ( 305): Fatal signal 6 (SIGABRT), code -6 in tid 305 (app_process32_o)
Mikos said the following as to command line syntax
Mikos said:
Hello, the syntax is simple, if you want comparison with supolicy, here is one example (taken from my SnooperStopper app):
Code:
supolicy --live 'allow vdc init fifo_file {read write getattr}'
is equivalent to:
Code:
sepolicy-inject -s vdc -t init -c fifo_file -p read,write,getattr -l
Click to expand...
Click to collapse
m
so how much progress you have done so far? need any help?
jazzespresso said:
so how much progress you have done so far? need any help?
Click to expand...
Click to collapse
Jazz,
have you ever done any work with sepolicy, setools ?
is there a way or do you know the right way to do the policy injection part of what Mikos described for
su and daemonsu ?
when i run strings on the sepolicy binary i do find su_exec.
so i'm still at daemonsu being the culprit. @Chainfire does make it clear the there is a hijack of app_process going on
and i do believe it works for other devices running a "state sanctioned" 5.1.1 so this is/has to be a dicky samsung move.
also how to determine the correct tid if that is indeed what i'm looking for. [see OP]
m
Will look into that, not sure how much differences between android 5.0.X and 5.1.1..
jazzespresso said:
Will look into that, not sure how much differences between android 5.0.X and 5.1.1..
Click to expand...
Click to collapse
It seems to be all sepolicy, i had to adblock and put in my usual apps minus root apps via adb push.
Swapping policy from the 5.0 boot.img reseults in no visuals or input but at adb/terminal i have access,
It just occured to me that i have not yet tried the policy swap and then applied root, hmm.
After i unscrew my system, i upgraded but forgot to change from sid so now wifi is totally boned, xD
I'll try that out, i figure it's something with ueventd.?
On disabling the policy it's complete no go so far.
In spite of modding init.rc
To disab;e sepolicy reload, to write to sys/fs/selinux/enable/0 and trying kernel cmdline edits for enforce=0 androidboot.selinux=0 etc, results
In bogus disable or no boot and dead adbd. Fun fun fun !
this is a copy/paste from my earlier sepolicy trip from galaxy tab 3 forum, putting here for reference
On-Device Policy Files
/sepolicy: Kernel binary policy
/file_contexts: File security contexts
/property_contexts: Property security contexts
/seapp_contexts: App security contexts
/system/etc/security/mac_permissions.xml: App certificate to seinfo mapping
On mac_permissions.xml
●At build time, mac_permissions.xml signature tag names (e.g. @platform) are rewritten to the actual
certificate value extracted from .pem file specified by external/sepolicy/keys.conf
.●build/tools/releasetools/sign_target_files_apks rewrites mac_permissions.xml with updated certificate values for new keys.
System Apps by Certificate
●mac_permissions.xml:
<signer signature= @platform" >
<seinfo value="platform" />
</signer>
●
seapp_contexts:
user=_app seinfo=platform domain=platform_app
type= app_data_file
---------------------------------------------------
Okay so what is this _u _r _t suffix stuff?
• _u – SELinux user
eg: system_u – used for running system services
• _r – SELinux role
eg: system_r – for daemons and background processes
• _t – SELinux type / domain
eg:httpd_t
you can change a single domain to permissive mode
-------------------------------------
the original thread is here, i forgot all about mac_permissions.xml when swapping policy
http://forum.xda-developers.com/galaxy-tab-3/general/se-linux-policy-information-thread-t2865457
moonbutt74 said:
It seems to be all sepolicy, i had to adblock and put in my usual apps minus root apps via adb push.
Swapping policy from the 5.0 boot.img reseults in no visuals or input but at adb/terminal i have access,
It just occured to me that i have not yet tried the policy swap and then applied root, hmm.
After i unscrew my system, i upgraded but forgot to change from sid so now wifi is totally boned, xD
I'll try that out, i figure it's something with ueventd.?
On disabling the policy it's complete no go so far.
In spite of modding init.rc
To disab;e sepolicy reload, to write to sys/fs/selinux/enable/0 and trying kernel cmdline edits for enforce=0 androidboot.selinux=0 etc, results
In bogus disable or no boot and dead adbd. Fun fun fun !
Click to expand...
Click to collapse
I was thinking about getting policy from the 5.0 boot.img and try and see...not sure if it would work - you may try and let me know your results
1) 5.0 sepolicy file.
2) initrd.img current one
3) initrd.img current one
It has been long time man I worked on it or dig this stuff......hmmm....hmmm....Galaxy S6 developers got root on 5.1.1, so this should be not so hard.....
okay so the sesearch string looks something like this , yielding the following output
Code:
[email protected]:/storage/AIK-Linux/ramdisk# sesearch -A -s shell -t system [COLOR="Red"]-c file[/COLOR] sepolicy
Found 3 semantic av rules:
allow shell newAttr33 : file { ioctl read write getattr lock open } ;
allow newAttr7 newAttr33 : file { ioctl read write getattr lock open } ;
allow appdomain newAttr33 : file { ioctl read write getattr lock open } ;
but if i leave out the -c [class=name] option it works sort of like a wild-card and i get this
Code:
[email protected]:/storage/AIK-Linux/ramdisk# sesearch -A -s shell -t system sepolicy
Found 20 semantic av rules:
allow shell system_server : process { transition siginh rlimitinh } ;
allow shell newAttr33 : process getattr ;
allow shell newAttr33 : file { ioctl read write getattr lock open } ;
allow shell newAttr33 : dir { ioctl read getattr search open } ;
[COLOR="Red"]allow shell newAttr33 : lnk_file { ioctl read getattr lock open } ;[/COLOR]
allow appdomain domain : process getattr ;
allow domain system_server : fd use ;
allow newAttr7 newAttr33 : file { ioctl read write getattr lock open } ;
allow newAttr7 newAttr33 : dir { ioctl read getattr search open } ;
[COLOR="Red"] allow newAttr7 newAttr33 : lnk_file { ioctl read getattr lock open } ; [/COLOR]
allow newAttr1 binderservicedomain : fd use ;
allow newAttr1 binderservicedomain : binder { call transfer } ;
allow appdomain system_server : fd use ;
allow appdomain system_server : fifo_file { ioctl read write getattr lock append open } ;
allow appdomain system_server : tcp_socket { read write getattr getopt shutdown } ;
allow appdomain system_server : unix_stream_socket { read write getattr getopt setopt shutdown } ;
allow appdomain newAttr33 : file { ioctl read write getattr lock open } ;
allow appdomain newAttr33 : dir { read getattr search open } ;
allow appdomain newAttr33 : lnk_file { read write getattr open } ;
allow appdomain system_server : binder { call transfer } ;
the lnk_file ones seem interesing, i'm not sure if write is the correct perm or if it's readwrite
using sepolicy inject i've been adding to that list like so
Code:
sepolicy-inject -s appdomain -t newAttr33 -c lnk_file -p write -P sepolicy -o sepolicy-UNdead
but nothing yet, as i go further i will learn more, i think it's finding out what need to be made permissive, getting a read on audit and allow rules don't seem to work, i'm using debian's sepolicy dev tools, as well as Miko's set, and the originating source for sepolicy-inject as well.
finding the permissions/av denial connected to daemonsu being prevented from changing dalvik-cache ownership is what i think i'm looking for
but i'm not 100% on that, though when i
Code:
chcon u:object_r:su_exec:s0 su
, i do get a denial in terminal when i reboot and run su, so i'm still uncertain if su is the culprit.
what makes you think su is the culprit, it is because 5.1.1?
jazzespresso said:
what makes you think su is the culprit, it is because 5.1.1?
Click to expand...
Click to collapse
well, su runs the daemon right the daemon and supolicy need root privelege to run and load
for the portion of the logcat, changing ownership in dalvik-cache fails because damonsu hijacks the app_process/32
changing ownership is the function of chown which needs root priveleges, that particular function happens after the init process,
the init process work with root privelege for the beginning stages of the boot process then lock down and throws over to the system,
without the system's su functioning that process of changing dalvik cache ownership fails and sigabrt , the system hangs.
the reason i'm not 100% sure it's su is because when i chcon app_process/32 -> /xbin/daemonsu to ubject_r:zygote_exec
then the process goes through so...
moonbutt74 said:
well, su runs the daemon right the daemon and supolicy need root privelege to run and load
for the portion of the logcat, changing ownership in dalvik-cache fails because damonsu hijacks the app_process/32
changing ownership is the function of chown which needs root priveleges, that particular function happens after the init process,
the init process work with root privelege for the beginning stages of the boot process then lock down and throws over to the system,
without the system's su functioning that process of changing dalvik cache ownership fails and sigabrt , the system hangs.
the reason i'm not 100% sure it's su is because when i chcon app_process/32 -> /xbin/daemonsu to ubject_r:zygote_exec
then the process goes through so...
Click to expand...
Click to collapse
re-moved
Jazz,
what i am actually going to say is;
pingpong root is a fail, i tried it a few days ago.
dumping general links into this thread is not help.
Linking DIRECTLY to kernel patches/mods etc., is better.
I am looking at the s6 source from the thread you linked to.
I don't think kernel version will make too much of a difference.
The interest, MY interest is in how to mod the default sepolicy to unbreak root.
I do NOT want permissive, i want enforcing with root functioning correctly.
I am getting a better hang of the sepolicy tools but have yet to find what needs changing adjusting
I did manage to disable [set permissive] the policy AND achieve root BUT with display,touch,input broken as before. [grumble]
In the furture please remove quoted text when you reply to post. Thanks.
m
moonbutt74 said:
Jazz,
what i am actually going to say is;
pingpong root is a fail, i tried it a few days ago.
dumping general links into this thread is not help.
Linking DIRECTLY to kernel patches/mods etc., is better.
I am looking at the s6 source from the thread you linked to.
I don't think kernel version will make too much of a difference.
The interest, MY interest is in how to mod the default sepolicy to unbreak root.
I do NOT want permissive, i want enforcing with root functioning correctly.
I am getting a better hang of the sepolicy tools but have yet to find what needs changing adjusting
I did manage to disable [set permissive] the policy AND achieve root BUT with display,touch,input broken as before. [grumble]
In the furture please remove quoted text when you reply to post. Thanks.
m
Click to expand...
Click to collapse
sorry....removed the links and references on my previous post....
jazzespresso said:
sorry....removed the links and references on my previous post....
Click to expand...
Click to collapse
Jazz,
security: SELinux: Avoid enabling enforcing by conventional flag
as to this https://github.com/djvoleur/V_925R4_BOF7/commit/3e33f1fb5538fb2f0f055e9035fe8885a3471322
i'll give it a try and see what happens, but i still want sepolicy enforcing.
@jazzespresso
EDIT - okay i tried it out straight and no-go, but looking at the diff between our selinuxfs.c
and the one you linked to i see that we have a compile/build flag
#ifdef CONFIG_ALWAYS_ENFORCE
//If build is user build and enforce option is set, selinux is always enforcing
new_value = 1;
[blah blah blah]
selinux_enforcing = new_value;
there's some more but i think you get the idea of where i'm going with this.
the new_value change has been used before to success so it will work with our kernel source,
it's just a matter of getting it right. =]

ADB command to insert SQL data

I'm trying to give an application root access in Magisk.
If I run these commands manually this works:
Code:
adb shell
su
sqlite3 /data/adb/magisk.db "INSERT INTO policies (uid,policy,until,logging,notification) VALUES(12345,2,0,1,1)"
What I am trying to do though is do it through a batch script as a single line. I tried different variations of this:
Code:
adb shell "su -c 'sqlite3 /data/adb/magisk.db 'INSERT INTO policies (uid,policy,until,logging,notification);VALUES(12345,2,0,1,1);''"
adb shell "su -c 'sqlite3 /data/adb/magisk.db 'INSERT INTO policies uid,policy,until,logging,notification;VALUES 12345,2,0,1,1;''"
adb shell "su -c 'sqlite3 /data/adb/magisk.db 'INSERT INTO policies VALUES 12345,2,0,1,1;''"
I either get an error telling me "Error: incomplete input", or "/system/bin/sh: syntax error: unexpected '('"
Does anyone have any thoughts? I'm sure it's just a syntax issue, but I'm not sure what else to try.
Thanks in advance.
In the 2nd code example the quotes used are wrong set: you always must alternate double quote and single quote, means the term
'INSERT INTO policies VALUES 12345,2,0,1,1;'
must get written as
"INSERT INTO policies VALUES 12345,2,0,1,1;"
BTW:
Never run several adb shell one after one: it always opens internally a shell window what really doesn't make sense.
Thank you, I'll give your suggestion a try.
Regarding the adb shell; if I do have multiple ADB shell commands to send, then what would be the proper way to do that?
What I am trying to accomplish is writing a batch script in windows that will automate several tasks for me after a factory reset.
I perform several application installs, disable several applications I don't need,
try to add permissions to apps through ADB, and also try to add root permissions like in my example above.
If there is a better way of sending multiple commands like that, could you show an example?
Quick follow up question...
Is there a way to update permission flags to USER_SET?
I tried:
Code:
adb shell pm clear-permission-flags com.name.app android.permission.READ_EXTERNAL_STORAGE user-set
and
Code:
adb shell pm set-permission-flags com.name.app android.permission.READ_EXTERNAL_STORAGE user-set
both gave me an error that the command is unknown. Is there another way? I am trying to set the USER_SET flag for android.permission.READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE

Categories

Resources