So, last week we ran strings over the binary from Pangu's original jailbreak, and some interesting URLs emerged. That made me wonder — what exactly are these URLs used for? Well, some seem to be used for FAQ and help within the Jailbreak app. Others, well, I'm not so sure.
So, let's take a look at what we have coming out of the app when we use it. For this, we'll use tcpdump and wireshark. Tcpdump is easy to install; from the command line on your phone, just type this:
$ apt-get install tcpdump
...and you're good to go. You'll want to install Wireshark on your Mac (or whatever computer you're using). You'll use Wireshark to look over the packet capture from your phone. This is always a good idea - tcpdump is a simpler program with a smaller attack surface; Wireshark's a much larger program. Personally, I usually capture packet data with tcpdump and analyze with Wireshark. I will also admit to being lazy from time to time, and just capturing directly from Wireshark. But here, tcpdump for capture and Wireshark for analysis is the way to go.
Okay, so let's grab some packets. First, turn off data over your service provider (Settings > Cellular; then turn off cellular data). Then, attach to a wifi network you control. Next, spin up tcpdump from the command line:
$ tcpdump -f tcpdump-en0.pcap
Now spin up the Jailbreak. Click around in the interface for a bit, and leave it up on your phone for a while (I think I left it up for 10 minutes or so). The phone is already jailbroken, so we're not going through the entire jailbreaking process, but it ends up we don't need to necessarily.
Now close down tcpdump (ctrl-c will do it), and pull the file off your phone; from the host:
$ scp -P <port_number_for_phone> root@localhost:<path_to_pcap> .
Great! Let's take a look. Open the PCAP file with wireshark - lots of stuff here to look at. First, let's take a look through the other systems we're communicating with (go to, in Wireshark, Statistics > Resolved Addresses); you'll see something like this:
188.8.131.52safebrowsing.cache.l.google.com 192.168.1.106iPad.local 184.108.40.206image.uc.cn.w.alikunlun.com 220.127.116.11ocsp.pki-apple.com.akadns.net 18.104.22.168applog.ucdns.uc.cn
Wait a minute - that last one looks interesting. Let's look a little deeper:
$ nslookup applog.ucdns.uc.cn Server:10.0.20.1 Address:10.0.20.1#53 Non-authoritative answer: Name:applog.ucdns.uc.cn Address: 22.214.171.124
Let's also take a look at applog.uc.cn, from our strings analysis of the binary:
$ nslookup applog.uc.cn Server:10.0.222.1 Address:10.0.222.1#53 Non-authoritative answer: applog.uc.cncanonical name = applog.ucdns.uc.cn. Name:applog.ucdns.uc.cn Address: 126.96.36.199
Well look at that, they're the same system; applog.uc.cn is an alias for applog.ucdns.uc.cn. So what kind of traffic is heading to this system? is it just DNS data? I mean, the canonical name makes it seem that way. We can also run whois to look at who controls this domain:
$ whois uc.cn Domain Name: uc.cn ROID: 20030312s10001s00053990-cn ... Registrant: 广州市动景计算机科技有限公司 Registrant Contact Email: firstname.lastname@example.org ...
Hmmm, that's something; let's check out who owns ucweb.com:
$ whois ucweb.com ... Domain Name: ucweb.com Registry Domain ID: 98132324_DOMAIN_COM-VRSN Registrar WHOIS Server: whois.markmonitor.com Registrar URL: http://www.markmonitor.com ... Admin Email: email@example.com ... Tech Email: firstname.lastname@example.org ...
Hmm, okay, so this domain is registered out of China and the technical and administrative contacts are affiliated with Alibaba (there's some additional information I'm not showing; actual names and contact numbers, but I'm not showing them. You can look them up yourself if you'd like, though). And again, we have hints that these are used for DNS (ie.g. dnsadmin@...). Well, now let's check out the actual packets heading to this IP address. In Wireshark, there's a filter box above the packet collection; filter on the destination IP like this:
This'll give you a list of the packets to this address. A quick look shows that this isn't DNS traffic; all the packets are TCP/IP; in fact, they're over TLS1.2. Well, that's interesting. Remember, the URL was an HTTPS url from strings. Perhaps we want to capture some HTTPS traffic? Next time, we'll insert an HTTPS proxy between our phone and the internet and see what we can capture. Things are getting interesting.