Here's a tutorial on how to fix the host's Android /system/bin not executing when using the chrooted Nethunter environment. UPDATED THREAD:
https://xdaforums.com/t/power-user-...-chrooted-environment-and-vice-versa.4649451/
The problem started with an itch, I wanted to be able to access android APIs through a shell/terminal which isn't possible afaik from a rooted shell. Then I learned about Automate(really powerful app similar to tasker but with a more beautiful UI) which allows you to send broadcasts over to it basically acting as an API to do things which you'd never be able to do through a barebones shell otherwise.
Only problem is, to send broadcasts to that app I need to use the am(Activity Manager) command and the am command is only available in the host environment and can't be accessed in the nethunter chroot. So then began my investigation into this
This was kind of a steep learning curve ngl. This will also serve as a guide for my future self in case I ever face a similar issue again.
I will also provide links to resources for a deeper understanding, you don't need to look at the resources, however.
At the end of this, I will post a simple sh script which you could execute that
should fix this issue in an instant.
Problem
When we are in a chrooted environment attempting to execute binaries that are present in /system/bin cause errors no matter what you try. Tried various things from setting LD_PRELOAD_PATH to modifying the elf but to no avail.
What is chroot
Attempting to execute them presents the following error
/system/bin/echo hello
zsh: no such file or directory: /system/bin/echo
Of course, if we use the one defined in our chroot path then it'd work normally
echo hi
hi
Which in reality just executes this
/usr/bin/echo hi
Now, why is the previous one erroring when this one's working fine? My first reaction was what in the hell does it mean no such file or directory. bruh it's right there, execute the damn thing. I could see 101% that it exists there and I could even use cat to read out its contents, check all the file permissions are correct, and the architecture is correct
How linux file permissions work
Understanding Linux file permissions (how to find them, read them, and change them) is an important part of maintaining and securing your systems.
www.redhat.com
How to know your device architecture(it's aarch64 which is basically arm64 btw)
uname -m gives i686 and uname -m gives i686 i386 output in Red Hat Enterprise Linux Server release 5.4 (Tikanga) machine. I need to install Oracle Database 10g Release 2 on that machine. So, how ca...
unix.stackexchange.com
How to figure out a binary's architecture
A Computer Science portal for geeks. It contains well written, well thought and well explained computer science and programming articles, quizzes and practice/competitive programming/company interview Questions.
www.geeksforgeeks.org
Then from some previous project I can't recall, I learned about static and dynamically compiled binaries
Remembering this, the first thing I checked was ldd but nope that didn't work either
ldd /system/bin/echo
/system/bin/sh: error while loading shared libraries: /lib/aarch64-linux-gnu/libc.so: invalid ELF header
/system/bin/ldd /system/bin/echo
zsh: /system/bin/ldd: bad interpreter: /system/bin/sh: no such file or directory
What static and dynamic libraries are
Looking further, you will find out that /system/bin/ldd is nothing but a symlink to a static binary that exists in the host's /apex/com.runtime.android/bin/linker64
after various attempting for a period of time to mount bind and mount rbind the apex directory to the chroot, I just gave up on it because the com.runtime.android kept on showing up empty. Till I realized that linker64 was static. So I copied it over to another folder inside the chroot and voila, I was able to execute it simply by running ./linker64
Through this, I now understood that the problem is not something I don't understand. The problem lies purely with the dynamic libraries being missing which I am certain of now. tried rebinding a couple of times but nope that failed so I just copied the whole /apex/com.android.runtime/*(which is just 8.3 megabytes in size) to the chroot's /apex/com.android.runtime and copy /linkerconfig to the chroot's root as well
Notice how I used an asterisk instead of attempting to copy the directory directly,this is because it won't allow you to copy the directory which was another source of headache for me
Make sure to create empty directories for apex and com.android.runtime in your chroot before copying things over
mkdir /apex /apex/com.android.runtime
then copy over(btw, you could also just bind each file/directory inside runtime to the chroot's runtime but copying is just easier and persistent without having to modify the chroot initialization process)
cp -r /apex/com.android.runtime/* /data/local/nhsystem/kalifs/apex/com.android.runtime
Things started working a bit then
Then at last to fix some library dependencies, you need to create symlinks to some commands like linker64 and cmd through the chroot
ln -s /apex/com.android.runtime/bin/linker64 /usr/bin/linker64
ln -s /usr/bin/cmd /system/bin/cmd
Then, you should be able to successfully run any binary inside /system/bin from within the Nethunter chroot
Eg:
/system/bin/echo Hello
Hello
/system/bin/am start -a android.intent.action.VIEW -d xdaforums.com -n com.android.chrome/com.google.android.apps.chrome.Main
etc
Tips and tricks
Some chroot commands like ping inside the chroot environment don't work(didn't really look into it tbh)
You could either use the system's ping or use busybox's instead from within the chroot
/system/bin/ping google.com
busybox ping google.com
To fix the apt update problem ( Temporary error resolving http.kali.org )
Solution is in the 5th post by jafoca
Hi, I'm seeing the following: root@kali:~# apt-get update Err:1 http://http.kali.org/kali kali-rolling InRelease Temporary failure resolving 'http.kali.org' Reading package lists... Done W: Failed to fetch http://http.kali.org/kali/dists/kali-rolling/InRelease Temporary failure...
forums.kali.org
To execute nethunter chroot binaries while being in a normal android shell
Btw, the thing you gotta modify is just the last bit which specifies /usr/bin/WHATEVER then the arguments/flags passed over. Note: Make sure that LD_PRELOAD doesn't contain anything by executing(by default it doesn't contain anything so most of the time you won't need to execute this)
unset LD_PRELOAD
Eg #1
PATH=$PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin /system/xbin/chroot /data/local/nhsystem/kalifs /usr/bin/echo Hello world!
Eg #2
This will give you an sh shell, which looks weird(sometimes you will have some things running through this if for example you setup vs coder on your system
( To make it look like a normal chroot zsh shell, execute the following after the chroot shell has started
/usr/bin/zsh followed by
source /root/zshrc)
PATH=$PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin /system/xbin/chroot /data/local/nhsystem/kalifs /usr/bin/sh
To access Android APIs that you wouldn't normally otherwise be able to normally access (I think tasker it's possible to do this with tasker too but I never bothered checking out tasker cuz it ain't free)
Automate has one limitation for free users, 30 blocks per flow. No ads no bs
Watch video for quick demo
Read documentation to become powerful
Create flowcharts that make your Android smartphone or tablet perform tasks automatically.
llamalab.com
Start a flow
am broadcast -a com.llamalab.automate.intent.action.START_FLOW -d <Flow URI from Flow beginning block> -n com.llamalab.automate/.StartServiceReceiver
Stop a flow
am broadcast -a com.llamalab.automate.intent.action.STOP_FLOW -d <Flow URI from Flow beginning block> -n com.llamalab.automate/.StartServiceReceiver
KWGT to create advanced custom widgets capable of communicating with Automate, adb, shell scripts
(Saved me from having to create an app for some project of mine)
Create your own custom color widgets with endless possibilities!
play.google.com
To mount the Nethunter chroot or any directory within the chroot so that you could access it through the phone's storage itself(in case you are dealing with some application)
mkdir /sdcard/nethunter_chroot
mount -o bind /data/local/nhsystem/kalifs /sdcard/nethunter_chroot
To unmount it( You don't have to do this manually, it will automatically unmount once the device resets)
umount /sdcard/nethunter_chroot
Some things that I have been interested in as well is to somehow ditch the VNC and directly output the desktop(forgot whether if it was xfce or plasma that comes with nethunter)
Still something that I have no idea also I like dex so I dunno whether if it'd interfere with Dex
If anyone has a clue about how to do this please let me know cuz I gotta know!!!
FINAL NOTE: WHEN RUNNING THE SCRIPT ATTACHED WITH THE MESSAGE, MAKE SURE TO RUN IT IN AN ANDROID SHELL ENVIRONMENT AS SU NOT IN THE CHROOT ENVIRONMENT!
Also make sure to check and understand what the script is doing before executing it(it's just 4~5 lines)