Ok guys, I'm a web programmer but I'm completely new to reverse engineering..

So, there's this android app called InstaMessage, I'd like to reverse engineer the client's connection to the server, so that I can emulate it on my computer and see what commands are there, perhaps play with it a bit and further create some scripts to act as my user actions

I was thinking of monitoring the traffic, seeing where it leads and which port, an try to start from there.

I know it's a kind of broad question, so if you could give me some tips on where to start off, it would help a lot..


  • Have you tried decompiling the app? If not, that might be a good start, rather than trying to monitor the network traffic. Commented Aug 21, 2015 at 13:55

2 Answers 2


I did this with a lot of Android apps so I'll share what I have learned.

When thinking of sniffing traffic, the first thing that comes to mind is "I'll just root the Android device, run tcpdump on it and I'm done". That works for simple things, but it gets really messy really fast. And if the app uses SSL (like 99% of what's out there) it's even worse.

Use a proxy

Most apps use HTTP/HTTPS to communicate with the server. The easiest way to sniff that kind of traffic is using a sniffing proxy (also called debugging proxy). Common ones are Charles and Fiddler. I use Charles, so I'll show you how to work with it, but Fiddler should be similiar.

First off, you need your computer and your Android device on the same LAN. Upon starting Charles, it will automatically start proxying your computer's traffic. You probably don't want this, so disable it from Proxy -> Proxy Settings... -> Windows. Now point your Android network settings to use your computer as HTTP proxy (Charles default port is 8888). Charles will show you all HTTP traffic from your device.

If you need SSL (HTTPS) proxying, you have to install the Charles certificate on your device. Android requires you to have a protected (at least pattern) lockscreen to install external certificates. You can find the certificate in the doc/ directory in Charles' install path, or you can visit http://www.charlesproxy.com/getssl/ from your device browser. Then, in Charles, go to Proxy -> Proxy Settings... -> SSL, enable SSL proxying and add the hosts you want to proxy (or just add * to proxy everything).

Non-HTTP(S) communication

An HTTP debugging proxy will cover most apps out there. In case the app is not using HTTP(S) things get a little more complex. You may want to look into the SOCKS proxy capability of Charles, and how to configure a SOCKS proxy on your device. If that doesn't suffice, then you'll really want to break out tools like tcpdump/Wireshark. You could set up a fake DNS, ARP spoof the device, use a sniffing VPN, etc. There are a lot of ways to go about it. A fake DNS is also good if you want to emulate the server, instead of the client.

SSL certificate checking

When dealing with SSL, most apps trust what the OS trusts. Since you can intall external certificates on Android, you're good. Rarely, the app will check the server certificate against an embedded CA root. This can be bypassed in a few ways:

  • Using tools like apktool and smali, inject your own certificate into the app, replacing the original one;
  • Write an xposed module that hooks the data send/receive methods, to sniff the decrypted messages;
  • Write an xposed module that hooks the certificate checking routine, bypassing it.

I would go with the first or the last one.


At some point you'll have to look at the application code. Maybe it's using a proprietary binary protocol, maybe the traffic is encrypted or compressed, maybe you can't make sense of some values. I suggest trying multiple decompilers/engines. They are not perfect, and a lot of times one works well where the other fails. Virtuous Ten Studio is a good one to start with. Then I alway extract the classes.dex file from the APK (it's just a ZIP file) and run it through dex2jar. I then run the resulting JAR through JD-GUI (JD-Core engine) and SecureTeam Java Decompiler (Procyon engine). Also, jadx can target DEX directly, without dex2jar.


I checked the app you're trying to reverse. It's using standard HTTPS communication, easy to sniff using either Charles or Fiddler. The server has various GET endpoints and the client sends a base64-encoded data field. This is binary data, I haven't really looked into it but the first 70% is identical in all requests, so I suspect it's some kind of session token. The final part varies with requests, but the whole field is pretty high entropy so I'm thinking it's either compressed or encrypted. I would try to decompile the app and see what's going on. The server response, on the other hand, is plain JSON.


If you want to emulate the server on your own anyway, I would start with the server which just prints out whatever connection data is coming in and point my android there. Much faster and easier than monitoring traffic and filtering out all the stuff that is irrelevant.

  • the app is binary.. how could I point it to my own server?
    – sigmaxf
    Commented Aug 21, 2015 at 6:16
  • Your question is a bit unclear then. You said that you want to emulate the connection, so I was assuming that you want to emulate the server. So you want to emulate the client side only and not the server side?
    – Devolus
    Commented Aug 21, 2015 at 7:04
  • 1
    Seems he doesn't have (his own) server, wants to analyze the connection first, then write a client to emulate the connection to the server. Commented Aug 21, 2015 at 9:47

Not the answer you're looking for? Browse other questions tagged or ask your own question.