This is probably not that useful unless (a) you're paranoid or (b) you need access to a secured network from your phone, however I managed to build openvpn and stunnel against bionic and the onboard openssl library. These are available at http://g1.fnord.to/crypto
OpenVPN requires root access and busybox. With this you can conceivably route all IP traffic through a server somewhere by use of the 'route' command, after the VPN link is brought up. This has been tested, and does not seem to affect phone functionality.
stunnel doesn't require root afaik so you should be able to run it from /data/local. This should allow you to encrypt web traffic at least, by setting the proxy via the 'Proxy Settings' app that's available with AnyCut.
Some how I think T-Mobile might get mad if you did this... They say they allow tethering but if you go over your 10GB limit and they can't see your traffic I would think they would want to know what is up.
Good idea and I know some people are that paranoid... but I see this getting people in trouble... or maybe it is just me.
This is GREAT. I've been looking for this since the day I got my G1. I tried to compile a statically-linked binary a while back, but it was HUGE and wouldn't do much before segfaulting at me.
This gets a 4 smilies because this is how I access my work network remotely from my desktop, and now I can access some of these servers for maintenance remotely from my phone! (I would have given it a whole row of smilies, but apparently that is frowned upon.)
Thanks a million for getting this working!
I probably won't be using it as a default route, but it can be a static route to my office servers for sure!
Just got done testing this to vpn to my workplace and it works awesome. It also routes all traffic while tethering thru the vpn tunnel route.
This has been the best reason for me to get root yet.
Wow this is dope... trying to set this up now so now I can connect to my server on the go. I hope t-mobile don't even see this cuz they will be trippin over why do you need to hide your traffic but this is great no more keeping record of wat you do. Next is gonna be p2p and I will even fell back for t-mobile network lol Thanks this great
neoobs said:
Some how I think T-Mobile might get mad if you did this... They say they allow tethering but if you go over your 10GB limit and they can't see your traffic I would think they would want to know what is up.
Good idea and I know some people are that paranoid... but I see this getting people in trouble... or maybe it is just me.
Click to expand...
Click to collapse
It would probably help for wifi usage. I never connect to public wifi with my G1 for this very reason. I have openvpn running on my router at home so I can tunnel into it when i'm wifi-ing on the go. If the G1 is in an area where there is no 3G coverage but there is public wifi, this might just be what the doctor ordered.
Can the G1 auto connect to openvpn whenever it connects to a network (via wifi), i want it to automatically poll mail for me..
The openvpn daemon is designed to autoreconnect if a keepalive ping fails. I would think if it is running in the background and you changed from Edge/3g to Wifi that it would force a reconnect situation, and it would re-establish the vpn through the new connection.
I will test this right now and get back to you
After testing, it works as expected. ~60 seconds after starting wifi I got the following message:
Inactivity timeout (--ping-restart), restarting
After that it re-established the tunnel through the new interface, and I was able to access machines at my office again.
I didn't know if anyone used a shell script to start/stop their VPN but I made the following so that I can easily start and stop it
Code:
#!/system/bin/sh
case "$1" in
'start')
modprobe tun
/data/local/bin/openvpn --config /path/to/config.ovpn --writepid /data/local/openvpn.pid &
;;
'stop')
kill -9 `cat /data/local/openvpn.pid`
sleep 2
rmmod tun
;;
*)
echo "Usage: $0 [start|stop]"
;;
esac
Instead of keepalive for timeout detection, it would be nice to have hooks called on ifup/ifdown, just like debian's /etc/network/if-up.d/*.
It would allow immediate reconnection upon switching interfaces (between 3G and Wifi for example), and also prevent a situation where an interface comes up, sets the default route, and traffic goes cleartext for 60 seconds until vpn reconnection.
I can think of a lot of other uses for such hooks. Does android offer them?
If we're certain the hooks do not exist natively, I'll find a non-polling way to provide them.
I couldn't find an android interface for ifup, so I just used the netlink notifications, via ip(8). Note that you need the real iproute2 ip binary rather than the busybox one. Probably awk as well - I didn't check since I use debian binaries rather than busybox.
Here's how you use it:
Code:
ip monitor route | awk -W interactive '/^default/ {system("/data/local/bin/ifup " $5)}'
It'll execute /data/local/bin/ifup whenever the default route is changed, and pass the interface name as $1. For 3G/GPRS the interface name is usually rmnet0, whereas for WLAN it is if<num> where num is increasing on every insmod, probably indicating a leak in the tiwlan driver.
If you want it to reconnect openvpn whenver the route changes, you should probably
Code:
killall -USR1 openvpn
for any interface other than tap0 (or whatever you call your openvpn interface).
The above method can be used for earlier events such as link-up, but I figured a default route would be the best time to start openvpn. For extra paranoia, you might want to use iptables to prevent connections to anything other than openvpn on tiwlan0, and have an "up" line in your openvpn config file to set the default route through your vpn when it comes up.
When I get around to write a nice script that does the above, I'll post it here.
How much space are we talking about using with native iproute2, awk, and other binaries? I would think the amount of space used is getting rather large. I guess that it quickly becomes a good time to start using the SD card to store apps.
I've not wanted to repartition my card, but I could always make a FS image and mount it 'mount -o loop' style.
As for instant-on, I'm not using this for paranoia like some are, so instant doesn't really matter to me nearly as much as it could otherwise.
Space requirements - I don't know how much it takes with the libs since I just use it inside a debian chroot and it's all on the sdcard. I need debian anyway, to run certain X apps, etc, so for me it's not a waste of space. Anyway, if you just build iproute2 and awk, or even your own binary that just creates a netlink socket and blocks on it, it shouldn't take a lot of space. Or, if you happen to have python on the phone, it can be done in a few lines of script instead of another binary.
Re instant on, I find it better, not just for paranoia reasons (e.g. ensuring that I never send a cleartext pop3/imap password over wlan), but also for long-running connections such as ssh. If I run them over the vpn interface, I have a fixed IP and the connections persist. If, on the other hand, I create the connection directly over 3g/wlan/gprs, it'll die as soon as I change interfaces. Therefore, I'd rather run all long-running connections over openvpn. IP mobility RFC implementation would be more efficient but as long as it's not an option, a vpn will do.
By the way, do we currently have a way to tie a script/executable to an icon/shortcut, or do you run your script from a terminal?
My understanding is there are problems running apps from a gui shortcut.
http://forum.xda-developers.com/showpost.php?p=3142661&postcount=93
I run everything I do from a terminal.
I guess we need a small loader then. Something that calls Exec.createSubprocess(), just like Term.apk does. Each app will have a symlink to this ShellLoader.apk, which will execute scripts based on the name it was executed under. Another one for the TODO list
From Term.java:
Code:
public void onCreate(Bundle icicle) {
super.onCreate(icicle);
Log.e(Term.LOG_TAG, "onCreate");
setContentView(R.layout.term_activity);
mEmulatorView = (EmulatorView) findViewById(EMULATOR_VIEW);
int[] processId = new int[1];
if (TEST_MODE) {
// This is a vt100 test suite.
mTermFd = Exec.createSubprocess("/sbin/vttest", null, null);
} else {
// This is the standard Android shell.
mTermFd = Exec.createSubprocess("/system/bin/sh", "-", null,
processId);
}
final int procId = processId[0];
final Term me = this;
final Handler handler = new Handler() {
@Override
public void handleMessage(Message msg) {
me.finish();
}
};
Can we use Exec.createSubprocess() as in this above but call "/system/bin/su /data/local/bin/APPLICATIONNAME" to make the Superuser app prompts for root among other things?
Maybe create a user interface that lets you enter what you want in the place of '/data/local/bin/appName' and then when it creates the shortcut also asks if that application needs root?
It could be a list of shortcuts that is selected from a list then. Look like a list of bookmarks perhaps?
I don't know enough of the android environment to know how realistically we could do something like that.
looks like that code example from above is old. Current source from git looks different, but the call looks similar enough. I will play with it here shortly.
Yes, we could do that, including su, but be careful with it
Re bookmarks inside a single loader, I think we can do even better:
We can have a single application called Loader, and call it with different parameters using AnyCut. AnyCut has a "make your own shortcut" option, where you can provide Action, Data and Type. I'm not familiar with the Android environment yet, but I guess the Action can point to the loader, and the Data can be a script name to be executed. This way, a single .apk can be used for starting many native programs.
If implemented that way, I suggest stripping slashes from Data and prepending with /data/local/scripts/ or a similar directory, so that it can only execute scripts the user meant for it to run, rather than arbitrary shell commands. /data/local/scripts/ can contain symlinks to scripts/apps the user wishes to execute from the Android interface. It's more secure that way, while retaining usability.
Makes sense?
Certainly does. You wouldn't want someone to be able to 'rm -rf /' or anything like that.
I think I like restricting it to /data/local/scripts and forcing us to symlink or place any scripts we want to be able run in that path.
Also agree with stripping slashes. There might be other sanitizing that we would want to do to keep malicious actions from being performed.
I would think strip any special characters that have special meaning to the shell * | < > ` etc. If we want to do anything that requires these, we put it in whatever shell script and then just call the script.
Maybe the best route is to just scan the /data/local/scripts folder and allow the user to select from a list.
In any case, whoever does this already has root, so it is just as easy to launch a terminal and break everything from there.
Just a few brainstormed thoughts.
Hi everyone,
I'm trying to write an android program which will allow users to connect to an HID device. The device captures external pen strokes and I would like to retrieve this data and make a basic whiteboard app.
I've made some progress so far: if I use adb push to put the "hidd" daemon on a rooted phone and use hidd --connect, then I can open up hcidump and see the raw data appearing when the pen is used, so I know such a connection is possible.
I'm still a beginner at Android development, but I've learned that app communication with the bluetooth facilities is done via the dbus API. So, I wrote a simple test program using the NDK that tries to make a connection to the system dbus, based on some bluetooth-related code in mydroid/bin/frameworks/base/core/jni:
DBusConnection *conn = dbus_bus_get(DBUS_BUS_SYSTEM, &err);
On my non-rooted phone, this results in the error "VERBOSE/JNI1Activity_DEBUG(3226): Result: Could not get onto the system bus: Failed to connect to socket /dev/socket/dbus: Permission denied."
If I go ahead and do chmod 666 on /dev/socket/dbus on my rooted phone, then the connection can be made without error.
So, my question is this--first of all, am I going about this the right way? If so, is there some way that an application can get permission to talk to dbus on a non-rooted phone?
(If I can get this working, I think the next step would be to try and package/build in the needed parts of hidd to include with my app...)
Many thanks for any help,
Tom
Hi pyro777,
I was wondering if you received any replies on your query?
I also have a similar problem -- my android app accesses Dbus via a JNI, but I am getting the same permissions problem. I can use your workaround of explicitly setting the permissions on /dev/socket/dbus, but that solution can't be used for production code.
My Android java app as BLUETOOTH permissions, but this doesn't appear to be applied across the JNI boundary (as my experience indicates) into the JNI c++ library (*.so).
Does anyone have more info on this issue?
Thanks in advance,
robin
Hi evodevo,
No, no such luck so far if you figure it out I'd be happy to hear.
Strange, if this fails how does the normal Bluetooth java API it?
Perhaps certain permissions need to be set on your app? BLUETOOTH_ADMIN or so?
question 4 u: which libraries do you include when doing dbus stuff I get undefined references the whole time?
A Chairde
I am wondering if anyone can help me. I have heard there are Rooting methods on Android devices not involving third party software on the device, could you tell me what they are, and what phones support them. I have read the XDA Developers book, and the closest I have come is the Google Nexus phone on Chapter 8, Unlockable device, but still needs to load Busybox APK, and SuperUser binaries.
This question revolves around sound forensic techniques, I believe XRY load tools into RAM when using physical extraction.
Any help / pointers would be greatly appreciated
crumdub12 said:
A Chairde
I am wondering if anyone can help me. I have heard there are Rooting methods on Android devices not involving third party software on the device, could you tell me what they are, and what phones support them. I have read the XDA Developers book, and the closest I have come is the Google Nexus phone on Chapter 8, Unlockable device, but still needs to load Busybox APK, and SuperUser binaries.
This question revolves around sound forensic techniques, I believe XRY load tools into RAM when using physical extraction.
Any help / pointers would be greatly appreciated
Click to expand...
Click to collapse
By default, Android doesn't have the ability to substitute the current user for the root user, which is why the 'su' binary has to be installed. By adding a particular line to '/data/local.prop', you can trick the ADB into thinking it's communicating with an emulator, which would temporarily give the ADB elevated permissions, but most of the techniques needed to do so require other binaries that Android doesn't have by default, hence the need for Busybox.
XRY physical extraction, on the other hand, doesn't communicate with Android at all, so there are no "root" permissions to be gained. It relies more on very low level communication with the hardware itself and extracting raw data (i.e. ones and zeros). Highly specialized software would then be needed to translate that data into a more human readable format.
So, to answer your question...
As far as I'm aware, there is no way to achieve permanent "root" permissions on Android without (at the very minimum) installing the 'su' binary.
soupmagnet said:
By default, Android doesn't have the ability to substitute the current user for the root user, which is why the 'su' binary has to be installed. By adding a particular line to '/data/local.prop', you can trick the ADB into thinking it's communicating with an emulator, which would temporarily give the ADB elevated permissions, but most of the techniques needed to do so require other binaries that Android doesn't have by default, hence the need for Busybox.
XRY physical extraction, on the other hand, doesn't communicate with Android at all, so there are no "root" permissions to be gained. It relies more on very low level communication with the hardware itself and extracting raw data (i.e. ones and zeros). Highly specialized software would then be needed to translate that data into a more human readable format.
So, to answer your question...
As far as I'm aware, there is no way to achieve permanent "root" permissions on Android without (at the very minimum) installing the 'su' binary.
Click to expand...
Click to collapse
SoupMagnet,
You answered my question fully, you are a legend !!
The latest build of Android hitting devices has been known for a while to be mostly about bug fixes with only a few minor changes that could be categorized as visual tweaks, like with the dialer and the people apps. It seems that the update to Android 4.4.3 also appears to be patching a really old security flaw that has been sitting in the code that exists within the part of the Android system known as VOLD, or Volume Management Daemon. Most people will probably never be familiar with this particular part of the Android OS or what it does for them, but basically it exists to manage the task of mounting your SD card. The new update fixes a vulnerability that uses VOLD to complete various attacks on the system of an Android device, most worrisome being a way to achieve root access.
The VOLD system doesn’t just handle mounting the SD card and creating /sdcard paths, but it also handles the task of mounting virtual file systems which is where the security flaw actually takes place, using a virtual file system called ASEC or Android Secure External Caches. Within the ASEC is where attackers can exploit the weakness, basically resulting in the system allowing them to manipulate the privileges of an application. Normally, most apps on an average Android device will only have read access unless the device is rooted, in which case the user can go into the files and provide read/write access to certain apps. The vulnerability allows for an attacker to slip into the VOLD and temporarily give write access to an application which is essentially a root privilege, which could allow them to manipulate the app for various potentially dangerous activities.
Thankfully with 4.4.3 Google was able to readily fix this security issue by installing a check in the VOLD that would basically prohibit redirecting the path from its designated location. Since this check never existed before attackers could pass into a path and the system never verified validity of the action, allowing the attacker to pass in without much difficulty. With the vulnerability being patched in with this newest software update any devices that will be moving forward to 4.4.3 generally won’t have to worry, but older devices could essentially still be vulnerable since the flaw has been around for quite some time. The good news for those using device who will never get the update to Android 4.4.3 is that completing such an attack requires multiple exploits, so there are limits to the attack.
DISCLAIMER:
It is extremely illegal to use this app against networks you don't own or don't have a permission to attack. I am not responsible for how you use it and any damage you may cause. Consider yourself warned.
Hijacker is a Graphical User Interface for the wireless auditing tools airodump-ng, aireplay-ng and mdk3. It offers a simple and easy UI to use these tools without typing commands in a console and copy&pasting MAC addresses.
This application requires an android device with a wireless adapter that supports Monitor Mode. A few android devices do, but none of them natively. This means that you will need a custom firmware. Nexus 5 and any other device that uses the BCM4339 (and BCM4358 (although injection is not yet supported so no aireplay or mdk)) chipset will work with Nexmon. Also, devices that use BCM4330 can use bcmon.
The required tools are included in the app. To install them go to Settings and click "Install Tools". This will install everything in the directory you select. If you have already installed them, you don't have to do anything. You can also have them at any directory you want and set the directories in Settings, though this might cause the wireless tools not being found. The Nexmon driver and management utility is also included.
Root is also necessary, as these tools need root to work. If you don't grant root permissions to it, it hangs... for some reason... don't know why...
Features:
View a list of access points and stations (clients) around you (even hidden ones)
View the activity of a network (by measuring beacons and data packets) and its clients
Deauthenticate all the clients of a network
Deauthenticate a specific client from the network it's connected
MDK3 Beacon Flooding
MDK3 Authentication DoS for a specific network or to everyone
Try to get a WPA handshake or gather IVs to crack a WEP network
Statistics about access points (only encryption for now)
See the manufacturer of a device (AP or station) from a OUI database (pulled from IEEE)
See the signal power of devices and filter the ones that are closer to you
Leave the app running in the background, optionally with a notification
Copy commands or MAC addresses to clipboard, so you can run them in a terminal if something goes wrong
Include the tools
Reaver WPS cracking (pixie-dust attack using NetHunter chroot)
.cap files cracking with custom wordlist
Let the user create custom commands to be ran on an access point or a client with one click.
Installation:
Make sure:
you are on Android 5+
you are rooted. SuperSU is required. If you are on CM, install SuperSU
have installed busybox (opened and installed the tools)
have a firmware to support Monitor Mode on your wireless interface
Download the latest version here.
When you run Hijacker for the first time, you will be asked whether you want to set up the tools or go to home screen. If you have installed your firmware and all the tools, you can just go to the home screen. Otherwise, click set up to install the tools. You can change the directories in which they will be installed, but I recommend that you leave them unchanged. The app will check what directories are available and select the best for you. Keep in mind that on some devices, installing files in /system might trigger an Android security feature and your system partition will be restored when you reboot. After installing the tools and the firmware (only Nexmon) you will land on the home screen and airodump will start. If you don't see any networks, make sure you have enabled your WiFi and it's in monitor mode. If you have a problem, go to settings and click "Test Tools". If they all pass, you probably don't have monitor mode enabled. If something fails, click "Copy test command" and select the tool that fails. A sample command will be copied to your clipboard so you can open a terminal, run it, and see what's wrong.
Keep in mind that Hijacker is just a GUI for these tools. The way it runs the tools is fairly simple, and if all the tests pass and you are in monitor mode, then you should be getting the results you want. But also keep in mind that these are AUDITING tools. This means that they are used to TEST the integrity of your network, so there is a chance (and you should hope for it) that the attacks don't work on a network. It's not the app's fault, it's actually something to be happy about (given that this means that your network is safe). However, if an attack works when you type a command in a terminal, but not with the app, feel free to post here to resolve the issue. This app is still under development so bugs are to be expected.
Troubleshooting:
First of all, if the app happens to crash at a random time, run it again and close it properly. This is to make sure that there are not any tools still running in the background, as this can cause battery drain. If it crashes during startup or exiting, open a terminal, run `ps | busybox grep -e air -e mdk` and kill the processes you see.
Most of the problems arise from the binaries not being installed (correctly or at all). If that's the case, go to settings, click "install tools", choose directories for binaries and the lib (libfakeioctl.so) and click install. If the directory for your binaries is included in PATH, then you don't have to do anything else. If it's not, the you need to adjust the absolute paths of the binaries, right below the "install tools" option. This might also cause problems (especially with mdk) since these programs require the wireless tools to be installed, and they won't find them if you install them anywhere other than the paths included in your PATH variable. If you don't know what the PATH variable is, then you probably shouldn't be using any of these programs.
If you are certain that there is problem with the app itself and not the tools installation, open an issue here so I can fix it. Make sure to include precise steps to reproduce the problem and a logcat (having the logcat messages options enabled in settings). If the app happens to crash, a new activity should start which will generate a report in /sdcard and give you the option to email it to me directly. I suggest you do that, and if you are worried about what will be sent you can check it out yourself, it's just a txt file and it will be sent as an email attachment to me.
XDA:DevDB Information
Hijacker, App for all devices (see above for details)
Contributors
chrisk44
Source Code: https://github.com/chrisk44/Hijacker
Version Information
Status: Testing
Current Stable Version: v1-RC.4
Stable Release Date: 2016-12-23
Created 2016-11-14
Last Updated 2016-12-26
Reserved
thank you
works great on my nexus 5 and note 3
not working on s6 edge problem i dont know i already installed in my device correctly and also hijacker airdump shows networks for attacking but not do real attack