Related
I learned about this here... http://fieldeffect.info/w/NativeCompileSDK
You can install an i386/x86_64 chroot within your existing Debian chroot using qemu-user-static to run the Android SDK on your Android phone/tablet/phablet.
1.
Get yourself a debian chroot, I recommend at least 2gb. I use DebianKit from market.
2.
You will need a X11 desktop environment and a VNC client on your device. I use androidVNC from market.
Here is my working example...
Start your Debian chroot/environment and do...
apt-get install openbox openbox-themes obmenu obconf menu menu-xdg xdg-utils xfonts-base xfonts-terminus* nautilus terminator lxappearance gmrun leafpad man-db hicolor-icon-theme tightvncserver tint2
That gives you a window manager, fonts, filebrowser, terminal emulator, text editor, theme manager, taskbar, and a VNC server.
Now lets get some GTK engines and libraries....
apt-get install gtk2-engines-auroa gtk2-engines-murrine gtk2-engines-oxygen gtk2-engines-pixbuf libgtk2.0-bin gtk3-engines-oxygen gtk3-engines-unico libgtk-3-bin
Now 7zip to handle zips and archives comfortably(put non-free in your apt sources.list)...
apt-get install p7zip p7zip-full p7zip-rar zip unzip
##The Android SDK manager, qemu, and multistrap##
apt-get install ant file openjdk-6-jre openjdk-6-jdk qemu-user-static libswt-gtk-3-java libswt-cairo-gtk-3-jni
3.
Now we can build a small x86_64 rootfs using multistrap
multistrap can use a config, have mine...
http://db.tt/hS5j3wg
Copy multistrap.conf straight into your working(pwd) directory....
cp /sdcard/Download/multistrap.conf .
Do this to avoid multistrap complaining later...
cat multistrap.conf >mstrap
mkdir /data/mnt
Determine size of rootfs for loop image..
du -hs /data/mnt/
Now make an image for x86_64 chroot
dd if=/dev/zero of=/sdcard/64bit.img bs=$(( 0x100000 )) count=YOUR IMAGE SIZE
That byte size makes your image slightly larger than the count value in Mb, for example count=78 will write 82Mb image.
mkfs.ext2 /sdcard/64bit.img
tune2fs -c0 /sdcard/64bit.img
mkdir /data/tmp
busybox mount -o loop /sdcard/64bit.img /data/tmp/
cp -r /data/mnt/* /data/tmp/
umount /data/tmp
rm -r /data/tmp/
rm -r /data/mnt/
mkdir /data/mnt
busybox mount -o loop /sdcard/64bit.img /data/mnt/
5.
Now the environment is set up and mounted, at this point install the SDK
Aim your browser to http://developer.android.com/sdk/index.html
Select "Linux" from "SDK Tools Only", thats the last thing at the bottom of the list.
cp /sdcard/Download/android-sdk_r21.0.1-linux.tgz .
7z x android-sdk_r21.0.1-linux.tgz russosv
7z x android-sdk_r21.0.1-linux.tar
Now we need a couple goodies from http://fieldeffect.info/w/NativeCompileAPK ##--Thanks to russosv from FeildEffect
These are edited from original....
#!/bin/bash
QEMU=/usr/bin/qemu-x86_64-static
64CHROOT=/data/mnt/
case "$1" in
mklinks)
if [ ! -e "./64BIT" ]; then
mkdir ./64BIT
fi
for i in $(file ./* | grep "ELF 32" | awk '{print $1}' | sed s/://g | sed s/[./]//g); do
echo "Moving $i..."
mv $i ./64BIT
ln -s ~/bin/run-64-link $i
done-
;;
*)
$QEMU $64CHROOT/lib64/ld-linux-x86_64.so.2 --library-path $64CHROOT/lib:$64CHROOT/usr/lib:$64CHROOT/usr/share/perl/5.12.4/unicore/lib:$64CHROOT/var/lib:$64CHROOT/lib/x86_64-linux-gnu:$64CHROOT/usr/lib/x86_64-linux-gnu [email protected]
;;
esac
Copy that to run-64, then...
chmod 755 run64
cp run-64 /usr/bin/
One more...
echo $(dirname $0)/64BIT/$(basename $0) [email protected]
/usr/bin/run-i386 $(dirname $0)/64BIT/$(basename $0) [email protected]
Make that run-64-link
chmod 755 run-64-link
cp run-64-link /usr/bin/
5b.
Now launch VNC server
tightvncpasswd
tightvncserver
killall Xtightvnc
cat >.vnc/xstartup<<EOF
tint2 &
terminator &
openbox-session
EOF
tightvncserver
export DISPLAY=:1
6.
Now launch the VNC client I mentioned earlier, should connect with 127.0.0.1:5901 and your password you set.
Go back to terminal or use the one launched on X11 to do...
sh android-sdk-linux/tools/android
Install at least one api.
If all went well you can now go around "debugging" yours and your friends Android devices over wifi now.
For an example, and to see it work do....
svc wifi disable(or enable) ##this turns off/on wifi
setprop service.adb.tcp.port 5555(or -1) ##this turns on/off adb over network
stop adbd
start adbd
adb connect 127.0.0.1(yours) or any other adbd addy listening on your network,
Have fun
Never did a "how to" before, go easy and I'll make corrections and answer things. Thanks for reading. Leave feedback.
Potential necro post but I believe the information is still currently valid and not readily available on searches. I've looked variations of this up for years with no luck until I hit the right search terms.
bump, and thanks.
can't believe there's no comments.
I know it's a slower than real-64-bit-pc method but not all of us have access to new hardware... or pc's. Maybe a novelty, still cool and useful if you've got the time to let the slower hardware compile.
you have preserved the scripts, original link is dead.
here is the Internet Wayback Machine cache of the original circa 2012 for reference.
http://web.archive.org/web/20120502044700/http://fieldeffect.info/w/NativeCompileAPK
appreciate you sharing.
I currently run Paranoid Android on my SG5, which works well enough for my tastes. One thing I've wanted to play with is reverse tethering. Since I charge my player via the computer's usb connection, I figured it'd make sense to disable wifi and save a little power to speed up the slow usb charging and just use the pc's internet connection via usb. I also have a few apps like calibre and the compantion app which don't work correctly when I'm on a wifi connection that's been firewalled to prevent devices from communicating with each other. This bypasses the wifi connection and gives me a nice secure connection between devices.
I got it working ... mostly. I don't expect many people to find this useful, but I thought it might be an entertaining hack to poke at.
The following script sits on my linux netbooks' ~/bin directory as reverse-tether.sh
Code:
#!/bin/sh
# We need root on the host to mess with networking
if [[ $(whoami) != "root" ]]; then
echo "You must be root to run this script!"
exit 1
fi;
# We need root on the Player to mess with networking
echo 'Enabling adb root access...'
adb -d root
# Turn on usb networking
echo 'Enabling usb network interface on the Galaxy Player...'
adb -d shell 'sh /storage/sdcard0/reverse_tether.sh up &'
# adb disconnects, so we wait for the network on the player to settle before continuing on.
sleep 2
# Rename device interface as ArchLinux has annoying device names (becomes player)
IF=`ifconfig -a | grep "enp" | cut -d ':' -f 1`
ip link set dev $IF down
/usr/sbin/ifrename -i $IF -n player
ip link set dev player up
echo 'Setting Computer IP Address ...'
ifconfig player 192.168.200.1 netmask 255.255.255.0
ifconfig player up
echo 'Enabling NAT and IP Forwarding on Computer...'
# Start forwarding and nat (use existing default gw)
iptables -F -t nat
iptables -A POSTROUTING -t nat -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 'Starting dnsmasq on Computer...'
dnsmasq --interface=player --no-dhcp-interface=player
echo
echo 'Connection is ready! Press any key to shutdown.'
echo
read
echo 'Shutting down reverse tethering'
# SSH server is always running on player, with public rsa key imported for passwordless logins
# This hackery is required as adb seems to be disabled with rndis active.
# I use dropbear server II, but any of the ssh servers would probably work.
ssh [email protected] 'sh /storage/sdcard0/reverse_tether.sh down &'
killall dnsmasq
ifconfig player down
iptables -F -t nat
echo 0 > /proc/sys/net/ipv4/ip_forward
And the following script is simply stashed on the sdcard of the player. as /storage/sdcard0/reverse_tether.sh
Code:
#!/system/bin/sh
if [ "$1" = "up" ]; then
echo 1 > /sys/class/usb_composite/rndis/enable
ip addr add 192.168.200.2/24 dev usb0
ip link set usb0 up
ip route delete default
ip route add default via 192.168.200.1
setprop net.dns1 192.168.200.1
fi
if [ "$1" = "down" ]; then
sleep 2
ip route delete default
ip link set usb0 down
echo 0 > /sys/class/usb_composite/rndis/enable
fi
When I finish, sometimes I need to restart wifi on the player to get networking to work again.
The only real problem I've had is that some apps require or want wifi/3g active in order to fully function. For example, the play store works fine until you try and download an actual update. Google Maps works fine, although you get lots of warnings about having wifi turned off. I have no idea how to "emulate" 3g or wifi which I think would solve that problem.
This was fun getting running. Hope you enjoyed...
I know this is an old thread but I found this really really useful. Going to give it a try after work today. Great job.
Sent from my YP-G70 using xda app-developers app
I have a rooted a GT-I9195 (SGS4-mini) done with CF-Auto-Root and the latest Busybox. I then decided to use the "Ssh server" from The Olive Tree, since it is simple, small, free, but unfortunately have ads. For on-device/local shell, I use the Android Terminal Emulator and everything works great, including su and shell environment.
However, I have a really strange bahaviour when connecting using ssh via WiFi, and trying to su.
First when connecting via ssh, I get the following message.
Code:
[SIZE=2]$ ssh -2 -4 -t [email protected] -p 50555
Authenticated with partial success.
[email protected]'s password:
/system/bin/sh: No controlling tty: open /dev/tty: No such device or address
/system/bin/sh: can't find tty fd
/system/bin/sh: warning: won't have full job control
[email protected]:/ $[/SIZE]
I have Googled this and there's little useful info. On one site they even say:
Code:
[SIZE=2]Getting a controlling tty
[B]How does one get a controlling terminal? [COLOR=Red]Nobody knows[/COLOR], this is a great mystery.[/B]
The System V approach is that the first tty opened by the process
becomes its controlling tty. The BSD approach is that one has to
explicitly call
ioctl(fd, TIOCSCTTY, ...);
to get a controlling tty.
Linux tries to be compatible with both, as always, and this results in
a very obscure complex of conditions. Roughly:
The [B]TIOCSCTTY [/B]ioctl will give us a controlling tty, provided that (i)
the current process is a session leader, and (ii) it does not yet have
a controlling tty, and (iii) maybe the tty should not already control
some other session; if it does it is an error if we aren't root, or we
steal the tty if we are all-powerful.
Opening some terminal will give us a controlling tty, provided that
(i) the current process is a session leader, and (ii) it does not yet
have a controlling tty, and (iii) the tty does not already control
some other session, and (iv) the open did not have the [B]O_NOCTTY[/B] flag,
and (v) the tty is not the foreground VT, and (vi) the tty is not the
console, and (vii) maybe the tty should not be master or slave pty.
[/SIZE]
Now this is not the end of the world, if it was not that it doesn't understand normal terminal control characters and in addition, when I do su, I loose the command prompt. However, using the "-i" (interactive) switch gets me the "#" prompt, but environment is still completely messed up:
Code:
[SIZE=2][email protected]:/ $ [B]su -c /system/bin/sh -i[/B]
/system/bin/sh: No controlling tty: open /dev/tty: No such device or address
/system/bin/sh: can't find tty fd
/system/bin/sh: warning: won't have full job control
[email protected]:/ #[/SIZE]
I've never had or seen this issue before. Any ideas?
(Also, where would I put a source to my .bashrc and make sure it runs when su'ing or ssh?)
PS. The phone is using a stock 4.2.2 SELinux kernel.
Code:
[SIZE=2]Device: Samsung Galaxy S4 Mini LTE (GT-I9195)
Board/Platform: MSM8930AB (Snapdragon 400)
Baseband: I9195XXUBML4
Kernel: 3.4.0-2340422
[email protected] #1
Build: JDQ39.I9195XXUBML4
SE: SEPF_GT-I9195_4.2.2_0022
ro.build.date: Sat Dec 21 01:46:00 KST 2013
ro.build.description: serranoltexx-user 4.2.2 JDQ39 I9195XXUBML4
[/SIZE]
I still have no idea of what's causing those error messages above, also because logcat is not telling us anything interesting either. Only as Warning from "System.err", but without any useful information. However, I have got some improvement in the terminal behavior when doing the initial ssh connection.
One problem seem to be that the TERM environment variable was copied from local machine (PC side) to remote server (Android phone), thus giving TERM=cygwin to the Android shell. This can be disabled or changed as follows.
Some relevant SSH options:
Code:
[SIZE=2]
-e escape_char
Sets the escape character for sessions with a pty (default: `~'). The escape
character is only recognized at the beginning of a line. The escape charac-
ter followed by a dot (`.') closes the connection; followed by control-Z sus-
pends the connection; and followed by itself sends the escape character once.
Setting the character to "none" disables any escapes and makes the session
fully transparent.
-T Disable pseudo-tty allocation.
-t Force pseudo-tty allocation. This can be used to execute arbitrary screen-
based programs on a remote machine, which can be very useful, e.g. when
implementing menu services. Multiple -t options force tty allocation, even
if ssh has no local tty.
[/SIZE]
Some relevant SSH -o options:
Code:
[SIZE=2][B]RequestTTY[/B]
Specifies whether to request a pseudo-tty for the session. The argument may
be one of: "no" (never request a TTY), "yes" (always request a TTY when stan-
dard input is a TTY), "force" (always request a TTY) or "auto" (request a TTY
when opening a login session). This option mirrors the -t and -T flags for
ssh(1).
[B]
SendEnv[/B]
Specifies what variables from the local environ(7) should be sent to the
server. Note that environment passing is only supported for protocol 2. The
server must also support it, and the server must be configured to accept
these environment variables. Refer to AcceptEnv in sshd_config(5) for how to
configure the server. Variables are specified by name, which may contain
wildcard characters. Multiple environment variables may be separated by
whitespace or spread across multiple SendEnv directives. The default is not
to send any environment variables.
[/SIZE]
So by using the ssh -T option (which is equivalent to using '-o RequestTTY="no"'), we are disabling "pseudo-tty allocation" which doesn't work anyway, but with the effect of not forwarding local TERM to server, and thus setting it to default "vt100" which accepts backspace (but not insert). But a better way is to actually set the TERM variable on our own. This is done by simply adding it as a prefix to the ssh command like this:
Code:
[SIZE=2]TERM=[B]vt220[/B] ssh -t [email protected] -p 50555[/SIZE]
(This effectively, but temporarily overrides the local TERM value and forwards it to remote server shell.)
RanTime!
Since Google intruduced the SELinux/SEAndroid features, they have essentially fukced up the entire AOS ecosystem as based on good-old normal Linux environments and all the years of standards therein. Basically nothing works as before and as logically intended or preferred and I bet from now on, developers will have to spend a significant and expensive time, on just trying to setup their various developer environments and jump through the hoops of dikchead Google engineers, rather than on actual developing. A very sad story all thanks to the populist "security" eye-candy marketing.
The SU time!
Apparently after having read about the various quirks and issues in using an SELinux Enforced based AOS {4}, it seem that the issue from OP is probably due to one of 3 things or a combination thereof.
My su binary (SuperSU 1.94) is not yet handling SElinux properly
The SSHd server is not handling SELinux properly
Lack of properly set SSH and SHELL environment files on the server side
As for (1) I just have to wait and see. For (2) we can only test with other SSHd servers/solutions which I don't know what to use. (They're all, either not free or full of ads. WTF!) And finally, for (3) we can only test, since I don't have the source code...
Unfortunately listing the SuperSU (1.94) command line options is not very helpful, since they're rather poorly explained. While some of the option themselves just doesn't work (for me). It would have been great if @Chainfire could write a more detailed how-to {2} for all these options, but then again we should be extremely grateful he's written anything at all.
Code:
[SIZE=2]Usage: su [options] [--] [-] [LOGIN] [--] [args...]
------------------------------------------------------------------------------------
Options:
-c, --command COMMAND pass COMMAND to the invoked shell
-cn, --context CONTEXT switch to SELinux CONTEXT before invoking
-h, --help display this help message and exit
-, -l, --login pretend the shell to be a login shell
-m, -p,
-mm, --mount-master connect to a shell that can manipulate the
master mount namespace - requires su to be
running as daemon, must be first parameter
--preserve-environment do not change environment variables
-s, --shell SHELL use SHELL instead of the default detected shell
-v, --version display public version and exit
-V display internal version and exit
Usage#2: su LOGIN COMMAND...
Usage#3: su {-d|--daemon|-ad|--auto-daemon|-r|--reload}
auto version starts daemon only on SDK >= 18 or
if SELinux is set to enforcing
Usage#4: su {-i|--install|-u|--uninstall}
perform post-install / pre-uninstall maintenance
[/SIZE]
References:
[1] [Chainfire G+] Next Android version: even more breakage
[2] [Chainfire] How-To SU (Guidelines for problem-free su usage)
[3] SuperSU Download
[4] [Google] Validating Security-Enhanced Linux in Android
From THIS very old post by @mirabilos , it is possible that command-line TAB-completion and up-arrow is not working on all mksh binaries. So perhaps we just need a new static mksh binary installed?
Tab expansion is pretty broken on BSD with xterm and GNU screen, but the same seems to work better on ssh’ing out to Linux, I wonder why, since all software involved is the same… except tput though. But it works like that and is usable. With post-R40 mksh, you can get about with even less hacks (more similarity to AT&T ksh).
Click to expand...
Click to collapse
However, this still doesn't explain why I have no controlling tty for ssh sessions.
Also I tested a new and different SSH server called SSHelper, which has more features and is better maintained, without ads, but is also 6 times larger at ~ 6MB, because of included OpenSSH, FTP and webserver log functionality. When logging in via ssh I get:
Code:
...
Server refused to allocate pty
Followed by an empty non-responsive connection.
Is this the same as […]this problem elsewhere? Man, I'm searching for ideas and keep coming back to your questions all over the 'net
To clarify, I talked to someone at Google; they renamed mksh into just sh lately, but this should have no adverse effect. They currently ship R48 and “would have updated it if I knew there was a new version”. That being said, the code of the shell itself is not at fault here.
The “no controlling tty” message here is a red herring: you do not have access to a tty at all, let alone a ctty
As I said elsewhere, use “ssh -t” and either change the SELinux policies to allow pty/tty pair allocation, or disable it (possibly set it into permissive mode).
@mirabilos: Yes, thanks for that info. I haven't updated this thread since I started it, in anticipation of a writeup about SELinux. However, that proves to be a little over my head, so it will take some time. What is clear though, is that the above problem is connected with the SEAndroid protection mechanisms, which in turn have been mangled and incorporated into Samsungs KNOX.
Also I have been busy making the SSHelper support thread:
[APP][INFO|SUPPORT] SSHelper (The free Android SSH Server Application)
There I have also added a small section about mksh.
@ E:V:A - I recently put together a little package containing all necessary bins/scripts to create a SSH server (via dropbear and dropbearkey) (properly secured, not public) and connect with a SSH client (ssh). The package also contains bins/scripts to create a Telnet server (via utelnetd) and connect with Telnet client (via "static busybox" telnet). Everything works with superuser that I've tested. Linked in my signature and attached to post as well.
Instructions (for anyone who sees this and would like a guide)::
Basically just extract it anywhere with:
Code:
tar -xf easy.ssh.and.telnetz.clients+servers.tar.gz
(if it's in /sdcard/Download which is probable, do "cd /sdcard/Download" then run the above)
Change directory inside the folder:
Code:
cd ./ssh.telnetz
There are 6 scripts: ssh.start(connect to ssh server via ssh), sshd.start(create ssh server), ssh.kill(kill ssh processes and remove ssh server keys), and... 3x telnet scripts for the telnet equivalents.
Running scripts and optional parameters:
Code:
./telnetd.start [ shell ]
e.g. TELNET_PORT=8080 ./telnetd.start /system/bin/mksh
./telnet.start [ ip port ]
e.g. ./telnet.start 192.168.0.3 8080
./sshd.start [ <dropbear_flags_and_options ]
e.g. ./sshd.start (default port is 8090)
./ssh.start [ ip port shell ]
e.g. ./ssh.start 192.168.0.3 8090 /system/bin/mksh
Default ip is the loopback 127.0.0.1 so you can test running a server and connecting to it on your phone at the same time. Just change params as described above to connect from/to your phone (phone is client/server).
***As far as I have tested on Android 4.4.4, this works perfectly as root or restricted user. You can get a su'd ssh shell by starting the sshd.start with /system/xbin/su or just entering su after you've connected as a restricted user.***
I've finally found a work-around for the crippled /dev/pts job-control and su combination. There are two small problems that combines to this issue.
1. The SELinux policy is screwed up by Samsung. And others?
2. The /dev/pts is mounted wrong by default.
The work-around:
Make sure you're device is already in Enforcing mode, so that you get the proper su prompt (#).
1. Open terminal session 1.
Code:
[SIZE=2]
## On Terminal 1
ssh -2 [email protected] -p 2222
$ su -c /system/bin/sh -i
# su 0 setenforce 0
# umount /dev/pts
# su -cn u:r:init:s0 -c "busybox mount -t devpts -o rw,seclabel,relatime,mode=620,gid=5 devpts /dev/pts"[/SIZE]
2. Now go to Terminal 2 and login:
Code:
[SIZE=2]## On terminal 2
ssh -2 [email protected] -p 2222
$
[/SIZE]
(You now have job-control but no su possibility.)
3. Now go back to Terminal 1 and enable Enforcing mode:
Code:
[SIZE=2]## On Terminal 1
# su 0 setenforce 1
[/SIZE]
4. Now go back to Terminal 2 and escalate to su:
Code:
[SIZE=2]## On terminal 2
$ su -c /system/bin/sh -i
# [/SIZE]
Unfortunately if you exit the su (#) shell, you'll have to repeat steps 2-4 of the procedure.
Hello,
I want to install DNScrypt proxy 1.4 on my android phone. You can get it here : download.dnscrypt.org/dnscrypt-proxy/
Could someone please make a tutorial an tell me how to install this? I want it to work with following DNS server: https://dnscrypt.eu/
It is a great enhancement in security and I would be glad if someone can get it to work and tell us.
Regards
Is nobody interested in this? [emoji20]
Can't believe there is no response. Is no one of the XDA members who looked at this able to install DNScrypt on there phone?
Do you prefer flappy bird clones over such a security enhancement?
Bump again then.
Bump
Another bump for all secureless xda members
XDA members are not able to install a tar.gz package on their android phone? Aww, really guys?!
B u m p
Seriously, no one...?
How to install dnscrypt on android
Requirements:
rooted phone
installed busybox
some handy tools like terminal emulator or ssh daemon for testing purpose, file explorer with acces to system partition
dnscrypt: https://copy.com/M6r38z6g3iyj (thanks to GitHub esp. @daddybr, KionLi...) - files for arm7
About:
We need to run dnscrypt every time phone is booted - for this purpose is necessary to add script "dnscrypt" into "init.d" directory In this script-file you can also change parameters like used resolver/provider etc.
dnscrypt-proxy is main binary file which will provide dnscrypt service for us. There is also script to start/stop dnscrypt-proxy service anytime we need and made some other usefull things for us...
How to:
check if directory "init.d" in /system/etc/ exist - if there is not such directory use program "Universal Init.d" and create it - otherwise follow bellow
extract downloaded files and put it into same directories they are, just to system partition (u can use any file browser with access to system partition, eg. Solid Explorer)
check if there is file "resolv.conf in /system/etc/ directory
- if there is not such file create it and put this into it "nameserver 127.0.0.1"
- if there is such file check if "nameserver 127.0.0.1"and delete else
all files putted in directory /system/xbin/ should have right permission to work correctly
Checking functionality:
Easiest way is to visit "www.opendns.com/welcome"
If it is working you will get something like "Your Internet is safer, faster, and smarter..."
If it is not working you will get something like "OOPS..."
Other way is to run nslookup in terminal emulator and check if you get 127.0.0.1 and name, eg "nslookup 8.8.8.8"
The hardest way is to use wireshark or tcpdump and analyze traffic while browsing on the phone..., eg. http://askubuntu.com/questions/105366/how-to-check-if-dns-is-encrypted
Also you can check if dnscrypt-proxy is running in terminal , eg. "ps w |grep dnscrypt"
DNS setting
Did anyone got this one to work? I did all the steps mentioned but it seems that the resolv.conf is not being checked. I even try with apps to change dns settings (dnset, dnschanger..) it just seems that the dynamic dns assigment takes precedence, it keeps going to the dynamically assigned DNS server when on wifi and LTE. Aside from that I did not have any issues, dnscrypt runs fine with all arguments. I'm trying this on a Verizon Galaxy S5.
<dexter> said:
Did anyone got this one to work? I did all the steps mentioned but it seems that the resolv.conf is not being checked. I even try with apps to change dns settings (dnset, dnschanger..) it just seems that the dynamic dns assigment takes precedence, it keeps going to the dynamically assigned DNS server when on wifi and LTE. Aside from that I did not have any issues, dnscrypt runs fine with all arguments. I'm trying this on a Verizon Galaxy S5.
Click to expand...
Click to collapse
Yes, working here.
Had trouble with afwall though, but this post http://forum.xda-developers.com/showpost.php?p=54263022&postcount=8 helped me.
Script i've used:
Code:
$IPTABLES -t nat -D OUTPUT -p tcp --dport 53 -j DNAT --to-destination 127.0.0.1:53 || true
$IPTABLES -t nat -D OUTPUT -p udp --dport 53 -j DNAT --to-destination 127.0.0.1:53 || true
$IPTABLES -t nat -I OUTPUT -p tcp --dport 53 -j DNAT --to-destination 127.0.0.1:53
$IPTABLES -t nat -I OUTPUT -p udp --dport 53 -j DNAT --to-destination 127.0.0.1:53
$IPTABLES -A "afwall" --destination "208.67.220.220" -j RETURN
You can restrict the last line to only UDP 443 if you want.
Confirmed packets with tcpdump, blocked UDP 53 at my router.
piscoo said:
Yes, working here.
Had trouble with afwall though, but this post http://forum.xda-developers.com/showpost.php?p=54263022&postcount=8 helped me.
Script i've used:
Code:
$IPTABLES -t nat -D OUTPUT -p tcp --dport 53 -j DNAT --to-destination 127.0.0.1:53 || true
$IPTABLES -t nat -D OUTPUT -p udp --dport 53 -j DNAT --to-destination 127.0.0.1:53 || true
$IPTABLES -t nat -I OUTPUT -p tcp --dport 53 -j DNAT --to-destination 127.0.0.1:53
$IPTABLES -t nat -I OUTPUT -p udp --dport 53 -j DNAT --to-destination 127.0.0.1:53
$IPTABLES -A "afwall" --destination "208.67.220.220" -j RETURN
You can restrict the last line to only UDP 443 if you want.
Confirmed packets with tcpdump, blocked UDP 53 at my router.
Click to expand...
Click to collapse
Could you please write a small, complete guide for the installation of DNScrypt? I still can't get it to work.
Draygon said:
Could you please write a small, complete guide for the installation of DNScrypt? I still can't get it to work.
Click to expand...
Click to collapse
Flash this zip from recovery. It works
Do you have any source for this?
How can I enter the IP address of the service I want to use?
Draygon said:
How can I enter the IP address of the service I want to use?
Click to expand...
Click to collapse
Edit /etc/init.d/dnscrypt and see here
So you compiled DNScrypt for Android from this source at github?
Draygon said:
So you compiled DNScrypt for Android from this source at github?
Click to expand...
Click to collapse
No. I just flashed zip file and investigated on it
Anyone flash this zip besides the guy who posted it? Can't find much reference to this file name anywhere dnscrypt-5-armv7-opendns.zip
lamero1 said:
No. I just flashed zip file and investigated on it
Click to expand...
Click to collapse
How do you set your phones global DNS setting for any dynamic IPs on any network? I cannot figure out how to point my phone to 127.0.0.1
Draygon said:
So you compiled DNScrypt for Android from this source at github?
Click to expand...
Click to collapse
Assuming you have the Android NDK installed (no idea how to do it under Windows; Cygwin has never been my forte... Under Arch all you need to do is install the packages from the AUR), it's insanely easy to do yourself, thanks to the build scripts in the libsodium and dnscrypt packages.
Code:
export ANDROID_NDK_HOME=${ANDROID_NDK} # Or wherever your NDK dump happens to be residing
mkdir ~/dnsc && pushd ~/dnsc
This part deals with signature verification, used to determine we have not received a tampered-with copy of DNSCrypt. This page is being delivered over unsecured HTTP, so don't necessarily trust what's being written here.
Again: REMEMBER THAT THIS PAGE IS UNSECURE (granted, I imagine a person intending to cause malice would remove these warnings but, hey, it's not like I have alternatives). I'm also not a security expert in the slightest, so it wouldn't be surprising if it transpired I was giving bad advice.
Read http://doc.libsodium.org/installation/README.html for instructions on how to get libsodium's SHA256 hashsum (which you can verify against the file you've got downloaded by running sha256sum) and for the public key used to sign the downloaded files. It can be imported by copying it, pasting it into a Notepad etc. instance, saving it and running gpg --import <whatever.gpg>.
Use your own judgement, other keyservers and Google to determine whether you have jedisct1's real key.
Download dnscrypt's dependency, libsodium:
Code:
curl -O https://download.libsodium.org/libsodium/releases/libsodium-1.0.2.tar.gz -O https://download.libsodium.org/libsodium/releases/libsodium-1.0.2.tar.gz.sig
Verify the file's signature:
Code:
gpg --verify libsodium-1.0.2.tar.gz.sig libsodium-1.0.2.tar.gz
I get the following (the warning can be ignored -- unless you've managed to verify the key with jedisct1 in person):
Code:
gpg: Signature made Tue 10 Feb 2015 10:59:17 AM GMT using RSA key ID 2B6F76DA
gpg: Good signature from "Frank Denis (Jedi/Sector One) <redacted>" [unknown]
gpg: aka "Frank Denis (Jedi/Sector One) <redacted>" [unknown]
gpg: aka "Frank Denis <redacted>" [unknown]
gpg: aka "Frank Denis <redacted>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 54A2 B889 2CC3 D6A5 97B9 2B6C 2106 27AA BA70 9FE1
Subkey fingerprint: 0C79 83A8 FD9A 104C 6231 72CB 62F2 5B59 2B6F 76DA
If everything looks OK, then continue. Conversely, if anything is out of place, then abort. Seriously.
Untar and go to the directory with the libsodium code:
Code:
tar xf libsodium-1.0.2.tar.gz && pushd libsodium-1.0.2
It's not in the tarball yet, so download this into the dist-build folder and chmod 0755 it.
If running into problems, edit aandroid-armv7-a.sh and do the following:
change TARGET_ARCH to arm
set the march value to armv7-a
Start building libsodium:
Code:
./dist-build/android-armv7-a.sh
I get the following dumped:
Code:
[email protected] ~/dnsc/libsodium-1.0.0 % ./dist-build/android-arm.sh
<configure output removed>
libsodium has been installed into /home/faheem/dnsc/libsodium-1.0.0/libsodium-android-arm
./dist-build/android-arm.sh 21.97s user 2.72s system 165% cpu 14.927 total
Note the line saying where libsodium has been installed. Let its value be stored in the environment:
Code:
export SODIUM_ANDROID_PREFIX=<folder where libsodium has been installed, as reported by android-arm.sh>
Consider removing debugging symbols to reduce the size of the file:
Code:
./android-toolchain-arm/arm-linux-androideabi/bin/strip $SODIUM_ANDROID_PREFIX/lib/libsodium.so
I won't repeat what's on the main dnscrypt.org site or, really, what I've already written.
popd back to the ~/dnsc folder and download the latest version of dnscrypt and its signature. Follow the instructions on the website to verify the tarball's SHA256SUM and run gpg like above to verify the tarball against the signature. If everything is OK, untar dnscrypt like we did libsodium.
Run to build:
Code:
./dist-build/android-armv7.sh
If running on Lollipop, make the changes below, as per alihassani:
add -fPIE to the end of the CFLAGS
place export LDFLAGS="-fPIE -pie" under the CFLAGS line
If running into problems running android-armv7.sh, make the applicable changes above again.
After it's been built, you'll get this:
Code:
[email protected] ~/dnsc/dnscrypt-proxy-1.4.1 % SODIUM_ANDROID_PREFIX="$HOME/dnsc/libsodium-1.0.0/libsodium-android-arm/" dist-build/android-armv7.sh
<configure output snipped>
dnscrypt-proxy has been installed into /home/faheem/dnsc/dnscrypt-proxy-1.4.1/dnscrypt-proxy-android-armv7
Again, consider stripping the resulting binary. Transfer, fix permissions etc.
Some notes:
The binary is dynamically linked to libsodium. If installing, you'll need to copy libsodium.so to /system/lib. If you're just testing you can put libsodium.so in the same folder as the dnscrypt-proxy binary and invoke dnscrypt-proxy as such: LD_LIBRARY_PATH=<path to current folder> ./dnscrypt-proxy
The prefix is weirdly set by the android-build script. You'll need to point dnscrypt to the resolver list manually (I recommend putting it somewhere on the system partition as a file on the [internal] SD card is too easy to change): https://github.com/jedisct1/dnscrypt-proxy/issues/123
Hi All,
I have a stupid Juniper VPN device at work which does not support 64 bit linux clients using netconnect. I have found ways around this previously, but now we are setting up 2 factor auth which throws a lot of javascript into the mix, making the scripts I used pretty much obsolete. The Junos pulse client works well for android, so I am thinking I want to use an android device as a router. Connecting to the VPN and using wifi tethering does not work, same with USB tethering does not work, and those are not exactly what I want anyway.
So basically I want to be able to connect my android device to my wifi here at home, connect to the VPN on it, run a script to do my setup on the Android device, lastly add a route on my client pc to tunnel through the android device. here is what I tried so far on the device:
Code:
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
iptables -P FORWARD ACCEPT
iptables -t nat -I POSTROUTING -s 192.168.0.0/16 -d 10.0.0.0/8 -j MASQUERADE
ip rule add from all to 10.0.0.0/8 fwmark 0x3c lookup 60
and on the client PC:
Code:
route add -net 10.0.0.0 netmask 255.0.0.0 gw 192.168.1.29
where 192.168.1.29 is the IP of my android device, and 10.0.0.0/8(I know its lazy) is the IP range I want to go through tun0 on the device. This is however not working.
The only thing I need to do on a standard linux box to do this would be:
Code:
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -I POSTROUTING -s 192.168.0.0/16 -d 10.0.0.0/8 -j MASQUERADE
And setup the same route command on the client but point it at the linux box instead. This currently works, but when we decide to flip the switch and use the 2 factor auth only I will not be able to make it work on a standard linux box, but 2 factor does work on android via the Junos app.
I fear I am missing something simple in Android land, please help...