I'm building an app that relies on a lot of online content. I'd like to monitor how much is being downloaded and attempt to minimize it as much as possible. These days, with more and more carriers implementing data caps, users deserve an application that has gone through data consumption testing.
Well, not exactly advanced tools. But you can use iptables in the underlying Linux system to give you network info. I used this a little while ago to do a bit of tracking. You needed a rooted phone. I've only tried this out thus far on my G2, not sure how it would fare on an emulator or something of the sort. But assuming that you did have a rooted phone, which will have the iptables command available, can use iptables to segment some traffic off into a chain and then get the stats out of the chain:
iptables -N app
iptables -A OUTPUT -d a.b.c.d -j app
If you wanted to track data you were sending to IP a.b.c.d from your handset. Then you can dump the stats from iptables using "iptables -L -v -n" to get the packet count and byte count by rule.
Might not be the right solution for you given that you control the source of the program. But comes in really useful for monitoring when you don't have the ability to modify the code.
Related
I am doing some investigation of a closed-source app using ADB. I would like to log the commands this app is making, the ADB binaries it uses are in the same directory. Would I be able to sniff the commands by faking an ADB device or maybe modding the source code of the build tools to include a log?
Best regards.
I tried using some apps on a physical android device to log the incoming packets, though I got nowhere. I expect to be able to know what this closed source app is doing on my device.
PS: I am sorry if this sounds dumb, I know ADB is open source, part of the Android Open Source Project, but I made this post to make sure I am not missing some small detail. I am not an expert in the ADB protocol so excuse my clumsiness.
Answer:
Copied from this answer to How to fetch ADB shell traffic?
It is as simple as listening on the ADB server's port through Wireshark (TCP port 5037) since all the commands pass through the adb server/daemon before going to USB.
It is also possible to sniff the USB traffic using USBPcap, as it also is unencrypted.
I have many questions about Android command. I do not know where I should start But, anyway, I have put all question related Android commands. Here ;
Is subset of Linux commands come in Android by default ? Or, Are we installing something ?
In system/bin, there are lots of commands. Where can I find their meaning ? I have tried man, but man is not built in.
Can I start and stop application via start and stop command ?
Why cannot I run the reboot from terminal emulator ? The error permission is denied.
NOTE : feel free to reedit the question, if you see meaningless part.
Is subset of Linux commands come in Android by default ? Or, Are we installing something ?
A subset exists by default within the system. Things like ls, cd, mkdir, cat etc... are present. You can gain access to a wider range by installing Busy Box on a rooted device, as stated by Zac.
In system/bin, there are lots of commands. Where can I find their meaning ? I have tried man, but man is not built in.
The ADB Page is a good place to start. That covers many of the basic ADB and shell commands. It states near the bottom:
"For a complete list of commands and programs, start an emulator instance and use the adb -help command."
So you can use adb -help on an emualator or device to see a full list of the ADB and shell commands (note I think this list will be android specific commands only, it won't include things like cd,ls and other basic unix commands).
Can I start and stop application via start and stop command ?
No, it states on the ADB dev page:
start ........ Starts (restarts) an emulator/device instance.
stop ........ Stops execution of an emulator/device instance.
To start an application you'll use the am utility iirc it will look something like am start com.your.packagename It's been a while though, I might have syntax wrong. The instructions are listend if you issue the am command by itself with no params in a shell.
Why cannot I run the reboot from terminal emulator ? The error permission is denied.
The system prevents applications from rebooting the device unless they are signed with the same key as the OS. When you use the terminal emulator you are restricted to whatever permissions that application has declared. The reboot permission is not granted to any third party applications, so it won't work correctly from any terminals. You could probably do it if your device was rooted and you used su though
EDIT:
Here is another good resource that lists more of the shell commands
There are not many Linux commands included in android, however if you are rooted you can easily install busybox which has a large range of linux commands.
You need to have root access to reboot your device via the command line (to prevent any old app being able to do it)
I was using earlier adb to debug Android applications over wifi, usb - it was great.
Right now I am wondering if it is possible to connect phone with adb via bluetooth.
I did a quick research but didn't find anything - have you tried it already ?
It is not supported by the current adb software, however you could probably make it possible if you have a rooted device (or possibly even if not - see below) either by modifying adb or by using bluetooth to tunnel a channel it does support, such as tcp.
You would need to obtain the source for the adb program - the same source is used to build both the PC and the device versions. First step is to just build it with unmodified functionality, which may take a fair amount of build system modification unless you do so as a part of a complete android source build (the way it was intended to be done)
Then you would modify it to add a bluetooth channel as an option and install it on the device (why you need root) and in your path on the PC. You'd think you could run it from an alternate location on the PC, and you likely can as long as you use it from the command line, but if your fire up DDMS it may kill off the running adb server and launch a new one using the default in the path, so ultimately you'll have to put your modified version there.
IF you can already get your device to accept adb connections over tcp (possible with root, perhaps possible in some cases without) there is another option, which is to not modify ADB (or at least not modify the device side) and instead come up with something running on the device which accepts bluetooth connections and forwards the traffic via local loopback to the tcp port on which the stock adb is operating. This would save the trouble of having to rebuild adb.
If you have some kind of tethering or similar network-over-bluetooth solution, you might even be able to leverage that to carry adb-over-tcp-over-bluetooth without writing any code.
Finally note that it is not 100% essential that the adb daemon run as a more privileged userid or be installed in place of the official one - you can run an adb daemon as an ordinary application and do many of the expected things with it. However, whichever adb daemon is running first will grab the unix domain java debug socket, and so only that adb daemon will be able to provide the full java debug services. More primitive things like logcat, shell, running process list, push/pull, etc will at least partially work without this, provided that your adb daemon doesn't quit (modification may be required) when it is unable to claim the debug socket. If you can kill the official adb daemon and exploit a race condition, you may be able to get an unofficial one started before it restarts - you would probably need to have a script or program to do this and run it with setsid from the official adb shell, meaning you'd need to connect via USB first. At that point, you'd also be able to start your unofficial adb daemon running as the same userid as the official one.
You may want to spend some time estimating or testing if the performance (speed) will be satisfactory before investing in a lot of time setting this up for real.
I know this is a bit old but I seem to have found a post that does this. All credit goes to the author of fomori.org for finding this and making the information available. Today it helped me, maybe tomorrow I'll help you by making it easier to find.
Source
I would like to monitor network traffic of my Android Phone. I was thinking using tcpdump for Android, but I'm not sure if I have to cross-compile for the phone.
Another question is the following, If I want to monitor the trafic data for a certain application, there's any command for doing that?
TCPDUMP is one of my favourite tools for analyzing network, but if you find difficult to cross-compile tcpdump for android, I'd recomend you to use some applications from the market.
These are the applications I was talking about:
Shark: Is small version of wireshark for Android phones). This program will create a *.pcap and you can read the file on PC with wireshark.
Shark Reader : This program allows you to read the *.pcap directly in your Android phone.
Shark app works with rooted devices, so if you want to install it, be sure that you have your device already rooted.
Good luck ;)
If you are doing it from the emulator you can do it like this:
Run emulator -tcpdump emulator.cap -avd my_avd to write all the emulator's traffic to a local file on your PC and then open it in wireshark
There is a similar post that might help HERE
Note: tcpdump requires root privileges, so you'll have to root your phone if not done already. Here's an ARM binary of tcpdump (this works for my Samsung Captivate). If you prefer to build your own binary, instructions are here (yes, you'd likely need to cross compile).
Also, check out Shark For Root (an Android packet capture tool based on tcpdump).
I don't believe tcpdump can monitor traffic by specific process ID. The strace method that Chris Stratton refers to seems like more effort than its worth. It would be simpler to monitor specific IPs and ports used by the target process. If that info isn't known, capture all traffic during a period of process activity and then sift through the resulting pcap with Wireshark.
For Android Phones(Without Root):- you can use this application tPacketCapture this will capture the network trafic for your device when you enable the capture.
See this url for more details about network sniffing without rooting your device.
Once you have the file which is in .pcap format you can use this file and analyze the traffic using any traffic analyzer like Wireshark.
Also see this post for further ideas on Capturing mobile phone traffic on wireshark
The DDMS tool included in the Android SDK includes a tool for monitoring network traffic. It does not provide the kind of detail you get from tcpdump and similar low level tools, but it is still very useful.
Oficial documentation: http://developer.android.com/tools/debugging/ddms.html#network
Preconditions: adb and wireshark are installed on your computer and you have a rooted android device.
Download tcpdump to ~/Downloads
adb push ~/Downloads/tcpdump /sdcard/
adb shell
su root
mv /sdcard/tcpdump /data/local/
cd /data/local/
chmod +x tcpdump
./tcpdump -vv -i any -s 0 -w /sdcard/dump.pcap
Ctrl+C once you've captured enough data.
exit
exit
adb pull /sdcard/dump.pcap ~/Downloads/
Now you can open the pcap file using Wireshark.
As for your question about monitoring specific processes, find the bundle id of your app, let's call it com.android.myapp
ps | grep com.android.myapp
copy the first number you see from the output. Let's call it 1234. If you see no output, you need to start the app. If you still don't see the app via ps try using top.
Download strace to ~/Downloads and put into /data/local using the same way you did for tcpdump above.
cd /data/local
./strace -p 1234 -f -e trace=network -o /sdcard/strace.txt
Now you can look at strace.txt for ip addresses, and filter your wireshark log for those IPs.
You would need to root the phone and cross compile tcpdump or use someone else's already compiled version.
You might find it easier to do these experiments with the emulator, in which case you could do the monitoring from the hosting pc. If you must use a real device, another option would be to put it on a wifi network hanging off of a secondary interface on a linux box running tcpdump.
I don't know off the top of my head how you would go about filtering by a specific process. One suggestion I found in some quick googling is to use strace on the subject process instead of tcpdump on the system.
Without root, you can use debug proxies like Charlesproxy&Co.
Packet Capture is the best tool to track network data on the android.
DOesnot need any root access and easy to read and save the calls based on application.
Check this out
Try this application
https://play.google.com/store/apps/details?id=app.greyshirts.sslcapture
We can view all networking communications .. even SSL encrypted communications.
The common approach is to call "cat /proc/net/netstat" as described here:
Android network stats
I'm trying to do kernel debugging for my Nexus One, and have been following instructions from http://bootloader.wikidot.com/android:kgdb. I was wondering if someone has actually got this to work? And has anyone done a more up to date solution for using KGDB to debug the kernel?
I found this post when I was looking for information of KGDB on Android so, despite it being a few years old, I thought it worth posting a link to some work I did to get this up and running on the Nexus 6.
http://www.contextis.com/resources/blog/kgdb-android-debugging-kernel-boss/
I hope this helps anyone else looking for similar answers.
Edited following feedback (thanks all):
To get this working I had to make a UART debug cable based on this Accuvant blog. This is quite a simple circuit which consists of a FTDI 3.3v basic breakout (available from SparkFun at the time of writing), as well as 4 resistors (2 x 1K Ohm, 1 x 1.2K Ohm and 1 x 100Ohm), and a 4-element Tip-Ring-Ring-Sleeve (TRRS) headphone jack. The resistors are essentially providing a voltage divider to reduce the 3.3v down to something a little safer for your phone. By inserting the audio jack with the other end connected to your circuit board, the audio subsystem recognises that a voltage (~2.8V) on the one of the pins and it knows to provide a UART interface via that cable. The FTDI breakout plugs into your PC via USB and from here you can access console messages via a terminal emulator like minicom. However, you now have a serial interface through the same mechanism and that's what we can use for a KGDB connection.
So at this point some relatively minor changes are required to the Nexus 6's serial driver (msm_serial_hs_lite.c) to support KGDB (specifically, the ability to perform atomic character I/O operations). I just ported these changes from the Linux Kernel mainline code as a chap called Stephen Boyd had done the hard work to the full MSM (Qualcomm) serial driver msm_serial.c. His changes can be found here or just search for "msm_serial: add support for poll_" on Google. The port wasn't difficult and my code can be found on github.
Aside from that you need to be able to build a custom kernel for your N6 which google provides lots of information on. You then need to create a boot image which contains the KGDB modifications in the github repo. I took the stock kernel from https://developers.google.com/android/nexus/images, extracted it (using abootimg -x) and then used the following command to repack it with my custom kernel (zImage-dtb) and additional command line params to ensure KGDB would be loaded and point to my serial port like so:
abootimg -u boot.img -k zImage-dtb -c 'cmdline=console=ttyHSL0,115200,n8 kgdboc=ttyHSL0,115200 kgdbretry=4'
With my boot.img created I could boot into it using the command fastboot boot boot.img, open an adb shell and then trigger a breakpoint in the Android kernel using the command:
echo -n g > /proc/sysrq-trigger
It is worth mentioning for completeness that you need superuser privileges to access /proc/sysrq-trigger so you need to have root.
With the phone halted, and your debug cable connected, launch a version of GDB for ARM on your host PC with your uncompressed kernel as an argument (e.g. arm-eabi-gdb ./vmlinux). Note: I'm running Ubuntu 14.04 and using arm-eabi-gdb from the 'prebuilts' directory in my AOSP source repository. Finally, enter the following commands:
set remoteflow off
set remotebaud 115200
target remote /dev/ttyUSB0
All being well this should immediately break into the kgdb breakpoint (that your write to /proc/sysrq-trigger produced) and you can start debugging.
I know that you've already asked a question at the Android Kernel Dev list and got no answers, but did you search through the archives for posts about kgdb and debugging?: http://groups.google.com/group/android-kernel/search?group=android-kernel&q=kgdb&qt_g=Search+this+group
In particular, you might want to look at this post: http://groups.google.com/group/android-kernel/browse_thread/thread/5233e03391867c98/320beef11e737a62
Here's a few other random links that might be helpful:
http://www.cs.gmu.edu/~astavrou/courses/ISA_673/Android_Debugging/Android_GDB.pdf
http://www.cs.columbia.edu/~nieh/teaching/w4118/ubb/Forum6/HTML/000122.html
http://wiki.ncl.cs.columbia.edu/wiki/AndroidVirt:Guides:Kernel_Debugging
http://source.android.com/porting/debugging_gdb.html
Anyhow, this is an interesting question, and I'm really having a hard time finding anything on it. You might want want to try hopping on IRC sometime (#android-dev or #android-root on freenode) and asking some people there for pointers (please post up what you find here), or maybe asking on the xda-developers Android forums.