Database Info

[DISCUSSION]All about boot.img's and kernels!!!

So, I've seen many a people talk about boot.imgs, and kernels, and mostly spamming dev threads. So, why not create a new thread for it?
Here, ask your questions related to kernels and boot.imgs, and feel free to post any *improvements* that you've made to an existing boot.img/kernel, and so...
Also, feel free to join the discussion, feature requests, whether or not possible, etc, etc.
This thread might be one whole lot of junk, but still if it helps from keeping people from spamming dev threads, why not
So, start!

Lets start from the basics...
Compiling a kernel is easy, IMO :fingers-crossed:
But, the unpacking repacking stuff is a bit difficult...
Anyways, here's the basics:
Packaging kernel for flashing on target device (by sakindia123): http://forum.xda-developers.com/showpost.php?p=31656992&postcount=3
Packaging kernel for flashing on target device (by #define): http://forum.xda-developers.com/showthread.php?t=2114594 (start from step 6)

New CM11 Ramdisk changes...
Well, this was taking up a lot of space on the main thread... Read it here :fingers-crossed:
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
edit: some more thoughts...
If you're going to boot this ROM from your SD Card, then, better beware of the new changes in the mounting process... A new fstab.pico is handling the mounting processes..
And, its moved from init.rc to init.pico.rc :|
So, If you're gonna do the editing stuff, you'd find that init.pico.rc has:
Code:
on fs
# mount mtd partitions
# Mount /system rw first to give the filesystem a chance to save a checkpoint
mount yaffs2 [email protected] /system
mount yaffs2 [email protected] /system ro remount
mount yaffs2 [email protected] /data nosuid nodev
mount yaffs2 [email protected] /cache nosuid nodev
# mount partitions
mount_all /fstab.pico
So, if you're gonna just edit those lines, and just change the [email protected], or the [email protected] lines, then, you'd likely be pretty much booting the ROM again from your internal nand. the main reason for this being the line below: mount_all /fstab.pico, which is the fstab.pico I was talking about...
Now, if you'd open up fstab.pico, its pretty much like the /etc/fstab that you'd find on any linux system. the typical device, mountpoint, type and all... If you'd open it, you'll find this:
Code:
#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>
/dev/block/mtdblock3 /system yaffs2 ro,barrier=1 wait
/dev/block/mtdblock4 /cache yaffs2 nosuid,nodev,barrier=1 wait,check
/dev/block/mtdblock5 /data yaffs2 nosuid,nodev,noauto_da_alloc,barrier=1 wait,check
/devices/platform/msm_sdcc.1/mmc_host/mmc0 auto vfat defaults voldmanaged=sdcard0:auto
Well, those were the lines from the CM11 preview, not exactly the same, the last line was derped by me in my vain attempts to get the sdcard running... Oh, and the mounting of the SD Card's completely changed too :silly:
BTW, getting back to mounting the ROM from the sdcard, you'd need to edit this fstab.pico file, to something similar to this:
Code:
#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>
/dev/block/mmcblk0p2 /system ext4 ro,barrier=1 wait
/dev/block/mmcblk0p4 /cache ext4 nosuid,nodev,barrier=1 wait,check
/dev/block/mmcblk0p3 /data ext4 nosuid,nodev,noauto_da_alloc,barrier=1 wait,check
/devices/platform/msm_sdcc.1/mmc_host/mmc0 auto vfat defaults voldmanaged=sdcard0:auto

Well this is the first post, asking for help... Hope you get the hint *wink *wink
In case you can't get something done, ask for help here!
I tried porting the touchscreen gestures from Siyah Kernel with reference from this commit: https://github.com/gokhanmoral/siyahkernel3/commit/9f57d9efc7458c1a9f540cd04bc5cb14e08fb342
Well, that more or less turned out to be like this: https://github.com/vineethraj49/android_kernel_htc_pico/tree/gestures (check the last few commits...)
And, turns out it works :laugh: with a small bug
1. only single finger gestures work, i think....
2. no way to get the infinite while loop started at init.d
Here's how I did it... Reference thread: http://forum.xda-developers.com/showthread.php?t=1831254
the init.d script is as belows, doesn't work...
Code:
#!/system/bin/sh
echo "
# Gesture 1 - swipe 1 finger near the top
1:1:(0|150,0|150)
1:1:(210|320,0|150)
" > /sys/devices/virtual/misc/touch_gestures/gesture_patterns
while [ 1 ]
do
GESTURE=`cat /sys/devices/virtual/misc/touch_gestures/wait_for_gesture`
if [ "$GESTURE" == "1" ]; then
screencap > /sdcard/`date +%H%M%S.png`
fi;
done
So, inputted those commands using adb, in adb shell, and it works... Got a hell lot of screenshots... but, any way to fix the bugs I mentioned?

Hey, one question
I'd like to know about one thing, I've seen people talking about memory increasing kernels and kernels that mount certain partitions(like cache, data etc. etc. ) . i want to know how this works? I mean, what all things are to be done in both things for them to work?
I'll be glad if you tell this to me in a noob-friendly way. :victory:
Thank You! :fingers-crossed:

#Superuser said:
Hey, one question
I'd like to know about one thing, I've seen people talking about memory increasing kernels and kernels that mount certain partitions(like cache, data etc. etc. ) . i want to know how this works? I mean, what all things are to be done in both things for them to work?
I'll be glad if you tell this to me in a noob-friendly way. :victory:
Thank You! :fingers-crossed:
Click to expand...
Click to collapse
Note: memory increasing kernels and, kernels that mount certain partitions(like cache, data etc. etc. ) both do the exact same thing.
Clarifications:
1. There's no such thing as a memory increasing kernel, and there can't be. No!? Why not? Because, however much memory's present, so, remains. This particular *myth* comes from the slang "memory increasing scripts", i.e. scripts that mount an external SD Card's partition as the internal /data partition.
2. The kernel doesn't increase the memory (check clarification 1). The increasing in memory is done by reverse-mounting (yes, reverse-mounting partitions, is a fairly popular slang for this practice) partitions from the SDCard as the internal partitions, and thus, the phone thinks that it has a more storage, than its own internal storage.
So, how does the memory increasing get done?
Ramdisks! These are the files that go on form the root file system. The kernel itself is packed with the ramdisk. A typical android bootup sequence is this: (thanks to the writers of this article here: http://elinux.org/Android_Booting)
1. The first program which runs on any Android system is the bootloader. Technically, the bootloader is outside the realm of Android itself, and is used to do very low-level system initialization, before loading the Linux kernel. The kernel then does the bulk of hardware, driver and file system initialization, before starting up the user-space programs and applications that make up Android.
2. 'init'
A key component of the Android bootup sequence is the program 'init', which is a specialized program for initializing elements of the Android system. Unlike other Linux systems (embedded or otherwise), Android uses its own initialization program. (Linux desktop systems have historically used some combination of /etc/inittab and sysV init levels - e.g. /etc/rc.d/init.d with symlinks in /etc/rc.d/rc.). Some embedded Linux systems use simplified forms of these -- such as the init program included in busybox, which processes a limited form of /etc/inittab, or a direct invocation of a shell script or small program to do fixed initialization steps.
The Android 'init' program processes two files, executing the commands it finds in them, called 'init.rc' and 'init.<machine_name>.rc', where <machine_name> is the name of the hardware that Android is running on. (Usually, this is a code word. The name of the HTC1 hardware for the ADP1 is 'trout', and the name of the emulator is 'goldfish'.
The 'init.rc' file is intended to provide the generic initialization instructions, while the 'init.<machine_name>.rc' file is intended to provide the machine-specific initialization instructions.
====================================================================================================
Now, that's the general booting process. Now, lets look into our phone's booting process. The bootloader is "HBOOT" specialised for our phones, made by HTC.
This boots up the hardware, loads the kernel, and, the "init" process starts running. If you unpack any kernel you'd find these two files:
Code:
init.rc
init.pico.rc
As you'd have guessed by now, the init.rc is general instructions, and init.pico.rc is the hardware device specific parts.
The init process is what will set up all native services and this is similar to a regular Linux system boot.
So, the init process is also the reason why the filesystems are mounted. If you'd open up any init.rc file, you'd find these lines:
Code:
on fs
# mount mtd partitions
# Mount /system rw first to give the filesystem a chance to save a checkpoint
mount yaffs2 [email protected] /system
mount yaffs2 [email protected] /system ro remount
mount yaffs2 [email protected] /data nosuid nodev
mount yaffs2 [email protected] /cache nosuid nodev
This language is commonly known as the "Android Init Language", and you can look up for help here: https://android.googlesource.com/platform/system/core/+/master/init/readme.txt
So, this is where the filesystems get mounted.
Now, to make a reverse-mounting boot.img, we'd need to modify these lines. Lets mount the second partition in the SD Card in the data partition. So, we'd simply replace this line:
Code:
mount yaffs2 [email protected] /data nosuid nodev
with a modified line, like this:
Code:
mount ext4 /dev/block/mmcblk0p2 /data nosuid nodev
If you'd see, this follows this configuration:
mount <type> <device> <dir> [ <mountoption> ]*
Now, the nosuid, nodev, etc are mountoptions. There are a variety of mount options, and the right choice of them, is likely to make your mounted partition accessible faster. Example: You can disable journaling, or use a different method of journaling, so that, you get access to the partitions faster, and as a direct result, your phone *might* become faster. The general mount options can be found here: http://linux.die.net/man/8/mount
So, that's about how you do the "reverse-mounting" thing.
p.s. here's the mount config that I usually use. Also posting the reasons
p.p.s. I use an ext4 partition
Code:
mount ext4 /dev/block/mmcblk0p2 /data nosuid nodev noatime nodiratime nouser norelatime nostrictatime noiversion nobarrier noauto_da_alloc nouser_xattr data=writeback commit=30 inode_readahead_blks=64 errors=continue
Code:
# [*]nosuid - Do not allow set-user-identifier or set-group-identifier bits to take effect.
# [*]nodev - Do not interpret character or block special devices on the file system.
# [*]noatime - Do not update inode access times on this filesystem.
# [*]nodiratime - Do not update directory inode access times on this filesystem.
# [*]nouser - Forbid an ordinary (i.e., non-root) user to mount the filesystem. This is the default.
# [*]norelatime - Do not use relatime feature. See also the strictatime mount option.
# [*]nostrictatime - Use the kernel's default behaviour for inode access time updates.
# [*]noiversion - Do not increment the i_version inode field.
# [**]nobarrier - This enables/disables barriers. nobarrier disables it, barrier enables it. Write barriers enforce proper on-disk ordering of journal commits, making volatile disk write caches safe to use, at some performance penalty.
# data=writeback - Data ordering is not preserved - data may be written into the main filesystem after its metadata has been committed to the journal. This is rumoured to be the highest-throughput option. It guarantees internal filesystem integrity, however it can allow old data to appear in files after a crash and journal recovery.
# commit=30 - Sync all data and metadata every 30 seconds. The default value is 5 seconds. Zero means default. (Setting it to very large values will improve performance.)
# noauto_da_alloc - http://forum.xda-developers.com/showthread.php?t=876069
# nouser_xattr - Support "user." extended attributes (or not).
# errors=continue - errors={continue|remount-ro|panic} Define the behaviour when an error is encountered. (Either ignore errors and just mark the filesystem erroneous and continue,
# inode_readahead_blks=64 -set to 64 from default 32

thewisenerd said:
Note: memory increasing kernels and, kernels that mount certain partitions(like cache, data etc. etc. ) both do the exact same thing.
Clarifications:
1. There's no such thing as a memory increasing kernel, and there can't be. No!? Why not? Because, however much memory's present, so, remains. This particular *myth* comes from the slang "memory increasing scripts", i.e. scripts that mount an external SD Card's partition as the internal /data partition.
2. The kernel doesn't increase the memory (check clarification 1). The increasing in memory is done by reverse-mounting (yes, reverse-mounting partitions, is a fairly popular slang for this practice) partitions from the SDCard as the internal partitions, and thus, the phone thinks that it has a more storage, than its own internal storage.
So, how does the memory increasing get done?
Ramdisks! These are the files that go on form the root file system. The kernel itself is packed with the ramdisk. A typical android bootup sequence is this: (thanks to the writers of this article here: http://elinux.org/Android_Booting)
1. The first program which runs on any Android system is the bootloader. Technically, the bootloader is outside the realm of Android itself, and is used to do very low-level system initialization, before loading the Linux kernel. The kernel then does the bulk of hardware, driver and file system initialization, before starting up the user-space programs and applications that make up Android.
2. 'init'
A key component of the Android bootup sequence is the program 'init', which is a specialized program for initializing elements of the Android system. Unlike other Linux systems (embedded or otherwise), Android uses its own initialization program. (Linux desktop systems have historically used some combination of /etc/inittab and sysV init levels - e.g. /etc/rc.d/init.d with symlinks in /etc/rc.d/rc.). Some embedded Linux systems use simplified forms of these -- such as the init program included in busybox, which processes a limited form of /etc/inittab, or a direct invocation of a shell script or small program to do fixed initialization steps.
The Android 'init' program processes two files, executing the commands it finds in them, called 'init.rc' and 'init.<machine_name>.rc', where <machine_name> is the name of the hardware that Android is running on. (Usually, this is a code word. The name of the HTC1 hardware for the ADP1 is 'trout', and the name of the emulator is 'goldfish'.
The 'init.rc' file is intended to provide the generic initialization instructions, while the 'init.<machine_name>.rc' file is intended to provide the machine-specific initialization instructions.
====================================================================================================
Now, that's the general booting process. Now, lets look into our phone's booting process. The bootloader is "HBOOT" specialised for our phones, made by HTC.
This boots up the hardware, loads the kernel, and, the "init" process starts running. If you unpack any kernel you'd find these two files:
Code:
init.rc
init.pico.rc
As you'd have guessed by now, the init.rc is general instructions, and init.pico.rc is the hardware device specific parts.
The init process is what will set up all native services and this is similar to a regular Linux system boot.
So, the init process is also the reason why the filesystems are mounted. If you'd open up any init.rc file, you'd find these lines:
Code:
on fs
# mount mtd partitions
# Mount /system rw first to give the filesystem a chance to save a checkpoint
mount yaffs2 [email protected] /system
mount yaffs2 [email protected] /system ro remount
mount yaffs2 [email protected] /data nosuid nodev
mount yaffs2 [email protected] /cache nosuid nodev
This language is commonly known as the "Android Init Language", and you can look up for help here: https://android.googlesource.com/platform/system/core/+/master/init/readme.txt
So, this is where the filesystems get mounted.
Now, to make a reverse-mounting boot.img, we'd need to modify these lines. Lets mount the second partition in the SD Card in the data partition. So, we'd simply replace this line:
Code:
mount yaffs2 [email protected] /data nosuid nodev
with a modified line, like this:
Code:
mount ext4 /dev/block/mmcblk0p2 /data nosuid nodev
If you'd see, this follows this configuration:
mount <type> <device> <dir> [ <mountoption> ]*
Now, the nosuid, nodev, etc are mountoptions. There are a variety of mount options, and the right choice of them, is likely to make your mounted partition accessible faster. Example: You can disable journaling, or use a different method of journaling, so that, you get access to the partitions faster, and as a direct result, your phone *might* become faster. The general mount options can be found here: http://linux.die.net/man/8/mount
So, that's about how you do the "reverse-mounting" thing.
p.s. here's the mount config that I usually use. Also posting the reasons
p.p.s. I use an ext4 partition
Code:
mount ext4 /dev/block/mmcblk0p2 /data nosuid nodev noatime nodiratime nouser norelatime nostrictatime noiversion nobarrier noauto_da_alloc nouser_xattr data=writeback commit=30 inode_readahead_blks=64 errors=continue
Code:
# [*]nosuid - Do not allow set-user-identifier or set-group-identifier bits to take effect.
# [*]nodev - Do not interpret character or block special devices on the file system.
# [*]noatime - Do not update inode access times on this filesystem.
# [*]nodiratime - Do not update directory inode access times on this filesystem.
# [*]nouser - Forbid an ordinary (i.e., non-root) user to mount the filesystem. This is the default.
# [*]norelatime - Do not use relatime feature. See also the strictatime mount option.
# [*]nostrictatime - Use the kernel's default behaviour for inode access time updates.
# [*]noiversion - Do not increment the i_version inode field.
# [**]nobarrier - This enables/disables barriers. nobarrier disables it, barrier enables it. Write barriers enforce proper on-disk ordering of journal commits, making volatile disk write caches safe to use, at some performance penalty.
# data=writeback - Data ordering is not preserved - data may be written into the main filesystem after its metadata has been committed to the journal. This is rumoured to be the highest-throughput option. It guarantees internal filesystem integrity, however it can allow old data to appear in files after a crash and journal recovery.
# commit=30 - Sync all data and metadata every 30 seconds. The default value is 5 seconds. Zero means default. (Setting it to very large values will improve performance.)
# noauto_da_alloc - http://forum.xda-developers.com/showthread.php?t=876069
# nouser_xattr - Support "user." extended attributes (or not).
# errors=continue - errors={continue|remount-ro|panic} Define the behaviour when an error is encountered. (Either ignore errors and just mark the filesystem erroneous and continue,
# inode_readahead_blks=64 -set to 64 from default 32
Click to expand...
Click to collapse
Three words - YOU ARE GREAT! I mean, in the whole explanation you did, I just knew that there is some reverse mounting in init.rc in which few partitions are mounted as data/cache and you cleared my concepts. One more thing related to this I'd like to ask, in sense based roms(For our device) is it possible to do changes in init.rc(which I guess would be required) so that apps are directly installed in sd-ext and the symlink also gets done.
Once again,
THANKS

thewisenerd said:
Note: memory increasing kernels and, kernels that mount certain partitions(like cache, data etc. etc. ) both do the exact same thing.
Clarifications:
Click to expand...
Click to collapse
Lol thats a huge explanation! :good: :highfive:

#Superuser said:
Three words - YOU ARE GREAT! I mean, in the whole explanation you did, I just knew that there is some reverse mounting in init.rc in which few partitions are mounted as data/cache and you cleared my concepts. One more thing related to this I'd like to ask, in sense based roms(For our device) is it possible to do changes in init.rc(which I guess would be required) so that apps are directly installed in sd-ext and the symlink also gets done.
Once again,
THANKS
Click to expand...
Click to collapse
Yes, it is possible. Open your init.rc and find the following line:
Code:
mkdir /data/app 0771 system system
mkdir /data/app-private 0771 system system
mkdir /data/app-asec 0700 root root
mkdir /data/app-lib 0771 system system
Now change it like this:
Code:
# For installing apps directly to /sd-ext:
mkdir /sd-ext/app 0771 system system
mkdir /sd-ext/app-private 0771 system system
mkdir /sd-ext/app-asec 0700 root root
mkdir /sd-ext/app-lib 0771 system system
# Now the symlinking part:
symlink /sd-ext/app /data/app
symlink /sd-ext/app-private /data/app-private
symlink /sd-ext/app-asec /data/app-asec
symlink /sd-ext/app-lib /data/app-lib
NOTE: Before doing this make sure that you have mounted /sd-ext partition.

@thewisenerd....excellent post.....cleared so many doubts....You are really great.
I have a question, I am no dev but just trying to learn some basics about android. As u said that ramdisk does the job of mounting sd partitions using the reverse mounting thing. What is the job of the scripts like int2ext or ungaze or mount2sd.
Is it like when the reverse mounting is not done in ramdisk we need to use these scripts. If yes, then how do these scripts talk 2 ramdisk or kernel to tell them to mount these sd partitions.
I know this may sound noob to you. But m just trying to learn some basics.

@cute_prince Thanks. Now, I'm gonna post all my doubt related to kernels and ramdisks! Thanks to @thewisenerd as well!

cuteitsme said:
@thewisenerd....excellent post.....cleared so many doubts....You are really great.
I have a question, I am no dev but just trying to learn some basics about android. As u said that ramdisk does the job of mounting sd partitions using the reverse mounting thing. What is the job of the scripts like int2ext or ungaze or mount2sd.
Is it like when the reverse mounting is not done in ramdisk we need to use these scripts. If yes, then how do these scripts talk 2 ramdisk or kernel to tell them to mount these sd partitions.
I know this may sound noob to you. But m just trying to learn some basics.
Click to expand...
Click to collapse
Everyone's a newbie (unless they remain to stay a n00b). Anyways, let's get back to on-topic.
So... How does these files in
Code:
/system/init.d/<insert-script-name>
cause the reverse-mount?
For this, we look back, into the init.rc and init.pico.rc files
If you'd read this, https://android.googlesource.com/platform/system/core/+/master/init/readme.txt, you'd find that the Android Init Language gives you an "exec" command for running apps/scripts. So, you should have gotten the hint by now
So, open up init.rc and search for any "exec" command. I can just make it easier, but I want you to find any "exec" call that runs processes from /system/*.
OFC, I'd be telling the answer below, but I want you to find it too
So, here's the key. You're likely to find lines as the same as, or similar to below lines:
Code:
# Run sysinit
exec /system/bin/sysinit
in any one of the *.rc files (mostly init.rc or init.pico.rc).
So, lets take a look at this file.
Below is the above file (/system/bin/sysinit) from CM10.2, weekly 9
Code:
#!/system/bin/sh
export PATH=/sbin:/system/sbin:/system/bin:/system/xbin
/system/bin/logwrapper /system/xbin/run-parts /system/etc/init.d
So, what's this, exactly?
Linux users would be familiar with the PATH variable name
And, logwrapper? Here's standard help:
Code:
Usage: logwrapper [-d] BINARY [ARGS ...]
Forks and executes BINARY ARGS, redirecting stdout and stderr to
the Android logging system. Tag is set to BINARY, priority is
always LOG_INFO.
-d: Causes logwrapper to SIGSEGV when BINARY terminates
fault address is set to the status of wait()
So, its going to execute a binary file, but which?
The next "argument" reads "/system/xbin/run-parts"
Again, here's standard help:
Code:
BusyBox v1.20.2-cm9 bionic (2012-11-18 13:31 +0100) multi-call binary.
Usage: run-parts [-t] [-l] [-a ARG] [-u MASK] DIRECTORY
Run a bunch of scripts in DIRECTORY
-t Print what would be run, but don't actually run anything
-a ARG Pass ARG as argument for every program
-u MASK Set the umask to MASK before running every program
-l Print names of all matching files even if they are not executable
So, run a bunch of scripts in a directory?
That pretty much explains why the next "argument" follows as "/system/etc/init.d ".
So, that's how init.d works :cyclops:
============================================================================================================
Now, moving on to memory increasing scripts (oh! I hate that slang)
Anyways, so, we found out that during the boot, the init.rc file is calling the /system/bin/sysinit file. If you'd notice, a few lines "above",
Here's something from http://www.kpbird.com/2012/11/in-depth-android-boot-sequence-process.html
Below is the sequence of android booting. Note that until all these processes are completed, you still see the boot logo. So, if your phone's struck at green htc screen, then, any one of this processes is.. hung.
on early-init:
Set init and its forked children's oom_adj.
Set the security context for the init process.
on init
setup the global environment
Create cgroup mount point for cpu accounting and many other things...
on fs
mount mtd partitions
on post-fs
change permissions of system directories
on post-fs-data
change permission of /data folders and sub folders
on boot
basic network init ,Memory Management ,etc
service servicemanager
start system manager to manage all native services like location, audio, shared preference etc..
service zygote
start zygote as app_process
So, the "/system/bin/sysinit" runs at the "boot" service. Also, it is run by the bootloader. So, it has full access to the root file system that the ramdisk creates. Now, to be noted: the "boot" service runs after the "fs" service, evidently, because else, you wouldn't be able to access the "/system/bin/sysinit" otherwise.
So, the "sysinit" script runs, running all the files from /system/etc/init.d with the help of busybox
That's about it
But, how does the reverse-mounting take place!?
Let me take the example of the simplest reverse mounting script I've ever found: int2ext. I've seen the mounts2sd script, and think its bloated, IMO, because why have a 1000+ lines script, when a script with >40 lines can do it :angel: ) (no offense). For me, just placing script, setting permissions, rebooting should increase the memory of my device. No roundabout stuff.
So, I'd be explaining how int2ext works, below:
Note: before you proceed, you'd have noticed that the sysinit file set the PATH variable. Its the location for all the accessible binary files. (if you don't understand this, using linux might help you understand this better ) This is similar to the PATH variable in windows too.. This just tells the system where to look for executable binary files/programs.
So, here's a very minimal int2ext script (modified to make this post smaller):
The purple lines ("Royal Blue" according to XDA), are the lines of code. Rest are my comments.
Credits go to original file, got from here: https://github.com/croniccorey/cronmod-scripts/blob/master/int2ext%20scripts/INT2EXT
## Only continue if mmcblk0p2 exists
if [ ! -e /dev/block/mmcblk0p2 ] //If /dev/block/mmcblk0p2 doesn't exist
then //then
exit //this script exists. this code's here for safety.
fi;
## Set SD cache size
SD_CACHE=/sys/devices/virtual/bdi/179:0/read_ahead_kb //read_ahead_kb is the amount of kb that the kernel reads, beforehand.
if [ -e $SD_CACHE ] //checking the existence of the file, just in case...
then
busybox echo "2048" > $SD_CACHE; //2048 is found to be an optimum value for sdcards, class 4 and better.
fi;
## Make /sd-ext directory if needed and unmount /sd-ext if it already mounted
##why? because the writer croniccorey, has done some thinking here
##will explain side by side... If the directory /sd-ext doesn't exist, its created here.
##note: the commands run by the init.rc have full access to the root file system created.
if [ ! -e /sd-ext ] //if doesn't exist sd-ext foler in root file system
then
busybox mount -o remount,rw /; //mount the root file system "/" as rewritable
busybox mkdir /sd-ext; //create a directory named sd-ext
busybox mount -o remount,ro /; //mount the file system as read-only again
else
busybox umount /sd-ext; //else, unmount the sd-ext partition, i.e. partition in the sd-card.
fi;
## Move /data mount point to /sd-ext
INT_DATA=$(busybox mountpoint -n /data | cut -d ' ' -f1) //this gets the mountpoint of the data partition.
// this command "busybox mountpoint -n /data | cut -d ' ' -f1" is actually runnable, and you'd get the mount point
// of the /data partition in the internal memory (which is this: /dev/block/mtdblock5)
busybox umount /data; //unmount the /data partition too/
// the data partition is unmounted because we're going to do some stuff
busybox mount $INT_DATA /sd-ext;
// mount the internal data partition in the sd-ext folder
## Mount mmcblk0p2 to /data
busybox mount -o noatime,nodiratime,nosuid,nodev /dev/block/mmcblk0p2 /data; //well, this is self-explanatory. mount the partition in sdcard into internal memory.
busybox chown 1000:1000 /data; //chown the folder by root (get more help by running "man chown" in a shell)
busybox chmod 771 /data; //chmod the folder (get more help by running "man chmod" in a shell)
## Move existing files
if [ ! -e /data/app ] //why /data/app? simply, it can also be anything else like /data/data...
then
busybox mv /sd-ext/* /data;
// the sd-ext folder has the files of the internal /data partition
// those are moved to the sd-card's partition, which is mounted in /data now.
fi;
## Unmount /sd-ext
//unmount the internal data partition.
// we have the partition from the sd-card mounted in the /data partition currently.
busybox umount /sd-ext;
sync;
//sync changes with file system
Click to expand...
Click to collapse
the comments should explain almost everything...
This script, is almost flawless. Couldn't find any bugs in it. Does what would have been done by changing the mount point in the "on fs" part, where it mounts the file system.
An added advantage is that this can be put into use any time you want... Example, you use your phone, internal memory gets filled up, just put this script in /system/etc/init.d, and set permissions, and reboot! voila! memory increased!
Note: reversing this can't be done by just deleting the script. an appropriate script that moves back user data to internal partitions may be needed.
Also note:
You can always tweak this command:
busybox mount -o noatime,nodiratime,nosuid,nodev /dev/block/mmcblk0p2 /data;
for better performance. Check my config, in post 8 or so... 1'st page..
You should've also guessed why we set permissions to executable, by now... Else, the file wouldn't be able to "execute"
P.S. Adding a few lines to init.rc should make it possible to have no permission change, but, that can wait for another day...

Simply awesome.....what an explanation sirji....
Still trying to understand some part but i will have to do more reading for that first....that i will do.....but must say U rock man.....thanks a lot for this....

thewisenerd said:
Everyone's a newbie (unless they remain to stay a n00b). Anyways, let's get back to on-topic.
So... How does these files in
Code:
/system/init.d/<insert-script-name>
cause the reverse-mount?
For this, we look back, into the init.rc and init.pico.rc files
If you'd read this, https://android.googlesource.com/platform/system/core/+/master/init/readme.txt, you'd find that the Android Init Language gives you an "exec" command for running apps/scripts. So, you should have gotten the hint by now
So, open up init.rc and search for any "exec" command. I can just make it easier, but I want you to find any "exec" call that runs processes from /system/*.
OFC, I'd be telling the answer below, but I want you to find it too
So, here's the key. You're likely to find lines as the same as, or similar to below lines:
Code:
# Run sysinit
exec /system/bin/sysinit
in any one of the *.rc files (mostly init.rc or init.pico.rc).
So, lets take a look at this file.
Below is the above file (/system/bin/sysinit) from CM10.2, weekly 9
Code:
#!/system/bin/sh
export PATH=/sbin:/system/sbin:/system/bin:/system/xbin
/system/bin/logwrapper /system/xbin/run-parts /system/etc/init.d
So, what's this, exactly?
Linux users would be familiar with the PATH variable name
And, logwrapper? Here's standard help:
Code:
Usage: logwrapper [-d] BINARY [ARGS ...]
Forks and executes BINARY ARGS, redirecting stdout and stderr to
the Android logging system. Tag is set to BINARY, priority is
always LOG_INFO.
-d: Causes logwrapper to SIGSEGV when BINARY terminates
fault address is set to the status of wait()
So, its going to execute a binary file, but which?
The next "argument" reads "/system/xbin/run-parts"
Again, here's standard help:
Code:
BusyBox v1.20.2-cm9 bionic (2012-11-18 13:31 +0100) multi-call binary.
Usage: run-parts [-t] [-l] [-a ARG] [-u MASK] DIRECTORY
Run a bunch of scripts in DIRECTORY
-t Print what would be run, but don't actually run anything
-a ARG Pass ARG as argument for every program
-u MASK Set the umask to MASK before running every program
-l Print names of all matching files even if they are not executable
So, run a bunch of scripts in a directory?
That pretty much explains why the next "argument" follows as "/system/etc/init.d ".
So, that's how init.d works :cyclops:
============================================================================================================
Now, moving on to memory increasing scripts (oh! I hate that slang)
Anyways, so, we found out that during the boot, the init.rc file is calling the /system/bin/sysinit file. If you'd notice, a few lines "above",
Here's something from http://www.kpbird.com/2012/11/in-depth-android-boot-sequence-process.html
Below is the sequence of android booting. Note that until all these processes are completed, you still see the boot logo. So, if your phone's struck at green htc screen, then, any one of this processes is.. hung.
on early-init:
Set init and its forked children's oom_adj.
Set the security context for the init process.
on init
setup the global environment
Create cgroup mount point for cpu accounting and many other things...
on fs
mount mtd partitions
on post-fs
change permissions of system directories
on post-fs-data
change permission of /data folders and sub folders
on boot
basic network init ,Memory Management ,etc
service servicemanager
start system manager to manage all native services like location, audio, shared preference etc..
service zygote
start zygote as app_process
So, the "/system/bin/sysinit" runs at the "boot" service. Also, it is run by the bootloader. So, it has full access to the root file system that the ramdisk creates. Now, to be noted: the "boot" service runs after the "fs" service, evidently, because else, you wouldn't be able to access the "/system/bin/sysinit" otherwise.
So, the "sysinit" script runs, running all the files from /system/etc/init.d with the help of busybox
That's about it
But, how does the reverse-mounting take place!?
Let me take the example of the simplest reverse mounting script I've ever found: int2ext. I've seen the mounts2sd script, and think its bloated, IMO, because why have a 1000+ lines script, when a script with >40 lines can do it :angel: ) (no offense). For me, just placing script, setting permissions, rebooting should increase the memory of my device. No roundabout stuff.
So, I'd be explaining how int2ext works, below:
Note: before you proceed, you'd have noticed that the sysinit file set the PATH variable. Its the location for all the accessible binary files. (if you don't understand this, using linux might help you understand this better ) This is similar to the PATH variable in windows too.. This just tells the system where to look for executable binary files/programs.
So, here's a very minimal int2ext script (modified to make this post smaller):
The purple lines ("Royal Blue" according to XDA), are the lines of code. Rest are my comments.
Credits go to original file, got from here: https://github.com/croniccorey/cronmod-scripts/blob/master/int2ext%20scripts/INT2EXT
the comments should explain almost everything...
This script, is almost flawless. Couldn't find any bugs in it. Does what would have been done by changing the mount point in the "on fs" part, where it mounts the file system.
An added advantage is that this can be put into use any time you want... Example, you use your phone, internal memory gets filled up, just put this script in /system/etc/init.d, and set permissions, and reboot! voila! memory increased!
Note: reversing this can't be done by just deleting the script. an appropriate script that moves back user data to internal partitions may be needed.
Also note:
You can always tweak this command:
busybox mount -o noatime,nodiratime,nosuid,nodev /dev/block/mmcblk0p2 /data;
for better performance. Check my config, in post 8 or so... 1'st page..
You should've also guessed why we set permissions to executable, by now... Else, the file wouldn't be able to "execute"
P.S. Adding a few lines to init.rc should make it possible to have no permission change, but, that can wait for another day...
Click to expand...
Click to collapse
I read somewhere, that init.d scripts run alphabetically, maybe this is the reason int2ext is named as 40int2ext so that it starts first?

#Superuser said:
I read somewhere, that init.d scripts run alphabetically, maybe this is the reason int2ext is named as 40int2ext so that it starts first?
Click to expand...
Click to collapse
Yeah....I guess that's the linux thing. I think the higher the no. the late the script will be called. This is basically to run the more important scripts before the other scripts.

hi i unpacked the boot.img files of cm11 beta 1 and 2 in order to understand this better and understood many things which u have explained.
I did found those lines starting with exec in some init. files.
Thanks a lot for this. Since u must be aware that the sd-ext is not mounting in buid 2 and thus int2ext is not working. So, out of curiosity I was trying to understand the difference between these two files from different builds(beta 1 and 2) but not able to find any.
Can u give any hint as to why even after having the same lines in fstab.pico of build 1 and build 2 int2ext was working in buld 1 and not in build 2. Of course by doing reverse mounting we can overcome this issue. But I am just trying to understand the difference between the two builds at ramdisk level.

cuteitsme said:
hi i unpacked the boot.img files of cm11 beta 1 and 2 in order to understand this better and understood many things which u have explained.
I did found those lines starting with exec in some init. files.
Thanks a lot for this. Since u must be aware that the sd-ext is not mounting in buid 2 and thus int2ext is not working. So, out of curiosity I was trying to understand the difference between these two files from different builds(beta 1 and 2) but not able to find any.
Can u give any hint as to why even after having the same lines in fstab.pico of build 1 and build 2 int2ext was working in buld 1 and not in build 2. Of course by doing reverse mounting we can overcome this issue. But I am just trying to understand the difference between the two builds at ramdisk level.
Click to expand...
Click to collapse
Hmm... Could you post the two boot.img's here? I'd like to have a look

thewisenerd said:
Hmm... Could you post the two boot.img's here? I'd like to have a look
Click to expand...
Click to collapse
Sure y not.....here u go

@thewisenerd: does the ION Kernel used in cyanogenmod 11 support swap

PiCo HackR said:
@thewisenerd: does the ION Kernel used in cyanogenmod 11 support swap
Click to expand...
Click to collapse
The question is: Why do you need swap?

Permission denied though uid=root

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.

[MOD] Encrypt sdcard with EncFS

Introduction
While Android allows to encrypt the /data partition this is not the case for the sdcard with many ROMs. So there are many files on the sdcard that remain accessible for wicked persons who have physical access to it. This script is an attempt to solve this problem by encrypting the content of the sdcard with the help of EncFS.
This thread is for people who have an interest to encrypt their sdcard. If you don't need it of if you want to discuss the necessity of encrypting the sdcard or encryption in general, please stay away and open a new thread if necessary.
Why EncFS?
When I was looking for a proper way to encrypt my sdcard, I wanted the following points to be fulfilled:
well-known, strong encryption method - the encrypted data should be accessible with other devices and systems (e.g. with Windows, MacOS, Linux)
conventional plain data and encrypted data on one sdcard - some file possibly should stay unencrypted (e.g. files for osmand, video files,...)
shared space for plain and encrypted data - especially with small sdcards it is more comfortable to stay with one big partition instead of splitting the sdcard
EncFS fulfills these points. Furthermore, there are working binaries and build instructions for Android thanks to Cryptionite.
Is it stable? Will it slow down my device?
I'm running my phone with encrypted sdcard for about a year now without any serious problems. I tested it with Sultanxda's CM11 KitKat ROM and ivanich's CM12 Lollipop ROM so I expect it to work at least on every CM11 and CM12 ROM. Please let me know if it works / doesn't work for you.
Using encryption will obviously slow down the read/write speed from/to sdcard. However, for me it is fast enough. As encryption and decryption is taking place in the CPU I expect the deceleration to be less on slow sdcards. But this is only an assumption.
With a SanDisk Ultra Class10 and AES 128 Bit encryption I tested the speed with the dd method on Android Lollipop:
Without encryption:
Write: 9 Mb/s
Read: 21,3 Mb/s
With EncFS encryption:
Write: 4,5 Mb/s
Read: 19,4 MB/s
Again, I hope to hear about the speed you measure.
Installation Instructions
Please backup your device before you try this! I don't know if this is working on your device and ROM. Do it at your own risk! I'm not responsible for any damage or data loss!
encrypt your /data partition. Your password for the sdcard-encryption will be stored on /data in plain text, so this is essential
install the attached zip-file via recovery
create a folder named ".encrypted" in the root of your sdcard
create an EncFS repository in the ".encrypted" folder. This is not difficult, search for howtos if you don't know what to do. You can do this on your device via adb or terminal (as root):
Code:
/system/bin/mount.encfs /sdcard/.encrypted /sdcard/decrypted
or with Linux, Windows or MacOS (via MacPorts), for example:
Code:
encfs /path-to-sdcard/.encrypted /only-temporary
save the password you entered in /data/local/passwd on your phone (adb or terminal as root)
Code:
echo "your-encfs-password-here" > /data/local/passwd
reboot
if everything works, you have the decrypted files of the ".encrypted" folder in "/storage/sdcard0" and ordinary plain files on your sdcard in "/storage/sdcard1"
now you can move the data of your apps, photos, ringtones, music,... from "/storage/sdcard1" to "/storage/sdcard0"
After flashing a new ROM, you only have to flash the zip-file again.
How does it work?
The script is executed every time you mount your sdcard (at boot and when inserting the sdcard). To achieve this, the sdcard daemon at /system/bin/sdcard is replaced with a script which performs the mounting stuff. It is looking for the ".encrypted" folder on the sdcard. If the folder exists, it decrypts it with the password stored in "/data/local/passwd". You will have the following sdcard structure dependent of the presence of the ".encrypted" folder:
".encrypted" folder is present (and "/data/local/passwd" containing the right password):
/storage/sdcard0 -> the decrypted data of .encrypted (the EncFS folder)
/storage/sdcard1 -> all the data of your sdcard
".encrypted" folder is not present:
/storage/sdcard0 -> all the data of your sdcard
So if you rename or delete the ".encrypted" folder on your sdcard, the script should react as if it doesn't exist.
There are some apps which can be configured to use another folder as "sdcard0". These can make use of "sdcard1", especially if they must access big files very fast (like Osmand or some podcast-apps).
Where is the EncFS binary from?
The EncFS binary is an ARMv7-version taken from Cryptonite. You can also build it yourself and replace the one in the zip file.

[ Reserved ]

support!!

Info
Can i encrypt/decrypt a single folder in internal sdcard?

ki1120 said:
support!!
Click to expand...
Click to collapse
Yeah.. so... I don't know what to say...
ultrasound1991 said:
Can i encrypt/decrypt a single folder in internal sdcard?
Click to expand...
Click to collapse
This is exactly what cryptonite does. You can mount single encrypted folders via a comfortable GUI.
If you want to mount the folder automatically together with the sdcard my script can also be adjusted. However, umnounting the sdcard (from settings or when connecting USB) could be prevented. This sould be tested. You can ask me if you need help.

Info
Cryptonite is no longer supported.
I have smartphone with Android L, root, and only internal sdcard.
I want to use your script to mount an encrypted folder, that contain encfs6.xml file.
Can you help me? I am not a programmer.

EncFS (FUSE) UID, GID not set, always "0" ("root")
It's old though, I was experimenting on a KitKat. All sets up fine, just the permissions part. Whatever uid and gid is set in command, folder is always mounted as uid=0 and gid=0 i.e. root when checked by 'mount' command. Mount details are as under:
Code:
[email protected]:/ # mount | grep "storage/sdcard"
encfs /storage/sdcard0 fuse.encfs rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other 0 0
/dev/fuse /storage/sdcard1 fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0
[email protected]:/ #
It's because sdcard daemon is run as root?
But apps need uid and gid 1023 (media_rw) or perhaps 1028 (sdcard_r). I'm not sure about this. As the init.qcom.rc lines say:
Code:
# create virtual SD card at /mnt/sdcard, based on the /data/media directory
# daemon will drop to user/group system/media_rw after initializing
# underlying files in /data/media wil be created with user and group media_rw (1023)
service sdcard /system/bin/sdcard -u 1023 -g 1023 -l /data/media /mnt/shell/emulated
class late_start
service fuse_sdcard1 /system/bin/sdcard -u 1023 -g 1023 /mnt/media_rw/sdcard1 /storage/sdcard1
.
Now, if I run command as user 1023 or 1028, encfs can't read /storage or /mnt directories due to restricted permissions:
Code:
[email protected]:/ # su 1023 /system/bin/mount.encfs -s -o "rw,nosuid,nodev,uid=1023,gid=1023,umask=006,allow_other" /mnt/media_rw/sdcard0/.encrypted /storage/sdcard0
The directory "/storage/sdcard0" does not exist. Should it be created? (y,n) y
Unable to create directory: : Permission denied
06:06:32 (main.cpp:435) Unable to locate mount point, aborting.
How to achieve this drop part?:
Code:
#daemon will drop to user/group system/media_rw after initializing
I think I'm missing something very simple.
And encfs latest static binary for arm can be made available somehow other than compiling? That's a real tough part.
Does EncFS work with Android 6+? If no, any similar alternatives i.e. command-line solution, not apps.

mirfatif said:
I think I'm missing something very simple.
Click to expand...
Click to collapse
Do you use the script I provided? It should create the sdcard as root before running encfs:
Code:
mkdir /storage/sdcard0 0700 root root
After that it runs encfs as root – the "drop part" is actually "uid=0,gid=01028" with which encfs mounts the encrypted folder:
Code:
/system/bin/mount.encfs -s -o "rw,nosuid,nodev,uid=0,gid=01028,umask=6,allow_other" /mnt/media_rw/sdcard0/.encrypted /storage/sdcard0
mirfatif said:
And encfs latest static binary for arm can be made available somehow other than compiling? That's a real tough part.
Click to expand...
Click to collapse
Development of Cryptonite seems quite inactive unfortunately. But there is a fork that seems to have some fixes for building, a build script and build instructions.
mirfatif said:
Does EncFS work with Android 6+? If no, any similar alternatives i.e. command-line solution, not apps.
Click to expand...
Click to collapse
I didn't test it with Android 6 as from there on adoptable storage is available. Adoptable storage fulfils most of the things I wanted for sdcard encryption (see my first post: strong encryption; conventional plain data and encrypted data). Thus, it basically makes my encfs-solution obsolete for Android 6+.

bastei said:
Do you use the script I provided? It should create the sdcard as root before running encfs:
Code:
mkdir /storage/sdcard0 0700 root root
After that it runs encfs as root – the "drop part" is actually "uid=0,gid=01028" with which encfs mounts the encrypted folder:
Code:
/system/bin/mount.encfs -s -o "rw,nosuid,nodev,uid=0,gid=01028,umask=6,allow_other" /mnt/media_rw/sdcard0/.encrypted /storage/sdcard0
Click to expand...
Click to collapse
I used these scripts without any problems on:
Android 4.4:
Code:
#!/system/bin/sh
#####################################################################################################
# DISABLE INTERNAL MEMORY (/data/media/0) AND USE EXTERNAL SD CARD AS INTERNAL STORAGE #
# ENCRYPT FILES ON EXTERNAL SD CARD FOR SECURITY #
# #
# STEPS: #
# 1. DIM i.e disable internal memory (KitKat, Lollipop), not explained here #
# #
# 2. change in boot.img > ramdisk > init.qcom.rc: #
# service fuse_sdcard0 /system/bin/sdcard -u 1023 -g 1023 -d /mnt/media_rw/sdcard0 /storage/sdcard0 #
# to #
# service fuse_sdcard1 /system/bin/sdcard -u 1023 -g 1023 -d /mnt/media_rw/sdcard0 /storage/sdcard1 #
# #
# ensure both lines exist in init.qcom.rc: #
# "mkdir /storage/sdcard1 0700 root root" and "mkdir /storage/sdcard0 0700 root root" #
# #
# 3. rename /system/bin/sdcard to sdcard_orig #
# 4. replace /system/bin/sdcard with this script (named "sdcard") #
# 5. copy encfs bianry to /system/bin #
# 6. set chmod +x permissions on all 3 files #
# #
# 7. encrypt internal storage (from settings) and save encfs password: #
# echo <your_password> | tee /data/local/pswd #
# 8. run this as root to mount encrypted directory: #
# /system/bin/encfs -o allow_other,umask=0 /mnt/media_rw/sdcard0/.encfs /data/local/SDCardTemp #
# copy all data on internal storage (/data/media/0/) to /data/local/SDCardTemp #
# reboot #
#####################################################################################################
export PATH=/system/bin:/system/xbin
# save log
mkdir -p /data/local/tmp
exec &>/data/local/tmp/encfs.log
date
echo "sdcard $*"
# mount encfs if not mounted already
if ! mountpoint /storage/sdcard0
then
cat /data/local/pswd | encfs -S /mnt/media_rw/sdcard0/.encfs /storage/sdcard0 -- -o allow_other,umask=0
# or may use uid=0,gid=1028,umask=006
fi
# pass original init command to sdcard daemon
sdcard_orig "[email protected]"
Android 5.0:
Code:
#!/system/bin/sh
# add following lines to boot.img > ramdisk > init.qcom.rc before sdcard service:
## service encfs /system/bin/encfs.sh
## oneshot
## class late_start
# save this script as /system/bin/encfs.sh
# copy encfs bianry to /system/bin
# chmod a+x /system/bin/encfs*
# echo <password> | tee /data/local/pswd
# /system/bin/encfs -o allow_other,umask=0 /data/media/encfs_crypted /data/local/SDCardTemp
# rsync -a --progress --exclude=encfs_crypted /data/media/ /data/local/SDCardTemp/
export PATH=/system/bin
# wait to avoid "PROTO_EXEC|PROTO_WRITE failed" error
sleep 5
# save log
exec &>/data/local/encfs.log
date
# mount encfs
exec cat /data/local/pswd | encfs -S /data/media_encfs_crypted /data/media -- -o uid=1023,gid=1023,umask=006,allow_other,nonempty &&
echo Mounted.
Mount options "nosuid" and "nodev" are set by default as a security measure. Mostly applications making use of FUSE (in kernel space) and optionally libfuse (in userspace) also set (or give a commandline parameters to set) "allow_other" and "default_permissions" options by default.
UMASK, UID, GID, ALLOW_OTHER
"umask" (or "dmask" and "fmask") needs to be provided explicitly to make files world accessible. Default mode set by "encfs" is 0600 (umask=177) and only mount owner (root) can access files unless every newly created file is manually chmod-ed.
Similarly, "uid" and "gid" options are needed to set desired owner/group. Default owner:group is the mount owner (0:0) unless every newly created file is manually chown-ed.
Actually mount owner and files/directories owner can be different, which was the source of my confusion. That's how FUSE is implemented to let non-privileged mounts work. Have a look at this:
user_id=N
group_id=N Specifies the numeric uid/gid of the mount owner.
This option should not be specified by the filesystem owner. It is set by libfuse (or, if libfuse is not used, must be set by the filesystem itself).​
. . .
uid=N
Override the st_uid field set by the filesystem (N is numeric).​
Click to expand...
Click to collapse
Since all "init" processes (including "sdcard" daemon) run as root (uid=0 and gid=0), 'mount' command always show "user_id=0" and "group_id=0". However it should be noted that provided "uid" and "gid" appear when we view files' ownership:
Code:
[B]/~#[/B] encfs -o allow_other,[COLOR="Red"]umask=7,uid=1023,gid=0[/COLOR] /.enc /enc
EncFS Password:
[B]/~#[/B] mount | grep enc
encfs on /encfs type fuse.encfs (rw,nosuid,nodev,relatime,[COLOR="red"]user_id=0,group_id=0[/COLOR],default_permissions,allow_other)
[B]/~#[/B] touch /enc/test
[B]/~#[/B] ls -l /.enc /enc
/.enc:
[COLOR="red"]-rw-rw-rw-[/COLOR] 1 [COLOR="Red"]0 0[/COLOR] 0 Mar 3 17:58 CoXOLL0fc0RaxZjq2HaSj9en
/enc:
[COLOR="YellowGreen"]-rwxrwx---[/COLOR] 1 [COLOR="YellowGreen"]1023 0[/COLOR] 0 Mar 3 17:58 test
[B]/~#[/B] chmod 0777 /enc/test
[B]/~#[/B] chown 0:1023 /enc/test
[B]/~#[/B] ls -l /.enc /enc
/.enc:
[COLOR="red"]-rwxrwxrwx[/COLOR] 1 [COLOR="red"]0 1023[/COLOR] 0 Mar 3 17:58 CoXOLL0fc0RaxZjq2HaSj9en
/enc:
[COLOR="YellowGreen"]-rwxrwx---[/COLOR] 1 [COLOR="YellowGreen"]1023 0[/COLOR] 0 Mar 3 17:58 test
[B]/~#[/B]
Setting "uid"/"gid" isn't necessarily required if universal access is granted using "umask=0" and "allow_other" mount options. Since every app is treated as a user on Android, so even the file explorer (same user who mounted filesystem by getting root privileges) can't access EncFS mounted directory without "allow_other" (if not running as root). So "allow_other" is necessarily required.
Mounting with "gid=9997,dmask=0007,fmask=0117,allow_other" at "/mnt/runtime/write/emulated/0/<mount_point>" on Android 6+ grants write access to apps with android.permission.WRITE_EXTERNAL_STORAGE granted. See this answer for details.
MOUNT OWNER
On Linux non-root users who are member of "fuse" group can mount and un-mount FUSE filesystems using "fusermount(3)" which is always run as root by set-UID-root or "setcap cap_sys_admin+ep". "fuse" group is the GID of "/dev/fuse". But non-privileged users can't set "allow_other" unless "user_allow_other" is set in FUSE configuration file /etc/fuse.conf. "/etc/fuse.conf" is used by "libfuse", and hence by all program depending on or linked to this library like "bindfs", "encfs", "sshfs", "rclone" and so on. So a non-root user can be the mount owner but other users (including root) can't access the mounted filesystem.
However on Android non-privileged user can't (u)mount FUSE filesystem because:
FUSE support is fully enabled from kernel side (on Linux it's usually a loadable module), can be checked by:
Code:
grep -E 'fuse|fuseblk' /proc/filesystems
But there are limitations in userspace.
There's no "fusermount" binary available on Android and the libfuse implementation doesn't use FUSE configuration because it's meant only for root users. But if we try to use binaries statically linked to standard Linux "libfuse" (like EncFS), they do read "/etc/fuse.conf" and may depend on "fusermount".
Apps on Android are run with all privileges dropped, so they can't make "mount" syscall even if "fusermount" is present with SUID bit set.
"/dev/fuse" is readable and writable only by root (0600, 0:0).
Non-root users on Android may face problem accessing filesystems (e.g. executing EncFS binary and reading "/dev/fuse") due to DAC or MAC permission checks. SELinux might need to be set "permissive" for the same reason, or the policy needs to be patched. SELinux also restricts Linux capabilities of processes.
So in short, EncFS and all other programs that make use of FUSE, can only be mounted by root on Android.
MOUNT NAMESPACE
Next important thing to be considered is "mount namespace" where even "allow_other" and root access won't help you. Mount namespaces enable apps to be exposed to an individual view of mounted filesystems. It means that "/proc/mounts" (which actually is "/proc/self/mounts") may look different to different processes. FUSE was implemented since KitKat to impose permissions derived from directory structure by emulating internal and/or external SD cards instead of direct mounting them. Mount namespaces are implemented since Marshmallow to serve the purpose of apps isolation in better way enforced by "zygote" at runtime. On rooted devices when an app requests a root shell, SU manager starts the shell in a new isolated namespace. While FUSE is implemented through UID's, namespaces are implemented through PID's. Super user rights with namespace separation are granted through
Code:
unshare -m sh
i.e. providing the app (process id) an independent view of mount points, not visible to the rest of apps.
Namespaces only affect (1) emulated SD card mounts handled by zygote or (2) any other filesystem mounted from a shell which was initiated by SuperSU with mount NS separation. All root processes started by Android ("init" on boot) run in global namespace. For example all mounts from adb shell will have no namespace separation because "adbd" is run in global namespace. Similarly, all shared mounts done at boot by init are propagated as a single unit from default/global/root namespace to all new zygote-forked per process namespaces. If we un-mount a filesystem from an app with root access, it will not affect the system and other apps. However if mount namespace separation is disabled, un-mounting a filesystem from any app will un-mount it globally. So isolated namespace feature provided by SU solutions is a security measure.
Say, you execute the following command from Termux (or any other terminal emulator app):
Code:
/system/bin/encfs -o allow_other /data/media/0/.encfs /data/media/0/encfs
Now, if mount namespace separation is enabled (by default), you will be able to open /data/media/0/encfs only from Termux app and from no other file explorer etc. For any other app, EncFS is not mounted at all. However Android su binaries provide a mount master option to always mount in global namespace:
Code:
[COLOR="Red"][B]su -mm[/B][/COLOR] /system/bin/encfs -o allow_other /data/media/0/.encfs /data/media/0/encfs
nsenter command can also be used to enter an existing isolated mount namespace. But note that namespaces are killed as soon as they have zero process running.
Other option is to disable "Mount Namespace Separation" in SuperSU app settings. However, do not disable this if you want to use apps like Titanium Backup or "Hide Root" feature as in Magisk etc. In addition to Isolated and Global, Magisk also provides a third option: Inherited i.e. run the root shell in same isolated namespace in which app is already running.
Related: Partition gets unmounted automatically in Android Oreo
DROP DAEMON PRIVILEGES
What I quoted earlier:
#daemon will drop to user/group system/media_rw after initializing
Click to expand...
Click to collapse
This "drop daemon privilege" thing is specific for "sdcard" daemon only as stated here and neither true for FUSE in general, nor related to filesystem "user_id" or "uid" options:
It must be run as root, but will drop to requested UID/GID as soon as it mounts a filesystem.
Click to expand...
Click to collapse
Code:
snprintf(opts, sizeof(opts),
"fd=%i,rootmode=40000,default_permissions,allow_other,user_id=%d,group_id=%d",
fd, uid, gid);
res = mount("/dev/fuse", dest_path, "fuse", MS_NOSUID | MS_NODEV, opts);
if (res < 0) {
ERROR("cannot mount fuse filesystem: %s\n", strerror(errno));
goto error;
}
/* Drop privs */
res = setgroups(sizeof(kGroups) / sizeof(kGroups[0]), kGroups);
if (res < 0) {
ERROR("cannot setgroups: %s\n", strerror(errno));
goto error;
}
res = setgid(gid);
if (res < 0) {
ERROR("cannot setgid: %s\n", strerror(errno));
goto error;
}
res = setuid(uid);
if (res < 0) {
ERROR("cannot setuid: %s\n", strerror(errno));
goto error;
}
fuse_init(&fuse, fd, source_path, write_gid, derive, split_perms);
umask(0);
res = ignite_fuse(&fuse, num_threads);
/* we do not attempt to umount the file system here because we are no longer
* running as the root user */
Process should call "setuid" itself to drop/elevate privileges which isn't the case for EncFS/FUSE by default. We can't use "su" or "setuidgid" or "chpst" commands to drop privileges later on but this isn't needed either as explained earlier. Only "uid=" and "gid=" options are enough.
Same source code file also explains somewhat how "legacy" and "derived permissions" work particularly on Android 4.4, 5 and 6 using FUSE filesystems for emulating SD card.
SUMMARY
On Android, only root can mount EncFS (FUSE) filesystem
Do mention "allow_other" option if you want to access EncFS mounted directory from a non-root app
Do mention "umask=" option if you want to read/write encrypted files from a non-root app
"uid" and "gid" need to be set if you want to give some specific non-root app write access to the filesystem. Otherwise "allow_other" and "umask" can suffice.
Disable "Mount Namespace Separation" option in SuperSU app if:
EncFS is to be mounted feom CLI (Terminal Emulator) app and not by some boot script or from adb shell, and
You want to access EncFS mounted directory from some app other than the root shell in CLI app
bastei said:
Development of Cryptonite seems quite inactive unfortunately. But there is a fork that seems to have some fixes for building, a build script and build instructions.
Click to expand...
Click to collapse
Latest EncFS binary is available here. Thanks to @DualJoe. It works with Android Oreo as well. However, overlapping with already mounted FUSE or sdcardfs (a FUSE-like filesystem implemented in Android 8+ that works in kernel space) should be avoided.
This is my understanding of EncFS and FUSE. Correct me if I'm wrong.

You could use /mnt/encfs. I think it might not be affected by namespace isolation.

DualJoe said:
You could use /mnt/encfs. I think it might not be affected by namespace isolation.
Click to expand...
Click to collapse
It didn't work for me. What I have understood is that mount namespace isolation implemented by SuperSU app is totally independent of that implemented by AOSP on emulated storage. SuperSU grants root access on the basis of app, not path. When an app requests root rights from SuperSU, a new namespace is created in which all global mounts are cloned. Now it's up to that app what it does with the mountpoints, not affecting any other process. So the path where filesystem is mounted doesn't matter. Also whatever location we choose, mount call won't be successful without root. I have added a few lines about this in my previous post.

Are you sure you're invoking 'mount' with 'su -mm'?
I can only speak for my system (LOS13, Magisk) but i can mount cifs or ecryptfs on any place (/data/media/0, /mnt/*) without problems. Magisk is still set to default namespace option (inherited). The '-mm' switch is always 'global namespace' though as it's primarily intended for public mounting (as described in 'su --help').

DualJoe said:
Are you sure you're invoking 'mount' with 'su -mm'?
I can only speak for my system (LOS13, Magisk) but i can mount cifs or ecryptfs on any place (/data/media/0, /mnt/*) without problems. Magisk is still set to default namespace option (inherited). The '-mm' switch is always 'global namespace' though as it's primarily intended for public mounting (as described in 'su --help').
Click to expand...
Click to collapse
Yes definitely 'su -mm' mounts in global namespace. I was talking about simple mount command from a su shell, without '-mm'.

After putting password in terminal after encfs command, does nothing. Means decrypted directory always remain empty. any idea how to resolve this ? Android 13
Edit1: now this working but new issue came which ia mentioned in next post.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}

i using below command:
su -mm -c "encfs --public -o nonempty,allow_other,rw,noatime,noexec,nodev,nosuid,gid=9997,umask=006 -S /mnt/runtime/write/3B86-9400/.encrypted /mnt/runtime/write/emulated/0/decrypted"
I can see content in the file manager only but not gallery.
After Android media store refresh only content of decrypted folder showing in gallery but content of sub folder of decrypted folder is not showing in the gallery.
Any idea how to resolve this issue.

[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. =]

[ARMv7/Intel][Root][Busybox][init.d]Optware-ng: install pre-compiled native packages

This how-to describes how to bootstrap and configure Optware-ng. Optware-ng is my Optware firmware-independent fork. This allows to install numerous pre-compiled packages.
Lists of available packages can be found here:
ARMv7 hardfloat
Intel
ARMv7 softfloat
And the project home is currently here:
https://github.com/alllexx88/Optware-ng
Some packages may not work, since not all of them are compatible with android, but most will. There're some pre-requisites you must satisfy before you can proceed:
1. You must be rooted
2. Optware-ng relies on some standard linux commands, the easiest way to make sure you have them is to install Busybox with all the links
3. We'll create Optware-ng initialization script in /system/etc/init.d, so init.d support is needed. If you don't have it, you can either add it (google for how-tos on doing this) or edit your init.rc android startup script to include Optware-ng initialization lines (though adding init.d support is still a better idea)
The following commands should be issued from terminal as root. I suggest you use some SSH server available on the Play Store, and connect via SSH from you PC.
1. This prepares needed environment:
- Optware-ng will be installed to /data/Optware-ng with /opt symlinked to it
- Optware-ng scripts rely on /bin/sh, so we symlink it to /system/bin/sh
- Optware-ng needs /tmp temp dir: we create 64Mb RAM disk there (you may adjust the size if you like)
Code:
mkdir -p /data/Optware-ng
mount -o remount,rw /
ln -s /data/Optware-ng /opt
mkdir /bin
ln -s /system/bin/sh /bin/sh
mkdir /tmp
chmod 777 /tmp
mount -t tmpfs -o size=64M tmpfs /tmp
mount -o remount,ro /
export PATH=$PATH:/opt/bin:/opt/sbin
2. This bootstraps the feed:
2.a) for ARMv7 hardfloat (most modern android devices):
Code:
cd /tmp
wget http://optware-ng.zyxmon.org/buildroot-armeabihf/buildroot-armeabihf-bootstrap.sh
sh buildroot-armeabihf-bootstrap.sh
2.b) for Intel:
Code:
cd /tmp
wget http://optware-ng.zyxmon.org/buildroot-i686/buildroot-i686-bootstrap.sh
sh buildroot-i686-bootstrap.sh
2.c) for the unlikely case where your device is ARMv7, but lacks FPU (softfloat feed):
Code:
cd /tmp
wget http://optware-ng.zyxmon.org/buildroot-armeabi-ng/buildroot-armeabi-ng-bootstrap.sh
sh buildroot-armeabi-ng-bootstrap.sh
Unless you're using ARMv7 softfloat feed, bootstrapping process may appear to be "stuck" on this:
Configuring glibc-locale
Generating locale-archive with default locales ...
Click to expand...
Click to collapse
Don't be frightened: if your device isn't too powerful, it indeed takes a lot of time, but you have to do this just once, so please be patient.
3. Make sure environment needed for Optware-ng is restored after reboots, and also run Optware-ng startup scripts on boot:
Create init.d startup script and make it executable
Code:
mount -o remount,rw /system
echo '#!/system/bin/sh
mount -o remount,rw /
ln -s /data/Optware-ng /opt
mkdir /bin
ln -s /system/bin/sh /bin/sh
mkdir /tmp
chmod 777 /tmp
mount -t tmpfs -o size=64M tmpfs /tmp
mount -o remount,ro /
sleep 2
export PATH=$PATH:/bin:/opt/bin:/opt/sbin
for script in `ls /opt/etc/init.d/S*`; do
$script start
done' > /system/etc/init.d/S99Optware-ng
chmod 755 /system/etc/init.d/S99Optware-ng
mount -o remount,ro /system
Once again, you may adjust this line
Code:
mount -t tmpfs -o size=64M tmpfs /tmp
if you want greater/lesser RAM disk on /tmp
(4.) You're basically done, but I suggest you now install Optware-ng's dropbear-android package to act as an SSH server:
Code:
ipkg update
ipkg install dropbear-android
dropbear configs are stored in /opt/etc/default/dropbear and by default are:
Code:
DROPBEAR_ENABLE=no
DROPBEAR_PORT=2222
DROPBEAR_PASSWORD=password
Run these commands to adjust configs, enable dropbear and start it:
(replace <*> strings with actual desired values)
Code:
sed -i -e '/^DROPBEAR_PORT=/s/=.*/=<YOUR_PORT>/' -e '/^DROPBEAR_PASSWORD=/s/=.*/=<YOUR_PASSWORD>/' -e '/^DROPBEAR_ENABLE=/s/=.*/=yes/' /opt/etc/default/dropbear
/opt/etc/init.d/S51dropbear start
Now you are advised to use dropbear as SSH server to play with Optware-ng: use 'root' user, '<YOUR_PASSWORD>' password and '<YOUR_PORT>' port
For better security you may use public key authorization only: set password to blank and add your public keys to /opt/etc/dropbear/authorized_keys (don't forget to `chmod 600 /opt/etc/dropbear/authorized_keys` after you create it!) and restart dropbear or just reboot.
P.S. I'm not exactly sure that this is the right place to post this, please move it if needed.