Archive
Android Process Memory Dumps – Notes
Disclaimer: I don’t really understand everything about the workings of RAM memory and the OS. These are just my notes on how i got RAM Process Memory Dumps of Android Apps.
Intro:
Capturing the process memory from a specific running process (application) in Android seems to have been more difficult that I thought. That’s probably because of the way Android is built that processes run under their own individual users and their respecting permissions.
Reading directly from /proc/<pid>/mem also seems to have been hindered since a process cannot read another process’ memory in Android (i think in some other Unix/Linux distributions at least reading seems to be possible)
A lot of sources talk about capturing “heap” dumps, but i wanted the entire process memory including the stack, the instructions (and essentially anything else). Heap dumps can be acquired through the DDMS tool in Android Studio (and somehow similarly in Eclipse also). The basic idea is that Android Studio provides RAM profiling tools for analyzing app runtime behaviour.
You can take heap dump from DDMS. According to most sources, it seems it needs to be converted from the default HPROF format to something that can be analyzed by the Java MAT tool (i’m not sure but i think DDMS now does all this automatically for you).
What I wanted was a full memory dump of the process and I couldn’t seem to find a way except through using the memfetch tool (by Michal Zalewski) compiled for Android or some smartly written script called memdump (by Tal Aloni) found on StackExchange.
Both scripts are written in C, so I had to compile them for Android and get them running on a phone in order to achieve my goal … and how this was done is the subject of the next post.
Major Sources:
[1]. Sylve, J., Case, A., Marziale, L., Richard, G.G.: Acquisition and analysis of volatile memory from android devices. Digital Investigation. 8, 175–184 (2012). here or here
[2]. http://security.stackexchange.com/questions/62300/memory-dumping-android
[3]. http://lcamtuf.coredump.cx (look for the memfetch code here)
Setting up DNS Tunneling with iodine on Ubuntu 14.04, 15.10
So I thought setting up DNS Tunneling was as easy as getting the server software running, then getting the client software running and once the tunnel is set up we’re good to go.
Easier said than done. The tunnel is set up but the routing also needs to be set up such that traffic goes through the tunnel. Ahaaa … yes that’s where things got tricky.
Summarily, the steps that need to be done are:
Phase I: Getting the DNS server and domain configurations done
Here you’ll need a domain name and access to the authoritative name server. Alternatively you can use a free domain name service that can provide you with the capability of configuring the A resource record (assigning a domain name to an IP) and the NS resource record (assigning the name or IP of the authoritative name server).
(Afraid.org is a nice free service that allows you to make use of free public subdomains and modify the necessary DNS records for this experiment)
Phase II: Getting the Tunneling ready
- Set up your network with an internal client machine, a firewall that locks down the internal machine and a machine that has a (static) public address
- Download the tunneling software (in my case iodine)
- Install (Make, Make install, Make test etc)
- Run the server
- Run the client
Phase III: Getting the routing of traffic through the tunnel and the forwarding at the server side
- Set up forwarding of traffic received on the tunnel to go out the server’s physical interface
- Create a route in the routing table of the client machine that tells the machine to go out through the normal interface to the normal gateway when looking for the usual/normal DNS server (So only DNS traffic to this server has a “default route”)
- Remove the original Default Gateway, and replace it with with the IP of the DNS Tunneling server within the tunnel
Now let’s get straight into the mix of how to configure this …
Step-by-Step Configuration:
The network set up:
- A Client machine within a private/internal LAN: 192.168.XX.XX
- A pfSense firewall with 2 interfaces (one to the internal LAN, that is the gateway 192.168.XX.1) and the other on a public network with a public IP.
- A server with a public address ZZZ.ZZZ.ZZZ.ZZZ (lets make it 123.123.123.123 for illustrative purposes)
The diagram below illustrates the set-up.
Phase I: Getting the DNS server and domain configurations done
Sign up at afraid.org. Either create a new domain or make use of a publicly usable shared sub-domain. Set the A record to be the IP address of your iodine server e.g. 123.123.123.123, and set the name to be something that you’ll remember e.g. test.ignorelist.com. Set the NS record name (testns.ignorelist.com) to point to the domain name (test.ignorelist.com)
That is:
test.ignorelist.com - A - 123.123.123.123
testns.ignorelist.com - NS - test.ignorelist.com
In effect both the (authoritative) name server and the domain itself are at the same IP, though the domain name actually doesn’t seem to be used visibly (to my knowledge).
Phase II: Getting the Tunneling Ready:
Get the latest version of the iodine repository to your server machine. Assuming you’re on Ubuntu for both the client and the server, you’ll need to install git first:
sudo apt-get install git
Clone the latest version of iodine from it’s github repository into whichever directory you please. I chose to clone it to the desktop:
cd Desktop git clone https://github.com/yarrick/iodine.git
Build, install and test the source:
NB: While doing the “make” “make install” and “make test”, it may complain that it’s missing some C header files (eg. zlib.h and check.h), so you should install ‘zlib1g-dev’ and ‘check’ packages/libraries
sudo apt-get install zlib1g-dev check
Then:
cd iodine make make install
Run the tests:
make test
If you’ve so far you’ve set this up on the server machine, then you need to repeat the process on the client machine so as to get the iodine package installed also on the client.
CHECK POINT: At this point you should have iodine installed on both your client and server machines.
Now we can run them so as to get the tunnel set up (To be honest, I haven’t read deeply in into the man pages for the details of the parameters /options available for different capabilities, so i’ll just note down what worked for me)
Run the server:
sudo iodined -c -D 10.0.0.1 testns.ignorelist.com
It may ask you for a password, which i used Password01. Alternatively you could use the -P directive and assign it a password directly in the command.
sudo iodined -c -P Password01 -D 10.0.0.1 testns.ignorelist.com
Run the client:
sudo iodine -P Password01 testns.ignorelist.com
At this point the tunnel should connect with the server having an IP of 10.0.0.1 and the client having an IP of 10.0.0.2. A new tun/tap interface (dns0) should also appear on both the client and the server ipconfig output. There should also be some “keep-alive” pings being logged on the server side terminal.
From the client, ping the server at 10.0.0.2:
ping 10.0.0.2
If the ping succeeds then we’ve made some good progress in setting up the tunnel, … but there’s still more to go.
Phase III: Getting the routing of traffic through the tunnel and the forwarding at the server side
This is done in order to get all the traffic routed from the client machine through the DNS tunnel (dns0) to the server physical interface and onward to the requested resource, and that subsequent responses received on the server side physical interface come back through the tunnel server and are forwarded back through the DNS tunnel to the client.
NB: These steps are only necessary if you want to get ‘all’ traffic from the client passing through the tunnel. If that’s not your desire, then you can skip Phase III.
Setting up IP forwarding on the SERVER SIDE involves changing the ip_forward flag and setting some iptables (ip_tables) rules
sudo bash -c 'echo 1 > /proc/sys/net/ipv4/ip_forward'
Check that the flag has been set to 1
cat /proc/sys/net/ipv4/ip_forward
(many times this ip_forward flag does not persist through reboots)
Set up the NAT rules in iptables to NAT traffic from the dns0 interface to the eth0 interface and vice versa:
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE sudo iptables -A FORWARD -i eth0 -o dns0 -m state --state RELATED,ESTABLISHED -j ACCEPT sudo iptables -A FORWARD -i dns0 -o eth0 -j ACCEPT
If you were unlucky like me, something was wrong with iptables and it could not be found despite the package being installed
sudo modprobe iptables
or
sudo modprobe ip_tables
should sort out the problem. If they don’t then you might have to check that the kernel object exists and if it doesn’t then an update of the the kernel package as follows, then running modprobe might help
/lib/modules/'uname -r'/kernel/net/ipv4/netfilter/iptables.ko
or
/lib/modules/'uname -r'/kernel/net/ipv4/netfilter/ip_tables.ko
Re-installing/updating the kernel image
sudo apt-get install linux-image-$(uname -r)
Run modprobe iptables again as seen above
Now for the tricky part (CLIENT SIDE):
Fix the routing table on the CLIENT machine such that DNS traffic goes legitimately to the local DNS server that usually does domain look-ups on your client’s behalf, out through the original default gateway
sudo route add -host [IP-Address of local DNS server] gw [original default gateway]
e.g:
sudo route add -host 123.123.123.10 gw 192.168.1.1
i.e. adding a route for a host (in this case, the DNS host machine), rather than a network via the normal gateway
The next 2 steps need to be done quickly (if there is a sizeable delay, for some reason the dns0 interface disappears and you won’t be able to add it as the actual default gateway)
Remove the original default gateway:
sudo route del default
Replace the default gateway with the tunnel device interface (dns0)
sudo route add default dev dns0 gw 10.0.0.1
Read as “add default gateway as 10.0.0.1 through device dns0”
At this point you should be able to ping 10.0.0.1 from the client and get a successful response indicating that the tunnel is active and connected.
To test that HTTP traffic is being tunneled over the DNS tunnel, open up Wireshark on the client machine and start a capture on eth0. If you open any webpage e.g. http://www.google.com you should see a flurry of DNS traffic that also corresponds with the verbose output visible on the server terminal
Some gotchas that might trip you up:
Check that the dns0 interfaces are up on both client and servers and that they are pingable between the 2. Sometimes the dns0 interface on the client could disappear unnannounced and you might have to start the client side of the tunnel again and do the routing set up again. Restart the server first for good measure.
Check that the ip_forward flag on the server side is still set to 1
Useful commands for dealing with the SSH Known Hosts File
Some useful things that you can use with ssh-keygen :
Listing all the entries in the known_hosts file:
ssh-keygen -l -f /home/myUserName/.ssh/known_hostsListing the a specific entry
(with IP address only)
ssh-keygen -l -f /home/myUserName/.ssh/known_hosts -F 192.168.1.1(with IP address and port)
ssh-keygen -l -f /home/myUserName/.ssh/known_hosts -F [192.168.1.1]:8888Listing the hash of a specific entry:
ssh-keygen -H -F 192.168.1.1 -f "/home/myUserName/.ssh/known_hosts" Getting the fingerprint off a public-key file (e.g: id_dsa.pub, id_rsa.pub)
ssh-keygen -lf ~/.ssh/id_rsa.pubssh-keygen -lf /home/myUserName/.ssh/id_rsa.pubRemoving an entry from the known_hosts file (using the IP address only):
ssh-keygen -f "/home/myUserName/.ssh/known_hosts" -R ip-addresse.g:
ssh-keygen -f "/home/User1/.ssh/known_hosts" -R 192.168.1.1Removing an entry from the known_hosts file (using the IP address and port) (Commonly seen with services that use non-standard ports):
ssh-keygen -f "/home/myUserName/.ssh/known_hosts" -R [ip-address]:porte.g:
ssh-keygen -f "/home/User1/.ssh/known_hosts" -R [192.168.1.1]:8888Also useful:
Sometimes you may have changed the owner of the known_hosts file by mistake thus making removal of entries impossible. So, to change the owner back to the particular user:
chown userName:Group /path/to/fileRunning Virtual Machines on KVM and QEMU from command line on Ubuntu 14.04
The aim of this post is to document how to get a Lubuntu 14.04 instance, a Windows 7 instance and an Android-86 instance running on KVM (running on QEMU in most cases).
[NB: This is not yet complete, so it may serve only as pointers and not a full guide…]
Install the prerequisites:
sudo apt-get install qemu-kvm libvirt-bin ubuntu-vm-builder bridge-utils
Check if Virtualization is supported on your machine (or virtual machine, if you’re trying to nest VMs) using the kvm-ok command
Method 1: Using the libvirt library / package / set of tools:
NB: I used this to get the lubuntu instance running
sudo apt-get install virtinst
sudo virt-install -n testLubuntu -r 512 \ --disk path=/home/USERNAME/Desktop/VMDisks/testLubuntu.img,bus=virtio,size=6 -c \ lubuntu-14.04.iso --network network=default,model=virtio \ --graphics vnc,listen=0.0.0.0 --noautoconsole -v
Check which VMs are running:
virsh -c qemu:///system list
Stop an instance:
virsh -c qemu:///system shutdown
NB: Replace the with the name of the instance, e.g. in my case “testLubuntu”
Start an instance:
virsh -c qemu:///system start
Destroy and undefine an instance:
virsh -c qemu:///system destroy
virsh -c qemu:///system undefine
Method 2: Using the kvm package directly:
NB: I used this to get the Android-x86 instance running … but without a WiFI network (as of now…)
Create a virtual disk image file
qemu-img create android-4.4.img 8G
Install the Android OS using a virtualized CD-Rom that points to a bootable Android image:
kvm -m 2048 -hda android-4.4.img -cdrom <Bootable-Android-ISO.iso> -boot d
Create a partition that is bootable and writable when the cfdisk prompts you to do so.
I haven’t been able to get the networking part right because it involves some bridging … which is a bit mind-boggling.
Resources:
-
KVM:
- https://help.ubuntu.com/community/KVM/Installation
- http://www.linux-kvm.org/page/Documents
- http://en.wikibooks.org/wiki/QEMU
- https://www.kernel.org/doc/Documentation/virtual/kvm/api.txt
- https://help.ubuntu.com/14.04/serverguide/libvirt.html
- http://www.techotopia.com/index.php/Installing_a_KVM_Guest_OS_from_the_Command-line_(virt-install)
- http://spica-and-roid.blogspot.se/2012/07/howto-porting-android-x86-onto-qemu-kvm.html
- http://virt-tools.org/learning/install-with-command-line/
- http://en.wikipedia.org/wiki/Book:Virtualization
- https://shanetomlinson.com/2009/bridging-a-wireless-card-in-kvmqemu/
- http://blog.bodhizazen.net/linux/bridge-wireless-cards/
- http://www.linux-kvm.org/page/Networking
- http://unix.stackexchange.com/questions/118891/wireless-bridged-networking-in-kvm-why-is-it-so-complicated
- http://blog.alantan.com/2007/01/qemu-tap-bridge-network-configuration.html
Networking:
Installing devstack (Openstack for developers) on Ubuntu 14.04
Step 1: Install git
sudo apt-get install git
Step 2: Clone the latest devstack repository (Grizzly, Icehouse, Juno, Kilo, etc …)
For Icehouse
git clone -b stable/icehouse https://github.com/openstack-dev/devstack.git
or, for Grizzly
git clone -b stable/grizzly https://github.com/openstack-dev/devstack.git
A folder in your home directory with the name devstack should have been created
Step 3: Change directory to the devstack directory
cd /devstack/userDir/devstack
Step 4: Install devstack using the stack.sh installation script
./stack.sh
You will first be presented with at least 5 dialogs asking for passwords for various services. The norm is to use the same password – for easy use while doing development and testing(Great security, right? not really, but it’s for convenience – i.e “Principle of Psychological acceptability”). Read the dialogs carefully and if you chose to put in more secure passwords (longer than 8 characters, alphanumeric, special characters) perhaps note them down somewhere – it may save you a great big headache later.
After these dialogs, the script will run and download stuff from the internet to install (Make sure your internet connection is working). The script runs for at least 20min, if it goes through the entire procedure and works.
At the end of the installation script (which may take at least 20min, so get a coffee, or do something else) you will be presented with the URL where the Openstack dashboard (horizon) can be found, as well as the username and password to log into the dashboard. The default usernames are “admin” and “demo”. The password will be what you set among the dialogs at the beginning, or if you just pressed enter to skip the dialogs, then devstack will choose a random long password for you (which it will show you at this point)
Generally if something went wrong and you want to stop the devstack platform as a whole, i.e. stopping all the services running you can use:
./unstack.sh
If you want to remove everything (well almost everything) that devstack installed on the machine:
./clean.sh
(NB: i’ve had varying success in ensuring that it removes everything. Sometimes you might have to run extra commands like apt-get remove –purge , apt-get autoremove and/or apt-get autoclean among others in order to clean out the devstack installation)
infosectrek 