Database Info

Allowing non market apps to be installed on locked down phones (backflip)

Hey guys,
My uncle works for Motorola and gave me a prototype phone (which I believe will be called the Motorola Sage, and it's model number is MB508. This thread isn't really about that, I can't post pictures because I don't want to get anyone in trouble). This phone is an AT&T phone, complete with AT&T startup screen, uninstallable AT&T apps and of course the inability to install non-market apps. Also it's running Android 2.1.
Now, I seem to have default root access to this phone. I'm assuming the file system is very similar to that of the Backflip (which I was previously using until I received this one). From what I've read and learned from poking around in /system/etc, non-market apps are blocked by two config files. These are:
/system/etc/motorola/com.android.providers.settings/secure.mkitso
Code:
# cat secure.mkitso
cat secure.mkitso
location_providers_allowed=network,gps
wifi_on=0
data_roaming=1
bluetooth_on=0
install_non_market_apps=0
usb_mass_storage_enabled=1
and
/system/etc/motorola/com.motorola.android.providers.settings/settings.mkitso
Code:
# cat settings.mkitso
cat settings.mkitso
mms_maximum_message_size=614400
auto_scan_on_flip=true
sms_pref_key_emailgateway_num=121
Single_Digit_Dial_Enabled=True
roaming_icon=0
dun_enable=1
force_only_market_apps=1
Bluetooth_Dun_Enabled=true
mms_x_wap_profile_url=http://uaprof.motorola.com/phoneconfi/MotoMB51/profile/MotoMB511.rdf
sms_pref_key_to_email=1
Okay, now it would seem that it's a simple matter of changing the values for "force_only_market_apps" to 0, and "install_non_market_apps" to 1. I did this, and let me quickly tell you how I did it.
- Make /system writable: mount -o remount,rw -t yaffs2 /dev/block/mtdblock4 /system
- Copy mkitso files to sdcard
- Edit mkitso files using Notepad++, changing the values as stated above
- Copy mkitso files back to their original directories
- chmod 644 to the files in order to keep their original permissions
- Make /system read only again: mount -o remount,ro -t yaffs2 /dev/block/mtdblock4 /system
- Restart the phone
However, this did not work, as I still get the warning when I try to install a non-market app.
I was wondering if anyone had any ideas on this, as when the Backflip gets rooted this is one thing that I'm sure we would like to know.

Have you tried adb install? I've heard that works on Backflops. You could download the app to your PC,and install it using "adb install PATH/TO/APP.APK"

Thanks, I know that I can use adb to install non market apps, but I was looking at how to change this setting on the phone. Since I have root on my phone, I figured it was possible.

Check out some of these terminal apps found in /system/bin/ directory of the backflip.Maybe they will help you.
Code:
modemlog
chown
check_prereq
dumpsys
qmuxd
rild
dd
port_bridge
installd
minipadut
vmstat
vold
ioctl
mm-audio-native-test
lsmod
id
mm-adec-omxamr-test
notify
getevent
hciattach
dhcpcd
service
cat
system_server
linker
mm-vdec-omxh264-test
mm-adec-omxevrc-test
wpa_supplicant
netstat
mm-adec-omxmp3-test
ls
wipe
iwpriv
stop
log
mm-vdec-omxmp4-test
top
bt_init
app_process
kill
dumpcrash
iwspy
tcmd_engine
sleep
port-bridge
input
chmod
flash_image
wfa_dut
monkey
dmesg
umount
dalvikvm
sh
sync
ptf
mm-jpeg-dec-test
ime
diag_klog
route
ln
batch
fuel_gauge
iwlist
bugreport
insmod
hcid
svc
rmmod
servicemanager
iwgetid
debuggerd
test_diag
am
renice
applypatch
ps
watchprops
sendevent
reboot
mount
mm-adec-omxQcelp13-test
pm
start
ping
busybox
toolbox
df
touchpad
mediaserver
setconsole
loc_api_app
setprop
logwrapper
rm
dvz
hd
ifconfig
rmdir
printenv
getprop
mm-venc-omx-test
fsck_msdos
iwconfig
iftop
bt_downloader
akmd2
sdptool
disp_util
mm-aenc-omxamr-test
newfs_msdos
gzip
cmp
iwevent
mv
smd
mmclog
mknod
mm-adspsvc-test
bt_test_exec
dexopt
date
set_grp_id
i2c
tcmd_sql
recovery
dumpstate
netcfg
surfaceflinger
mkdir
dbus-daemon
mm-adec-omxaac-test
schedtest
mm-jpeg-enc-test
logcat
mm-aenc-omxaac-test
schedtop
fmradio
EDIT:Also there does not seem to be a com.android.providers.settings in /system/etc/motorola/ only com.motorola.android.providers.settings and the file located in that directory is named secure.mkitso and the market app setting is set up like this:install_non_market_apps=0
So there is a slight difference in how the devices are set up and maybe a bit less security on the backflip =)

Thanks for your suggestion, but if you read above I changed the mkitso files without any changes in the behavior of the phone .

I was thinking that since I changed the settings files and they didn't do anything, maybe they will be applied during a hard reset. I'll try that sometime this weekend and report on the results.
The reason I'm asking for help is because I believe that once the Backflip gets rooted, we will need to know how to disable this setting.

I doubt you have root unless it came already rooted (you did make up some **** about a prototype) I honestly think this wont be a hard issue to tackle or work around when root is achieved on the Lackflip...yes I did Lackflip on purpose because of how crippled it is..so spend your time ANNONYMOUSLY sending www.endgadget.com some nice shiney pics of your supposed prototype codnamed:
"Motorola Sage"

I'm not sure why you're so aggressive, Honestly77. I'm able to "su" in shell and I'm able to modify files in the /system folder, so unless I'm mistaken (which I very well might be), then I believe I have root on the phone.
It is a prototype phone for testing, so it coming rooted isn't too farfetched at all.
When the Backflip does get rooted yes, this will be an easier issue to solve, but I'm trying now. If we're able to figure it out now then no time will have to be devoted to it when the Backflip is rooted.

Alright, I just did a hard reset and it activated a menu toggle under Settings -> Applications -> "Unknown Sources: Allow install of non-Market applications" which can be checked or unchecked.
To summarize, if you have root on your phone, edit secure.mkitso and settings.mkitso and change the variables, then you need to hard reset the phone.

hey met3ora, I too have a backflop, I am currently trying to sell my soul to obtain some sort of root or even simple control over the device, I have 2 questions for you...
1: using the config files and other software availible on this forum, would it be possible to obtain a workaround to be able to install apps from sd? I'm sure you are well aware that the backflip has no memory and won't even allow market apps to be installed via sd.
my second question (its ok if you don't want to answer as we will find out soon enough)
is: the moto sage, how does it compare to the backflip? no specifics needed just, is it better?
Iv'e seen the photos of the sage that appeared a couple weeks ago and it looks good, just incase we need it you should copy the system files as I'm sure the one AT&T will give us will be on lockdown as well. Thanks!

Honestly77 said:
I doubt you have root unless it came already rooted (you did make up some **** about a prototype) I honestly think this wont be a hard issue to tackle or work around when root is achieved on the Lackflip...yes I did Lackflip on purpose because of how crippled it is..so spend your time ANNONYMOUSLY sending www.endgadget.com some nice shiney pics of your supposed prototype codnamed:
"Motorola Sage"
Click to expand...
Click to collapse
THis thread is old but it still helped me with a bravo. Thanks OP.
And to this guy above, wtf, why be such a douche? You are also clearly an idiot or you would know that engineering models always have root.
Calling the OP a liar was way out of line and you should apologize.

[SECURITY] Multiple Android Superuser vulnerabilities

Well, I was going to hold off until all of the vendors had new releases posted, but now that the cat is out of the bag and the evildoers have sufficient information to figure out what got fixed:
[size=+1]Current Superuser/SuperSU releases have security holes that allow any application to execute commands as root without the user's permission (even apps with no permissions). Please upgrade immediately to SuperSU >= v1.69 or another patched release.[/size]
This is expected to impact the vast majority of rooted devices and custom ROMs.
Details follow:
[size=+2]Superuser unsanitized environment vulnerability on Android <= 4.2.x[/size]
Vulnerable releases of several common Android Superuser packages may allow malicious Android applications to execute arbitrary commands as root without notifying the device owner:
ChainsDD Superuser (current releases, including v3.1.3)
CyanogenMod/ClockWorkMod/Koush Superuser (current releases, including v1.0.2.1)
Chainfire SuperSU prior to v1.69
The majority of third-party ROMs include one of these packages.
On a rooted Android <= 4.2.x device, /system/xbin/su is a setuid root binary which performs a number of privilege checks in order to determine whether the operation requested by the caller should be allowed. In the course of its normal duties, and prior to making the allow/deny decision, /system/xbin/su invokes external programs under a privileged UID, typically root (0) or system (1000):
/system/bin/log, to record activity to logcat
/system/bin/am, to send intents to the Superuser Java app
/system/bin/sh, to execute the /system/bin/am wrapper script
/system/bin/app_process, the Dalvik VM
The user who invokes /system/xbin/su may have the ability to manipulate the environment variables, file descriptors, signals, rlimits, tty/stdin/stdout/stderr, and possibly other items belonging to any of these subprocesses. At least two vulnerabilities are readily apparent:
- On ClockWorkMod Superuser, /system/xbin/su does not set PATH to a known-good value, so a malicious user could trick /system/bin/am into using a trojaned app_process binary:
Code:
echo -e '#!/system/bin/sh\nexport PATH=/system/bin:$PATH\ntouch /data/trojan.out\nexec $0 "[email protected]"' > app_process ; chmod 755 app_process
PATH=`pwd`:$PATH su -c 'true'
The PATH vulnerability is being tracked under CVE-2013-6768.
- Other environment variables could be used to affect the behavior of the (moderately complex) subprocesses. For instance, manipulation of BOOTCLASSPATH could cause a malicious .jar file to be loaded into the privileged Dalvik VM instance. All three Superuser implementations allowed Dalvik's BOOTCLASSPATH to be supplied by the attacker.
The BOOTCLASSPATH vulnerability is being tracked under CVE-2013-6774.
[size=+2]Android Superuser shell character escape vulnerability[/size]
Vulnerable releases of two common Android Superuser packages may allow malicious Android applications to execute arbitrary commands as root, either without prompting the user or after the user has denied the request:
CyanogenMod/ClockWorkMod/Koush Superuser (current releases, including v1.0.2.1)
Chainfire SuperSU prior to v1.69
The majority of recent third-party ROMs include one of these packages. Older ROMs may use the ChainsDD Superuser package, which is not affected but is no longer maintained.
On a rooted Android <= 4.2.x device, /system/xbin/su is a setuid root binary which performs a number of privilege checks in order to determine whether the operation requested by the caller should be allowed. If any of these checks fail, the denial is recorded by broadcasting an intent to the Superuser app through the Android Activity Manager binary, /system/bin/am. /system/bin/am is invoked as root, and user-supplied arguments to the "su" command can be included on the "am" command line.
On a rooted Android >= 4.3 device, due to changes in Android's security model, /system/xbin/su functions as an unprivileged client which connects to a "su daemon" started early in the boot process. The client passes the request over a UNIX socket, and the daemon reads the caller's credentials using SO_PEERCRED. As described above, /system/bin/am is called (now from the daemon) to communicate with the app that implements the user interface.
If the user invokes "su -c 'COMMAND'" and the request is denied (or approved), ClockWorkMod Superuser constructs a command line to pass to a root shell:
Code:
snprintf(user_result_command, sizeof(user_result_command), "exec /system/bin/am " ACTION_RESULT " --ei binary_version %d --es from_name '%s' --es desired_name '%s' --ei uid %d --ei desired_uid %d --es command '%s' --es action %s --user %d",
VERSION_CODE,
ctx->from.name, ctx->to.name,
ctx->from.uid, ctx->to.uid, get_command(&ctx->to),
policy == ALLOW ? "allow" : "deny", ctx->user.android_user_id);
get_command() would return "COMMAND", unescaped, through "/system/bin/sh -c". By adding shell metacharacters to the command, the root subshell can be tricked into running arbitrary command lines as root:
Code:
su -c "'&touch /data/abc;'"
Upon denial by the operator, "touch /data/abc" will be executed with root privileges. The Superuser variant of this problem is being tracked under CVE-2013-6769.
SuperSU prior to v1.69 removes quote and backslash characters from the string passed to /system/bin/sh, but backticks or $() can be used instead for the same effect:
Code:
su -c '`touch /data/abc`'
su -c '$(touch /data/abc)'
The SuperSU variant of this problem is being tracked under CVE-2013-6775.
ChainsDD Superuser v3.1.3 does not appear to pass the user-supplied input on the /system/bin/am command line.
[size=+2]Superuser "su --daemon" vulnerability on Android >= 4.3[/size]
Current releases of the CyanogenMod/ClockWorkMod/Koush Superuser package may allow restricted local users to execute arbitrary commands as root in certain, non-default device configurations.
Android 4.3 introduced the concept of "restricted profiles," created through the Settings -> Users menu. A restricted profile can be configured to allow access to only a minimal set of applications, and has extremely limited abilities to change settings on the device. This is often used to enforce parental controls, or to protect shared devices set up in public places. The OS requires an unlock code to be entered in order to access the owner's profile to administer the system.
/system/xbin/su is a setuid root executable, and any user may invoke it in client mode ("su -c 'foo'" or just "su"), or in daemon mode ("su --daemon"). In either mode of operation, the user who invokes this program has the ability to manipulate its environment variables, file descriptors, signals, rlimits, tty/stdin/stdout/stderr, and possibly other items. By adding new entries at the front of the PATH for commonly-executed root commands, then re-invoking "su --daemon", an attacker may be able to hijack legitimate root sessions subsequently started by other applications on the device.
"su --daemon" is normally started up very early in the boot process, as root, from /init.superuser.rc (CM) or from /system/etc/install-recovery.sh (other ROMs). The fact that unprivileged users are allowed to restart the daemon later, under EUID 0, appears to be an oversight.
Successful exploitation requires a number of conditions to be met:
- The attacker must have ADB shell access, e.g. over USB. This is disabled by default, and normally restricted to trusted ADB clients whose RSA key fingerprints have been accepted by the device administrator. Root access via ADB (i.e. Settings -> Developer Options -> Root access -> Apps and ADB) is not required. Note that ADB shell access is typically considered a security risk, even in the absence of this problem.
- The attacker must have a way to assume a non-shell (non-2000), suid-capable Linux UID in order to prevent /system/xbin/su from creating infinitely recursive connections to itself through the daemon client UID check in main(). One way to do this would involve uploading an app with the "debuggable" flag and using /system/bin/run-as to assume this UID. "adb install" can probably used for this purpose. However, due to a bug in Android 4.3's "run-as" implementation[1], this does not currently work. This bug was fixed in Android 4.4, so CM11 will probably be able to satisfy this requirement.
- The device owner must have granted root permissions to one or more applications via Superuser. The restricted profile does not need to be able to run this app from the launcher.
Sample exploit:
The restricted local user can reboot the tablet, run "adb shell" when the boot animation shows up, then invoke the following commands:
Code:
echo -e '#!/system/bin/sh\nexport PATH=/system/bin:$PATH\ntouch /data/trojan.out\nexec $0 "[email protected]"' > /data/local/tmp/trojan
chmod 755 /data/local/tmp/trojan
for x in id ls cp cat touch chmod chown iptables dmesg; do ln -s trojan /data/local/tmp/$x ; done
PATH=/data/local/tmp:$PATH setsid run-as.422 my.debuggable.package /system/xbin/su --daemon &
(Note the use of "run-as.422" as a proxy for a working Android 4.3 run-as binary, and the installation of "my.debuggable.package" with the debuggable flag set.)
At this point the USB cable may be disconnected.
The next time a root application successfully passes the Superuser check and invokes one of the trojaned shell commands, /data/local/tmp/trojan will be executed under UID 0.
An ideal candidate for exploitation is a package which runs privileged commands on boot, e.g. AdBlock Plus or AFWall+, as this allows for instant access. Another possibility is to hijack an app which the device's operator runs frequently, such as Titanium Backup.
Note that this can NOT be exploited by malicious applications, as zygote-spawned processes (apps) always access /system in nosuid mode[2] on Android 4.3+. The ADB shell was used as the attack vector as it is not subject to this restriction.
ChainsDD Superuser v3.1.3 does not have an Android 4.3+ client/server mode at all, and SuperSU aborts if an existing "daemonsu" instance is already bound to the abstract @"eu.chainfire.supersu" socket.
Proposed resolution: on Android 4.3 and higher, install all Superuser-related binaries with mode 0755 (setuid bit unset).
This problem is being tracked under CVE-2013-6770.
[1] https://code.google.com/p/android/issues/detail?id=58373
[2] http://source.android.com/devices/tech/security/enhancements43.html

Did you report that to @Chainfire?

SecUpwN said:
Did you report that to @Chainfire?
Click to expand...
Click to collapse
Yes, he's been very responsive.
I contacted all three developers last Saturday, and posted the advisory after there was enough public information available to deduce what the problems were.
In case you're curious, there's been some additional discussion about exploiting ChainsDD Superuser on BUGTRAQ.

Is there a way we can patch this maybe using xposed framework

milojoseph said:
Is there a way we can patch this
Click to expand...
Click to collapse
There are new releases of SuperSU and CWM Superuser posted:
https://play.google.com/store/apps/details?id=eu.chainfire.supersu&hl=en
http://forum.xda-developers.com/showthread.php?t=1538053
https://play.google.com/store/apps/details?id=com.koushikdutta.superuser&hl=en
I haven't seen any updates to ChainsDD Superuser, and AFAICT the project is no longer maintained.
maybe using xposed framework
Click to expand...
Click to collapse
Xposed is useful for patching Java programs, but /system/xbin/su is compiled C code. So the techniques used by Xposed would not apply to this case.

cernekee said:
Xposed is useful for patching Java programs, but /system/xbin/su is compiled C code. So the techniques used by Xposed would not apply to this case.
Click to expand...
Click to collapse
There's always Substrate, that can be used even for patching native code, but still in this case not applicable I guess.

Where you able to find any patch to fix them?

thank you for sharing ...

I am getting this message in lollipop "zygote has been granted superuser permission" i accidentally allowed it root access thinking it was link2sd. Could it be malware? There is a nameless app in my supersu under name "zygote". i didn't installed anything outside from playstore. My supersu version is 2.78

diabolicalprophecy said:
I am getting this message in lollipop "zygote has been granted superuser permission" i accidentally allowed it root access thinking it was link2sd. Could it be malware? There is a nameless app in my supersu under name "zygote". i didn't installed anything outside from playstore. My supersu version is 2.78
Click to expand...
Click to collapse
Did you get an answer for this? I have the same issue on 4.4.4

Vankog said:
Did you get an answer for this? I have the same issue on 4.4.4
Click to expand...
Click to collapse
No I didn't, I reflashed the rom and it solved the problem.

[Shell][mksh][Scripting]::mksh-R50e-static-FULL+mkshrc_mods:::

:::BRIEF DESCRIPTION:::
mksh is the official, currently-developed shell used for Android. It is not an app nor a virus (lol) like some people seem to think, looking at a quick xda search. And as the core shell for android, it is used to shell superuser, so if you're rooted and get a message saying "mksh requests root", that basically just means that superuser is being run correctly and is using the default Android shell that is in every Android device. (GOOD)
If you get a message saying bash(or any other shell) requested root, and you're NOT in the terminal interactively. That most likely is NOT GOOD! Almost all bash scripts I've seen will run shelled with mksh, so be safe and shebang with mksh. You'll have better performance and features, and when you see bash requesting root, you'll know when your security is likely compromised.
::: mksh Resources/links/info :::
mksh author: mirabilos (on xda forums)
mirbsd mksh main page: https://www.mirbsd.org/mksh.htm
mksh man page: https://www.mirbsd.org/htman/i386/man1/mksh.htm
edited 15Aug2014
Now that that's out of the way, I've attached a few zips in the 2nd post. The first contains my personalized mkshrc (startup mksh script), the full original mkshrc it's based on, and a diff for anyone who's interested. **This file belongs at /system/etc/mkshrc.** The rest of this first post details what I've cooked up in my mkshrc (and fpath functions). The other zips' contents are described in the 2nd post.
Features scripted into mkshrc:
--sudo: basic su executor
e.g.:
Code:
sudo mount -o rw,remount -t f2fs /system /system
sudo cat <<< $'\n' >> /system/build.prop
sudo 'sysrw; for i in /system/*; do chown 0 "$i" ; done; sysro'
--suid: (set user id) Uses chpst to run a prog setsuid, this is broken in most busyboxes so I included one with a working chpst. Usage:::
e.g.:
Code:
suid 1000 sh
--Rebind tab completion: unjams clustered words:
e.g.: <[cursor]> is cursor position
Code:
bind -m -- '^I= ^B^[=^D'
<<EXAMPLE USAGE>>
ec<[cursor]>12345 + tab ---> echo 12345
--Rebinded "control + u" to "cut-to-beginning of line" like bash. (As mirabilos points out, this is ksh incompatible behaviour since "control + u" is "kill-line" in *ksh shells. This can be removed from the (/system)/etc/mkshrc shell startup file if it presents any problems in editing.) The exact binds are:
Code:
bind -- '^[W=kill-region'
bind -m -- '^U=^[ ^A^[W'
<<EXAMPLE USAGE>>
ec<[cursor]>12345 + ctrl + u ---> <[cursor]>12345
--TMPDIR: mounts a tmpdir at /tmp for all users and random generates subdirs for individual secured tmpdirs. This fixes here-docs, here-strings, and here-executions.
e.g.:
Code:
su << 'eof'
sysrw; chgrp 2000 /system/bin; sysro
! (( $? )) && print -- -changed them bin group-
eof
--Basic "help" command: Android lacks this and the doc is still under development I believe. I added all the basic info/command-forms for mksh bultins to a command help(aliased to h):
e.g.:
Code:
help mkn
> mknod [-m mode] name b|c major minor
> mknod [-m mode] name p
or
Code:
help
(all help is printed, grep from here if you want)
--Complicated-programmed and colorful PS1 prompt, it looks good and I thought it through. Programming shows mksh potential for rich shell programming. It auto-turns off xtrace within itself (to 3 lines) so that 50 lines don't get printed each return with set -x. mksh small (R43 mksh) will be autodetected and give a different white and black classic ksh prompt.
--ton of ultra lazy aliases, got my android scripting speed up to ~70% my normal pc speed.
--dot.mkshrc functions from official mkshrc like pushd, popd, dirs, more, hd, Lb64encode, Lb64decode, hash optimizations
The scripting in this gets pretty complex, especially the inherent mkshrc functions. It would make a good scripting learning tool to say the least. I know I've learned twice what I knew from bash scripting back 3 months ago.
I've been working on modding the mkshrc a while, so I appreciate any error reports if you give mine a try. Shouldn't be any problems though.
Modifying the mkshrc file / mksh shell has system-wide effects, so PLEASE nandroid backup as usual!!! This should be COMPATIBLE with all androids, but has only been tested on my Galaxy Nexus thus far. **The binary is compatible with androids using an ARM cpu, but the steps in the 3rd post will generate a binary for whatever ARCH you're running.**
EDIT: reprogrammed sudo with pexec, so it can do parallel executions. pexec, grep, and a full busybox are included in a zip with some other bins.
For Jack Palevich's terminal emulator or connectbot, telnet, etc, I use this as my su'd "shell" command under >>Options>>Shell:
Code:
/system/xbin/su --shell /system/bin/mksh --command exec /system/bin/pexec -z -15 --shell /system/bin/mksh -m '/system/bin/mksh'
What's safer though is to just use a non-su shell command:
Code:
/system/bin/mksh -
...and then use sudo for your su commands. This is more linux'y.
EDIT2 (big update): Got static mksh R50 compiled. Ended up booting ubuntu in Android to compile instead of cross-compiling. mksh's Build.sh compiler script works great. I just had to "sudo apt-get install gcc" and bam it built with "LDSTATIC=-static ./Build.sh".
EDIT3 - Changed main.c source mkshrc file to /system/etc/mkshrc, perfect static mksh R50 now.
EDIT4 - Changed compiler to klcc to get size way down, now at 196KB with -O2 LTO speed optimizations.
EDIT5 - Binary is updated to R50d, compiled with CFLAGS=-Os, and stripped to get size down to ~140KB. (This is even smaller than the R43 dynamic mksh binary that is currently used in roms.)
EDIT6 - Added a mksh trunk (latest and greatest) binary with the printf builtin compiled in. Use with caution. Btw, if you read all the way down here, then yes, these binaries work in lollipop since they're statically compiled.

:ownloads:: (#7 or #8 is the static binary by itself)
(1) mksh R50 source, binary, manual
(2) Highly compressed pack of extra bins/libs that are mentioned in my mkshrc (zsh, lz4c, grep, busybox, bash, nano, vim, curl, etc) and some other cool ones like macchanger and ed. Download #3 to extract on Android.
(3) 7za in case you need it to extract (2) on Android.
Code:
7za x name_of_archive.7z
(4) Classic unix text editor "ed" which mksh uses for edit functionality. (Copy to /system/bin along with mksh.)
(5) Official mkshrc (unzip and copy to /system/etc, set permissions to 0444)
(6)
My personalized mkshrc startup mksh shell script based on the official full mkshrc 2014/01/11 release. Described in first post. If you try this, make sure to symlink /system/xbin/busybox to /system/bin/busybox.ndk.
Official mkshrc 2014/01/11 release
"diff -ur /system/etc/dot.mkshrc--official.mkshrc mkshrc" (diff patch set from official mkshrc to my personalized mkshrc)
(7) mksh static binary! (Just unzip, "chmod +rx" it, and copy to /system/bin or run from anywhere, no libs required )
(8) mksh R50e with printf builtin (I know some people were looking for this)

::: Building mksh Static On Android (really Ubuntu though..):::
This is just for anyone who wants to try, and especially those without access to a PC.
Things we'll need besides your phone:
-"Android Terminal Emulator" app {get it from (http://jackpal.github.com/Android-Terminal-Emulator/downloads/Term.apk) or fdroid or gplay}
-"Complete Linux Installer" app {get it from (http://sourceforge.net/projects/linuxonandroid/?source=typ_redirect) or gplay or maybe fdroid}
-internet/wifi
-mksh source {download from (https://www.mirbsd.org/MirOS/dist/mir/mksh/mksh-R50.tgz) or link in first post or DL in second post}
1) We need to get Ubuntu or Debian booted for a sufficient build environment. I've used both on Android but I like the better stocked terminal in the Ubuntu images. I used the app Complete Linux Installer which is free and works beautifully, very simple and easy too. In the app you want to follow the short instructions to download an Ubuntu image, rename it to ubuntu.img, and place it in a folder named ubuntu in /sdcard. Then hit menu in the app and click the terminal screen icon that says "Launch". An Ubuntu terminal will now open in Android Terminal Emulator. Super quick and easy.
2) Let's download GCC and ed so we can build and test with zero errors.
Code:
apt-get install -y gcc ed
3) Now the cool thing about this chroot Ubuntu environment is that we still have access to the sdcard to transfer files between Android environment and the chroot jail. Extract your downloaded mksh source to your Ubuntu home with something like:
Code:
cd
tar -xf /sdcard/Download/mksh*.tgz
cd mksh
4) Since we're building this for Android, the mkshrc file is at /system/etc/mkshrc instead of ~/.mkshrc, so we can change this with:
Code:
sed -i 's|~/.mkshrc|/system/etc/mkshrc|' ./main.c
Now we can build mksh statically:
Code:
chmod +x Build.sh
MKSHRC_PATH=/system/etc/mkshrc LDSTATIC=-static ./Build.sh -r -c lto && ./test.sh
Let the build script crank out the binary for a couple minutes and run the test suite. There should only be an error on a "mkshrc" test since we changed it for android. The "-r -c lto" flags/opt aren't needed but recommended.
Edit: (size optimization): Strip the compiled mksh binary to make it super small (~150KB with a CC="klcc" or CC="diet gcc" compile).
Code:
strip --strip-unneeded ./mksh
5) Now let's copy it to /system/bin to replace your old one.
Code:
cp ./mksh /sdcard
(Open a new terminal tab to get into Android Environment)
sysrw
cp -f /sdcard/mksh /system/bin
chmod 0555 /system/bin/mksh
sysro
.. and done. Run some scripts and enjoy your static mksh!
*** OPTIONAL EXTRA STEPS TO USE klcc or other compiler ***
In step (1), also do
Code:
apt-get install -y libklibc-dev
to get the klibc development tools, and then...
In step (4), this is how you specify to use klcc (aka build against klibc using the klcc wrapper):
Code:
CC="$(which klcc)" MKSHRC_PATH=/system/etc/mkshrc LDSTATIC=-static ./Build.sh -r -c lto && ./test.sh
:::Compile mksh in Android (for ARM):::
1) Download the attached cross-compiler and mksh source (https://www.mirbsd.org/MirOS/dist/mir/mksh/mksh-R50.tgz). Copy them to /data/media. If you don't have 7za, download that as well from the previous post but place it in /system/bin and "chmod +x" it
2) Extract contents:
Code:
cd /data/media
7za x -so 2014-10-01__simple-cross-compiler-armv4tl.stripped.tar.7z | tar -xf -
tar -xf mksh*.tgz
3) Compile the source with:
Code:
cd mksh
chmod +x Build.sh
LDFLAGS=-static CC=../simple-cross-compiler-armv4tl.stripped/bin/*gcc ./Build.sh -r -c lto
../simple-cross-compiler-armv4tl.stripped/bin/*strip -s mksh
4) Replace old mksh and mkshrc
Code:
mount -o rw,remount /system
cp mksh /system/bin
cp dot.mkshrc /system/etc/mkshrc
chmod 0555 /system/bin/mksh
chmod 0444 /system/etc/mkshrc
mount -o ro,remount /system

@7175 : Hello! Look like a bunch of hard work there. Very nice.
1. Would you have any clue to what's going on HERE?
2. Would you know if I can just install over my old mksh binary to get this working, or do I need "everything"?
3. And since I've heard that /system/bin/mksh will soon be permanently only /system/bin/sh perhaps this need to be changed?

Hey E.VA. thanks for checking out the thread. If you want to just test out R48 mksh, just copy(from zip root directory) the lib*.so from /data/media/shell to /system/lib and then copy /data/media/shell/mksh to /system/bin (and chmod 0555 /system/bin/mksh; chmod 0444 /system/lib/*.so). Then you'll have your whole system running full mksh R48.
As far as the ssh problem with android, this definitely becomes grey-zone material to my knowledge, which is limited in this area. I'm pretty sure android has udev amputated so it lacks a fully working /dev/tty. This could probably be patched over though with some terminal work, mknod action. I've gotten ssh working under "terminal ide", but haven't used the stock ssh stuff in /system/bin. Now that you mention this though, I will try and get stock ssh going as well as openssh which had a similar problem last time I tried (thx for mentioning your support thread, I'll be checking that out).
Here's what I searched to shed a little light on that ssh /dev/tty issue: duckduckgo.com/html5/?q=ssh+%27dev%2Ftty%27+error.
It looks like you've done a ton of searching though.
For su commands, I would try using, e.g.,
Code:
su exec [i]command[/i]
...opposed to "su -c", or better e.g.,
Code:
su -c exec /system/bin/sh -c '[i]command[/i]'
...and see if that gives any different results.
I just know from experience "su -c" hasn't always cut it.
*edit: Couple other things worth trying:
1) preappend command with environment variable: global TTY=/dev/pts/0 ...
2) use the -T option when calling mksh, i,e. ssh ... -e mksh -T /dev/pts/0 ...

@7175 : Hey thanks for looking into this. I will definitely try your suggestions.
However, I've already tried the -T flag to ssh, but never by specifying the pts to use, as it should be dynamically allocated by the ptmx. (As it could be already in use, by something else, like ATE.) Also, what does "global" do?
You also mentioned "stock ssh" in /system/bin. I've never seen that. Perhaps that could be a better solution, unless its' even more crippled. Does it also support sshd (i.e. ssh -D)?
In the mean time, is there any particular reason why you decided to dynamically link mksh? (I assumed it would have been more portable with static linking?)
I see that you did a huge amount of work on that mkshrc script. Looks crazy (in a good way)!
Finally, and aside, I also noticed that when I start mksh from ssh session, there are some aliases in there, that is not specified in the mkshrc, nor the .profile of my SSH server, so where the heck do they come from?
Code:
[SIZE=2][email protected]:home # alias
autoload='typeset -fu'
functions='typeset -f'
hash='alias -t'
history='fc -l'
integer='typeset -i'
local=typeset
login='exec login'
nameref='typeset -n'
nohup='nohup '
r='fc -e -'
source='PATH=$PATH:. command .'
type='whence -v'[/SIZE]
Perhaps they're hardcoded or sourced from somewhere? Have you seen this?

E:V:A said:
@7175 : Hey thanks for looking into this. I will definitely try your suggestions.
However, I've already tried the -T flag to ssh, but never by specifying the pts to use, as it should be dynamically allocated by the ptmx. (As it could be already in use, by something else, like ATE.) Also, what does "global" do?
You also mentioned "stock ssh" in /system/bin. I've never seen that. Perhaps that could be a better solution, unless its' even more crippled. Does it also support sshd (i.e. ssh -D)?
In the mean time, is there any particular reason why you decided to dynamically link mksh? (I assumed it would have been more portable with static linking?)
I see that you did a huge amount of work on that mkshrc script. Looks crazy (in a good way)!
Finally, and aside, I also noticed that when I start mksh from ssh session, there are some aliases in there, that is not specified in the mkshrc, nor the .profile of my SSH server, so where the heck do they come from?
Code:
[SIZE=2][email protected]:home # alias
autoload='typeset -fu'
functions='typeset -f'
hash='alias -t'
history='fc -l'
integer='typeset -i'
local=typeset
login='exec login'
nameref='typeset -n'
nohup='nohup '
r='fc -e -'
source='PATH=$PATH:. command .'
type='whence -v'[/SIZE]
Perhaps they're hardcoded or sourced from somewhere? Have you seen this?
Click to expand...
Click to collapse
Thanks man lol it's a big rc. It was 50KB before I converted a bunch of the functions to fpath functions in /etc/fpath and stripped most of the comments. It should give a pretty quick shell in terminal though with the ulimit and renicing tweaks. The PS1 prompt is pretty awesome, probably the best thing in the mkshrc I included.
"global" is a function just like "typeset" or "declare" in bash. The difference is that global prevents an accessed variable from being localized/ different than the global value in a function. This is a mksh function, bash will use "declare -g". There are a couple of example usage in the mkshrc, like with the set -x spam fix for the command prompt.
I checked and stock ssh in /system/bin has the "-D" flag. I would also check rolo's zshaolin zsh project which comes with some afterstock ssh stuff, ssh keygen, ssh keysearch, different ssh etc.
Yeah I just symlinked sh to save space really and for portability to try out other shells like bash and zsh(this works!) to run the system. Recently I switched to using a copy of mksh as sh since "chattr +i" wasn't protecting the symlink from being over-linked.
The aliases you posted are in fact hard-coded. If you do "strings /system/bin/mksh | grep -C7 autoload" or something similar, you'll see them in the binary. I always wondered where those came from too until I read through the mksh manual over a couple months, that's some pretty dense reading lol. mksh is a superb shell though, so it's definitely well worth it.
Sorry I can't be of more help with the ssh /dev/tty problem. I will keep my eyes open though, and try not to be so lazy using telnet for all my remote connections. I mean that's basically using the internet without a condom lol.
(*Also, just something I should mention about the install zip contents: not all the /etc/fpath functions are finished yet. I still gotta tweak the ssh ports from /etc/ssh and finish my xargs. Most should work though and are safe and won't interfer with shell usage, even if autoloaded.)

@mirabilos :
Hi, why did you choose to hardcode the aliases (shown in post#6) into the mksh binary?
Also, do you have a later version than the R48 Android binary above?
The "r" alias is particularly disturbing as it is masking the native toolbox use of "r" to read a memory location.

7175 said:
with the ulimit and renicing tweaks.
Click to expand...
Click to collapse
Why do they need to be tweaked?
I checked and stock ssh in /system/bin has the "-D" flag. I would also check rolo's zshaolin zsh project which comes with some afterstock ssh stuff, ssh keygen, ssh keysearch, different ssh etc.
Click to expand...
Click to collapse
Sorry my bad, I was sleepy and mistakenly understood "-D" as running SSH in daemon mode, when in fact it does the opposite and prevents it. Seem like his links are dead or I'm just looking in the wrong place.
Recently I switched to using a copy of mksh as sh since "chattr +i" wasn't protecting the symlink from being over-linked.
Click to expand...
Click to collapse
Not sure what you're saying here...
Sorry I can't be of more help with the ssh /dev/tty problem. I will keep my eyes open though, and try not to be so lazy using telnet for all my remote connections. .
Click to expand...
Click to collapse
Thanks, but if telnet works with tty/pts jobcontrol and vi etc, then I'm fine with that for now. I tried your command variations above and got this:
Code:
[SIZE=2]#ssh -2 [email protected] -p 2222 -T su -c exec /system/bin/sh -i # This worked!
#ssh -2 [email protected] -p 2222 -T su -c exec /tmp-mksh/tmp-mksh -T /dev/pts/0
/tmp-mksh/tmp-mksh: chvt: can't find tty /dev/pts/0
#ssh -2 [email protected] -p 2222 -T su -c exec /tmp-mksh/tmp-mksh -T /dev/ptmx
/tmp-mksh/tmp-mksh: chvt: new shell is potentially insecure, can't revoke /dev/ptmx
[/SIZE]
The fist one is good to get direct root prompt, the second fails, since pts/0 has not been created yet, and if it has, it fails with permission issue, since another process is trying to steal the pts. The reason why the third one fails, is very cryptic and I don't understand the error message and neither the code generating it.
Do you think one could use the ATE app to get a working root shell by the use of a more complex ssh command? Any suggestions how that would look?
Finally, I'm a bit worried about replacing the libc.so dependency, since the whole system depend upon it, and would probably not boot if an incompatible libc.so is used. This is why I asked about a static binary. I'd much rather have a bloated mksh than having to add library files. (We have plenty of memory and space these days.)
Regarding compiling, I would recommend using Linaro a build, rather than the crappy and often broken/outdated Code Sourcery junk.
Check this thread:
[LINARO GCC] Cross Compiler Toolchains [Linaro GCC 4.9 2014.07, 4.8 and 4.7 2014.04][19/07/2014]
Cheers!

7175 said:
--Better tab completion: unjams clustered words:
--Added "control + u" to "cut-to-beginning of line" like bash.
Click to expand...
Click to collapse
Hi! As the author of mksh, I am hereby explicitly requesting you to add a suffix to the shell version, similar to what the PLD Linux guys do here, because this changes the behaviour of the shell in an incompatible way. (Just add your own string there after a space, the @distro@ is just a placeholder that gets replaced with the PLD Linux package version.)
Do note that ^U in Korn Shell (and others) is “delete entire line”.
7175 said:
--Very complicated-programmed and colorful PS1 prompt, it looks good and I thought it through. Programming shows mksh potential for rich shell programming. It auto-turns off xtrace within itself so that 50 lines don't get printed each return with set -x. mksh small will be autodetected and give a different white and black classic ksh prompt.
Click to expand...
Click to collapse
Interesting idea, I think I will pick up the “set +x” thing.
Do you mind sharing a patchset of all your changes, so I can incorporate those I feel would be good to have in general?
7175 said:
EDIT: It appears the libc required for full mksh isnt always friendly
Click to expand...
Click to collapse
Just link the shell statically, then.
E:V:A said:
1. Would you have any clue to what's going on HERE?
Click to expand...
Click to collapse
You are annoying me. I've told you times and times again to disable SEAndroid, or to fix its SELinux policies.
E:V:A said:
2. Would you know if I can just install over my old mksh binary to get this working, or do I need "everything"?
Click to expand...
Click to collapse
Define “everything”. mksh in AOSP is /system/bin/mksh plus mkshrc.
E:V:A said:
3. And since I've heard that /system/bin/mksh will soon be permanently only /system/bin/sh perhaps this need to be changed?
Click to expand...
Click to collapse
I'm working with enh of Google on that. I would like for mksh to be installed as /system/bin/mksh and /system/bin/sh to be a link/copy of it, always. He said he'd agree I could change that back.
E:V:A said:
Hi, why did you choose to hardcode the aliases (shown in post#6) into the mksh binary?
Click to expand...
Click to collapse
These are part of the shell, and have always been, even in pdksh times.
E:V:A said:
Also, do you have a later version than the R48 Android binary above?
Click to expand...
Click to collapse
I do not deal in binaries normally. I'm somewhat working on updating AOSP to mksh CVS HEAD, in tandem with enh from Google, but when I had the time for that, it appears they changed the build system requirements. But it will be there.
It's not as if a newer mksh version would fix your SELinux problem, though…
E:V:A said:
The "r" alias is particularly disturbing as it is masking the native toolbox use of "r" to read a memory location.
Click to expand...
Click to collapse
The “r” alias is especially required for the Emacs command line editing mode. Interesting that toolbox uses it too. Thanks for bringing this to my attention, I will ask enh to change “r” in toolbox.

@E:V:A : Glad the first execution you mentioned worked. I would try messing with quotes/double quotes around the shell command, i.e. ssh ... -T su -c 'exec ...' or try ssh ... -T su -c exec "...", as something to test out further. This can make a lot of difference.
The ulimit shell function can control all sorts of performance related stuff, priority, max niceness, etc. You can see all values with "ulimit -a".
I understand your hesitance about the libc.so replacement. I would keep a copy of the old one and twrp backup before trying out a new one. I get what you're saying about statically linked binaries. I just fixed my i7 desktop that had a blown power supply, so I'll be looking into this. Thanks for the linaro link!
@mirabilos : Thanks for taking a look at this and providing us with mksh! I updated my OP with the specifics about the rebinds for "control I" and "control U" that you mentioned, and I added a suffix to the beginning comments of the file. Something like:
Code:
# $MirOS: src/bin/mksh/dot.mkshrc,v 1.88 2014/01/11 18:09:39 tg Exp $Android_mod by [email protected] 2014/08/04$
Not sure if that's what you wanted me to add in. I included an extra zip to download in the 2nd post that contains the official mkshrc 2014/01/11, my personal mkshrc, and a "diff -ur" patch (also attached to this post).
I will look into getting a statically linked mksh compiled, that sounds like something really handy to keep around.
edit: Here's basically what I added to the beginning and end of PS1 to trim down its "set -x" verbosity to 3 lines. I'd like to get it down more but haven't figured it out.
Code:
PS1=$'\001\r'; PS1+='${|
local e=$?
[[ -o -x ]] && set +x && global -x XTR_DBG=1 || global -x XTR_DBG=0
...
...
...
(( XTR_DBG )) && set -x
return ${e}
} '

7175 said:
@mirabilos : Thanks for taking a look at this and providing us with mksh!
Click to expand...
Click to collapse
You’re welcome!
7175 said:
Not sure if that's what you wanted me to add in.
Click to expand...
Click to collapse
Ah, so you did not patch the mksh binary, only the mkshrc file?
But then, that’s okay as you wrote, sure.
7175 said:
I included an extra zip to download in the 2nd post that contains the official mkshrc 2014/01/11, my personal mkshrc, and a "diff -ur" patch (also attached to this post).
Click to expand...
Click to collapse
OK, thanks. Will have a look at it within the next weeks (August is going to be a busy month for me).
I’m assuming you are okay with me adding some of your changes back to main mksh?
7175 said:
I will look into getting a statically linked mksh compiled, that sounds like something really handy to keep around.
Click to expand...
Click to collapse
Indeed, it is.
The first mksh run on Android actually was statically compiled against µClibc, though that’s cheating. (Also, dietlibc and klibc are better than µClibc). I think it should work against Bionic, too.
7175 said:
edit: Here's basically what I added to the beginning and end of PS1 to trim down its "set -x" verbosity to 3 lines. I'd like to get it down more but haven't figured it out.
Click to expand...
Click to collapse
I don’t think it works in less, considering you have to save the previous $?. There are a few handy tricks around. I tried these four:
#1 is:
Code:
local e=$?
[[ -o -x ]]; local x=$?; set +x
(( e )) && REPLY+="$e|"
[…]
(( x )) || set -x
return $e
This is about what you did. #2 is:
Code:
local e=$? x=$([[ -o -x ]]; echo $?); set +x
(( e )) && REPLY+="$e|"
[…]
(( x )) || set -x
return $e
This only looks different (I’d prefer #1 over this.) #3 is:
Code:
set +x $? $([[ -o -x ]]; echo $?)
(( $1 )) && REPLY+="$1|"
[…]
(( $2 )) || set -x
return $1
This reduces visual clutter. #4 is:
Code:
set +x $? $([[ -o -x ]]; echo $?)
(( $1 )) && REPLY+="$1|"
[…]
(( $2 )) && return $1
(( $1 )) && set -x && return $1
set -x
This reduces visual clutter even more, in that, when $? is 0, one line less is shown. But it makes the number of lines shown be not always the same. YMMV on whether to use this, #3 or #1.
This could be made even nicer *iff* mksh had the EXIT trap when leaving a function. The manpage says it’s TODO. This part of the manpage is from 1999 or older. (I started mksh in late 2002, early 2003.) Go figure… But now I have a reason to add it ☺
Another thing you could do is “set +o inherit-xtrace”, which makes functions not run with “set -x” when the main body runs with it. But wait, I see now that it does not affect ${|…;} blocks. This is a bug, which I’ll fix ☻

@mirabilos:
You Wrote:
1. Would you have any clue to what's going on HERE?
Click to expand...
Click to collapse
You are annoying me. I've told you times and times again to disable SEAndroid, or to fix its SELinux policies.
Click to expand...
Click to collapse
Well, you can be as annoyed as you like. First of all, that question was not aimed at you, and second, as I have also said repeatedly, I have already tried using SELinux in Permissive mode and it doesn't work either. In addition, your suggestion to "fix its SELinux policies" is rather ridiculous as there are no tools available to do so. At least nothing out of the box and no available binaries anywhere, and surely no instructions how to do so. So if you know how to do it, why don't you just explain for us how to do so. (My policies are updated to latest according Androids policy update tools.)
In addition there is no such thing as "disable SEAndroid". It's either in Permissive or Enforced mode. That is, unless you flash a new custom FW, which is out of the question. In addition, ATE works just fine, in Enforcing mode.
So believe me, I am far more annoyed by Googles lack of SELinux/SEAndroid developer support, than you will ever be from me asking these questions.
Thanks for explaining and helping with everything else above.
@7175:
The ulimit shell function can control all sorts of performance related stuff, priority, max niceness, etc. You can see all values with "ulimit -a".
Click to expand...
Click to collapse
Yes, I know about all those things, but I was asking why you think they need to be tweaked? The defaults, seem to work just fine.

@mirabilos : Thank you for your detailed replies, and I would be more than happy to contribute if you see anything from the content I posted.
It is interesting to see the other possibilities for turning off xtrace within the PS1. I didn't even realize you could set positional parameters after the set -x... I think I like that one the most. It just seems more array-like and streamlined, although I guess the same number of variables is still used. I look forward to seeing what updates you'll have on the exit trap and localization. This is something I'd like to toy around with.
I took your advice and set out to get a mksh static built. I ended up compiling with GCC, running "LDSTATIC=-static ./Build.sh" in the mksh source directory. I'm pretty new to cross compiling, so I didn't really get that far or try that hard before chrooting to a fresh Ubuntu terminal on my Nexus, installing GCC, and compiling there. The only thing I changed in the source code was ${ENV:-~/.mkshrc} to ${ENV:-/system/etc/mkshrc} in the "main.c" source file. I can include this in the OP though as you mentioned before. (edit: just saw this as a compiler option with Build.sh)
Edit: I see the option now in the Build.sh for changing the mkshrc path. Also, got R50 rebuilt static with klibc. Damn that got the size way down from using glibc, 684K to 204K.

R50e is released
R50e is released -- see https://www.mirbsd.org/mksh.htm#clog

Hi @7175, good stuffs here man :good:
I've been using your modded mkshrc, and I can see a hell of a lot of work you put into it. Looks really cool. Plus it's really a good place to learn for someone like me, I definitely had learnt a lot for the past few days. Tons of aliases too, and I'm getting used to using it now. I really appreciate your stuffs here, hope to see more of it

alanthehat said:
R50e is released -- see https://www.mirbsd.org/mksh.htm#clog
Click to expand...
Click to collapse
Thanks for the heads up. Updated the binaries posted in the 2nd OP to mksh R50e.
Reinkaos said:
Hi @7175, good stuffs here man :good:
I've been using your modded mkshrc, and I can see a hell of a lot of work you put into it. Looks really cool. Plus it's really a good place to learn for someone like me, I definitely had learnt a lot for the past few days. Tons of aliases too, and I'm getting used to using it now. I really appreciate your stuffs here, hope to see more of it
Click to expand...
Click to collapse
Thanks for the feedback man! Glad it's been a good learning experience like it has been for me.

7175 said:
Thanks for the feedback man! Glad it's been a good learning experience like it has been for me.
Click to expand...
Click to collapse
Well, thanks for the updated binary! Anyway, anything you can recommend me to read other than the man page in OP? And I have one more question, what's the difference between the busybox (I got one from your other thread) and yours busybox.ndk?

While I’m the upstream developer of mksh, hacking it has also been a good learning experience for me.
So it is for a friend of mine, who has taken some fundamental script frameworks I wrote, and extended it to an impressive management system, learning to code good shell while doing so.
I’m always happy when my stuff helps other people, and they share their joy! ☺
By the way: new mksh release announcements are sent over the miros-mksh mailing list (send an eMail to postmaster at mirbsd dot either org or de to subscribe).
---------- Post added at 08:40 PM ---------- Previous post was at 08:34 PM ----------
Well, we have https://www.mirbsd.org/ksh-chan.htm which collects lots of Korn Shell-related resources, although most of it is for AT&T ksh93 (the “original” Korn Shell), much also applies to mksh, though the Android OS has some special handling (especially caused by the different user-space tooling) obviously.
The shell itself behaves exactly the same across *all* supported platforms though, so (once you have set $TMPDIR to something writable for your current user) you can write Pure mksh code exactly like on Unix or Cygwin or the Macintosh or even Haiku.

mirabilos said:
While I’m the upstream developer of mksh, hacking it has also been a good learning experience for me.
So it is for a friend of mine, who has taken some fundamental script frameworks I wrote, and extended it to an impressive management system, learning to code good shell while doing so.
I’m always happy when my stuff helps other people, and they share their joy!
By the way: new mksh release announcements are sent over the miros-mksh mailing list (send an eMail to postmaster at mirbsd dot either org or de to subscribe).
---------- Post added at 08:40 PM ---------- Previous post was at 08:34 PM ----------
Well, we have https://www.mirbsd.org/ksh-chan.htm which collects lots of Korn Shell-related resources, although most of it is for AT&T ksh93 (the “original” Korn Shell), much also applies to mksh, though the Android OS has some special handling (especially caused by the different user-space tooling) obviously.
The shell itself behaves exactly the same across *all* supported platforms though, so (once you have set $TMPDIR to something writable for your current user) you can write Pure mksh code exactly like on Unix or Cygwin or the Macintosh or even Haiku.
Click to expand...
Click to collapse
Thanks for the link, and for your works on mksh too! I'm really new to shell, I'm not even that familiar with unix/linux either. But I always have been interested in shell scripting, so I'm glad that I stumbled upon this thread
Whew, that's a lot of stuff in that link you gave, definitely gonna make use of it, thanks again!

Init.d for Oreo - root required

I have created a mod (initd-DJ9) to add init.d functionality to Oreo ROMs.
Anyone who has added init.d to Nougat ROMs by patching "init.qcom.post_boot.sh" will have learnt that this does not work with Oreo.
The initd-DJ9 mod avoids that problem.
What use is init.d?
1. init.d allows you to fine-tune/tweak your device or fix problems, and to make the changes persistent (i.e., to survive reboots) without changing your ROM
2. Typical uses include: a) setting new cpu frequencies (overclock or underclock) to override the stock ones; b) tweak interactive governor values; c) disable/enable cpu cores; d) running fstrim on your device's storage; d) retrieve hardware information that is normally difficult to ascertain; e) tweak I/O values; f) set the brightness of led/torch; g) do certain things that you want to happen each time the phone is booted up, etc, etc. - see the sample script that is attached.
Downloads
1A initd-DJ9 installer: Generic (activated on boot_completed)
OR;
1B. initd-DJ9 installer: Snapdragon only (activated on completion of qcom post-boot)
2. Readme
3. Sample init.d script (updated)
Installation
1. Backup your current boot image - if case something goes wrong, you can restore it with TWRP/OrangeFox recovery
2. Download your preferred initd-DJ9 zip installer to your internal (or external) SD
3. Boot to recovery
4. Install it as a normal zip, from TWRP/OrangeFox (or any other) recovery (what the installer does is to patch the boot image's ramdisk, using anykernel2 functionality by @osm0sis)
5. You are ready to roll!
Usage (your phone must be rooted)
1. Install initd-DJ9
2. Create a shell script (it must have the extension ".sh", and must have unix/linux line endings - not Windows or Mac line endings) - see the attachment below for a sample (rename it to sample.sh)
3. Copy the shell script to /system/etc/init.d/
4. Reboot the phone. Every time that the phone is booted, the init.d script(s) will be executed.
5. Check "/data/local/sysinitd.log" to see whether the scripts were executed. This file is updated on every bootup, and so you might want to delete it once in a while , so that it doesn't get too big.
6. This mod has been tested on a number of Oreo ROMs. It has not been tested on Nougat ROMs. It uses anykernel2 functionality, and so might work on Nougat and other ROMs. However, I have only tested it on Oreo. I would not recommend using it on Nougat or Marshmallow ROMs. If you do, you are on your own!

For what it will be helpful???
Sent from my Redmi Note 4 using XDA-Developers Legacy app

Vinay Patani said:
For what it will be helpful???
Click to expand...
Click to collapse
See the "What use is init.d?" section in the OP.

LeoPantera said:
Sample script say 'echo "0" > /proc/touchpanel/enable_dt2w' (disable double-tap-to-wake). You echo "1" to enable?
Click to expand...
Click to collapse
All you need to do is to delete the line, or comment it out.

LeoPantera said:
This can repleace kernel aduitor run startup script?
Click to expand...
Click to collapse
If you are asking about running scripts during the bootup process, then "yes".

Thank you for this.
One question though, is root required for your init.d mod to function or just to push the scripts and set the required permission.
I tried to figure it out by looking at the codes but I'm kinda noob to this.

thapaavijeet said:
Thank you for this.
One question though, is root required for your init.d mod to function or just to push the scripts and set the required permission.
I tried to figure it out by looking at the codes but I'm kinda noob to this.
Click to expand...
Click to collapse
Note the "root required" in the title of the thread? Although it should be possible for the init.d process to kick in without root, you would definitely need to be rooted to use the feature. How would you create or edit your own initd scripts in the /system/etc/init.d/ directory without root?

DarthJabba9 said:
Note the "root required" in the title of the thread? Although it should be possible for the init.d process to kick in without root, you would definitely need to be rooted to use the feature. How would you create or edit your own initd scripts in the /system/etc/init.d/ directory without root?
Click to expand...
Click to collapse
If you could include the directory creation in you mod, if not already there then placing scripts in it and chmod 775 on the script can be done though TWRP file manager itself.
The code should be something like this but I'm not sure about it. However, I was able to place scripts through custom recoveries on un rooted devices.
Code:
INITDIR=/system/etc/init.d
if [ ! -d $INITDIR ]; then
mkdir -p $INITDIR
fi

thapaavijeet said:
If you could include the directory creation in you mod, if not already there then placing scripts in it and chmod 775 on the script can be done though TWRP file manager itself.
Click to expand...
Click to collapse
All that is already there.

Can you correct me if this init.d script is right or wrong, if it is wrong how would it be right?
#!/system/bin/sh
# Cloudflare DNS
iptables -t nat -A OUTPUT -p tcp --dport 53 -j DNAT --to-destination 1.1.1.1:53
iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to-destination 1.0.0.1:53
iptables -t nat -I OUTPUT -p tcp --dport 53 -j DNAT --to-destination 1.1.1.1:53
iptables -t nat -I OUTPUT -p udp --dport 53 -j DNAT --to-destination 1.0.0.1:53
setprop net.eth0.dns1 1.1.1.1
setprop net.eth0.dns2 1.0.0.1
setprop net.dns1 1.1.1.1
setprop net.dns2 1.0.0.1
setprop net.ppp0.dns1 1.1.1.1
setprop net.ppp0.dns2 1.0.0.1
setprop net.rmnet0.dns1 1.1.1.1
setprop net.rmnet0.dns2 1.0.0.1
setprop net.rmnet1.dns1 1.1.1.1
setprop net.rmnet1.dns2 1.0.0.1
setprop net.pdpbr1.dns1 1.1.1.1
setprop net.pdpbr1.dns2 1.0.0.1
setprop 2606:4700:4700::1111
setprop 2606:4700:4700::1001

DarthJabba9 said:
I have created a mod (initd-DJ9) to add init.d functionality to Oreo ROMs.
Anyone who has added init.d to Nougat ROMs by patching "init.qcom.post_boot.sh" will have learnt that this does not work with Oreo.
The initd-DJ9 mod avoids that problem.
What use is init.d?
1. init.d allows you to fine-tune/tweak your device or fix problems, and to make the changes persistent (i.e., to survive reboots) without changing your ROM
2. Typical uses include: a) setting new cpu frequencies (overclock or underclock) to override the stock ones; b) tweak interactive governor values; c) disable/enable cpu cores; d) running fstrim on your device's storage; d) retrieve hardware information that is normally difficult to ascertain; e) tweak I/O values; f) set the brightness of led/torch; g) do certain things that you want to happen each time the phone is booted up, etc, etc. - see the sample script that is attached.
Downloads
1A initd-DJ9 installer: Generic (activated on boot_completed)
OR;
1B. initd-DJ9 installer: Snapdragon only (activated on completion of qcom post-boot)
2. Readme
3. Sample init.d script (updated)
Installation
1. Backup your current boot image - if case something goes wrong, you can restore it with TWRP/OrangeFox recovery
2. Download your preferred initd-DJ9 zip installer to your internal (or external) SD
3. Boot to recovery
4. Install it as a normal zip, from TWRP/OrangeFox (or any other) recovery (what the installer does is to patch the boot image's ramdisk, using anykernel2 functionality by @osm0sis)
5. You are ready to roll!
Usage (your phone must be rooted)
1. Install initd-DJ9
2. Create a shell script (it must have the extension ".sh", and must have unix/linux line endings - not Windows or Mac line endings) - see the attachment below for a sample (rename it to sample.sh)
3. Copy the shell script to /system/etc/init.d/
4. Reboot the phone. Every time that the phone is booted, the init.d script(s) will be executed.
5. Check "/data/local/sysinitd.log" to see whether the scripts were executed. This file is updated on every bootup, and so you might want to delete it once in a while , so that it doesn't get too big.
6. This mod has been tested on a number of Oreo ROMs. It has not been tested on Nougat ROMs. It uses anykernel2 functionality, and so might work on Nougat and other ROMs. However, I have only tested it on Oreo. I would not recommend using it on Nougat or Marshmallow ROMs. If you do, you are on your own!
Click to expand...
Click to collapse
-------
Thank you,
finally, I drop here and found a solution to enable init.d for Mido SND (stock kernel-Android N)
Try a lot solutions around but seem not to work (cann't find /data/init_test.log), even the solution to put scripts in magisk/.core/post-fs-data.d,...etc
until this zip (patch boot.img) is working for me

[ROOT][SamPWND][N960U][WIP-Combo Needed]

Hello XDA!
Samsung has been semi SamPWND again!
Disclaimer:
This root method was developed and tested on the N960U model. This is the only model I have that is a Samsung device. I do have friends and other devs however that have tested this method on various other Samsung devices on both Qualcomm and Exynos chipsets and it has worked on a good number of them meaning this method is not limited to the Note 9. With that being said, due to all the time I have already spent on this and not having any other devices, I will ONLY be supporting the N960U. So do not get upset if I do not respond to you if you have a Samsung A8934839K312 on 7.1 Android (aka a device I have never even heard of before.)
Disclaimer 2:
This root method is mainly for dev's or those who like to tinker and figure things out. The reason I say this is because at this time, you are REQUIRED to be on a factory/combination firmware to mess with the root method. I will ignore any comments/questions for people who do not read this disclaimer and ask me how to root stock etc. as that is what I have been trying to do for over a month now. If you need your phone for work or a daily then I suggest only messing with this root method if you have a lot of spare time since it involves flashing combo firmware at which mobile services and other stuff will not be functional. You have been warned!
Disclaimer 3:
This thread/poc are essentially to get you the ability to use root apps and have a root shell, that is it. If I have time and see some questions that are legit questions I will try to provide help in a timely manner. This POC simply pushes busybox binary from Magisk.zip and SuperSU (the last version chains released before retirement) and installs it in sbin/daemon mode. There is also a way to install MagiskSU in daemon mode as well as ways to install root to /system/xbin for example and do mods such as Xposed that typically need to modify the system partition but that is not the purpose of this thread and these methods are a bit more involved (require modifying the root script as well as setting up bind mounts and other stuff.) Hopefully once this is released and some devs chime in I hope there will eventually be others contributing with various root scripts, install methods etc. and of course HOPEFULLY find a way to write to system/odm/vendor partitions so we can eventually run root on stock!
Disclaimer 4:
I am NOT responsible if you break your phone, wipe your IMEI, hard brick etc. etc.! Also, I spent months to get to this point and already had someone steal my files from AFH (I know, my fault for not hiding them) so please do not take my work as your own. If you want to use it in any way/shape/form just ask for permission and/or give credits in your thread is all I ask! If you are however using someone else's modified files and in here trying to get help I might turn you away (back to the person who provided the modified files) just an FYI!
I think that is enough disclaimers for now!
Note: This thread will most likely be ugly for a bit as I am terrible with making these things look pretty... Hopefully as time goes I will keep improving it or find someone who is trustworthy I can make a "contributor" so they can fix it up for me haha.
Now, Let's Get To It!
Technical Details:
This is sort of a spawn from an exploit I found and reported to Samsung back on the Tab S3 that I never released on XDA. That method (long story short) involved modifying the Persist partition and flashing it in ODIN as ODIN did not check it for integrity. Of course it was patched by Samsung who gave me some $$$ and gave me a shout out on their security bulletin which was pretty cool!
This method is similar to "Persist Root" except we are not flashing any modified partitions in ODIN. Instead, on many Samsung combination firmwares there is an init rc script on /system. If you want to know if your device is compatible a good starting point would be to look for a file called "init.lab.rc" which is typically located at "/system/etc/init/init.lab.rc" like so:
-rw-r--r-- 1 root root ubject_r:system_file:s0 14784 2008-12-31 10:00 init.lab.rc
As it stands, we cannot edit this script. I noticed something cool however when I was reading it one day. Specifically one thing that caught my eye was this:
chmod 777 /data/lab/run_lab_app.sh
There are MANY files and scripts at /data/lab. Luckily, the init.lab.rc sets permissions to "0777" and sets ownership to system on the entire /data/lab directory! If you are still with me, this means all the contents of this directory are world readable/writeable and we can modify any of the files in this DIR without elevated privileges!
Now I am showing the "run_lab_app.sh" script specifically for a reason. We know we can modify any scripts on /data/lab, but how can we execute it with elevates privileges? Going back to the init.lab.rc, if you scroll to the bottom of the rc file you will see this:
service start_abc /system/bin/sh /data/lab/run_lab_app.sh factory abc+
user system
group system
disabled
oneshot
on property:sec.lab.abc.start=1
start start_abc
setprop sec.lab.abc.start 0
Now what that means is, when you set the property "sec.lab.abc.start" to "1" it executes the abc service as system user and more specifically it will start by executing the "run_lab_app.sh" script! Therefore, after you modify the script to your liking, push it to /data/lab/run_lab_app.sh, then do a "setprop sec.lab.abc.start 1" your script will be executed as system user!
Now system obviously is not "root". Now that we can execute as system user we have more attack vectors to elevate privileges even more. Ideally, I remembered how I rooted the Tab S3 about a year ago using Persist partition. As it stands, we are not able to read/write on persist. If we were to set permissions however on /persist using the run_lab_app.sh script, then we can gain access to it! Therefore, one would only need to add this command to the run_lab_app.sh script and execute it using the setprop command:
chmod -R 0777 /persist
As soon as you modify the script, push it and execute the setprop command, it will change permissions on the /persist DIR to be world readable/writeable!
Now, the reason why I like to use Persist, there is a script that is executed by INIT on every reboot automatically (this means it is executed by root!) The script in question is this one "/persist/coresight/qdss.agent.sh." (I am not sure if this script itself is a Qualcomm specific script or not.) Modifying this script has no ill effects on anything from what I have seen.
Now to see how the script is executed you can look in "/vendor/etc/init/hw/init.qcom.test.rc" and you will see some interesting stuff including this:
crownqltesq:/vendor/etc/init/hw # cat init.qcom.test.rc | grep persist
service cs-early-boot /vendor/bin/sh /persist/coresight/qdss.agent.sh early-boot /vendor/bin/init.qcom.debug.sh
service cs-post-boot /vendor/bin/sh /persist/coresight/qdss.agent.sh post-boot /vendor/bin/init.qcom.debug.sh
write /persist/coresight/enable 1
write /persist/coresight/enable 0
crownqltesq:/vendor/etc/init/hw #
As I stated earlier, due to this init script, the qdss.agent.sh script is executed by init context/root user automatically during early boot and post boot. This means once you get everything set up, you won't need to keep reinstalling root (unless you mess something up) on each reboot. This is ideal since we don't have a way yet to modify system/vendor/odm partitions yet. Think of it as a "systemless" root.
For the POC I have provided in this thread for example, it contains the bare minimum SU files. The files in the attached zip are simple: SamPWND.bat, sampwnd1.sh, sampwnd2.sh, /sampwnd which contains su, sukernel, supolicy, libsupol.so and busybox. The way it works is this:
1) You double click the .bat file and it should do everything for you! The .bat file will:
- Push sampwnd1.sh to /data/lab/run_lab_app.sh
- Execute the lab script by doing "setprop sec.lab.abc.start 1"
- Push sampwnd2.sh to /persist/coresight/qdss.agent.sh
- Push root files in "sampwnd" folder to /persist/coresight/sampwnd
- Set permissions on the files we just pushed to Persist to 0777
- Reboot the device (Note: The .bat file reboots the device at this point since everything is in place to root when the device reboots, it's that simple!)
After the device reboots, you should now be able to use a root shell as well as sideloading any root apps will work (apps such as TiBu, Root Explorer, Flashfire etc. etc.)
When the device reboots, the qdss.agent.sh script does the following automatically:
1) Mounts rootfs and sets permissions to 0777 so we can access /sbin
2) Pushes the contents of the root files folder "sampwnd" to /sbin
3) Sets permissions to the files we just moved to /sbin
4) Exports the LIB path to /sbin due to the libsupol.so being needed to patch the sepolicy with supolicy
- The export command is "export LD_LIBRARY_PATH=/sbin"
- Once the script is over and you use another app or go into a shell etc. the LIB path will be gone/reset so you don't need to
worry.
5) Patches the sepolicy for SU
6) Installs SU by executing "su --install"
7) Executes the SU daemon by running "su --daemon"
8) Lastly, remounts rootfs back to RO.
As stated earlier, these commands are all automatically executed by init/root each time you reboot the device. Essentially, whatever we put into the qdss.agent.sh script will be executed on boot by init/root. If for some reason permissions are lost, we should still have our lab script and we would only need to run "setprop sec.lab.abc.start 1" to change permissions on persist again!
The initial files I provide today are just a simple root install script. I have successfully used the root script to install MagiskSU, Xposed (using bind mounts to overlay on /system) and other tests. I also at one point made a backup script that backed up all the partitions on the device into a folder which I extracted to my PC for safe keeping, you get the picture! Once you have root however, you can do these things easier as you will have root access.
Now that you know the workings of the exploit (err exploits?) I will explain briefly what is needed and how to test it.
Pre-requisites:
1) Download links will be in 2nd post.
2) For the purpose of this thread and the only device I personally have, you should have a N960U/U1/W on a rev1 bootloader (there isn't a rev2 BL yet so most should be good to go.)
3) A vulnerable Combo Firmware. I linked the one I use in Post 2. I use 1ARG4 Factory/Combo firmware. Of course you will need ODIN to flash the combo.
4) The root files/7z linked in post 2.
5) Stock firmware for when you are done playing, testing, etc. etc.
6) Almost forgot, you will need ADB. I will not go into details on this, if you don't have a working ADB Google is your friend. I recommend setting it to your path so you can use ADB from anywhere on the PC.
Install Instructions:
1) Extract the root files 7z into a DIR of your choice.
2) Flash whichever vulnerable combo firmware you are using via ODIN.
3) Once it boots up, make sure your device is seen by adb by running "adb devices"
4) Double click the .bat file.
5) That's it! Your device will reboot and you should be rooted!
If for some reason it is not working and you are on a N960U/U1/W, there could be a number of reasons. If you are not using the 1ARG4 combo I linked then it's possible the combo you are using is not vulnerable. It could also be an issue with ADB. Sometimes if things get crazy throughout your testing you might need to reflash /persist in ODIN or reflash the combo firmware in ODIN then re-run the .bat file (I only experience this typically when I get crazy with the root script and end up losing permissions to everything or something I added in the root script is causing the device to boot-loop etc. etc.)
Now donations are not required but feel free to throw me some beer money if you want! My paypal email/link is in a few places, you shouldn't have any trouble finding it!
TELEGRAM GROUP IS COMING REAL SOON!
We will use the TGRAM to provide support, ideas, share scripts/files and HOPEFULLY, we can all figure out together how to turn this into rooting the stock firmware as this is the goal and will be the primary focus of the chat!
Credits:
@samsung - for letting us PWND them time and time again!
@chainfire - SuperSU of course
@topjohnwu - MagiskSU of course
@me2151 - For all the time and help he is going to be putting in with us! Such a great guy! lol
@jrkruse - For everything! Everything from EDL support, ROM support, Root support you name it!
@partcyborg - For also spending countless hours helping answer questions in here so I don't have to hahah
@mweinbach - He writes great articles for XDA! He is a good kid who gets his hands on cool things frequently
@"mysecretfriendfromfaraway - I will not name him haha, he knows who he is. He always helps out and gets great things!
XDA:DevDB Information
SamPWND N960U Root, Tool/Utility for the Samsung Galaxy Note 9
Contributors
elliwigy
Version Information
Status: Testing
Created 2019-05-05
Last Updated 2019-05-05